Kubernetes: ConfigMaps, Secrets y cómo gestionar configuraciones

ConfigMaps: configuración desacoplada del código

Un ConfigMap es un recurso de Kubernetes que almacena datos no sensibles en pares clave-valor. Separa la configuración de la imagen del contenedor, permitiendo usar el mismo contenedor en distintos entornos (dev, staging, prod) simplemente cambiando el ConfigMap.

Se pueden crear desde literales, archivos, directorios completos o incluso YAML declarativos.

# Crear ConfigMap con literales
kubectl create configmap app-config --from-literal=DB_HOST=localhost \
  --from-literal=DB_PORT=3306 --from-literal=APP_ENV=production

# Crear desde archivo
kubectl create configmap nginx-conf --from-file=nginx.conf

# Ver ConfigMaps
kubectl get configmaps
kubectl describe configmap app-config

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_HOST: "localhost"
  DB_PORT: "3306"
  APP_ENV: "production"
  nginx.conf: |
    server {
        listen 80;
        server_name itfrontech.com;
        root /usr/share/nginx/html;
    }

Secrets: datos sensibles cifrados

Los Secrets son similares a los ConfigMaps pero están diseñados para datos sensibles como contraseñas, tokens y claves SSH. En Kubernetes, los valores se almacenan codificados en base64 (no cifrados por defecto, ojo — en producción usa encryptación en etcd).

# Crear Secret con literales
kubectl create secret generic db-credentials \
  --from-literal=DB_USER=admin \
  --from-literal=DB_PASSWORD=s3cr3tP@ss

# El valor se almacena en base64
kubectl get secret db-credentials -o yaml
# apiVersion: v1
# kind: Secret
# data:
#   DB_USER: YWRtaW4=
#   DB_PASSWORD: czNjcjN0UEBzcw==

# Crear desde archivo
kubectl create secret generic tls-cert \
  --from-file=tls.crt=server.crt \
  --from-file=tls.key=server.key

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-backend
spec:
  template:
    spec:
      containers:
      - name: backend
        image: myapp:1.0
        env:
        # ConfigMap como variables de entorno
        - name: DB_HOST
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: DB_HOST
        # Secret como variable de entorno
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-credentials
              key: DB_PASSWORD
        volumeMounts:
        - name: nginx-config
          mountPath: /etc/nginx/conf.d
          readOnly: true
        - name: tls
          mountPath: /etc/nginx/tls
          readOnly: true
      volumes:
      - name: nginx-config
        configMap:
          name: nginx-conf
      - name: tls
        secret:
          secretName: tls-cert

Un patrón muy común es montar ConfigMaps como volúmenes para archivos de configuración largos (nginx.conf, php.ini) y Secrets para certificados TLS o credenciales de base de datos. Cuando actualizas el ConfigMap o Secret, los pods existentes no lo ven automáticamente a menos que uses un controlador como Reloader o hagas un rollout manual.