Wiki.Pilas.Guru

5. Resiliencia y actualizaciones

Eliminar el Pod de la API

Observar los Pods:

kubectl get pods -n mern -l app=api -w

En otra terminal, eliminar un Pod:

kubectl delete pod -n mern <nombre-del-pod>

El Deployment y su ReplicaSet crean otro Pod automáticamente.

El Service no depende del nombre del Pod. Selecciona los Pods mediante:

selector:
  app: api

Port-forward y recreación de Pods

Si se elimina el Pod seleccionado por kubectl port-forward, el túnel puede caer:

network namespace for sandbox ... is closed

Esto no significa que el Service haya desaparecido. El port-forward es un túnel temporal ligado a un Pod seleccionado. Hay que crearlo nuevamente.

Añadir readiness y liveness

En el contenedor api, al mismo nivel que ports y env, añadir:

          readinessProbe:
            httpGet:
              path: /
              port: 3000
            initialDelaySeconds: 5
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 3

          livenessProbe:
            tcpSocket:
              port: 3000
            initialDelaySeconds: 10
            periodSeconds: 10

Aplicar:

kubectl apply -f k8s/01-db-api.yaml
kubectl rollout status deployment/api -n mern

La readinessProbe controla si el Pod recibe tráfico. La livenessProbe controla si el contenedor debe reiniciarse.

Escalar la API

kubectl scale deployment api --replicas=2 -n mern

Comprobar los endpoints:

kubectl get endpointslice \
  -n mern \
  -l kubernetes.io/service-name=api \
  -o wide

Eliminar uno de los Pods:

kubectl delete pod -n mern <nombre-del-pod>

Con dos réplicas, la aplicación puede continuar atendiendo tráfico mediante la otra réplica.

Rolling update y rollback

Observar los Pods:

kubectl get pods -n mern -l app=api -w

Crear una nueva revisión modificando una variable:

kubectl set env deployment/api RELEASE=v2 -n mern

Esperar el rollout:

kubectl rollout status deployment/api -n mern
kubectl rollout history deployment/api -n mern

Volver a la revisión anterior:

kubectl rollout undo deployment/api -n mern
kubectl rollout status deployment/api -n mern

Durante los rollouts, si la aplicación local deja de responder, comprobar primero que el port-forward del Ingress sigue activo:

kubectl port-forward \
  -n ingress-nginx \
  service/ingress-nginx-controller \
  8080:80

Pruebas a realizar

Además de las pruebas realizadas durante cada cambio, se puede observar el
estado completo de la aplicación con:

kubectl get all -n mern
kubectl get events -n mern --sort-by=.lastTimestamp

También resulta útil describir el Deployment para relacionar sus réplicas,
ReplicaSets y Pods:

kubectl describe deployment api -n mern
kubectl get replicasets -n mern -l app=api

Después de añadir las probes, observar los estados de preparación y los
reinicios:

kubectl get pods -n mern -l app=api \
  -o custom-columns=NAME:.metadata.name,READY:.status.containerStatuses[0].ready,RESTARTS:.status.containerStatuses[0].restartCount

Se puede repetir la eliminación de un Pod con dos réplicas y comprobar que el
Service mantiene endpoints disponibles durante la recreación:

kubectl get endpointslice -n mern \
  -l kubernetes.io/service-name=api -w
kubectl delete pod -n mern <nombre-del-pod>

Finalmente, comparar el historial antes y después del cambio y del rollback:

kubectl rollout history deployment/api -n mern
kubectl get pods -n mern -l app=api -o wide

Aprendizajes del despliegue