Skip to main content

Erori, rollback și curățare

În ultima parte a laboratorului introducem două erori controlate și folosim informațiile oferite de Kubernetes pentru a le diagnostica.

Imagine inexistentă​

Aplicați Deployment-ul care referă o imagine inexistentă:

kubectl apply -f k8s/scenarios/deployment-broken-image.yaml
kubectl rollout status deployment/ticketing-api -n cc-lab2 --timeout=30s

Este de așteptat ca ultima comandă să expire. Inspectați starea:

kubectl get deployments,replicasets,pods -n cc-lab2
kubectl describe deployment ticketing-api -n cc-lab2
kubectl describe pod <nume-pod-cu-eroare> -n cc-lab2
kubectl get events -n cc-lab2 --sort-by=.metadata.creationTimestamp

Pod-ul nou va ajunge, de regulă, în starea ImagePullBackOff sau ErrImagePull. Deoarece noul Pod nu devine Ready și strategia are maxUnavailable: 0, vechile replici funcționale sunt păstrate.

Consultați istoricul și reveniți la ultima revizie funcțională:

kubectl rollout history deployment/ticketing-api -n cc-lab2
kubectl rollout undo deployment/ticketing-api -n cc-lab2
kubectl rollout status deployment/ticketing-api -n cc-lab2

Pentru revenirea la o revizie anume se poate folosi:

kubectl rollout undo deployment/ticketing-api \
  -n cc-lab2 \
  --to-revision=<număr-revizie>

Selector greșit​

Opriți orice sesiune port-forward rămasă activă. O sesiune deja stabilită poate continua să comunice direct cu Pod-ul ales anterior și nu ar demonstra corect problema selectorului.

Aplicați Service-ul al cărui selector nu corespunde Pod-urilor:

kubectl apply -f k8s/scenarios/service-broken-selector.yaml
kubectl describe service ticketing-api -n cc-lab2
kubectl get endpointslices -n cc-lab2 \
  -l kubernetes.io/service-name=ticketing-api

Service-ul există, dar nu mai are endpoint-uri funcționale. O nouă încercare de port-forward către Service nu va putea selecta un Pod:

kubectl port-forward service/ticketing-api -n cc-lab2 8080:80

Restaurați Service-ul corect:

kubectl apply -f k8s/base/30-service.yaml
kubectl get endpointslices -n cc-lab2 \
  -l kubernetes.io/service-name=ticketing-api

Porniți din nou port-forward, dacă este necesar, și executați testul final:

kubectl port-forward service/ticketing-api -n cc-lab2 8080:80

În alt terminal:

curl http://localhost:8080/health
curl http://localhost:8080/info

Curățare​

Opriți port-forward cu Ctrl+C, apoi ștergeți clusterul:

kind delete cluster --name cc-lab2

Ce am obținut​

Am pornit de la imaginea aplicației din Laboratorul 1 și am ajuns la:

  • o aplicație declarată printr-un Deployment
  • mai multe replici menținute automat
  • un endpoint stabil oferit de un Service
  • self-healing și scalare
  • actualizare graduală și rollback
  • diagnosticarea unor erori uzuale.

În Laboratorul 3 vom adăuga PostgreSQL și persistență și vom analiza ce se întâmplă cu datele și disponibilitatea atunci când componentele eșuează.