cAdvisor și metricile containerelor
De unde provin metricile de resurse
cAdvisor este integrat în kubelet și colectează pentru containere informații precum:
- timpul CPU consumat
- memoria utilizată și working set-ul
- traficul de rețea
- operațiile de I/O
- identificarea podului, namespace-ului și containerului.
Metrics Server prelucrează o parte dintre aceste date pentru autoscaling. Prometheus poate colecta serii mai detaliate și le poate păstra în timp.
Inspectarea endpoint-ului kubelet
Nu expunem kubelet direct pe gazdă. Accesăm endpoint-ul prin Kubernetes API, folosind drepturile utilizatorului curent:
NODE=$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')
kubectl get --raw "/api/v1/nodes/${NODE}/proxy/metrics/cadvisor" \
| head -n 30
Filtrați câteva familii de metrici:
kubectl get --raw "/api/v1/nodes/${NODE}/proxy/metrics/cadvisor" \
| grep -E '^container_(cpu_usage_seconds_total|memory_working_set_bytes|network_receive_bytes_total)' \
| head
O serie conține un nume, o valoare și etichete care identifică sursa:
container_cpu_usage_seconds_total{
namespace="cc-lab5",
pod="ticketing-api-...",
container="api"
} ...
Metrici de infrastructură versus metrici aplicative
| cAdvisor / kubelet | Ticketing API |
|---|---|
| CPU, memorie, rețea și I/O | cereri, erori și latență |
| vede containerul | înțelege rutele și statusurile HTTP |
| poate explica presiunea pe resurse | poate explica impactul asupra utilizatorului |
| nu știe câte tichete au fost create | expune tickets_created_total |
Un pod poate consuma puțin CPU și totuși aplicația să răspundă lent din cauza unei dependențe. De aceea, observabilitatea nu se reduce la resursele containerului.
Etichetele Prometheus trebuie să aibă un număr controlat de valori. Folosim ruta normalizată
GET /tickets/{id}, nu URL-ul concret /tickets/123, pentru a evita crearea unei serii noi
pentru fiecare tichet.