Блог

Возможно, я просто очень медленный, но я не могу понять это.

• Существуют репозитории / концентраторы (artifacthub и т. Д.) С указателями на другие репозитории, в которых есть диаграммы helm
• Я могу добавить эти диаграммы в качестве «зависимости» в свою диаграмму helm.файл yaml, если я знаю имя / версию / репозиторий
• Например, для https://artifacthub.io/packages/helm/vultr/cert-manager-webhook-vultr версия = 1.0.0, зависимость = vultr/cert-manager-webhook-vultr и репозиторий = https://vultr.github.io/helm-charts (это правильно? Почему эти 3 значения не видны. Это всегда похоже на игру в угадайку при попытке свернуть диаграммы)
• На artifacthub есть раздел «шаблоны», в котором есть различные файлы yaml. Это то, какие свойства можно изменить на диаграмме? Как эти yaml шаблона helm, которые я определяю, применяются к установленным мной диаграммам? (Например, если у меня есть оба входа nginx и traefik, получат ли они оба все yaml для kind: Ingress, примененные к ним?)
• Почему helm требует, чтобы я перенес кластер в мое локальное хранилище, чтобы использовать его? Используют ли люди helm для отслеживания релизов в «реальном мире»?
• В каком сценарии я бы просто сделал «helm install X», а не добавлял его в свою диаграмму.зависимости yaml?

Документы helm (и множество руководств) очень кратки и содержат только один пример сценария. Разве я не должен хотеть, чтобы вся моя «инфраструктура как код»? Я не понимаю постоянных предложений «helm add repo» и «helm install», а затем махать рукой над любыми настройками?

Я думаю, что самая интересная часть этого вопроса — это последний пункт, касающийся того, что делать helm install ; остальное — детали.

Я могу представить четыре разных «вида» диаграмм руля:

1. Диаграммы библиотеки содержат только {{- define -}} блоки шаблонов, но не ресурсы Kubernetes. Это первоклассная концепция в Helm 3, но довольно редкая в дикой природе.
2. Диаграммы «Инфраструктуры» содержат предварительно упакованную часть программного обеспечения, например PostgreSQL или Redis, которые вы, вероятно, не используете напрямую. Они могут зависеть от библиотечных диаграмм.
3. Диаграммы «Приложения» содержат, скажем, один микросервис, который вы используете напрямую. Они, вероятно, зависят от диаграмм инфраструктуры, например, для получения локальной базы данных.
4. «Зонтичные» диаграммы зависят от конкретных версий нескольких приложений и описывают объединенную систему.

Итак, если у вас есть система, состоящая из нескольких сервисов, и вы хотите отслеживать их релизы, у вас есть несколько вариантов. Один из них заключается в создании зонтичной диаграммы и helm upgrade этой диаграммы по мере поступления новых сборок компонентов; у этого есть механическая проблема, связанная с тем, что Helm любит комбинировать зависимости, поэтому все зависимости «сервис-локальной» базы данных будут объединены в одну. Вы можете helm install создавать диаграммы приложений по отдельности или использовать такой инструмент, как Helmfile или Helmsman, для управления набором смежных установленных диаграмм.

Однако в рамках этой иерархии вы обычно устанавливаете диаграммы «зонтика» или «приложения», но не устанавливаете диаграммы «инфраструктуры» или библиотеки напрямую. За исключением ранних экспериментов, которые вы обычно не helm install bitnami/redis делали, а вместо этого включали его как зависимость от вашего фактического приложения.

Вы в основном правы в механике использования диаграмм зависимостей. Каждая диаграмма включает в себя templates каталог, и шаблонные файлы YAML там установлены в кластере. Каждая диаграмма также включает values.yaml файл на своем верхнем уровне, и это единственный способ настроить диаграмму зависимостей. Родительская диаграмма может включать конфигурацию для своих зависимостей под ключом с именем зависимости

 # application/values.yaml
#   Chart.yaml depends on a specific chart named "infrastructure"
infrastructure:
  # This would be a top-level key in values.yaml in
  # the "infrastructure" chart
  username: foo
 

Вы не можете изменить фактическое содержимое шаблона из диаграмм зависимостей; вы можете настроить только то, что создается путем установки значений. Некоторые диаграммы имеют лучше документированные значения, чем другие, а у лучших есть все детали в их README.md файле.

Вы спрашиваете о нескольких вариантах реализации, и на них трудно дать конкретные ответы. Вам нужно загрузить зависимости в локальный charts подкаталог (например, with helm dep up ), но я не уверен, почему; Я могу представить варианты использования в автономном режиме, когда вы переносите диаграмму и ее зависимости в изолированную сеть и запускаете там установку, но я также могу представить, что Helm предпочитает charts каталог и автоматическая загрузка. Аналогично, поиск диаграмм на самом деле может быть сложным, но одна из причин этого заключается в том, что поддержание хранилища пакетов является как финансово, так и операционно сложным. Раньше существовало официальное «стабильное» хранилище графиков, но оно было прекращено.

И последнее, что я здесь затрону, — это понятие «кластерная инфраструктура». Вы можете представить, что хотите запустить, например, контроллер входа или агент ведения журнала, который может быть упакован в виде диаграммы управления. В моей первоначальной иерархии я бы рассматривал их как «приложения»; служебная диаграмма может иметь type: Ingress ресурс, но сама по себе не будет зависеть от входных контроллеров Nginx или Traefik. Вы можете настроить Helmfile для кластерной инфраструктуры параллельно с настройкой основного приложения или управлять ими вместе, если вы уверены, что используете только одну копию своей системы в кластере.