Der kube-apiserver ist die zentrale Komponente eines Kubernetes-Clusters. Er stellt die Kubernetes REST API bereit und ist der einzige Dienst, über den der Clusterzustand gelesen oder verändert wird. Alle Werkzeuge und internen Prozesse wie kubectl, Scheduler, Controller oder Operatoren kommunizieren ausschließlich mit ihm.
Wo wird der kube-apiserver betrieben?
Der API-Server läuft innerhalb der Kubernetes Control Plane (Master-Ebene). In produktiven Umgebungen wird er meist redundant auf mehreren Control-Plane-Nodes betrieben und über einen internen oder externen Load Balancer erreichbar gemacht. Er ist eng mit etcd verbunden, der verteilten Key-Value-Datenbank, in der der komplette Clusterzustand gespeichert wird.
Typische Betriebsformen, die ich in der Praxis sehe:
- Als statischer Systemdienst bei selbst installierten Clustern (kubeadm, Bare Metal)
- Als Container/Pod in gemanagten Distributionen (OpenShift, Rancher, Tanzu)
- Automatisch verwaltet in Cloud-Services wie EKS, AKS oder GKE
Wie funktioniert der kube-apiserver?
Kubernetes basiert auf dem Prinzip des Desired State. Der kube-apiserver nimmt Anfragen entgegen, prüft sie und schreibt den gewünschten Zustand in etcd. Danach sorgen Controller dafür, dass die reale Umgebung diesem Zustand entspricht.
Request-Verarbeitung
- Authentifizierung: Der API-Server prüft Identität über Zertifikate, Token oder OIDC.
- Autorisierung: Mit RBAC wird entschieden, ob die Operation erlaubt ist.
- Admission Control: Zusätzliche Richtlinien und Webhooks können Objekte prüfen oder verändern.
- Validierung: Das Objekt wird gegen das API-Schema geprüft.
- Persistenz: Speicherung in etcd als neue Version der Ressource.
- Events/Watches: Andere Komponenten reagieren eventbasiert auf Änderungen.
Kommunikationsmodell
Der kube-apiserver ist kein einfacher Webservice, sondern eine stark gesicherte API-Schicht:
- Er bietet CRUD-Operationen für Ressourcen wie Pods, Deployments und Services.
- Er ermöglicht Watch-Streams, damit Komponenten Änderungen in Echtzeit erhalten.
- Er versioniert jedes Objekt und verhindert konkurrierende inkonsistente Schreibzugriffe.
- Er liefert Metriken und Audit-Logs zur Überwachung.
Beispiele der Nutzung
Objekt anlegen
Beim Befehl kubectl apply -f deployment.yaml sendet das Tool eine HTTP-Anfrage an den kube-apiserver. Dieser legt das Deployment in etcd an, der Deployment-Controller erzeugt anschließend die passenden Pods.
Status abfragen
Mit kubectl get pods lese ich über den API-Server den aktuellen Zustand, ohne direkt auf Nodes zugreifen zu müssen.
Debugging
kubectl describe pod zeigt mir Events, die vom kube-apiserver gesammelt und bereitgestellt werden, etwa Fehler des Schedulers wie FailedScheduling.
Fazit
Der kube-apiserver ist die zentrale, gesicherte API-Schicht der Kubernetes Control Plane. Er läuft auf Master-/Control-Plane-Nodes, kommuniziert direkt mit etcd und verarbeitet alle Anfragen nach klaren Regeln aus Authentifizierung, RBAC und Admission Control. Er selbst führt keine Container aus, sondern speichert und verteilt den Zustand, auf dessen Basis Kubernetes arbeitet.