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

Не я один подметил это, этот факт подсвечен во многих материалах по K8s. Например, вот: 

This highly composable, recursive architecture makes Kubernetes not just a container orchestrator but a universal control plane for declarative systems, or in other words a Cloud Operating System.

Источник

Высокомодульная рекурсивная архитектура делает kubernetes не просто оркестратором контейнеров, но и универсальным управляющим контуром для декларативных систем, иными словами, настоящей Облачной Операционной Системой.

Это позволяет нам работать на более высоком уровне абстракции, решать больше проблем и эффективнее закрывать текущие задачи. К сожалению, у любого повышения уровня абстракции есть обратная сторона, которая выражена в статье известного Joel Spolsky, а именно, — «абстракции текут». В K8s есть множество движущихся частей: разные компоненты control plane, свой DNS‑сервер, механизмы расширения через плагины. Действительно, ведь, в базовом kubernetes нет драйвера хранилища (CSI), а кому нужна система, которая не умеет хранить данные? Для подачи трафика на нагрузки, запущенные в kubernetes, тоже нужен отдельный компонент — ingress‑контроллер.

И так для всего. Каждый перечисленный выше компонент существует в нескольких реализациях. Например, основных сетевых плагинов есть минимум 5 штук (Calico, Cilium, kube-router, kube-ovn, flannel) и есть еще целая плеяда менее известных. В этом многообразии легко потеряться неискушенному пользователю (и почитать про критерии выбора можно тут). Более того — возникает проблема совместимости между разными версиями различных компонентов. Именно поэтому и появляется необходимость делать сборку, которая будет состоять из стабильных компонентов, и настройки которых будут совместимы друг с другом. Это не единственная вещь, которую предоставляют дистрибутивы. Дополнительно они могут иметь свой удобный инсталлятор, комфортный и надежный процесс обновления. Коммерческие дистрибутивы идут с пакетами поддержки — что означает, что в случае вопросов или проблем пользователь не останется с ними наедине, а сможет получить квалифицированную помощь и их решение.

Может, всё-таки облако?

Возникает вопрос — ну, хорошо, а может, все-таки пойти в облако (например, Яндекс, Селектел или Таймвеб) и взять там kubernetes как услугу? Так называемый “managed kubernetes”. И тут всплывают нюансы. Заключаются они в том, что облако как правило предоставляет самый базовый, голый kubernetes, в котором даже не факт, что будет вышеупомянутый ingress-контроллер. Вполне вероятно, что не будет ни мониторинга, ни сбора логов. Не будет никаких механизмов безопасности. А набор настроек, которые будут доступны при создании кластера, скорее всего, будет очень ограничен и, по сути, сведен к версии кластера и размеру рабочих узлов. Не говоря уже о том, что не все компании могут себе позволить миграцию в облако по различным соображениям — например, обработка персональных данных. Последний аргумент против облака — это цена. Те же вычислительные мощности можно приобрести раза в три дешевле, если подойти с умом: в нашем мире нет чудес, и облачный провайдер — не благотворительная организация, а вполне себе нацелен на получение прибыли. 

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

Начнем с установки

Первая вещь, которую мы при этом обнаруживаем, — Штурвал не является open-source-решением. Под open-source я понимаю не бесплатность продукта, а возможность скачать исходные коды, ознакомиться с ними в любой момент времени. Возможно, собрать из них бинарные артефакты и запустить продукт локально, если лицензия позволяет. А в случае Штурвала помимо коммерческой версии существует так называемая Community Edition, которую можно бесплатно использовать с определенными ограничениями. Лично для меня как для инженера исходный код продукта в доступности — это важный показатель. Это сильно повышает доверие к продукту, так как можно всегда посмотреть, как он работает изнутри, произвести сравнение разных версий, а не опираться на историю изменений или описание релизов, которые подготавливаются разработчиком. 

Для того чтобы начать работу и тестирование, необходимо получить лицензионный ключ для Community Edition. Он запрашивается на странице продукта или через телеграм-бота. Опять же, лично я осуждаю такие маркетинговые приемы, так как они напоминают механики сбора персональных данных пользователей. А как они будут использоваться в дальнейшем — большой вопрос.

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

Я человек достаточно любопытный, поэтому формат лицензии мне напомнил JWT. Я сразу же вставил ключ в декодер и получил:

Видим, на какой продукт выписана лицензия, (отмечаем для себя, что вероятно, есть возможность в уже существующую установку на базе Community Edition воткнуть коммерческую лицензию и разблокировать какие-то возможности), набор фич и ограничений (например, в Community Edition доступно 10 узлов), имя пользователя, на которого лицензия выписана, и самое главное — время окончания действия лицензии — 11 июня 2075 года. Не думаю, что хотя бы одна установка доживет без какого-либо обслуживания до этой даты, так что фактически эта лицензия «вечная», и волноваться о ее истечении не придется.

Учитывая, что лицензии — это JWT, у меня есть большое подозрение, что они не отзываемые. То есть если кто-то случайно поделится лицензией в интернете, то ее можно будет использовать несколько раз для разных кластеров. Наверное, так делать не следует. 

Утилита stc

В официальной документации Штурвала сообщается, что для установки платформы предназначена утилита stc. К сожалению, она существует в бинарных файлах только для операционных систем Linux и Windows. С Mac OS ее не запустить. Думаю, что можно было бы запаковать ее в контейнерный образ. Я избегаю словосочетания «докер образ», так как docker сделал великое дело для развития индустрии в виде стандарта OCI, который уже сильно шире только лишь образов, да еще и появилась целая плеяда различных контейнерных рантаймов: containerd, cri-o и множество других.

В любом случае, очень здорово, что такая утилита есть. Мне это напоминает позитивный опыт установки кластеров Kubernetes лет 6 тому назад, когда наиболее простым способом получить работоспособный кластер было использование утилиты rke от Rancher. 

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

wget -O /usr/local/bin/stc https://public.shturval.tech/stc-2.11.0 && \
  sudo chmod +x /usr/local/bin/stc

К сожалению, первый опыт установки Штурвала прошел неудачно. Потому что кто же читает документацию! А надо внимательнее смотреть в системные требования. Моя ошибка была в том, что я наивно использовал Ubuntu 24.04. Казалось бы, а что такого, это же актуальная версия LTS-дистрибутива Ubuntu. Но нет, не вышло. По крайней мере утилита дает адекватное сообщение об ошибке, из которого сразу ясно, в чем дело:

Установка в минимальном режиме. Значения флагов enabled-system-services и disabled-system-services игнорируются.

Выполняется установка модуля управления конфигурацией узлов
Пакет /opt/shturvald_2.11.0_amd64.deb успешно установлен
Error: ошибка инсталляции кластера ошибка проверки узлов: ошибка получения информации об узлах: 1 error occurred:
	* ошибки проверки конфигурации узла: 1 error occurred:
	* узел 212.233.93.199 - ошибка проверки операционной системы ubuntu, неподдерживаемый релиз noble операционной системы ubuntu

Считаю, что список поддерживаемых дистрибутивов Штурвала — жирный минус. С одной стороны, в нем есть куча отечественных дистрибутивов. Это может быть очень актуально для российских корпоративных клиентов. Но отсутствие последней версии Ubuntu и других популярных дистрибутивов вроде openSUSE (или подставьте свой любимый, но только не Arch / NixOS :-)) очень расстраивает.

Еще я обратил внимание, что в документации есть определенные недостатки. Например, инструкции по синхронизации времени на операционных системах считываются не как набор альтернатив по каждому из типов операционной систем, а скорее как набор шагов, так как список пронумерован. В документации еще используется устаревшая терминология: такая как «master-узел». В современном K8s уже давно перешли на политически и гендерно-нейтральную терминологию, например, «control plane». Думаю, что и Штурвал тоже должен придерживаться аналогичной позиции.

Последнее — в документации полностью игнорируется английский язык. Как и в ошибках от утилиты. Я не могу сказать, что я не патриот или отрицаю русский язык. Но исторически так получилось, что локаль по умолчанию — английский язык. И так как IT-индустрия — международная, то и терминология по умолчанию тоже англоязычная. И чтобы понимать вещи одним образом и считывать тоже однообразно — считаю, что англоязычные документация и сообщения из утилиты были бы очень желательны.

Понятно, что часто производители ПО пишут документацию по остаточному принципу, так как в приоритете сам продукт. Но, учитывая, что документация является лицом продукта, и это именно то, с чем пользователь сталкивается и использует (по крайней мере, на первых порах) очень часто —  важно обращать на это внимание. Лично у меня был огромный позитивный опыт, например, от взаимодействия с официальной документацией на сам проект kubernetes или на документацию от проектов OKD/OpenShift. Степень детализации документации этих проектов такая высокая, что ее можно использовать даже как учебное пособие по продукту.

Двигаемся дальше

После замены операционной системы на Ubuntu 22.04 установка пошла успешно:

Установка в минимальном режиме. Значения флагов enabled-system-services и disabled-system-services игнорируются.

Выполняется установка модуля управления конфигурацией узлов
Пакет /opt/shturvald_2.11.0_amd64.deb успешно установлен
Имя кластера: production
Адрес Kubernetes API: 95.163.250.43:6443
Ingress: --ingress=95.163.250.43.sslip.io
Ingress VIP: 
Ingress external LB: true
Kubernetes API external LB: false
Конфигурация Controlplane: Отдельный узел
Расширенные параметры информационной безопасности: выкл.
Используемый репозиторий: r.shturval.tech
Версия платформы Штурвал: 2.11.0
Узлы:
Роль       Имя узла                       Адрес                Операционная система
master     ubuntu-std3-6-8-80gb           95.163.250.43        ubuntu

Для настройки внешнего балансировщика HAProxy можете использовать пример конфигурации /root/.production/haproxy.cfg

Настройка узлов
Проверка /etc/machine-id
Проверка /etc/machine-id завершена успешно
ubuntu-std3-6-8-80gb          успешно   
Инициализация первого узла кластера ubuntu-std3-6-8-80gb успешно
Добавление узлов в кластер
Выполняется попытка установить лейблы для worker-узлов кластера.
Лейблы для worker-узлов успешно установлены.
Установка CNI...
Может занять несколько минут.

CNI успешно установлен
Установка системных компонентов кластера...
Может занять несколько минут.

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

Выполняется попытка обновить machines
Установка системных компонентов кластера завершена успешно.

Выполняется установка системных сервисов. Может занять несколько минут

Системные сервисы установлены. Ожидание готовности...

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

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

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

https://front.--ingress=65.109.171.186.sslip.io

Понятно, что в утилите не хватает валидации параметров. 

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

./stc-2.11.0 remove --ssh-user=ubuntu --ssh-private-key=/root/1.pem cluster
Error: ошибка удаления кластера ошибка создания клиента подключения к кластеру: ошибка создания конфигурации для подключения к кластеру: ошибка получения bootstrap-узла для инициализации кластера

Тут уж стало лень разбираться, что же пошло не так, поэтому я попросту взял еще одну чистую виртуальную машину и начал с нуля. Честно говоря, у меня никогда с первого раза ни один IT-продукт не заработал. Я всегда натыкался на какие-то проблемы, но здесь очень важно, чтобы сами IT-продукты помогали устанавливать их и подсказывали, что не так. И в случае проблем реализовывали принцип fail-fast. Если что-то пошло не так — или пытаемся включить автоматику, или сразу падаем с подробным и внятным сообщением об ошибке. 

Для установки кластера я в конечном счете выбрал вариант «Команда для запуска инсталляции на 1 Master-узле с внешним балансировщиком для API-сервера и Ingress, самоподписными сертификатами в открытом контуре» из возможных сценариев установки. 

При этом видно, что документация местами сыровата.  

Например, ключи командной строки перечислены неверно. Не с двумя dash, а с одним. Это явная ошибка, так как утилита в консоли выдает все ключи с лидирующими --, да и в предыдущей версии документации команда была указана верно. 

В процессе набирания этих параметров я устал — все аргументы содержат в себе кучу символов. Во множестве других утилит (например, aws-cli, kubectl, клиент Yandex.Cloud и многие другие) для удобства пользователей реализовано автодополнение. Хоть и установка кластера — не так часто используемая операция, но автодополнение ускоряет ввод команд и самое главное — страхует от опечаток в процессе переноса команд из документации. И интересно, что действительно есть соответствующая субкоманда для утилиты stc:

stc completion bash

В конечном счете у меня получилась такая команда для установки кластера:

stc install management --license="........" \
  --cluster-name="test" \
  --ssh-user=root \
  --ssh-private-key=/root/.ssh/id_rsa \
  --use-external-kubeapi-lb=true \
  --api-endpoint=65.109.171.186.sslip.io \
  --timezone=Europe/Moscow \
  --use-external-ingress-lb=true\
  --master-nodes=65.109.171.186 \
  --ingress=65-109-171-186.sslip.io \
  --skip-check \
  --ntp-servers=0.ru.pool.ntp.org,1.ru.pool.ntp.org \
  --minimal=true

(лицензионный ключ я вырезал)

Команда выдала такой выхлоп:

Установка в минимальном режиме. Значения флагов enabled-system-services и disabled-system-services игнорируются.
Выполняется установка модуля управления конфигурацией узлов
Имя кластера: test
Адрес Kubernetes API: 65.109.171.186.sslip.io:6443
Ingress: 65-109-171-186.sslip.io
Ingress VIP: 
Ingress external LB: true
Kubernetes API external LB: true
Конфигурация Controlplane: Отдельный узел
Расширенные параметры информационной безопасности: выкл.
Используемый репозиторий: r.shturval.tech
Версия платформы Штурвал: 2.11.0
Узлы:
Роль       Имя узла                       Адрес                Операционная система
master     ubuntu-16gb-hel1-1             65.109.171.186       ubuntu
Для настройки внешнего балансировщика HAProxy можете использовать пример конфигурации /root/.test/haproxy.cfg
Настройка узлов
Проверка /etc/machine-id
Проверка /etc/machine-id завершена успешно
ubuntu-16gb-hel1-1            успешно   
Инициализация первого узла кластера ubuntu-16gb-hel1-1 успешно
Добавление узлов в кластер
Выполняется попытка установить лейблы для worker-узлов кластера.
Лейблы для worker-узлов успешно установлены.
Установка CNI...
Может занять несколько минут.
CNI успешно установлен
Установка системных компонентов кластера...
Может занять несколько минут.
Продолжается установка системных компонентов кластера. Может занять несколько минут.
Выполняется попытка обновить machines
Установка системных компонентов кластера завершена успешно.
Вы можете нажать Ctrl+C, чтобы завершить установку, или дождаться готовности web-интерфейса платформы Штурвал

Я честно ждал минут 20, когда же сообщение исчезнет и система перейдет на следующий этап. В результате мне надоело ждать, и я попросту открыл еще одну консоль ssh к тому же серверу. Там я увидел каталог ./test (по названию кластера), в котором лежали файлы:

root@ubuntu-16gb-hel1-1:~/.test# ls -la
total 36
drwxr--r-- 2 root root  4096 Aug 18 19:37 .
drwx------ 9 root root  4096 Aug 18 19:54 ..
-rw-r--r-- 1 root root  5540 Aug 18 19:37 clusteradmin.conf
-rwxr--r-- 1 root root  1473 Aug 18 19:36 clusterconfig.yaml
-rw-r--r-- 1 root root 10259 Aug 18 19:36 config.yml
-rw-r--r-- 1 root root   857 Aug 18 19:36 haproxy.cfg

Как можно догадаться, clusterconfig.yaml похож на конфигурационный файл для kubectl для подключения к кластеру. Им и воспользуемся:

export KUBECONFIG=$PWD/clusteradmin.conf

Попробуем взглянуть на ингрессы:

root@ubuntu-16gb-hel1-1:~/.test# kubectl get ing -A
NAMESPACE          NAME                CLASS   HOSTS                                                               ADDRESS   PORTS     AGE
shturval-backend   docs                nginx   docs.65-109-171-186.sslip.io                                                  80, 443   10m
shturval-backend   sh-authn            nginx   shturval.65-109-171-186.sslip.io,shturval.65-109-171-186.sslip.io             80, 443   18m
shturval-backend   sh-authn-keys       nginx   shturval.65-109-171-186.sslip.io                                              80, 443   18m
shturval-backend   shturval-backend    nginx   shturval.65-109-171-186.sslip.io                                              80, 443   18m
shturval-backend   shturval-frontend   nginx   shturval.65-109-171-186.sslip.io                                              80, 443   10m

Отсюда сразу виден интересный факт — платформа в установленном виде сама предоставляет документацию на себя. Думаю, что это очень удобно, в частности, в случае установки в закрытые контуры (то есть контуры, в которых нет доступа в сеть Интернет, или наоборот — из сети Интернет).

Можно посмотреть список подов:

root@ubuntu-16gb-hel1-1:~/.test# kubectl get pods -A
NAMESPACE                           NAME                                                             READY   STATUS      RESTARTS      AGE
capbd-system                        shturval-capbd-controller-manager-d8458998d-pszbj                2/2     Running     0             11m
capi-kubeadm-bootstrap-system       capi-kubeadm-bootstrap-controller-manager-69d59cb985-vjn59       1/1     Running     2 (15m ago)   16m
capi-kubeadm-control-plane-system   capi-kubeadm-control-plane-controller-manager-7c84fdc869-pqfwf   1/1     Running     0             16m
capi-system                         capi-controller-manager-84fb7fb99d-cxbt9                         1/1     Running     2 (14m ago)   20m
capos-system                        shturval-capos-controller-manager-7f9fff464c-bg5bn               1/1     Running     0             12m
capov-system                        capov-controller-manager-55f664d4b-26wn7                         1/1     Running     0             11m
capv-system                         capv-controller-manager-7986786dbb-sdt8k                         1/1     Running     0             12m
capy-system                         capy-controller-manager-77b55cd8b9-fxzwt                         2/2     Running     0             12m
cert-manager                        shturval-cert-manager-548894f969-pd4f5                           1/1     Running     0             22m
cert-manager                        shturval-cert-manager-cainjector-7d9fcf944d-skznz                1/1     Running     0             22m
cert-manager                        shturval-cert-manager-webhook-847665cd47-l2vlm                   1/1     Running     0             22m
ingress                             shturval-ingress-controller-controller-78897fd859-cztq7          1/1     Running     0             19m
ingress                             shturval-ingress-controller-controller-78897fd859-sq45r          0/1     Pending     0             19m
kube-system                         cilium-envoy-rz85r                                               1/1     Running     0             22m
kube-system                         cilium-jmzjt                                                     1/1     Running     0             22m
kube-system                         cilium-operator-857c7689f4-qpqnk                                 1/1     Running     1 (14m ago)   22m
kube-system                         coredns-b45fd9454-jtsth                                          1/1     Running     0             22m
kube-system                         coredns-b45fd9454-rldx8                                          1/1     Running     0             22m
kube-system                         etcd-ubuntu-16gb-hel1-1                                          1/1     Running     0             22m
kube-system                         kube-apiserver-ubuntu-16gb-hel1-1                                1/1     Running     0             14m
kube-system                         kube-controller-manager-ubuntu-16gb-hel1-1                       1/1     Running     1 (15m ago)   22m
kube-system                         kube-scheduler-ubuntu-16gb-hel1-1                                1/1     Running     1 (14m ago)   22m
kube-system                         shturval-caching-dns-wgqdz                                       1/1     Running     0             19m
kube-system                         shturval-init-job-j8qcp                                          0/1     Completed   0             21m
kube-system                         shturval-init-job-k4rpf                                          0/1     Error       0             22m
kube-vip                            shturval-vip-provider-554c68c767-5swk5                           1/1     Running     1 (15m ago)   20m
kube-vip                            shturval-vip-xsrf7                                               1/1     Running     1 (14m ago)   19m
rawfile-provisioner                 shturval-local-csi-controller-0                                  2/2     Running     0             20m
rawfile-provisioner                 shturval-local-csi-node-9pr5f                                    4/4     Running     0             20m
shturval-backend                    authn-5795fdc89d-dqpjp                                           2/2     Running     0             19m
shturval-backend                    docs-6fd96c697d-wxcqc                                            1/1     Running     0             12m
shturval-backend                    ldap-cache-85cd5c4696-bqc7k                                      1/1     Running     0             19m
shturval-backend                    monitoring-authz-c84979d78-sqhbh                                 2/2     Running     0             19m
shturval-backend                    shturval-auth-operator-7967db8c9f-k6cng                          2/2     Running     1 (14m ago)   19m
shturval-backend                    shturval-backend-677558f64c-gx6dz                                3/3     Running     0             19m
shturval-backend                    shturval-backend-677558f64c-sk5nw                                3/3     Running     0             19m
shturval-backend                    shturval-backend-valkey-primary-0                                1/1     Running     0             16m
shturval-backend                    shturval-frontend-5dfdc77d9b-mjbnv                               1/1     Running     0             12m
shturval-backend                    shturval-permissions-operator-6fd7cd8fc5-psg5s                   1/1     Running     2 (14m ago)   19m
shturval-capsm                      shturval-capsm-controller-manager-65dbd98779-kc7q6               1/1     Running     1 (20m ago)   20m
shturval-cluster-manager            shturval-cluster-manager-cluster-api-58bddfbfb7-mdjtb            1/1     Running     1 (15m ago)   20m
shturval-cluster-manager            shturval-cluster-manager-ip-pool-7f4f6c9795-5sdrt                2/2     Running     0             20m
shturval-node-config-system         shturval-node-config-controller-manager-654dc7494f-mgp8h         1/1     Running     0             20m
shturval-node-config-system         shturval-node-config-controller-manager-654dc7494f-rttk4         1/1     Running     2 (15m ago)   20m
shturval-services-system            shturval-services-controller-manager-86884575dc-czwrb            1/1     Running     2 (14m ago)   21m
shturval-trust-manager              shturval-trust-manager-94d949bd9-6k9tg                           1/1     Running     2 (15m ago)   19m
shturval-update-system              shturval-update-controller-manager-7c65df9d8c-kchxm              1/1     Running     0             11m
snapshotter                         shturval-snapshotter-6dfc86c6dc-bl78d                            1/1     Running     1 (14m ago)   19m
snapshotter                         snapshot-validation-webhook-78db9dd455-jxb9b                     1/1     Running     0             19m

По сути, система представляет собой классический Kubernetes-кластер вокруг kubeadm с дополнительными компонентами.

Я уже совсем не вытерпел и нажал Ctrl+C в основном окне консоли:

^C
Для подключения используйте ключ /root/.test/clusteradmin.conf
Веб-интерфейс Штурвала доступен по адресу https://shturval.65-109-171-186.sslip.io
Для подключения используйте логин admin и пароль Y0MSktshcbhUfR[0В этот момент времени у нас уже есть установленный менеджмент кластер Штурвала, и он доступен по ссылке. 

В этот момент времени у нас уже есть установленный менеджмент кластер Штурвала, и он доступен по ссылке. 

Изучив административный интерфейс, я увидел, по сути, полноценный интерфейс доступа ко всем кластерам, управляемым платформой Штурвал. В интерфейсе сделана очень четкая группировка. Есть возможность просматривать и изменять не только стандартные ресурсы Kubernetes, но и дополнительные, которые реализуются через механизм CRD или расширений API-сервера.

Сам управляющий кластер не предназначен для запуска пользовательских нагрузок, хотя это технически возможно сделать. Для пользовательских нагрузок предлагается создать отдельный кластер при помощи одного из доступных провайдеров — это может быть кластер в Yandex.Cloud, на VMware, на базе технологий OpenStack или oVirt. Таким образом Штурвал позволяет управлять кластерами как в облаке, так и на своих собственных вычислительных мощностях. Создание клиентского кластера тривиальное. По сути, требуется только правильно заполнить данные для подключения к облаку. В выполнении этой задачи помогают подробные пошаговые инструкции платформы Штурвал.

В меню я обнаружил возможность подключения каталога пользователей LDAP. Это может быть актуально для корпоративных пользователей, которые хотят управлять доступами пользователей из одного места. Это ставит Штурвал в один ряд с такими продуктами как OpenShift или RKE (Rancher). 

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

Сама платформа предоставляет собой не просто «голый кластер» — существует ещё и возможность доустановки модулей для мониторинга и логирования. В комплекте уже есть ingress-контроллер. Таким образом, Штурвал — законченное решение для запуска и работы с kubernetes-кластерами.

Из интересных технических решений в платформе я увидел древовидную модель тенантов. Это позволяет наследовать доступы между кластерами и группировать пространства имен (namespace). 

Очень похожая модель доступов используется в продукте cozystack.io Отличие Штурвала в том, что в платформе управляющий кластер отдельный, а управляемые (клиентские) кластера находятся на инфраструктуре снаружи. А в cozystack.io управляющий кластер разворачивается на железных серверах и клиентские кластера запускаются на этом же железе, но в контейнерах при помощи технологии KubeVirt.

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

Еще платформа сама по себе обеспечивает жизненный цикл узлов, которые в неё добавлены. Это очень перекликается с проектом System Upgrade Controller из платформы Rancher, но заходит дальше, так как Штурвал полностью берет на себя вопрос настройки и поддержки узла в таком состоянии, чтобы kubernetes-кластера работали в оптимальной конфигурации и без сбоев. 

Из всего опыта, который у меня есть по настройке kubernetes, я могу сказать, что это очень важно и без этого попросту невозможно безопасно и надежно управлять кластерами. Даже если взять очень популярные проекты вроде kubeadm или kubespray, они либо эту задачу перекладывают на плечи оператора кластера, либо накладывают достаточно серьезные ограничения на используемые операционные системы и их конфигурации. 

Проекты вроде RedHat OpenShift или VMware Tanzu идут еще дальше  и, по сути, представляют собой «коробочный» kubernetes, который разворачивается в вашем IT-ландшафте на своей операционной системе, куда в общем случае лезть не надо. Так как платформа Штурвал поддерживает широкий спектр операционных систем, то она может быть достаточно легко вписана в существующую инфраструктуру без серьезных изменений или, например, без конфликтов с ИБ-отделом, который уже изначально выдвинул требования использования определенной ОС.

Выводы?

Взял бы ли я Штурвал для себя? На самом деле, зависит от требований. Всегда интересно поиграться с чем-то новым, это позволяет открыть новые грани, узнать что-то, увидеть альтернативные решения. Но я, скорее, сторонник контролировать все самостоятельно, и поэтому, если рассматривать некий идеальный сценарий — я бы взял специализированный дистрибутив ОС Линукс Talos, позволяющий развернуть «ванильный» кластер с нуля с минимумом забот, а далее уже наполнял бы кластер теми компонентами, которые всем известны, и по сути уже являются стандартом —— cert-manager, стек мониторинга на VictoriaMetrics и grafana, nginx-ingress или istio и прочие.