ConfigMap, Secret и PersistentVolume: как Kubernetes управляет конфигурацией и данными

Практически любое приложение нуждается во внешних настройках: адресах баз данных, паролях, API-ключах, токенах. Если зашить всё это внутрь Docker-образа, сопровождение превращается в головную боль, а безопасность — в иллюзию. Kubernetes решает эту проблему через три специализированных механизма: ConfigMap, Secret и PersistentVolume.

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

Представьте: база данных переехала на другой сервер. Если адрес подключения зашит в образ, придётся изменить конфиг, пересобрать образ, загрузить его в Registry и накатить обновление в кластере — и всё это ради одного параметра.

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

Отдельная история — пароли и токены. Если они попали внутрь образа или в репозиторий Git, любой человек с доступом к коду или Registry может их прочитать. Именно для разделения кода, конфигурации и секретов Kubernetes предоставляет специальные объекты.

ConfigMap: конфигурация отдельно от кода

ConfigMap — объект Kubernetes для хранения обычных, несекретных настроек приложения в виде пар «ключ — значение». Типичное содержимое: адреса сервисов, номера портов, режим работы, пути к директориям, параметры логирования.

Пример манифеста:

yaml apiVersion: v1 kind: ConfigMap metadata: name: app-config data: APP_ENV: production DB_HOST: postgres DB_PORT: "5432" LOG_LEVEL: info

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

Второй подход особенно востребован для приложений, которые читают конфигурацию из файлов, а не из переменных окружения: Nginx, Prometheus, Grafana, PostgreSQL, различные Java-сервисы. Смена конфига в этом случае не требует пересборки образа — достаточно обновить ConfigMap.

Secret: секреты и важный нюанс про Base64

Для хранения чувствительных данных — паролей, токенов, SSH-ключей, TLS-сертификатов, API-ключей — предназначен объект Secret. По интерфейсу он похож на ConfigMap: те же два способа передачи данных в контейнер (переменные окружения или монтирование файлов).

Пример:

yaml apiVersion: v1 kind: Secret metadata: name: db-secret type: Opaque stringData: username: admin password: Passpass

Здесь важно развеять распространённое заблуждение. Многие считают, что Kubernetes автоматически шифрует содержимое Secret. Это не так. По умолчанию значения хранятся в кодировке Base64 — а это кодирование, а не шифрование. Любой, кто получит доступ к объекту, сможет мгновенно декодировать значение.

Для полноценной защиты секретов используют дополнительные инструменты:

• HashiCorp Vault — популярное решение для централизованного управления секретами, широко применяется в корпоративных инсталляциях, в том числе в компаниях ПВТ;
• AWS Secrets Manager, Azure Key Vault, Google Secret Manager — облачные варианты для соответствующих платформ;
• шифрование данных непосредственно в хранилище etcd на уровне кластера.

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

PersistentVolume: данные, которые переживают Pod

ConfigMap и Secret решают вопрос конфигурации. Но у приложений есть ещё одна потребность — хранить данные, которые не исчезнут при перезапуске или переносе Pod на другой узел.

Обычный Volume в Kubernetes привязан к жизненному циклу Pod: удалили Pod — потеряли данные. Для баз данных, файловых хранилищ и любых сервисов с состоянием это неприемлемо.

Для решения этой задачи существуют три взаимосвязанных объекта.

PersistentVolume (PV) — независимый том хранения, который существует отдельно от приложений. Его можно представить как виртуальный диск: он продолжает существовать даже после удаления Pod. PV может использовать локальный диск сервера, Amazon EBS, Google Persistent Disk, Azure Disk, Ceph и другие системы хранения.

PersistentVolumeClaim (PVC) — запрос от приложения на получение хранилища. Разработчику не нужно знать, где физически лежат данные: он просто описывает потребность («нужен диск 10 ГиБ»), а Kubernetes сам находит подходящий PV и связывает их.

StorageClass — описание того, как Kubernetes должен создавать новые тома: SSD, HDD, высокопроизводительные NVMe или сетевые файловые системы. Когда создаётся PVC, StorageClass позволяет автоматически выделить новый PV нужного типа — этот механизм называется Dynamic Provisioning. В современных облачных платформах создавать диски вручную обычно не требуется.

Полная цепочка выглядит так: Pod → PVC → StorageClass → PV → физическое хранилище. Если Pod удаляется или переносится на другой узел, Kubernetes снова подключает тот же PV через PVC — данные остаются доступными.

При создании PV и PVC важно выбрать правильный режим доступа. ReadWriteOnce — том подключается для чтения и записи только к одному узлу, стандартный вариант для баз данных. ReadOnlyMany — несколько узлов читают одновременно, запись запрещена. ReadWriteMany — несколько узлов читают и пишут одновременно, используется сетевыми файловыми системами.

Практика: kubectl и первое приложение в Minikube

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

kubectl не управляет контейнерами напрямую: каждая команда уходит в Kubernetes API Server, который входит в состав Control Plane, а дальше работают компоненты кластера. Это означает, что одной утилитой можно управлять и локальным кластером, и удалёнными в облаке.

Для подключения к нужному кластеру kubectl использует файл kubeconfig (~/.kube/config). Внутри него хранятся адреса API Server, данные аутентификации и список контекстов. Контекст — это сохранённый набор параметров: какой кластер, какой пользователь, какой Namespace использовать по умолчанию. Переключение между контекстами критично при работе с несколькими окружениями: случайно выполнить команду в продакшне вместо тестового стенда — классическая ошибка.

Для локального обучения и экспериментов оптимален Minikube — инструмент, запускающий полноценный Kubernetes-кластер на одном компьютере. Он бесплатен, поддерживает Linux, Windows и macOS и включает все основные компоненты Kubernetes. Для запуска достаточно установленного Docker и свободных 20 ГБ на диске.

После старта кластера командой minikube start можно развернуть первое приложение буквально двумя командами:

bash kubectl create deployment nginx --image=nginx kubectl expose deployment nginx --port=80 --type=NodePort minikube service nginx

Kubernetes сам создаст Deployment, ReplicaSet и Pod, загрузит образ Nginx и откроет страницу приветствия в браузере.

Для диагностики проблем чаще всего используют четыре команды: kubectl describe pod <name> — подробная информация и события Pod; kubectl logs <name> — логи приложения; kubectl exec -it <name> -- sh — подключение внутрь контейнера; kubectl get events — события всего кластера. В большинстве случаев этого достаточно, чтобы найти причину неисправности.

Полный путь приложения в Kubernetes выглядит так: Dockerfile → сборка образа → Container Registry → kubectl apply → Deployment → ReplicaSet → Pod → Service → Ingress → пользователь. Понимание этой цепочки — основа работы DevOps-инженера с современными контейнерными платформами.