.svg)
Что такое Kubernetes? Знакомимся с дико популярной платформой контейнерной оркестрации
С появлением микросервисной архитектуры и технологии контейнеризации разработчики и администраторы стали совсем по-другому тестировать и развертывать современное ПО.
Контейнеры облегчают масштабирование и развертывание приложений, но при этом создают совершенно новую инфраструктурную экосистему, а, значит, новые проблемы и сложности. Разработчики ПО, как крупные корпорации, так и стартапы, ежедневно развертывают тысячи экземпляров контейнеров и должны этим снежным комом как-то управлять. Как им это удается?
Добро пожаловать в эпоху Kubernetes
Kubernetes была задумана корпорацией Google как платформа контейнерной оркестрации с открытым исходным кодом, предназначенная для развертывания, масштабирования и управления контейнерными приложениями. Kubernetes стала де факто общепринятым стандартом контейнерной оркестрации и флагманским проектом Фонда развития облачных вычислений (англ. Cloud Native Computing Foundation), который поддержали такие ключевые игроки рынка как Google, AWS, Microsoft, IBM, Intel, Cisco, и Red Hat.
Kubernetes позволяет легко внедрять и использовать приложения в микросервисной архитектуре, создавая уровень абстракции поверх группы хостов. В результате команды разработчиков могут развертывать приложения и позволяют платформе Kubernetes:
- Контролировать, сколько ресурсов потребляет приложение или команда
- Равномерно распределять нагрузку приложений по инфраструктуре хоста
- Автоматически отправлять запросы на балансировку нагрузки между разными экземплярами приложения
- Отслеживать потребление ресурсов и их лимиты, чтобы автоматически останавливать и затем перезапускать приложения, потребляющие слишком много ресурсов.
- Перемещать экземпляр приложения с одного хоста на другой, если хосту не хватает ресурсов или если он упал.
- Автоматически задействовать дополнительные ресурсы при добавлении нового хоста в кластер
Легко запускать канареечные релизы и откатываться назад.
Ладно, но что за хайп? Почему Kubernetes так популярен?
Чем больше организаций переходит на микросервисные и заточенные под облако архитектуры с контейнеризацией, тем больше растет спрос на надежные и проверенные платформы. Специалисты переходят на Kubernetes по четырем основным причинам:
- Kubernetes ускоряет работу. С Kubernetes вы получаете платформу как услугу (PaaS) с возможностью самообслуживания и можете создавать на ней уровень аппаратных абстракций для разработчиков. Ваши команды разработчиков смогут быстро и легко запрашивать и получать как необходимые, так и дополнительные ресурсы (например, для обработки дополнительной нагрузки), так как все ресурсы предоставляются из общей инфраструктуры, доступной всем вашим командам.
Больше никакой бумажной волокиты с запросом новых машин для запуска вашего приложения. Просто получаете ресурсы и вперед, тем более что еще можно воспользоваться разработанными специально под Kubernetes инструментами для автоматизации процесса упаковки, развертывания и тестирования, например, пакетным менеджером Helm (подробности ниже). - Kubernetes — это экономично. Kubernetes и контейнеры гораздо рациональнее расходуют ресурсы по сравнению с гипервизорами и виртуальными машинами (ВМ); они мало весят и поэтому требуют меньше ресурсов ЦП и памяти.
- Kubernetes не зависит от конкретных облачных платформ. Kubernetes работает не только на Amazon Web Services (AWS), Microsoft Azure или Google Cloud Platform (GCP), но еще и в локальной инфраструктуре. При переносе рабочих нагрузок не придется перепроектировать приложения или полностью перекраивать инфраструктуру, что позволяет стандартизировать работу на платформе и избежать привязки к конкретному вендору.
Более того, такие компании как Kublr, Cloud Foundry и Rancher предлагают инструментарий, который облегчает развертывание кластера Kubernetes и управление им как локально, так и в облаке любого поставщика. - Поставщики облачных услуг возьмут на себя управление Kubernetes. Как уже было сказано, Kubernetes — это золотой стандарт для инструментов контейнерной оркестрации, поэтому неудивительно, что разные варианты «Kubernetes как услуга» есть в портфеле большинства поставщиков облачных услуг. Amazon EKS, Google Cloud Kubernetes Engine, Azure Kubernetes Service (AKS), Red Hat Openshift и IBM Cloud Kubernetes Service — берут на себя все управление платформой Kubernetes, чтобы вы могли сосредоточиться на более важных делах: доставке приложений на радость пользователям.
Так как же работает 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, но могут быть по-своему полезны:
Система доменных имен (DNS) Kubernetes
В Kubernetes предусмотрен механизм для обнаружения сервисов между подами с помощью DNS. Этот DNS-сервер работает в дополнение к любым другим DNS-серверам в вашей инфраструктуре.
Журнал кластерного уровня
При наличии инструмента журналирования можно интегрировать его с Kubernetes, чтобы извлекать и хранить журналы приложений и систем, взятые из кластера и записанные на стандартное устройство вывода и со стандартными кодами ошибок. Если вы хотите использовать журналы кластерного уровня, то имейте в виду, что в Kubernetes не предусмотрено место для хранения журналов, поэтому вы сами должны подобрать решение для хранения журнала.
Пакетный менеджер Helm как диспетчер приложений Kubernetes
Helm — это реестр диспетчера приложений для Kubernetes, поддерживаемый Фондом развития облачных вычислений. Так называемые карты Helm (charts) — это преднастроенные прикладные программные ресурсы, которые можно загрузить и развернуть в вашей среде Kubernetes. Согласно опросу, проведенному в 2018 году Фондом развития облачных вычислений ( 2018 CNCF survey), большинство респондентов (68%) выбирают Helm в качестве диспетчера приложений Kubernetes. Команды DevOps смогут быстрее управлять приложениями в Kubernetes с помощью готовых карт Helm, которыми они могут обмениваться, дополнять и развертывать их в своих средах разработки и продуктивных средах.
Kubernetes и Istio: сладкая парочка
В микросервисной архитектуре — такой как в Kubernetes — сервисная сетка (service mesh) представляет собой уровень инфраструктуры, на котором экземпляры ваших сервисов сообщаются между собой. Кроме того, сервисная сетка дает возможность настроить, как ваши экземпляры сервисов будут выполнять важные действия, такие как обнаружение сервисов, балансировка нагрузки, шифрование данных, аутентификация и авторизация. Istio — одна из таких сервисных сеток, которая, по мнению лидеров ИТ-индустрии, таких как Google и IBM, постепенно становится неотъемлемой частью платформы.
Облачная команда IBM, например, использует Istio при решении проблем контроля, прозрачности процессов и безопасности, с которыми она столкнулась при массовом развертывании Kubernetes. Если перечислять по пунктам, то Istio помогает IBM:
- Налаживать связь между сервисами и управлять потоком трафика
- Защитить взаимодействие между микросервисами с помощью гибких политик авторизации и аутентификации
- Установить контрольную точку, которая позволяет IBM управлять сервисами в продуктивной среде
- Наблюдать за тем, что происходит в сервисах, через адаптер, который передает данные от Istio к New Relic и, таким образом, позволяет отслеживать данные о производительности микросервисов из Kubernetes вместе с данными приложений, которые он также собирает
Трудности перехода на Kubernetes
Kubernetes ощутимо эволюционировал за первые пять лет своего существования, однако в таком еще детском возрасте стремительный рост периодически причиняет боль. Вот несколько трудностей, с которыми сталкиваются при переходе на Kubernetes:
- Технологический ландшафт Kubernetes может показаться запутанными. За что разработчики любят технологии с открытым исходным кодом, такие как Kubernetes, так это за их потенциал для быстрого развития инноваций. Но иногда чрезмерная инновационность создает путаницу, особенно когда пользователи не поспевают за темпами развития центральной кодовой базы Kubernetes. В довершение армада из поставщиков платформ и управляемых услуг окончательно сбивает с толку новичков на просторах Kubernetes.
- Прогрессивные идеи разработчиков и ИТ-специалистов не всегда совпадают с приоритетами бизнеса. Если бюджет позволяет только поддерживать статус-кво, то командам будет сложно получить финансирование на эксперименты с Kubernetes, на которые часто уходит куча времени и сил. Кроме того, ИТ-отделы компаний зачастую боятся рисковать и не торопятся меняться.
- Командам все еще нужно нарабатывать навыки, чтобы воспользоваться всеми преимуществами Kubernetes. Всего пару лет назад разработчики и ИТ-специалисты освоили контейнеризацию, а уже пора разбираться в контейнерной оркестрации. Компаниям, которые хотят перейти на Kubernetes, нужно нанять профессионалов, которые умеют писать код, знают, как управлять операциями, и понимают архитектуру приложений, хранилищ и процедуры работы с данными.
- Платформой Kubernetes сложно управлять. На портале GitHub, в разделе Отказ работы Kubernetes, уже накопилось целое собрание всевозможных леденящих кровь баек о Kubernetes от детской страшилки про обвал DNS-сервера до истории ужасов про каскадный отказ распределенных систем.
Kubernetes as a Service и Managed Kubernetes – что это такое, и в чем основные отличия?
Несмотря на то, что переход на 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:
| Функция |
Kubernetes as a Service (Cloud PaaS) |
Managed Kubernetes (Professional services) |
|---|---|---|
| Развертывание и преднастройка ВМ | ||
| Настройка ОС | ||
| Настройка сетевых параметров | ||
| Настройка безопасности кластера | ||
| Обновление ОС и кластера Kubernetes | ||
| Возможность развертывания кластера в нескольких AZ (Availability Zones) | ||
| Автоматическое развертывание «по кнопке» | – | |
| Помощь в проектировании и создании кастомных конфигураций кластера Kubernetes и прикладного ПО (мониторинг, логирование, инструменты СI/CD и др.) | – | |
| Развертывание кластера с преднастроенным прикладным ПО под ключ (мониторинг, логирование, инструменты СI/CD и др.) | – | |
| Тонкая интеграция прикладного ПО (мониторинг, логирование, инструменты СI/CD и др.) | – | |
| Создание кастомной автоматизации под проект на базе Terraform, Ansible, Helm, Puppet и др. | – | |
| Расширенная техническая поддержка кластера и смежных компонентов (выделенная команда: менеджер проекта, архитектор, DevOps-инженеры, сетевые инженеры, инженеры защиты ИТ-инфраструктуры) | – |
