“En mi máquina funciona.”

Quien trabaja con software ya ha oído esa frase. Los contenedores resolvieron parte del problema: la aplicación lleva consigo bibliotecas, runtime y configuración. Pero el contenedor por sí solo no responde preguntas como:

• ¿Quién garantiza que la aplicación siga en línea si el proceso muere?
• ¿Cómo distribuir 20 contenedores entre 6 servidores sin hacer una hoja de cálculo?
• ¿Cómo actualizar una versión sin tumbar todo?
• ¿Cómo dar un nombre estable a un servicio cuyas IPs cambian todo el tiempo?

Kubernetes es la respuesta a esas preguntas. Es un orquestador: tú declaras el estado deseado y él intenta mantener la realidad alineada con ese estado.

Sello del curso: conceptos válidos para Kubernetes 1.35. Los comandos del laboratorio están probados en Ubuntu 24.04.

Contenedor no es VM

Una VM virtualiza el hardware: cada VM tiene su propio kernel, sus drivers, su arranque. Un contenedor comparte el kernel del host y aísla procesos con namespaces y cgroups.

	VM	Contenedor
Peso	GBs	MBs
Arranque	segundos/minutos	milisegundos
Kernel	propio	comparte el del host
Aislamiento	fuerte (hardware virtual)	bueno (proceso)
Densidad	decenas por host	centenas por host

Esto explica por qué los contenedores son rápidos y por qué una imagen pequeña importa. También explica por qué “el contenedor no es seguridad absoluta”: el aislamiento es del proceso, no del hardware.

Qué hace realmente Kubernetes

Kubernetes no “ejecuta contenedores” en el sentido de ejecutar el binario. Quien ejecuta es el container runtime (containerd, CRI-O, Docker vía shim). Kubernetes decide dónde, cuántos y cómo se ejecutan.

El modelo es declarativo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: portal
spec:
  replicas: 3
  selector:
    matchLabels:
      app: portal
  template:
    metadata:
      labels:
        app: portal
    spec:
      containers:
        - name: portal
          image: nginx:1.27
          ports:
            - containerPort: 80

Dices “quiero 3 réplicas”. Kubernetes compara con la realidad. Si hay 2, crea 1. Si hay 4, elimina 1. Este ciclo se llama reconciliación.

El condominio

Piensa en el clúster como un condominio:

• API Server es la portería: toda petición pasa por él.
• etcd es el libro de registro: guarda el estado del condominio.
• Scheduler es el administrador: decide en qué apartamento (nodo) cada residente (pod) va a vivir.
• Controller Manager es la administración: hace cumplir lo que está fuera del reglamento.
• kubelet es el conserje de cada torre: garantiza que los residentes de su nodo estén allí.
• container runtime es la empresa que efectivamente entrega el cambio.
• CNI es el sistema de tuberías entre apartamentos.
• kube-proxy es la central de enrutamiento de visitas.

Cada pieza tiene un papel simple. La complejidad aparece cuando muchas piezas necesitan estar de acuerdo.

Control plane y workers

Componente	Dónde se ejecuta	Función
kube-apiserver	control plane	punto único de entrada y validación
etcd	control plane	base de datos clave-valor del estado
kube-scheduler	control plane	elige el nodo del pod
kube-controller-manager	control plane	reconcilia controladores
kubelet	worker	ejecuta y monitorea pods del nodo
container runtime	worker	descarga imagen y ejecuta contenedor
kube-proxy	worker	reglas de red para Services
CNI	worker	red de los pods

En un clúster de laboratorio, el control plane y los workers pueden estar en la misma máquina. En producción, se separan. En este curso, vamos a separarlos desde el principio, incluso para entender qué se rompe cuando un nodo cae.

Pod: la unidad más pequeña

Un pod es uno o más contenedores que comparten red y volúmenes. En la práctica, el 90% de los pods tienen un contenedor. El pod es efímero: nace, muere y se recrea con otra IP.

Por eso casi nunca creas pods directamente. Creas Deployments, que crean ReplicaSets, que crean pods. El Deployment garantiza el número de réplicas y el historial de rollout.

Deployment -> ReplicaSet -> Pod(s)

Lo que Kubernetes no resuelve

• No escribe tu aplicación.
• No sustituye la observabilidad: sin métricas y logs, te quedas ciego.
• No sustituye el backup: la persistencia sin restore probado es fe.
• No impide el error humano: un YAML incorrecto sigue siendo un YAML incorrecto.
• No es magia de alta disponibilidad: si la base de datos es de un solo nodo, el clúster no la salva.

Laboratorio del capítulo

En este capítulo todavía no vamos a montar el clúster. Solo vamos a preparar el cliente y entender el terreno.

1. Instala kubectl

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
kubectl version --client

2. Instala kind (opcional, para un clúster desechable)

curl -Lo ./kind https://kind.sigs.k8s.io/dl/latest/kind-linux-amd64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind
kind create cluster --name curso
kubectl get nodes

Si no quieres kind ahora, no pasa nada: en el capítulo 02 montamos el clúster real con kubeadm.

3. Explora la API

kubectl api-resources | head -30
kubectl explain pod.spec.containers | head -30

kubectl explain es la documentación que vive en el clúster. Úsalo y abusa.

4. Crea y observa un pod

kubectl run ola --image=nginx:1.27 --port=80
kubectl get pods -o wide
kubectl describe pod ola | tail -20
kubectl logs ola
kubectl delete pod ola

Observa: el pod obtuvo una IP, fue programado en un nodo y, al ser eliminado, desapareció. Si hubieras creado un Deployment, volvería.

Errores comunes en esta etapa

Síntoma	Causa probable
The connection to the server was refused	kubeconfig incorrecto o clúster apagado
error: You must be logged in	contexto/kubeconfig ausente
ImagePullBackOff	imagen inexistente, registry privado o sin credencial
CrashLoopBackOff	el contenedor inicia y muere; consulta kubectl logs --previous
Pod Pending	sin recursos, nodeSelector/taint o PVC no vinculado
YAML “no se aplica”	indentación, campo desconocido o kubectl apply en el archivo incorrecto

Lista de verificación

• [ ] Sé la diferencia entre VM y contenedor.
• [ ] Entendí el estado deseado y la reconciliación.
• [ ] Sé el papel de API server, etcd, scheduler, controller, kubelet, CNI y kube-proxy.
• [ ] Entendí que el pod es efímero y Deployment es el nivel correcto.
• [ ] Instalé kubectl y ejecuté kubectl version --client.
• [ ] Creé y eliminé un pod.

Glosario

• Cluster: conjunto de nodos gestionados por un control plane.
• Nodo: máquina (física o VM) que ejecuta pods.
• Pod: unidad más pequeña de ejecución.
• Deployment: controlador que garantiza réplicas y rollout.
• ReplicaSet: garantiza un número de pods de una versión.
• CNI: plugin de red de los pods.
• etcd: almacén de estado del clúster.
• kubeconfig: archivo de acceso al clúster.

Próximo

En el capítulo 02 vamos a salir de la teoría y montar el laboratorio: 6 VMs, red, containerd y el primer kubeadm init.

Próximo: Curso Kubernetes 02 — Montando el laboratorio: 6 VMs y un clúster que cabe en el bolsillo