Если вы активно используете 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 будет использоваться сгенерированный ранчером самоподписанный сертификат. Для тестов более чем достаточно. Однако, если есть возможность, то лучше подкинуть свой проверенный сертификат:

# <CERT_DIRECTORY> - путь на текущей машине, где лежат сертификаты.
# <FULL_CHAIN.pem> - имя файла с полной цепочкой сертификатов.
# <PRIVATE_KEY.pem> - имя файла ключа, которым зашифрован данный сертификат.
docker run -d --restart=unless-stopped \
  -p 80:80 -p 443:443 \
  -v /opt/rancher:/var/lib/rancher \
  -v /<CERT_DIRECTORY>/<FULL_CHAIN.pem>:/etc/rancher/ssl/cert.pem \
  -v /<CERT_DIRECTORY>/<PRIVATE_KEY.pem>:/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, управление проектами, чат и т. п.), то можно использовать существующий кластер kubernetes и развернуть Rancher на нём, с помощью helm chart'а. Кластер, в который будет установлен сервис автоматически появится в списке как local , и им так же можно будет управлять. Если этот кластер работает на базе k3s или rke/rke2, то вам тоже будет доступно обновление самого кластера.

Управление

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

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

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

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

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

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

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

Драйверы

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

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

Так же можно добавить свой через интерфейс, указав путь до бинарника 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.