Как использовать ConfigMaps для конфигурации Kubernetes

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

Для чего нужны карты конфигурации?

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

ConfigMap позволяет вам управлять этими данными в выделенном ресурсе Kubernetes. Поды получают пары «ключ-значение» в виде переменных среды или файлов в смонтированном томе.

Для чего их не использовать?

В некоторых ситуациях ConfigMap нельзя использовать.

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

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

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

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

Значения ConfigMap могут быть либо строками UTF-8, либо двоичными данными, закодированными как строка base64. Имена клавиш могут содержать буквенно-цифровые символы, символы . (точка), - (дефис) и _ (подчеркивание). Некоторые языки программирования и фреймворки могут иметь другое соглашение для переменных конфигурации, поэтому убедитесь, что вы используете формат, который поддерживается как Kubernetes, так и вашим приложением.

Создание карты конфигурации

ConfigMaps имеют простые манифесты YAML. Для каждой ConfigMap требуется name в стандартном формате Kubernetes и поле data, содержащее ваши пары ключ-значение:

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-configmap
data:
  database_host: "192.168.0.10"
  system_email: "k8s@example.com"

Поле data предназначено для указания ключей со строковыми значениями. Вы можете использовать binaryData вместо этого или наряду с data для добавления двоичных значений в кодировке base64. Ключи должны быть уникальными как для data, так и для binaryData.

Примените манифест к своему кластеру с помощью kubectl или предпочитаемого вами инструмента.

Связывание ConfigMaps и модулей

ConfigMap ничего не делает сам по себе. Вы добавили некоторые данные в свой кластер; теперь давайте свяжем его с подом:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      image: example-image:latest
      envFrom:
        - configMapRef:
            name: example-configmap

Поле envFrom извлекает переменные среды, определенные другим ссылочным ресурсом. В этом случае configMapRef идентифицирует созданную ранее карту ConfigMap. Контейнеры пода будут запущены с определенными переменными среды database_host и system_email.

Выборочное добавление переменных среды

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

env:
  - name: DATABASE_HOST_IP
    valueFrom:
      configMapKeyRef:
        name: example-configmap
        key: database_host

В этом примере показано, как можно запустить модуль, используя только ключ database_host из ConfigMap. Ключ также переименовывается перед внедрением, поэтому модуль получит его как DATABASE_HOST_IP.

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

ConfigMaps можно монтировать как файлы внутри модулей. Kubernetes создает том, вставляет содержимое ConfigMap в виде набора файлов и монтирует том в ваш под.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      image: example-image:latest
      volumeMounts:
        - name: app-config
          mountPath: "/etc/config-data"
          readOnly: true
  volumes:
    - name: app-config
      configMap:
        name: example-configmap

Этот манифест модуля создает том с именем app-config. Поле configMap предварительно заполнит том, используя данные из указанного ConfigMap.

Pod монтирует том в /etc/config-data. Ваши контейнеры могут читать файлы в каталоге, чтобы получить доступ к вашим значениям конфигурации. Каждый ключ ConfigMap будет иметь свой собственный файл в точке подключения.

Обновление значений ConfigMap

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

Установленные тома

ConfigMaps, подключенные к модулям через том, будут обновлены Kubernetes. Изменения в ConfigMaps периодически проверяются; при обнаружении разницы файлы в вашем томе будут обновлены, поэтому ваш модуль получит новые данные. Задержка зависит от интервала синхронизации, настроенного для экземпляров Kubelet на ваших рабочих узлах.

Переменные среды

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

Вновь созданные поды всегда будут получать текущие данные ConfigMap, независимо от того, используете ли вы тома или переменные среды. Если вам нужно принудительно обновить конфигурацию, измените аннотацию в вашем поде, чтобы Kubernetes воссоздал его.

Неизменяемые карты конфигурации

В ConfigMap есть необязательное поле immutable, которое предотвращает их обновление. Когда это поле установлено, вы не можете обновить данные ConfigMap или удалить неизменяемый статус.

apiVersion: v1
kind: ConfigMap
metadata:
  name: immutable-configmap
data:
  foo: bar
immutable: true

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

Краткое содержание

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

Пароли и другие учетные данные принадлежат секретам. Они функционируют очень похоже на ConfigMaps, и модули ссылаются на них таким же образом. Замените configMapRef на secretRef, чтобы получить ключ из именованного секрета вместо ConfigMap.