При выполнении контейнерирования часто возникает необходимость в управлении некоторыми конфигурациями извне контейнера. После загрузки контейнера с определенными предварительно сконфигурированными данными необходимо иметь способ, которым эти данные могут быть изменены во время выполнения, если это необходимо. Например, у нас могут быть разные конфигурации для разных сред развертывания, и мы можем захотеть использовать правильный набор конфигураций для целевой среды без повторного создания контейнера.
Kubernetes предоставляет, ConfigMapчтобы помочь настроить данные извне. Это следует парадигме дизайна — «отделение конфига от кода». API ConfigMap делает приложение переносимым. Конфигурация может быть изменена без повторного развертывания приложения.
ConfigMap
Ресурс Kuignetes ConfigMap содержит данные в виде пары ключ-значение. Это позволяет нам указывать данные конфигурации вне контейнера. Это разъединяет изображение и его конфигурацию. Любые изменения в configMap во время выполнения также отражаются в работающем контейнере. Следовательно, configMap является очень полезным инструментом в нескольких случаях использования, таких как:
- Установка переменных среды
- Установка аргументов командной строки в модуле
- Чтение файлов конфигурации с тома
Каждый из этих вариантов использования объясняется далее в этом посте.
Во-первых, давайте посмотрим на образец ConfigMap.
YAML
1
kindConfigMap
2
apiVersionv1
3
metadata
4
creationTimestamp2020-03-12T20105Z
5
namemy-configmap
6
namespacedefault
7
data
8
environment.variable.1value1
9
environment.variable1.2value2
10
external.property.file-
11
prop.1=value1
12
prop.2=value2
13
prop.3=value3
14
В приведенном выше примере данные поля содержат данные конфигурации. Как мы видим, он может содержать как отдельные свойства, так и содержимое из внешнего файла.
Создать ConfigMap
Давайте теперь начнем с создания configMap. Это можно сделать с помощью команды ниже:
xxxxxxxxxx
1
$ kubectl create configmap <name> <source>
где имя - это имя configMap, а источник - литеральное значение или файл, содержащий данные.
Чтобы заполнить configMap из литеральных значений, смотрите команду:
Оболочка
1
$ kubectl create configmap my-configmap --from-literal=property.1=value1 --from-literal=property.2=value2
Если у нас есть каталог, содержащий несколько файлов, используйте следующую команду:
Оболочка
xxxxxxxxxx
1
$ kubectl create configmap my-configmap --from-file=parentDir/container/configmap/
Чтобы увидеть детали уже созданного configMap, используйте следующую команду:
Оболочка
xxxxxxxxxx
1
$ kubectl describe configmaps my-configmap
Использование ConfigMap в модуле
Есть несколько вариантов использования, где configMap используется внутри спецификации Pod.
Для переменных среды
Если нам нужно установить значение переменной среды, объявленной в спецификации Pod, используя configMap, тогда мы можем выполнить следующие шаги.
Сначала создайте configMap:
Оболочка
xxxxxxxxxx
1
$ kubectl create configmap my-configmap --from-literal=property.1=value
Теперь создайте спецификацию pod (mypod.yaml):
YAML
xxxxxxxxxx
1
apiVersionv1
2
kindPod
3
metadata
4
namemy-pod
5
spec
6
containers
7
namemy-container
8
imagemy-image
9
env
10
# Here we define environment variable
11
nameENV_VARIABLE
12
valueFrom
13
configMapKeyRef
14
# Name the ConfigMap which has value for this env variable
15
namemy-configmap
16
# Name the key in the configMap which holds value of this env var
17
keyproperty.1
18
Теперь создайте стручок из вышеупомянутой спецификации.
xxxxxxxxxx
1
$ kubectl apply -f mypod.yaml
2
pod/my-pod created
Теперь, чтобы проверить, были ли созданы переменные среды.
Оболочка
xxxxxxxxxx
1
$ kubectl exec my-pod -it -- env | grep ENV_VARIABLE
2
ENV_VARIABLE =value
Нет необходимости устанавливать данные конфигурации только из одной карты конфигурации. Мы можем указать несколько configMaps и использовать их для установки различных переменных среды.
Допустим, у нас есть два configMaps, my-configmap1 и my-configmap2.
Затем мы можем использовать их следующим образом:
YAML
xxxxxxxxxx
1
apiVersionv1
2
kindPod
3
metadata
4
namemy-pod
5
spec
6
containers
7
namemy-container
8
imagehello-world
9
env
10
nameENV_VARIABLE_1
11
valueFrom
12
configMapKeyRef
13
namemy-configmap1
14
keyproperty.1
15
nameENV_VARIABLE_1
16
valueFrom
17
configMapKeyRef
18
namemy-configmap2
19
keyproperty.1
Для аргументов командной строки A Pod
Под спецификацией есть раздел команд. Мы можем установить эту команду из configMap, таким образом делая команду динамической. Смотрите ниже спецификации стручка:
YAML
xxxxxxxxxx
1
apiVersionv1
2
kindPod
3
metadata
4
namemy-pod
5
spec
6
containers
7
namemy-container
8
imagemy-hello-world
9
command "/bin/sh" "echo $(KEY)"
10
env
11
nameKEY
12
valueFrom
13
configMapKeyRef
14
namemy-configmap
15
keyproperty.1
Здесь, KEYсодержит значение property.1, определенное в configMap my-configMap.
Если мы используем том Kubernetes для модуля, а затем мы можем заполнить его, используя файлы, объявленные в configMap. Смотрите спецификацию стручка ниже:
YAML
xxxxxxxxxx
1
apiVersionv1
2
kindPod
3
metadata
4
namemy-pod
5
spec
6
containers
7
namemy-container
8
imagehello-world
9
volumeMounts
10
nametest-volume
11
mountPath/etc/myvolume
12
volumes
13
nametest-volume
14
configMap
15
# Name ConfigMap which contains list of files which will be populated in the voume
16
namemy-configmap
В приведенном выше примере данные my-configmap будут добавлены в том, указанный в volumeMounts.mountPath.
Заключение
В этом посте мы обсуждали, как мы можем использовать ресурс Kubernetes configMap для динамической установки данных конфигурации модулей, что позволяет отделить конфигурацию от кода.
Мы объяснили, как использовать configMap с помощью реальных фрагментов кода, которые можно легко использовать в вашем проекте.