Wir erklären Ihnen, wie wir unseren Kubernetes Service aufgebaut haben.
Unser Kubernetes Service ist aufbauend auf der Talos-Linux-Distribution von Siderolabs. Generell kann man dies als "Vanilla Kubernetes" bezeichnen, wir haben jedoch für gewisse Komponenten eine Vorentscheidung getroffen, um es für Sie möglichst einfach zu gestallten.
Wir erläutern nachfolgend die wichtigsten Komponenten, verweisen jedoch für Details auf die offizielle Dokumentation.
Dieser Dienst befindet sich derzeit im Early Access. Kontaktieren Sie uns, um Zugang zu beantragen.
Die wichtigsten Kubernetes Komponenten
In der nachfolgenden grünen Textbox ist jeweils ein Beispiel der Komponente und ihrer Funktion.
Quelle: https://kubernetes.io/docs/concepts/overview/components/
Kube-API-Server
Der Kube-API-Server ist die zentrale Verwaltungsschnittstelle von Kubernetes, welche die Kommunikation zwischen allen Kubernetes-Komponenten koordiniert. Der Server verarbeitet API-Anfragen, führt Validierungen durch und stellt sicher, dass die gewünschten Zustände der Cluster-Ressourcen erreicht werden.
Eine oder ein Developer sendet eine Anfrage an den Kube-API-Server, um eine neue Web-Anwendung in Form eines Deployments zu erstellen. Der Kube-API-Server nimmt diese Anfrage entgegen, validiert sie und speichert die Konfiguration im ETCD.
ETCD
ETCD ist der konsistente Schlüssel-Wert-Speicher, der von Kubernetes zur Speicherung aller Clusterdaten verwendet wird. Er speichert den gesamten Cluster-Status, einschliesslich Konfigurationen, Geheimnisse und Informationen über den aktuellen Status von Pods und anderen Ressourcen.
ETCD speichert Informationen über das neue Deployment, einschliesslich der Anzahl der Replikate, Container-Images und Konfigurationen. Er fungiert als zentrale Datenbank für den aktuellen Zustand des Clusters.
Kube Scheduler
Der Kube Scheduler ist die Komponente von Kubernetes, die für die Zuweisung von Pods zu Knoten im Cluster verantwortlich ist. Er prüft die Anforderungen und Einschränkungen der Pods wie z.B. Ressourcenanforderungen und Affinitätsregeln und entscheidet dann, auf welchem Knoten die Pods am besten ausgeführt werden, um eine effiziente Ressourcennutzung und Lastverteilung zu gewährleisten.
Der Kube-Scheduler erkennt die neue Pod-Anfrage, die im ETCD gespeichert ist. Er bewertet die verfügbaren Knoten auf der Grundlage der Ressourcenanforderungen und der Affinitätsregeln des Pods und entscheidet, auf welchem Knoten der Pod platziert werden soll.
Kube-Controller-Manager
Der Kube-Controller-Manager ist eine zentrale Komponente von Kubernetes, die verschiedene Controller-Prozesse verwaltet und koordiniert. Diese Controller überwachen den Zustand des Clusters, reagieren auf Änderungen und sorgen dafür, dass die gewünschte Konfiguration der Cluster-Ressourcen erhalten bleibt, indem sie beispielsweise sicherstellen, dass die richtige Anzahl an Pods läuft oder die Nodes korrekt funktionieren.
Der Kube-Controller-Manager überwacht den Status der neuen Pods. Wenn ein Pod nicht ordnungsgemäss funktioniert oder ein Knoten ausfällt, startet der Controller neue Pods, um die gewünschte Anzahl an Replikaten sicherzustellen.
Kubelet
Der Kubelet ist der Agent, der auf jedem Knoten des Kubernetes Clusters läuft und für die Ausführung und Verwaltung der Pods auf diesem Knoten verantwortlich ist. Er kommuniziert mit dem kube-apiserver, um Podspezifikationen zu erhalten, startet Container über Container-Runtime-Engines wie Docker und überwacht kontinuierlich ihren Zustand, um sicherzustellen, dass sie korrekt ausgeführt werden.
Auf dem ausgewählten Knoten überwacht der Kubelet die eingehenden Pod-Definitionen vom kube-apiserver. Er startet die Container gemäss der Spezifikationen und überwacht ihren Zustand, um sicherzustellen, dass sie wie erwartet funktionieren.
Kube Proxy
Der Kube Proxy ist eine Netzwerkkomponente von Kubernetes, die auf jedem Knoten läuft und für die Netzwerkkommunikation zuständig ist. Er verwaltet die Netzwerkregeln und stellt sicher, dass Serviceanfragen korrekt an die entsprechenden Pods weitergeleitet werden, indem er die Lastverteilung und das Netzwerk-Routing zwischen den verschiedenen Komponenten des Clusters ermöglicht.
Der Kube-Proxy stellt sicher, dass Anfragen an den Webanwendungsdienst korrekt an die Pods weitergeleitet werden. Er verwaltet die Netzwerkregeln und sorgt für die Lastverteilung zwischen den verschiedenen Pods der Anwendung.
Container Runtime
Die Container Runtime ist die Software, die Container auf einem Knoten ausführt und verwaltet. Sie ist für das Erstellen, Ausführen, Beenden und Löschen von Containern verantwortlich und stellt sicher, dass Container gemäss den Spezifikationen im Kubernetes-Cluster ausgeführt werden.
Sie ist verantwortlich für das Erstellen, Ausführen, Beenden und Löschen von Containern und stellt sicher, dass Container gemäss den Spezifikationen im Kubernetes-Cluster ausgeführt werden.
Die von Xelon gewählten Distributionen der Komponenten
Nachfolgend finden Sie die Komponenten, die wir als Basis für unseren Kubernetes Service ausgewählt haben. Die nicht aufgeführten Komponenten sind Vanilla-Kubernetes-Komponenten. Unser Ziel ist es, einen möglichst standardisierten Kubernetes Service anzubieten, denn schliesslich ist die Standardisierung der Grund warum sich Kubernetes gegenüber Alternativen durchgesetzt hat.
Betriebssystem - Talos Linux
Das Betriebssystem selbst ist nicht direkt eine Kubernetes-Komponente, aber es ist die Basis für den Kubernetes Service. Für die Kubernetes Nodes setzen wir auf Talos Linux, ein minimales Betriebssystem, das speziell für den Betrieb von Kubernetes neu entwickelt wurde.
Viele Kubernetes-Knoten laufen unter Ubuntu, RHEL oder minimalen Container-Betriebssystemen wie "MicroOS" von SUSE oder "CoreOS" von Fedora/Redhat. Die meisten dieser Distributionen konzentrieren sich darauf, alle nicht benötigten Anwendungen zu entfernen.
Talos Linux von SideroLabs dreht den Spiess um: Es ist ein Linux-Kernel mit den minimal notwendigen Binaries, um Container betreiben zu können. Zudem ist die Systempartition unveränderlich und wird bei einem Upgrade durch eine neue ersetzt.
KubePrism
KubePrism ist ein simples Tool von SideroLabs, das die Verfügbarkeit von den Controlplanes im Cluster selbst erhöht. Im Grunde erstellt es ein Loadbalancer auf den Controlplane Nodes, der die Kube-API-Server Anfragen an einen gesunden Endpoint weiterleitet. Des weiteren werden die Anfragen an den KubeAPI Server mit der tiefsten Latenz gesendet. Für genauere Details verweisen wir Sie auf die offizielle Dokumentation.
Container Network Interface - Cilium
Als CNI (Container Network Interface) haben wir uns für Cilium entschieden, das derzeit noch keine standardmässige Installationsoption auf der Talos-Linux-Distribution ist, aber es gibt bereits eine Menge Dokumentation, welche die Installation vereinfacht. Wir haben uns aus zwei Hauptgründen für Cilium entschieden. Der erste ist die gute Performance, die Cilium bietet. Cilium benutzt ebpf, um Pakete zwischen den Knoten hin und her zu leiten, und das Tolle daran ist, dass ebpf im Vergleich zu traditionellen Tools wie iptables/nftables sehr wenig CPU- und Speicher-Ressourcen verbraucht. Der zweite Grund für Cilium ist die Überwachbarkeit. Mit Hubble und anderen integrierten Tools ist der Netzwerkverkehr zwischen Containern und Services nicht mehr nur schwarze Magie, sondern wieder übersichtlich und nachvollziehbar auch für Teamkolleginnen und kollegen, die den Cluster nicht selbst aufgesetzt haben.
Als Bonus-Tipp weisen wir darauf hin, dass im Cluster auch der Cilium Ingress (Envoy) vorinstalliert ist, der auch Layer 7 Traffic verständlich und transparent macht.
Xelon - Cloud Controller Manager
Der Kube Controller Manager ist eine Standardkomponente im Kubernetes Cluster, die mit der Komponente "CCM" (Cloud Controller Manager) erweitert werden kann. Wir haben hier eine eigene Erweiterung geschrieben, die im Cluster vorinstalliert ist. Diese ermöglicht das Erstellen von Services vom Typ Loadbalancer, was vereinfacht gesagt ein Public Endpoint ist, ohne dass ein Loadbalancer manuell konfiguriert werden muss.
Xelon - Container Storage Interface
Kubernetes wurde ursprünglich fast ausschliesslich für stateless Anwendungen verwendet, der Grund dafür war das "komplizierte" Speichermanagement. Sobald eine Anwendung auf mehreren Servern laufen kann, müssen alle Server Zugriff auf den gleichen Speicher haben. Das CSI (Container Storage Interface) ist eine Standardisierung für die Anbindung von Volumes an Container. Auch hier haben wir standardmässig unser eigenes Xelon-CSI im Cluster installiert.
Xelon Kubernetes Architektur
Nachfolgend sehen Sie, wie unser Service aufgebaut ist.
Gateway & Loadbalancer
Wir legen grossen Wert auf Sicherheit, daher befinden sich alle Kubernetes Nodes in einem LAN, welches durch die Loadbalancer vom Internet abgeschottet ist und gleichzeitig die Funktion einer Layer 3 Firewall übernimmt. Jeder Kubernetes Cluster verfügt über mindestens einen Loadbalancer (Primary Loadbalancer), der die Doppelfunktion als Gateway übernimmt.
Wenn der "Production"-Modus aktiv ist, wird nicht nur ein Loadbalancer erstellt, sondern zwei, die durch virtuelle IPs und HaProxy ausfallsicher gemacht werden.
Jeder Loadbalancer-Cluster (produktiv und nicht produktiv) benötigt ein dediziertes /29 WAN-Netzwerk. Nachfolgend ein Beispielnetzwerk mit den IPs und ihren Funktionen.
| Netzwerk: 45.131.171.40/29 | ||
| IP | Funktion | Beschreibung |
| 45.131.171.40 | Netzwerk ID | nicht nutzbar |
| 45.131.171.41 | Xelon WAN Upstream Gateway | nicht nutzbar |
| 45.131.171.42 | Dedizierte IP des primären Loadbalancers | Wird vom Loadbalancer als primäre IP genutzt. |
| 45.131.171.43 | Dedizierte IP des sekundären Loadbalancers (FailOver) | Wird vom zweiten Loadbalancer als primäre IP genutzt. |
| 45.131.171.44 |
#1 Virtuelle IP-Adresse |
Wird beim ersten Loadbalacer Cluster pro Kubernetes Cluster als Endpoint für die KubeAPI (6443), Talos API (50000) und Cilium Ingress Controller (80, 443) Verwendet. Bei jedem weiteren Loadbalancer Cluster ist diese auch als Loadbalancer IP verwendbar. |
| 45.131.171.45 | #2 Virtuelle IP-Adresse | Nutzbare IP-Adresse für Kubernetes Service vom Typ Loadbalancer |
| 45.131.171.46 | #3 Virtuelle IP-Adresse | Nutzbare IP-Adresse für Kubernetes Service vom Typ Loadbalancer |
| 45.131.171.47 | Broadcast-Adresse | nicht nutzbar |
Kubernetes Nodes
Unsere Kubernetes Nodes sind in zwei Typen unterteilt, Controlplane Nodes und Worker Nodes. Dies sind jedoch nur logische Unterteilungen zur besseren Übersicht und Skalierbarkeit.
Die Controlplane Nodes befinden sich immer im ersten Pool, dieser ist nur in zwei Grössen verfügbar: "produktiv" und "nicht produktiv". Im nicht produktiven Modus wird nur eine Controlplane bereitgestellt. Wenn diese neu gestartet wird oder nicht mehr verfügbar ist, ist die KUBE API nicht mehr funktionsfähig und Container / Workloads werden nicht neu erstellt und können nicht verwaltet werden, bis die Controlplane wieder verfügbar ist. Workloads, die bereits auf den Worker Nodes laufen, sind von einer solchen Unterbrechung nicht betroffen, sofern keine weiteren Abhängigkeiten bestehen. Das Skalieren vom nicht produktiven Modus in den produktiven Modus ist möglich, nicht jedoch in die entgegengesetzte Richtung. Im Produktivmodus wird der ETCD-Datenspeicher aktiv zwischen den Controlplane-Knoten synchronisiert. Dieser Modus erlaubt den Ausfall eines Controlplane-Nodes.
Worker Nodes können beliebig skaliert werden, das Verkleinern von Festplatten ist jedoch nicht möglich.
Node Pool
Wie bereits erwähnt verwenden wir das Prinzip der Node Pools, die ein logisches Modell für die Nodes in einem Pool darstellen. Das Ziel ist, dass alle Knoten in einem Pool die gleiche Anzahl an Ressourcen haben, was die Berechnung von Fehlertoleranzen vereinfacht.