Kubernetes-Architektur Teil 2 - API-Server, API Objects

Dies ist der zweite Teil des Artikels über Kubernetes Komponenten. In diesem Teil geht es hauptsächlich um den Kubernetes API Server und die dazugehörigen Komponenten; RESTful API, API Objects, API Group, API Versioning. 

• Teil 5 - Taints & Tolerations, NodeSelector, Affinity 
• Teil 4 - Workload Oobjekte
• Teil 3 - Namespaces, Labels und Annotations
• Teil 1 - Überblick über die Kubernetes Architektur

API Server

Der API-Server ist eine Komponente eines Kubernetes-Clusters, die als zentrale Steuereinheit zwischen den verschiedenen Komponenten des Clusters und den Benutzern/Administratoren agiert. Die Konfiguration und Steuerung des Kubernetes-Clusters ist nur über den API-Server möglich. Der Kubernetes API-Server ist ein typisches Beispiel für die Client-Server-Architektur.

Der API-Server selbst ist ein einzelner, in der Programmiersprache Go geschriebener Prozess. Der API-Server stellt eine RESTful API bereit, die für Authentifizierung, Autorisierung, Validierung, Zulassung, Ressourcenspeicherung, Informationsabruf sowie CRUD-Operationen (Create, Read, Update, Delete) verantwortlich ist.

Hier sind die Kernfunktionen der RESTful im erweiterten Überblick:

RESTful API

Im Allgemeinen ist eine RESTful API (Representational State Transfer) eine Softwarearchitektur, die es Systemen ermöglicht, über das Internet/Intranet per http miteinander zu kommunizieren und Ressourcen auszutauschen.

RESTful APIs basieren auf dem Konzept von Ressourcen. Eine Ressource ist ein Objekt (oft als Entität bezeichnet), auf das über eine eindeutige URL zugegriffen werden kann.

Der Client kann eine Anwendung, ein Skript oder ein System sein, das die API-Anfragen sendet. Der Kubernetes API-Server verarbeitet diese Anfragen. Dabei ist die RESTful API zustandslos, das bedeutet, dass keine Informationen über vorherige Anfragen speichert werden.

In einem Kubernetes-Cluster gibt es viele verschiedene Arten von Ressourcen, wie z.B. Pods, Deployments, Services und ConfigMaps. Jede dieser Ressourcen hat ihre eigene spezielle URL, über die man sie in der API aufrufen kann.

Die häufigsten http-Methoden in Kubernetes sind (die kursiv markierten Methoden gelten als speziell):

• GET - eine Ressource abrufen oder Informationen darüber erhalten
• POST - eine neue Ressource erstellen
• PUT - eine vorhandene Ressource aktualisieren oder ersetzen
• DELETE - eine vorhandene Ressource löschen
• PATCH - die angegebenen Felder einer Ressource ändern
• LOG - abrufen von Protokollen aus einem Container in einem Pod
• EXEC - ausführen eines Befehls in einem Container und Abrufen der Ausgabe
• WATCH - Änderungsbenachrichtigungen für eine Ressource mit Streaming-Ausgabe

kubectl api-resources

kubectl api-resources - zeigt die Ressourcen zusammen mit ihren Kurznamen, API-Gruppen und ob sie in einem bestimmten Namespace verfügbar oder clusterweit verfügbar sind.

Authentifizierung, Autorisierung, Validierung und Zulassung

Authentifizierung

Der API-Server ist verantwortlich für die Authentifizierung von Benutzern und Komponenten, die auf den Kubernetes Cluster zugreifen möchten. Der API-Server stellt sicher, dass nur authentifizierte Benutzer und Komponenten auf die Ressourcen zugreifen dürfen.

Autorisierung

Nach der Authentifizierung eines Benutzers oder einer Komponente prüft der API-Server, ob diese berechtigt sind, die angeforderte Aktion auf der angegebenen Ressource auszuführen. Der API-Server kann sowohl Role-Based Access Control (RBAC) als auch Attribute-Based Access Control (ABAC) verwenden, wobei RBAC die empfohlene und standardmäßige Methode ist.

Validierung

Der API-Server validiert eingehende API-Anfragen, nachdem diese authentifiziert und autorisiert wurden. Der API-Server überprüft, ob die in der Anfrage enthaltenen Daten korrekt formatiert sind und alle erforderlichen Felder enthalten. Wenn die Anfrage die Validierung nicht besteht, wird sie abgelehnt und der Client erhält eine Fehlermeldung.

Zulassung

Nachdem eine Anfrage die Validierung bestanden hat, durchläuft sie den Zulassungsprozess. Der API-Server kann auch zusätzlichen Kontrollen durchführen und möglicherweise die Anpassungen vornehmen. z.B. an dieser Stelle sind die "Admission Webhooks" (ValidatingAdmissionWebhook, MutatingAdmissionWebhook) integriert.

Anschließend werden die Anfragen, die  authentifiziert, autorisiert,  validiert und zugelassen wurden, die Ressourcen und ihr Status in der ETCD gespeichert.

Informationsaustausch mit ETCD

Die Kommunikation mit der Datenbank (ETCD) gehört ebenfalls zu der Kernaufgaben der API-Server. In diesem Fall ist der API-Server für diese Aufgaben verantwortlich:  Lesen von Daten, Schreiben von Daten und Beobachten von Änderungen.

Lesen von Daten

Wenn eine Komponente (oder ein Benutzer über kubectl) den Zustand einer Ressource abfragen möchte, sendet sie eine Anfrage an den API-Server. Der API-Server liest dann die entsprechenden Daten aus ETCD und sendet sie an den Anfragenden zurück.

Schreiben von Daten

Wenn eine Komponente den Zustand einer Ressource ändern möchte, sendet sie eine Anfrage an den API-Server. Der API-Server validiert die Anfrage und schreibt die Änderungen in der ETCD.

Beobachten von Änderungen

Viele Komponenten in Kubernetes müssen auf Änderungen an bestimmten Ressourcen reagieren. Dies passiert, indem sie den API-Server auffordern, sie über Änderungen zu informieren. Der API Server hält eine Verbindung zu ETCD und wird über Änderungen informiert, die er danach an die beobachtenden Komponenten weiterleitet.

Skalierbarkeit, Erweiterbarkeit, Versionskontrolle

Skalierbarkeit, Erweiterbarkeit und Versionskontrolle sind weitere Eigenschaften des API-Servers.

Skalierbarkeit. Die Architektur des API-Servers ermöglicht eine horizontale Skalierung, um sowohl die Leistung als auch die Verfügbarkeit zu erhöhen. 

Erweiterbarkeit. Der API-Server ist erweiterbar und kann mit zusätzlichen Funktionen ausgestattet werden, ohne dass der Kern des API-Servers verändert werden muss. Die wohl bekannteste Möglichkeit ist die Verwendung von Custom Resource Definitions (CRDs). Die CRDs bieten die Möglichkeit, neue Ressourcentypen zu definieren, die der API-Server verstehen kann. Weitere Methoden sind Aggregated APIs, Admission Controllers, API Extensions und Webhooks.

Versionskontrolle. Der API-Server unterstützt die Versionskontrolle für die APIs, und ermöglicht damit die Abwärtskompatibilität. Mehr dazu unten im Abschnitt: API Groups

API Objects

Die API-Objekte sind die grundlegenden Einheiten (in der offiziellen Dokumentation als Persistent Entities bezeichnet), mit denen Kubernetes interagiert und die den Zustand des Kubernetes-Clusters repräsentieren. 

Die API Objekte: 

• repräsentieren und definieren den Zustand des Kubernetes-Clusters
• stellen alles dar, was in einem Kubernetes-Cluster existiert
• dienen als Basis, um den aktuellen Zustand mit dem gewünschten Zustand zu vergleichen
• dienen als Schnittstelle zwischen dem Benutzer und dem Kubernetes-System
• werden im YAML- oder JSON-Format beschrieben
• können über die Kubernetes API oder über kubectl erstellt, aktualisiert und gelöscht werden

"Kubernetes API-Objekte sind auf drei Arten organisiert" bezieht sich auf die Struktur und Kategorisierung von API-Objekten innerhalb von Kubernetes. Hier sind die drei Arten, wie sie organisiert sind: Kind, API-Group und API-Version

Kind

Kind - ist ein String-Wert, der den Typ des API-Objekts darstellt. In Kubernetes gibt es keine feste Anzahl von Kind-Typen. Die Anzahl der verfügbaren Ressourcentypen hängt von den installierten Erweiterungen, benutzerdefinierten Ressourcen und der verwendeten Version von Kubernetes ab.

Hier sind die häufig verwendete "Kind"-Typen, die in den meisten Kubernetes-Clustern vorhanden sind:

API Groups

• Zurück
• Weiter