Nicht-VRF- oder VRF-aktiviertes Konto nur mit Public-Cloud-Serviceendpunkt

Die folgende Abbildung zeigt die Komponenten Ihres Clusters und ihre Interaktion in einem nicht-VRF- oder VRF-aktivierten Konto, wenn nur der Public-Cloud-Serviceendpunkt aktiviert ist.

VRF-aktiviertes Konto mit Private- und Public-Cloud-Serviceendpunkten

Die folgende Abbildung zeigt die Komponenten Ihres Clusters und die Art und Weise ihrer Interaktion in einem VRF-aktivierten Konto, wenn der Public- und der Private-Cloud-Serviceendpunkt aktiviert sind.

Kubernetes-Masterkomponenten

Der Kubernetes-Master ist mit der Verwaltung aller Datenverarbeitungs-, Netz- und Speicherressourcen im Cluster betraut und stellt sicher, dass Ihre containerisierten Apps und Services gleichmäßig auf den Workerknoten im Cluster bereitgestellt werden. Abhängig davon, wie Sie Ihre App und Services konfigurieren, bestimmt der Master den Workerknoten, der über ausreichend Ressourcen verfügt, um die Anforderungen einer App zu erfüllen.

Der Kubernetes-Master und alle Masterkomponenten sind nur Ihnen vorbehalten und werden nicht mit anderen IBM Kunden gemeinsam genutzt.

In der folgenden Tabelle werden die Komponenten des Kubernetes-Masters beschrieben.

kube-apiserver

Der Kubernetes-API-Server dient als Haupteinstiegspunkt für alle Anforderungen der Clusterverwaltung vom Workerknoten zum Kubernetes-Master. Der Kubernetes-API-Server validiert und verarbeitet Anforderungen, die den Status von Kubernetes-Ressourcen (z. B. Pods oder Services) ändern, und speichert diesen Status in 'etcd'.

konnectivity-server

Der Konnectivity-Server arbeitet mit dem Konnectivity-Agenten zusammen, um den Master sicher mit dem Worker-Knoten zu verbinden. Diese Verbindung unterstützt apiserver proxy-Aufrufe für Ihre Pods und Services sowie kubectl exec-, attach- und logs-Aufrufe für 'kubelet'.

etcd

etcd ist ein hoch verfügbarer Schlüsselwertspeicher, in dem der Status aller Kubernetes-Ressourcen eines Clusters gespeichert ist, z. B. von Services, Bereitstellungen und Pods. Daten in 'etcd' werden in einer verschlüsselten Speicherinstanz gesichert, die von IBM verwaltet wird.

kube-scheduler

Der Kubernetes-Scheduler überwacht neu erstellte Pods und entscheidet, wo sie auf der Basis von Kapazität, Leistungsbedarf, Richtlinienvorgaben, Anti-Affinität-Spezifikationen und Workloadanforderungen bereitgestellt werden. Wird kein Workerknoten gefunden, der mit den Anforderungen übereinstimmt, so wird der Pod nicht im Cluster bereitgestellt.

kube-controller-manager

Der Kubernetes-Controller-Manager ist ein Dämonprozess, der den Zustand von Clusterressourcen wie z. B. Replikatgruppen überwacht. Wenn sich der Zustand einer Ressource ändert, z. B. wenn ein Pod in einer Replikatgruppe inaktiv wird, leitet der Controller-Manager Korrekturmaßnahmen ein, um den erforderlichen Zustand zu erreichen.

Workerknotenkomponenten

Jeder Workerknoten ist eine physische Maschine (Bare-Metal) oder eine virtuelle Maschine, die auf physischer Hardware in der Cloudumgebung ausgeführt wird. Wenn Sie einen Workerknoten bereitstellen, legen Sie die Ressourcen fest, die den auf diesem Workerknoten gehosteten Containern zur Verfügung stehen. Die Worker-Knoten werden mit einer von IBM verwalteten Container-Laufzeitumgebung, separaten Rechenressourcen, Netzwerkfunktionen und einem Volume-Dienst eingerichtet. Die integrierten Sicherheitsfeatures stellen die Isolation, die Funktionalität für die Verwaltung von Ressourcen und die Einhaltung der Sicherheitsbestimmungen für die Workerknoten sicher.

Die Workerknoten und alle Workerknotenkomponenten sind nur Ihnen vorbehalten und werden nicht mit anderen IBM Kunden gemeinsam genutzt. Wenn Sie jedoch eine virtuelle Maschine mit Workerknoten verwenden, wird die zugrunde liegende Hardware möglicherweise mit anderen Kunden gemeinsam genutzt, abhängig vom Grad der Hardware-Isolation, den Sie auswählen.

Das Ändern von Standardkomponenten für Workerknoten wie kubelet wird nicht unterstützt und kann zu nicht erwarteten Ergebnissen führen.

In den folgenden Tabellen werden die Komponenten eines Workerknotens beschrieben.

kube-system-Namensbereich

ibm-master-proxy

ibm-master-proxy leitet Anforderungen vom Workerknoten an die IP-Adressen der hoch verfügbaren Master-Replikate weiter. In Einzelzonenclustern verfügt der Master über drei Replikate auf separaten Hosts mit einer Master-IP-Adresse und einem Domänennamen. Für Cluster in einer mehrzonenfähigen Zone verfügt der Master über drei Replikate, die über Zonen verteilt sind. Jeder Master hat hier seine eigene IP-Adresse, die bei DNS registriert ist, und einen Domänennamen für den gesamten Cluster-Master.

konnectivity-agent

Der Konnectivity-Agent arbeitet mit dem Konnectivity-Server zusammen, um den Master sicher mit dem Worker-Knoten zu verbinden. Diese Verbindung unterstützt apiserver proxy-Aufrufe für Ihre Pods und Services sowie kubectl exec-, attach- und logs-Aufrufe für 'kubelet'.

kubelet

Das 'kubelet' ist ein Pod, der auf allen Workerknoten ausgeführt wird und der für die Überwachung des Zustands der Pods verantwortlich ist, die auf dem Workerknoten aktiv sind, und für die Überwachung der Ereignisse, die der Kubernetes-API-Server sendet. Das 'kubelet' erstellt oder entfernt auf der Basis der Ereignisse Pods, stellt Aktivitäts- und Bereitschaftsprüfungen sicher und meldet dem Kubernetes-API-Server den Zustand der Pods.

coredns

Kubernetes plant standardmäßig einen CoreDNS-Pod und -Service (bzw. KubeDNS-Pod in Version 1.12 und früher) auf dem Cluster. Container verwenden automatisch die IP des DNS-Service, um DNS-Namen bei der Suche nach weiteren Pods und Services aufzulösen.

calico

Calico verwaltet die Netzrichtlinien für Ihren Cluster und besteht aus den folgenden Komponenten.

calico-cni: Die Containernetzschnittstelle Calico Container Network Interface (CNI) verwaltet die Netzkonnektivität von Containern und entfernt zugeordnete Ressourcen, sobald ein Container gelöscht wird.

calico-ipam: Die Komponente Calico-IPAM verwaltet die Zuweisung von IP-Adressen für Container.

calico-node: Der Calico-Knoten ist ein Container, der die verschiedenen Komponenten bündelt, die für den Netzbetrieb von Containern mit Calico erforderlich sind.

calico-policy-controller: Der Calico-Richtliniencontroller überwacht die Einhaltung der festgelegten Netzrichtlinien für den eingehenden und ausgehenden Netzdatenverkehr. Wenn der Datenverkehr im Cluster nicht zulässig ist, wird der Zugriff auf den Cluster blockiert. Der Richtliniencontroller von Calico wird auch verwendet, um Netzrichtlinien für einen Cluster zu erstellen und festzulegen.

kube-proxy

Der Kubernetes-Netzproxy ist ein Dämonprozess, der auf allen Workerknoten ausgeführt wird und der TCP- und UDP-Netzverkehr für im Cluster ausgeführte Services weiterleitet oder deren Last verteilt.

kube-dashboard

Das Kubernetes-Dashboard ist eine webbasierte Benutzerschnittstelle, die es Benutzern ermöglicht, den Cluster und die Anwendungen, die im Cluster ausgeführt werden, zu verwalten und auftretende Fehler zu beheben.

heapster

Heapster ist ein clusterweiter Aggregator von Überwachungs- und Ereignisdaten. Der Heapster-Pod erkennt alle Knoten im Cluster und fragt bei den Kubelets der einzelnen Knoten die Nutzungsinformationen ab. Sie finden Nutzungsdiagramme im Kubernetes-Dashboard.

Ingress-ALB

Ingress ist ein Kubernetes Service, den Sie verwenden können, um Netzverkehrworkloads in Ihrem Cluster auszugleichen, indem Sie öffentliche oder private Anforderungen an mehrere Apps in Ihrem Cluster weiterleiten. Um Ihre Apps über das öffentliche oder private Netz zugänglich zu machen, müssen Sie eine Ingress-Ressource erstellen, um Ihre Apps für die Ingress-ALB (ALB – Application Load Balancer, Lastausgleichsfunktion für Anwendungen) zu registrieren. Es kann dann mithilfe einer einzigen URL- oder IP-Adresse auf mehrere Apps zugegriffen werden.

Speicherprovider

Jeder Cluster ist mit einem Plug-in für die Bereitstellung von Dateispeicher konfiguriert. Sie können auswählen, weitere Add-ons zu installieren, wie z. B. Blockspeicher.

ibm-system-Namensbereich

Protokollierung und Metriken

Sie können die IBM Cloud Logs- und IBM Cloud® Monitoring-Services verwenden, um Ihre Sammlung und Aufbewahrungskapazitäten bei der Arbeit mit Protokollen und Metriken zu erweitern. Lastausgleichsfunktion

Eine Lastausgleichsfunktion ist ein Kubernetes Service, der verwendet werden kann, um Netzverkehrworkloads in Ihrem Cluster auszugleichen, indem öffentliche oder private Anforderungen an eine App weitergeleitet werden.

default-Namensbereich

App-Pods und -Services

Im Namensbereich default oder in den Namensbereichen, die Sie erstellen, können Sie Apps in Pods und Services bereitstellen, um mit diesen Pods zu kommunizieren.