Helm 3 alpha без Tiller: проверили в dev-кластере, впечатление сугубо положительное

Tiller - это такой компонент в Helm 2, про который все знают, что он неудобный, но пользуются, потому что альтернативы нет. Под в kube-system с cluster-admin-правами по умолчанию, без которого ни один helm install не пройдёт. С точки зрения RBAC - кошмар: один Tiller на кластер, и у него есть доступ ко всему. Можно его ограничить, но это требует отдельного Tiller-а на каждый namespace с отдельной service account - и это уже неудобная конструкция, которую мало кто доводит до конца.

В мае анонсировали Helm 3 alpha. Главное изменение - Tiller убран полностью. Мы взяли alpha и посмотрели, насколько это работает в реальности.

Чем был плох Tiller

Если коротко: Tiller жил в кластере с правами, которые нужны ему для деплоя чего угодно куда угодно. В результате любой, кто мог вызвать helm install, фактически имел права cluster-admin через Tiller - просто опосредованно. Это классический privileged proxy, и он разрушал всю логику RBAC-настройки.

Варианты, которые мы видели у клиентов на managed-инфраструктуре:

• Один Tiller на кластер с cluster-admin - стандартная установка из документации, «починим потом». Не чинят.
• Отдельный Tiller на каждый namespace - технически правильно, практически больно: несколько Deployment, несколько ServiceAccount, несколько RoleBinding на каждое окружение.
• TLS между helm-клиентом и Tiller - добавлено для галочки, ключи лежат на тех же машинах, что и kubectl-конфиги.

На нашем собственном dev-кластере жил один Tiller с cluster-admin. Честно - мы тоже «починим потом».

Что изменилось в Helm 3 alpha

Helm 3 использует kubeconfig напрямую - никакого pod-а в кластере нет. Клиент обращается к API-серверу от имени того пользователя или service account, которые прописаны в kubeconfig. Это означает, что права helm-команды = права пользователя в kubeconfig. Хочешь задеплоить в production-namespace - имей права на этот namespace. Хочешь задеплоить cluster-wide ресурсы - имей соответствующие права. RBAC работает так, как и должен.

Ещё изменения, которые бросились в глаза:

• Хранение state переехало в Secrets внутри namespace приложения. В Helm 2 история релизов хранилась в ConfigMap в kube-system - там, где живёт Tiller. Теперь каждый namespace хранит свои релизы сам, в Secret-ах с label owner: helm. Это логично: если у тебя есть доступ к namespace, ты видишь историю своих релизов, и не видишь чужих.
• Удалены helm serve и helm init - в новой архитектуре они не нужны, helm init в частности делал именно Tiller-установку.
• Chart API версии v2 - это отдельная история, но по сути: зависимости теперь описываются в Chart.yaml, отдельного requirements.yaml нет.

Что мы проверили

Взяли dev-кластер на Kubernetes 1.15, поставили Helm 3 alpha рядом с Helm 2 (они не конфликтуют, бинарники разные), развернули несколько charts.

Первое ощущение - установка из одной команды без helm init, без ожидания пока Tiller-pod запустится. Это мелочь, но приятная.

RBAC-поведение проверили намеренно: создали service account с правами только на один namespace, прописали в kubeconfig, попробовали задеплоить в другой namespace. Helm 3 вернул 403 от API-сервера - именно то, что мы хотели. В Helm 2 то же самое прошло бы через Tiller.

Из неожиданного: migration с Helm 2 не автоматическая. Существующие релизы Helm 2 Helm 3 не видит - там другой формат хранения. Есть плагин helm-2to3, который конвертирует, но мы его не тестировали - это уже для продакшн-миграции, когда выйдет стабильная версия.

Ещё момент: namespace isolation работает правильно, но требует, чтобы team-ы, которые деплоят через Helm, имели собственные kubeconfig-ы с правильными service account. Если сейчас все используют один admin-kubeconfig «для простоты» - это нужно разгрести до перехода.

Где мы сейчас

В продакшн alpha не несём - логично. Но для dev-кластеров alpha уже рабочий вариант: деплоить тестовые окружения через Helm 3 удобнее, чем поддерживать Tiller. Главный результат проверки - убеждение в том, что архитектурное решение правильное. RBAC в Kubernetes работает нормально, Tiller был тем слоем, который это обходил.

Когда выйдет стабильный релиз - будем мигрировать клиентские кластеры. Migration-план уже прикидываем, но это разговор на потом - alpha ещё меняется.