Диаграмма Хельма: Как мне сначала установить зависимости? - PullRequest
Новая
       3

Диаграмма Хельма: Как мне сначала установить зависимости?

1 голос
/ 18 февраля 2020

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

Чтобы быть более точным c, я ' Я пытаюсь создать ресурсы, определенные в strimzi-kafka-operator в моей диаграмме управления, и хотел бы, чтобы зависимость была установлена ​​явно. Я следовал документации helm и добавил следующее в свой Chart.yaml 

dependencies:
- name: strimzi-kafka-operator
  version: 0.16.2
  repository: https://strimzi.io/charts/

Я запустил: 

$ helm dep up ./prototype-chart
$ helm install ./prototype-chart
> Error: unable to build Kubernetes objects from release manifest: unable to recognize "": no matches for kind "KafkaTopic" in version "kafka.strimzi.io/v1beta1"

, который показывает, что он пытается развернуть мою диаграмму до моей зависимости. Как правильно установить сначала зависимости, а затем мою родительскую диаграмму?

(Для справки, вот вопрос, который я открыл на GitHub напрямую со Стримзи, где они сообщили мне, что не уверены, как использовать свой шлем в качестве зависимости: https://github.com/strimzi/strimzi-kafka-operator/issues/2552)

1 Ответ

1 голос
/ 19 февраля 2020

Относительно CRD: тот факт, что Helm по умолчанию не будет управлять этими 1 , является функцией, а не ошибкой. Он все равно установит их, если их нет; но он не будет изменять или удалять существующие CRD. Предыдущая версия Helm (v2) делает , но (если судить по опыту), которая может привести вас к всевозможным неприятностям, если вы не будете осторожны. Цитирование по ссылке, на которую вы ссылались:

В настоящее время не поддерживается обновление или удаление CRD с помощью Helm. Это было явное решение после долгих обсуждений в сообществе из-за опасности непреднамеренной потери данных. [...] Одним из явных недостатков метода crd-install, используемого в Helm 2, была невозможность надлежащей проверки диаграмм из-за изменения доступности API (CRD фактически добавляет другой доступный API в ваш кластер Kubernetes). Если на диаграмме установлена ​​CRD, у helm больше не было действительного набора версий API для работы. [...] С новым методом crds установки CRD мы теперь гарантируем, что у Helm есть полностью достоверная информация о текущем состоянии кластера.

Идея в том, что Helm должен работать только при уровень выпуск данных (добавление / удаление развертываний, хранилище и т. д. c.); но с CRD вы фактически модифицируете расширение самого API Kubernetes, потенциально непреднамеренно нарушая другие выпуски, которые используют те же определения. Если вы работаете в команде, у которой есть «библиотека» CRD, совместно используемая несколькими диаграммами, и вы хотите удалить одну из них - ранее, с v2, Helm с радостью позволил бы вам изменять или даже удалять их по своему желанию, без проверок на если / как они использовались в других выпусках. Изменения в CRD - это изменения в вашей плоскости управления / ядре API , и их следует рассматривать как таковые - вы изменяете глобальные ресурсы.

Вкратце: с v3 Хелм позиционирует себя как инструмент «разработчика» для определения, шаблонирования и управления релизами; CRD, однако, предназначены для независимого управления, например, «администратором кластера». В конце концов, это выигрыш для всех сторон, так как разработчики могут настраивать / демонтировать развертывания по желанию, с уверенностью, что они не нарушат функциональность в другом месте ... и тому, кто находится на связи, не придется иметь дело с оповещениями, если / когда вы случайно удаляете / модифицируете CRD и ломаете вещи в процессе производства:)

См. также подробное обсуждение здесь для получения дополнительной информации о данном решении.

Надеюсь, это поможет!

...