Вместо эпиграфа: Статья написана для новичков и содержит значительные допущения в логике работы Kubernetes. Если вы опытный пользователь, будем благодарны за обратную связь и помощь сообществу в комментариях :)
Представим себе крупную компанию, которая состоит из нескольких бизнес-юнитов. В ней каждый юнит занимается своим направлением деятельности. Условно, когда «Лаборатория Числитель» разрастется, у нас будет три отдельных бизнес-юнита: контейнеры («Штурвал»), ИТ-мониторинг («Пульт») и облака («Нимбиус»). У каждого юнита есть офис и департаменты, поделенные на отделы, в которых работают сотрудники с конкретными функциями.
Еженедельно бизнес-юнит ставит задачи и распределяет их между департаментами, а также делает отчеты для дирекции компании. Таким образом, у всех получается достигать поставленных бизнес-целей. Перед каждым юнитом стоят одинаковые задачи — распределение обязанностей, наем или увольнение сотрудников. Дирекция контролирует все происходящие процессы в бизнес-юнитах, распределяет затраты и отвечает за принятие финальных решений. Также в крупных компаниях нужны различные менеджеры, сейлы и еще множество других сотрудников.
Мы решили сравнить платформу оркестрации кластеров Kubernetes с любой крупной компанией, взяв за пример «Штурвал».
Чтобы упростить понимание, статья поделена на три части:
Введение в Kubernetes.
Больше об объектах Kubernetes.
От кластера 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. Но зачем это нужно?
Всё просто.
В разное время на приложение приходится разная нагрузка. Kubernetes позволяет увеличивать и уменьшать количество подов (horizontal pod autoscaler) с экземплярами приложения, а значит, и пользователи всегда имеют доступ к приложению и ресурсы на поддержку его функционирования не простаивают.
Платформа контейнерной оркестрации (например, «Штурвал») позволяет создавать в одном кластере узлы рабочих нагрузок (где будет запущено приложение) на физических серверах и виртуальных машинах, что повышает уровень отказоустойчивости.
Разработчики часто выпускают обновления. Чтобы обновить приложение, упакованное в контейнер, нужно только заменить образ. Это быстрая и безопасная процедура.
Благодаря простоте запуска контейнеров в Kubernetes такие приложения удобно тестировать — под с нужным контейнером можно запустить одной командой или, если мы говорим о платформе оркестрации, в пару кликов. Представляете, пара кликов, и у вас развернуто приложение?
Подытоживая, Kubernetes — это не так сложно, как кажется. Более того, каждый из нас сталкивается с ним ежедневно. Теперь-то убедились в этом?
Часть №3. От кластера Kubernetes к мультикластерной платформе
Мы увидели, что такое кластер Kubernetes и какие у него основные объекты. В этой части предлагаем разобраться, зачем нужна платформа, если вся магия уже есть в Kubernetes?
Здесь могу предложить другую аналогию — кластер Kubernetes как сложное ресторанное блюдо. Да, его может приготовить любой при должном упорстве и старании, но это сложно и долго, а дьявол, как всегда, кроется в деталях. Платформа в таком контексте выступает как сервис доставки. Вы говорите, какой кластер Kubernetes вам нужен, из какого ресторана (в случае с K8s — на каких мощностях), и через несколько минут получаете готовый к эксплуатации кластер.
Звучит просто, но как же это организовать?
Дальше, выше, быстрее!
Давайте вернемся к нашей «бытовухе». Когда ваша компания становится еще больше, появляются новые виды деятельности, много сотрудников в штате и новый уровень абстракции — бизнес-юнит. Это то, чем раньше была ваша компания. Теперь таких юнитов становится несколько, т.е. несколько кластеров Kubernetes. Здесь логика точно такая же, как и внутри кластера: чтобы управлять множеством кластеров, требуется управляющий объект. В случае платформы это управляющий кластер.
Каждый бизнес-юнит любой крупной компании можно считать клиентским кластером (Worker Cluster), а дирекцию — кластером управления (Management Cluster). От бизнес-юнитов в дирекцию поступают различные отчеты, в том числе операционные, и она выделяет им (клиентским кластерам) офисные помещения.
В мультикластерной платформе есть кластер управления (Management Cluster). Он может контролировать множество клиентских кластеров (Worker Cluster).
Платформа оркестрации кластеров Kubernetes и кластер Kubernetes
Сам Kubernetes можно представить в виде абстракции по типу франшизы, в которой прописано: такой-то набор офисов + набор его характеристик + его регламенты = бизнес-юнит. Он будет нанимать и контролировать наличие сотрудников с необходимыми компетенциями, если вы запросите.
Платформа оркестрации уже добавляет такую надстройку, как дирекция, автоматизация запуска этой франшизы, возможность управления сразу множеством бизнес-юнитов, контроль за их работой.
Благодаря платформе можно создавать и упразднять бизнес-юниты, оперативно решая поставленные задачи. А стандартизация процесса позволяет сократить расходы на согласование, выделение доступов и погружение новых сотрудников.
Надеемся, после прочтения трех частей о платформе оркестрации вам стали ближе такие понятия, как Kubernetes и мультикластерная платформа :)
Глоссарий
Метафорическое определение | Термин | Определение термина |
Крупная компания | Платформа оркестрации кластеров Kubernetes | Например, наша платформа управления контейнерами «Штурвал» |
Департамент (например, департамент ИТ) | Неймспейс (пространство имен) | Механизм организации и изоляции объектов в Kubernetes |
Офис директората | Master-узел | Узел управления в кластере Kubernetes |
Офис рядовых сотрудников | Worker-узел | Узел, на котором запускаются приложения в кластере Kubernetes |
Устав или другой обязательный регламент руководства | etcd | Распределенное хранилище данных, используемое Kubernetes для хранения конфигураций в формате «ключ-значение» |
Отделы департаментов | Нагрузки, Рабочие нагрузки, Workloads | Задачи или процессы, которые выполняются в Kubernetes |
Отдел разработки | Deployment | Объект, который управляет развертыванием приложения в Kubernetes |
Направление отдела разработки, например Backend, DevOps | ReplicaSet | Контроллер, который обеспечивает стабильное количество реплик пода |
Бухгалтерия, хранящая архивы | StatefulSet | Контроллер, который управляет порядком и идентичностью реплик пода в Kubernetes |
HR, обеспечивающие присутствие необходимых сотрудников в определенных отделах | DaemonSet | Контроллер, который обеспечивает запуск определенного числа подов на каждом узле в кластере |
Сотрудники, выполняющие разовые задачи, например кейтеринг для мероприятия в офисе | Job | Объект, который запускает задачу и завершает ее при выполнении |
Сотрудники, выполняющие регулярные задачи, например приготовление обедов, уборка | CronJob | Объект, позволяющий запускать задачу по расписанию |
Сотрудник | Pod | Минимальная единица развертывания в Kubernetes, содержащая один или несколько контейнеров |
Функция сотрудника с точно определенными ресурсами (зарплатой, графиком), подходами к исполнению (Операционной системой) | Container | Изолированное окружение, в котором запускается приложение со всеми зависимостями |
Функция сотрудника с точно определенными ресурсами (зарплатой, графиком), подходами к исполнению (Операционной системой) на время онбординга | Init Container | Специальный тип контейнера, который запускается и выполняется до запуска основных контейнеров в поде |
Определенная функция сотрудника | Образ, Image | Снимок файловой системы контейнера, содержащий приложения и их зависимости |
Запись в базе о том, кто, какой объем и где хранит согласно заявке на выделение места | PersistentVolume | Объем дискового пространства в кластере Kubernetes, которое было создано администратором |
Заявка на выделение места хранения | PersistentVolumeClaim | Запрос на PersistentVolume от пользователя |
Накладная, в которой описывается, кто и где что-то хранит | StorageClass | Классы хранения в Kubernetes, определяющие место хранения данных |
Хранилище внутри офиса департамента, например кладовка или личная тумбочка | LocalStorage | Тип PersistentVolume, который позволяет использовать локальное хранилище в кластере Kubernetes |
Внешний поставщик места хранения для физических предметов или информации | Ceph FS, NFS, oVirt, vSphere | Различные провайдеры хранилища данных, которые можно использовать в кластере Kubernetes |
Руководитель проекта, распределяющий нагрузку между сотрудниками на проекте | Descheduler | Инструмент, который перераспределяет поды между узлами в кластере, чтобы улучшить общую эффективность работы |
Компания, состоящая из одного или несколько офисов с работающими в них сотрудниками | Кластер Kubernetes | Группа из одного или нескольких узлов с запущенными на них подами |
Дирекция компании | Кластер управления | Кластер, который управляет инфраструктурой клиентских кластеров, централизованно хранит логи и метрики клиентских кластеров в архитектуре «Штурвала» |
Бизнес-юнит | Клиентский кластер | Кластер, в котором запущены пользовательские нагрузки. Находится под управлением кластера управления в архитектуре платформы, например, «Штурвала» |
Франшиза по запуску и работе одного бизнес-юнита | Kubernetes | Оркестратор контейнеров |
Набор регламентов, который используют сотрудники | ConfigMap | Объект Kubernetes, который используется для хранения и распространения конфигурации среди подов |
Защищенная информация для сотрудников, например 2FA, пропуск в офис | Secret | Объект Kubernetes для безопасного хранения чувствительных данных, например паролей и ключей |
Ограничения, установленные для департамента, например по закупке техники или использования офисов | Quota | Пределы, установленные для использования ресурсов |
Ограничения, установленные для департамента, например на наем сотрудников только определенных компетенций | LimitRange | Объект, который указывает на ограничения использования ресурсов на уровне пространства имен |
Менеджер, коммуницирующий с другими рядовыми сотрудниками и внешним миром | Ingress | Объект, через который входящий трафик может быть направлен на службы внутри кластера |
Руководитель направления внутри департамента, распределяющий сотрудников между проектами | LoadBalancer | Балансировщик нагрузки, который автоматически распределяет входящий сетевой трафик по нескольким подам |
Алиса Кириченко
Заместитель владельца платформы «Штурвал»
Если вы увлечены миром Kubernetes так же сильно, как и мы — присоединяйтесь к нашему Kubernetes-сообществу в Telegram :) Там обмениваемся опытом, помогаем установить и настроить бесплатную и полнофункциональную community-версию «Штурвала», а еще почти каждую неделю разыгрываем призы!