El caso
Doce servicios y uno que siempre falla. ¿Quién reinicia el contenedor a las tres de la mañana?
La tienda de Isaac creció. Pedidos, existencias, pagos, notificaciones y el panel del contador se volvieron doce contenedores. Cada uno necesita copias corriendo al mismo tiempo, un reinicio cuando se traba y una forma de encontrar a los demás.
Una madrugada, el servicio de existencias se trabó. Nadie lo notó hasta la mañana siguiente, porque nadie estaba mirando.
Este post parte de Contenedores en la nube y de Serverless y Cloud Run en Google Cloud. Con Cloud Run, Google decide cuándo corre el contenedor. Aquí, tu equipo decide qué corre, en cuántas copias y cómo se encuentran las partes.
El problema
Un contenedor solo no se cuida solo
Arrancar un contenedor es fácil. Mantenerlo vivo es otra historia:
- Reinicios: si el proceso se traba, alguien tiene que notarlo y volver a levantarlo.
- Copias: para atender la demanda, hay que correr varias copias y repartirlas entre máquinas.
- Direcciones: cuando un contenedor se recrea, su dirección cambia, y quien depende de él se rompe.
La solución
Kubernetes: el equipo describe, el sistema ejecuta
Kubernetes (o K8s) es un sistema de orquestación de contenedores. Declaras el estado que quieres, por ejemplo «tres copias del servicio de pedidos siempre en línea», y él trabaja para mantener ese estado. Si una copia cae, crea otra. Si una máquina desaparece, mueve las copias a otra.
Es como pedirle al gerente de la tienda que tenga tres cajas abiertas a cualquier hora. No eliges a quién llamar para cubrir una falta; él se encarga y solo te avisa cuando no puede.
Tres objetos
Pod, Deployment y Service
Pod
La unidad más pequeña de Kubernetes: uno o más contenedores que corren juntos y comparten la misma dirección.
En la tienda: el contenedor del servicio de existencias, con su recolector de logs al lado.
Deployment
Declara cuántas copias de un pod deben existir, y recrea las que caen.
En la tienda: tres copias del servicio de pedidos, siempre.
Service
Una dirección estable para llegar a los pods, incluso cuando se recrean.
En la tienda: la dirección «pagos», que el servicio de pedidos llama sin saber en qué máquina está el pago.
No confundas
GKE Autopilot × GKE Standard
GKE (Google Kubernetes Engine) es el Kubernetes administrado de Google Cloud. En los dos modos, Google se ocupa del plano de control (control plane), el cerebro del clúster. La diferencia está en quién se ocupa de los nodos, las máquinas donde corren los pods.
GKE Autopilot
“¿Quién administra los nodos?”
- Ejemplo
- Google. El equipo define los pods y los recursos que pide cada uno, y no crea ni configura las máquinas.
- Foco
- Paga por los recursos que piden los pods. Es el modo que recomienda Google.
GKE Standard
“¿Quién administra los nodos?”
- Ejemplo
- El equipo elige el tipo de máquina, el tamaño y la cantidad de nodos.
- Foco
- Más control sobre la infraestructura, y más trabajo para mantenerla.
Por debajo
Clúster, nodos y pods
Un clúster es el plano de control junto con los nodos. Los nodos son máquinas virtuales, como las de Compute Engine, y cada pod se programa en un nodo con espacio libre. El plano de control decide dónde corre cada pod y verifica que se cumpla el estado declarado.
Cuando sube el tráfico, el número de pods puede crecer automáticamente. Si los nodos no tienen lugar para ellos, el clúster necesita más nodos. En Autopilot, Google se ocupa de eso; en Standard, el equipo configura ese comportamiento.
En la práctica
Lo que la tienda necesita, y cómo resolverlo
| Lo que la tienda necesita | Cómo resolverlo |
|---|---|
| Tres copias del servicio de pedidos siempre en línea | Deployment con tres réplicas |
| Reiniciar existencias cuando se traba | Kubernetes recrea el pod que falló |
| Llamar a pagos por nombre, no por dirección | Service |
| Más pedidos de noche, menos de mañana | Escalado automático de pods, y de nodos cuando falte espacio |
| Nadie quiere administrar máquinas | GKE Autopilot |
Términos clave
Cinco términos para fijar
Toca la tarjeta para ver la definición.
Prueba rápida
Tres preguntas, estilo examen
01
El equipo quiere correr contenedores en Kubernetes sin administrar las máquinas. ¿Qué modo de GKE conviene más?
02
Un servicio necesita tres copias de un contenedor siempre en marcha, recreando las que fallen. ¿Qué objeto de Kubernetes hace eso?
03
¿Qué afirmación sobre GKE es verdadera?
Kubernetes no reemplaza al contenedor: decide dónde y cuántas copias corren. Con GKE, Isaac deja de despertarse de madrugada por culpa de las existencias, y el equipo mira lo que necesita la tienda, y no cada máquina. El próximo paso del recorrido es la seguridad: quién puede acceder a cada servicio.