Fasse die Hauptkomponenten einer Kubernetes-Cluster-Kontrollebene in diesem Absatz zusammen
Kubernetes definiert eine Reihe von Bausteinen ("Primitives"), die gemeinsam Mechanismen für den Einsatz, die Wartung und die Skalierung von Anwendungen auf der Grundlage von CPU-, Speicher- oder benutzerdefinierten Metriken bereitstellen. Kubernetes ist lose gekoppelt und erweiterbar, um unterschiedlichen Arbeitslasten gerecht zu werden. Sowohl die internen Komponenten als auch die Erweiterungen und Container, die auf Kubernetes laufen, basieren auf der Kubernetes-API. Die Plattform übt ihre Kontrolle über Rechen- und Speicherressourcen aus, indem sie Ressourcen als Objekte definiert, die dann auch als solche verwaltet werden können.

Kubernetes folgt der primären/replizierenden Architektur. Die Komponenten von Kubernetes lassen sich in solche, die einen einzelnen Knoten verwalten, und solche, die Teil der Steuerungsebene sind, unterteilen.

Steuerebene
Der Kubernetes-Masterknoten verwaltet die Kubernetes-Kontrollebene des Clusters, indem er die Arbeitslast verwaltet und die Kommunikation innerhalb des Systems steuert. Die Kubernetes-Kontrollebene besteht aus verschiedenen Komponenten, von denen jede ein eigener Prozess ist, der sowohl auf einem einzigen Master-Knoten als auch auf mehreren Mastern laufen kann, die hochverfügbare Cluster unterstützen. Die verschiedenen Komponenten der Kubernetes-Kontrollebene sind wie folgt:

etcd ist ein persistenter, leichtgewichtiger, verteilter Key-Value-Datenspeicher, den CoreOS entwickelt hat. Er speichert zuverlässig die Konfigurationsdaten des Clusters, die den Gesamtzustand des Clusters zu jedem beliebigen Zeitpunkt repräsentieren. etcd zieht im Falle einer Netzwerkpartition die Konsistenz der Verfügbarkeit vor (siehe CAP-Theorem). Die Konsistenz ist entscheidend für die korrekte Planung und den Betrieb von Diensten.
Der API-Server bedient die Kubernetes-API mit JSON über HTTP, die sowohl die interne als auch die externe Schnittstelle zu Kubernetes darstellt. Der API-Server verarbeitet und validiert REST-Anfragen und aktualisiert den Status der API-Objekte in etcd, so dass Clients Workloads und Container über Worker Nodes hinweg konfigurieren können. Der API-Server nutzt die Watch-API von etcd, um den Cluster zu überwachen, kritische Konfigurationsänderungen auszurollen oder Abweichungen vom Status des Clusters auf den vom Deployer deklarierten Status zurückzusetzen. Der Deployer kann z. B. angeben, dass drei Instanzen eines bestimmten "Pods" (siehe unten) laufen müssen. etcd speichert diese Tatsache. Wenn der Deployment Controller feststellt, dass nur zwei Instanzen laufen (was im Widerspruch zur etcd-Deklaration steht), plant er die Erstellung einer zusätzlichen Instanz dieses Pods.
Der Scheduler ist die erweiterbare Komponente, die anhand der Ressourcenverfügbarkeit auswählt, auf welchem Knoten ein ungeplanter Pod (die vom Scheduler verwaltete Basisinstanz) läuft. Der Scheduler verfolgt die Ressourcennutzung auf jedem Knoten, um sicherzustellen, dass die Arbeitslast nicht über die verfügbaren Ressourcen hinaus geplant wird. Zu diesem Zweck muss der Scheduler die Ressourcenanforderungen, die Ressourcenverfügbarkeit und andere vom Benutzer vorgegebene Einschränkungen oder Richtlinien wie Quality-of-Service, Affinitäts- und Anti-Affinitätsanforderungen und Datenlokalität kennen. Die Aufgabe des Schedulers ist es, das "Angebot" an Ressourcen mit der "Nachfrage" nach Workloads abzustimmen.
Ein Controller ist eine Abstimmungsschleife, die den tatsächlichen Clusterzustand in Richtung des gewünschten Zustands steuert und mit dem API-Server kommuniziert, um die von ihm verwalteten Ressourcen (z. B. Pods oder Service-Endpunkte) zu erstellen, zu aktualisieren und zu löschen. Eine Art von Controller ist der Replication Controller, der die Replikation und Skalierung steuert, indem er eine bestimmte Anzahl von Kopien eines Pods im gesamten Cluster ausführt. Er kümmert sich auch um die Erstellung von Ersatz-Pods, wenn der zugrundeliegende Knoten ausfällt. Andere Controller, die Teil des Kubernetes-Kernsystems sind, sind ein DaemonSet-Controller, der genau einen Pod auf jeder Maschine (oder einer Teilmenge von Maschinen) ausführt, und ein Job-Controller, der Pods ausführt, die bis zum Ende laufen (z. B. als Teil eines Batch-Jobs). Label-Selektoren, die Teil der Controller-Definition sind, geben die Menge der Pods an, die ein Controller verwaltet.
Der Controller-Manager ist ein Prozess, der eine Reihe von Kubernetes-Kerncontrollern verwaltet.
Die Steuerungsebene des Kubernetes-Clusters läuft auf einem oder mehreren Master-Knoten. Die Komponenten sind:
1. etcd - ein Key Value Datastore, der die Konfigurationsdaten des Clusters enthält.
2. Der api-server ist ein Server, der den Status des Kubernetes-Clusters bedient und aktualisiert. Er überwacht etcd und hält den Ist-Zustand des Clusters mit seinem Soll-Zustand synchron.
3. Der Scheduler ist eine Komponente, die auswählt, auf welchem Knoten ein ungeplanter Pod ausgeführt werden soll, je nachdem, was der Pod braucht und was die Knoten im Cluster unterstützen können.
4. Der Controller-Manager verwaltet mehrere Controller, die den Cluster mit seinem gewünschten Zustand synchronisieren.
Summarize the main components of a Kubernetes cluster control plane from this paragraph
Kubernetes defines a set of building blocks ("primitives") that collectively provide mechanisms that deploy, maintain, and scale applications based on CPU, memory[33] or custom metrics.[34] Kubernetes is loosely coupled and extensible to meet different workloads. The internal components as well as extensions and containers that run on Kubernetes rely on the Kubernetes API.[35] The platform exerts its control over compute and storage resources by defining resources as Objects, which can then be managed as such.

Kubernetes follows the primary/replica architecture. The components of Kubernetes can be divided into those that manage an individual node and those that are part of the control plane.[35][36]

Control plane
The Kubernetes master node handles the Kubernetes control plane of the cluster, managing its workload and directing communication across the system. The Kubernetes control plane consists of various components, each its own process, that can run both on a single master node or on multiple masters supporting high-availability clusters.[36] The various components of the Kubernetes control plane are as follows:

etcd[37] is a persistent, lightweight, distributed, key-value data store that CoreOS has developed. It reliably stores the configuration data of the cluster, representing the overall state of the cluster at any given point of time. etcd favors consistency over availability in the event of a network partition (see CAP theorem). The consistency is crucial for correctly scheduling and operating services.
The API server serves the Kubernetes API using JSON over HTTP, which provides both the internal and external interface to Kubernetes.[35][38] The API server processes and validates REST requests and updates the state of the API objects in etcd, thereby allowing clients to configure workloads and containers across worker nodes.[39] The API server uses etcd's watch API to monitor the cluster, roll out critical configuration changes, or restore any divergences of the state of the cluster back to what the deployer declared. As an example, the deployer may specify that three instances of a particular "pod" (see below) need to be running. etcd stores this fact. If the Deployment Controller finds that only two instances are running (conflicting with the etcd declaration),[40] it schedules the creation of an additional instance of that pod.[36]
The scheduler is the extensible component that selects on which node an unscheduled pod (the basic entity managed by the scheduler) runs, based on resource availability. The scheduler tracks resource use on each node to ensure that workload is not scheduled in excess of available resources. For this purpose, the scheduler must know the resource requirements, resource availability, and other user-provided constraints or policy directives such as quality-of-service, affinity vs. anti-affinity requirements, and data locality. The scheduler's role is to match resource "supply" to workload "demand".[41]
A controller is a reconciliation loop that drives the actual cluster state toward the desired state, communicating with the API server to create, update, and delete the resources it manages (e.g., pods or service endpoints).[42][38] One kind of controller is a Replication Controller, which handles replication and scaling by running a specified number of copies of a pod across the cluster. It also handles creating replacement pods if the underlying node fails.[42] Other controllers that are part of the core Kubernetes system include a DaemonSet Controller for running exactly one pod on every machine (or some subset of machines), and a Job Controller for running pods that run to completion (e.g., as part of a batch job).[43] Labels selectors that are part of the controller's definition specify the set of pods that a controller manages.[44]
The controller manager is a process that manages a set of core Kubernetes controllers.
The kubernetes cluster control plane runs on one more more master nodes. The components are:
1. etcd - a key value datastore containing the configuration data of the cluster.
2. The api-server is a server which serves and updates the state of the kubernetes cluster. It watches etcd and keeps the clusters actual state in sync with its desired state.
3. The scheduler is a component which selects on which node an unscheduled pod should run, based on what each pod needs and what the nodes in the cluster can support.
4. The controller manager manages several controllers which keep the cluster in sync with its desired state.