Гуёвая автоматизация управления кластерами09.03.2023 10:17

Если вы активно используете kubernetes в своей инфраструктуре, при этому у вас небольшая команда, или она состоит в основном из разработчиков, то у меня к вам вопрос: ну как вам — стала жизнь легче? Наверное те, кто используют managed-решения в некотором роде покивают головой. Продавцы этих решений скажут «да!», с особенно довольным лицом, а бизнес, пуская скупую слезу, просто согласятся с большинством (ну бизнес же растёт).

Тот инструмент, про который я сегодня хочу рассказать подходит в большей степени для самого что ни на есть микросервисного и девопснутого подхода, когда команды разработчиков имеют необходимую и достаточную абстракцию для самостоятельного управления кластерами, при этом команда эксплуатации сохраняет контроль за всем. Речь пойдёт про Rancher и около стоящие продукты.

Анализ рынка

На рынке сейчас есть несколько наиболее популярных (по слухам) платформ, которые решают примерно один и тот же набор задач:

• OpenShift — обладает особой популярностью благодаря поддержке от RedHat. Не возьмусь про него подробно писать, потому что с ним не работал (видел, даже тыкал всякое, но не использовал). Предоставляет как и другие всё необходимое, чтобы развернуть кластер и управлять контейнерами. Говорят, удобный во многом. Есть целые секты.

• Deckhouse — по сути платформа, которая позволяет пользователям развернуть ванильный куб с обвязкой в виде стандартного набора приложений и некоторого гуя. Кластеры можно развернуть в публичных облаках (AWS, Azure, GCP, Yandex Cloud, который считается киллер-фичей), частных (VMWare и OpenStack) и, конечно же, на голом железе. На сайте они позиционируют продукт как NoOps.

• Rancher — то же самое, что и Deckhouse, только вышел раньше, с некоторого времени принадлежит Suse, имеет шире поддержку по облакам (использует для управления виртуалками механизм docker-machine-driver) и умеет управлять managed-кластерами (EKS, GKS и т.п.). Одна из особенностей — все плагины доступны во Free версии, включая Istio, безопасность и т.п. Дословный перевод — владелец ранчо (большой сельскохозяйственный участок, где очень часто надо разгребать г… бардак).

Нельзя сказать, что какой-то продукт лучше или хуже. На самом деле, если приглядеться, то можно увидеть, что у каждого есть своя сильная черта. Я продвигаю Rancher по двум причинам. Во-первых, я с ним работал, относительно хорошо знаю его сильные и слабые стороны. Когда я искал инструмент, который бы решал мои задачи, то выбора особо и не было. А во-вторых, я наивно верю в силу Open Source и уверен, что, приложив немного усилий, я смогу адаптировать этот инструмент под любой облачный вендор (мощная система плагинов решает).

Забавный факт

Под капотом

Чтобы понять — откуда мощь, нужно заглянуть «под капот» платформы, и там обнаружится, что и этот GUI обёртка над CLI. По классике жанра, хороший интерфейс делает более привлекательным и более понятным мощный набор инструментов для деплоя и управления кластерами kubernetes.

RKE

Rancher Kubernetes Engine — первое поколение инструментария для решения проблемы установки кластера в различных средах. Для тех, кому это важно, rke использует docker практически везде. С помощью докера на сервер или вируталку доставляются все компоненты, а так же сами контейнеры подов. Возможно, именно поэтому для старта кластера требуются слегка большие мощности (может не взлететь на вирутуалке »2 ядра, 2 гига»). Но, преимуществ так же хватает: знакомый инструментарий, возможности docker-machine и т.п.

Этот инструмент отлично подходит для GitOps, потому что он берёт конфиг, на основании него формирует state-файл, в котором описывает что, где и как развернул, и конфиг для kubectl. Так же легко интегрируется в CI, как и любая другая утилита, не требующая отдельного сервиса. Жирный минус в том, что версии кластера сильно отстают от upstream, но это не всех волнует.

Примеры конфигураций

cluster_name: "rke-test"
ssh_agent_auth: true
ssh_key_path: "~/.ssh/rke-test.pem"
# kubernetes_version: v1.10.3-rancher2

nodes:
 - address: 172.16.160.165
   internal_address: 172.16.160.165
   user: rke
   ssh_key_path: "~/.ssh/default.pem"
   role:
    - controlplane
    - worker
    - etcd

ingress:
   provider: nginx
   network_mode: hostNetwork

cluster_name: "rke-test"
ssh_agent_auth: true
ssh_key_path: "~/.ssh/rke-test.pem"
# kubernetes_version: v1.10.3-rancher2

nodes:
 - address: 172.16.160.165
   internal_address: 172.16.160.165
   user: rke
   ssh_key_path: "~/.ssh/rke-test-master.pem"
   role:
    - controlplane
    - etcd

- address: 172.16.160.167
  internal_address: 172.16.160.167
  user: rke
  ssh_key_path: "~/.ssh/rke-test-worker.pem"
  role:
   - worker

- address: 172.16.160.168
  internal_address: 172.16.160.168
  user: rke
  ssh_key_path: "~/.ssh/rke-test-worker.pem"
  role:
   - worker

ingress:
   provider: nginx
   network_mode: hostNetwork

K3S

Облегчённая версия кластера, где в качестве хранилища состояния кластера может выступать некоторый набор SQL баз. Это всего один бинарь, который содержит в себе весь необходимый набор компонентов, чтобы проинициализировать кластер. Настолько легковесный, что очень часто используется DIY-решениях на базе «малинки» и прочих одноплатников. Более подробно можно почитать в моём предыдущем посте.

RKE2

Rancher Kubernetes Engine второго поколения взял лучшее из предыдущих двух миров. Но в большей степени это полноценный «сын маминой подруги» для k3s. Процесс установки и развёртывания практически идентичен. Сами разработчики позиционируют его как решение для государственных учреждений, с особым отношением к безопасности и уязвимостям.

Это три наиболее значимых инструмента, которые используются или подразумевают использование внутри самого Rancher’а. Первый используется непосредственно внутри для деплоя и масштабирования кластеров. Второй подразумевает использование для решения проблемы отказоустойчивости самой платформы. Третий предназначен для стабильных production-кластеров. Все вместе они позволяют строить гибридные и не очень кластера.

Rancher

Взято с официальной документации

Сам сервер Rancher это самостоятельный сервис, который может быть развёрнут как простой контейнер в docker (или аналоге), так и в уже готовом кластере. Ресурсов для одного контейнера он потребляет «будь здоров», но вместе с этим помимо создания и масштабирования кластеров, сервис предоставляет такие возможности как:

• Аутентификация (я пользовался только встроенной и Active Directory).

• Управление политиками безопасности.

• Контроль доступа к кластерам.

• Набор инструментов для управления приложениями и проектами.

А чтобы прям совсем было удобно, они добавили возможность развернуть по кнопке сервисы и управлять Service mesh (Istio), мониторингом (Grafana+Prometheus), алертами, логами и даже Continuous Delivery (Fleet) запихнули. Эти компоненты не являются обязательными и можно настроить свои сервисы. Однако именно с этими интегрирован сам интерфейс. Это не исчерпывающий список сервисов (есть решение по безопасности NeuVector+CIS, хранилищам Longhorn, и т.п.), но важно то, что можно заточить практически любое расширение с помощью системы плагинов.

Установка

Вариантов установки всего два: одна машина или кластер kubernetes. В документации на сайте описаны примеры для некоторых облачных провайдеров, но всё сводится к одному — helm chart. Самое главное, чтобы к кластеру и от сервера Rancher был доступ к агенту.

Скриншот из официальной документации

Такая архитектура позволяет размещать сам управляющий кластер в закрытом и защищённом контуре (спокойно работает за NAT) и ограничить доступ к кластеру.

docker run -d --restart=unless-stopped \
  -p 80:80 -p 443:443 \
  -v /opt/rancher:/var/lib/rancher \
  --privileged \
  rancher/rancher:stable

В таком варианте сервер поднимется на стандартных HTTP/HTTPS портах и для TLS будет использоваться сгенерированный ранчером самоподписанный сертификат. Для тестов более чем достаточно. Однако, если есть возможность, то лучше подкинуть свой проверенный сертификат:

#  - путь на текущей машине, где лежат сертификаты.
#  - имя файла с полной цепочкой сертификатов.
#  - имя файла ключа, которым зашифрован данный сертификат.
docker run -d --restart=unless-stopped \
  -p 80:80 -p 443:443 \
  -v /opt/rancher:/var/lib/rancher \
  -v //:/etc/rancher/ssl/cert.pem \
  -v //:/etc/rancher/ssl/key.pem \
  --privileged \
  rancher/rancher:stable \
  --no-cacerts

или для тех, у кого сервер будет торчать наружу голым задом открытыми портами:

docker run -d --restart=unless-stopped \
  -p 80:80 -p 443:443 \
  -v /opt/rancher:/var/lib/rancher \
  --privileged \
  rancher/rancher:stable \
  --acme-domain мой.потрясающий.домен

Есть и другие варианты, например, использовать терминирующий прокси, который решит проблему сертификатов на своей стороне.

В моей интерпретации установки, по сравнению с официальной документацией, можно заметить пару нюансов — я всегда монтирую директорию с данными и использую канал stable. Без этого вы просто не сможете обновить образ, потому что все данные о кластерах исчезнут, а на нестабильный канал слишком часто обновляется. А так всё сводится к тому, чтобы спулить свежий образ, остановить контейнер, удалить его и запустить команду по новой. Если сервер, на котором вы всё это проделываете достаточно надёженый и мощный, активно бэкапится и имеет резервное питание, то для относительно небольшого количества кластеров такого варианта будет достаточно.

Насколько мощный сервер/виртуалка?

Если же мы уверены, что хотим использовать большое количество кластеров или хотим так же задействовать текущие мощности для каких-то иных задач (например, дополнительно развернуть внутренние сервисы git, управление проектами, чат и т.п.), то можно использовать существующий кластер kubernates и развернуть Rancher на нём, с помощью helm chart’а. Кластер, в который будет установлен сервис автоматически появится в списке как local, и им так же можно будет управлять. Если этот кластер работает на базе k3s или rke/rke2, то вам тоже будет доступно обновление самого кластера.

Интересный факт

Управление

После того как мы развернули сервис, на этом интересное не заканчивается. Что можно делать с кластерами:

• Разворачивать новые с помощью RKE и различных Node Driver’ов или с помощью запуска агента в докере (команда генерируется в интерфейсе). Так же доступны плагины для запуска managed-решений (т.е. GKS, который сам по себе кластер, ECS, который даже не kubernetes как таковой).

• Обновлять версию kubernetes кластера и прочее обслуживание.

• Подключать репозитории helm и устанавливать оттуда приложения в кластеры.

• Управлять всеми сущностями контейнеров (Workaload=Deployment/DaemonSet, Service, Ingress и т.п.).

• Подключить необходимые плагины и расширения.

• Управлять доступом и пользователями.

Драйверы

Наверное, это самая крутая штука в самой платформе. После установки доступно сразу несколько различных драйверов:

Доступные драйверы

Драйверы управляемых кластеров.

Кусочек списка доступных драйверов для вируталок (там ниже есть VMWare)

Так же можно добавить свой через интерфейс, указав путь до бинарника docker-machine-driver.

Очень часто люди спрашивают за Proxmox VE driver. Мы с командой в своё время допилили до ума его так, что он проверенно работает. По аналогии можно написать свой под любые нужды. Главный принцип в том, чтобы драйвер предоставил нужную информацию Rancher’у о хосте и параметрах подключения. Дальнейшая работа осуществляется в докере.

Для особо искушённых, можно реализовать собственный драйвер управляемого кластера (т.е. не самих виртуалок, а уже управляемого кластера). Например, очень актуально написать драйвер для местных Yandex, VK, MTS, Selectel и т.п. Пишется всё на Go, и есть хороший пример для Google облака. Собранный бинарь просто загружается через UI на сервис и предоставляет интерфейс создания/управления.

Обслуживание и обновление

Базовые инструменты обслуживания, которые даёт Rancher:

• Получение всех необходимых конфигурационных файлов.

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

• Управление нодами (всякие метки, параметры, drain и прочее).

• Снэпшоты etcd (можно в S3).

• Бесшовное обновление (можно настроить стратегию обновления).

• Шаблоны RKE (какая версия кластера, параметры и т.п.)

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

Приложения и расширения

Насколько всё просто

Один из чартов

Установка приложений идёт и так же можно посмотреть лог

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

В тех случаях, когда готового чарта нет, контейнер вместе с сервисом и ингрессом можно развернуть руками, просто накликав нагрузку:

Ручной труд

Даже с объяснением для «особенных»

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

После создания деплоймента нужно создать сервис

Тут тоже создаётся осмысленный объект

И так далее…

Стоит отметить, что расширения находятся в тех же самых репозиториях, что и приложения. Чтобы написать своё расширение, достаточно заглянуть в репозитории Rancher’а.

Управление доступом и пользователями

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

Создание пользователя в платформе

Уже видно, что можно настраивать доступ ко всем частям платформы по отдельности

Добавление пользователя в кластер

Итог

Когда мы управляем одним или двумя кластерами выделенной командой эксплуатации, то в целом инструмент не имеет значения. Во многих случаях, кластер может быть managed от вендора, и это покроет все необходимые задачи. Но когда мы хотим дать возможность разработчикам и командам самим управлять своими кластерами, чтобы распределить нагрузку, то нужен такой инструмент, с которым справится даже джун. У ранчера хорошие шансы заменить как таковые managed-кластеры со множеством разных интерфейсов у разных провайдеров на единый удобный UI. За счёт того, что у него очень гибкая система плагинов и полностью открытая лицензия, можно небольшой командой поддерживать настоящий зоопарк разных вендоров незаметно для пользователей продукта (команды каждого продукта).

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

Пусть вас вдохновляет многообразие Open Source на написание плагинов и использование Kubernetes без страха.

P.S.: Всех с окончанием сезона Кубера на Хабре! Целых две статьи по продуктам Rancher Labs написаны из любви к продукту. Дальше буду писать про Ansible.

© Habrahabr.ru