Конфигурация приложений в Kubernetes: ConfigMap и Secret

Философия Cloud Native: почему конфигурация должна быть отделена от артефакта

Представьте ситуацию: вы написали отличный микросервис, упаковали его в Docker-образ и развернули в production. Внезапно служба безопасности сообщает, что пароль от базы данных скомпрометирован и его нужно сменить прямо сейчас. Если пароль «зашит» в коде приложения или внутри самого Docker-образа, вам придется менять код, запускать CI/CD пайплайн, ждать сборки нового образа, прогонять тесты и только потом обновлять приложение. Это может занять от 15 минут до нескольких часов. В мире Cloud Native такой подход недопустим.

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

Артефакт должен быть неизменяемым

В традиционной разработке часто можно было встретить ситуацию, когда для тестовой среды (Dev) собирался один билд приложения, а для боевой (Prod) — совершенно другой, с другими файлами настроек внутри.

В парадигме Cloud Native мы оперируем понятием артефакта. В контексте Kubernetes артефакт — это ваш Docker-образ. Главное правило работы с артефактами: образ должен быть неизменяемым (immutable).

Вы собираете образ ровно один раз. Этот же самый образ, с тем же самым хэшем (SHA256), должен последовательно проходить через все среды: от компьютера разработчика до production-кластера.

Если образ неизменяем, как заставить его подключаться к тестовой базе данных в среде Dev и к боевой базе данных в среде Prod? Ответ кроется в строгом разделении кода и конфигурации.

Методология The Twelve-Factor App

В 2011 году инженеры платформы Heroku сформулировали методологию «Приложение двенадцати факторов» (The Twelve-Factor App) — свод правил для создания масштабируемых веб-приложений. Третий фактор этой методологии посвящен конфигурации.

Конфигурация — это всё, что может меняться между средами развертывания (staging, production, developer environments). Двенадцатифакторное приложение требует строгого разделения конфигурации и кода.

The Twelve-Factor App

Как проверить, правильно ли ваше приложение работает с конфигурацией? Задайте себе один вопрос: «Могу ли я прямо сейчас выложить исходный код своего приложения в открытый доступ на GitHub, не скомпрометировав при этом никаких паролей, ключей или внутренних адресов?» Если ответ «нет», значит, конфигурация смешана с кодом.

Что относится к артефакту, а что — к конфигурации?

Чтобы не путаться, давайте разделим эти сущности.

Сущность	Артефакт (Docker-образ)	Конфигурация (Внешняя среда)
Суть	Логика работы, код, зависимости.	Данные, зависящие от окружения.
Примеры	Исполняемый файл, статические картинки, CSS-стили, дефолтные шаблоны.	URL базы данных, пароли, API-ключи внешних сервисов, уровень логирования (DEBUG/INFO).
Изменяемость	Read-only. Изменяется только через пересборку (новый коммит).	Динамическая. Можно изменить без пересборки кода.

Инъекция конфигурации в Kuberentes

Если конфигурации нет в образе, она должна попадать туда извне. В Cloud Native архитектуре работает простой принцип:

Контейнер = Образ + Конфигурация

Когда Kubernetes запускает ваш контейнер (внутри сущности, которая называется Pod), он берет неизменяемый образ и «впрыскивает» (inject) в него нужную конфигурацию. Приложение стартует, читает предоставленные настройки и начинает работать в контексте текущей среды.

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

Переменные окружения (Environment Variables): Простой и нативный способ, который поддерживается любым языком программирования. Приложение при старте читает переменные вроде DB_HOST или API_KEY.
Файлы (Volumes): Иногда конфигурация слишком сложна для переменных окружения (например, это большой XML/JSON файл, сертификат tls.crt или конфиг Nginx). В этом случае Kubernetes может создать виртуальный файл из конфигурации и подмонтировать его прямо в файловую систему контейнера.

Как это реализовано в Kubernetes?

Kubernetes предоставляет два специальных API-объекта для хранения конфигурации отдельно от Pod'ов:

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

Вместо того чтобы хардкодить DB_HOST=prod-db.example.com в конфигурации самого Pod'а, вы создаете объект ConfigMap. Затем вы говорите Pod'у: «При запуске возьми значение для переменной DB_HOST из вот этого ConfigMap».

Такой подход дает невероятную гибкость. Если адрес базы данных изменится, вам не нужно пересобирать Docker-образ. Вам даже не нужно менять манифест самого Pod'а. Вы просто обновляете ConfigMap, и приложение (после перезапуска) подхватывает новые настройки.

В следующих главах мы подробно разберем анатомию ConfigMap и Secret, заглянем под капот их хранения в etcd и научимся на практике пробрасывать переменные и файлы в работающие контейнеры.

ConfigMap: анатомия, хранение данных в etcd и способы передачи в Pod

Мы уже выяснили, что хардкодить настройки в Docker-образ — плохая практика. Артефакт должен оставаться неизменным, а конфигурация должна подаваться снаружи в момент запуска. В Kubernetes главным инструментом для хранения неконфиденциальной конфигурации выступает объект ConfigMap.

В этой статье мы разберем, как устроен этот объект, где он физически хранится в кластере и какими способами kubelet доставляет его содержимое внутрь контейнера.

Анатомия ConfigMap

ConfigMap — это API-объект Kubernetes, который хранит конфигурационные данные в виде пар «ключ-значение».

С точки зрения синтаксиса, это простой YAML-манифест:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: default
data:
  # Простые переменные
  LOG_LEVEL: "debug"
  MAX_CONNECTIONS: "100"

  # Целые конфигурационные файлы
  application.properties: |
    server.port=8080
    database.timeout=30s
    feature.toggles.new_ui=true

Ключевой блок здесь — data. В нем ключами могут выступать как имена переменных (LOG_LEVEL), так и названия файлов (application.properties). Значения всегда являются строками. Если вам нужно сохранить бинарные данные (например, скомпилированный плагин или небольшую картинку), используется блок binaryData, где содержимое кодируется в base64.

Под капотом: хранение в etcd и жесткие лимиты

Когда вы выполняете команду kubectl apply -f config.yaml, манифест отправляется в kube-apiserver. API-сервер валидирует объект и сохраняет его в etcd — распределенном хранилище типа «ключ-значение», которое является мозгом и базой данных всего кластера Kubernetes.

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

По умолчанию максимальный размер одного объекта в etcd ограничен 1 МБ. Это означает, что размер одного ConfigMap не может превышать 1 Мегабайт.

Если ваша конфигурация весит больше 1 МБ (например, это огромный XML-файл с правилами маршрутизации или дамп данных), ConfigMap вам не подойдет. Для таких задач используют внешние хранилища (S3), базы данных или специализированные тома (Volumes).

Способы инъекции: как данные попадают в Pod

Сам по себе ConfigMap просто лежит в базе данных кластера. Чтобы приложение смогло им воспользоваться, данные нужно «пробросить» (сделать инъекцию) внутрь Pod.

За этот процесс отвечает kubelet — агент Kubernetes, работающий на каждой рабочей ноде. Когда kubelet получает задачу запустить Pod, он обращается к API-серверу, скачивает нужный ConfigMap и подготавливает среду для контейнера.

Существует два основных способа инъекции.

Способ 1: Переменные окружения (Environment Variables)

Этот метод идеально подходит для небольших настроек: флагов, URL-адресов, уровней логирования.

Вы можете пробросить конкретный ключ из ConfigMap в конкретную переменную окружения контейнера:

apiVersion: v1
kind: Pod
metadata:
  name: web-app
spec:
  containers:
    - name: my-app
      image: my-app:1.0
      env:
        - name: APP_LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: LOG_LEVEL

Или можно импортировать все ключи из ConfigMap разом с помощью envFrom:

      envFrom:
        - configMapRef:
            name: app-config

Особенности метода: Переменные окружения считываются процессом только один раз — в момент старта. Если вы измените ConfigMap в кластере, переменные внутри уже работающего контейнера не обновятся. Чтобы приложение увидело новые значения, Pod придется перезапустить.

Способ 2: Монтирование как файлы (Volumes)

Если ваше приложение ожидает конфигурационный файл (например, nginx.conf или application.properties), переменные окружения не помогут. В этом случае ConfigMap монтируется как файловая система.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
    - name: nginx
      image: nginx:alpine
      volumeMounts:
        - name: config-volume
          mountPath: /etc/nginx/conf.d
  volumes:
    - name: config-volume
      configMap:
        name: app-config

Как это работает:

В секции volumes мы объявляем том с именем config-volume, источником которого является наш ConfigMap.
В секции volumeMounts контейнера мы указываем, что этот том нужно примонтировать в директорию /etc/nginx/conf.d.
kubelet создает на ноде временную файловую систему (tmpfs), записывает туда ключи из ConfigMap в виде файлов (имя файла = ключ, содержимое файла = значение) и пробрасывает эту директорию в контейнер.

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

Диагностика ошибок (Troubleshooting)

Самая частая ошибка при работе с конфигурациями — опечатка в имени ConfigMap или попытка запустить Pod до создания самой конфигурации.

По умолчанию ConfigMap является обязательным. Если вы описали в Pod зависимость от ConfigMap, которого нет в кластере, kubelet не сможет запустить контейнер.

Вы увидите статус Pod как CreateContainerConfigError. Чтобы понять причину, используйте команду описания Pod:

kubectl describe pod <имя-пода>

В конце вывода, в разделе Events, будет четко указано: Warning Failed ... Error: configmap "app-config" not found

Если вы хотите, чтобы Pod стартовал даже при отсутствии конфигурации (например, приложение умеет использовать дефолтные настройки), в манифесте нужно явно указать optional: true:

      envFrom:
        - configMapRef:
            name: app-config
            optional: true

Практическое задание

Чтобы закрепить материал, выполните этот сценарий в вашем тестовом кластере:

Создайте файл index.html с текстом "Hello from ConfigMap!".
Создайте из него ConfigMap с помощью команды: kubectl create configmap custom-page --from-file=index.html
Напишите YAML-манифест для Pod с образом nginx:alpine.
Примонтируйте созданный ConfigMap как Volume в директорию /usr/share/nginx/html.
Запустите Pod и пробросьте порт (kubectl port-forward pod/<имя> 8080:80), чтобы убедиться, что Nginx отдает вашу кастомную страницу, а не стандартную заглушку.

Разделив приложение (стандартный образ Nginx) и конфигурацию (ваш HTML-файл), вы сделали первый практический шаг в сторону Cloud Native архитектуры. В следующей главе мы поговорим о том, что делать, если в конфигурации нужно передать не просто HTML-страничку, а пароль от базы данных или TLS-сертификат.

Secret: механизмы защиты, base64-кодирование и отличия от ConfigMap

Мы умеем пробрасывать конфигурацию в Pod, отделяя её от артефакта. Но если поместить пароль от базы данных или TLS-сертификат в обычный ConfigMap, возникает критическая уязвимость. Любой инженер с правами на чтение ConfigMap или злоумышленник, получивший доступ к резервной копии etcd, увидит эти данные в открытом виде. Для чувствительной информации в Kubernetes существует отдельный объект — Secret.

Иллюзия безопасности: зачем нужен Base64

Если вы создадите стандартный Secret (тип Opaque) и посмотрите его YAML-манифест, вы увидите, что значения выглядят как случайный набор символов.

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  password: c3VwZXJzZWNyZXQ=

Главная ловушка для новичков — считать, что строка c3VwZXJzZWNyZXQ= зашифрована. Это не шифрование, это Base64-кодирование. Любой человек может декодировать её одной командой в терминале: echo "c3VwZXJzZWNyZXQ=" | base64 -d, получив исходное слово supersecret.

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

Kubernetes API общается в формате JSON. JSON отлично справляется с обычным текстом, но ломается, если попытаться передать через него бинарные данные (например, скомпилированный .p12 сертификат или ключ SSH, содержащий специфические символы переноса строк). Base64 переводит любые байты в безопасный ASCII-алфавит.

За эту универсальность приходится платить объёмом. Размер закодированных данных вычисляется по формуле:

$S_{base64} = 4 \times \lceil \frac{S_{raw}}{3} \rceil$

Где $S_{raw}$ — размер исходных данных в байтах, а $\lceil \dots \rceil$ — округление вверх. На практике это означает, что Base64 увеличивает размер данных примерно на 33%. Учитывая жесткий лимит etcd в 1 МБ на объект, реальный максимальный размер полезной нагрузки в Secret составляет около 700 КБ.

Как Secret защищается на самом деле

Если Base64 не защищает данные, то почему Secret считается безопасным? Разница между ConfigMap и Secret кроется на более низком уровне архитектуры кластера: в том, как данные хранятся на дисках.

1. Уровень Control Plane: Encryption at Rest

По умолчанию kube-apiserver сохраняет Secret в базу данных etcd точно так же, как и ConfigMap — в виде обычного текста (точнее, в Base64, что равносильно тексту). Если кто-то украдет файл .db с сервера etcd, он получит все пароли.

Чтобы Secret стал действительно секретным в хранилище, администратор кластера должен включить Encryption at Rest (шифрование в покое). Это конфигурация на уровне kube-apiserver, которая заставляет его прозрачно шифровать данные (например, алгоритмом AES-CBC) перед записью в etcd и расшифровывать при чтении в память. ConfigMap при этом шифроваться не будет — это экономит ресурсы процессора на Control Plane.

2. Уровень Worker Node: tmpfs

Когда Pod запускается на узле, компонент kubelet должен передать ему конфигурацию. Если вы монтируете Secret как Volume, kubelet создает файловую систему в оперативной памяти — tmpfs.

Секретные файлы существуют только в RAM узла. Они никогда не записываются на физический жесткий диск (SSD/HDD) Worker-узла. Если сервер внезапно обесточить, данные исчезнут бесследно. ConfigMap, напротив, может кэшироваться на постоянном хранилище узла.

Практика: stringData против data

Работать с Base64 вручную при написании YAML-манифестов неудобно. Kubernetes предлагает синтаксический сахар — поле stringData. Оно позволяет писать секреты в открытом виде прямо в манифесте.

apiVersion: v1
kind: Secret
metadata:
  name: api-keys
type: Opaque
stringData:
  api-token: "12345-abcde"

Когда вы отправляете этот манифест в кластер, kube-apiserver автоматически переведет содержимое stringData в Base64, поместит его в поле data, а само поле stringData удалит. Если вы запросите этот Secret обратно через kubectl get secret api-keys -o yaml, вы увидите только поле data с закодированным значением.

ConfigMap vs Secret: сводная таблица

Характеристика	ConfigMap	Secret
Назначение	Неконфиденциальные настройки, URL, флаги	Пароли, токены, SSH-ключи, TLS-сертификаты
Формат в манифесте	Обычный текст (`data`)	Base64 (`data`) или текст (`stringData`)
Хранение на узле (Volume)	Может сохраняться на диск	Строго в оперативной памяти (`tmpfs`)
Хранение в etcd	Открытый текст	Может быть зашифровано (Encryption at Rest)
Лимит размера	1 МБ	1 МБ (с учетом +33% налога Base64)

Разделение на два разных объекта позволяет применять разные политики доступа (RBAC). Вы можете разрешить разработчику читать ConfigMap в пространстве имен, но запретить чтение Secret, исключив утечку production-паролей.

Механизмы обновления: как kubelet синхронизирует изменения в Volume и Env

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

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

Две парадигмы: статика переменных и динамика томов

Когда вы передаете конфигурацию в Pod, вы выбираете один из двух путей: переменные окружения (env, envFrom) или файловые тома (volumes). Этот выбор определяет не только то, как приложение прочитает данные при старте, но и то, что произойдет при их изменении.

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

В операционных системах семейства Linux (на которых работают контейнеры) переменные окружения передаются процессу в момент его запуска системным вызовом execve. Процесс получает копию окружения.

Если вы измените ConfigMap или Secret, на который ссылается запущенный Pod через envFrom, внутри контейнера ничего не произойдет. kubelet физически не может внедрить новые переменные в память уже работающего процесса.

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

Тома (Volumes): динамическое обновление файлов

Если же ConfigMap или Secret примонтирован как файловый том (Volume), картина меняется. kubelet периодически опрашивает API-сервер на предмет изменений. Обнаружив новую версию объекта, он обновляет файлы прямо внутри работающего контейнера.

Но здесь возникает инженерная проблема: что если приложение начнет читать файл конфигурации ровно в ту миллисекунду, когда kubelet его перезаписывает? Приложение прочитает половину старого файла и половину нового, получит невалидный JSON или YAML и упадет с ошибкой.

Чтобы избежать состояния гонки (race condition), kubelet использует механизм атомарного обновления через символические ссылки (symlinks).

Магия симлинков: как kubelet обновляет файлы безопасно

Если вы зайдете внутрь контейнера (через kubectl exec) и посмотрите на директорию, куда примонтирован ConfigMap, вы увидите не просто файлы, а сложную структуру ссылок.

Допустим, мы примонтировали ConfigMap в /etc/config. Структура внутри будет выглядеть так:

..data — это символическая ссылка, которая указывает на скрытую директорию с временной меткой (например, ..2023_10_25_14_30_00.123456789).
Внутри директории с временной меткой лежат реальные файлы конфигурации (например, app.json).
Файл /etc/config/app.json — это символическая ссылка, указывающая на ..data/app.json.

Когда ConfigMap обновляется в etcd, kubelet делает следующее:

Создает новую скрытую директорию с новой временной меткой и записывает туда обновленные файлы. На этом этапе старые файлы всё ещё используются, приложение ничего не замечает.
Изменяет симлинк ..data так, чтобы он указывал на новую директорию. В Linux операция изменения симлинка является атомарной — она происходит за один такт файловой системы.
Удаляет старую директорию с временной меткой.

Благодаря этому механизму приложение всегда видит либо полностью старую, либо полностью новую конфигурацию.

Задержка обновления: почему это не происходит мгновенно

Даже при использовании томов обновление файлов не происходит в ту же секунду, когда вы нажали kubectl apply. Время доставки изменений зависит от двух факторов.

Максимальное время задержки можно описать формулой: $T_{delay} \leq T_{sync} + T_{cache}$

Где:

$T_{delay}$ — итоговое время задержки перед обновлением файла в контейнере.
$T_{sync}$ — период синхронизации kubelet (по умолчанию 1 минута). kubelet не держит постоянное соединение для каждого тома, он сверяет локальное состояние с желаемым раз в минуту.
$T_{cache}$ — время жизни кэша (TTL) в API-сервере. Чтобы не перегружать etcd, kubelet часто читает данные из локального кэша API-сервера, который тоже имеет свою задержку инвалидации.

В реальном production-кластере обновление файла в примонтированном томе может занимать от нескольких секунд до двух минут. Это нормальное поведение системы, которое нужно учитывать при проектировании архитектуры.

Ловушка subPath: когда динамическое обновление ломается

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

Часто разработчикам нужно пробросить только один файл конфигурации (например, nginx.conf) в директорию, где уже лежат другие важные файлы (например, /etc/nginx/). Если примонтировать том целиком в /etc/nginx/, он перекроет (скроет) всё содержимое этой директории. Чтобы этого избежать, используют subPath — монтирование конкретного ключа из ConfigMap как отдельного файла.

Но как только вы добавляете subPath в манифест, файлы перестают обновляться. Почему?

Дело в том, как kubelet реализует subPath на уровне операционной системы. Вместо создания структуры симлинков, он использует механизм Linux под названием bind mount (монтирование с привязкой). Bind mount привязывается не к имени файла, а к его inode — уникальному идентификатору файла на диске.

Когда ConfigMap обновляется, kubelet создает новый файл (с новым inode). Но bind mount внутри контейнера намертво привязан к старому inode. Контейнер будет вечно смотреть на удаленный/устаревший участок памяти, пока Pod не будет перезапущен.

Ответственность приложения

Важно понимать границу ответственности Kubernetes. Задача kubelet — безопасно обновить файл на диске внутри контейнера. На этом его работа заканчивается.

Kubernetes не посылает приложению сигнал о том, что файл изменился. Если ваше приложение (например, написанное на Java, Go или Python) читает конфигурационный файл только один раз при запуске и сохраняет значения в оперативной памяти, то обновление файла на диске ничего не изменит.

Чтобы приложение реагировало на обновления без перезапуска Pod, оно должно уметь "горячую перезагрузку" (Hot Reload). Для этого разработчики используют:

Опрос (Polling) — приложение само проверяет хэш файла раз в несколько секунд.
inotify — системный API Linux, который позволяет приложению подписаться на события изменения файлов в директории.

Если ваше приложение не умеет делать Hot Reload, единственный способ применить изменения — перезапустить Pod. В production для автоматизации этого процесса часто используют сторонние контроллеры (например, Reloader), которые следят за изменениями ConfigMap/Secret и автоматически инициируют Rolling Update для Deployment.

В следующей главе мы перейдем к вопросам диагностики. Мы разберем, как искать проблемы, если Pod не может запуститься из-за ошибок монтирования, и как правильно управлять секретами в production-среде, чтобы не скомпрометировать кластер.

Диагностика и безопасность: отладка ошибок доступа и управление секретами в Production

Вы написали идеальный манифест, применили его в кластере, но ваше приложение не отвечает. Вы проверяете статус и видите пугающее CrashLoopBackOff или CreateContainerConfigError. В production-среде цена каждой минуты простоя высока, а слепой перебор вариантов («а давайте удалим и создадим заново») — путь к катастрофе.

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

Анатомия сбоя: почему Pod не стартует

Взаимодействие Pod с ConfigMap и Secret может сломаться на двух принципиально разных этапах: до запуска контейнера (ошибка инфраструктуры) и после его старта (ошибка логики приложения).

Этап 1: Ошибка монтирования (CreateContainerConfigError)

Как мы разбирали ранее, kubelet отвечает за подготовку окружения. Если вы указали в манифесте Pod зависимость от ConfigMap или Secret, которых физически нет в кластере (или в данном Namespace), kubelet откажется запускать контейнер.

Симптом: статус Pod зависает в состоянии CreateContainerConfigError.

Главный инструмент диагностики на этом этапе — команда описания событий: kubectl describe pod <имя-пода>

В самом конце вывода, в секции Events, вы увидите причину. Например:

Warning Failed kubelet Error: configmap "my-app-config" not found

Решение: проверить наличие объекта (kubectl get configmap), убедиться, что нет опечаток в имени, и проверить, что объект находится в том же Namespace, что и Pod.

Этап 2: Ошибка приложения (CrashLoopBackOff)

Если kubelet успешно нашел конфигурацию, смонтировал тома и передал переменные окружения, он запускает контейнер. С точки зрения Kubernetes инфраструктурная задача выполнена.

Но если в ConfigMap указан неверный порт, или в Secret лежит устаревший пароль от базы данных, приложение внутри контейнера упадет с ошибкой (exit code $\neq 0$ ).

Kubernetes заметит падение и попытается перезапустить контейнер. Если приложение снова падает, Pod переходит в состояние CrashLoopBackOff. Задержка между перезапусками растет экспоненциально, чтобы не перегружать узел.

Время задержки вычисляется по формуле: $T_{delay} = \min(10 \times 2^{N-1}, 300)$ где $T_{delay}$ — время ожидания в секундах, а $N$ — количество падений подряд. Пример: после первого падения ( $N=1$ ) задержка составит $10 \times 2^0 = 10$ секунд. После пятого ( $N=5$ ) — $10 \times 2^4 = 160$ секунд. Максимальное время ожидания ограничено 300 секундами (5 минут).

Главный инструмент диагностики здесь — логи самого приложения: kubectl logs <имя-пода>

Здесь вы ищете ошибки уровня кода: Connection refused, Invalid credentials или Parse error in config.yaml.

Автоматизация обновлений: контроллер Reloader

В прошлой главе мы выяснили границу ответственности: Kubernetes обновляет файлы в примонтированных томах, но переменные окружения (env) остаются неизменными до перезапуска Pod. Более того, даже если файл обновился, приложение должно уметь перечитать его «на лету» (Hot Reload).

Что делать, если приложение не умеет перечитывать конфиги, или мы используем переменные окружения? Нам нужно перезапустить Pod. Делать это вручную (kubectl delete pod) в production недопустимо.

Здесь на сцену выходят сторонние контроллеры, стандартом де-факто среди которых стал Reloader (от компании Stakater).

Как работает Reloader

Reloader — это системный компонент, который работает в кластере и непрерывно наблюдает (watch) за изменениями ConfigMap и Secret.

Вы добавляете специальную аннотацию в ваш Deployment: reloader.stakater.com/auto: "true".
Вы меняете значение в ConfigMap и применяете его.
Reloader замечает изменение ConfigMap.
Он находит все Deployment, которые используют этот ConfigMap и имеют нужную аннотацию.
Reloader инициирует Rolling Update (плавное обновление) для этого Deployment.

В результате старые Pod плавно гасятся, а новые создаются уже с новыми значениями переменных окружения или файлов. Никакого ручного вмешательства и нулевой простой (Zero Downtime).

Безопасность: кто имеет право читать Secret?

Мы помним, что Base64 — это не шифрование, а механизм Encryption at Rest защищает данные только на жестком диске узла etcd. Если злоумышленник (или неопытный разработчик) имеет доступ к API Kubernetes, он может выполнить kubectl get secret -o yaml и прочитать пароли в открытом виде.

Для решения этой проблемы используется подсистема RBAC (Role-Based Access Control — управление доступом на основе ролей).

В RBAC доступ строится на двух основных объектах:

Role (Роль) — описывает, что можно делать. Это набор правил.
RoleBinding (Привязка роли) — связывает Роль с тем, кто это делает (пользователь, группа или сервисный аккаунт).

Разделение прав

В production-кластере права должны выдаваться по принципу минимальных привилегий. Разработчику обычно нужно смотреть логи и статус Pod, но ему не нужно читать Secret.

Ресурс (Resources)	Действие (Verbs)	Доступ разработчика
pods, pods/log	get, list, watch	Разрешено
configmaps	get, list, watch	Разрешено
secrets	get, list, watch	Запрещено

Создавая Роль без упоминания ресурса secrets, вы на уровне API-сервера блокируете возможность прочитать конфиденциальные данные. Если разработчик попытается запросить Secret, kube-apiserver отклонит запрос со статусом 403 Forbidden. При этом Pod, управляемый контроллером, продолжит беспрепятственно получать свои секреты, так как использует системный сервисный аккаунт.

Управление секретами в парадигме GitOps

Современный подход к управлению инфраструктурой — GitOps. Вся конфигурация кластера (включая манифесты ConfigMap и Secret) хранится в Git-репозитории. Специальный агент (например, ArgoCD) непрерывно синхронизирует состояние кластера с кодом в репозитории.

Здесь возникает фундаментальный конфликт: нельзя хранить пароли в Git, даже закодированные в Base64.

Как доставить секрет в кластер, не сохраняя его в Git? Для этого индустрия выработала паттерн с использованием внешних хранилищ (например, HashiCorp Vault, AWS Secrets Manager) и операторов внутри Kubernetes.

External Secrets Operator (ESO)

External Secrets Operator — это мост между внешним защищенным хранилищем и Kubernetes.

Как это работает:

Инженер безопасности создает пароль от БД напрямую в HashiCorp Vault. В Git этот пароль никогда не попадает.
Разработчик пишет манифест ExternalSecret (кастомный ресурс) и кладет его в Git. В этом манифесте нет самого пароля, там есть только ссылка: «возьми секрет по пути database/prod/password из Vault».
ArgoCD применяет ExternalSecret в кластер.
Контроллер ESO видит этот манифест, идет в Vault (используя строгую аутентификацию), забирает реальный пароль.
ESO автоматически создает стандартный объект Secret в Kubernetes.
Ваш Pod монтирует этот Secret точно так же, как мы делали это в предыдущих главах.

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

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

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

Распродажа в «Черную пятницу», нагрузка на биллинг выросла в десять раз. Администратор баз данных экстренно ротирует скомпрометированный пароль от PostgreSQL. Через минуту микросервис платежей начинает сыпать ошибками авторизации в БД. Пароль в Vault обновлен, но приложение об этом не знает — старый пароль застрял в памяти запущенных контейнеров. Чтобы восстановить работу, дежурному инженеру приходится вручную удалять Pod'ы. Каждая секунда простоя стоит тысячи USD.

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

Спроектируем production-ready архитектуру конфигурации для микросервиса payment-service, которая исключает подобные инциденты, объединяя все изученные ранее механизмы в единую систему.

Шаг 1: Декомпозиция требований приложения

Проектирование начинается не с написания YAML-манифестов, а с анализа того, как приложение потребляет данные. Наш payment-service требует четыре параметра:

DB_HOST — адрес базы данных. Меняется только при переезде инфраструктуры.
DB_PASSWORD — чувствительный пароль. Регулярно ротируется политиками безопасности.
LOG_LEVEL — уровень логирования. Требует оперативного переключения при инцидентах.
features.json — объемный файл с флагами доступности платежных шлюзов. Должен применяться без перезапуска приложения (Hot Reload), чтобы не прерывать текущие транзакции пользователей.

Если мы сложим всё это в один объект, мы создадим монолитную конфигурацию. Изменение флагов в features.json потребует перезапуска Pod, так как оркестратор не знает, какую именно часть монолита мы обновили.

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

Матрица принятия решений

Параметр	Тип данных	Источник истины	Способ доставки в Pod	Реакция на изменение
`DB_HOST`, `LOG_LEVEL`	Открытые	Git (репозиторий)	Переменные окружения	Перезапуск Pod
`DB_PASSWORD`	Секретные	Vault / AWS Secrets	Переменные окружения	Перезапуск Pod
`features.json`	Открытые	Git (репозиторий)	Файл (Volume)	Чтение на лету (inotify)

Исходя из матрицы, нам потребуются три независимых объекта Kubernetes:

ConfigMap для статических переменных.
Secret (управляемый через External Secrets Operator) для пароля.
Отдельный ConfigMap исключительно для файлов, требующих горячего обновления.

Шаг 2: Реализация инфраструктурного кода

Начнем с переменных окружения. Мы создаем payment-env-config для несекретных данных.

apiVersion: v1
kind: ConfigMap
metadata:
  name: payment-env-config
data:
  DB_HOST: "postgres-cluster.db.svc.cluster.local"
  LOG_LEVEL: "info"

Для пароля мы не создаем Secret напрямую. Мы декларируем ExternalSecret, который заберет пароль из корпоративного Vault и создаст нативный Secret с именем payment-db-credentials.

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: payment-db-sync
spec:
  refreshInterval: "1h"
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: payment-db-credentials # Имя итогового Secret
  data:
  - secretKey: DB_PASSWORD
    remoteRef:
      key: secret/payment/database
      property: password

Третий объект — конфигурация файловых флагов. Выносим её в отдельный ресурс payment-features-config.

apiVersion: v1
kind: ConfigMap
metadata:
  name: payment-features-config
data:
  features.json: |
    {
      "enable_crypto_gateway": false,
      "max_transaction_usd": 5000
    }

Шаг 3: Сборка Deployment и управление состоянием

Теперь свяжем объекты с приложением. Наша цель — автоматизировать реакцию системы на изменения.

Если меняется payment-env-config или payment-db-credentials (переменные окружения), Pod должен быть мягко перезапущен, так как процессы в Linux не могут перечитать переменные окружения после старта. Для этого мы используем контроллер Reloader.

Если меняется payment-features-config (файл в Volume), Pod не должен перезапускаться. Kubelet сам обновит файл через механизм симлинков, а приложение перечитает его.

Посмотрим на итоговый манифест Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
  annotations:
    # Reloader следит ТОЛЬКО за этими двумя объектами
    reloader.stakater.com/auto: "false"
    configmap.reloader.stakater.com/reload: "payment-env-config"
    secret.reloader.stakater.com/reload: "payment-db-credentials"
spec:
  replicas: 3
  selector:
    matchLabels:
      app: payment
  template:
    metadata:
      labels:
        app: payment
    spec:
      containers:
      - name: app
        image: payment-service:v2.4.0
        # 1. Инъекция переменных окружения
        envFrom:
        - configMapRef:
            name: payment-env-config
        - secretRef:
            name: payment-db-credentials
        # 2. Инъекция файлов
        volumeMounts:
        - name: features-volume
          mountPath: /app/config
          readOnly: true
      volumes:
      - name: features-volume
        configMap:
          name: payment-features-config

Обратите внимание на секцию volumeMounts. Мы монтируем директорию целиком (/app/config), не используя директиву subPath.

Жизненный цикл конфигурации в Production

Проследим, как эта архитектура ведет себя в реальных сценариях.

Сценарий 1: Ротация пароля БД.

Администратор меняет пароль в Vault.
External Secrets Operator (согласно refreshInterval) замечает изменение и обновляет объект payment-db-credentials (Secret) в кластере.
Reloader видит изменение хеша Secret, указанного в его аннотациях.
Reloader инициирует Rolling Update для Deployment.
Kubernetes плавно гасит старые Pod'ы и поднимает новые. Новые контейнеры стартуют, считывая уже новый пароль из Secret в свои переменные окружения. Даунтайм равен нулю.

Сценарий 2: Включение нового платежного шлюза.

Разработчик меняет enable_crypto_gateway на true в Git. CI/CD обновляет payment-features-config (ConfigMap).
Reloader игнорирует это событие, так как этот ConfigMap не указан в его аннотациях. Перезапуска Pod не происходит.
Kubelet на Worker-узлах замечает изменение объекта в etcd.
Спустя время $T_{sync}$ (задержка синхронизации) kubelet атомарно переключает симлинк ..data в директории /app/config/ внутри контейнеров.
Приложение, подписанное на события файловой системы через inotify, мгновенно перечитывает features.json. Транзакции пользователей не прерываются.

Изоляция отказов (Failure Isolation)

Спроектированная архитектура устойчива к отказам инфраструктурных компонентов. Что произойдет, если корпоративный Vault станет недоступен?

External Secrets Operator не сможет получить новый пароль. Однако он не удалит существующий нативный Secret payment-db-credentials. Deployment продолжит масштабироваться, а новые Pod'ы будут успешно запускаться со старым, но все еще рабочим паролем. Это принцип постепенной деградации (Graceful Degradation): отказ внешней системы управления конфигурацией не приводит к падению самого приложения.

Разделение конфигурации на независимые потоки (статичный Env и динамический Volume), делегирование работы с секретами специализированным операторам и автоматизация перезапусков там, где они действительно нужны — это стандарт проектирования Cloud Native приложений. Мы полностью абстрагировали код от среды выполнения, выполнив требования The Twelve-Factor App.