Что такое Helm и Helm Charts: полное руководство

В мире Kubernetes каждое приложение состоит из множества компонентов — deployments, services, configmaps, secrets и других ресурсов. Каждый из них требует отдельного YAML-манифеста, и управление всей этой экосистемой быстро превращается в настоящий кошмар. Представьте себе: вы развертываете веб-приложение с базой данных, кешем и балансировщиком нагрузки — это минимум 10-15 файлов конфигурации, которые нужно синхронизировать, обновлять и версионировать.

Именно здесь на сцену выходит Helm — инструмент, который можно смело назвать «менеджером пакетов» для Kubernetes. Если провести аналогию с операционными системами, то Kubernetes играет роль ядра системы, а Helm выступает в качестве apt для Ubuntu или yum для CentOS. Мы получаем возможность упаковать все компоненты приложения в единый пакет — чарт (chart), который содержит не только манифесты ресурсов, но и логику их конфигурирования.

Сравнение количества YAML-файлов при ручном управлении и при использовании Helm. Диаграмма наглядно показывает, насколько проще становится развертывание с помощью чарта.

Основные возможности Helm

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

Ключевые преимущества Helm:

• Шаблонизация — динамическая генерация манифестов на основе параметров.
• Управление версиями — каждый релиз имеет свою версию и может быть откачен.
• Зависимости — автоматическое управление связанными сервисами.
• Репозитории — централизованное хранение и распространение чартов.
• Автоматизация — интеграция в CI/CD пайплайны без написания сложных скриптов.

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

Разобравшись с концептуальными основами, давайте погрузимся в практические возможности Helm, которые делают его незаменимым инструментом в арсенале современного DevOps-инженера.

Управление манифестами через чарты

Helm позволяет объединить все Kubernetes-ресурсы приложения в единый пакет — чарт. Вместо работы с десятками отдельных YAML-файлов мы получаем структурированную систему шаблонов, которые генерируют финальные манифесты на основе переданных параметров. Это означает, что один чарт может быть использован для развертывания в различных окружениях — от локальной разработки до продакшн-кластера.

Поддержка зависимостей

Современные приложения редко существуют в изоляции. Веб-сервису может понадобиться Redis для кеширования, PostgreSQL для данных и Prometheus для мониторинга. Helm автоматически управляет такими зависимостями — достаточно объявить их в файле Chart.yaml, и система сама позаботится об их установке и конфигурировании в правильной последовательности.

Управление версиями и откатами

Каждая установка чарта создает релиз с уникальным номером версии. Helm ведет полную историю изменений, что позволяет в любой момент откатиться к предыдущей рабочей версии простой командой helm rollback. Это критически важно для продакшн-систем, где каждая минута простоя может стоить значительных потерь.

Централизованная работа с репозиториями

Helm поддерживает концепцию репозиториев — централизованных хранилищ чартов, доступных для поиска и установки. Artifact Hub содержит тысячи готовых решений от сообщества, а корпоративные команды могут создавать собственные приватные репозитории для внутренних приложений.

Параметризация и кастомизация

Файл values.yaml позволяет настроить любой аспект развертывания без изменения самих шаблонов. Количество реплик, образы контейнеров, ресурсные лимиты, сетевые политики — все это становится конфигурируемым через простые YAML-параметры.

Совокупность этих возможностей превращает Helm в своеобразный «швейцарский нож» для работы с Kubernetes, где каждая функция дополняет другие, создавая целостную экосистему управления приложениями.

Архитектура и принцип работы Helm

Эволюция архитектуры Helm наглядно демонстрирует, как инструменты адаптируются под изменяющиеся требования безопасности и упрощения развертывания. Понимание этих изменений критически важно для корректного использования современных версий.

Helm 2: эпоха Tiller

Первоначальная архитектура Helm 2 следовала классической клиент-серверной модели. Клиентская часть (helm CLI) взаимодействовала с серверным компонентом под названием Tiller, который устанавливался непосредственно в кластер Kubernetes. Tiller выполнял роль посредника, получая команды от клиента и применяя изменения через Kubernetes API.

Однако такой подход создавал серьезные проблемы с безопасностью: Tiller требовал расширенных привилегий для работы с ресурсами кластера, что противоречило принципам least privilege. Более того, управление правами доступа становилось сложной задачей в мульти-тенантных средах.

Helm 3: революционное упрощение

Релиз Helm 3 кардинально изменил архитектуру, полностью исключив Tiller из уравнения. Теперь helm CLI работает напрямую с Kubernetes API, используя те же учетные данные и права доступа, что и пользователь. Это решение не только устранило проблемы безопасности, но и значительно упростило установку и сопровождение — больше не нужно развертывать дополнительные компоненты в кластере.

Управление состоянием релизов

Интересный вопрос: где Helm хранит информацию о состоянии установленных релизов? В отличие от Helm 2, который использовал ConfigMaps, в Helm 3 по умолчанию используется хранение в Secrets (Секретах) в том же namespace, где развернут релиз. Это обеспечивает более высокий уровень безопасности, поскольку Secrets предназначены для хранения конфиденциальных данных.

Однако для менее чувствительных сценариев или по историческим причинам доступны альтернативы:

• ConfigMaps — могут быть явно сконфигурированы для хранения информации о релизах.
• SQL-базы данных — PostgreSQL или MySQL для корпоративных сценариев с требованиями к аудиту и масштабируемости.

Диаграмма сравнивает архитектуру, безопасность и способы хранения релизов в Helm 2 и Helm 3. Она помогает быстро увидеть ключевые улучшения новой версии.

Переход на Helm 3 стал логичным шагом в эволюции инструмента, отражающим более глубокое понимание потребностей enterprise-сегмента и принципов cloud-native безопасности. Эта архитектурная трансформация подчеркивает важность постоянного переосмысления технических решений в контексте изменяющихся требований индустрии.

Структура Helm-чарта

Понимание внутреннего устройства Helm-чарта — это ключ к эффективной работе с инструментом. Каждый чарт представляет собой четко структурированную директорию, где каждый файл выполняет определенную роль в процессе развертывания и управления приложением.

Chart.yaml — паспорт чарта

Центральный файл метаданных, который содержит всю необходимую информацию для идентификации и управления чартом. Здесь указывается версия API (v2 для современных чартов), имя, версия, описание и критически важная секция dependencies. Именно через этот файл Helm понимает, какие внешние компоненты требуются для корректной работы приложения — будь то база данных Redis или брокер сообщений RabbitMQ.

values.yaml — центр конфигурации

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

templates/ — сердце шаблонизации

Директория содержит шаблоны Kubernetes-манифестов, написанные с использованием синтаксиса Go templates. Файлы deployment.yaml, service.yaml, configmap.yaml и другие генерируют финальные манифесты, подставляя значения из values.yaml и системных переменных Helm. Особый интерес представляет файл _helpers.tpl, который содержит переиспользуемые функции и макросы для унификации именования и лейблов.

charts/ — управление зависимостями

Когда мы выполняем команду helm dependency update, все зависимые чарты загружаются именно в эту директорию. Это позволяет создавать сложные составные приложения, где главный чарт оркеструет развертывание всех необходимых компонентов в правильной последовательности.

NOTES.txt — постустановочная информация

Файл, который часто недооценивают, но который играет важную роль в пользовательском опыте. После успешной установки Helm выводит содержимое этого файла, предоставляя пользователю инструкции по подключению к приложению, URL-адреса, учетные данные или следующие шаги. NOTES.txt также поддерживает шаблонизацию, что позволяет генерировать динамические инструкции.

.helmignore и вспомогательные файлы

Аналогично .gitignore, файл .helmignore позволяет исключить определенные файлы и директории из финального пакета чарта. Это особенно важно для исключения временных файлов, документации для разработчиков или конфиденциальных данных, которые не должны попадать в распространяемую версию.

Такая продуманная структура превращает каждый Helm-чарт в самодокументированный, переносимый и легко сопровождаемый пакет, который инкапсулирует не только техническую реализацию, но и знания о том, как правильно развертывать и использовать приложение.

Helm Charts и релизы

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

Чарт vs Релиз: концептуальное разделение

Чарт можно сравнить с архитектурным чертежом здания — это набор шаблонов, инструкций и параметров, описывающих как должно быть развернуто приложение. Релиз же представляет собой конкретную реализацию этого чертежа — фактически работающий экземпляр приложения в кластере Kubernetes с уникальным именем и состоянием.

Одного чарта может существовать множество релизов. Например, чарт веб-приложения может быть развернут как staging-release в тестовой среде и как production-release в продакшене, каждый со своими параметрами конфигурации и версией.

Жизненный цикл релиза

Процесс создания релиза начинается с команды helm install, которая принимает два обязательных аргумента:

helm install my-application ./my-chart

В этом примере my-application становится именем релиза, а ./my-chart указывает на локальный чарт. Helm также поддерживает установку из репозиториев:

helm install redis-cache bitnami/redis --version 17.3.7

Управление жизненным циклом

После создания релиза мы получаем полный контроль над его жизненным циклом:

# Просмотр статуса релиза
helm status my-application

# Обновление с новыми параметрами
helm upgrade my-application ./my-chart --set image.tag=v2.0.0

# Просмотр истории изменений
helm history my-application

# Откат к предыдущей версии
helm rollback my-application 1

Параметризация во время установки

Один из мощнейших механизмов Helm — возможность переопределения параметров без изменения самого чарта. Это достигается через флаги —set или —values:

# Переопределение отдельных параметров
helm install webapp ./chart --set replicas=3 --set image.tag=latest

# Использование файла значений
helm install webapp ./chart --values production-values.yaml

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

Пространства имен и изоляция

Каждый релиз существует в определенном namespace Kubernetes, что обеспечивает логическую изоляцию между различными развертываниями. По умолчанию Helm использует namespace default, но это поведение легко изменить:

helm install my-app ./chart --namespace production --create-namespace

Эта концепция релизов превращает Helm из простого инструмента шаблонизации в полноценную систему управления жизненным циклом приложений, где каждое развертывание отслеживается, версионируется и может быть воспроизведено или откачено по требованию.

Репозитории Helm Charts

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

Artifact Hub — глобальный каталог решений

Artifact Hub представляет собой централизованный реестр, объединяющий чарты из множества публичных репозиториев. Это своеобразный «npm для Kubernetes», где можно найти готовые решения для большинства популярных приложений — от баз данных до систем мониторинга.

# Поиск чартов во всех доступных репозиториях

helm search hub nginx

helm search hub prometheus

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

Локальные репозитории и их управление

Для регулярной работы с определенными репозиториями Helm предоставляет механизм их локального кэширования:

# Добавление популярного репозитория Bitnami
helm repo add bitnami https://charts.bitnami.com/bitnami

# Добавление официального репозитория stable charts
helm repo add stable https://charts.helm.sh/stable

# Обновление индекса репозиториев
helm repo update

# Поиск в подключенных репозиториях
helm search repo redis

Корпоративные и приватные репозитории

В enterprise-средах часто возникает потребность в создании собственных репозиториев для внутренних чартов. Helm поддерживает различные backend’ы для хостинга:

# Подключение приватного репозитория с аутентификацией
helm repo add company-charts https://charts.company.com/helm \
  --username $USERNAME --password $PASSWORD

# Использование OCI-совместимых регистров
helm registry login registry.company.com

helm install my-app oci://registry.company.com/charts/webapp

Верификация и безопасность

Современные требования безопасности диктуют необходимость верификации загружаемых чартов:

# Проверка подписи чарта
helm verify ./downloaded-chart.tgz

# Загрузка с проверкой
helm fetch bitnami/redis --verify

Работа с версиями и обновлениями

Репозитории поддерживают версионирование чартов, что позволяет точно контролировать используемые версии:

# Просмотр доступных версий
helm search repo bitnami/postgresql --versions

# Установка конкретной версии
helm install db bitnami/postgresql --version 12.1.2

# Информация о чарте
helm show chart bitnami/postgresql

helm show values bitnami/postgresql

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

Post-Renderers в Helm

Post-Renderers представляют собой мощный, но часто недооцененный механизм Helm, который позволяет модифицировать сгенерированные манифесты после обработки шаблонизатором, но до их применения в кластере. Эта возможность открывает двери для интеграции дополнительных инструментов и процессов в workflow развертывания.

Зачем нужны Post-Renderers

Представьте ситуацию: у нас есть готовый чарт от стороннего разработчика, который почти идеально подходит для наших потребностей, но требует небольших модификаций — добавления security contexts, изменения resource limits или внедрения корпоративных политик безопасности. Вместо создания форка чарта мы можем использовать post-renderer для внесения необходимых изменений.

Интеграция с Kustomize

Наиболее популярный сценарий использования post-renderers — интеграция с Kustomize для применения организационных стандартов:

Создаем структуру для Kustomize:

mkdir kustomize

cd kustomize

Файл kustomization.yaml:

commonLabels:

  environment: production

  managed-by: platform-team

patchesStrategicMerge:

  - security-patch.yaml

Файл security-patch.yaml:

apiVersion: apps/v1

kind: Deployment

metadata:

  name: not-important

spec:

  template:

    spec:

      securityContext:

        runAsNonRoot: true

        runAsUser: 1001

      containers:

      - name: app

        securityContext:

          allowPrivilegeEscalation: false

          readOnlyRootFilesystem: true

Создание Post-Render скрипта

Скрипт должен читать манифесты из STDIN и выводить модифицированный результат в STDOUT:

#!/bin/bash

# post-render.sh

# Создаем временную директорию

WORK_DIR=$(mktemp -d)

INPUT_FILE="$WORK_DIR/input.yaml"

# Сохраняем входные данные

cat > "$INPUT_FILE"

# Применяем Kustomize

cd kustomize

echo "resources:" > kustomization-temp.yaml

echo "- $INPUT_FILE" >> kustomization-temp.yaml

cat kustomization.yaml >> kustomization-temp.yaml

kustomize build . -f kustomization-temp.yaml

# Очистка

rm -rf "$WORK_DIR"

Применение Post-Renderer

После подготовки скрипта его можно использовать при установке или обновлении чарта:

chmod +x post-render.sh

helm install webapp stable/webapp --post-renderer ./post-render.sh

helm upgrade webapp stable/webapp --post-renderer ./post-render.sh

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

Управление зависимостями

Современные приложения редко существуют в изоляции — веб-сервису нужна база данных, кеш-серверу требуется система мониторинга, а микросервисной архитектуре необходим ervice mesh. Helm предоставляет элегантный механизм управления такими зависимостями, автоматизируя процесс развертывания сложных составных приложений.

Объявление зависимостей в Chart.yaml

Зависимости декларируются в секции dependencies основного чарта. Каждая зависимость определяется именем, версией и репозиторием, что обеспечивает воспроизводимость развертываний:

apiVersion: v2

name: my-web-application

version: 1.0.0

dependencies:

  - name: redis

    version: "^17.3.7"

    repository: "https://charts.bitnami.com/bitnami"

  - name: postgresql

    version: "12.1.2"

    repository: "https://charts.bitnami.com/bitnami"

  - name: nginx

    version: "13.2.4"

    repository: "https://charts.bitnami.com/bitnami"

    condition: nginx.enabled

Диаграмма показывает, как один главный чарт управляет зависимыми сервисами — Redis, PostgreSQL и Nginx. Это помогает визуально понять структуру многокомпонентного развертывания.

Управление жизненным циклом зависимостей

Helm предоставляет набор команд для работы с зависимостями:

# Просмотр объявленных зависимостей
helm dependency list ./my-chart

# Загрузка и размещение зависимостей
helm dependency update ./my-chart

# Построение зависимостей без загрузки
helm dependency build ./my-chart

Команда dependency update создает файл Chart.lock, который фиксирует точные версии всех зависимостей, обеспечивая детерминированность сборок.

Условные зависимости и теги

Не все зависимости должны устанавливаться в каждом окружении. Helm поддерживает условную установку через параметры condition и tags:

dependencies:

  - name: redis

    version: "17.3.7"

    repository: "https://charts.bitnami.com/bitnami"

    condition: redis.enabled

  - name: postgresql

    version: "12.1.2"

    repository: "https://charts.bitnami.com/bitnami"

    tags:

      - database

Управление через values.yaml:

redis:

  enabled: true

tags:

  database: false  # Отключает все зависимости с тегом database

Переопределение конфигурации зависимостей

Критически важная особенность — возможность настройки зависимых чартов через главный values.yaml:

# values.yaml главного чарта

redis:

  architecture: standalone

  auth:

    enabled: true

    password: "secure-password"

  master:

    persistence:

      enabled: true

      size: 8Gi

postgresql:

  auth:

    postgresPassword: "postgres-password"

    database: "myapp"

  primary:

    persistence:

      enabled: true

      size: 10Gi

Практический пример: веб-приложение с микросервисами

Рассмотрим реальный сценарий развертывания e-commerce платформы:

# Инициализация чарта
helm create ecommerce-platform

# Обновление зависимостей
helm dependency update ./ecommerce-platform

# Развертывание с кастомизацией
helm install shop ./ecommerce-platform \
  --set redis.enabled=true \
  --set postgresql.auth.database=shop \
  --set nginx.ingress.enabled=true

Такой подход превращает процесс развертывания сложных приложений из последовательности ручных операций в единую атомарную команду, где все компоненты развертываются в правильной последовательности с корректными взаимосвязями и конфигурацией.

Helm SDK для Go

Для команд, работающих с автоматизацией и CI/CD пайплайнами, командной строки Helm может оказаться недостаточно. Helm SDK для Go открывает возможности программного управления чартами и релизами, позволяя встраивать функциональность Helm непосредственно в корпоративные системы и инструменты автоматизации.

Иллюстрация показывает интеграцию Helm SDK в CI/CD пайплайн. Она подчёркивает, как SDK связывает этап разработки с автоматическим развертыванием и управлением инфраструктурой.

Инициализация клиента Helm

package main

import (

    "fmt"

    "log"

    "os"

    "path/filepath"

    

    "helm.sh/helm/v3/pkg/action"

    "helm.sh/helm/v3/pkg/cli"

    "k8s.io/client-go/util/homedir"

)

func initHelmClient() *action.Configuration {

    settings := cli.New()

    actionConfig := new(action.Configuration)

    

    if err := actionConfig.Init(

        settings.RESTClientGetter(),

        settings.Namespace(),

        os.Getenv("HELM_DRIVER"),

        func(format string, v ...interface{}) {

            fmt.Printf(format, v...)

        },

    ); err != nil {

        log.Fatalf("Failed to initialize Helm client: %v", err)

    }

    

    return actionConfig

}

Программная установка чартов

SDK предоставляет полный контроль над процессом установки, включая валидацию, настройку параметров и обработку ошибок:

func installChart(actionConfig *action.Configuration, chartPath, releaseName string, values map[string]interface{}) error {

    client := action.NewInstall(actionConfig)

    client.ReleaseName = releaseName

    client.Namespace = "default"

    client.Wait = true

    client.Timeout = time.Minute * 5

    

    chartRequested, err := loader.Load(chartPath)

    if err != nil {

        return fmt.Errorf("failed to load chart: %v", err)

    }

    

    release, err := client.Run(chartRequested, values)

    if err != nil {

        return fmt.Errorf("failed to install chart: %v", err)

    }

    

    fmt.Printf("Release %s installed successfully\n", release.Name)

    return nil

}

Обновление и управление релизами

Программное управление жизненным циклом релизов открывает возможности для создания сложных стратегий развертывания:

func upgradeRelease(actionConfig *action.Configuration, releaseName, chartPath string, values map[string]interface{}) error {

    client := action.NewUpgrade(actionConfig)

    client.Namespace = "default"

    client.Wait = true

    client.ResetValues = false

    

    chartRequested, err := loader.Load(chartPath)

    if err != nil {

        return err

    }

    

    release, err := client.Run(releaseName, chartRequested, values)

    if err != nil {

        return fmt.Errorf("upgrade failed: %v", err)

    }

    

    fmt.Printf("Release %s upgraded to revision %d\n", release.Name, release.Version)

    return nil

}

Интеграция в CI/CD пайплайны

SDK особенно эффективен при создании автоматизированных пайплайнов развертывания, где требуется условная логика и интеграция с внешними системами:

func deployWithRollbackStrategy(actionConfig *action.Configuration, releaseName, chartPath string) error {

    // Попытка обновления

    err := upgradeRelease(actionConfig, releaseName, chartPath, nil)

    if err != nil {

        log.Printf("Upgrade failed: %v, attempting rollback", err)

        

        // Откат к предыдущей версии

        rollbackClient := action.NewRollback(actionConfig)

        rollbackClient.Wait = true

        

        if rollbackErr := rollbackClient.Run(releaseName); rollbackErr != nil {

            return fmt.Errorf("both upgrade and rollback failed: upgrade=%v, rollback=%v", err, rollbackErr)

        }

        

        return fmt.Errorf("upgrade failed but rollback successful: %v", err)

    }

    

    return nil

}

Мониторинг и получение статуса

SDK позволяет интегрировать проверки состояния релизов в системы мониторинга:

func getReleaseStatus(actionConfig *action.Configuration, releaseName string) (*release.Release, error) {

    client := action.NewGet(actionConfig)

    

    release, err := client.Run(releaseName)

    if err != nil {

        return nil, err

    }

    

    fmt.Printf("Release: %s, Status: %s, Version: %d\n", 

        release.Name, release.Info.Status, release.Version)

    

    return release, nil

}

Использование Helm SDK превращает статические пайплайны развертывания в интеллектуальные системы, способные принимать решения на основе состояния кластера, результатов тестов и бизнес-логики организации. Это особенно критично для enterprise-сред, где требования к автоматизации и надежности развертываний выходят за рамки возможностей стандартных CI/CD инструментов.

Заключение

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

• Helm — менеджер пакетов для Kubernetes. Он объединяет разрозненные YAML в воспроизводимые чарты.
• Шаблонизация и values.yaml дают гибкую параметризацию. Один чарт покрывает разные окружения без правок шаблонов.
• Управление версиями и откаты повышают надёжность релизов. История изменений и команда rollback сокращают время простоя.
• Зависимости декларируются в Chart.yaml. Helm автоматически подтягивает и настраивает связанные сервисы.
• Репозитории и Artifact Hub упрощают поиск и обмен чартами. Подписи и версии повышают безопасность и контроль.
• Архитектура Helm 3 исключает Tiller. Прямое обращение к Kubernetes API упрощает доступ и усиливает безопасность.
• Структура чарта стандартизирует проект. Chart.yaml, templates/ и NOTES.txt делают развёртывание предсказуемым.
• Post-renderers добавляют корпоративные политики без форков. Kustomize поверх рендеринга внедряет стандарты.
• Helm SDK для Go автоматизирует операции. Программное управление установками, апгрейдами и откатами встраивается в CI/CD.

Если вы только начинаете осваивать DevOps и Kubernetes, рекомендуем обратить внимание на подборку курсов по DevOps. В них есть как теоретическая база, так и практические задания, помогающие закрепить навыки развёртывания приложений в реальных кластерах.