Helm 3 и Helm 2: больше никаких Tiller

Сегодня Вы используете Helm 3, но сначала появился Helm 2, работавший совсем иначе. Знание этих изменений поможет Вам правильно читать старые руководства. 📜

Helm 2 состоял из клиентской части и компонента в кластере под названием Tiller. CLI обращался к Tiller, а Tiller — к Kubernetes.

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

Tiller часто работал с широкими правами администратора кластера. Любой, кто получал к нему доступ, фактически мог сделать что угодно, что представляло серьёзный риск. 🔓

Главное изменение в Helm 3 простое: Tiller исчез. Теперь CLI напрямую обращается к API Kubernetes, как и kubectl. 🎉

Helm 3 — это исключительно клиент. Он использует Ваш kubeconfig и Ваши собственные разрешения, поэтому дополнительного серверного компонента для защиты нет.

Поскольку Helm 3 использует Ваши учётные данные, Вам доступны только те действия, которые разрешает Ваша роль Kubernetes. Управление доступом становится простым и стандартным.

Helm 3 хранит состояние каждого релиза как Kubernetes-ресурс Secret в пространстве имён релиза, а не в прежнем хранилище Tiller.

В Helm 3 имена релизов уникальны для каждого пространства имён, а не для всего кластера. Одно и то же имя может безопасно существовать в двух разных пространствах имён.

В Helm 3 также появилась необязательная проверка схемы значений и встроенная поддержка реестров OCI, а Tiller был полностью удалён.

Если в руководстве упоминаются Tiller или helm init, оно предназначено для Helm 2. Современному Helm не нужен шаг init, поэтому его можно спокойно пропустить. 👍

Helm 3 удалил Tiller, стал работать только как клиент, использует Ваши собственные разрешения и хранит релизы как Secrets в пространствах имён. Безопаснее и проще. ✅