Прим. перев.: как многим хорошо известно, Kubernetes — это всего лишь пять бинарников. Об их назначении и рассказывает в этой статье Vedashree Patil, консультант из Deloitte Digital. Когда ей потребовалось изучить Kubernetes, она столкнулась с большим количеством новой информации, осознать которую за короткое время было непросто. Так она пришла к идее уменьшить порог вхождения в K8s другим специалистам, создав цикл публикаций «Kubernetes 101». Все статьи сопровождаются простыми и наглядными комиксами. Представляем вниманию перевод материала под названием «Внутри кластера» из этого цикла.
![Из известного набора стикеров для Telegram Из известного набора стикеров для Telegram](https://habrastorage.org/getpro/habr/upload_files/860/a1a/7d6/860a1a7d6a0f7e81f43df50648e00e24.png)
Как выглядит кластер Kubernetes? Как работают узлы? Из этой статьи вы узнаете обо всех основных компонентах системы Kubernetes.
Предисловие
Мы уже говорили о концепции master-slave в Kubernetes. Один узел контролирует все остальные. В Kubernetes все устроено именно таким образом. Но мы ещё не рассматривали, КАК работает связка master-slave. Что именно делает мастер-узел (master node)? Итак, начнём...
Общая картина
Примерно так выглядит типичный мастер-узел:
![Мастер-узел (слева) и рабочий узел (справа) Мастер-узел (слева) и рабочий узел (справа)](https://habrastorage.org/getpro/habr/upload_files/80b/a02/d00/80ba02d00b4694e9a359098fb33873ad.png)
Если вам интересно, что означают все эти причудливые термины, они будут подробно рассмотрены далее. Сначала давайте разберёмся с мастер-узлом…
«Команда» Control Plane
На мастер-узле, также известном как Control Plane (иногда его переводят как «управляющий слой» — прим. перев.), выполняется большинство важных задач по управлению и администрированию кластера. Он включает в себя четыре основных компонента:
API server (API-сервер);
scheduler (планировщик);
controller manager (менеджер контроллеров);
etcd.
![Команда представителей Control Plane Команда представителей Control Plane](https://habrastorage.org/getpro/habr/upload_files/413/e57/1d9/413e571d97fd372c47a55576e293942b.png)
Давайте подробнее остановимся на каждом из них.
API server
Самый первый, и, пожалуй, самый важный — API-сервер. Это «лицо» Kubernetes. Чтобы взаимодействовать с кластером Kubernetes, вам наверняка придется познакомиться с API-сервером:
![А этот парень — API-сервер… И у него Kubernetes API… Знаете, что это значит?.. Он тот самый супергерой, который выполнит все ваши запросы…
— Эй, API-сервер, покажи-ка мне логи недавно задеплоенного веб-сервиса! — Логи уже на подходе. А этот парень — API-сервер… И у него Kubernetes API… Знаете, что это значит?.. Он тот самый супергерой, который выполнит все ваши запросы…
— Эй, API-сервер, покажи-ка мне логи недавно задеплоенного веб-сервиса! — Логи уже на подходе.](https://habrastorage.org/getpro/habr/upload_files/851/775/e5f/851775e5f39413daba3ec2d989ca3df8.png)
Для любых манипуляций с кластером приходится обращаться к API-серверу с помощью Kubernetes API. Используете kubectl, REST или любую из клиентских библиотек Kubernetes? Все они завязаны на API Kubernetes'а и взаимодействуют с API-сервером.
![Но когда становится реально жарко…
— Эй, мне нужно то. — Эй, удали это! — Эй, API-сервер, ты там жив? — Покажи логи! — А как же моя работа? — Создай-ка вон то!
Этот парень с лёгкостью масштабируется… горизонтально. — Вперёд, ребятки! Ещё полно работы. Но когда становится реально жарко…
— Эй, мне нужно то. — Эй, удали это! — Эй, API-сервер, ты там жив? — Покажи логи! — А как же моя работа? — Создай-ка вон то!
Этот парень с лёгкостью масштабируется… горизонтально. — Вперёд, ребятки! Ещё полно работы.](https://habrastorage.org/getpro/habr/upload_files/260/a37/4ce/260a374ce39ea288cbe4a9e0bbb598f7.png)
Примечательная особенность API-сервера состоит в том, что он умеет масштабироваться по горизонтали. Другими словами, при резком увеличении количества поступающих запросов API-сервер может создавать «клоны» или реплики самого себя, чтобы справиться с нагрузкой.
Scheduler
Следующий компонент — планировщик. Как вы думаете, что он делает? Правильно, планирует.
Давайте разбираться:
![А этот занятой парень — планировщик. Именно он назначает узлы новым Pod'ам.
— То есть ты утверждаешь, что тебе нужны все эти ресурсы? — Ага! А этот занятой парень — планировщик. Именно он назначает узлы новым Pod'ам.
— То есть ты утверждаешь, что тебе нужны все эти ресурсы? — Ага!](https://habrastorage.org/getpro/habr/upload_files/ee4/ea1/c75/ee4ea1c75a46e0c31aeb4a0709818452.png)
Новый Pod остается в статусе Pending
до тех пор, пока ему не будет выделен узел для работы (рекомендую обратиться к соответствующей статье о Pod'ах). Именно за это отвечает планировщик:
![Узел 1 — загружен по полной. Узел 2 — то, что надо. Узел 3 — сидит без работы.
— С первым узлом всё понятно. Итак, остались 2 и 3… У 2-го ещё есть чуток ресурсов, а 3-й вообще свободен. Думаю, ему надо чем-то заняться. Ок, тогда 3-й! Узел 1 — загружен по полной. Узел 2 — то, что надо. Узел 3 — сидит без работы.
— С первым узлом всё понятно. Итак, остались 2 и 3… У 2-го ещё есть чуток ресурсов, а 3-й вообще свободен. Думаю, ему надо чем-то заняться. Ок, тогда 3-й!](https://habrastorage.org/getpro/habr/upload_files/c9b/ac5/8ee/c9bac58eeff7bbfa5712df1a080f1f0f.png)
Каждому Pod’у требуются определенные ресурсы: память, CPU, железо… в общем, стандартный набор. Планировщик должен решить, какой узел соответствует требованиям Pod’а. Поэтому планировщик выполняет два действия:
Подбирает узлы-кандидаты для Pod’а;
Останавливает свой выбор на одном из них.
Controller manager
Прежде всего стоит узнать, что такое Контроллер.
Я люблю называть его компонентом, который «всё исправляет». Почему? Потому что работа у него такая — приводить в норму. Поясню. Он наблюдает за кластером — словно хищная птица за добычей, без устали и покоя. Если что-то идёт не так, контроллер предпринимает соответствующие действия для исправления ситуации.
Иными словами, у кластера есть состояние, называемое желаемым (англ. desired state). Именно в таком состоянии должен находиться кластер. Контроллер считает его единственно верным. С другой стороны, в каждый момент времени кластер находится в состоянии, называемом текущим (current state). Контроллеры будут делать всё, чтобы привести текущее состояние к желаемому.
![Как работает контроллер: текущее состояние (бумага) → требуемое действие (вырезать из бумаги) → желаемое состояние (человечек из бумаги). Как работает контроллер: текущее состояние (бумага) → требуемое действие (вырезать из бумаги) → желаемое состояние (человечек из бумаги).](https://habrastorage.org/getpro/habr/upload_files/4ff/1ee/d80/4ff1eed80a70b8e4c4e223919b3777d1.png)
Или другой пример: вам требуется двадцать секунд, чтобы пробежать стометровку. Чтобы уменьшить это время до пятнадцати, придется каждый день тренироваться, чтобы достичь цели. Это и есть переход из текущего состояния в желаемое.
На самом деле контроллер — это просто бесконечный цикл, который постоянно следит за неким ресурсом в кластере (например, за Pod’ом). Если что-то идет не так, он исправляет возникшую проблему.
Теперь вернёмся к нашему менеджеру.
Менеджер контроллеров (Controller Manager) — это набор различных контроллеров. Например, может быть один контроллер, который наблюдает за узлами, другой — за задачами (Jobs), и так далее.
Но такой менеджер — это инструмент «всё в одном». По сути, он отслеживает сразу все ресурсы. За это отвечает ОДИН процесс, но благодаря многозадачности складывается впечатление, что одновременно работают несколько контроллеров. Вот некоторые из самых популярных:
![Контроллер узлов: «О нет! Похоже, второй узел не работает. Нужно с этим что-то делать».
Контроллер репликации: «Pod'у XX нужны три реплики, а там только две. Надо создать ещё одну».
Контроллер учётных записей и токенов: «Хм-м, новое пространство имён. Нужны новые токены доступа». Контроллер узлов: «О нет! Похоже, второй узел не работает. Нужно с этим что-то делать».
Контроллер репликации: «Pod'у XX нужны три реплики, а там только две. Надо создать ещё одну».
Контроллер учётных записей и токенов: «Хм-м, новое пространство имён. Нужны новые токены доступа».](https://habrastorage.org/getpro/habr/upload_files/4d7/45f/836/4d745f836e6ba9b430de0d018e4a0692.png)
Etcd
Etcd — это личный журнал Kubernetes. Скажите, зачем люди ведут личные дневники и журналы? Все просто: чтобы сохранить в памяти мимолетные моменты (увы, мозг не способен хранить все события каждого дня нашей жизни).
То же самое и с Kubernetes. Всё, что происходит в кластере, должно быть записано и сохранено. Вообще всё! И тут на сцену выходит etcd. Эта база данных типа ключ-значение выступает резервным хранилищем для Kubernetes.
Переходим к рабочим узлам (worker nodes).
«Команда» рабочих узлов
Мы уже рассмотрели, что такое мастер-узел. Но настоящая работа происходит именно на рабочих узлах. А всё потому, что на каждом узле есть компоненты, отвечающие за его бесперебойное функционирование. Они включают в себя:
kubelet;
kube-proxy;
container runtime.
![Команда представителей рабочих узлов Команда представителей рабочих узлов](https://habrastorage.org/getpro/habr/upload_files/1d3/1f5/9bb/1d31f59bbcd2af2bee3a3a99f0afe1c6.png)
kubelet
Этот парень, пожалуй, самый важный. kubelet — это агент, который следит за тем, чтобы на узле всё работало должным образом. Подобная работа подразумевает ряд задач.
Первая — взаимодействие с мастер-узлом. Обычно мастер-узел отправляет задачу в форме манифеста или спецификации (Podspec). Манифест определяет, какие работы необходимо провести и какие Pod’ы нужно создать.
![Обычный день из жизни kubelet: «Та-а-ак, новый манифест от мастера. Посмотрим… Два Pod'а с образом xxx». Обычный день из жизни kubelet: «Та-а-ак, новый манифест от мастера. Посмотрим… Два Pod'а с образом xxx».](https://habrastorage.org/getpro/habr/upload_files/a59/221/f9f/a59221f9f4895a0aa00f7d4ef12003db.png)
Вторая — взаимодействие с исполняемой средой контейнера (container runtime) на узле. Исполняемая среда скачивает нужные образы, после чего вступает в действие kubelet, мониторя Pod’ы, созданные с использованием этих образов.
![— Скачай-ка образ xxx. Нам нужны новые Pod'ы. — Ок! — Скачай-ка образ xxx. Нам нужны новые Pod'ы. — Ок!](https://habrastorage.org/getpro/habr/upload_files/4f8/a3e/dcb/4f8a3edcb7079109dc0bdd187f416f6f.png)
Третья — проверки (probes) состояния Pod’ов. Кто отвечает за них? Конечно же, kubelet! Потому что следить за здоровьем Pod’а — его обязанность!
![— Просто звоню узнать, как ты там. Обычная проверка, как всегда… Всё в порядке? — Лучше не бывает! — Просто звоню узнать, как ты там. Обычная проверка, как всегда… Всё в порядке? — Лучше не бывает!](https://habrastorage.org/getpro/habr/upload_files/929/eb2/819/929eb2819b2fb3a217ccdff9714dccb8.png)
kube-proxy
Следующий неотъемлемый элемент — работа с сетью, и kube-proxy готов позаботиться об этом. Он работает как балансировщик нагрузки, распределяя трафик между Pod’ами, а также следит за соблюдением сетевых правил. Можно сказать, что kube-proxy полностью отвечает за коммуникации внутри кластера.
![kube-proxy следит за соблюдением сетевых правил. Появился сетевой пакет с IP: 123.456.789.100. — Стой! Твоего IP-адреса нет в списке. Вход запрещён! kube-proxy следит за соблюдением сетевых правил. Появился сетевой пакет с IP: 123.456.789.100. — Стой! Твоего IP-адреса нет в списке. Вход запрещён!](https://habrastorage.org/getpro/habr/upload_files/b01/51b/c19/b0151bc199b1449ad663171a21b9ac6d.png)
Заключение
В статье рассмотрены основные компоненты кластера Kubernetes. Но процесс познания далек от завершения — ещё необходимо освоить множество важных понятий. Например, мы лишь упомянули работу с сетью, ничего не сказали о рабочих нагрузках и конфигурациях в Kubernetes. Не переживайте: обо всём этом вы сможете узнать из будущих статей (в оригинале они публикуются здесь — прим. перев.).
Полезные ссылки
«Cluster Architecture» в документации Kubernetes;
«Introduction to Kubernetes architecture» с сайта Red Hat.
P.S. от переводчика
Читайте также в нашем блоге: