Dieses Dokument wurde mithilfe automatisierter maschineller Übersetzungstechnologie übersetzt. Wir bemühen uns um korrekte Übersetzungen, übernehmen jedoch keine Gewähr für die Vollständigkeit, Richtigkeit oder Zuverlässigkeit der übersetzten Inhalte. Im Falle von Abweichungen ist die englische Originalversion maßgebend und stellt den verbindlichen Text dar.

Rollen für Knoten in Kubernetes

In diesem Abschnitt werden die Rollen für etcd-Knoten, Controlplane-Knoten und Worker-Knoten in Kubernetes beschrieben und wie die Rollen in einem Cluster zusammenarbeiten.

Dieses Diagramm ist für Kubernetes-Cluster die mit Rancher unter Verwendung von RKE gestartet wurden. geeignet.

Clusterdiagramm
Figure 1. Die Linien zeigen den Datenfluss zwischen den Komponenten. Farben werden ausschließlich zur visuellen Unterstützung verwendet

etcd

Knoten mit der Rolle etcd führen etcd aus, das ein konsistenter und hochverfügbarer Schlüssel-Wert-Speicher ist, der als Kubernetes’ Backing Store für alle Cluster-Daten verwendet wird. etcd repliziert die Daten auf jeden Knoten.

Knoten mit der Rolle etcd werden in der Benutzeroberfläche als Unschedulable angezeigt, was bedeutet, dass standardmäßig keine Pods auf diesen Knoten geplant werden.

controlplane

Knoten mit der Rolle controlplane führen die Kubernetes-Masterkomponenten aus (ausgenommen etcd, da dies eine separate Rolle ist). Siehe Kubernetes: Master-Komponenten für eine detaillierte Liste der Komponenten.

Knoten mit der Rolle controlplane werden in der Benutzeroberfläche als Unschedulable angezeigt, was bedeutet, dass standardmäßig keine Pods auf diesen Knoten geplant werden.

kube-apiserver

Der Kubernetes API-Server (kube-apiserver) skaliert horizontal. Jeder Knoten mit der Rolle controlplane wird dem NGINX-Proxy auf den Knoten mit Komponenten hinzugefügt, die auf den Kubernetes API-Server zugreifen müssen. Das bedeutet, dass wenn ein Knoten nicht erreichbar wird, der lokale NGINX-Proxy auf dem Knoten die Anfrage an einen anderen Kubernetes API-Server in der Liste weiterleitet.

kube-controller-manager

Der Kubernetes Controller-Manager verwendet Leader Election über einen Endpunkt in Kubernetes. Eine Instanz des kube-controller-manager erstellt einen Eintrag in den Kubernetes-Endpunkten und aktualisiert diesen Eintrag in einem konfigurierten Intervall. Andere Instanzen sehen einen aktiven Leader und warten darauf, dass dieser Eintrag abläuft (zum Beispiel, wenn ein Knoten nicht reagiert).

kube-scheduler

Der Kubernetes Scheduler verwendet Leader Election über einen Endpunkt in Kubernetes. Eine Instanz des kube-scheduler erstellt einen Eintrag in den Kubernetes-Endpunkten und aktualisiert diesen Eintrag in einem konfigurierten Intervall. Andere Instanzen sehen einen aktiven Leader und warten darauf, dass dieser Eintrag abläuft (zum Beispiel, wenn ein Knoten nicht reagiert).

Worker

Knoten mit der Rolle worker führen die Kubernetes-Knotenkomponenten aus. Siehe Kubernetes: Knotenkomponenten für eine detaillierte Liste der Komponenten.

Hinweise