Trabajar con Kubernetes desde la terminal cambia la forma en que entiendes la orquestación de contenedores. Aquí aprenderás a crear pods, replica sets y deployments usando kubectl, tanto en su forma imperativa como declarativa, y cómo se relacionan entre sí para sostener aplicaciones escalables en producción.

Esta guía es para ti si ya conoces los conceptos básicos de Kubernetes y quieres pasar a la consola para construir tu primer flujo real de despliegue.

¿Cómo se listan y crean namespaces en Kubernetes?

Los namespaces son espacios lógicos donde viven tus recursos. Si no especificas uno, kubectl asume que trabajas en default.

Para ver los que existen, usa kubectl get namespaces. Vas a encontrar varios creados por la herramienta: default, kube-node-lease, kube-public y kube-system. Todos los que empiezan con kube son de uso interno y no deberías tocarlos [2:00].

¿Qué es un namespace en Kubernetes? Es un espacio lógico que separa recursos dentro del mismo clúster. Te permite aislar aplicaciones, equipos o ambientes sin necesidad de levantar otro clúster.

Para crear uno propio: kubectl create namespace pod-test. La versión corta usa ns en lugar de namespace. Validas con kubectl get namespaces y verás tu nuevo espacio listado.

¿Cuál es la diferencia entre la forma imperativa y la declarativa?

Kubernetes te ofrece dos caminos para crear recursos y cada uno tiene su lugar.

• Imperativa: usas la CLI directamente con comandos como kubectl run. Es rápida para pruebas.
• Declarativa: defines el estado deseado en archivos YAML y aplicas con kubectl apply -f. Es la forma profesional porque versionas tu infraestructura.

Para crear un pod imperativo, ejecuta kubectl run nginx-node-port --image=nginx --restart=Never --port=80. Esto se parece a un docker run cuando enlazas puertos [5:30].

Una vez creado, valida con kubectl get pods. Y para ver detalles internos como la IP, el container ID o las condiciones del pod, ejecuta kubectl describe pod nginx-node-port. Aquí entra en juego kubelet, el servicio del nodo worker que reporta si el pod está inicializado, listo y agendado.

¿Por qué usar replica sets en lugar de pods sueltos?

Un pod por sí solo no es escalable. Si se cae, se cae tu aplicación. Aquí aparece el replica set, el objeto que mantiene N copias de un pod corriendo todo el tiempo.

Primero limpia el pod anterior con kubectl delete pod nginx-node-port. Luego revisa el archivo replica-set.yaml del repositorio del curso. Vas a encontrar:

• La versión de la API.
• El tipo de recurso (kind: ReplicaSet).
• La metadata con labels críticos para identificar el recurso.
• El número de réplicas deseadas.
• Los selectors, que indican qué pods controla este replica set.
• La especificación del contenedor con imagen, tag y puerto.

¿Por qué son críticos los labels en Kubernetes? Porque componentes como kube-proxy y los servicios usan esos labels para enrutar tráfico. Si dos aplicaciones comparten labels, el clúster no sabrá hacia dónde dirigir las peticiones.

Aplica el archivo con kubectl apply -f replica-set.yaml. Verifica con kubectl get pods que tengas tres pods corriendo y con kubectl get replicasets que aparezca tu nginx-replica-set [10:15].

¿Qué pasa si elimino un pod de un replica set?

Probemos la magia. Toma un pod aleatorio y ejecuta kubectl delete pod <nombre>. Al volver a listar pods, verás que uno nuevo apareció hace pocos segundos con nombre distinto pero ejecutando el mismo proceso.

Kubernetes funciona como una orquesta: cuando un músico desentona, siempre hay un backup listo para que el show no se detenga.

¿Para qué sirven los deployments si ya tengo replica sets?

Los deployments son la unidad superior. Engloban replica sets, así como los replica sets engloban pods. Te dan control sobre actualizaciones, rollbacks y versiones sin afectar el servicio.

En el archivo deployment.yaml cambia el kind a Deployment, defines cuatro réplicas y usas la imagen gcr.io/google-samples/hello-app:1.0 expuesta en el puerto 8080. Aplicas con kubectl apply -f deployment.yaml.

Al revisar con kubectl get replicasets, notarás que el deployment creó automáticamente un nuevo replica set. Esa es la jerarquía: deployment orquesta replica sets, replica sets orquestan pods [16:40].

¿Cómo actualizo la imagen de un deployment sin tocar el YAML?

Usa el comando kubectl set image deployment/hello-deployment hello-app=gcr.io/google-samples/hello-app:2.0. Kubernetes inicia un rolling update y reemplaza pods de forma progresiva.

Para monitorear el proceso: kubectl rollout status deployment/hello-deployment. Te dirá cuántas réplicas se actualizaron y cuándo terminó.

¿Qué es un rollout en Kubernetes? Es el proceso de mover un deployment de una versión de imagen a otra de forma controlada, manteniendo el servicio activo durante la transición.

¿Qué hago si una actualización falla?

Si apuntas a una imagen inexistente como hello-app:3.0, los pods entrarán en estado ErrImagePull. Los verás con kubectl get pods mostrando cero contenedores listos.

Para revertir, ejecuta kubectl rollout undo deployment/hello-deployment. Es el Control Z de los deployments: vuelve a la versión anterior y tus pods regresan a estado normal [22:10].

¿Cómo expongo un deployment para ver tráfico real?

Usa kubectl port-forward deploy/hello-deployment 8080:8080. Esto enlaza el puerto 8080 de tu máquina con el puerto interno del contenedor.

Abre el navegador en localhost:8080 y verás la vista de Hello World versión 2.0 con el hostname del pod que respondió. Si recargas varias veces, notarás que siempre responde el mismo pod, aunque tengas cuatro corriendo.

¿Por qué crees que Kubernetes no balancea el tráfico entre las cuatro réplicas si kube-proxy se encarga de la red? Cuéntame en los comentarios qué piensas que está pasando aquí.