Sari la conținutul principal

Diagnostic, curățare și concluzii

Probleme frecvente​

kubectl top nu returnează valori​

kubectl get apiservice v1beta1.metrics.k8s.io
kubectl logs deployment/metrics-server -n kube-system --tail=100

Verificați că folosiți clusterul kind-cc-lab5 și Kubernetes v1.34.x.

Stack-ul de monitorizare rămâne Pending​

kubectl get pods -n monitoring
kubectl describe pod -n monitoring <numele-podului>
kubectl get events -n monitoring --sort-by=.metadata.creationTimestamp | tail -n 20

Alocați mai multă memorie Docker Desktop sau opriți alte clustere locale.

Ticketing API apare ImagePullBackOff​

Imaginea GHCR trebuie să fie publică. Alternativ:

docker build -t ghcr.io/cloud-computing-upb/lab5:1.0.0 .
kind load docker-image ghcr.io/cloud-computing-upb/lab5:1.0.0 --name cc-lab5
kubectl rollout restart deployment/ticketing-api -n cc-lab5

Ținta Ticketing API lipsește din Prometheus​

kubectl get servicemonitor ticketing-api -n cc-lab5 --show-labels
kubectl get service ticketing-api -n cc-lab5 --show-labels
kubectl get endpointslice -n cc-lab5 -l kubernetes.io/service-name=ticketing-api

Verificați eticheta release=monitoring, selectorul și portul numit http.

Dashboard-ul nu apare​

kubectl get configmap ticketing-grafana-dashboard -n cc-lab5 --show-labels
kubectl logs deployment/monitoring-grafana -n monitoring -c grafana-sc-dashboard --tail=100

Curățare​

Varianta rapidă șterge întregul cluster și toate volumele locale:

kind delete cluster --name cc-lab5

Dacă doriți să inspectați separat dezinstalarea:

helm uninstall ticketing -n cc-lab5
helm uninstall monitoring -n monitoring
helm uninstall metrics-server -n kube-system

kubectl delete namespace cc-lab5 monitoring
kind delete cluster --name cc-lab5

CRD-urile instalate de kube-prometheus-stack există până la ștergerea clusterului Kind.

Concluzii​

În acest laborator am legat patru niveluri:

  1. kubelet/cAdvisor oferă metrici detaliate despre containere
  2. Metrics Server oferă valori curente pentru kubectl top și HPA
  3. Prometheus păstrează istoricul și evaluează interogări și reguli
  4. Grafana și logurile aplicației transformă semnalele în dovezi pentru diagnostic.

Am observat și o limită importantă: mai multe replici pot absorbi încărcare CPU, dar nu repară orice cauză a latenței sau erorilor.

Întrebări de verificare​

  1. De ce nu poate Metrics Server înlocui Prometheus?
  2. De ce folosim rate() pentru un counter?
  3. De ce ruta este o etichetă mai sigură decât URL-ul complet?
  4. Ce condiție trebuie îndeplinită pentru ca HPA să calculeze utilizarea CPU procentuală?
  5. De ce dashboard-ul și regulile sunt păstrate în Git?
  6. Ce dovadă arată că incidentul este aplicativ și nu o problemă de readiness?
  7. În ce situație adăugarea de replici nu reduce rata erorilor?