Tu primer Pod

Un Pod es la unidad mínima de despliegue en Kubernetes. No es un contenedor, sino una envoltura alrededor de uno o más contenedores que comparten red y almacenamiento. Cuando Kubernetes ejecuta tu aplicación, siempre lo hace dentro de un Pod.

En esta lección vas a crear tu primer Pod de dos maneras distintas:

• De forma imperativa, con un solo comando de kubectl (esta unidad).
• De forma declarativa, describiendo el Pod en un archivo YAML (la siguiente unidad).

También aprenderás a inspeccionar un Pod con kubectl describe y a leer sus logs con kubectl logs. Todo el trabajo se hace en un clúster de Kubernetes real que ya está esperándote en la pestaña dev-machine.

Paso 1: Crea un Pod de forma imperativa

La forma más rápida de crear un Pod es el comando kubectl run. Se llama forma imperativa porque le das una orden directa al clúster: "crea esto ahora".

Ejecuta lo siguiente en la terminal:

kubectl run web --image=ghcr.io/iximiuz/labs/nginx:alpine --port=80

Comprueba el estado del Pod:

kubectl get pods

Al principio puede aparecer en estado ContainerCreating. Espera unos segundos y vuelve a ejecutar el comando hasta que veas Running.

Paso 2: Inspecciona el Pod con kubectl describe

kubectl get te da un resumen, pero kubectl describe te cuenta la historia completa del Pod: en qué nodo se ejecuta, qué imagen usa, qué eventos ha generado y mucho más.

kubectl describe pod web

Fíjate en estas secciones de la salida:

• Node: el nodo del clúster donde se ha programado el Pod.
• Containers: la lista de contenedores del Pod, con su imagen y puertos.
• Conditions: las condiciones que debe cumplir el Pod para estar listo.
• Events: la línea de tiempo de lo que le ha pasado al Pod (imagen descargada, contenedor creado, contenedor arrancado).

Para demostrar que has leído la salida con atención, responde a esta pregunta:

Paso 3: Lee los logs del Pod

Todo lo que el proceso principal del contenedor escribe en su salida estándar queda registrado y se puede consultar con kubectl logs:

kubectl logs web

Verás los mensajes de arranque de nginx. La última línea debería decir algo como start worker processes, señal de que el servidor está listo para atender peticiones.

Paso 4: Elimina el Pod imperativo

La forma imperativa es cómoda para experimentos, pero tiene un problema: la definición del Pod solo existe en el clúster. Si alguien lo borra, no queda ningún rastro de cómo estaba web.

Antes de pasar a la forma declarativa, elimina el Pod:

kubectl delete pod web

Continúa con la siguiente unidad para crear el mismo Pod de la forma en que se hace en el mundo real: con un archivo YAML.

La forma declarativa es la que usarás en el mundo real: describes el estado deseado en un archivo YAML y Kubernetes se encarga de hacerlo realidad. El archivo se puede versionar en git, revisar en un pull request y aplicar tantas veces como quieras.

Paso 5: Crea un Pod de forma declarativa

Crea un archivo llamado pod.yaml con este contenido. Se pega tal cual en la terminal; si prefieres escribirlo a mano, la pestaña IDE también está ahí:

cat << 'EOF' > pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
spec:
  containers:
  - name: nginx
    image: ghcr.io/iximiuz/labs/nginx:alpine
    ports:
    - containerPort: 80
EOF

El YAML, explicado con preguntas y respuestas

¿Qué es apiVersion y por qué vale v1?

Indica la versión de la API de Kubernetes que sabe interpretar este objeto. Los Pods pertenecen al grupo de recursos básicos (core), que se identifica simplemente como v1. Otros recursos, como los Deployments, usan versiones con grupo, por ejemplo apps/v1.

¿Qué indica kind?

El tipo de objeto que estás describiendo. Aquí es Pod, pero el mismo esquema de archivo sirve para cualquier recurso de Kubernetes: Service, Deployment, ConfigMap, etc.

¿Para qué sirve metadata.name?

Es el nombre único del Pod dentro de su namespace. Es el identificador que usas en todos los comandos: kubectl get pod web, kubectl describe pod web, kubectl logs web.

¿Qué son las labels y por qué las añadimos ya?

Son etiquetas de tipo clave-valor que permiten agrupar y seleccionar objetos. Ahora mismo la etiqueta app: web no hace nada, pero en cuanto crees un Service o un Deployment verás que todo en Kubernetes se conecta a través de labels. Es una buena costumbre etiquetar desde el primer día.

¿Qué define spec?

El estado deseado del objeto. En metadata dices cómo se llama el Pod y en spec dices cómo debe ser por dentro.

¿Por qué containers es una lista?

Porque un Pod puede tener más de un contenedor. Es un caso menos habitual, pero existen patrones como los sidecars que lo aprovechan. En esta lección la lista tiene un solo elemento.

¿Qué papel juega containerPort?

Es principalmente informativo: documenta el puerto en el que escucha el proceso del contenedor. El tráfico llegaría al puerto 80 aunque no lo declararas, pero declararlo hace el YAML más legible y lo aprovechan otras herramientas.

¿Qué diferencia hay entre kubectl run y kubectl apply -f?

Con kubectl run das una orden puntual y la configuración solo vive en el clúster. Con kubectl apply -f el archivo YAML es la fuente de la verdad: puedes guardarlo, versionarlo y volver a aplicarlo en cualquier clúster.

¿Qué pasa si aplico el mismo YAML dos veces?

Nada malo. kubectl apply es idempotente: si el objeto ya existe y coincide con el archivo, no cambia nada; si hay diferencias en campos modificables, las actualiza.

Aplica el archivo

Ahora crea el Pod a partir del archivo:

kubectl apply -f pod.yaml

Y comprueba que llega al estado Running:

kubectl get pod web

Repite ahora la inspección que hiciste en la unidad anterior, esta vez sobre el nuevo Pod:

kubectl describe pod web

kubectl logs web

Resumen

En esta lección has:

• Creado un Pod de forma imperativa con kubectl run.
• Inspeccionado un Pod con kubectl describe y localizado su nodo, su imagen, sus condiciones y sus eventos.
• Consultado los logs del contenedor con kubectl logs.
• Eliminado un Pod con kubectl delete.
• Creado el Pod web de forma declarativa con un archivo YAML y kubectl apply.

La forma declarativa es la base de todo lo que viene después: Deployments, Services y el resto de objetos de Kubernetes se gestionan exactamente igual, con archivos YAML aplicados sobre el clúster.