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

Представим себе крупную компанию, которая состоит из нескольких бизнес-юнитов. В ней каждый юнит занимается своим направлением деятельности. Условно, когда «Лаборатория Числитель» разрастется, у нас будет три отдельных бизнес-юнита: контейнеры («Штурвал»), ИТ-мониторинг («Пульт») и облака («Нимбиус»). У каждого юнита есть офис и департаменты, поделенные на отделы, в которых работают сотрудники с конкретными функциями.

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

Мы решили сравнить платформу оркестрации кластеров Kubernetes с любой крупной компанией, взяв за пример «Штурвал».

Чтобы упростить понимание, статья поделена на три части:

1. Введение в Kubernetes.

2. Больше об объектах Kubernetes.

3. От кластера Kubernetes к мультикластерной платформе.

Для вашего удобства в конце можно найти глоссарий.

Часть №1. Введение в Kubernetes

Начало начал

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

Слухи о качестве вашего кода стремительно распространяются. Ваше дело начинает расти, запросов на вашу деятельность все больше. Поэтому вы принимаете решение масштабироваться и открываете ИП. Далее — нанимаете и самостоятельно обучаете разработке несколько человек, буквально вкладывая в их головы все, что знаете вы: ваши методики, подходы, знания. Это можно сравнить с упаковкой приложения в контейнер и поднятием нескольких реплик в Docker. Контейнер ограничен операционной системой так же, как человек подходами (методиками), которым его обучили. Также он ограничен ресурсами, ровно как человек зарплатой, возможностями своей памяти и длительностью рабочего дня.

Docker не умеет автоматически менять количество реплик в зависимости от нагрузки, так и вы можете только самостоятельно нанять или уволить сотрудников при изменении количества запросов на вашу деятельность.

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

• бухгалтерия;

• HR;

• уборка офиса;

• и многие-многие другие.

Каждый из сотрудников выполняет какую-то функцию (должностные обязанности), которые можно сравнить с экземпляром его приложения. А компания организована таким образом, чтобы распределять задачи между сотрудниками, вести учет, наем и многое другое.

Итак, добро пожаловать в кластер Kubernetes!

В кластере Kubernetes функции (компании) выполняют объекты под названием Pod (под). Они содержат в себе контейнеры с экземплярами приложений.

Деятельность сотрудника (Container, контейнер)

Функции сотрудника (экземпляры его приложения), его зарплата и рабочий график (ресурсы, которые требует это приложение) прописываются в договоре сотрудника (Pod Template) и могут меняться с течением времени.

Сотрудник может иметь разный набор функций, например, одновременно быть разработчиком и DevOps-инженером, офицером ИБ и project-менеджером. Бывает, что на время онбординга сотруднику назначена одна функция, а сразу после его завершения — другая. В этом случае функции на время онбординга — это Init-контейнер, который запускается только при старте пода (начальном времени работы сотрудника). В идеальном мире сотрудник, конечно же, специализируется только на одной функции =)

Сотрудники (Workloads, рабочие нагрузки)

Сотрудники выполняют работу и объединяются в отделы. В Kubernetes такие отделы называются рабочими нагрузками (Workloads). Они могут заниматься разработкой, управлять человеческими ресурсами, заведовать важными данными или обслуживать офисы. Некоторые отделы находятся в офисе весь рабочий день, другие приходят только на время выполнения своих обязанностей (функций).

В зависимости от вида функций разные отделы (нагрузки) имеют разное название. 

Постоянные сотрудники StatefulSets

Если есть информация, которая нужна другим отделам в надежном месте, нет ничего лучше, чем StatefulSets (например, бухгалтерия, чьи сотрудники консультируют других по поводу архивных данных).

DaemonSets

Отдел, отвечающий за человеческие ресурсы (HR), — это DaemonSets. Они следят, чтобы сотрудники (Pod) находились на своих местах и выполняли свою работу. Так, например, они контролируют, чтобы в бизнес-юните были такие сотрудники, которые собирают фидбэк по другим сотрудникам и отчеты по отделам (логи и метрики), а также прописывают регламенты для онбординга сотрудников (можно сравнить с бэкапированием подов или даже целых неймспейсов).

Deployments

Отделы, которые заняты проектной деятельностью, — это Deployments. В зависимости от количества запросов к ним они увеличивают или сокращают количество подов (число сотрудников в штате).

ReplicaSets

Несколько сотрудников в одном отделе, обладающих одинаковыми компетенциями, можно сопоставить с ReplicaSets подов. Такой набор может создавать Deployment. Допустим, на проекте есть направление frontend-разработки, в котором есть три пода (сотрудника) — можно сказать, что это ReplicaSet из трех подов. В направлении Deployment может быть указано определенное количество сотрудников (Pods) или ограниченное какими-то цифрами, но не больше определенных значений в зависимости от загрузки (horizontal pod autoscaler). В таком случае количество подов (сотрудников) может быть:

• задано строго в виде определенного значения (например, только два разработчика);

• задано в пределах коридора значений (например, всегда должно быть не меньше одного разработчика, но при необходимости можно нанять до пяти).

Pods

Также компания может привлечь сотрудника из другого отдела для конкретного проекта. Это будет отдельно стоящий под без управления Deployment, DaemonSet или StatefulSet.

Приходящие сотрудники Jobs

Офис необходимо обслуживать. Например, мы покупаем кофе или заказываем кейтеринг на мероприятие. Это job, который создает один или несколько подов (условно курьеров или уборщиков), которые разово появляются в офисе и выполняют свою работу. В результате job завершается, а курьеры и уборщики покидают офис.

CronJobs

Еще предусмотрена регулярная уборка офисов, которая проходит по расписанию каждые четыре часа (CronJob). В отличие от подов других нагрузок, мы не держим поды (сотрудников) Job и CronJob непрерывно. Мы их приглашаем только для выполнения задачи, а затем отпускаем отдыхать :)

От отделов к департаментам

Мы рассмотрели, какие бывают отделы (нагрузки в Kubernetes). Надеемся, вы еще не запутались, и мы можем двигаться дальше.  

Отделы компании, которую мы с вами собираем, объединяются в департаменты, у которых есть общие правила и ограничения. В Kubernetes такие департаменты называются пространствами имен, или namespaces.

Каждая компания должна иметь юридический адрес. Если упростить, то можно назвать его офисом. Давайте разместим в этот офис департаменты с отделами.

Офис (Узел кластера)

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

Представим, что вся компания работает только из офиса. В таком случае офисы, в которых работают руководители, будут Master-узлами, а те, в которых сидят рядовые сотрудники, — Worker-узлами. Очевидно, что кабинетов для рядовых сотрудников потребуется значительно больше, чем для руководителей.

В каждом офисе руководителей (на каждом Master-узле) должен храниться одинаковый комплект регламентных (например, уставных) документов (etcd). Кроме того, сами руководители должны уметь договориться между собой. Однако договориться они могут только тогда, когда в споре побеждает большинство, например, если оппонентов только один, трое или пятеро. Четное количество людей не может договориться между собой. Логично, что чем больше руководителей мы имеем, тем сложнее им договориться между собой и держать регламентный набор документов с одинаковым набором данных.

Теперь вы познакомились с основными сущностями Kubernetes!

Часть №2. Больше об объектах в Kubernetes

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

Взаимодействия

LoadBalancer и Descheduler

В компании (кластере) есть специальный человек, который принимает извне входящие задачи, например пресейл, и распределяет их между своими офисами (узлами). Он знает, кто как загружен на момент поступления задачи в работу, и выполняет роль балансировщика нагрузки (LoadBalancer). Внутри департамента (пространства имен) тоже есть свой LoadBalancer. Принцип работы у него точно такой же.

После распределения нагрузки может выясниться, что сотрудники какого-то офиса сделали работу слишком быстро, а другие, наоборот, мучаются и никак не могут решить проблему — к ним поступают всё новые и новые доработки. Тогда на сцену выходит другой специалист (например, менеджер проекта) — Descheduler. Он перераспределяет нагрузку между сотрудниками (Pod) разных офисов.

Ingress

Помните телефонисток, получающих звонки и соединяющих с нужным номером? В Kubernetes есть кое-что похожее.

Ingress проще всего представить в роли менеджера. Менеджеры не работают в дирекции, они являются частью офиса рядовых сотрудников (Worker-узел). Представим, что среди менеджеров есть лиды и рядовые сотрудники. Вторые фактически являются Ingress-контроллером. Они получают всю внешнюю информацию от бизнеса (извне) и передают ее локальным менеджерам в департаментах (Ingress в неймспейсах). У них всегда есть персональные номера локальных менеджеров — в терминологии Kubernetes это порты, по которым они обращаются.

Заглянем в офис?

Хранилище департамента (Storage)

В нем размещаются:

• запросы на хранение информации (PersistentVolumeClaims);

• защищенная информация (Secrets);

• регламентные документы (ConfigMaps).

PersistentVolumeClaims

Ответственные сотрудники отделов смотрят, сколько у них собралось документов, и запрашивают у руководства место для их хранения в офисе (на узле). Этот запрос называется PersistentVolumeClaims. Для обеспечения этого требования руководство выделяет тумбочки, шкафы и комнаты библиотек — постоянные тома (PersistentVolumes) — и хранит их. Размещение информации фиксируется в базе офиса в виде объекта класса хранилища (Storage Class). Так, например, размещение внутри бизнес-юнита будет локальным хранилищем (LocalStorage).

Как мы понимаем, большой объем данных по тумбочкам не разложишь. Для совсем маленького отдела, может, это и помогло бы, но для огромной компании — точно не вариант. В нашем случае ответственные сотрудники просят освободить забитые скоросшивателями кладовки и разместить информацию на серверах. Таким образом, они создают новый запрос на хранилище, только с объемом данных, превышающим размер кладовки. Также они намекают на использование внешнего хранилища (например, облака или склада), указывают в своем запросе на хранилище (PersistentVolumeClaim), например, Ceph или vSphereCSI в зависимости от того, с кем у компании уже заключен договор.

Configmaps

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

Secrets

Важную информацию, которую мы не должны показывать всем подряд, мы записываем в секреты. Это, например, наши пропуски. Они создаются в отделе безопасности, а дальше мы используем в качестве ссылки (карточки с фотографиями) на объект без демонстрации состава данных (зашитого в них ключа).

Quotas и LimitRanges

Руководство может устанавливать ограничения на наем сотрудников, размер занимаемых кабинетов и использование хранилища для департамента или конкретного отдела. Такие ограничения фиксируются, а потолок значения устанавливается в виде квот. Также может быть принят регламент (LimitRange), согласно которому, например, в департаменте должно работать не меньше пяти, но не больше 50 сотрудников.

А что дальше?

Теперь, когда вы в общих чертах познакомились с терминологией, можно рассмотреть, как Kubernetes работает в реальной жизни.

Представим, что компания N разрабатывает свое программное обеспечение. Это могут быть порталы, сайты, приложения, игры, а если конкретнее, то, например, всем знакомый мобильный банкинг. Экземпляр написанного приложения упаковывают в виде образа (слепка) в контейнер. Операция упаковки похожа на запись игры на диск (привет из нулевых :D). Дальше, как вы помните, контейнер запускается с помощью пода в кластере Kubernetes. Но зачем это нужно?

Всё просто.

1. В разное время на приложение приходится разная нагрузка. Kubernetes позволяет увеличивать и уменьшать количество подов (horizontal pod autoscaler) с экземплярами приложения, а значит, и пользователи всегда имеют доступ к приложению и ресурсы на поддержку его функционирования не простаивают.

2. Платформа контейнерной оркестрации (например, «Штурвал») позволяет создавать в одном кластере узлы рабочих нагрузок (где будет запущено приложение) на физических серверах и виртуальных машинах, что повышает уровень отказоустойчивости.

3. Разработчики часто выпускают обновления. Чтобы обновить приложение, упакованное в контейнер, нужно только заменить образ. Это быстрая и безопасная процедура.

Благодаря простоте запуска контейнеров в Kubernetes такие приложения удобно тестировать — под с нужным контейнером можно запустить одной командой или, если мы говорим о платформе оркестрации, в пару кликов. Представляете, пара кликов, и у вас развернуто приложение?

Подытоживая, Kubernetes — это не так сложно, как кажется. Более того, каждый из нас сталкивается с ним ежедневно. Теперь-то убедились в этом?

Часть №3. От кластера Kubernetes к мультикластерной платформе

Мы увидели, что такое кластер Kubernetes и какие у него основные объекты. В этой части предлагаем разобраться, зачем нужна платформа, если вся магия уже есть в Kubernetes? 

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

Звучит просто, но как же это организовать?

Дальше, выше, быстрее!

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

Каждый бизнес-юнит любой крупной компании можно считать клиентским кластером (Worker Cluster), а дирекцию — кластером управления (Management Cluster). От бизнес-юнитов в дирекцию поступают различные отчеты, в том числе операционные, и она выделяет им (клиентским кластерам) офисные помещения.

В мультикластерной платформе есть кластер управления (Management Cluster). Он может контролировать множество клиентских кластеров (Worker Cluster).

Платформа оркестрации кластеров Kubernetes и кластер Kubernetes

Сам Kubernetes можно представить в виде абстракции по типу франшизы, в которой прописано: такой-то набор офисов + набор его характеристик + его регламенты = бизнес-юнит. Он будет нанимать и контролировать наличие сотрудников с необходимыми компетенциями, если вы запросите.

Платформа оркестрации уже добавляет такую надстройку, как дирекция, автоматизация запуска этой франшизы, возможность управления сразу множеством бизнес-юнитов, контроль за их работой.

Благодаря платформе можно создавать и упразднять бизнес-юниты, оперативно решая поставленные задачи. А стандартизация процесса позволяет сократить расходы на согласование, выделение доступов и погружение новых сотрудников.  

Надеемся, после прочтения трех частей о платформе оркестрации вам стали ближе такие понятия, как Kubernetes и мультикластерная платформа :)

Глоссарий

Если вы увлечены миром Kubernetes так же сильно, как и мы — присоединяйтесь к нашему Kubernetes-сообществу в Telegram :) Там обмениваемся опытом, помогаем установить и настроить бесплатную и полнофункциональную community-версию «Штурвала», а еще почти каждую неделю разыгрываем призы!