Не так давно я побывала на конференции Kubecon 2023 в Чикаго. Готовясь к конференции, я почитала статьи в блогах, а на самой конференции посетила несколько семинаров для начинающих (в жанре «101»). Но всё равно не могла сказать, что уверенно понимаю эту технологию. Хуже всего прошёл последний день конференции. Я решила добираться в отель на такси и вызвала Uber. И водитель спрашивает: «А о чём была конференция»? Я ему отвечаю: «О Kubernetes». Попыталась объяснить, но почти сразу поняла, что двух слов на эту тему связать не смогу.

Только представьте себе: уезжать с трёхдневной конференции, но быть не в силах рассказать таксисту о той технологии, которая на ней обсуждалась. Фейспалм. Поэтому теперь попытаюсь реабилитироваться и пофантазировать, как следовало бы рассказать о Kubernetes таксисту Uber.



❯ Начало беседы


Я: представьте, что вы шеф-повар, руководите кухней популярного ресторана. У вас в подчинении целая бригада поваров, и каждый отвечает за приготовление тех или иных блюд. Есть группа, занимающаяся закусками, есть те, кто специализируется на горячих блюдах, есть группа по десертам. Ваша задача – скоординировать работу этих поваров, а также обеспечить, что клиенту не придётся чрезмерно долго ждать заказанных блюд. Представили?


Водитель: понятно.

Я: В данном сценарии шеф-повар – это Kubernetes. Точно как реальный шеф-повар обязан управлять всей командой поваров на кухне, Kubernetes координирует работу всех компонентов, обеспечивающих корректную работу вашего софта. Официально Kubernetes определяется как «инструмент оркестрации контейнеров», но понятие «контейнер» в данном случае весьма абстрактное, поэтому давайте в нашем контексте вместо «контейнера» говорить «повар». В таком случае Kubernetes – это «инструмент оркестрации поваров». Таким образом, когда услышите о Kubernetes – сразу представляйте себе такую кухню.


Водитель: Ага, пока всё логично. Но в чём суть этих контейнеров? Не могу же я всё время представлять их в виде поваров.

Я: Да, в точку. Теперь, когда вы уже представляете себе кухню под управлением Kubernetes, давайте обсудим, как различные роли кухонного персонала соотносятся с концепциями Kubernetes. Пойдём от меньшего к большему.

Контейнер


Мельчайший элемент этой картинки – контейнер. В принципе, это может быть любой полноценный софт. Например, это может быть веб-сервер Node.js, на котором развёрнуто веб-приложение, либо в контейнере может лежать база данных MongoDB, в которой хранятся данные (этот тезис ориентирован в основном на программистов, читающих данную статью, таксисту я бы так объяснять не стала ?). Допустим, на кухне вы готовите суп на первое и салат в качестве закуски. Здесь суп – это отдельный контейнер. Салат – тоже отдельный контейнер.

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


Под


На кухне под подобен подносу, на котором вам подают суп и салат. В Kubernetes под – это сущность, в которой могут содержаться 1 или более контейнеров. Так делается потому, что контейнеры в пределах пода могут обмениваться информацией друг с другом.

Для программистов: представьте, что в рамках одного пода у меня находится контейнер с веб-сервером и контейнер с базой данных. Они могут обмениваться информацией через r localhost.

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


Ведущий узел


Это шеф-повар, управляющий всей кухней и присматривающий за ней. Вспомните концепцию «оркестрации контейнеров» или «оркестрации поваров», о которой мы говорили выше. Если попытаться показать на реальных примерах, как устроена оркестрация, то есть, работа этого ведущего узла, то вот что у нас получится:

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

Автоматизированное развёртывание – это определение зависимостей вашего приложения и инструкций для среды выполнения в файле YAML. Далее приложение можно развернуть на основе конфигурации, описанной в этом файле. На кухне такой YAML-файл аналогичен рецепту, с которым повар сверяется при приготовлении блюда. Тем самым обеспечивается единообразие блюд и эффективность готовки как таковой.

Балансировка нагрузки – это распределение сетевого трафика между разными подами. На кухне балансировка нагрузки подобна тому, как если бы мы поручали разные задачи разным поварам, которые сегодня заняты на смене. Может быть, Боб занимается десертами, но его завалили заказами, только успевай зачерпывать мороженое. В таком случае шеф-повар клонирует Боба, у него получается Боб 2.0. Далее Боб 2.0 перехватывает у Боба 1.0 часть заказов на приготовление мороженого, чтобы немного разгрузить Боба 1.0.


Здесь важно отметить и такой момент: у каждого рабочего узла есть так называемый «kubelet». В кухонном сценарии «kubelet» аналогичен повару, работающему за отдельным столом. У этого повара есть набор задач, например, убедиться, что блюда для каждого заказа корректно собираются на подносе. Другие задачи – подбирать ингредиенты для блюда и выбрасывать очистки. Аналогично, «kubelet» делает, например, такие вещи: обеспечивает бесперебойную работу контейнеров внутри подов, помогает инициализировать поды (например, заботится о том, чтобы все необходимые зависимости были установлены), участвует в сборке мусора и делает многое другое.

Добавлю контекста для технарей: Kubelet – это свободно распространяемый исполняемый двоичный файл на языке Go (например, файл с инструкциями, написанными на машинном коде; ЦП может непосредственно выполнять эти инструкции).


Здесь давайте ненадолго остановимся. Если вы поняли всё, что я уже успела рассказать, то вы усвоили основы архитектуры Kubernetes! Если вы не хотите вечно залипать на этом комиксе про кухню, посмотрите следующую схему – там употребляется только терминология, специфичная для Kubernetes.


Водитель: Кстати, вы всё логично рассказываете. Так что я понял, что такое Kubernetes. Но по-прежнему ума не приложу, зачем он может быть нужен. То есть, какой смысл всё это изучать?

Я: Именно, последнее, что нам осталось разобрать — как именно используется Kubernetes. Что с ним можно делать? Чем он полезен/важен в мире технологий? Давайте ненадолго вернёмся к кухонной аналогии и объясним ещё несколько концепций.

  • Владелец ресторана/франшизы в данном случае аналогичен команде разработчиков, создающих приложение или сервис. В Макдональдсе владелец франшизы (назовём его Франсуа Галль) хочет получить данные о том, какова выручка в каждой из точек, и на основании этого уволить часть сотрудников или нанять новых. Для этого Франсуа Галль может взять телефон, позвонить директору ресторана, чтобы узнать информацию и раздать распоряжения. При работе с Kubernetes программисты, конечно же, не могут взять трубку и переговорить со своим кластером, но на «ведущем узле» есть сервер API. Его можно вызвать и получить доступ ко всем задачам. Например, инженер может узнать, какова ситуация со всеми подами, узлами, сервисами, понять степень работоспособности системы м проверить метрики. Также инженер может создать или удалить ресурсы по мере необходимости.
  • Гость, который заходит в ресторан перекусить, аналогичен пользователю приложения или сервиса. Точно как на кухне Макдональдса готовят бигмаки, чтобы я мог утолить голод, кластер Kubernetes в Spotify позволяет мне слушать в браузере музыку, которую я выбираю из очень большой коллекции.

Всю эту новую информацию я вынес на рисунок, приведённый ниже. Эта схема очень похожа на те, которые можнео нагуглить по запросу «архитектура Kubernetes».



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

❯ Заключение


Я решила написать этот пост именно в таком стиле (изложить высокотехнологичную тему так, как будто объясняю её таксисту), поскольку хотела подобрать для Kubernetes аналогии, которые были бы понятны и доступны любому человеку.


Возможно, захочется почитать и это: