Einführung in die Kubernetes-Architektur

• Die Kubernetes-Architektur basiert auf einem Control Plane/Workerknoten-Modell.
• Ein Kubernetes-Cluster sollte sicher, benutzerfreundlich und erweiterbar sein.
• Ein Cluster besteht aus 2 Teilen: der Control Plane, die globale Entscheidungen trifft, und den Nodes, auf denen Anwendungen ausgeführt werden.
• Standardmäßig bietet Kubernetes keine Methode, mit der Pods auf verschiedenen Nodes miteinander kommunizieren können, und auch keine Möglichkeit, den Internetverkehr innerhalb des Netzwerks weiterzuleiten oder Protokolle einfach anzuzeigen.
• Kubernetes bietet die Tools zur Orchestrierung einer großen und komplexen containerisierten Anwendung, überlässt Ihnen aber auch viele Entscheidungen.

Was ist Kubernetes-Architektur?

Die Kubernetes-Architektur basiert auf einem Control Plane/Workerknoten-Modell. Dabei wird ein Cluster in 2 primäre Schichten unterteilt: die Control Plane, die globale Entscheidungen trifft und den Cluster verwaltet, und die Workerknoten, die Ihre Anwendungen physisch in Containern ausführen.

Wenn Sie nur die Grundlagen von Kubernetes kennen, wissen Sie, dass es sich um eine Open Source-Plattform zur Container-Orchestrierung handelt, die für die Ausführung verteilter Anwendungen und Services in großem Umfang entwickelt wurde. Aber die einzelnen Komponenten und deren Interaktionen verstehen Sie möglicherweise nicht.

Im Folgenden werden die Designprinzipien von Kubernetes beleuchtet und anschließend veranschaulicht, wie die verschiedenen Komponenten von Kubernetes zusammenarbeiten.

Das Design eines Kubernetes-Clusters basiert auf 3 Prinzipien, die in den Details zur Kubernetes-Implementierung erläutert werden.

Ein Kubernetes-Cluster sollte folgende Eigenschaften besitzen:

• Sicher: Er sollte den neuesten Best Practices für die Sicherheit entsprechen.
• Benutzerfreundlich: Er sollte mit wenigen einfachen Befehlen zu verwenden sein.
• Erweiterbar: Er sollte keinen Anbieter bevorzugen und über eine Konfigurationsdatei angepasst werden können.

Ein funktionierendes Kubernetes-Deployment wird als Cluster bezeichnet. Ein Kubernetes-Cluster besteht aus 2 Teilen: der Control Plane und den Rechenmaschinen oder Nodes. Ein einzelner Node ist eine eigene Linux®-Umgebung und kann entweder eine physische oder eine virtuelle Maschine sein. Auf den Nodes werden Pods ausgeführt, die aus Containern bestehen.

Dieses Diagramm zeigt, wie die Teile eines Kubernetes-Clusters zusammenhängen:

Die Kubernetes Control Plane ist das „Gehirn“ Ihres Clusters. Sie trifft globale Entscheidungen – wie die Planung von Anwendungen – und erkennt Cluster-Events, auf die sie reagiert. Außerdem stellt sie sicher, dass der aktuelle Zustand Ihres Clusters dem gewünschten Zustand entspricht, den Sie angegeben haben.

In der Kubernetes Control Plane befinden sich auch die Komponenten zur Steuerung des Cluster sowie Daten zu seinem Status und seiner Konfiguration. Die Kernkomponenten von Kubernetes übernehmen die wichtige Aufgabe, sicherzustellen, dass Ihre Container in ausreichender Anzahl und mit den erforderlichen Ressourcen ausgeführt werden. 

Die Control Plane steht in ständigem Kontakt mit Ihren Rechenmaschinen. Sie haben Ihren Cluster so konfiguriert, dass er auf eine bestimmte Weise ausgeführt wird. Die Control Plane stellt sicher, dass dies auch so geschieht.

kube-apiserver

Die Kubernetes-API ist das Frontend der Kubernetes Control Plane und verarbeitet interne und externe Anfragen. Der API-Server ermittelt, ob eine Anfrage gültig ist, und verarbeitet sie dann. Sie können die API über REST-Aufrufe, über die Befehlszeile „kubectl“ oder über andere Befehlszeilentools wie „kubeadm“ aufrufen.

kube-scheduler

Der Scheduler berücksichtigt den Ressourcenbedarf eines Pods, etwa die CPU oder den Arbeitsspeicher, sowie den Zustand des Clusters. Anschließend wird der Pod für einen geeigneten Compute Node geplant.

kube-controller-manager

Controller sorgen dafür, dass der Cluster tatsächlich ausgeführt wird, und der Kubernetes Controller-Manager enthält mehrere ineinander verschachtelte Controller-Funktionen. Ein Controller befragt den Scheduler und stellt sicher, dass die richtige Anzahl von Pods ausgeführt wird. Wenn ein Pod ausfällt, springt ein anderer Controller ein. Ein Controller verbindet Services mit Pods, damit Anfragen an die richtigen Endgeräte gelangen. Außerdem gibt es Controller zur Erstellung von Accounts und API-Zugriffs-Tokens.

etcd

Konfigurationsdaten und Informationen zum Status des Clusters befinden sich in etcd, einer Speicherdatenbank für Schlüsselwerte. Etcd ist fehlertolerant, dezentralisiert und bildet die „Ultimate Source of Truth“ für Ihren Cluster.

Die Control Plane ist das Gehirn und die Kubernetes-Workerknoten sind der Muskel, denn sie übernehmen die eigentliche Schwerstarbeit beim Ausführen Ihrer Anwendungen.

Ein Kubernetes-Node kann ein physische Maschine oder eine virtuelle Maschine (VM) sein. Die Abläufe in einem Node sind ein kontinuierlicher Zyklus: Es werden Anweisungen von der Control Plane empfangen, Container ausgeführt, das Netzwerk wird verwaltet und der Integritätsstatus zurückgemeldet.

Ein Kubernetes-Cluster benötigt mindestens einen Compute Node, hat jedoch normalerweise viele. Pods werden zur Ausführung auf Nodes geplant und orchestriert. Sie müssen die Kapazität Ihres Clusters vertikal skalieren? Fügen Sie einfach weitere Nodes hinzu.

Pods

Ein Pod ist die kleinste und einfachste Einheit im Kubernetes-Objektmodell. Er stellt eine einzelne Instanz einer Anwendung dar. Ein Pod besteht aus einem Container oder einer Reihe eng gekoppelter Container sowie den Optionen, mit denen die Ausführung der Container gesteuert wird. Pods können mit persistentem Storage verbunden werden, um zustandsbehaftete Anwendungen auszuführen.

Container Runtime Engine

Zur Ausführung der Container verfügt jeder Node über eine Container Runtime Engine. Docker ist nur ein Beispiel, aber Kubernetes unterstützt auch andere Runtimes, die mit der Open Container Initiative kompatibel sind, wie etwa rkt und CRI-O.

Kubelet

Jeder Node enthält ein Kubelet, eine winzige Anwendung, die mit der Control Plane kommuniziert. Das Kubelet stellt sicher, dass die Container in einem Pod ausgeführt werden. Wenn die Control Plane einen Vorgang in einem Node benötigt, führt das Kubelet die Aktion aus.

kube-proxy

Jeder Node enthält auch „kube-proxy“, einen Netzwerk-Proxy für die Kubernetes-Netzwerkservices. Kube-proxy verwaltet die Netzwerkkommunikation innerhalb oder außerhalb Ihres Clusters. Dabei wird entweder die Paketfilterschicht Ihres Betriebssystems verwendet oder der Datenverkehr selbst weitergeleitet.

Sobald Sie die Control Plane und die Workerknoten haben, haben Sie technisch gesehen einen Kubernetes-Cluster. Allerdings ist er sozusagen komplett nackt. Standardmäßig bietet Kubernetes keine Methode, mit der Pods auf verschiedenen Nodes miteinander kommunizieren können, und auch keine Möglichkeit, den Internetverkehr innerhalb des Netzwerks weiterzuleiten oder Protokolle einfach anzuzeigen.

Um einen Cluster produktionsfähig zu machen, müssen Sie Add-Ons und die unterstützende Infrastruktur installieren.

1. Netzwerk: Kubernetes erfordert ein virtuelles Netzwerk-Overlay, damit Pods nahtlos über verschiedene Nodes hinweg kommunizieren können. Ein CNI-Plugin (Container Network Interface) wie Cilium oder Calico muss installiert sein, um diese Netzwerkschicht zu erstellen und den einzelnen Pods eindeutige IP-Adressen zuzuweisen.
2. Ingress Controller: Der interne Datenverkehr wird automatisch abgewickelt, für den externen Datenverkehr benötigen Sie jedoch ein Gateway. Ein Ingress Controller wie NGINX oder Traefik fungiert als Reverse-Proxy und Load Balancer, der den externen Internetdatenverkehr sicher an die richtigen Services in Ihrem Cluster weiterleitet.
3. Cluster-DNS: Da Pods die IP-Adressen bei einem Neustart ständig ändern, können Sie Netzwerkpfade nicht hartcodieren. Ein Cluster-DNS-Anbieter (in der Regel CoreDNS) ordnet Ihren Services automatisch permanente Domain-Namen zu und stellt so sicher, dass Ihre Anwendungen sich stets gegenseitig finden können.
4. Storage-Provisioner: Container sind von Natur aus zustandslos. Die darin gespeicherten Daten werden also bei einem Absturz gelöscht. Ein CSI (Container Storage Interface) verbindet Ihren Cluster mit externem physischen Speicher (wie NFS oder einer Cloud-Disk) und übernimmt automatisch die Provisionierung und den Anschluss permanenter Festplatten, damit Ihre Daten nach einem Neustart weiterhin verfügbar sind.
5. Beobachtbarkeits-Stack: Bei Anwendungen, die auf mehrere Rechner verteilt sind, erfordert die Fehlerbehebung zentralisierte Einblicke. Tools wie Prometheus und Grafana überwachen Cluster-Metriken, während Protokollierungs-Agenten wie FluentBit Container-Protokolle in einem einzigen, durchsuchbaren Dashboard zusammenfassen.

Dieser vereinfachte Überblick über die Kubernetes-Architektur kratzt nur an der Oberfläche. Wenn Sie bedenken, wie diese Komponenten miteinander und mit externen Ressourcen und Infrastrukturen kommunizieren, werden Sie sich der Herausforderungen bewusst, die mit der Konfiguration und Sicherung eines Kubernetes-Clusters einhergehen.

Kubernetes bietet die Tools zur Orchestrierung einer großen und komplexen containerisierten Anwendung, überlässt Ihnen aber auch viele Entscheidungen. Sie wählen das Betriebssystem, die Container Runtime, CI/CD-Tools (Continuous Integration/Continuous Delivery), Anwendungsservices, den Storage und die meisten anderen Komponenten aus. Auch Punkte wie Rollenmanagement, Zugriffskontrolle, Mandantenfähigkeit und sichere Standardeinstellungen sind zu bedenken. Darüber hinaus können Sie Kubernetes selbst ausführen oder mit einem Anbieter zusammenarbeiten, der eine unterstützte Version bereitstellt.

Diese Entscheidungsfreiheit ist Teil des flexiblen Charakters von Kubernetes. Die Implementierung von Kubernetes kann komplex sein, aber Kubernetes bietet Ihnen auch enorme Möglichkeiten, containerisierte Anwendungen nach Ihren eigenen Vorstellungen auszuführen und flexibel auf Veränderungen in Ihrem Unternehmen zu reagieren.

Entwickeln cloudnativer Anwendungen mit Kubernetes

In dieser Webinar-Reihe erhalten Sie Einblick in die Perspektiven von Expertinnen und Experten, die Sie beim Einrichten der Datenplattform auf Kubernetes für Unternehmen unterstützen, die Sie zum Entwickeln, Ausführen, Bereitstellen und Modernisieren von Anwendungen benötigen. 

On-Demand ansehen

Red Hat ist ein führender und aktiver Entwickler von Open Source-Container-Technologien (darunter auch Kubernetes) und entwickelt wichtige Tools zum Sichern, Vereinfachen und automatischen Aktualisieren Ihrer Container-Infrastruktur. 

Red Hat® OpenShift® ist eine unternehmensfähige Kubernetes-Distribution. Mit Red Hat OpenShift erhalten Teams eine einzelne, integrierte Plattform für DevOps. Red Hat OpenShift bietet Entwicklungsteams eine große Auswahl an Sprachen, Frameworks, Middleware und Datenbanken sowie die Möglichkeit der Automatisierung von Entwicklung und Deployment durch CI/CD, wodurch die Produktivität weiter verbessert wird. Red Hat OpenShift Data Foundation ist eine für Container entwickelte Daten- und Storage-Serviceplattform.

Mehr erfahren