Ga naar inhoud

KubeSchedulerDown

  • Bron: kube-prometheus-stack default rules
  • Alert: KubeSchedulerDown
  • Severity: critical

Betekenis

Prometheus ziet de kube-scheduler niet (meer) als up via de metrics endpoint. Dit kan duiden op: - Scheduler-proces is gestopt of gecrasht. - Metrics endpoint is niet bereikbaar (network/RBAC/ServiceMonitor). - In managed control planes: tijdelijke provider-storing of maintenance.

Typische trigger

Afgeleid van de up{job="kube-scheduler"} metric (of absent(...)) gedurende een periode (bijv. 15m).

Runbook

  1. Verifieer status
  2. kubectl -n kube-system get pods -l component=kube-scheduler -o wide (labels kunnen per distro afwijken).
  3. Bekijk up{job="kube-scheduler"} in Prometheus en de Targets-pagina: is de scrape failing? (DNS, TLS, 401/403, timeout)
  4. Logs/gezondheid
  5. kubectl -n kube-system logs -l component=kube-scheduler --tail=200
  6. Control-plane events: kubectl -n kube-system get events --sort-by=.lastTimestamp
  7. Scraping en netwerk
  8. ServiceMonitor/Endpoints: bestaat er een Service/Endpoints voor de scheduler metrics en matcht de ServiceMonitor-selector?
  9. NetworkPolicy/Firewall: mag Prometheus de scheduler endpoint bereiken?
  10. TLS/RBAC: vereist de endpoint auth? Controleer eventueel certificaten en rollen.
  11. Managed vs self-managed
  12. Managed (AKS/EKS/GKE): controleer provider status/maintenance-meldingen; vaak herstelt dit automatisch. Escaleer naar cloud support bij aanhoudende uitval.
  13. Self-managed: herstel scheduler (re-deploy/rollout/restart), verhelp resource- of configuratieproblemen en zorg voor HA (meerdere replicas) waar passend.
  14. Validatie
  15. up{job="kube-scheduler"} == 1 voor alle verwachte instanties.
  16. Alert gaat naar Resolved na enkele evaluaties.

Routing

  • Slack via default receiver; critical prioriteit.

Test (alleen non-prod)

  • Pauzeer de scheduler of blokkeer de metrics-scrape tijdelijk (NetworkPolicy/Service) en controleer dat de alert vuurt; herstel daarna direct.