Kubernetes Engine-(OKE-) und Kubernetes-Konzepte

Ein Kubernetes-Cluster ist eine Gruppe von Knoten (Rechner, auf denen Anwendungen ausgeführt werden). Jeder Knoten kann ein physischer Rechner oder ein virtueller Rechner sein. Die Kapazität des Knotens (CPU-Anzahl und Speichermenge) wird beim Erstellen des Knotens definiert. Ein Cluster umfasst:

• Control-Plane-Knoten (zuvor als "Masterknoten" bezeichnet). Normalerweise sind drei Control-Plane-Knoten für High Availability vorhanden.
• Worker-Knoten, in Knotenpools organisiert.

Wenn Sie ein Cluster mit Kubernetes Engine erstellen, können Sie das neue Cluster als Basiscluster oder als erweitertes Cluster erstellen.

Beim Erstellen eines neuen Clusters mit der Kubernetes-Engine geben Sie den Typ des zu erstellenden Clusters an. Sie können Folgendes angeben:

• Verbessertes Cluster: Erweiterte Cluster unterstützen alle verfügbaren Features, einschließlich Features, die von grundlegenden Clustern nicht unterstützt werden (wie virtuelle Knoten, Cluster-Add-on-Verwaltung, Workload-Identität und zusätzliche Worker-Knoten pro Cluster). Erweiterte Cluster verfügen über ein finanziell abgesichertes Service Level Agreement (SLA).
• Grundlegendes Cluster: Grundlegende Cluster unterstützen alle von Kubernetes und Kubernetes Engine bereitgestellten Kernfunktionen, aber keines der erweiterten Features, die Kubernetes Engine bereitstellt. Grundlegende Cluster haben ein Service Level Objective (SLO), aber kein finanziell unterstütztes Service Level Agreement (SLA).

Beachten Sie Folgendes beim Erstellen von Clustern:

• Wenn Sie mit der Konsole ein Cluster erstellen und während der Clustererstellung keine erweiterten Features auswählen, können Sie das neue Cluster als Basiscluster erstellen. Ein neues Cluster wird standardmäßig als erweitertes Cluster erstellt, es sei denn, Sie möchten explizit ein einfaches Cluster erstellen.
• Wenn Sie ein Cluster mit der CLI oder API erstellen, können Sie angeben, ob ein einfaches Cluster oder ein erweitertes Cluster erstellt werden soll. Wenn Sie nicht explizit den Typ des zu erstellenden Clusters angeben, wird standardmäßig ein neues Cluster als Basiscluster erstellt.

Wenn Sie ein neues Cluster als erweitertes Cluster erstellen, können Sie später problemlos erweiterte Features hinzufügen, selbst wenn Sie anfangs keine erweiterten Features ausgewählt haben. Wenn Sie ein neues Cluster als Basiscluster erstellen möchten, können Sie das Basiscluster auch später auf ein erweitertes Cluster upgraden. Ein erweitertes Cluster kann jedoch nicht auf ein Basiscluster herabgestuft werden.

Siehe Erweiterte Cluster mit einfachen Clustern vergleichen.

Beachten Sie, dass sich alle Verweise auf "Cluster" in der Kubernetes Engine-Dokumentation sowohl auf erweiterte Cluster als auch auf grundlegende Cluster beziehen, sofern nicht ausdrücklich etwas anderes angegeben ist.

Die Kubernetes-Cluster-Control-Plane implementiert die Kernfunktionalität von Kubernetes. Sie wird auf Compute-Instanzen (als "Control-Plane-Knoten" bezeichnet) im Kubernetes-Engine-Service-Mandanten ausgeführt. Die Cluster-Control-Plane wird vollständig von Oracle verwaltet.

Die Cluster-Control-Plane führt eine Reihe von Prozessen aus, darunter:

• kube-apiserver zur Unterstützung von Kubernetes-API-Vorgängen, die vom Kubernetes-Befehlszeilentool (kubectl) und anderen Befehlszeilentools sowie von direkten REST-Aufrufen angefordert werden. Der kube-apiserver-Prozess enthält Zulassungscontroller, die für erweiterte Kubernetes-Vorgänge erforderlich sind.
• kube-controller-manager zur Verwaltung verschiedener Kubernetes-Komponenten (z.B. Replikationscontroller, Endpunktcontroller, Namespace-Controller und Serviceaccountcontroller)
• kube-scheduler, um zu steuern, wo im Cluster Jobs ausgeführt werden sollen
• etcd zum Speichern der Konfigurationsdaten des Clusters
• cloud-controller-manager zum Aktualisieren und Löschen von Worker-Knoten (mit dem Knotencontroller), zum Erstellen von Load Balancern, wenn Kubernetes-Services von type: LoadBalancer erstellt werden (mit dem Servicecontroller) und zum Einrichten von Netzwerkrouten (mit dem Routencontroller). Der OCI-cloud-controller-manager implementiert auch eine Container-Storage-Schnittstelle, einen Flexvolume-Treiber und einen Flexvolume-Provisioner (weitere Informationen finden Sie in der Dokumentation zu OCI Cloud Controller Manager (CCM) auf GitHub).

Mit der Kubernetes-API können Endbenutzer Kubernetes-Ressourcen abfragen und ändern (wie Pods, Namespaces, ConfigMap-Objekte und Ereignisse).

Sie greifen über einen Endpunkt, der in einem Subnetz Ihres VCN gehostet wird, auf die Kubernetes-API auf der Cluster-Control-Plane zu. Bei diesem Kubernetes-API-Endpunktsubnetz kann es sich um ein privates oder ein öffentliches Subnetz handeln. Wenn Sie ein öffentliches Subnetz für den Kubernetes-API-Endpunkt angeben, können Sie den Endpunkt optional dem Internet bereitstellen, indem Sie dem Endpunkt eine öffentliche IP-Adresse zuweisen (und die private IP-Adresse). Der Zugriff auf das Kubernetes-API-Subnetz wird mit Sicherheitsregeln kontrolliert, die für Netzwerksicherheitsgruppen (empfohlen) oder Sicherheitslisten definiert sind.

Worker-Knoten stellen die Data Plane des Clusters dar. In Worker-Knoten werden die Anwendungen ausgeführt, die Sie in einem Cluster bereitstellen.

Jeder Worker-Knoten führt eine Reihe von Prozessen aus, darunter:

• Der kubelet-Prozess zur Kommunikation mit der Cluster-Control-Plane
• Der kube-proxy-Prozess zur Verwaltung von Networkingregeln

Die Cluster-Control-Plane-Prozesse überwachen und erfassen den Status der Worker-Knoten und verteilen angeforderte Vorgänge zwischen ihnen.

Ein Knotenpool ist eine Untergruppe von Worker-Knoten in einem Cluster, die alle dieselbe Konfiguration aufweisen. Mit Knotenpools können Sie Pools von Rechnern in einem Cluster erstellen, die unterschiedliche Konfigurationen haben. Beispiel: Sie können in einem Cluster einen Knotenpool mit virtuellen Maschinen und einen anderen mit Bare-Metal-Rechnern erstellen. Ein Cluster muss mindestens einen Knotenpool aufweisen, aber ein Knotenpool muss keine Worker-Knoten enthalten.

Die Worker-Knoten in einem Knotenpool sind mit einem Worker-Knotensubnetz in Ihrem VCN verbunden.

Beim Erstellen eines Knotenpools geben Sie an, dass die Worker-Knoten im Knotenpool entweder alle als virtuelle Knoten oder alle als verwaltete Knoten erstellt werden.

Beim Erstellen eines Knotenpools mit der Kubernetes-Engine geben Sie an, dass die Worker-Knoten im Knotenpool wie folgt erstellt werden sollen:

• Virtuelle Knoten, vollständig von Oracle verwaltet. Virtuelle Knoten bieten eine "serverlose" Kubernetes-Erfahrung, mit der Sie containerisierte Anwendungen in großem Maßstab ausführen können, ohne den Betriebsaufwand für das Upgrade der Data-Plane-Infrastruktur und die Verwaltung der Clusterkapazität. Sie können nur virtuelle Knoten in erweiterten Clustern erstellen.
• Verwaltete Knoten, die auf Compute-Instanzen (entweder Bare Metal oder Virtual Machine) in Ihrem Mandanten ausgeführt und zumindest teilweise von Ihnen verwaltet werden. Da Sie für die Verwaltung verwalteter Knoten verantwortlich sind, können Sie diese flexibel konfigurieren, um Ihre spezifischen Anforderungen zu erfüllen. Sie sind für das Upgrade von Kubernetes auf verwalteten Knoten und für das Verwalten der Clusterkapazität verantwortlich. Sie können verwaltete Knoten sowohl in Basisclustern als auch in erweiterten Clustern erstellen.

Siehe Virtuelle Knoten mit verwalteten Knoten vergleichen.

Beachten Sie, dass sich alle Verweise auf "Knoten" und "Arbeiterknoten" in der Kubernetes Engine-Dokumentation sowohl auf virtuelle Knoten als auch auf verwaltete Knoten beziehen, sofern nicht ausdrücklich etwas anderes angegeben ist.

Weitere Informationen finden Sie unter Mit selbstverwalteten Knoten arbeiten.

Beachten Sie, dass alle Verweise auf "Knoten" und "Arbeiterknoten" in der Kubernetes Engine-Dokumentation selbstverwaltete Knoten abdecken, sofern nicht ausdrücklich etwas anderes angegeben ist.

Wenn eine auf einem Worker-Knoten ausgeführte Anwendung aus mehreren Containern besteht, fasst Kubernetes die Container zur einfachen Verwaltung und Discovery zu einer einzigen logischen Einheit zusammen, die als Pod bezeichnet wird. Die Container im Pod verwenden denselben Networking-Namespace und denselben Speicherplatz. Sie können von der Cluster-Control-Plane als einzelnes Objekt verwaltet werden. Eine Reihe von Pods, die dieselbe Funktionalität bereitstellen, kann in einem einzigen logischen Set gruppiert werden, das als Service bezeichnet wird.

Kubernetes-Cluster verwenden Container Network Interface-(CNI-)Plug-ins, um die Netzwerkkonnektivität für Pods zu implementieren, die auf Worker-Knoten ausgeführt werden. CNI-Plug-ins konfigurieren Netzwerkschnittstellen, stellen IP-Adressen bereit und pflegen die Konnektivität.

Weitere Informationen zu Pods finden Sie in der Kubernetes-Dokumentation.

In Kubernetes ist ein Service eine Abstraktion, die ein logisches Set von Pods und eine Policy definiert, mit der auf sie zugegriffen werden kann. Welche Pods die Ziele eines Service darstellen, wird normalerweise von einem Selektor bestimmt.

Bei manchen Teilen einer Anwendung (z.B. Frontends) möchten Sie möglicherweise einen Service auf einer externen IP-Adresse außerhalb eines Clusters bereitstellen.

Mit Kubernetes-ServiceTypes können Sie die Art des Service angeben, den Sie bereitstellen möchten. Eine LoadBalancer ServiceType erstellt einen Oracle Cloud Infrastructure-Load Balancer in Load-Balancer-Subnetzen in Ihrem VCN.

Weitere allgemeine Informationen zu Services finden Sie in der Kubernetes-Dokumentation. Weitere Informationen zum Erstellen von Load-Balancer-Services mit der Kubernetes-Engine finden Sie unter Kubernetes-Services des Typs LoadBalancer definieren.

Kubernetes hat die Container Network Interface-(CNI-)Spezifikation für die Netzwerkressourcenverwaltung übernommen. Das CNI besteht aus einer Spezifikation und Bibliotheken zum Schreiben von Plugins zur Konfiguration von Netzwerkschnittstellen in Linux-Containern sowie einer Reihe von unterstützten Plugins.

Kubernetes-Cluster verwenden Container Network Interface-(CNI-)Plug-ins, um die Netzwerkkonnektivität für Pods zu implementieren, die auf Worker-Knoten ausgeführt werden. CNI-Plug-ins konfigurieren Netzwerkschnittstellen, stellen IP-Adressen bereit und pflegen die Konnektivität.

Weitere Informationen finden Sie in der CNI-Dokumentation unter GitHub.

Eine Kubernetes-Manifestdatei enthält Anweisungen in einer YAML- oder JSON-Datei, mit denen angegeben wird, wie eine Anwendung auf dem bzw. den Knoten in einem Kubernetes-Cluster bereitgestellt werden soll. Die Anweisungen umfassen Informationen über das Deployment von Kubernetes, den Kubernetes-Service und andere Kubernetes-Objekte, die auf dem Cluster erstellt werden sollen. Das Manifest wird im Allgemeinen auch als "Pod Spec" oder als deployment.yaml-Datei bezeichnet (obwohl andere Dateinamen zulässig sind). Die Parameter, die in eine Kubernetes-Manifestdatei aufgenommen werden müssen, werden in der Kubernetes-Dokumentation beschrieben.

Ein Kubernetes-Zulassungscontroller fängt authentifizierte und autorisierte Anforderungen an den Kubernetes-API-Server ab, bevor ein Objekt (wie z.B. ein Pod) an das Cluster zugelassen wird. Ein Zulassungscontroller kann ein Objekt validieren und/oder ändern. Für viele erweiterte Features in Kubernetes ist ein aktivierter Zulassungscontroller erforderlich. Weitere Informationen hierzu finden Sie in der Kubernetes-Dokumentation.

Die Kubernetes-Version, die Sie beim Erstellen eines Clusters mit der Kubernetes-Engine auswählen, bestimmt die von diesem Cluster unterstützten Zulassungscontroller. Informationen zu den unterstützten Zulassungscontrollern, der Reihenfolge, in der sie auf dem Kubernetes-API-Server ausgeführt werden, und den Kubernetes-Versionen, in denen sie unterstützt werden, finden Sie unter Unterstützte Zulassungscontroller.

Ein Kubernetes-Cluster kann in Namespaces unterteilt werden, um die Ressourcen des Clusters zwischen mehreren Benutzern aufzuteilen. Anfänglich weist ein Cluster die folgenden Namespaces auf:

• "default" für Ressourcen ohne anderen Namespace
• "kube-system" für Ressourcen, die vom Kubernetes-System erstellt werden
• "kube-node-lease" für ein Leasingobjekt pro Knoten, um die Knotenverfügbarkeit zu bestimmen
• "kube-public" wird im Allgemeinen für Ressourcen verwendet, die im ganzen Cluster zugänglich sein müssen

Weitere Informationen zu Namespaces finden Sie in der Kubernetes-Dokumentation.