Deployments and Services (The Magic Tripod)

Creating a "loose and bare" Pod by hand (as we saw in the previous lesson) is almost considered a heresy in the corporate armies of real production.

The big problem is that if you create a Pod manually and that Pod fades away due to a tragic memory error... no one is going to bring it back. It died and that's it. The fall will be worldwide, the losses countless and the disgrace will be absolute for our brand.

This bleak and hypothetical scenario is elegantly resolved in practice by wrapping the Pods and encapsulating them with something superior and omniscient: A Deployment.

Deployments (The Automatic Cloner)

A Deployment is the official controller of the Pods. In your YAML, instead of saying "Create an nginx pod", what we write is a plea to the Master:

"Hello Master Node, this is a Deployment. I want you to perpetually and restlessly ensure that in this Universe there are always alive and on the table, running perfectly: exactly 3 identical Nginx Pods."

apiVersion: apps/v1
kind: Deployment # Now our top category
metadata:
  name: deployment-nginx
spec:
  replicas: 3 # THE SECRET OF AUTO-SCALING AND RESILIENCE!
  selector:
    matchLabels:
      app: mypage
  template: # In here you put exactly the instructions of a POD exactly as we already know how to do it 
    metadata:
      labels:
        app: mypage
    spec:
      containers:
      - name: container-nginx-execution
        image: nginx:1.14.2
        ports:
        - containerPort: 80

We apply it the same with kubectl apply -f file.yml.

And the true K8s miracle happens! If a Hacker enters the internal matrix and plants a bomb annihilating Pod#2... Kubernetes will be extremely outraged (since its divine order was 3 and now math is missing in the Universe), it will take the cloned remnants in milliseconds to another remote Node and a new savior will be born. Auto-healing magic.

---

Services (Servicios)

Okay, we have 300 perfect identical clones repetitively born to provide a vital backend labor (pods orchestrated thanks to our dear Deployment).

And now how do I talk to them if I want to consult them and I don't know about internal, ephemeral IPs born under uncertain milliseconds? A user cannot write "Hey please send me to Pod #221 from 14PM".

Containers/Pods are volatile and immortal and unconditionally come and disappear without mercy, and with them their IPs change. We need a constant face, a unique and respectable number of a facade to speak through the internal sea with them in an external way.

That is a Kubernetes Service.

A Service creates a single static, centralized and routing IP address that survives everything and will not change if the Pods it fronts for die. It works as a "Restaurant Waiter" a Load Balancer:

The client enters from the street to the internet on your page (front static IP of the Service), it receives the entire overwhelming web traffic squarely on its heroic chest, and it amiably balances it in milliseconds dividing tasks among your 300 slave Pods (1.1, 3.22, 4.54) according to who is locally freest and swiftest inside the Master architecture.