Обзор высокоуровневых пакетных менеджеров для k8s или история одной боли

helmwave/helmsman/helmfile - почему и зачем. Краткое сравнение.

Transcript

1. Обзор высокоуровневых пакетных менеджеров для k8s или история одной боли Всплытие из Helm Package Manager v17
2. Автор Терешков Евгений Из Southbridge.io / Slurm.io в X5: evgeny.tereshkov@x5.ru
3. План рассказа • Проблематика • Чего хочется? • Решение • Что есть сейчас: краткое сравнение
4. Фантомные боли №1: продуктовая команда Настройки контуров: values.yaml prod-values.yaml Создание review-окружений с нуля: kubectl create ns NS kubectl create secret fakesecret –from-literal=... helm upgrade -i –set foo=$CI_COMMIT_REF
5. Фантомные боли №2: инфраструктурная команда Задача: надо поставить в кластер (и иногда обновлять/удалять) 100500 чартов, чтобы он был пригоден для работы клиента И поддержки Задача: иногда для запуска “здесь и сейчас” надо задеплоить готовые YAML- манифесты с минимальными усилиями Дано: есть кучки values.yaml и редмишек/скриптов с helm upgrade, безсистемно разбросанных в git-е. Идёт переход с helm2 на helm3.
6. Найдённое решение Высокоуровневый пакетный менеджер для k8s. Аля dnf для helm-а. Ну или terraform для облака. Мы пишем - что хотим, оно делает, что нужно. Найденные кандидаты: • helmsman • helmfile • terraform helm provider
7. Боль 2021. Что было в .gitlab-ci.yml .deploy: script: - helm upgrade --install --set image.repository=docker-foo.x5.ru --set ci.job_url=${CI_JOB_URL} --set ci.project_path_slug=${CI_PROJECT_PATH_SLUG} --set ci.enviroment_slug=${CI_ENVIRONMENT_SLUG} --set component.url=${COMPONENT_URL} --set env.API_PROXY=false --set env.API_HOST=${API_HOST} --set env.API_SHOP_PROXY=${API_SHOP_PROXY} --set env.API_SHOP_PROXY_LOCATION=${API_SHOP_PROXY_LOCATION} --set env.API_SHOP_URL=${API_SHOP_URL} --set env.API_QNA_PROXY=${API_QNA_PROXY} --set env.API_QNA_PROXY_LOCATION=${API_QNA_PROXY_LOCATION} --set env.API_QNA_HOST=${API_QNA_HOST} --set env.API_QNA_TLS=${API_QNA_TLS} --set env.AUTH_PROXY=${AUTH_PROXY} --set env.AUTH_HOST=${AUTH_HOST} --set env.S3_HOST=${S3_HOST} --set env.S3_BUCKET=${S3_BUCKET} --history-max 3 --debug ${COMPONENT_NAME} ./ci/deploy/helm portal-ui to dev: extends: .deploy_helm variables: COMPONENT_NAME: "portal-ui" ENV_NAME: "dev" IMAGE_TAG: $CI_COMMIT_SHORT_SHA CPU_LIMIT: 200m MEMORY_LIMIT: 256Mi CPU_REQUEST: 50m MEMORY_REQUEST: 128Mi API_PROXY: "false" API_HOST: "http://portal-api.xcloud-dev.x5.ru" API_SHOP_PROXY: "false" API_SHOP_PROXY_LOCATION: "/api/shop" API_SHOP_URL: "http://shop-api.xcloud-dev.x5.ru" API_QNA_PROXY: "false" # API_QNA_PROXY_LOCATION: "/api/qna" API_QNA_HOST: "api.qna.foo.xcloud-dev.x5.ru" API_QNA_TLS: 'false' AUTH_PROXY: 'false' AUTH_HOST: "https://keycloak.foo.os-dev.x5.ru" S3_HOST: https://spb-nsg-s3.x5.ru:1082 S3_BUCKET: uploads rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' when: manual
8. И это ещё не всё… Не забудь прописать новых переменных в ConfigMap и Secret
9. Почему это сделано так? “Когда в руках молоток - всё вокруг кажется гвоздём”(с).
10. Проблемы? Пожалуй. Чтобы что-то внести надо загрузить весь пайплайн в мозг. А он конечный. И ленивый. Когда нужна новая переменная - разработчики приходят к тебе. Потому что опасаются лезть в 20кб+ пайплайн. И ты тоже опасаешься, но вносишь. Зачастуя в 7-8-ми местах и с ошибками. Т.е. пайплайн и все настройки в одном месте - плохо масштабируется.
11. Чего хотим? • Попроще пайплайны • DRY • Выделить конфигурацию • Попроще чарты
12. Решение Использовать helmfile лишь для одного чарта разрабатываемого приложения. Это позволит нам разделить определения пайплайна, деплоя, контура, четко разделить статическую и динамически генерируемую части конфигурации.
13. Вы же обычно не запускаете rpm/deb на своём сервере/десктопе чтобы установить один пакет?
14. Как работает высокоуровневый пакетный менеджер в kubernetes? repositories: - name: prometheus-community url: https://prometheus-community.github.io/helm-charts releases: - name: kube-prometheus-stack namespace: prometheus-monitoring chart: prometheus-community/kube-prometheus-stack values: - promstack.yaml version: ~30.0.0 disableValidationOnInstall: true На примере helmfile.yaml helmfile apply всё сделает
15. Что стало: пайплайн deploy prod: extends: .deploy rules: - if: '$CI_COMMIT_TAG' variables: ENV_NAME: prod .deploy: stage: deploy image: docker-registry.x5.ru/evgkrsk/kubernetes-helm script: - helmfile --environment $ENV_NAME --file ci/helmfile.yaml apply environment: name: ${ENV_NAME} url: http://foobar-api.${KUBE_INGRESS_BASE_DOMAIN}
16. Что стало: деплой и конфигурации ci/deploy/helm/values.yaml env: foo: somevalue bar: someothervalue ci/deploy/helmfile.yaml environments: dev: {} stage: {} prod: {} helmBinary: werf releases: - name: {{ requiredEnv "CI_PROJECT_NAME" }} chart: ./helm namespace: {{ requiredEnv "KUBE_NAMESPACE" }} missingFileHandler: Warn values: - values.yaml.gotmp - {{ .Environment.Name }}.yaml.gotmpl - {{ .Environment.Name }}.yaml ci/deploy/stage.yaml.gotmpl ingress: url: foo.{{ requiredEnv “KUBE_INGRESS_BASE_DOMAIN” }} ci/deploy/stage.yaml env: bar: overridevalue
17. Итоги Странно, но вроде бы получили всё что хотели. Упростили себе жизнь и работу. Хотя, осталось ещё использовать встроенную поддержку helm-secrets в helmfile (читай: брать секреты из vault-а). Плюс, за это время появились новые проекты: • Helmwave - сырмолодой, перспективный.
18. Что есть сейчас: краткое сравнение Возможности helmfile (3.6K ⭐) helmsman (1K ⭐) helmwave (150 ⭐) Рендеринг релизов sprig, yaml anchors yaml anchors sprig, gomplate, yaml anchors Рендеринг values ✅ (опционально, в .gotmpl) ❌ (опционально, только $переменные) ✅ Обёртка YAML-ов ✅ ❌ ❌ Обязательные переменные ✅ ❌ ✅ Защита релизов ❌ ✅ ❌ Live deploy debug ❌ (внешний werf, по результату) ❌ ✅ (kubedog) Создание ns/quota/limitrange ❌ (манифестом/внешним чартом) ✅ ❌ (внешним чартом) Патченье релизов ✅ ❌ ❌ Удаление релизов ✅ ✅ ❌ Semver lock ✅ ❌ ❌
19. Вопросы? Критика? Предложения?