Kubernetes y la nube

Kubernetes tiene un vocabulario propio que se pregunta literalmente. Estos son los términos que hay que saber colocar.

El concepto que hay que entender bien es el pod, porque no equivale a contenedor. Un pod es normalmente un contenedor, pero puede llevar varios cuando son inseparables: el servicio y un acompañante que le recoge los registros o le hace de proxy. Lo que agrupa el pod son contenedores y volúmenes bajo una misma dirección IP, de modo que se ven entre ellos como si estuvieran en la misma máquina, y viven y mueren juntos. Emparentada con esa idea está la IP flotante: una dirección que no pertenece a una máquina concreta, sino que se puede mover entre varias máquinas o varios contenedores, y que es lo que permite que el servicio siga respondiendo en la misma dirección cuando cambia quién lo atiende.

Kubernetes se despliega en dos mitades: el plano de control se instala en el servidor central y decide, y en cada nodo trabajador se instala un agente, el Kubelet, que recibe esas decisiones y se ocupa de que los contenedores de su máquina estén en el estado que le han dicho. Es multiplataforma y es el orquestador que se usa en producción.

El servicio existe porque los pods son efímeros y su dirección cambia cada vez que se recrean. Nadie puede apuntar a la dirección de un pod. Se apunta al servicio, que ofrece un nombre y una dirección estables y hace de balanceador hacia los pods que en ese momento estén disponibles. El tráfico que entra desde fuera del clúster se gobierna con el ingress.

Cadena de contención, de mayor a menor: clúster contiene nodos, un nodo alberga pods, y un pod agrupa contenedores. El servicio no contiene nada: es la puerta estable por la que se llega a un grupo de pods.

Docker resuelve el problema de un contenedor en una máquina. En cuanto hay treinta contenedores repartidos por diez servidores, aparecen preguntas que Docker no contesta: en qué máquina arrancar cada uno, qué hacer cuando una máquina se cae, cómo repartir el tráfico entre cinco copias del mismo servicio, cómo sustituir la versión 2.4 por la 2.5 sin cortar el servicio, o cómo lanzar más copias cuando llega el examen y sube la carga.

Un orquestador es la capa que responde a todo eso, y de paso permite escalar, aporta seguridad de servicio y equilibra la carga: si se cae un nodo replica sus contenedores en otro, reparte las ejecuciones entre los nodos disponibles y puede mover un contenedor de una máquina saturada a otra que lo esté menos. Su idea de fondo es el estado deseado: el administrador no da órdenes paso a paso, sino que describe cómo debe quedar el sistema, y el orquestador se encarga permanentemente de que la realidad coincida con esa descripción.

Un pod suelto no tiene ninguna garantía: si muere, muere. Quien asegura que haya siempre un número determinado de copias es otro objeto. El histórico se llamaba Replication Controller y aún aparece en muchos apuntes; su sucesor es el ReplicaSet, que hace lo mismo con una forma más flexible de seleccionar los pods.

Ninguno de los dos se escribe hoy a mano. Lo que se declara es un Deployment, que es la pieza de nivel superior: define qué imagen hay que ejecutar y cuántas réplicas se quieren, crea por debajo el ReplicaSet que las mantiene, y sobre todo sabe cambiar de versión de forma progresiva, levantando pods de la versión nueva y retirando los de la vieja poco a poco, sin cortar el servicio y con posibilidad de deshacer el cambio.

El escalado horizontal es, en este modelo, cambiar un número. Subir de tres réplicas a diez es modificar una línea del Deployment, y Kubernetes se ocupa de crear los pods, repartirlos entre los nodos que tengan sitio y darlos de alta en el servicio para que empiecen a recibir tráfico.

Si una pregunta habla de desplegar una versión nueva sin parar el servicio y de poder volver atrás, la respuesta es Deployment, no ReplicaSet ni pod.

kubectl es la herramienta de línea de comandos con la que se administra un clúster de contenedores repartido sobre una infraestructura de nodos. Con ella se trabaja de dos maneras distintas, y la distinción se pregunta.

# Declarativo: se aplica el fichero, y se puede repetir sin miedo
kubectl apply -f api-temario.yaml

# Imperativo: crea el objeto una vez, y falla si ya existe
kubectl create -f api-temario.yaml

# Imperativo puro, sin fichero: util para una prueba rapida
kubectl run api-temario --image=api-temario:2.4.1 --port=3000

# Consultar el clúster
kubectl get pods
kubectl get nodes
kubectl get services

# Detalle y diagnostico de un objeto concreto
kubectl describe pod api-temario
kubectl logs api-temario
kubectl exec -it api-temario -- bash

# Escalar y cambiar de version
kubectl scale deployment api-temario --replicas=5
kubectl set image deployment/api-temario api=api-temario:2.5.0
kubectl rollout undo deployment/api-temario

La diferencia práctica entre apply y create es que apply es idempotente: aplicar dos veces el mismo fichero deja el clúster igual, mientras que create falla si el objeto ya existía. Por eso apply es el que encaja con la automatización, donde el mismo fichero se ejecuta una y otra vez.

apply es declarativo y create es imperativo. Es una pregunta habitual, y la pista para recordarlo es que apply describe un destino mientras que create ordena una acción.

Los ficheros de Kubernetes se escriben en YAML y todos comparten la misma estructura de cuatro bloques, así que leído uno se leen todos.

• apiVersion: qué versión de la API del clúster se está usando.
• kind: qué clase de objeto se va a crear. Pod, Deployment, Service, Namespace.
• metadata: los datos de identificación, sobre todo el nombre y las etiquetas por las que otros objetos lo encontrarán.
• spec: la especificación de lo que se quiere, que es lo único que cambia de verdad de un tipo de objeto a otro.

apiVersion: v1
kind: Pod
metadata:
  name: api-temario
  labels:
    app: api-temario
spec:
  containers:
    - name: api
      image: registro.llegandoalcorte.com/api-temario:2.4.1
      ports:
        - containerPort: 3000
      env:
        - name: NODE_ENV
          value: production
  restartPolicy: Always

Las etiquetas de metadata no son decorativas: son el mecanismo con el que unos objetos seleccionan a otros. Un servicio no enumera los pods a los que manda tráfico, sino que declara qué etiqueta deben llevar, y así los pods que se creen mañana entran automáticamente en el reparto. La política de reinicio decide qué hacer si el contenedor se detiene, y Always significa que se reintente siempre.

Existe un pariente pequeño de esta idea que conviene no confundir con el orquestador. Docker Compose sirve para llevar la mano de un grupo de contenedores dentro de un único anfitrión: en un fichero docker-compose.yml se declara qué contenedores se quieren, con sus imágenes, sus puertos, sus volúmenes y sus dependencias, y una sola orden lo levanta todo de golpe. Su caso de uso típico es montar en un momento el entorno de trabajo completo de un equipo de desarrollo.

# docker-compose.yml: el entorno completo de desarrollo
services:
  bd-temario:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: desarrollo
    volumes:
      - datos-temario:/var/lib/postgresql/data

  api-temario:
    image: api-temario:2.4.1
    depends_on:
      - bd-temario
    ports:
      - "8080:3000"

volumes:
  datos-temario:

La frontera entre los dos es el número de máquinas: Docker Compose coordina contenedores dentro de un solo anfitrión, y Kubernetes los distribuye por un clúster de nodos.

Kubernetes, que se abrevia como k8s por las ocho letras que van entre la k y la s, es el orquestador de referencia, pero no el único. Docker Swarm es la alternativa integrada en el propio Docker: mucho más sencilla de montar y de entender, con bastantes menos capacidades, y hoy claramente minoritaria frente a Kubernetes.

Compose no es un orquestador de clúster: coordina contenedores dentro de un anfitrión. Es la confusión más habitual al enumerar herramientas de orquestación.

Los contenedores casi nunca se ejecutan hoy sobre hierro propio, sino sobre una plataforma contratada, y esa contratación tiene modelos con nombre. Todos responden a la misma pregunta: hasta dónde llega el proveedor y desde dónde empieza el cliente. Cuanto más alto es el modelo, menos administra el cliente y menos control conserva.

CaaS y KaaS son variantes de la misma idea aplicadas a los contenedores, y se sitúan entre IaaS y PaaS. La diferencia entre las dos es el nivel de la abstracción: en CaaS el cliente entrega contenedores y no ve el clúster, y en KaaS el cliente sí administra un clúster de Kubernetes, pero sin encargarse de montarlo ni de mantener sus nodos maestros. Los tres grandes proveedores de nube lo ofrecen: EKS en Amazon Web Services, GKE en Google Cloud y AKS en Microsoft Azure.

En la sigla CSP, la C es de Cloud: proveedor de servicios en la nube. No es un proveedor de comunicaciones, aunque algunos apuntes lo traduzcan así.

Los nombres de los servicios concretos se preguntan, sobre todo los de Amazon Web Services y los de OpenStack, que es la plataforma abierta de infraestructura y la que más aparece en el ámbito público por no depender de un fabricante. La gracia de verlos juntos es que las dos ofrecen lo mismo con nombres distintos.

Junto a esas dos, los otros proveedores de infraestructura que se citan son Microsoft Azure y Google Cloud. En el ámbito de la Administración General del Estado hay además infraestructura propia, ofrecida sobre la red SARA a los organismos públicos, que evita sacar de las administraciones los datos y las cargas de trabajo.

El mecanismo interno de una plataforma PaaS moderna es, precisamente, lo que se ha estudiado en este subtema: la consola crea los contenedores que hagan falta para el entorno pedido, por ejemplo una versión concreta de Java con una base de datos y una caché, y los distribuye por el clúster con Kubernetes. El desarrollador entrega su código y no llega a ver nada de eso.

OpenShift es la respuesta cuando la pregunta pide una plataforma PaaS que se apoye en Kubernetes y pueda instalarse en las instalaciones del propio organismo.