Прим. перев.: как многим хорошо известно, Kubernetes — это всего лишь пять бинарников. Об их назначении и рассказывает в этой статье Vedashree Patil, консультант из Deloitte Digital. Когда ей потребовалось изучить Kubernetes, она столкнулась с большим количеством новой информации, осознать которую за короткое время было непросто. Так она пришла к идее уменьшить порог вхождения в K8s другим специалистам, создав цикл публикаций «Kubernetes 101». Все статьи сопровождаются простыми и наглядными комиксами. Представляем вниманию перевод материала под названием «Внутри кластера» из этого цикла.
Из известного набора стикеров для Telegram
Как выглядит кластер Kubernetes? Как работают узлы? Из этой статьи вы узнаете обо всех основных компонентах системы Kubernetes.
Мастер-узел (слева) и рабочий узел (справа)
Если вам интересно, что означают все эти причудливые термины, они будут подробно рассмотрены далее. Сначала давайте разберёмся с мастер-узлом…
Команда представителей Control Plane
Давайте подробнее остановимся на каждом из них.
[IMG alt="А этот парень — API-сервер… И у него Kubernetes API… Знаете, что это значит?.. Он тот самый супергерой, который выполнит все ваши запросы…
— Эй, API-сервер, покажи-ка мне логи недавно задеплоенного веб-сервиса! — Логи уже на подходе."]https://habrastorage.org/r/w1560/ge...f/851775e5f39413daba3ec2d989ca3df8.png[/IMG]А этот парень — API-сервер… И у него Kubernetes API… Знаете, что это значит?.. Он тот самый супергерой, который выполнит все ваши запросы… — Эй, API-сервер, покажи-ка мне логи недавно задеплоенного веб-сервиса! — Логи уже на подходе.
Для любых манипуляций с кластером приходится обращаться к API-серверу с помощью Kubernetes API. Используете kubectl, REST или любую из клиентских библиотек Kubernetes? Все они завязаны на API Kubernetes'а и взаимодействуют с API-сервером.
[IMG alt="Но когда становится реально жарко…
— Эй, мне нужно то. — Эй, удали это! — Эй, API-сервер, ты там жив? — Покажи логи! — А как же моя работа? — Создай-ка вон то!
Этот парень с лёгкостью масштабируется… горизонтально. — Вперёд, ребятки! Ещё полно работы."]https://habrastorage.org/r/w1560/ge.../260a374ce39ea288cbe4a9e0bbb598f7.png[/IMG]Но когда становится реально жарко… — Эй, мне нужно то. — Эй, удали это! — Эй, API-сервер, ты там жив? — Покажи логи! — А как же моя работа? — Создай-ка вон то! Этот парень с лёгкостью масштабируется… горизонтально. — Вперёд, ребятки! Ещё полно работы.
Примечательная особенность API-сервера состоит в том, что он умеет масштабироваться по горизонтали. Другими словами, при резком увеличении количества поступающих запросов API-сервер может создавать «клоны» или реплики самого себя, чтобы справиться с нагрузкой.
Давайте разбираться:
[IMG alt="А этот занятой парень — планировщик. Именно он назначает узлы новым Pod'ам.
— То есть ты утверждаешь, что тебе нужны все эти ресурсы? — Ага!"]https://habrastorage.org/r/w1560/ge...5/ee4ea1c75a46e0c31aeb4a0709818452.png[/IMG]А этот занятой парень — планировщик. Именно он назначает узлы новым Pod'ам. — То есть ты утверждаешь, что тебе нужны все эти ресурсы? — Ага!
Новый Pod остается в статусе Pending до тех пор, пока ему не будет выделен узел для работы (рекомендую обратиться к соответствующей статье о Pod'ах). Именно за это отвечает планировщик:
[IMG alt="Узел 1 загружен по полной. Узел 2 — то, что надо. Узел 3 сидит без работы.
— С первым узлом всё понятно. Итак, остались 2 и 3… У 2-го ещё есть чуток ресурсов, а 3-й вообще свободен. Думаю, ему надо чем-то заняться. Ок, тогда 3-й!"]https://habrastorage.org/r/w1560/ge...9bac58eeff7bbfa5712df1a080f1f0f.png[/IMG]Узел 1 загружен по полной. Узел 2 — то, что надо. Узел 3 сидит без работы. — С первым узлом всё понятно. Итак, остались 2 и 3… У 2-го ещё есть чуток ресурсов, а 3-й вообще свободен. Думаю, ему надо чем-то заняться. Ок, тогда 3-й!
Каждому Pod’у требуются определенные ресурсы: память, CPU, железо… в общем, стандартный набор. Планировщик должен решить, какой узел соответствует требованиям Pod’а. Поэтому планировщик выполняет два действия:
Я люблю называть его компонентом, который «всё исправляет». Почему? Потому что работа у него такая — приводить в норму. Поясню. Он наблюдает за кластером — словно хищная птица за добычей, без устали и покоя. Если что-то идёт не так, контроллер предпринимает соответствующие действия для исправления ситуации.
Иными словами, у кластера есть состояние, называемое желаемым (англ. desired state). Именно в таком состоянии должен находиться кластер. Контроллер считает его единственно верным. С другой стороны, в каждый момент времени кластер находится в состоянии, называемом текущим (current state). Контроллеры будут делать всё, чтобы привести текущее состояние к желаемому.
Как работает контроллер: текущее состояние (бумага) → требуемое действие (вырезать из бумаги) → желаемое состояние (человечек из бумаги).
Или другой пример: вам требуется двадцать секунд, чтобы пробежать стометровку. Чтобы уменьшить это время до пятнадцати, придется каждый день тренироваться, чтобы достичь цели. Это и есть переход из текущего состояния в желаемое.
На самом деле контроллер — это просто бесконечный цикл, который постоянно следит за неким ресурсом в кластере (например, за Pod’ом). Если что-то идет не так, он исправляет возникшую проблему.
Теперь вернёмся к нашему менеджеру.
Менеджер контроллеров (Controller Manager) — это набор различных контроллеров. Например, может быть один контроллер, который наблюдает за узлами, другой — за задачами (Jobs), и так далее.
Но такой менеджер — это инструмент «всё в одном». По сути, он отслеживает сразу все ресурсы. За это отвечает ОДИН процесс, но благодаря многозадачности складывается впечатление, что одновременно работают несколько контроллеров. Вот некоторые из самых популярных:
[IMG alt="Контроллер узлов: «О нет! Похоже, второй узел не работает. Нужно с этим что-то делать».
Контроллер репликации: «Pod'у XX нужны три реплики, а там только две. Надо создать ещё одну».
Контроллер учётных записей и токенов: «Хм-м, новое пространство имён. Нужны новые токены доступа»."]https://habrastorage.org/r/w1560/ge...36e6ba9b430de0d018e4a0692.png[/IMG]Контроллер узлов: «О нет! Похоже, второй узел не работает. Нужно с этим что-то делать». Контроллер репликации: «Pod'у XX нужны три реплики, а там только две. Надо создать ещё одну». Контроллер учётных записей и токенов: «Хм-м, новое пространство имён. Нужны новые токены доступа».
То же самое и с Kubernetes. Всё, что происходит в кластере, должно быть записано и сохранено. Вообще всё! И тут на сцену выходит etcd. Эта база данных типа ключ-значение выступает резервным хранилищем для Kubernetes.
Переходим к рабочим узлам (worker nodes).
Команда представителей рабочих узлов
Первая — взаимодействие с мастер-узлом. Обычно мастер-узел отправляет задачу в форме манифеста или спецификации (Podspec). Манифест определяет, какие работы необходимо провести и какие Pod’ы нужно создать.
Обычный день из жизни kubelet: «Та-а-ак, новый манифест от мастера. Посмотрим… Два Pod'а с образом xxx».
Вторая — взаимодействие с исполняемой средой контейнера (container runtime) на узле. Исполняемая среда скачивает нужные образы, после чего вступает в действие kubelet, мониторя Pod’ы, созданные с использованием этих образов.
— Скачай-ка образ xxx. Нам нужны новые Pod'ы. — Ок!
Третья — проверки (probes) состояния Pod’ов. Кто отвечает за них? Конечно же, kubelet! Потому что следить за здоровьем Pod’а — его обязанность!
— Просто звоню узнать, как ты там. Обычная проверка, как всегда… Всё в порядке? — Лучше не бывает!
kube-proxy следит за соблюдением сетевых правил. Появился сетевой пакет с IP: 123.456.789.100. — Стой! Твоего IP-адреса нет в списке. Вход запрещён!
habr.com
Как выглядит кластер Kubernetes? Как работают узлы? Из этой статьи вы узнаете обо всех основных компонентах системы Kubernetes.
Предисловие
Мы уже говорили о концепции master-slave в Kubernetes. Один узел контролирует все остальные. В Kubernetes все устроено именно таким образом. Но мы ещё не рассматривали, КАК работает связка master-slave. Что именно делает мастер-узел (master node)? Итак, начнём...Общая картина
Примерно так выглядит типичный мастер-узел:
Если вам интересно, что означают все эти причудливые термины, они будут подробно рассмотрены далее. Сначала давайте разберёмся с мастер-узлом…
«Команда» Control Plane
На мастер-узле, также известном как Control Plane (иногда его переводят как «управляющий слой» — прим. перев.), выполняется большинство важных задач по управлению и администрированию кластера. Он включает в себя четыре основных компонента:- API server (API-сервер);
- scheduler (планировщик);
- controller manager (менеджер контроллеров);
- etcd.
Давайте подробнее остановимся на каждом из них.
API server
Самый первый, и, пожалуй, самый важный — API-сервер. Это «лицо» Kubernetes. Чтобы взаимодействовать с кластером Kubernetes, вам наверняка придется познакомиться с API-сервером:[IMG alt="А этот парень — API-сервер… И у него Kubernetes API… Знаете, что это значит?.. Он тот самый супергерой, который выполнит все ваши запросы…
— Эй, API-сервер, покажи-ка мне логи недавно задеплоенного веб-сервиса! — Логи уже на подходе."]https://habrastorage.org/r/w1560/ge...f/851775e5f39413daba3ec2d989ca3df8.png[/IMG]А этот парень — API-сервер… И у него Kubernetes API… Знаете, что это значит?.. Он тот самый супергерой, который выполнит все ваши запросы… — Эй, API-сервер, покажи-ка мне логи недавно задеплоенного веб-сервиса! — Логи уже на подходе.
Для любых манипуляций с кластером приходится обращаться к API-серверу с помощью Kubernetes API. Используете kubectl, REST или любую из клиентских библиотек Kubernetes? Все они завязаны на API Kubernetes'а и взаимодействуют с API-сервером.
[IMG alt="Но когда становится реально жарко…
— Эй, мне нужно то. — Эй, удали это! — Эй, API-сервер, ты там жив? — Покажи логи! — А как же моя работа? — Создай-ка вон то!
Этот парень с лёгкостью масштабируется… горизонтально. — Вперёд, ребятки! Ещё полно работы."]https://habrastorage.org/r/w1560/ge.../260a374ce39ea288cbe4a9e0bbb598f7.png[/IMG]Но когда становится реально жарко… — Эй, мне нужно то. — Эй, удали это! — Эй, API-сервер, ты там жив? — Покажи логи! — А как же моя работа? — Создай-ка вон то! Этот парень с лёгкостью масштабируется… горизонтально. — Вперёд, ребятки! Ещё полно работы.
Примечательная особенность API-сервера состоит в том, что он умеет масштабироваться по горизонтали. Другими словами, при резком увеличении количества поступающих запросов API-сервер может создавать «клоны» или реплики самого себя, чтобы справиться с нагрузкой.
Scheduler
Следующий компонент — планировщик. Как вы думаете, что он делает? Правильно, планирует.Давайте разбираться:
[IMG alt="А этот занятой парень — планировщик. Именно он назначает узлы новым Pod'ам.
— То есть ты утверждаешь, что тебе нужны все эти ресурсы? — Ага!"]https://habrastorage.org/r/w1560/ge...5/ee4ea1c75a46e0c31aeb4a0709818452.png[/IMG]А этот занятой парень — планировщик. Именно он назначает узлы новым Pod'ам. — То есть ты утверждаешь, что тебе нужны все эти ресурсы? — Ага!
Новый Pod остается в статусе Pending до тех пор, пока ему не будет выделен узел для работы (рекомендую обратиться к соответствующей статье о Pod'ах). Именно за это отвечает планировщик:
[IMG alt="Узел 1 загружен по полной. Узел 2 — то, что надо. Узел 3 сидит без работы.
— С первым узлом всё понятно. Итак, остались 2 и 3… У 2-го ещё есть чуток ресурсов, а 3-й вообще свободен. Думаю, ему надо чем-то заняться. Ок, тогда 3-й!"]https://habrastorage.org/r/w1560/ge...9bac58eeff7bbfa5712df1a080f1f0f.png[/IMG]Узел 1 загружен по полной. Узел 2 — то, что надо. Узел 3 сидит без работы. — С первым узлом всё понятно. Итак, остались 2 и 3… У 2-го ещё есть чуток ресурсов, а 3-й вообще свободен. Думаю, ему надо чем-то заняться. Ок, тогда 3-й!
Каждому Pod’у требуются определенные ресурсы: память, CPU, железо… в общем, стандартный набор. Планировщик должен решить, какой узел соответствует требованиям Pod’а. Поэтому планировщик выполняет два действия:
- Подбирает узлы-кандидаты для Pod’а;
- Останавливает свой выбор на одном из них.
Controller manager
Прежде всего стоит узнать, что такое Контроллер.Я люблю называть его компонентом, который «всё исправляет». Почему? Потому что работа у него такая — приводить в норму. Поясню. Он наблюдает за кластером — словно хищная птица за добычей, без устали и покоя. Если что-то идёт не так, контроллер предпринимает соответствующие действия для исправления ситуации.
Иными словами, у кластера есть состояние, называемое желаемым (англ. desired state). Именно в таком состоянии должен находиться кластер. Контроллер считает его единственно верным. С другой стороны, в каждый момент времени кластер находится в состоянии, называемом текущим (current state). Контроллеры будут делать всё, чтобы привести текущее состояние к желаемому.
Или другой пример: вам требуется двадцать секунд, чтобы пробежать стометровку. Чтобы уменьшить это время до пятнадцати, придется каждый день тренироваться, чтобы достичь цели. Это и есть переход из текущего состояния в желаемое.
На самом деле контроллер — это просто бесконечный цикл, который постоянно следит за неким ресурсом в кластере (например, за Pod’ом). Если что-то идет не так, он исправляет возникшую проблему.
Теперь вернёмся к нашему менеджеру.
Менеджер контроллеров (Controller Manager) — это набор различных контроллеров. Например, может быть один контроллер, который наблюдает за узлами, другой — за задачами (Jobs), и так далее.
Но такой менеджер — это инструмент «всё в одном». По сути, он отслеживает сразу все ресурсы. За это отвечает ОДИН процесс, но благодаря многозадачности складывается впечатление, что одновременно работают несколько контроллеров. Вот некоторые из самых популярных:
[IMG alt="Контроллер узлов: «О нет! Похоже, второй узел не работает. Нужно с этим что-то делать».
Контроллер репликации: «Pod'у XX нужны три реплики, а там только две. Надо создать ещё одну».
Контроллер учётных записей и токенов: «Хм-м, новое пространство имён. Нужны новые токены доступа»."]https://habrastorage.org/r/w1560/ge...36e6ba9b430de0d018e4a0692.png[/IMG]Контроллер узлов: «О нет! Похоже, второй узел не работает. Нужно с этим что-то делать». Контроллер репликации: «Pod'у XX нужны три реплики, а там только две. Надо создать ещё одну». Контроллер учётных записей и токенов: «Хм-м, новое пространство имён. Нужны новые токены доступа».
Etcd
Etcd — это личный журнал Kubernetes. Скажите, зачем люди ведут личные дневники и журналы? Все просто: чтобы сохранить в памяти мимолетные моменты (увы, мозг не способен хранить все события каждого дня нашей жизни).То же самое и с Kubernetes. Всё, что происходит в кластере, должно быть записано и сохранено. Вообще всё! И тут на сцену выходит etcd. Эта база данных типа ключ-значение выступает резервным хранилищем для Kubernetes.
Переходим к рабочим узлам (worker nodes).
«Команда» рабочих узлов
Мы уже рассмотрели, что такое мастер-узел. Но настоящая работа происходит именно на рабочих узлах. А всё потому, что на каждом узле есть компоненты, отвечающие за его бесперебойное функционирование. Они включают в себя:- kubelet;
- kube-proxy;
- container runtime.
kubelet
Этот парень, пожалуй, самый важный. kubelet — это агент, который следит за тем, чтобы на узле всё работало должным образом. Подобная работа подразумевает ряд задач.Первая — взаимодействие с мастер-узлом. Обычно мастер-узел отправляет задачу в форме манифеста или спецификации (Podspec). Манифест определяет, какие работы необходимо провести и какие Pod’ы нужно создать.
Вторая — взаимодействие с исполняемой средой контейнера (container runtime) на узле. Исполняемая среда скачивает нужные образы, после чего вступает в действие kubelet, мониторя Pod’ы, созданные с использованием этих образов.
Третья — проверки (probes) состояния Pod’ов. Кто отвечает за них? Конечно же, kubelet! Потому что следить за здоровьем Pod’а — его обязанность!
kube-proxy
Следующий неотъемлемый элемент — работа с сетью, и kube-proxy готов позаботиться об этом. Он работает как балансировщик нагрузки, распределяя трафик между Pod’ами, а также следит за соблюдением сетевых правил. Можно сказать, что kube-proxy полностью отвечает за коммуникации внутри кластера.
Заключение
В статье рассмотрены основные компоненты кластера Kubernetes. Но процесс познания далек от завершения — ещё необходимо освоить множество важных понятий. Например, мы лишь упомянули работу с сетью, ничего не сказали о рабочих нагрузках и конфигурациях в Kubernetes. Не переживайте: обо всём этом вы сможете узнать из будущих статей (в оригинале они публикуются здесь — прим. перев.).Внутреннее устройство Kubernetes-кластера простым языком
Прим. перев. : как многим хорошо известно, Kubernetes — это всего лишь пять бинарников. Об их назначении и рассказывает в этой статье Vedashree Patil, консультант из Deloitte Digital. Когда ей...
habr.com