Un ConfigMap es un recurso de Kubernetes para inyectar configuración en sus contenedores. Le permiten mantener la configuración de su pila por separado de su código. Aquí se explica cómo trabajar con ConfigMaps y suministrarlos a sus Pods.
¿Para qué sirven los ConfigMaps?
Los ConfigMaps están diseñados específicamente para encapsular pequeñas cantidades de datos de configuración no confidenciales. Son un mecanismo para obtener pares clave-valor arbitrarios en sus Pods. Se usan comúnmente para almacenar la dirección IP del servidor de su base de datos, la dirección de correo electrónico saliente para su aplicación y otras configuraciones específicas de la aplicación que necesita para poder configurarlas fuera de sus Pods.
El ConfigMap le permite administrar estos datos en un recurso de Kubernetes dedicado. Los pods reciben los pares clave-valor como variables de entorno o archivos en un volumen montado.
¿Para que no usarlos?
Hay algunas situaciones en las que un ConfigMap debería no ser utilizado.
Los ConfigMaps no se almacenan de forma segura y sus valores no tienen cifrado. No deben contener datos sensibles o confidenciales que puedan constituir un riesgo para la seguridad o la privacidad si se filtran.
No coloque contraseñas, claves de API o claves de cifrado en un ConfigMap; use un secreto de Kubernetes en su lugar, ya que funcionan de manera similar a ConfigMaps pero con protecciones adicionales. Los sistemas que necesitan una conexión a la base de datos deben colocar el nombre de host en un ConfigMap y las credenciales en un secreto separado.
Los ConfigMaps individuales no pueden exceder 1 MB de tamaño. Los sistemas que necesitan más claves de configuración pueden recibir un mejor servicio con un enfoque alternativo, como la inyección de archivos de configuración generados manualmente a través de un volumen.
Si desea seguir con ConfigMaps, considere dividir su configuración en varios recursos de ConfigMap. Este enfoque debería evitar el límite de 1 MB al tiempo que le permite proporcionar a cada uno de sus Pods el conjunto mínimo de claves de configuración que necesita.
Los valores de ConfigMap pueden ser cadenas UTF-8 o datos binarios codificados como una cadena base64. Los nombres de las claves pueden contener caracteres alfanuméricos, . (punto), - (guion) y _ (guión bajo) caracteres. Algunos marcos y lenguajes de programación pueden tener una convención diferente para las variables de configuración, así que asegúrese de usar un formato que sea compatible tanto con Kubernetes como con su aplicación.
Creación de un mapa de configuración
ConfigMaps tiene manifiestos YAML simples. Cada ConfigMap necesita un name en el formato estándar de Kubernetes y un data campo que contiene sus pares clave-valor:
apiVersion: v1 kind: ConfigMap metadata: name: example-configmap data: database_host: "192.168.0.10" system_email: "[email protected]"
Los data El campo es para especificar claves con valores de cadena. Puedes usar binaryData en lugar o además de data para agregar valores binarios codificados en base64. Las claves deben ser únicas en ambos data y binaryData .
Aplique el manifiesto a su clúster usando kubectl o su herramienta preferida.
Vincular mapas de configuración y pods
Un ConfigMap no hace nada por sí mismo. Ha agregado algunos datos a su clúster; ahora vinculémoslo a un Pod:
apiVersion: v1
kind: Pod
metadata:
name: example-pod
spec:
containers:
- name: example-container
image: example-image:latest
envFrom:
- configMapRef:
name: example-configmap
El envFrom El campo extrae las variables de entorno definidas por otro recurso al que se hace referencia. En este caso, un configMapRef identifica el ConfigMap creado anteriormente. Los contenedores del Pod se iniciarán con database_host y system_email variables de entorno definidas.
Adición selectiva de variables de entorno
envFrom es útil cuando desea consumir todas las claves en ConfigMap y está seguro de que no habrá conflictos con las otras variables de entorno de su Pod. En situaciones más controladas, use un env regular sección, defina claves individuales y extraiga el valor de cada clave del ConfigMap:
env:
- name: DATABASE_HOST_IP
valueFrom:
configMapKeyRef:
name: example-configmap
key: database_host
Este ejemplo muestra cómo se puede iniciar un Pod con solo el database_host clave del ConfigMap. La clave también se renombra antes de la inyección, por lo que el Pod la recibirá como DATABASE_HOST_IP .
Uso de ConfigMaps con volúmenes
Los ConfigMaps se pueden montar como archivos dentro de Pods. Kubernetes crea un volumen, inyecta el contenido de ConfigMap como un conjunto de archivos y monta el volumen en su Pod.
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
Este manifiesto de Pod crea un volumen llamado app-config . El configMap El campo rellenará previamente el volumen con los datos del ConfigMap especificado.
El Pod monta el volumen en /etc/config-data . Sus contenedores pueden leer los archivos dentro del directorio para acceder a sus valores de configuración. Cada clave de ConfigMap tendrá su propio archivo dentro del punto de montaje.
Actualización de los valores de ConfigMap
Como ConfigMap es un recurso estándar de la API de Kubernetes, puede actualizar los valores en cualquier momento modificando su manifiesto y volviendo a aplicarlo a su clúster. La forma en que los nuevos valores llegan a sus Pods depende del mecanismo de inyección que esté utilizando.
Volúmenes Montados
Kubernetes actualizará ConfigMaps montados en pods a través de un volumen. Los cambios en ConfigMaps se verifican periódicamente; cuando se detecta una diferencia, los archivos en su volumen se actualizarán, por lo que su Pod recibirá los nuevos datos. El retraso depende del intervalo de sincronización configurado para las instancias de Kubelet en sus nodos trabajadores.
Variables de entorno
No es posible cambiar las variables de entorno de un pod, por lo que los cambios de ConfigMap no llegarán a los pods existentes que hacen referencia a claves a través de este mecanismo. Debe reemplazar sus Pods para usar los nuevos datos.
Los pods recién creados siempre recibirán los datos actuales de ConfigMap, independientemente de si está utilizando volúmenes o variables de entorno. Si necesita forzar una actualización de configuración, cambie una anotación en su Pod para que Kubernetes la vuelva a crear.
Mapas de configuración inmutables
ConfigMaps tiene un immutable opcional campo que impide que se actualicen. Cuando se establece este campo, no puede actualizar los datos de ConfigMap ni eliminar el estado inmutable.
apiVersion: v1 kind: ConfigMap metadata: name: immutable-configmap data: foo: bar immutable: true
Esto puede ser útil cuando está seguro de que los valores de configuración nunca cambiarán. Mejora la seguridad al eliminar la posibilidad de ediciones accidentales. El rendimiento también se puede mejorar, ya que Kubernetes ya no necesita monitorear el ConfigMap para propagar cualquier cambio de valor en sus Pods.
Resumen
ConfigMaps debería ser su opción para proporcionar claves de configuración no confidenciales a sus pods de Kubernetes. Son un recurso API de primera clase que puede consumir como variables de entorno o archivos montados en volúmenes.
Las contraseñas y otras credenciales pertenecen a Secretos. Estos funcionan de manera muy similar a ConfigMaps y los Pods hacen referencia a ellos de la misma manera. Sustituir configMapRef con secretRef para extraer una clave de un Secreto con nombre en lugar de un ConfigMap.