кластер kubernetes что это

Внутреннее устройство Kubernetes-кластера простым языком

Прим. перев.: как многим хорошо известно, Kubernetes — это всего лишь пять бинарников. Об их назначении и рассказывает в этой статье Vedashree Patil, консультант из Deloitte Digital. Когда ей потребовалось изучить Kubernetes, она столкнулась с большим количеством новой информации, осознать которую за короткое время было непросто. Так она пришла к идее уменьшить порог вхождения в K8s другим специалистам, создав цикл публикаций «Kubernetes 101». Все статьи сопровождаются простыми и наглядными комиксами. Представляем вниманию перевод материала под названием «Внутри кластера» из этого цикла.

Из известного набора стикеров для Telegram

Как выглядит кластер Kubernetes? Как работают узлы? Из этой статьи вы узнаете обо всех основных компонентах системы Kubernetes.

Предисловие

Мы уже говорили о концепции master-slave в Kubernetes. Один узел контролирует все остальные. В Kubernetes все устроено именно таким образом. Но мы ещё не рассматривали, КАК работает связка master-slave. Что именно делает мастер-узел (master node)? Итак, начнём.

Общая картина

Примерно так выглядит типичный мастер-узел:

Мастер-узел (слева) и рабочий узел (справа)

Если вам интересно, что означают все эти причудливые термины, они будут подробно рассмотрены далее. Сначала давайте разберёмся с мастер-узлом…

«Команда» Control Plane

На мастер-узле, также известном как Control Plane (иногда его переводят как «управляющий слой» — прим. перев.), выполняется большинство важных задач по управлению и администрированию кластера. Он включает в себя четыре основных компонента:

API server (API-сервер);

controller manager (менеджер контроллеров);

Команда представителей Control Plane

Давайте подробнее остановимся на каждом из них.

API server

Самый первый, и, пожалуй, самый важный — API-сервер. Это «лицо» Kubernetes. Чтобы взаимодействовать с кластером Kubernetes, вам наверняка придется познакомиться с API-сервером:

А этот парень — API-сервер… И у него Kubernetes API… Знаете, что это значит. Он тот самый супергерой, который выполнит все ваши запросы… — Эй, API-сервер, покажи-ка мне логи недавно задеплоенного веб-сервиса! — Логи уже на подходе.

Для любых манипуляций с кластером приходится обращаться к API-серверу с помощью Kubernetes API. Используете kubectl, REST или любую из клиентских библиотек Kubernetes? Все они завязаны на API Kubernetes’а и взаимодействуют с API-сервером.

Но когда становится реально жарко… — Эй, мне нужно то. — Эй, удали это! — Эй, API-сервер, ты там жив? — Покажи логи! — А как же моя работа? — Создай-ка вон то! Этот парень с лёгкостью масштабируется… горизонтально. — Вперёд, ребятки! Ещё полно работы.

Примечательная особенность API-сервера состоит в том, что он умеет масштабироваться по горизонтали. Другими словами, при резком увеличении количества поступающих запросов API-сервер может создавать «клоны» или реплики самого себя, чтобы справиться с нагрузкой.

Scheduler

Следующий компонент — планировщик. Как вы думаете, что он делает? Правильно, планирует.

А этот занятой парень — планировщик. Именно он назначает узлы новым Pod’ам. — То есть ты утверждаешь, что тебе нужны все эти ресурсы? — Ага!

Новый Pod остается в статусе Pending до тех пор, пока ему не будет выделен узел для работы (рекомендую обратиться к соответствующей статье о Pod’ах). Именно за это отвечает планировщик:

Узел 1 — загружен по полной. Узел 2 — то, что надо. Узел 3 — сидит без работы. — С первым узлом всё понятно. Итак, остались 2 и 3… У 2-го ещё есть чуток ресурсов, а 3-й вообще свободен. Думаю, ему надо чем-то заняться. Ок, тогда 3-й!

Каждому Pod’у требуются определенные ресурсы: память, CPU, железо… в общем, стандартный набор. Планировщик должен решить, какой узел соответствует требованиям Pod’а. Поэтому планировщик выполняет два действия:

Подбирает узлы-кандидаты для Pod’а;

Останавливает свой выбор на одном из них.

Controller manager

Прежде всего стоит узнать, что такое Контроллер.

Я люблю называть его компонентом, который «всё исправляет». Почему? Потому что работа у него такая — приводить в норму. Поясню. Он наблюдает за кластером — словно хищная птица за добычей, без устали и покоя. Если что-то идёт не так, контроллер предпринимает соответствующие действия для исправления ситуации.

Иными словами, у кластера есть состояние, называемое желаемым (англ. desired state). Именно в таком состоянии должен находиться кластер. Контроллер считает его единственно верным. С другой стороны, в каждый момент времени кластер находится в состоянии, называемом текущим (current state). Контроллеры будут делать всё, чтобы привести текущее состояние к желаемому.

Как работает контроллер: текущее состояние (бумага) → требуемое действие (вырезать из бумаги) → желаемое состояние (человечек из бумаги).

Или другой пример: вам требуется двадцать секунд, чтобы пробежать стометровку. Чтобы уменьшить это время до пятнадцати, придется каждый день тренироваться, чтобы достичь цели. Это и есть переход из текущего состояния в желаемое.

На самом деле контроллер — это просто бесконечный цикл, который постоянно следит за неким ресурсом в кластере (например, за Pod’ом). Если что-то идет не так, он исправляет возникшую проблему.

Теперь вернёмся к нашему менеджеру.

Менеджер контроллеров (Controller Manager) — это набор различных контроллеров. Например, может быть один контроллер, который наблюдает за узлами, другой — за задачами (Jobs), и так далее.

Но такой менеджер — это инструмент «всё в одном». По сути, он отслеживает сразу все ресурсы. За это отвечает ОДИН процесс, но благодаря многозадачности складывается впечатление, что одновременно работают несколько контроллеров. Вот некоторые из самых популярных:

Контроллер узлов: «О нет! Похоже, второй узел не работает. Нужно с этим что-то делать». Контроллер репликации: «Pod’у XX нужны три реплики, а там только две. Надо создать ещё одну». Контроллер учётных записей и токенов: «Хм-м, новое пространство имён. Нужны новые токены доступа».

Etcd — это личный журнал Kubernetes. Скажите, зачем люди ведут личные дневники и журналы? Все просто: чтобы сохранить в памяти мимолетные моменты (увы, мозг не способен хранить все события каждого дня нашей жизни).

То же самое и с Kubernetes. Всё, что происходит в кластере, должно быть записано и сохранено. Вообще всё! И тут на сцену выходит etcd. Эта база данных типа ключ-значение выступает резервным хранилищем для Kubernetes.

Переходим к рабочим узлам (worker nodes).

«Команда» рабочих узлов

Мы уже рассмотрели, что такое мастер-узел. Но настоящая работа происходит именно на рабочих узлах. А всё потому, что на каждом узле есть компоненты, отвечающие за его бесперебойное функционирование. Они включают в себя:

Команда представителей рабочих узлов

kubelet

Этот парень, пожалуй, самый важный. kubelet — это агент, который следит за тем, чтобы на узле всё работало должным образом. Подобная работа подразумевает ряд задач.

Первая — взаимодействие с мастер-узлом. Обычно мастер-узел отправляет задачу в форме манифеста или спецификации (Podspec). Манифест определяет, какие работы необходимо провести и какие Pod’ы нужно создать.

Обычный день из жизни kubelet: «Та-а-ак, новый манифест от мастера. Посмотрим… Два Pod’а с образом xxx».

Вторая — взаимодействие с исполняемой средой контейнера (container runtime) на узле. Исполняемая среда скачивает нужные образы, после чего вступает в действие kubelet, мониторя Pod’ы, созданные с использованием этих образов.

— Скачай-ка образ xxx. Нам нужны новые Pod’ы. — Ок!

Третья — проверки (probes) состояния Pod’ов. Кто отвечает за них? Конечно же, kubelet! Потому что следить за здоровьем Pod’а — его обязанность!

— Просто звоню узнать, как ты там. Обычная проверка, как всегда… Всё в порядке? — Лучше не бывает!

kube-proxy

Следующий неотъемлемый элемент — работа с сетью, и kube-proxy готов позаботиться об этом. Он работает как балансировщик нагрузки, распределяя трафик между Pod’ами, а также следит за соблюдением сетевых правил. Можно сказать, что kube-proxy полностью отвечает за коммуникации внутри кластера.

kube-proxy следит за соблюдением сетевых правил. Появился сетевой пакет с IP: 123.456.789.100. — Стой! Твоего IP-адреса нет в списке. Вход запрещён!

Заключение

В статье рассмотрены основные компоненты кластера Kubernetes. Но процесс познания далек от завершения — ещё необходимо освоить множество важных понятий. Например, мы лишь упомянули работу с сетью, ничего не сказали о рабочих нагрузках и конфигурациях в Kubernetes. Не переживайте: обо всём этом вы сможете узнать из будущих статей (в оригинале они публикуются здесь — прим. перев.).

Источник

Основы Kubernetes

В этой публикации я хотел рассказать об интересной, но незаслуженно мало описанной на Хабре, системе управления контейнерами Kubernetes.

Что такое Kubernetes?

Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а так же обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект был начат Google и теперь поддерживается многими компаниями, среди которых Microsoft, RedHat, IBM и Docker.

Компания Google пользуется контейнерной технологией уже более десяти лет. Она начинала с запуска более 2 млрд контейнеров в течение одной недели. С помощью проекта Kubernetes компания делится своим опытом создания открытой платформы, предназначенной для масштабируемого запуска контейнеров.

Проект преследует две цели. Если вы пользуетесь контейнерами Docker, возникает следующий вопрос о том, как масштабировать и запускать контейнеры сразу на большом количестве хостов Docker, а также как выполнять их балансировку. В проекте предлагается высокоуровневый API, определяющее логическое группирование контейнеров, позволяющее определять пулы контейнеров, балансировать нагрузку, а также задавать их размещение.

Концепции Kubernetes

Nodes (node.md): Нода это машина в кластере Kubernetes.
Pods (pods.md): Pod это группа контейнеров с общими разделами, запускаемых как единое целое.
Replication Controllers (replication-controller.md): replication controller гарантирует, что определенное количество «реплик» pod’ы будут запущены в любой момент времени.
Services (services.md): Сервис в Kubernetes это абстракция которая определяет логический объединённый набор pod и политику доступа к ним.
Volumes (volumes.md): Volume(раздел) это директория, возможно, с данными в ней, которая доступна в контейнере.
Labels (labels.md): Label’ы это пары ключ/значение которые прикрепляются к объектам, например pod’ам. Label’ы могут быть использованы для создания и выбора наборов объектов.
Kubectl Command Line Interface (kubectl.md): kubectl интерфейс командной строки для управления Kubernetes.

Архитектура Kubernetes

Работающий кластер Kubernetes включает в себя агента, запущенного на нодах (kubelet) и компоненты мастера (APIs, scheduler, etc), поверх решения с распределённым хранилищем. Приведённая схема показывает желаемое, в конечном итоге, состояние, хотя все ещё ведётся работа над некоторыми вещами, например: как сделать так, чтобы kubelet (все компоненты, на самом деле) самостоятельно запускался в контейнере, что сделает планировщик на 100% подключаемым.

Нода Kubernetes

При взгляде на архитектуру системы мы можем разбить его на сервисы, которые работают на каждой ноде и сервисы уровня управления кластера. На каждой ноде Kubernetes запускаются сервисы, необходимые для управления нодой со стороны мастера и для запуска приложений. Конечно, на каждой ноде запускается Docker. Docker обеспечивает загрузку образов и запуск контейнеров.

Kubelet

Kubelet управляет pod’ами их контейнерами, образами, разделами, etc.

Kube-Proxy

Также на каждой ноде запускается простой proxy-балансировщик. Этот сервис запускается на каждой ноде и настраивается в Kubernetes API. Kube-Proxy может выполнять простейшее перенаправление потоков TCP и UDP (round robin) между набором бэкендов.

Компоненты управления Kubernetes

Система управления Kubernetes разделена на несколько компонентов. В данный момент все они запускаются на мастер-ноде, но в скором времени это будет изменено для возможности создания отказоустойчивого кластера. Эти компоненты работают вместе, чтобы обеспечить единое представление кластера.

Состояние мастера хранится в экземпляре etcd. Это обеспечивает надёжное хранение конфигурационных данных и своевременное оповещение прочих компонентов об изменении состояния.

Kubernetes API Server

Kubernetes API обеспечивает работу api-сервера. Он предназначен для того, чтобы быть CRUD сервером со встроенной бизнес-логикой, реализованной в отдельных компонентах или в плагинах. Он, в основном, обрабатывает REST операции, проверяя их и обновляя соответствующие объекты в etcd (и событийно в других хранилищах).

Scheduler

Scheduler привязывает незапущенные pod’ы к нодам через вызов /binding API. Scheduler подключаем; планируется поддержка множественных scheduler’ов и пользовательских scheduler’ов.

Kubernetes Controller Manager Server

Все остальные функции уровня кластера представлены в Controller Manager. Например, ноды обнаруживаются, управляются и контролируются средствами node controller. Эта сущность в итоге может быть разделена на отдельные компоненты, чтобы сделать их независимо подключаемыми.

ReplicationController — это механизм, основывающийся на pod API. В конечном счете планируется перевести её на общий механизм plug-in, когда он будет реализован.

Пример настройки кластера

В качестве платформы для примера настройки была выбрана Ubuntu-server 14.10 как наиболее простая для примера и, в то же время, позволяющая продемонстрировать основные параметры настройки кластера.

Для создания тестового кластера будут использованы три машины для создания нод и отдельная машина для проведения удалённой установки. Можно не выделять отдельную машину и производить установку с одной из нод.

Подготовка нод

Требования для запуска:

Установка ПО на ноды

Установку Docker можно произвести по статье в официальных источниках:

Дополнительная настройка Docker после установки не нужна, т.к. будет произведена скриптом установки Kubernetes.
Установка bridge-utils:

Добавление ssh-ключей

Выполняем на машине, с которой будет запущен скрипт установки.
Если ключи ещё не созданы, создаём их:

Копируем ключи на удалённые машины, предварительно убедившись в наличии на них необходимого пользователя, в нашем случае core.

Установка Kubernetes

Далее мы займёмся установкой непосредственно Kubernetes. Для этого в первую очередь скачаем и распакуем последний доступный релиз с GitHub:

Настройка

Для того, чтобы использовать последний, на момент написания статьи, релиз 0.17.0 необходимо заменить:

На этом настройка заканчивается и можно переходить к установке.

Установка

Первым делом необходимо сообщить системе про наш ssh-agent и используемый ssh-ключ для этого выполняем:

В процессе установки скрипт потребует пароль sudo для каждой ноды. По окончанию установки проверит состояние кластера и выведет список нод и адреса Kubernetes api.

Посмотрим, какие ноды и сервисы присутствуют в новом кластере:

Видим список из установленных нод в состоянии Ready и два предустановленных сервиса kubernetes и kubernetes-ro — это прокси для непосредственного доступа к Kubernetes API. Как и к любому сервису Kubernetes к kubernetes и kubernetes-ro можно обратиться непосредственно по IP адресу с любой из нод.

Запуск тестового сервиса

Для запуска сервиса необходимо подготовить docker контейнер, на основе которого будет создан сервис. Дабы не усложнять, в примере будет использован общедоступный контейнер nginx. Обязательными составляющими сервиса являются Replication Controller, обеспечивающий запущенность необходимого набора контейнеров (точнее pod) и service, который определяет, на каких IP адресе и портах будет слушать сервис и правила распределения запросов между pod’ами.

Любой сервис можно запустить 2-я способами: вручную и с помощью конфиг-файла. Рассмотрим оба.

Запуск сервиса вручную

Начнём с создания Replication Controller’а:

Далее создаём service который будет использовать наш Replication Controller как бекенд.
Для http:

Для проверки запущенности можно зайти на любую из нод и выполнить в консоли:

В выводе curl увидим стандартную приветственную страницу nginx. Готово, сервис запущен и доступен.

Запуск сервиса с помощью конфигов

Для этого способа запуска необходимо создать конфиги для Replication Controller’а и service’а. Kubernetes принимает конфиги в форматах yaml и json. Мне ближе yaml поэтому будем использовать его.

Предварительно очистим наш кластер от предыдущего эксперимента:

Был создан Replication Controller с именем nginx и количеством реплик равным 6. Реплики в произвольном порядке запущены на нодах, местоположения каждой pod’ы указано в столбце HOST.

Можно заметить, что при использовании конфига за одним сервисом могут быть закреплены несколько портов.
Применяем конфиг:

Для проверки запущенности можно зайти на любую из нод и выполнить в консоли:

В выводе curl увидим стандартную приветственную страницу nginx.

Заметки на полях

В качестве заключения хочу описать пару важных моментов, о которые уже пришлось запнуться при проектировании системы. Связаны они были с работой kube-proxy, того самого модуля, который позволяет превратить разрозненный набор элементов в сервис.
PORTAL_NET. Сущность сама по себе интересная, предлагаю ознакомиться с тем, как же это реализовано.
Недолгие раскопки привели меня к осознанию простой, но эффективной модели, заглянем в вывод iptables-save:

На этом всё, спасибо за внимание
К сожалению, всю информацию, которую хочется передать, не получается уместить в одну статью.

Источник

Что такое Kubernetes?

Kubernetes — это платформа с открытым исходным кодом для управления кластером контейнерных приложений и сервисов, которую часто называют операционной системой для облака. Платформа Kubernetes была разработана инженерами Google Джо Беда (Joe Beda), Бренданом Бернсом (Brendan Burns) и Крейгом Маклакки (Craig McLuckie) в 2014 году, вскоре после этого ее исходный код стал открытым, а сама она превратилась в самостоятельную cloud native экосистему. Сегодня Kubernetes, что на древнегреческом означает «рулевой» или «пилот», управляется фондом Cloud Native Computing Foundation (CNCF), частью проекта Linux Foundation.

Kubernetes стал первым законченным проектом для CNCF и одним из самых быстрорастущих проектов с открытым исходным кодом в истории. К настоящему моменту Kubernetes насчитывает более 2300 участников и широко используется как крупными, так и мелкими компаниями, а также половиной списка Fortune 100.

Основы Kubernetes—Основные термины

Для начала познакомимся с несколькими основными терминами, связанными с Kubernetes. Более подробный список представлен на странице глоссария стандартных терминов по Kubernetes. Можно также воспользоваться Памяткой по Kubernetes, содержащей список популярных флагов и команд kubectl.

Кластер

Набор машин, по отдельности называемых узлами, которые используются для запуска контейнерных приложений, управляемых Kubernetes.

Виртуальная или физическая машина. Кластер состоит из главного узла и нескольких рабочих узлов.

Облачный контейнер

Образ, содержащий программное обеспечение и его зависимости.

Модуль

Один контейнер или набор контейнеров, работающих в кластере Kubernetes.

Развертывание

Объект, управляющий реплицированными приложениями, которые представлены модулями. Модули развертываются на узлах кластера.

Набор реплик

Обеспечивает одновременное выполнение определенного количества реплик модулей.

Сервисы

Описывает процесс получения доступа к приложениям, представленным набором модулей. Сервисы обычно описывают порты и балансировщики нагрузки и могут использоваться для управления внутренним и внешним доступом к кластеру.

Что такое KubeCon?

KubeCon — это ежегодная конференция разработчиков и пользователей Kubernetes. Со времени первой конференции KubeCon, прошедшей в 2015 году и собравшей 500 участников, KubeCon стала важным событием для сообщества разработчиков облачных технологий. В 2019 году команда KubeCon в Сан-Диего, штат Калифорния, собрала 12 000 разработчиков и инженеров по обеспечению надежности сайтов для проведения мероприятия, посвященного созданию экосистемы с открытым исходным кодом на базе платформы облачной оркестрации Kubernetes.

Что такое контейнеры Kubernetes?

Поскольку разработчики все чаще развертывают программное обеспечение самых разных вычислительных сред с разными облаками, тестовыми средами, ноутбуками, устройствами, операционными системами и платформами, проблема обеспечения надежной работы программного обеспечения приобретает первостепенное значение. Им на помощь приходят контейнеры. Они связывают приложение со всей его средой выполнения. В этом смысле контейнеры представляют собой форму виртуализации, поскольку они создают «пузырь», в котором приложение может работать, включая правильные библиотеки, зависимости и операционные системы. Но контейнеры меньше виртуальных машин, потому что они содержат только ресурсы, необходимые приложению, и не более того.

Сравнение Kubernetes и Docker

Из каких компонентов состоит Kubernetes?

Основными компонентами Kubernetes являются кластеры, узлы и плоскость управления. Кластеры содержат узлы. Каждый узел включает в себя как минимум одну рабочую машину. На узлах размещаются модули, содержащие элементы развернутого приложения. Плоскость управления управляет узлами и модулями в кластере, часто на большом количестве компьютеров, для обеспечения высокой доступности.

Плоскость управления включает следующие компоненты.

Компоненты узла включают следующее.

Какие преимущества дает Kubernetes?

С контейнерами Вы можете быть уверены, что Ваши приложения укомплектованы всем, что им нужно для работы. Но по мере добавления контейнеров, которые часто содержат микросервисы, Вы можете автоматически управлять ими и распространять их с помощью Kubernetes.

Возможности, которые Kubernetes дает компаниям:

Какие проблемы возникают при использовании Kubernetes?

Несмотря на то что платформа Kubernetes легко компонуется и может поддерживать приложения любого типа, в ней сложно разобраться и ее непросто использовать. По словам некоторых членов CNCF, Kubernetes не всегда является правильным решением для конкретной нагрузки. Вот почему экосистема Kubernetes содержит ряд связанных облачных инструментов, которые компании создали для решения конкретных проблем с нагрузками.

Kubernetes развертывает контейнеры, а не исходный код и не создает приложения. Для ведения журналов, промежуточного программного обеспечения, мониторинга, настройки, CI/CD и многих других производственных операций требуются дополнительные инструменты. Тем не менее платформа Kubernetes является расширяемой и доказала свою эффективность в самых разных сценариях использования — от реактивных самолетов до машинного обучения. Фактически поставщики облачных решений, включая Oracle, Google, Amazon Web Services и другие, используют собственную расширяемость Kubernetes для создания управляемых Kubernetes, которые представляют собой сервисы для снижения сложности и повышения продуктивности разработчиков.

Что такое управляемый Kubernetes?

Oracle Cloud Infrastructure Container Engine for Kubernetes — это удобный для разработчиков управляемый сервис, который можно использовать для развертывания контейнерных приложений в облаке. Используйте Container Engine for Kubernetes, если Ваша команда разработчиков хочет надежно создавать, развертывать cloud native приложения и управлять ими. Вы указываете вычислительные ресурсы, которые требуются Вашим приложениям, а Oracle Container Engine for Kubernetes предоставляет их в существующей арендованной облачной инфраструктуре Oracle.

Несмотря на то что Вам необязательно использовать управляемый сервис Kubernetes, решение Oracle Cloud Infrastructure Container Engine for Kubernetes — это простой способ запустить высокодоступные кластеры с контролем, безопасностью и предсказуемой производительностью Oracle Cloud Infrastructure. Container Engine for Kubernetes поддерживает как системы без виртуализации, так и виртуальные машины как узлы, и сертифицирован соответствующим образом организацией CNCF. Вы также получаете все обновления Kubernetes, и совместимость с экосистемой CNCF обеспечивается без каких-либо дополнительных действий с Вашей стороны.

Cloud Native и Kubernetes меняют подход AgroScout к поддержке разработчиков.

Источник