Pods que van y vienen, una dirección fija

Services

Cada pod tiene su IP, pero los pods se recrean todo el tiempo y con ellos cambia la IP. Un Service da a un grupo de pods un nombre y una IP estables, y reparte las peticiones entre los que estén listos. Igual que el Deployment, encuentra sus pods por etiquetas: los pods que coinciden con su selector son sus endpoints.

Hay tres tipos principales:

• ClusterIP (el predeterminado): solo accesible dentro del clúster. Otros pods lo usan por su nombre: http://api:3000. Es lo normal para bases de datos y servicios internos.
• NodePort: además abre un puerto (entre 30000 y 32767) en todos los nodos; desde afuera se entra por IP_DE_UN_NODO:PUERTO.
• LoadBalancer: en una nube, pide un balanceador externo con su propia IP pública.

apiVersion: v1
kind: Service
metadata:
  name: tienda
spec:
  type: NodePort
  selector:
    app: tienda          # envía a los pods con esta etiqueta
  ports:
    - port: 80           # el puerto del Service
      targetPort: 8080   # el puerto donde escucha el contenedor
      nodePort: 30080    # el puerto abierto en cada nodo

Los dos errores más comunes: un selector que no coincide con ninguna etiqueta (el Service queda sin endpoints) y un targetPort distinto del puerto en que escucha el contenedor (la conexión se rechaza).

Ingress

Con muchos servicios, abrir un NodePort o un balanceador para cada uno es caro y desordenado. Un Ingress define reglas HTTP: según el host y la ruta de la petición, a qué Service enviarla. Lo hace cumplir un controlador de Ingress (normalmente un Nginx o Traefik que corre dentro del clúster), que además suele encargarse del HTTPS.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web
spec:
  rules:
    - host: tienda.local
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api
                port:
                  number: 3000
          - path: /
            pathType: Prefix
            backend:
              service:
                name: tienda
                port:
                  number: 80

ConfigMaps, Secrets y escalado automático

La imagen debe ser la misma en todos los ambientes; lo que cambia (la dirección de la base, una clave de API) se inyecta al crear el pod. Un ConfigMap guarda configuración no sensible y un Secret, datos sensibles. Los dos se pasan a los contenedores como variables de entorno o como archivos.

kubectl create configmap api-config --from-literal=DB_HOST=postgres
kubectl create secret generic api-secret --from-literal=DB_PASSWORD=…
kubectl set env deployment/api --from=configmap/api-config
kubectl set env deployment/api --from=secret/api-secret

Dos detalles importantes. Los valores de un Secret se guardan en base64, que no es cifrado: cualquiera con permiso de leer Secrets los puede decodificar; se protegen con permisos (RBAC) y cifrado en etcd. Y las variables se leen al crear el pod: si cambias un ConfigMap, los pods que ya corren no se enteran hasta que se recrean (kubectl rollout restart).

Por último, un HorizontalPodAutoscaler (HPA) ajusta las réplicas de un Deployment según el uso de CPU: kubectl autoscale deployment tienda --min=2 --max=8 --cpu-percent=60 agrega pods cuando el promedio pasa del 60 % y los quita cuando baja.

Antes de leer la respuesta