Kubernetes для Python-разработчиков: от контейнера до продакшена

Основы архитектуры K8s и деплой первого Python-сервиса через Pod и Deployment

Добро пожаловать в курс Kubernetes для Python-разработчиков. Если вы читаете эту статью, значит, вы уже переросли запуск приложений через python app.py на локальной машине и, вероятно, уверенно чувствуете себя с Docker. Но когда контейнеров становится не два, а двадцать, или когда нужно обеспечить отказоустойчивость продакшн-уровня, Docker Compose перестает справляться. Здесь на сцену выходит Kubernetes (K8s).

В этой вводной статье мы разберем анатомию кластера, поймем, почему мы не деплоим «голые» контейнеры, и запустим ваш первый Python-сервис, используя правильные абстракции.

Зачем Python-разработчику Kubernetes?

Как Middle-разработчик, вы отвечаете не только за код, но и за то, как он живет в дикой природе. Kubernetes решает фундаментальные проблемы эксплуатации:

* Self-healing (Самовосстановление): Если ваш скрипт упал из-за MemoryError, K8s перезапустит его. * Scaling (Масштабирование): Пришел «Хабр-эффект»? Одной командой можно поднять 10 реплик вашего FastAPI приложения. * Zero Downtime Deployment: Выкатка новой версии без прерывания обслуживания пользователей.

Архитектура Kubernetes: Взгляд с высоты птичьего полета

Kubernetes — это не единый монолит, а распределенная система. Глобально кластер делится на две части: Control Plane (управляющий слой) и Worker Nodes (рабочие узлы).

!Архитектура кластера: Control Plane управляет состоянием, а Worker Nodes выполняют нагрузку

1. Control Plane (Мозг кластера)

Это командный центр. Обычно он скрыт от разработчика (особенно в облаках вроде AWS EKS или Google GKE), но понимать его устройство необходимо для траблшутинга.

* API Server: Единственный компонент, с которым вы общаетесь напрямую (через утилиту kubectl). Это «парадная дверь» кластера. Он валидирует запросы и обновляет состояние в базе данных. * etcd: Высокодоступное хранилище типа «ключ-значение». Это единственное место, где хранится состояние кластера. Если вы потеряли etcd — вы потеряли кластер. * Scheduler: Планировщик. Он смотрит на новые задачи (Поды) и решает, на какую именно ноду их отправить, исходя из свободных ресурсов (CPU, RAM). Controller Manager: Следит за тем, чтобы текущее состояние кластера соответствовало желаемому*. Если вы попросили 3 копии сервиса, а одна упала, контроллер заметит разницу и прикажет создать новую.

2. Worker Nodes (Мускулы кластера)

Здесь работает ваш Python-код.

* Kubelet: Агент, который работает на каждой ноде. Он получает инструкции от API Server (например: «Запусти этот контейнер») и передает их Docker (или другому Container Runtime). * Kube-proxy: Отвечает за сетевые правила. Благодаря ему ваши сервисы могут общаться друг с другом внутри кластера. * Container Runtime: Среда запуска контейнеров (Docker, containerd, CRI-O).

Декларативный подход: YAML как язык общения

В отличие от скриптов на Bash, где вы пишете как сделать (императивный подход), в Kubernetes вы описываете что хотите получить (декларативный подход).

Вы создаете манифест (обычно YAML-файл), описывающий Desired State (желаемое состояние). Вы «скармливаете» этот файл кластеру, и K8s делает всё возможное, чтобы реальность совпала с вашим описанием.

Атом Kubernetes: Pod (Под)

Многие новички спрашивают: «Почему я не могу просто запустить контейнер, как в Docker?». В Kubernetes минимальной единицей деплоя является не контейнер, а Pod.

Pod — это логическая обертка над одним или несколькими контейнерами.

Зачем нужна эта прослойка?

Контейнеры внутри одного Пода:

Имеют общий IP-адрес.

Имеют общее пространство портов (localhost).

Могут иметь общие тома (Volume) для обмена файлами.

[VISUALIZATION: Иллюстрация концепции Pod. Изображен стручок гороха (Pod), внутри которого находятся две горошины-контейнера. Одна горошина подписана

Управление конфигурацией: ConfigMaps и Secrets для переменных окружения Python

В предыдущей статье мы научились запускать Python-код в Kubernetes, используя Pod и Deployment. Однако, если вы внимательно посмотрели на свой манифест Deployment, то могли заметить проблему: что делать с настройками подключения к базе данных, API-ключами и флагами DEBUG=True?

Хардкодить их в код приложения — это путь к катастрофе. Зашивать их в Docker-образ — небезопасно и неудобно (придется пересобирать образ ради смены пароля).

В этой статье мы разберем, как Kubernetes решает задачу конфигурации приложений согласно методологии 12-Factor App, отделяя конфигурацию от кода с помощью двух примитивов: ConfigMap и Secret.

Проблема конфигурации в распределенных системах

Представьте, что у вас есть сервис на FastAPI. Локально вы используете файл .env, который парсится библиотекой python-dotenv или pydantic-settings.

Когда мы переходим в Kubernetes, файл .env перестает быть удобным решением. Нам нужно место, где мы можем централизованно хранить настройки и «впрыскивать» их в контейнеры при запуске.

Kubernetes предлагает два хранилища:

ConfigMap — для несекретных данных (URL базы данных, уровень логирования, настройки таймаутов).

Secret — для чувствительных данных (пароли, API-ключи, сертификаты).

ConfigMap: Словарь вашего кластера

ConfigMap (карта конфигураций) — это объект API, который хранит данные в формате «ключ-значение». Эти данные можно передать в Pod как переменные окружения или как конфигурационные файлы.

Создание ConfigMap

Давайте создадим конфигурацию для нашего Python-сервиса. Допустим, нам нужно передать хост базы данных и режим отладки.

Вот как выглядит манифест app-config.yaml:

Применим его:

Теперь эти данные живут в etcd кластера, но наш Pod о них еще не знает.

Подключение ConfigMap к Pod

Есть два основных способа передать эти данные в контейнер: по одному ключу или все сразу.

#### Способ 1: Выборочная передача (valueFrom)

Этот способ хорош, если имя переменной в Python отличается от ключа в ConfigMap, или если вам нужно всего пару значений.

В манифесте Deployment:

#### Способ 2: Массовая передача (envFrom)

Это наиболее удобный способ для Python-разработчиков. Он берет все ключи из ConfigMap и превращает их в переменные окружения контейнера.

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

Secrets: Сейф для паролей

Хранить пароли в ConfigMap — плохая практика. Любой, кто имеет доступ к просмотру ConfigMap (а это часто широкий круг разработчиков), увидит их в открытом виде. Для этого существуют Secrets.

В чем отличие Secret от ConfigMap?

Кодирование: Данные в манифестах Secrets хранятся в формате Base64.

Шифрование: В современных кластерах (EKS, GKE) Secrets шифруются в состоянии покоя (Encryption at Rest) внутри базы данных etcd.

ОЗУ: Secrets монтируются в Pod как tmpfs (оперативная память) и не записываются на диск узла, чтобы избежать утечек.

!Визуализация того, как данные из разных источников объединяются в переменные окружения контейнера

Создание Secret

Создадим секрет с паролем от базы данных.

Важно: В YAML-файле значения должны быть закодированы в Base64.

Пример генерации Base64 в терминале:

Манифест app-secret.yaml:

Обратите внимание: Base64 — это не шифрование, это кодирование. Если у злоумышленника есть доступ к этому YAML-файлу, он легко декодирует пароль. Поэтому манифесты с секретами нельзя хранить в Git в открытом виде (используйте инструменты типа Sealed Secrets или External Secrets).

Использование Secret в Pod

Синтаксис почти идентичен ConfigMap, только меняется ключевое слово на secretKeyRef.

Или массово через envFrom:

Python-код: Как это выглядит изнутри?

Самое приятное в этом подходе то, что вашему Python-коду абсолютно все равно, откуда пришли переменные — из .env файла локально или из Kubernetes Secrets в продакшене. Он просто читает os.environ.

Пример использования с pydantic-settings (стандарт де-факто для современных проектов):

Если вы используете чистый os:

ConfigMap как файл (Volume Mount)

Иногда переменные окружения не подходят. Например, если вам нужно передать сложный nginx.conf или settings.json для вашего приложения. В этом случае ConfigMap можно примонтировать как файл.

Пример:

Создаем ConfigMap, где ключом является имя файла, а значением — содержимое файла.

В Deployment монтируем его через volumes.

В результате в контейнере по пути /app/config появятся файлы с вашими настройками.

Обновление конфигурации

Важный нюанс Kubernetes: изменение ConfigMap или Secret не приводит к автоматическому перезапуску Pod'ов.

Если вы поменяли LOG_LEVEL в ConfigMap, ваше запущенное приложение об этом не узнает, так как переменные окружения считываются только при старте процесса.

Чтобы применить изменения, нужно перезапустить Поды. Самый простой способ сделать это декларативно — изменить аннотацию в Deployment или воспользоваться командой:

Резюме

Никогда не храните конфигурацию внутри образа контейнера.

Используйте ConfigMap для обычных настроек и Secret для чувствительных данных.

Для Python-приложения самый простой способ интеграции — маппинг через envFrom, который заполняет os.environ.

Помните, что Base64 в манифестах Secrets — это защита от глаз, а не от хакеров. Не коммитьте сырые секреты в Git.

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

Сетевое взаимодействие: Service Discovery, Ingress и доступ к API снаружи

В предыдущих частях курса мы прошли путь от упаковки Python-приложения в Docker-образ до его запуска в Kubernetes с использованием ConfigMaps и Secrets. Теперь у нас есть работающий Pod (или даже несколько реплик), который правильно сконфигурирован. Но есть одна проблема: этот Pod абсолютно изолирован. Никто из внешнего мира не может отправить к нему запрос, и даже другие сервисы внутри кластера не знают, как его найти.

В этой статье мы разберем сетевую магию Kubernetes. Мы узнаем, почему IP-адреса Pod'ов бесполезны для конфигурации, как работает Service Discovery и как правильно организовать вход в кластер через Ingress, чтобы ваше FastAPI или Django приложение стало доступно пользователям.

Проблема: Эфемерность Pod'ов

Каждый Pod в Kubernetes получает свой собственный IP-адрес. Казалось бы, почему просто не взять этот IP и не прописать его в конфиг другого сервиса?

Потому что в мире Kubernetes Pod'ы смертны.

Если Pod падает и перезапускается, он получает новый IP.

Если вы масштабируете Deployment с 1 до 5 реплик, у вас появляется 5 новых IP-адресов.

Если нода кластера уходит на обслуживание, Pod'ы переезжают на другую ноду и меняют адреса.

Пытаться отслеживать IP-адреса Pod'ов вручную — это сизифов труд. Нам нужна стабильная точка входа, единый адрес, который не меняется, даже если за ним умирают и рождаются сотни контейнеров. Эта абстракция называется Service.

Service: Стабильный адрес в хаосе

Service (Сервис) — это объект Kubernetes, который объединяет логический набор Pod'ов и определяет политику доступа к ним.

Сервис выполняет две главные функции:

Service Discovery: Дает стабильное DNS-имя и IP-адрес.

Load Balancing: Распределяет трафик между всеми живыми репликами Pod'ов.

Как Сервис находит свои Поды?

Здесь в игру вступают Labels (Метки) и Selectors (Селекторы). Это тот самый клей, который держит объекты Kubernetes вместе.

Когда вы создавали Deployment, вы указывали метки в шаблоне Pod'а:

Сервис использует Selector, чтобы найти все Pod'ы с соответствующими метками и направить на них трафик.

!Service находит нужные Pod'ы по совпадению меток и распределяет запросы между ними

Типы Сервисов

В зависимости от того, кто должен иметь доступ к вашему приложению, вы выбираете тип сервиса (type в YAML).

#### 1. ClusterIP (По умолчанию)

Сервис получает IP-адрес, доступный только внутри кластера.

* Для чего: Для баз данных (Postgres, Redis), внутренних микросервисов, к которым не нужен доступ из интернета. * Пример: Ваш фронтенд внутри кластера обращается к бэкенду.

#### 2. NodePort

Сервис открывает определенный порт (в диапазоне 30000-32767) на IP-адресе каждой ноды кластера.

* Для чего: Часто используется для отладки или в простых bare-metal кластерах. * Минусы: Небезопасно открывать порты на всех машинах; неудобные номера портов (например, 31543).

#### 3. LoadBalancer

Используется в облачных провайдерах (AWS, GCP, Azure). Kubernetes заказывает у облака создание настоящего внешнего балансировщика нагрузки (например, AWS ELB), который перенаправляет трафик в кластер.

* Для чего: Для публичных сервисов. * Минусы: Это стоит денег. Если у вас 50 микросервисов, платить за 50 LoadBalancer'ов будет накладно.

Service Discovery: Как Python находит соседей

Самое приятное для Python-разработчика — это встроенный DNS в Kubernetes (обычно CoreDNS).

Когда вы создаете Service с именем my-python-app, в DNS кластера создается запись. Теперь любой другой Pod в том же пространстве имен (Namespace) может обратиться к нему просто по имени.

Пример манифеста service.yaml:

Python-код

Представьте, что у вас есть сервис frontend, которому нужно отправить запрос в auth-service. Вам не нужно знать IP-адреса. Вы просто пишете:

Если сервисы находятся в разных Namespace, используется полное доменное имя (FQDN): auth-service.production.svc.cluster.local.

Ingress: Единая точка входа

Если LoadBalancer — это дорого (один IP на один сервис), а NodePort — неудобно, то как выставить наружу 10 микросервисов, имея один белый IP-адрес?

Ответ: Ingress.

Ingress — это не просто "дырка" в заборе, это умный маршрутизатор (L7 Load Balancer), работающий на прикладном уровне (HTTP/HTTPS). Он позволяет настроить правила маршрутизации на основе хоста (домена) и пути (path).

Для работы Ingress нужен Ingress Controller. Это обычный Pod (часто Nginx, Traefik или HAProxy), который слушает внешний трафик и перенаправляет его на нужные внутренние сервисы согласно правилам.

!Ingress Controller принимает весь внешний трафик и маршрутизирует его к нужным сервисам на основе URL или домена

Пример Ingress-манифеста

Допустим, мы хотим, чтобы:

Запросы на example.com/api шли в backend-service.

Запросы на example.com/docs шли в docs-service.

Преимущества Ingress

Экономия: Один LoadBalancer (для Ingress Controller) обслуживает десятки сервисов.

SSL/TLS Termination: Вы можете настроить сертификаты (например, через Let's Encrypt и cert-manager) в одном месте — на Ingress. Ваши Python-сервисы внутри кластера могут общаться по обычному HTTP, не заботясь о шифровании.

Красивые URL: Вы скрываете внутреннюю архитектуру за понятными путями (/api/v1/users).

Итоговая схема взаимодействия

Давайте соберем всё вместе. Путь запроса от пользователя до вашего Python-кода выглядит так:

User вводит https://example.com/api/users.

DNS интернета направляет запрос на внешний IP вашего кластера.

Load Balancer облака принимает запрос и передает его на Ingress Controller.

Ingress Controller смотрит правила, видит префикс /api и понимает, что нужно отправить запрос в сервис backend-service.

Service backend-service выбирает один из живых Pod'ов (например, backend-pod-xyz).

Запрос попадает в контейнер, где его обрабатывает Uvicorn/Gunicorn.

Резюме

Никогда не полагайтесь на IP-адреса Pod'ов. Они меняются.

Используйте Service типа ClusterIP для внутренней связи между микросервисами.

Используйте DNS-имена сервисов в вашем Python-коде (http://db-service).

Используйте Ingress для публикации HTTP/HTTPS приложений в интернет. Это стандарт де-факто для продакшена.

Теперь ваше приложение доступно миру. Но готово ли оно к нагрузкам? В следующей статье мы поговорим о том, как Kubernetes следит за здоровьем ваших приложений с помощью Probes (Liveness и Readiness) и как настроить автоматическое масштабирование.

Стабильность и ресурсы: Liveness/Readiness Probes и Requests/Limits для Python-процессов

В предыдущей статье мы настроили Ingress и Service, открыв наше приложение внешнему миру. Теперь трафик поступает в кластер, балансировщик находит нужный Pod и отправляет туда запрос. Но здесь возникает нюанс: тот факт, что процесс Python запущен (PID существует), еще не означает, что приложение готово обрабатывать запросы.

Что если ваше FastAPI приложение зависло в бесконечном цикле? Или Gunicorn запустился, но соединение с базой данных еще не установлено? Или, что хуже, один из ваших Pod'ов начал потреблять всю доступную память ноды, убивая соседние процессы?

В этой статье мы превратим наше приложение из «просто запущенного» в «надежное и предсказуемое». Мы разберем два фундаментальных механизма Kubernetes: Probes (проверки здоровья) и Resources (управление потреблением CPU и RAM).

Probes: Пульс вашего приложения

Kubernetes не умеет читать мысли вашего кода. По умолчанию он считает, что если контейнер работает, то все хорошо. Чтобы научить кластер понимать реальное состояние приложения, используются Probes (пробы).

Существует три основных типа проб:

Liveness Probe (Проверка живучести)

Readiness Probe (Проверка готовности)

Startup Probe (Проверка запуска)

!Иллюстрация различий: Liveness перезапускает контейнер, а Readiness управляет входящим трафиком.

1. Liveness Probe: «Ты живой?»

Эта проба отвечает на вопрос: «Нужно ли перезапустить контейнер?».

Если ваше Python-приложение словило «мертвую блокировку» (deadlock) или вошло в состояние, из которого не может выйти самостоятельно, Liveness Probe это заметит. Если проверка проваливается, kubelet убивает контейнер, и он создается заново.

Опасность: Никогда не проверяйте внешние зависимости (например, базу данных) в Liveness Probe. Если база данных упадет, Liveness Probe провалится во всех ваших Pod'ах одновременно, Kubernetes начнет перезапускать их все по кругу, но это не починит базу. Вы получите каскадный сбой.

2. Readiness Probe: «Ты готов к работе?»

Эта проба отвечает на вопрос: «Можно ли отправлять сюда трафик?».

Представьте, что ваше приложение при старте загружает в память большую модель машинного обучения или прогревает кэш. Это занимает 30 секунд. Если отправить запрос на 5-й секунде, пользователь получит ошибку 502.

Если Readiness Probe проваливается, Kubernetes не перезапускает Pod. Он просто временно удаляет IP-адрес этого Pod'а из списка Endpoints соответствующего Service. Трафик идет только на «готовые» реплики.

3. Реализация в Python (FastAPI)

Для корректной работы проб нам нужно добавить в приложение специальные эндпоинты. Хорошей практикой считается разделение проверок.

Конфигурация в YAML

Добавим пробы в наш Deployment:

Resources: Requests и Limits

Вторая важнейшая тема — ресурсы. В мире Docker на локальной машине ваш контейнер может съесть все 16 ГБ оперативной памяти. В кластере Kubernetes это недопустимо, так как на одной ноде живут десятки контейнеров.

Kubernetes использует два понятия для управления ресурсами CPU и Memory:

Requests (Запросы): То, что гарантируется контейнеру. Планировщик (Scheduler) использует это значение, чтобы выбрать подходящую ноду.

Limits (Лимиты): То, что контейнеру запрещено превышать. Это жесткий потолок.

CPU: Время процессора

CPU в Kubernetes измеряется в ядрах. Но так как микросервисам редко нужно целое ядро, используется единица millicores (m).

Формула перевода:

где — это одно логическое ядро процессора (vCPU в облаке или поток Hyper-threading на железе), а — миллиядра, минимальная дробная единица ресурса.

* 250m = 0.25 ядра. * 100m = 0.1 ядра.

Особенность Python: Из-за GIL (Global Interpreter Lock) стандартный процесс CPython может эффективно использовать только одно ядро. Поэтому для одного воркера Gunicorn нет смысла ставить limits больше 1000m (1 ядро), если только вы не используете многопроцессность или C-расширения (numpy/pandas).

Что будет при превышении лимита CPU? Произойдет Throttling (троттлинг). Процессор просто перестанет выдавать такты вашему контейнеру. Приложение начнет «тормозить», но не упадет.

Memory: Оперативная память

Память измеряется в байтах (MiB, GiB).

Что будет при превышении лимита Memory? Память — это несжимаемый ресурс. Если контейнер попытается выделить больше памяти, чем указано в limits, придет OOM Killer (Out Of Memory Killer) и убьет процесс. Статус Pod'а изменится на OOMKilled, и он перезапустится (если позволяет политика).

!Иллюстрация работы OOM Killer при превышении лимита памяти.

Пример конфигурации

В этом примере: * Kubernetes найдет ноду, где свободно минимум 128 МБ RAM и 0.25 ядра. * Если приложение съест больше 256 МБ RAM, оно будет убито. * Если приложение захочет больше 0.5 ядра, оно будет замедлено.

QoS Classes: Классы обслуживания

На основе того, как вы задали requests и limits, Kubernetes присваивает Pod'у один из трех классов качества обслуживания (Quality of Service). Это важно, когда на ноде заканчиваются ресурсы и нужно кого-то выселить (Eviction).

1. Guaranteed (Гарантированный)

* Условие: requests равны limits для CPU и RAM. * Поведение: Это VIP-персоны. Kubernetes убивает их в последнюю очередь. * Для чего: Базы данных, критически важные брокеры сообщений.

2. Burstable (Взрывной)

* Условие: requests меньше limits. * Поведение: Приложение имеет гарантированный минимум, но может «взрываться» по потреблению до лимита, если на ноде есть свободные ресурсы. * Для чего: Большинство Python веб-сервисов. Нагрузка на API часто неравномерна.

3. BestEffort (Как получится)

* Условие: requests и limits не заданы. * Поведение: Первые кандидаты на выселение при нехватке ресурсов. Могут использовать все свободное место, но без гарантий. * Для чего: Тестовые скрипты, неважные фоновые задачи.

Практические советы для Python

Gunicorn и ресурсы: Если вы запускаете Gunicorn с 4 воркерами (-w 4), помните, что потребление памяти умножается на 4 (с учетом механизма Copy-on-Write, но все же). Requests по CPU должны учитывать сумму потребностей всех воркеров.

Java vs Python: В отличие от Java (где нужно настраивать Heap Size -Xmx), Python забирает память динамически. Лимит в K8s — это единственный способ ограничить аппетиты Python.

Утечки памяти: Если вы видите частые OOMKilled, не спешите просто поднимать лимиты. Возможно, в вашем коде утечка памяти (незакрытые соединения, глобальные списки). Используйте профилировщики (например, memray).

Резюме

Используйте Liveness Probe, чтобы перезапускать зависшие процессы, но не проверяйте в ней внешние зависимости.

Используйте Readiness Probe, чтобы не пускать трафик на непрогретое приложение.

Всегда указывайте Requests, чтобы планировщик мог корректно разместить Pod.

Указывайте Limits для памяти, чтобы один багованный сервис не положил всю ноду.

Для Python-сервисов класс Burstable (requests < limits) обычно является оптимальным выбором.

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

Продвинутый деплой: шаблонизация через Helm и построение CI/CD пайплайнов

В предыдущих частях курса мы прошли путь от написания Dockerfile до настройки Ingress и Liveness Probes. К этому моменту у вас должен быть набор YAML-манифестов: deployment.yaml, service.yaml, ingress.yaml, configmap.yaml и, возможно, secret.yaml.

Пока у вас одно приложение и одна среда (например, ваш локальный minikube), управлять этими файлами вручную через kubectl apply -f вполне терпимо. Но реальность Python-разработчика в продакшене выглядит иначе:

Много сред: Dev, Stage, Production. В каждой среде свои настройки (CPU/RAM, URL базы данных, количество реплик).

Много сервисов: Если вы переходите на микросервисы, копировать одни и те же YAML-файлы для 20 сервисов, меняя только имя образа — это нарушение принципа DRY (Don't Repeat Yourself).

Автоматизация: Никто не деплоит в продакшен с ноутбука разработчика. Это должна делать CI/CD система.

В этой статье мы решим проблему «YAML-ада» с помощью Helm и настроим автоматическую доставку кода в кластер через CI/CD.

Helm: Пакетный менеджер для Kubernetes

Если для Python стандартом управления пакетами является pip, то для Kubernetes это Helm.

Helm решает две главные задачи:

Шаблонизация: Позволяет создать один универсальный шаблон манифеста и подставлять в него значения (Values) в зависимости от среды.

Управление релизами: Позволяет устанавливать, обновлять и откатывать (rollback) версии приложения одной командой.

Анатомия Helm Chart

Пакет в терминологии Helm называется Chart (Чарт). Структура типичного чарта выглядит так:

Шаблонизация: Jinja2 на стероидах

Helm использует движок шаблонов языка Go, который синтаксически напоминает Jinja2 (знакомый вам по Django/Flask). Вы заменяете жестко прописанные значения на переменные.

Взглянем на пример templates/deployment.yaml:

А теперь посмотрим на файл values.yaml, где хранятся данные для этих переменных:

!Иллюстрация того, как Helm объединяет шаблоны и значения для генерации финальных манифестов.

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

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

Helm возьмет шаблоны, подставит значения из values.yaml и отправит итоговый YAML в Kubernetes API.

А если вам нужно задеплоить это же приложение в Production, но с другими настройками (больше реплик, другой уровень логов), вы не переписываете шаблоны. Вы просто создаете файл values-prod.yaml:

И обновляете релиз:

CI/CD: Автоматизация поставки

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

CI (Continuous Integration) — это сборка и тестирование кода. Для Python это обычно:

Linting (ruff, flake8).

Unit Tests (pytest).

Сборка Docker-образа.

CD (Continuous Delivery/Deployment) — это доставка собранного образа в кластер. Здесь в игру вступает Helm.

Стратегия тегирования образов

Одна из самых распространенных ошибок новичков — использование тега latest для деплоя.

> Никогда не используйте тег latest в продакшене. Это делает ваши деплои недетерминированными.

Если вы обновите код, пересоберете образ с тегом latest и скажете Kubernetes перезапустить Pod, кластер может не увидеть изменений, так как имя образа не поменялось (ImagePullPolicy часто стоит IfNotPresent).

Правильный подход: Использовать SHA-хеш коммита Git или семантическую версию в качестве тега.

Пример: my-app:a1b2c3d.

Типичный пайплайн (на примере GitHub Actions / GitLab CI)

Рассмотрим логическую схему пайплайна для Python-приложения в Kubernetes.

!Этапы автоматической доставки кода от коммита до обновления кластера.

#### Шаг 1: Сборка и Пуш (CI)

Сначала мы собираем Docker-образ и пушим его в реестр (Docker Hub, AWS ECR, GitLab Registry).

Обратите внимание: мы используем {GITHUB_SHA}».

bash helm upgrade ... --set env.DB_PASSWORD=${{ secrets.DB_PASSWORD }} bash helm rollback my-app ``

Эта команда вернет состояние всех ресурсов (Deployment, ConfigMap, Service) к предыдущей ревизии. Это возможно, потому что Helm хранит историю всех релизов в виде секретов внутри самого кластера.

GitOps: Будущее деплоя (ArgoCD)

Описанный выше метод называется Push-based (CI-система «толкает» изменения в кластер). Он прост и популярен, но имеет недостаток: CI-системе нужен полный доступ (admin kubeconfig) к вашему кластеру, что небезопасно.

Современный стандарт — GitOps (Pull-based).

В этом подходе:

CI только собирает образ и пушит его в реестр.

CI делает коммит в специальный git-репозиторий с конфигурацией (меняет тег в values.yaml).

Внутри кластера работает агент (например, ArgoCD или Flux).

Агент видит изменения в git-репозитории и сам применяет их к кластеру.

Это безопаснее (кластер не торчит наружу) и надежнее (Git становится единственным источником правды).

Резюме

Не используйте «голые» YAML-манифесты. Используйте Helm для шаблонизации и управления пакетами.

Выносите все изменяемые параметры (образы, реплики, ресурсы) в values.yaml.

Никогда не используйте тег latest. Тегируйте образы хешем коммита или версией.

Настройте CI/CD пайплайн, который автоматически собирает образ и вызывает helm upgrade.

Для управления секретами используйте переменные CI-системы и передавайте их через флаги --set` (или используйте External Secrets).

Теперь у вас есть полностью автоматизированный конвейер доставки кода. Но как понять, что происходит с приложением после деплоя? В следующей, заключительной части курса мы поговорим об Observability: сборе логов, метрик и трассировке Python-приложений в Kubernetes.