Deployments y Servicios (El Trípode Mágico)

Crear un Pod "suelto y pelado" a mano (como vimos en la lección anterior) es casi considerado una herejía en los ejércitos corporativos de producción real.

El gran problema es que si creas un Pod manualmente y ese Pod se desvanece por un trágico error de memoria... nadie va a traerlo de regreso. Se murió y ya. La caída será mundial, las pérdidas incontables y la desgracia será absoluta para nuestra marca.

Este desolador e hipotético panorama se solventa elegantemente en la práctica envolviendo a los Pods y encapsulándolos con algo superior y omnisciente: Un Deployment.

Deployments (El Clonador Automático)

Un Deployment es el controlador oficial de los Pods. En tu YAML, en lugar de decir "Crea un pod nginx", lo que escribimos es un ruego al Maestro:

"Hola Master Node, este es un Deployment. Quiero que asegures perpetuamente y sin descanso que en este Universo siempre estén vivos y en la mesa, corriendo perfectamente: 3 Pods exactos e idénticos de Nginx."

apiVersion: apps/v1
kind: Deployment # Ahora nuestra categoría superior
metadata:
  name: deployment-nginx
spec:
  replicas: 3 # ¡EL SECRETO DEL AUTO-ESCALAMIENTO Y RESILIENCIA!
  selector:
    matchLabels:
      app: mipagina
  template: # Acá dentro pones exactamente las instrucciones de un POD como ya sabemos hacerlo 
    metadata:
      labels:
        app: mipagina
    spec:
      containers:
      - name: contenedor-nginx-ejecucion
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Aplicamos igual con kubectl apply -f archivo.yml.

¡Y ocurre el verdadero milagro de K8s! Si un Hacker entra a la matriz interna e implanta una bomba aniquilando al Pod#2... Kubernetes se indignará de sobremanera (ya que su orden divina era 3 y ahora en el Universo faltan matemáticas), tomará los retales clonados en milisegundos en otro Node remoto y nacerá un nuevo salvador. Magia auto-curativa.

---

Services (Servicios)

Bien, tenemos 300 clones perfectos idénticos repititivamente nacidos para dar una labor de backend vital (pods orquestados gracias a nuestro querido Deployment).

¿Y ahora cómo le hablo a ellos si quiero consultarlos y no sé de IPs internas, efímeras y nacidas bajo milisegundos inciertos? Un usuario no puede escribir "Oye por favor envíame a Pod #221 de las 14PM".

Los contenedores/Pods son volátiles e inmortales y vienen y desaparecen sin piedad, y con ellos sus IPs cambian. Necesitamos una cara constante, un número único y respetable de una fachada para hablar a través del mar interno con ellos de modo externo.

Eso es un Kubernetes Service (Servicio).

Un Servicio crea una única dirección IP estática, centralizada y enrutadora que sobrevive a todo y no va a cambiar si se mueren los Pods a los que hace frente. Funciona como un "Mesero de Restaurante" un Load Balancer:

El cliente entra de la calle a internet en tu página (IP estática frontal del Servicio), este recibe el tráfico web abrumador entero en su pecho heroico, y lo balancea amablemente en milisegundos dividiendo tareas entre tus 300 Pods esclavos (1.1, 3.22, 4.54) según quien ande más libre localmente y veloz dentro de la arquitectura Master.