Capitulo 5: Pods y Deployments
Capitulo 5: Pods y Deployments
< Volver al Indice del Tutorial
Que es un Pod
Un Pod es la unidad minima de ejecucion en Kubernetes. Contiene uno o mas contenedores que comparten red y almacenamiento. En la mayoria de casos, un Pod ejecuta un solo contenedor.
Crear un Pod con YAML Manifest
Todo recurso en Kubernetes se define con 4 campos obligatorios:
apiVersion: v1 # Version de la API
kind: Pod # Tipo de recurso
metadata: # Nombre, labels, namespace
name: mi-pod
spec: # Especificacion del recurso
containers: []
Ejemplo: Pod con Nginx
Crea un archivo nginx-pod.yaml:
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
app: nginx
entorno: desarrollo
spec:
containers:
- name: nginx
image: nginx:1.27-alpine
ports:
- containerPort: 80
Aplica y verifica:
kubectl apply -f nginx-pod.yaml
kubectl get pods
kubectl describe pod nginx-pod
kubectl logs nginx-pod
Para acceder temporalmente al pod:
kubectl port-forward nginx-pod 8080:80
# Visitar http://localhost:8080
Eliminar el pod:
kubectl delete pod nginx-pod
Los pods por si solos no se reinician si fallan. Para eso existen los Deployments.
Deployments
Un Deployment gestiona pods de forma declarativa. Se encarga de crear, escalar, actualizar y reiniciar pods automaticamente.
Crear un Deployment
Archivo nginx-deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.27-alpine
ports:
- containerPort: 80
kubectl apply -f nginx-deployment.yaml
kubectl get deployments
kubectl get pods -l app=nginx
Escalar Replicas
Para aumentar o disminuir el numero de pods:
# Escalar a 3 replicas
kubectl scale deployment nginx-deploy --replicas=3
kubectl get pods -l app=nginx
# Escalar a 1 replica
kubectl scale deployment nginx-deploy --replicas=1
Tambien puedes editar el campo replicas en el YAML y hacer kubectl apply -f.
Actualizar Imagen
Para actualizar la version de la imagen:
kubectl set image deployment/nginx-deploy nginx=nginx:1.27
kubectl rollout status deployment/nginx-deploy
Kubernetes crea pods nuevos con la imagen actualizada y elimina los antiguos gradualmente.
Estrategias de Despliegue
Se configuran en spec.strategy del Deployment.
RollingUpdate (por defecto)
Reemplaza pods gradualmente. Nunca hay tiempo de inactividad:
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # Pods extra durante actualizacion
maxUnavailable: 0 # Pods no disponibles permitidos
maxSurge: 1significa que puede haber 1 pod adicional temporal.maxUnavailable: 0significa que todos los pods actuales siguen activos hasta que los nuevos esten listos.
Recreate
Elimina todos los pods antes de crear los nuevos. Hay tiempo de inactividad pero es util cuando no pueden coexistir dos versiones:
spec:
strategy:
type: Recreate
Rollouts: Historial y Rollback
Kubernetes mantiene un historial de revisiones de cada Deployment.
Verificar estado del rollout
kubectl rollout status deployment/nginx-deploy
Ver historial de revisiones
kubectl rollout history deployment/nginx-deploy
Para ver detalles de una revision especifica:
kubectl rollout history deployment/nginx-deploy --revision=2
Rollback a revision anterior
# Revertir al deploy anterior
kubectl rollout undo deployment/nginx-deploy
# Revertir a una revision especifica
kubectl rollout undo deployment/nginx-deploy --to-revision=1
Para que el historial tenga descripciones utiles, usa --record al aplicar cambios o agrega anotaciones:
kubectl annotate deployment/nginx-deploy \
kubernetes.io/change-cause="Actualizar nginx a 1.27"
Labels y Selectors
Los labels son pares clave-valor que se asignan a los recursos. Los Deployments usan selectors para encontrar los pods que les pertenecen.
Como funciona la relacion
Deployment (selector: app=nginx)
|
+--> ReplicaSet (labels: app=nginx)
|
+--> Pod 1 (labels: app=nginx)
+--> Pod 2 (labels: app=nginx)
+--> Pod 3 (labels: app=nginx)
El campo selector.matchLabels del Deployment debe coincidir con los labels del template.metadata.labels. Si no coinciden, Kubernetes rechaza el manifiesto.
Consultar por labels
# Pods con label app=nginx
kubectl get pods -l app=nginx
# Pods con label entorno=produccion
kubectl get pods -l entorno=produccion
# Multiples labels (AND)
kubectl get pods -l app=nginx,entorno=produccion
# Negacion
kubectl get pods -l 'app!=nginx'
Ejemplo Completo: App Web con 3 Replicas
Archivo webapp-deployment.yaml:
apiVersion: apps/v1
kind: Deployment
metadata:
name: webapp
labels:
app: webapp
tier: frontend
spec:
replicas: 3
selector:
matchLabels:
app: webapp
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
template:
metadata:
labels:
app: webapp
tier: frontend
spec:
containers:
- name: webapp
image: nginx:1.27-alpine
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "128Mi"
cpu: "100m"
kubectl apply -f webapp-deployment.yaml
kubectl get deploy webapp
kubectl get pods -l app=webapp
Verifica que las 3 replicas estan corriendo:
kubectl get pods -l app=webapp -o wide
La columna NODE muestra en que nodo corre cada pod. Con multiples nodos, Kubernetes distribuye las replicas automaticamente.
Probar resiliencia
Elimina un pod y observa como el Deployment lo recrea:
# Obtener nombre de un pod
kubectl get pods -l app=webapp
# Eliminar uno
kubectl delete pod webapp-xxxxx
# Ver como se crea uno nuevo inmediatamente
kubectl get pods -l app=webapp -w
El Deployment garantiza que siempre existan 3 replicas.
Siguiente: Capitulo 6: Services —>