company_banner

Практическое знакомство с пакетным менеджером для Kubernetes — Helm



    Статья является логическим продолжение нашей недавней публикации об истории пакетного менеджера для Kubernetes — Helm. В этот раз мы снова затронем вопросы устройства и функционирования нынешнего Helm (версия 2.x), а также управляемых им чартов и репозиториев, после чего перейдём к практике: установке Helm в кластер Kubernetes и использованию чартов.

    Вступление


    Helm — инструмент для управления чартами.

    Чарт описывает необходимый набор данных для создания экземпляра приложения в кластере Kubernetes. Он может иметь вложенные чарты и использоваться как для описания полноценных сервисов, состоящих из множества зависимых ресурсов, так и для описания отдельных независимых составляющих. К примеру, чарт stable/gitlab-ce описывает комплексное решение с использованием независимых чартов redis и postgresql.

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

    Клиентская часть Helm отвечает за формирование чарта и передачу вместе с пользовательскими параметрами находящемуся в кластере Kubernetes компоненту Tiller. В свою очередь, Tiller отвечает за жизненный цикл экземпляра запущенного чарта, релиза. (На всякий случай напомню, что в следующем крупном обновлении Helm — версии 3 — уже не будет Tiller.)

    А теперь — обо всём по порядку.

    Установка и обновление


    Для работы с Helm требуется Kubernetes. Можно использовать локально установленный Minikube (см. также «Начало работы в Kubernetes с помощью Minikube») или любой другой доступный кластер.

    Начнём с установки клиента: выбираем релиз, скачиваем и распаковываем архив для своей системы, переносим исполняемый файл…

    $ curl https://storage.googleapis.com/kubernetes-helm/helm-v2.10.0-linux-amd64.tar.gz | tar -zxv
    $ sudo mv linux-amd64/helm /usr/local/bin/helm
    

    Далее установка Tiller в кластер. По умолчанию Tiller устанавливается в кластер контекста kubectl (kubectl config current-context), в пространство имён kube-system, но это можно изменить, используя соответствующие опции и переменные окружения — они описаны в справке (helm init --help). Выполним установку и посмотрим на созданные ресурсы в кластере:

    $ helm init
    $HELM_HOME has been configured at /home/habr/.helm.
    (Use --client-only to suppress this message, or --upgrade to upgrade Tiller to the current version.)
    Happy Helming!
    
    $ kubectl get all --selector=name=tiller --namespace kube-system
    NAME                               READY     STATUS    RESTARTS   AGE
    po/tiller-deploy-df4fdf55d-h5mvh   0/1       Running   0          5s
    
    NAME                CLUSTER-IP      EXTERNAL-IP   PORT(S)     AGE
    svc/tiller-deploy   10.107.191.68   <none>        44134/TCP   5s
    
    NAME                   DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
    deploy/tiller-deploy   1         1         1            0           5s
    
    NAME                         DESIRED   CURRENT   READY     AGE
    rs/tiller-deploy-df4fdf55d   1         1         0         5s
    

    Теперь Tiller установлен в кластер и готов к управлению релизами, взаимодействию с Kubernetes API.

    Примечание: При установке и обновлении (опция --upgrade) Tiller'а можно задавать конкретный образ вместо использования последнего стабильного релиза по умолчанию. Имя произвольного образа определяется опцией --tiller-image, а с опцией --canary-image при выкате Tiller будет использован canary-образ. Сanary-образ позволяет использовать Tiller, версия кода которого соответствует ветке master.

    Служебные данные хранятся в кластере в специальных ресурсах, ConfigMaps, поэтому удаление и переустановка Tiller'а не приводят к потере данных установленных ранее релизов.

    Репозитории чартов


    Репозиторий чартов — HTTP-сервер для хранения и распространения чартов. Информация о чартах в репозитории хранится в файле index.yaml. В нём же указывается, откуда каждый чарт может быть загружен. Чаще всего чарты хранятся вместе с файлом index.yaml, но ничего не мешает разместить их на другом сервере. Обычно файловая структура сводится к плоской форме:

    .
    ├── index.yaml
    ├── artifactory-7.3.0.tgz
    ├── docker-registry-1.5.2.tgz
    ...
    └── wordpress-2.1.10.tgz
    

    По умолчанию Helm использует официальный репозиторий чартов Kubernetes. Он содержит тщательно проработанные актуальные чарты для решения множества прикладных задач. Этот репозиторий именуется stable:

    $ helm repo list
    NAME    URL
    stable  https://kubernetes-charts.storage.googleapis.com
    

    При необходимости создание собственного репозитория не составит никаких проблем. Требования к серверу — минимальные, поэтому, как и большинство публичных репозиториев чартов, его можно разместить на GitHub Pages. Подробнее про инструменты и необходимые для этого шаги можно почитать в документации.

    При использовании репозиториев чартов они могут быть добавлены и удалены. Для того, чтобы версии чартов были актуальными, необходимо периодически обновлять индекс. Приведу пример для публичного репозитория bitnami, большая часть чартов которого используется в официальном репозитории Helm:

    $ helm repo add bitnami https://charts.bitnami.com/bitnami
    "bitnami" has been added to your repositories
    
    $ helm repo update
    Hang tight while we grab the latest from your chart repositories...
    ...Successfully got an update from the "bitnami" chart repository
    ...Successfully got an update from the "stable" chart repository
    Update Complete.  Happy Helming!
    
    $ helm repo remove bitnami
    "bitnami" has been removed from your repositories
    

    Далее — поиск по репозиториям. Вызов helm search без аргументов показывает все доступные чарты:

    $ helm search
    NAME                                  CHART VERSION APP VERSION                   DESCRIPTION
    stable/acs-engine-autoscaler          2.2.0         2.1.1                         Scales worker nodes within agent pools
    stable/aerospike                      0.1.7         v3.14.1.2                     A Helm chart for Aerospike in Kubernetes
    stable/anchore-engine                 0.2.1         0.2.4                         Anchore container analysis and policy evaluation engine s...
    stable/apm-server                     0.1.0         6.2.4                         The server receives data from the Elastic APM agents and ...
    stable/ark                            1.2.1         0.9.1                         A Helm chart for ark
    stable/artifactory                    7.3.0         6.1.0                         Universal Repository Manager supporting all major packagi...
    ...
    stable/weave-cloud                    0.2.2         0.2.0                         Weave Cloud is a add-on to Kubernetes which provides Cont...
    stable/weave-scope                    0.9.3         1.6.5                         A Helm chart for the Weave Scope cluster visualizer.
    stable/wordpress                      2.1.10        4.9.8                         Web publishing platform for building blogs and websites.
    stable/xray                           0.4.1         2.3.0                         Universal component scan for security and license invento...
    stable/zeppelin                       1.0.1         0.7.2                         Web-based notebook that enables data-driven, interactive ...
    stable/zetcd                          0.1.9         0.0.3                         CoreOS zetcd Helm chart for Kubernetes
    

    В необязательном поле keywords в Chart.yaml разработчики указывают теги, которые используются для упрощения поиска в репозиториях чартов:

    $ helm search web
    NAME                        CHART VERSION APP VERSION             DESCRIPTION
    stable/cerebro              0.3.1         0.8.1                   A Helm chart for Cerebro - a web admin tool that replaces...
    stable/chronograf           0.4.5         1.3                     Open-source web application written in Go and React.js th...
    stable/jasperreports        2.0.4         7.1.0                   The JasperReports server can be used as a stand-alone or ...
    stable/joomla               2.0.9         3.8.12                  PHP content management system (CMS) for publishing web co...
    stable/kubernetes-dashboard 0.7.2         1.8.3                   General-purpose web UI for Kubernetes clusters
    stable/odoo                 2.0.7         11.0.20180815           A suite of web based open source business apps.
    stable/phabricator          2.1.9         2018.34.0               Collection of open source web applications that help soft...
    stable/redmine              4.1.0         3.4.6                   A flexible project management web application.
    stable/rethinkdb            0.1.4         0.1.0                   The open-source database for the realtime web
    stable/schema-registry-ui   0.1.0         v0.9.4                  This is a web tool for the confluentinc/schema-registry i...
    stable/superset             0.1.2         0.24.0                  Apache Superset (incubating) is a modern, enterprise-read...
    stable/testlink             2.0.3         1.9.17                  Web-based test management system that facilitates softwar...
    stable/tomcat               0.1.0         7                       Deploy a basic tomcat application server with sidecar as ...
    stable/wordpress            2.1.10        4.9.8                   Web publishing platform for building blogs and websites.
    ...
    
    $ helm search cms blog
    NAME              CHART VERSION APP VERSION DESCRIPTION
    stable/drupal     1.1.3         8.5.6       One of the most versatile open source content management ...
    stable/joomla     2.0.9         3.8.12      PHP content management system (CMS) for publishing web co...
    stable/wordpress  2.1.10        4.9.8       Web publishing platform for building blogs and websites

    Примечание: При использовании команды helm search можно столкнуться с нестабильной работой нескольких фильтров: наличие результата зависит от порядка указания и количества фильтров.

    После того, как круг поисков сузился до нескольких вариантов, можно перейти к более детальному анализу чартов — с помощью команды helm inspect. Она выводит содержимое файлов чарта Chart.yaml, values.yaml и README.md. Каждый раздел по отдельности можно вывести с соответствующими аргументами: chart, values и readme.

    В официальном репозитории чарты прекрасно документированы и содержат примеры использования, а некоторые чарты — даже готовые конфигурации для production. К примеру, хороший readme представлен у stable/wordpress (для его вывода в консоли см. helm inspect readme stable/wordpress).

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

    Первое приложение


    Для примера выбран уже упомянутый чарт stable/wordpress.

    В нём используются параметры, описанные в файле values.yaml. Параметры можно переопределить в YAML-файле, а затем передать этот файл во время установки (опции -f, --values). Кроме того, их можно переопределить непосредственно в командной строке (опции --set, --set-string и --set-file). Все опции доступны для использования произвольное количество раз; при этом переопределение в командной строке имеет больший приоритет над файлами с параметрами.

    При установке чарта можно задать имя релизу опцией --name или использовать случайное имя, сгенерированное Helm.

    Установим чарт с конфигурацией для production, поменяем название блога, отключим сохранение данных WordPress в PersistentVolumeClaim (подробнее про постоянные хранилища см. в документации Kubernetes):

    $ curl https://raw.githubusercontent.com/helm/charts/master/stable/wordpress/values-production.yaml --output values-production.yaml
    $ helm install --name habr --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml stable/wordpress
    NAME:   habr
    LAST DEPLOYED: Fri Aug 31 15:17:57 2018
    NAMESPACE: default
    STATUS: DEPLOYED
    
    RESOURCES:
    ==> v1/Secret
    NAME            TYPE    DATA  AGE
    habr-mariadb    Opaque  2     0s
    habr-wordpress  Opaque  2     0s
    
    ==> v1/ConfigMap
    NAME                       DATA  AGE
    habr-mariadb-init-scripts  1     0s
    habr-mariadb               1     0s
    habr-mariadb-tests         1     0s
    
    ==> v1/Service
    NAME            TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)         AGE
    habr-mariadb    ClusterIP  10.111.7.232   <none>       3306/TCP        0s
    habr-wordpress  ClusterIP  10.106.129.88  <none>       80/TCP,443/TCP  0s
    
    ==> v1beta1/Deployment
    NAME            DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
    habr-wordpress  3        3        3           0          0s
    
    ==> v1beta1/StatefulSet
    NAME          DESIRED  CURRENT  AGE
    habr-mariadb  1        1        0s
    
    ==> v1beta1/Ingress
    NAME                  HOSTS            ADDRESS  PORTS  AGE
    wordpress.local-habr  wordpress.local  80, 443  0s
    
    ==> v1/Pod(related)
    NAME                            READY  STATUS             RESTARTS  AGE
    habr-wordpress-7955b95fd-hh7b9  0/1    ContainerCreating  0         0s
    habr-wordpress-7955b95fd-tgsxk  0/1    ContainerCreating  0         0s
    habr-wordpress-7955b95fd-xjz74  0/1    ContainerCreating  0         0s
    habr-mariadb-0                  0/1    ContainerCreating  0         0s
    
    
    NOTES:
    1. Get the WordPress URL:
    
      You should be able to access your new WordPress installation through
      https://wordpress.local/admin
    
    2. Login with the following credentials to see your blog
    
      echo Username: user
      echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
    

    В случае работы с полноценным кластером далее можно следовать рекомендациям из блока NOTES выше. Если же у вас Minikube — откройте сайт в браузере следующим образом:

    $ minikube service habr-wordpress
    Waiting, endpoint for service is not ready yet...
    Opening kubernetes service default/habr-wordpress in default browser...

    Поздравляю, приложение в кластере!



    Развёрнутый чарт с WordPress появился в списке всех релизов Helm:

    $ helm list
    NAME  REVISION  UPDATED                   STATUS    CHART             APP VERSION NAMESPACE
    habr  1         Fri Aug 31 15:17:57 2018  DEPLOYED  wordpress-2.1.10  4.9.8       default
    

    Следующим шагом обновим наш релиз и изменим образ с блогом. Для примера будет использован другой тег из того же Docker-репозитория (4.9.8-ol-7):

    $ helm upgrade habr --set "image.tag=4.9.8-ol-7" --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml stable/wordpress
    Release "habr" has been upgraded. Happy Helming!
    LAST DEPLOYED: Fri Aug 31 15:21:08 2018
    NAMESPACE: default
    STATUS: DEPLOYED
    
    RESOURCES:
    ==> v1/Service
    NAME            TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)         AGE
    habr-mariadb    ClusterIP  10.111.7.232   <none>       3306/TCP        3m
    habr-wordpress  ClusterIP  10.106.129.88  <none>       80/TCP,443/TCP  3m
    
    ==> v1beta1/Deployment
    NAME            DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
    habr-wordpress  3        4        2           0          3m
    
    ==> v1beta1/StatefulSet
    NAME          DESIRED  CURRENT  AGE
    habr-mariadb  1        1        3m
    
    ==> v1beta1/Ingress
    NAME                  HOSTS            ADDRESS  PORTS  AGE
    wordpress.local-habr  wordpress.local  80, 443  3m
    
    ==> v1/Pod(related)
    NAME                             READY  STATUS       RESTARTS  AGE
    habr-wordpress-66f4fd6b74-gqwhh  0/1    Pending      0         0s
    habr-wordpress-66f4fd6b74-mf6vj  0/1    Pending      0         0s
    habr-wordpress-7955b95fd-hh7b9   1/1    Running      2         3m
    habr-wordpress-7955b95fd-tgsxk   1/1    Running      2         3m
    habr-wordpress-7955b95fd-xjz74   0/1    Terminating  2         3m
    habr-mariadb-0                   1/1    Running      0         3m
    
    ==> v1/Secret
    NAME            TYPE    DATA  AGE
    habr-mariadb    Opaque  2     3m
    habr-wordpress  Opaque  2     3m
    
    ==> v1/ConfigMap
    NAME                       DATA  AGE
    habr-mariadb-init-scripts  1     3m
    habr-mariadb               1     3m
    habr-mariadb-tests         1     3m
    
    
    NOTES:
    1. Get the WordPress URL:
    
      You should be able to access your new WordPress installation through
      https://wordpress.local/admin
    
    2. Login with the following credentials to see your blog
    
      echo Username: user
      echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
    

    Обратите внимание, что при обновлении Tiller сравнивает полученный чарт с параметрами с последним сохранённым и выполняет соответствующие запросы в Kubernetes API, а актуальное состояние ресурсов релиза не берётся в расчёт. Важно понимать эту особенность и не совершать ошибок:

    • Обновление ничем не отличается от инсталяции: Helm-клиент отправляет Tiller чарт вместе с параметрами, поэтому надо быть внимательнее и не забыть указать параметры и файлы с параметрами, которые задавались при инсталяции (или при предыдущем обновлении) и которые не должны быть проигнорированы. В примере выше — это --set "wordpressBlogName=Flant's Blog!" --set "persistence.enabled=false" -f values-production.yaml.
    • Приложения, которые выкатываются при помощи Helm, должны обслуживаться только с использованием Helm: изменения, сделанные вручную при помощи kubectl, не будут учтены Helm и могут приводить к необратимым последствиям.

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

    Состояние компонентов релиза приложения в кластере всегда можно проверить следующим образом:

    $ helm status habr
    LAST DEPLOYED: Fri Aug 31 15:21:08 2018
    NAMESPACE: default
    STATUS: DEPLOYED
    
    RESOURCES:
    ==> v1/Secret
    NAME            TYPE    DATA  AGE
    habr-mariadb    Opaque  2     4m
    habr-wordpress  Opaque  2     4m
    
    ==> v1/ConfigMap
    NAME                       DATA  AGE
    habr-mariadb-init-scripts  1     4m
    habr-mariadb               1     4m
    habr-mariadb-tests         1     4m
    
    ==> v1/Service
    NAME            TYPE       CLUSTER-IP     EXTERNAL-IP  PORT(S)         AGE
    habr-mariadb    ClusterIP  10.111.7.232   <none>       3306/TCP        4m
    habr-wordpress  ClusterIP  10.106.129.88  <none>       80/TCP,443/TCP  4m
    
    ==> v1beta1/Deployment
    NAME            DESIRED  CURRENT  UP-TO-DATE  AVAILABLE  AGE
    habr-wordpress  3        4        2           3          4m
    
    ==> v1beta1/StatefulSet
    NAME          DESIRED  CURRENT  AGE
    habr-mariadb  1        1        4m
    
    ==> v1beta1/Ingress
    NAME                  HOSTS            ADDRESS  PORTS  AGE
    wordpress.local-habr  wordpress.local  80, 443  4m
    
    ==> v1/Pod(related)
    NAME                             READY  STATUS   RESTARTS  AGE
    habr-wordpress-66f4fd6b74-gqwhh  0/1    Pending  0         1m
    habr-wordpress-66f4fd6b74-mf6vj  1/1    Running  0         1m
    habr-wordpress-7955b95fd-hh7b9   1/1    Running  3         4m
    habr-wordpress-7955b95fd-tgsxk   1/1    Running  3         4m
    habr-mariadb-0                   1/1    Running  1         4m
    
    
    NOTES:
    1. Get the WordPress URL:
    
      You should be able to access your new WordPress installation through
      https://wordpress.local/admin
    
    2. Login with the following credentials to see your blog
    
      echo Username: user
      echo Password: $(kubectl get secret --namespace default habr-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)
    

    Helm позволяет откатываться до определённой ревизии релиза. На текущий момент ревизий две:

    $ helm history habr
    REVISION  UPDATED                   STATUS      CHART             DESCRIPTION
    1         Fri Aug 31 15:17:57 2018  SUPERSEDED  wordpress-2.1.10  Install complete
    2         Fri Aug 31 15:21:08 2018  DEPLOYED    wordpress-2.1.10  Upgrade complete
    

    Откатим приложения к первоначальному состоянию:

    $ helm rollback habr 1
    Rollback was a success! Happy Helming!
    

    Теперь история ревизий пополнилась на одну запись:

    $ helm history habr
    REVISION  UPDATED                   STATUS      CHART             DESCRIPTION
    1         Fri Aug 31 15:17:57 2018  SUPERSEDED  wordpress-2.1.10  Install complete
    2         Fri Aug 31 15:21:08 2018  SUPERSEDED  wordpress-2.1.10  Upgrade complete
    3         Fri Aug 31 15:25:06 2018  DEPLOYED    wordpress-2.1.10  Rollback to 1
    

    Статья подходит к концу и релиз больше не требуется?

    $ helm delete habr
    release "habr" deleted
    

    А удалён ли он в действительности?..

    Команда удаляет Kubernetes-ресурсы, связанные с релизом, но не сам релиз. Вся информация о релизе остаётся доступной, в том числе и его история:

    $ helm list --all
    NAME  REVISION  UPDATED                   STATUS  CHART             APP VERSION NAMESPACE
    habr  3         Fri Aug 31 15:25:06 2018  DELETED wordpress-2.1.10  4.9.8       default
    

    $ helm history habr
    REVISION  UPDATED                   STATUS      CHART             DESCRIPTION
    1         Fri Aug 31 15:17:57 2018  SUPERSEDED  wordpress-2.1.10  Install complete
    2         Fri Aug 31 15:21:08 2018  SUPERSEDED  wordpress-2.1.10  Upgrade complete
    3         Fri Aug 31 15:25:06 2018  DELETED     wordpress-2.1.10  Deletion complete
    

    Примечание: По задумке, удалённый релиз можно откатывать к предыдущим версиям, но в последних версиях эта возможность не работает — подробности см. в issue #3722.

    Для полного удаления релиза используется опция --purge:

    $ helm delete --purge habr
    release "habr" deleted
    

    Резюмируя


    В этой статье рассказано про базовую архитектуру Helm 2, его компоненты и их функций, а также об основных примитивах, чартах, релизах и репозиториях чартов. Мы установили Helm в кластер Kubernetes и получили понимание жизненного цикла релиза и основных команд для работы с ним.

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

    P.S.


    Флант
    DevOps-as-a-Service, Kubernetes, обслуживание 24×7

    Comments 9

      +3
      Статей из ряда «как начать использовать helm» = 100500. Вот бы кто рассказал зачем? С примерами в сравнении с kubectl.

      При ~100 сервисов, лично я не увидел пользы от helm. Скорее минусы… Может толк станет заметен при 1000, 10000+ сервисах?
        0
        Статей из ряда «как начать использовать helm» = 100500

        Но на хабре их 0 (да и в рунете тоже). А ответ по теме нужности/полезности есть по ссылке в комментарии ниже (от коллеги и автора статьи, который, похоже, промахнулся при ответе).
          0

          Хм, на моем опыте даже если у нас всего пара-тройка деплойментов, их сервисов и конфигмапов, то это все менеджить одним Хелм чартом удобнее, чем yaml файлами для kubectl. Особенно в процессе разработки, когда изменения и редеплои проходят постоянно.

            0
            Удобней… чем? Какую проблему для вас решает helm?
              +2
              — В helm мы можем экстернализировать любые параметры наших ресурсов, и они все храняться в одном месте, в values.yaml. Например если мы делаем чарт для другого типа платформ, то просто меняем в одном файле пару параметров. Сгружать же все ресурсы в один конфиг для kubectl и дальше искать и редактировать параметры во всех местах где они встречались руками — неудобно и чревато ошибками.

              — В helm удобно сделан просмотр текущих состояний релизов. Сразу видно что у нас стоит в кластере, в каком неймспейсе и точная дата-время установки. В kubectl же выводить простыню через kubectl get all и потом разбираться какой ресурс к какому приложению относится, еще и отдельно для каждого неймспейса — неудобно.

              — Допустим нам надо подправить конфиг на рабочем деплойменте и мы изменили конфигмап. kubectl не умеет подхватывать изменения в конфигмапах, нам надо вручную рескейлить деплоймент и руками удалять старые поды. В helm мы можем в metadata: annotations: деплоймента поставить проверку чексуммы конфигмапа. И дальше сделать всю работу одной командой helm upgrade

              — Чисто субьективно, работать с разными версиями чартов как с артифактами удобнее, чем хранить kubectl конфиги в гите и версионировать все разными бранчами.
                0
                — темплейтинг манифестов будет нужен, пока что, сервисов с динамичными настройками мало, где нужно — обходимся sed'om в CI
                — думаю тут дело привычки, на данный момент, мне удобней смотреть состояние через kubectl +сделал несколько алиасов
                — решаем такие вещи добавлением в под конфиг-релоадера
                — конфиги пишем 1:1 файл:kind, только rbac манифесты в одном yaml — разобраться/прочитать не составит труда

                Для решения CI/CD + templateing есть альтернативы, тащить «package manager» для этого, не вижу смысла.
                0
                Да и в целом Go-темплейтинг — крутая штука. Мы можем использовать традиционные конфиг файлы с отдельного репозитория и создавать из них конфигмапы на лету при установке чарта. Генерировать конфиги на лету для зависимых чартов в зависимости от параметров в родительском чарте. И т.д.
            +3
            Чтобы не дублировать ответ на подобный комментарий предлагаю перейти по ссылке к прошлой статье.
              0
              Да, аргументы есть. Но я бы не сказал, что они прям уж таки «железные».

            Only users with full accounts can post comments. Log in, please.