Примеры использования ConfigMap в Kubernetes

Введение

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

Что такое ConfigMap в Kubernetes

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

Преимущества ConfigMap:

• Настройки можно менять отдельно от кода приложения.
• Обновления ConfigMap не требуют пересборки образов.
• Поддерживается интеграция с подами разными способами (через переменные окружения, файлы и аргументы командной строки).

Теперь шаг за шагом разберём основные сценарии применения ConfigMap.

Создание ConfigMap

В Kubernetes можно создавать ConfigMap разными способами. Я покажу вам, как это сделать с помощью манифеста и с помощью команды kubectl.

Создание ConfigMap из файла YAML

Ниже пример манифеста, который создаёт ConfigMap с именем app-config. Здесь хранятся настройки в виде пар ключ-значение.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  ENV: production       # Указывает среду запуска
  LOG_LEVEL: info       # Уровень логирования

Для создания ConfigMap на основе манифеста нужно выполнить команду:

kubectl apply -f app-configmap.yaml

Создание ConfigMap через команду kubectl

Вы можете создать ConfigMap из командной строки, указывая параметры явно:

kubectl create configmap app-config \
  --from-literal=ENV=production \
  --from-literal=LOG_LEVEL=info

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

Использование ConfigMap в подах

Давайте посмотрим, как использовать созданный ConfigMap внутри подов. Существует три основных способа:

• Передача значений через переменные окружения.
• Монтирование ConfigMap как файлов внутри контейнера.
• Считывание значений ConfigMap через аргументы запуска приложения.

Пример 1. Использование ConfigMap в переменных окружения

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

apiVersion: v1
kind: Pod
metadata:
  name: example-pod-env
spec:
  containers:
    - name: demo-container
      image: busybox
      command: ["sh", "-c", "env | grep ^ENV; env | grep ^LOG_LEVEL"]
      envFrom:
        - configMapRef:
            name: app-config

Здесь ключи ENV и LOG_LEVEL появятся в переменных окружения контейнера.

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

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

Пример 2. Использование ConfigMap как файлов (монтирование)

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

apiVersion: v1
kind: Pod
metadata:
  name: example-pod-volume
spec:
  containers:
    - name: demo-container
      image: busybox
      command: ["cat", "/config/ENV", "/config/LOG_LEVEL"]
      volumeMounts:
        - name: config-volume
          mountPath: /config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

О чём важно помнить:

• Каждый ключ из ConfigMap станет отдельным файлом в директории /config.
• Имя файла совпадает с именем ключа, а содержимое — со значением.

Пример 3. Использование отдельных ключей из ConfigMap в переменных

Можно использовать не все значения, а только отдельные ключи из ConfigMap. Например:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod-key
spec:
  containers:
    - name: demo-container
      image: busybox
      command: ["sh", "-c", "echo $ENV"]
      env:
        - name: ENV
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: ENV

Здесь в переменную окружения ENV будет добавлено только значение ключа ENV из ConfigMap.

Пример 4. Использование ConfigMap для настройки приложения через файл конфигурации

Если вашему приложению требуется конфигурационный файл определённой структуры (например, YAML или JSON), просто создайте ConfigMap на основе такого файла:

kubectl create configmap nginx-config --from-file=nginx.conf

В результате ключом будет имя файла, а значением — его содержимое.

Далее монтируем эту конфигурацию в под:

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

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

Особенности работы с ConfigMap

Обновление ConfigMap и отклик подов

ConfigMap является отдельным объектом и его можно редактировать командой:

kubectl edit configmap app-config

Или можно заменить ConfigMap, загрузив изменённый конфиг. Изменения применяются к новым подам сразу, а для уже работающих возможны два варианта:

• Если ConfigMap монтируется через volume — изменения становятся видны в контейнере независимо от перезапуска пода (через некоторое время).
• Если значения передаются через переменные окружения — перезапуск пода необходим, чтобы новые значения подхватились.

Использование ConfigMap совместно с Deployment

Рассмотрим пример интеграции ConfigMap с Deployment. Это удобно для обновлений при выкатывании новых версий:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
        - name: demo-container
          image: busybox
          command: ["sh", "-c", "echo $LOG_LEVEL"]
          envFrom:
            - configMapRef:
                name: app-config

Как обновить поды при изменении ConfigMap

Когда вы обновили ConfigMap, уже запущенные поды, получающие данные через переменные окружения, автоматически НЕ получают новые значения. Чтобы "применить" их, перезапустите поды, например так:

kubectl rollout restart deployment demo-deployment

Иначе новые значения подхватят только новые поды.

Передача параметров через аргументы запуска

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

apiVersion: v1
kind: Pod
metadata:
  name: example-args-pod
spec:
  containers:
    - name: arg-demo
      image: busybox
      command:
        - sh
        - -c
        - "echo Управляющий параметр: $PARAM"
      env:
        - name: PARAM
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: LOG_LEVEL

Здесь значение LOG_LEVEL будет доступно внутри скрипта как переменная окружения, которую можно передать в команды.

Более сложные шаблоны использования

ConfigMap гибко используется в комбинации с другими объектами Kubernetes:

• Хранение шаблонов конфигураций, которые подставляются через сторонние процессы (например, с помощью envsubst).
• Обеспечение fallback-настроек: если ключ отсутствует — используется дефолтное значение.
• Монтирование только определённых ключей как файлов (выборочно).

Пример — монтирование только одного файла по другому имени:

apiVersion: v1
kind: Pod
metadata:
  name: custom-mount-pod
spec:
  containers:
    - name: single-key-demo
      image: busybox
      command: ["cat", "/custom/config.env"]
      volumeMounts:
        - name: custom-config
          mountPath: /custom/config.env
          subPath: ENV         # Только ключ ENV
  volumes:
    - name: custom-config
      configMap:
        name: app-config

Такой подход удобен, когда приложению нужен конкретный файл или имя.

Валидация и обработка ошибок при работе с ConfigMap

Имейте в виду, что:

• Если монтировать ConfigMap как том, но значение ещё не создано, под не запустится, пока ConfigMap не будет создан.
• Если в manifest вы ссылаетесь на ключ в ConfigMap, а такого ключа нет, под также не стартует.
• Убедитесь, что не забыли обновить или пересоздать поды после правок ConfigMap (как уже обсуждали ранее).

Интеграция с секретами (Secret) и отличие

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

Использование ConfigMap в различных средах

В production-средах часто применяют следующий подход:

• Хранят источники конфигурации в Git или другом репозитории и используют в pipeline для автоматического создания/обновления ConfigMap через kubectl, Helm или CI/CD-систему.
• Используют разные ConfigMap для разных сред — test, staging, prod (разделяя с помощью namespace).

Ограничения при работе с ConfigMap

• Объём одного ConfigMap ограничен 1 МБ.
• ConfigMap не поддерживает байтовые данные, только строки.
• Не храните секретную информацию в ConfigMap.

Заключение

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

Частозадаваемые технические вопросы по теме статьи и ответы на них

Как обновить ConfigMap и убедиться, что поды подхватили изменения без ручного перезапуска?

Для этого используйте автоматизацию через аннотацию. Добавьте к Deployment аннотацию с хешем ConfigMap (например, через CI/CD). При изменении значения аннотации поды автоматически перезапустятся. Пример:

spec:
  template:
    metadata:
      annotations:
        configmap-hash: "<сюда запишите хеш текущего ConfigMap>"

Хеш обновляется скриптом или с помощью шаблонизатора (kustomize, Helm).

Можно ли использовать один ConfigMap в разных namespace?

Нет, ConfigMap "видим" только в пределах своего namespace. Если требуется одинаковая конфигурация в нескольких namespace, создайте копии ConfigMap в каждом или автоматизируйте развёртывание ними.

Как ограничить доступ к значениям ConfigMap для приложений в одном кластере?

ConfigMap не имеет средств контроля доступа на уровне значения. Используйте разные namespace для разграничения или перейдите на Secret и RBAC-политику, если нужна приватность.

Что происходит при удалении ConfigMap, к которой уже примонтирован под?

Если ConfigMap удалён, то:

• При монтировании через volume — содержимое файлов станет недоступным (под сообщает ошибку).
• При использовании через env — уже запущенные поды продолжают работать (у них "копия" значений в окружении).

Как быть, если значение в ConfigMap превышает лимит в 1 МБ?

Разбейте большую конфигурацию на несколько ConfigMap по логическим частям. Если невозможно — рассмотрите хранение файла в объекте PersistentVolume или использование другого хранилища (например, blob-хранилищ).