Что такое Kubernetes? Знакомимся с дико популярной платформой контейнерной оркестрации

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

1. Kubernetes ускоряет работу. С Kubernetes вы получаете платформу как услугу (PaaS) с возможностью самообслуживания и можете создавать на ней уровень аппаратных абстракций для разработчиков. Ваши команды разработчиков смогут быстро и легко запрашивать и получать как необходимые, так и дополнительные ресурсы (например, для обработки дополнительной нагрузки), так как все ресурсы предоставляются из общей инфраструктуры, доступной всем вашим командам.
   Больше никакой бумажной волокиты с запросом новых машин для запуска вашего приложения. Просто получаете ресурсы и вперед, тем более что еще можно воспользоваться разработанными специально под Kubernetes инструментами для автоматизации процесса упаковки, развертывания и тестирования, например, пакетным менеджером Helm (подробности ниже).
2. Kubernetes ­— это экономично. Kubernetes и контейнеры гораздо рациональнее расходуют ресурсы по сравнению с гипервизорами и виртуальными машинами (ВМ); они мало весят и поэтому требуют меньше ресурсов ЦП и памяти.
3. Kubernetes не зависит от конкретных облачных платформ. Kubernetes работает не только на Amazon Web Services (AWS), Microsoft Azure или Google Cloud Platform (GCP), но еще и в локальной инфраструктуре. При переносе рабочих нагрузок не придется перепроектировать приложения или полностью перекраивать инфраструктуру, что позволяет стандартизировать работу на платформе и избежать привязки к конкретному вендору.
   Более того, такие компании как Kublr, Cloud Foundry и Rancher предлагают инструментарий, который облегчает развертывание кластера Kubernetes и управление им как локально, так и в облаке любого поставщика.
4. Поставщики облачных услуг возьмут на себя управление Kubernetes. Как уже было сказано, Kubernetes — это золотой стандарт для инструментов контейнерной оркестрации, поэтому неудивительно, что разные варианты «Kubernetes как услуга» есть в портфеле большинства поставщиков облачных услуг. Amazon EKS, Google Cloud Kubernetes Engine, Azure Kubernetes Service (AKS), Red Hat Openshift и IBM Cloud Kubernetes Service — берут на себя все управление платформой Kubernetes, чтобы вы могли сосредоточиться на более важных делах: доставке приложений на радость пользователям.

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

Общая схема кластера Kubernetes показана на следующей диаграмме: 

Ведущий узел Kubernetes

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

Ведущий узел хранит данные о состоянии и конфигурации для всего кластера в постоянном и распределенном хранилище ключей/значений ectd. У каждого узла есть доступ к хранилищу ectd, и через него узлы узнают, как поддерживать конфигурацию своих контейнеров. Хранилище etcd можно запустить на ведущем узле Kubernetes или в автономной конфигурации.

Ведущие узлы сообщают остальным узлам в кластере через API сервер Kubernetes (kube-apiserver), где находится главная точка доступа к панели управления. Например, kube-apiserver контролирует, чтобы конфигурации в хранилище etcd и в контейнерах, развернутых в кластерах, соответствовали друг другу.

Менеджер контроллеров Kubernetes (kube-controller-manager) взаимодействует с контурами регулирования, которые управляют состоянием кластера, через API сервер Kubernetes. Кроме того, этот сервис управляет контроллерами развертывания, реплик и узлов. Например, контроллер узла регистрирует узел и отслеживает его рабочее состояние в течение всего жизненного цикла.

За отслеживание рабочих нагрузок на узле в кластере и управление ими отвечает планировщик Kubernetes (kube-scheduler). Этот сервис отслеживает производительность и ресурсы узлов и распределяет работу по узлам, исходя из их доступности.

Менеджер облачных контроллеров (cloud-controller-manager) — это один из сервисов в Kubernetes, обеспечивающий независимость от конкретных облачных платформ. Он реализован в виде уровня абстракции, который отделяет API и инструменты поставщика облачных услуг (например, тома хранилища или балансировщики нагрузки) от их визави в Kubernetes.

Узлы

Все узлы в кластере Kubernetes должны быть настроены в среде выполнения контейнера, как правило, в Docker. Среда выполнения контейнера запускает контейнеры и управляет ими после того, как Kubernetes развернет их на узлах в кластере. Ваши приложения (веб-сервисы, базы данных, серверы API и т.д.) выполняются внутри контейнеров.

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

kube-proxy — это сетевой прокси, который выполняется на узлах в кластере и еще работает как балансировщик нагрузки для сервисов, запущенных на узле.

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

Нужные вам характеристики контейнеров можно описать в поде через объект, написанный на языке YAML или JSON и называемый Pod Spec. Эти объекты попадут в kubelet через API сервер.

Под может определять один или несколько томов (volumes), таких как локальный или сетевой диск, а также раскрывать их другим контейнерам в поде — таким образом разные контейнеры делят между собой пространство хранения. Например, тома можно задействовать, когда один контейнер загружает содержимое, а другой выгружает его куда-то еще.

Поскольку контейнеры внутри подов часто эфемерны, Kubernetes предлагает тип балансировщика нагрузки (service), который упрощает отправку запросов группе подов. Сервис целенаправленно отбирает логическое множество подов на основе меток (labels) (подробности ниже). По умолчанию сервисы доступны в пределах конкретного кластера, но вы можете сделать их общедоступными, если хотите, чтобы они получали запросы извне кластера.

Развертывание и реплики

Развертывание (deployment) — это YAML-объект , определяющий поды и количество экземпляров контейнеров, так называемых реплик, для каждого пода. Вы задаете необходимое количество реплик для выполнения в кластере через набор реплик (ReplicaSet), который входит в объект развертывания. Так, например, если узел, на котором работал под, падает, то ReplicaSet распределит его нагрузку на другой под, работающий на другом доступном узле.

Набор фоновых процессов (DaemonSet) запускает и выполняет определенные фоновые процессы (в поде) на назначенных вами узлах. Чаще всего они применяются для обслуживания и поддержки подов. Например, с помощью набора фоновых процессов инфраструктура New Relic разворачивает агент инфраструктуры на всех узлах в кластере.

Пространства имен

Пространства имен (Namespaces) позволяют создавать виртуальные кластеры поверх физического кластера и предназначены для многопользовательских сред, где пользователи распределены по разным командам или проектам. Они распределяют квоты ресурсов и логически изолируют ресурсы кластера.

Метки

Метки (Labels) — это пары ключ/значение, которые можно присвоить подам и другим объектам в Kubernetes. С помощью меток операторы Kubernetes упорядочивают и отбирают подгруппы объектов. Например, во время мониторинга объектов Kubernetes метки помогают быстро найти нужную информацию.

Наборы с сохранением состояния и постоянные тома хранения

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

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

1. Технологический ландшафт Kubernetes может показаться запутанными. За что разработчики любят технологии с открытым исходным кодом, такие как Kubernetes, так это за их потенциал для быстрого развития инноваций. Но иногда чрезмерная инновационность создает путаницу, особенно когда пользователи не поспевают за темпами развития центральной кодовой базы Kubernetes. В довершение армада из поставщиков платформ и управляемых услуг окончательно сбивает с толку новичков на просторах Kubernetes.
2. Прогрессивные идеи разработчиков и ИТ-специалистов не всегда совпадают с приоритетами бизнеса. Если бюджет позволяет только поддерживать статус-кво, то командам будет сложно получить финансирование на эксперименты с Kubernetes, на которые часто уходит куча времени и сил. Кроме того, ИТ-отделы компаний зачастую боятся рисковать и не торопятся меняться.
3. Командам все еще нужно нарабатывать навыки, чтобы воспользоваться всеми преимуществами Kubernetes. Всего пару лет назад разработчики и ИТ-специалисты освоили контейнеризацию, а уже пора разбираться в контейнерной оркестрации. Компаниям, которые хотят перейти на Kubernetes, нужно нанять профессионалов, которые умеют писать код, знают, как управлять операциями, и понимают архитектуру приложений, хранилищ и процедуры работы с данными.
4. Платформой Kubernetes сложно управлять. На портале GitHub, в разделе Отказ работы Kubernetes, уже накопилось целое собрание всевозможных леденящих кровь баек о Kubernetes от детской страшилки про обвал DNS-сервера до истории ужасов про каскадный отказ распределенных систем.

Несмотря на то, что переход на Kubernetes – задача не из простых, сегодня облачные провайдеры предлагают бизнесу два типа услуг для ее решения: Kubernetes as a Service и Managed Kubernetes. Каждый из них позволяет значительно минимизировать трудовые и временные затраты компаний на развертывание и сопровождение инфраструктуры на базе микросервисов и контейнеров.

Основное различие между ними заключается в уровне управления и поддержки. Kubernetes as a Service обеспечивает заказчику основные функциональные возможности, но при этом подразумевает необходимость самостоятельного управления. В то время как Managed Kubernetes включает широкий спектр услуг для поддержки даже самых сложных проектов и требований, а также предполагает возможность полной передачи управления контейнерной инфраструктурой на аутсорс.

Что выбрать – зависит от специфики задач, стоящих перед вами. Если у вас есть необходимость в полном контроле над вашим Kubernetes-кластером, и вы готовы заниматься его самостоятельным развертыванием, масштабированием и администрированием, то Kubernetes as a Service – подходящий вариант. Но при этом важно учитывать, что в данном случае важно наличие собственной экспертизы в Kubernetes.

Managed Kubernetes – более удобный способ управления кластерами. Он рекомендуется в случаях, когда требуется миграция с зарубежных платформ оркестрации контейнеров, более тонкая степень настройки, поддержка 24/7, а также для тех проектов, где необходима выделенная команда специалистов. Также он может быть предпочтительным выбором, когда вам нужно быстро развернуть кластер, или если вы не обладаете опытом в управлении Kubernetes.

Ниже в таблице представлено более подробное сравнение Kubernetes as a Service и Managed Kubernetes: