ConfigMaps y Secrets inmutables
La inmutabilidad en ConfigMaps y Secrets evita modificaciones accidentales, mejora el rendimiento del clúster y aumenta la seguridad. Descubre cómo implementarla con kubectl, Helm y Kustomize.
La inmutabilidad nos garantiza que el contenido no ha sido ni puede ser modificado. Kubernetes ofrece esta funcionalidad como Generally Available (GA) en ConfigMaps y Secrets desde la versión 1.21.
Gracias a la inmutabilidad, nos aseguramos de que el contenido no cambia y de que todos los Pods siempre utilizan exactamente la misma versión.
Además, mejora el rendimiento del clúster de Kubernetes: cuando una ConfigMap o Secret es inmutable, el kubelet deja de observarlas (WATCH). Esto supone una mejora notable en clústeres con una gran cantidad de recursos.
Las labels y annotations pueden ser modificadas. La inmutabilidad solo aplica al campo data (y stringData)
¡Gracias por pasarte por aquí! 🙌
Si te interesa seguir recibiendo guías prácticas sobre Kubernetes, Azure, DevOps y contenedores directamente en tu email…
Suscríbete gratis y no te pierdas ninguna novedad. 🚀
Crear ConfigMap inmutable
Para crear un ConfigMap inmutable configura la propiedad immutable a true
apiVersion: v1
kind: ConfigMap
metadata:
name: minions-config
immutable: true
data:
minion-leader: "Kevin"
favorite-food: "banana"
catchphrase: "Bello! Banana!"
gadget-instructions: |
Para construir el gel de banana:
- 100 bananas maduras
- 1 máquina de Gru
- 3 minions bailando
evil-plan-level: "medio"Una vez creado el ConfigMap, intentamos modificarlo:
kubectl patch configmap minions-config \
--type merge \
-p '{"data":{"favorite-food":"pizza","catchphrase":"¡Banana Party!"}}'
Una vez creado ya no puede ser actualizado. Si necesitas cambiar un valor tienes que crear un nuevo ConfigMap y referenciarlo desde tus workloads.
apiVersion: apps/v1
kind: Deployment
metadata:
name: minion-deployment
spec:
replicas: 3
selector:
matchLabels:
app: minion
template:
metadata:
labels:
app: minion
spec:
containers:
- name: minion
image: nginx:alpine
volumeMounts:
- name: config-volume
mountPath: /config
volumes:
- name: config-volume
configMap:
name: minions-configCrear Secret inmutable
La manera de configurarlo es exactamente la misma que para un ConfigMap, configura la propiedad immutable a true
apiVersion: v1
kind: Secret
metadata:
name: minions-secret
immutable: true
type: Opaque
data:
gru-password: Z3J1MTIzNDU2
banana-vault-key: c3VwZXItYmFuYW5hLXNlY3JldC1rZXk=
stuart-favorite-song: SGV5IGJhbmFuYSBtaW5pb24h
bob-dibujo: |
iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAADUlEQVR42mP8/5+hHgAHggJ/PchI7wAAAABJRU5ErkJggg== Al igual que con el ConfigMap, intentamos modificarlo:
kubectl patch secret minions-secret \
--type merge \
-p '{"data":{"gru-password":"c2VjdXJldGVzdDEyMw=="}}'
Para actualizarlo, es necesario crear una nueva versión y referenciarla desde nuestro Pod.
apiVersion: apps/v1
kind: Deployment
metadata:
name: minion-deployment
spec:
replicas: 3
selector:
matchLabels:
app: minion
template:
metadata:
labels:
app: minion
spec:
containers:
- name: minion
image: nginx:alpine
volumeMounts:
- name: secret-volume
mountPath: /secrets
volumes:
- name: secret-volume
secret:
secretName: minions-secretEstrategias para actualizar ConfigMaps y Secrets inmutables
La inmutabilidad no permite modificarlos, todas las estrategias consisten en crear una nueva versión y actualizar la referencia en los workloads.
Todas las estrategias implican una limpieza manual o automática de los ConfigMaps y Secrets antiguos. Es vital mantener el cluster limpio de recursos no utilizados.
Kubectl
Con kubectl creas el ConfigMap o Secret con un nuevo nombre y la configuración actualizada. Referencia el nuevo valor desde tu workload.
Ejemplos de nombres recomendados:
minions-config-v2
minions-config-20250412
minions-config-banana-v2
helm
Aprovechando las ventajas que el templating de helm podemos generar diferentes versiones.
Definimos el ConfigMap y añadimos un sufijo:
apiVersion: v1
kind: ConfigMap
metadata:
name: {{ .Values.configmap.name }}-{{ .Values.configmap.version }}
immutable: true
data:
...Definimos el fichero de values:
configmap:
name: minions-config
version: v2.1.0
secret:
name: minions-secret
version: v2.1.0Ejecutamos el comando helm upgrade --install demo . --dry-run --debug para obtener el yaml final:
kustomize
Kustomize puede añadir un hash automáticamente al nombre del ConfigMap o Secret utilizando la propiedad disableNameSuffixHash. El valor por defecto es false, lo que hace que Kustomize añada automáticamente el hash al nombre.
Creamos los archivos necesarios:
k8s/
├── base/
│ ├── kustomization.yaml
│ ├── minion.env
│ ├── minion-secrets.env
│ └── deployment.yamlCreamos el contenido del archivo kustomization.yaml. Nos aseguramos que el valor de la propiedad disableNameSuffixHash es false (valor por defecto) para que Kustomize genere el sufijo hash automáticamente:
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configMapGenerator:
- name: minion-config
envs:
- minion.env
options:
immutable: true
secretGenerator:
- name: minion-secrets
envs:
- minion-secrets.env
type: Opaque
options:
immutable: true
resources:
- deployment.yaml
generatorOptions:
disableNameSuffixHash: false
Comprobamos el contenido generado ejecutando kubectl kustomize .
Si este post te ha ayudado o aclarado algo, me harías muy feliz con un ❤️
Y si crees que le puede servir a alguien más… ¡compártelo! 🙌
Conclusion
La inmutabilidad de ConfigMaps y Secrets proporciona diversas varias ventajas: protección ante posibles cambios y mejorar el rendimiento del cluster de Kubernetes. En algunos casos de uso puede parecer que el mantenimiento y despliegue de nuevas versiones puede ser algo más tedioso pero con herramientas como helm o kustomize sin duda reduce esta fricción.
Y tú, ¿qué opinas? te leo en comentarios.
Referencias
https://kubernetes.io/docs/concepts/configuration/configmap/#configmap-immutable
https://kubernetes.io/docs/concepts/configuration/secret/#secret-immutable