Kubernetes на сковородке: готовим самые вкусные кластеры

Почему Kubernetes?

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

Привет! Меня зовут Игорь Титов, я Product Lead системных инженеров в Garage Eight. В этой статье расскажу, что такое контейнеризация, как с ней помогает Kubernetes и почему важно уметь правильно его готовить.

Контейнеризация в 2024 году

Возможно, некоторых из вас удивит выбор контейнеризации в наши дни, но у её использования есть целый ряд преимуществ.

• Повторяемость. Один маленький контейнер можно копировать многократно, и при этом он останется ровно таким же, каким был изначально.

• Масштабируемость. Правильно приготовленный контейнер с окружением можно масштабировать на сотни и тысячи экземпляров

• Легковесность. Контейнеры могут быть довольно простыми, и потому весить совсем немного.

• Изолированность. Контейнеризация, реализованная в Linux, позволяет добиться высокой изолированности контейнера от хостовой операционной системы

• Вычислительная плотность. При правильном расположении контейнеры позволяют достигнуть рационального использования имеющихся ресурсов.

• Управляемость. Контейнеризированные решения удобно повторять и редактировать даже спустя годы.

Что такое Kubernetes и почему это наш выбор

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

Когда речь заходит о контейнеризации, Куберу нет равных. Почему?

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

• Является бесплатным. Всегда приятно иметь возможность работать с качественным ПО и при этом не оставлять ежегодно круглую сумму за его эксплуатацию. 

• Поддерживается Google. Кубер имеет открытый исходный код и  поддерживается Гуглом, так как изначально им и был создан.

• Имеет самое большое коммьюнити. Систему применяет и поддерживает наибольшее количество специалистов по всему в сравнении с другими подобными решениями.

Альтернативы Куберу

Когда я говорю о конкурентах системы, я беру это слово в кавычки: по факту ни один из них не имеет такого же полного ряда функций. Почетного упоминания заслуживают Docker Swarm, OpenShift, Nomad и Cycle, которые во многом похожи на Кубер, но не равны.

Помимо управления контейнерами привычным способом, также существует более продвинутый вариант — через системы без серверов (serverless). Как это работает: я могу запустить приложение в контейнере, но без специфической среды, предоставив его облачному провайдеру, который сам производит все необходимые манипуляции. Среди примеров таких ПО: AWS Amazon Fargate, Google Cloud Run, Microsoft Azure Container Instances, Yandex Serverless Containers и др.

Kubernetes через призму кулинарии

Несмотря на то, что у нас как бы нет выбора, работать с Kubernetes или нет, у нас есть выбор, с чем его есть и как готовить. Для упрощения понимания принципов его работы я часто буду прибегать к сравнению с кулинарией. Мне просто — вам вкусно 🙂 

Приготовление и хранение

Существует несколько способов работы с Кубером:

1. Его можно  разложить на «железные сервера» (hardway): устанавливаем операционную систему и разворачиваем в ней нашу систему. Это может выйти сложно и дорого, но будет стоить потраченных усилий. 

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

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

4. Наконец, самый простой способ — softway for softway — приложение, в которое мы  передаём конфигурацию кластера. Так я могу управлять множеством кластеров и орекстировать их на свой вкус.

Комбинирование вкусов: prod and dev

В зависимости от задачи я могу сочетать различные способы поднятия кластеров. 

Например, на этапе продакшн можно использовать Hardway Bare Metal с большими вычислительными мощностями, если приложению требуется работать близко к железу. А на этапе девелопмента уже можно перейти к чему-то попроще, как к RKE на виртуальных машинах KVM. 

Другим вариантом является применение managed-кластеров, управляемых через Terraform и в деве, и в проде.

Разумеется, можно пойти наиболее легким путем: отказаться от Кубера, пользоваться ванильным Docker’ом и управлять им через Ansible, но это всё равно, что пользоваться палкой-копалкой в наши дни — только, если вы в глухом лесу без инструментов.

Творческие эксперименты

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

Среди удобных для экспериментов систем выделю следующие:

• Docker Desktop позволяет добавить и комбинировать сразу несколько контейнеров, например, с базой данных, бэком, фронтом и т.д. Там приложение будет крутиться, и я буду иметь возможность видоизменять его.

• Minikube —  самое популярное решение, стабильно работающее и имеющее всё необходимое — мини Кубернетес

• Kind и Colima выделяются тем, что они единственные из списка позволяют создать кластер на операционной системе от Apple.

• И другие: Rancher Desktop, K3d, MicroK8S, K0s, k3s — имеют свои преимущества в виде легковесности инсталляции Kubernetes, или декларативности конфигурации и т.д.

Щепотка магии

Иногда работа с Кубером требует не просто экспериментального подхода, а колдовских скиллов. Платформы Okteto, Garden и Telepresence дают возможность пробрасывать локальные файлы в Kubernetes-кластер. Таким образом можно разрабатывать в удаленном кластере, но делать это локально.

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

Непрерывное приготовление (CI/CD)

Когда код уже написан и проверен на тестовом кластере, его нужно доставить в какую-нибудь среду после мёрджа, например в контур интеграционного тестирования или препрод. В этом мне помогут ArgoCD, Flux, Gitlab CI или Jenkins X.

Как готовят в Garage Eight

В нашей компании применяются 3 основных варианта «готовки» Кубера:

• Простой stateless Kubernetes-дев;

• Надежный stateless Kubernetes-прод;

• Удобная «кухня»-инфраструктура.

Простой Stateless Kubernetes-дев

Это наш любимый вариант работы с Kubernetes, потому что он не требователен в плане хранения данных и затрат на них.

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

Как правило, такие кластеры не обслуживаются, то есть, если что-то идет не по плану, мы просто пересоздаём их, а не ищем причину поломки. Для управления используется Rancher, а для управления им — Terraform. 

Для оценки эффективности созданного Кубернетес-окружения и дев-инфраструктуры мы использем различные показатели качества инфраструктуры:

• типичный SRE-путь с применением подходящих метрик, индикаторов и SLO, даже некоторый SLA через ключевые результаты;

• наш собственный инструмент Easy Peasy Dev — система, которая позволяет любому разработчику отследить состояние как своего стенда в виде виртуальной машины, так и Кубернетес-кластера, в котором работает его приложение.

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

Возможности разработки 

Благодаря нашему подходу к работе с Kubernetes, появляются гибкие варианты процесса разработки:

• Локальная и/или в локальном кластере (на базе упомянутых систем по типу Docker Desktop, Minikube и т.п.);

• локальная, но в удаленном кластере (на базе Okteto);

• CI/CD в удаленный кластер (на базе чистого Gitlab CI или в комбинации его с собственным сервисом деплоя).

Примеры кодов

Посолить по вкусу Rancher’ом

Уже не раз в статье я упоминал платформу для менеджмента контейнеров Rancher — слишком она хороша в качестве приправы к основному Кубернетесу. Дело в том, что с ним можно создавать самые различные кластеры, как Managed из коробки для популярных облаков, так и на базе  Docker Node driver. При помощи него мы можем создать кластер из виртуальных машин почти любого облака.

Кроме того, Rancher прост в управлении, имеет понятный UI и поддерживает Terraform. Последнее особенно ценно, так как мы постоянно работаем с Terraform из-за его умения сокращать время восстановления и предоставлять полную структуру проектов.

Надежный Stateless Kubernetes-прод

Поскольку наш продукт распространяется по всему миру, то и кластера вместе с их облаками являются гео-распределенными. Мы используем кластера провайдеров, такие как GCP, Alibaba Cloud, AWS и др.

Мы построили надежную сетевую инфраструктуру, которая полностью управляется из кода и даже внедрение изменений проходит через ее виртуальную среду, построили надежную  инфраструктуру хранения и обработки данных.

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

Путь компании — создавать разработки, которые облегчают жизнь. Так что и здесь не обошлось без собственных сервисов. Мы используем свои сервисы для:

• отслеживания качества деплоя;

• прогнозирования нагрузки на инфраструктуру (на основе машинного обучения);

• управления Horizontal Pod Autoscaler;

Так же мы не забываем про сервисы типа Cluster Autoscaler от GCP.

Horizontal Pod Autoscaler

На нашем сервисе управления кластерами хотелось бы остановиться немного подробнее. Мы написали сервис, который готовит метрику для Horizontal Pod Autoscaler.

HPA смотрит на эту метрику, которая определяется на основе:

• Оценки нагрузки на балансировщиках;

• Расписания;

• Прогнозирования;

• API (вручную).

 Наш сервис дает возможность вовремя заметить, что на инфраструктуру поступает повышенная нагрузка и сообщить Horizontal Pod Autoscaler, что пора скейлиться в большую сторону или вообще заранее спрогнозировать такую нагрузку. Такой проактивный подход значительно упрощает процесс менеджмента ситуации. 

Авторский рецепт Kubernetes 

В конце концов, мой личный путь, путь команды и наши подходы к созданию Кубера можно разложить на 3 этапа:

• Снижение стоимости разработки через простое создание и восстановление Kubernetes-кластеров.

• Улучшение возможности и интерактивной непрерывной разработки через локальную, Okteto и Gitlab CI.

• Быстрое восстановление даже на этапе продакшн, где наш основной помощник это IaC (инфраструктура как код).

Кулинарные советы по Kubernetes

Я сам обожаю готовить Kubernetes, и вам советую. Главное помнить, что это продукт, который нужно уметь готовить правильно. Он особенно вкусен, когда его готовят к качественной инфраструктуре, не переперчивают stateful’ом, но при этом достаточно подсаливают stateless’ом.

Перед употреблением в пищу просто залейте ваш Кубер метриками и готово, bon appétit!