Kubernetes in Action

1. Kubernetes orchestriert Container, nicht nur Docker

Kubernetes ist ein System zur Orchestrierung von Containern, das speziell für Docker-basierte Container entwickelt wurde.

Über Docker hinaus. Während Docker eine beliebte Containerplattform ist, wurde Kubernetes so konzipiert, dass es unabhängig von der Container-Laufzeit funktioniert. Es kann Container orchestrieren, die mit Docker, rkt oder anderen Container-Laufzeiten erstellt wurden, die die Container Runtime Interface (CRI) implementieren. Diese Flexibilität ermöglicht die Nutzung einer breiteren Palette von Containertechnologien innerhalb einer Kubernetes-Umgebung.

• Kubernetes nutzt Linux-Containertechnologien zur Isolation.
• Docker ist eine Plattform zum Verpacken, Verteilen und Ausführen von Anwendungen.
• rkt ist eine weitere Linux-Container-Engine, die Sicherheit und offene Standards betont.

Abstraktion ist der Schlüssel. Kubernetes abstrahiert die zugrunde liegende Containertechnologie, sodass Entwickler sich auf die Bereitstellung und Verwaltung von Anwendungen konzentrieren können, anstatt sich mit den Einzelheiten der Container-Laufzeit zu befassen. Diese Abstraktion ist entscheidend für Portabilität und Interoperabilität in verschiedenen Umgebungen.

• Kubernetes stellt das gesamte Rechenzentrum als eine einzige Bereitstellungsplattform dar.
• Entwickler können Anwendungen über Kubernetes bereitstellen, ohne Unterstützung von Systemadministratoren zu benötigen.
• Systemadministratoren können besser schlafen, da Kubernetes automatisch mit ausgefallenen Knoten umgeht.

Fokus auf Orchestrierung. Die Hauptaufgabe von Kubernetes besteht darin, Container zu orchestrieren, nicht selbst eine Container-Laufzeit zu sein. Es bietet die Werkzeuge und Mechanismen zur Bereitstellung, Skalierung und Verwaltung containerisierter Anwendungen, unabhängig von der zugrunde liegenden Containertechnologie. Dieser Fokus auf Orchestrierung macht Kubernetes zu einer leistungsstarken Plattform für die moderne Anwendungsentwicklung.

2. Pods: Die atomare Einheit von Kubernetes

Ein Pod ist eine Gruppe von einem oder mehreren eng verwandten Containern, die immer zusammen auf demselben Arbeitsknoten und in denselben Linux-Namespace(n) ausgeführt werden.

Pods als logische Hosts. Pods sind die grundlegenden Bausteine in Kubernetes und repräsentieren eine Gruppe von einem oder mehreren Containern, die Ressourcen teilen und immer auf demselben Knoten lokalisiert sind. Sie bieten eine logische Host-ähnliche Umgebung für Anwendungen, die es Containern ermöglicht, zu kommunizieren und Daten so zu teilen, als ob sie auf derselben Maschine ausgeführt würden.

• Pods sind wie separate logische Maschinen mit eigener IP, Hostname, Prozessen usw.
• Pods sind die grundlegende Einheit der Skalierung.
• Pods sind flüchtig.

Container innerhalb von Pods. Container innerhalb eines Pods teilen sich dasselbe Netzwerk und UTS-Namespace, was ihnen ermöglicht, über localhost zu kommunizieren und denselben Hostnamen zu sehen. Sie können auch Dateien über Volumes teilen. Diese Co-Lokalisierung und Ressourcenteilung machen Pods ideal für die Ausführung eng gekoppelt Anwendungen.

• Container in einem Pod teilen sich dieselbe IP-Adresse und Port-Raum.
• Container in einem Pod können über IPC kommunizieren.
• Container in einem Pod können Dateien über Volumes teilen.

Organisation von Containern. Container sollten basierend auf ihren Abhängigkeiten und Skalierungsanforderungen in Pods gruppiert werden. Eng gekoppelte Prozesse, die zusammen ausgeführt werden müssen, sollten im selben Pod platziert werden, während unabhängige Komponenten in separaten Pods bereitgestellt werden sollten. Dieser Ansatz ermöglicht eine bessere Ressourcennutzung und flexiblere Skalierung.

• Ein Container sollte nicht mehrere Prozesse ausführen.
• Ein Pod sollte keine mehreren Container enthalten, wenn sie nicht auf derselben Maschine ausgeführt werden müssen.

3. Controller: Sicherstellung der Anwendungsintegrität und -skalierung

Kubernetes hält Anwendungen gesund, indem es Container automatisch neu startet.

Controller als Aufpasser. Kubernetes-Controller sind aktive Komponenten, die kontinuierlich den Zustand des Clusters überwachen und Maßnahmen ergreifen, um den tatsächlichen Zustand mit dem gewünschten Zustand in Einklang zu bringen. Sie beobachten Änderungen an Ressourcen und führen Operationen durch, um sicherzustellen, dass das System immer wie gewünscht läuft.

• Controller überwachen den API-Server auf Änderungen an Ressourcen.
• Controller führen Operationen durch, um den tatsächlichen Zustand mit dem gewünschten Zustand in Einklang zu bringen.
• Controller kommunizieren nicht direkt miteinander.

ReplicationControllers und ReplicaSets. Diese Controller stellen sicher, dass eine bestimmte Anzahl von Pod-Replikaten immer läuft. Sie starten Container, die abstürzen, automatisch neu und planen Pods neu, wenn ein Knoten ausfällt. ReplicaSets sind die neuere Version der ReplicationControllers und bieten ausdrucksstärkere Label-Selektoren.

• ReplicationControllers halten Anwendungen gesund, indem sie Container automatisch neu starten.
• ReplicaSets sind die neuere Version der ReplicationControllers.
• ReplicaSets verwenden ausdrucksstärkere Label-Selektoren.

DaemonSets und Jobs. DaemonSets stellen sicher, dass ein Pod auf jedem Knoten im Cluster ausgeführt wird, während Jobs Pods ausführen, die eine einmalige, abschließbare Aufgabe erledigen. Diese Controller bieten verschiedene Möglichkeiten zur Verwaltung von Pods basierend auf spezifischen Anwendungsfällen.

• DaemonSets führen einen Pod auf jedem Knoten aus.
• Jobs führen Pods aus, die eine einmalige, abschließbare Aufgabe erledigen.
• CronJobs führen Jobs regelmäßig oder einmal in der Zukunft aus.

4. Services: Ermöglichung von Kommunikation und Entdeckung

Services repräsentieren einen statischen Standort für eine Gruppe von einem oder mehreren Pods, die alle denselben Service bereitstellen.

Services als stabile Endpunkte. Kubernetes-Services bieten eine stabile IP-Adresse und einen Port, über die Clients auf eine Gruppe von Pods zugreifen können. Diese Abstraktion ermöglicht es, Pods im Cluster zu verschieben, ohne die Konnektivität der Clients zu beeinträchtigen.

• Services bieten eine einzige statische IP-Adresse und einen Port für eine Gruppe von Pods.
• Services ermöglichen es Clients, Pods zu entdecken und darauf zuzugreifen.
• Services balancieren Verbindungen über mehrere Pods.

Service-Typen. Kubernetes unterstützt verschiedene Arten von Services, darunter ClusterIP (für internen Zugriff), NodePort (für externen Zugriff über Knotenports) und LoadBalancer (für externen Zugriff über einen Cloud-Load-Balancer). Jeder Typ bietet unterschiedliche Möglichkeiten, Services für Clients bereitzustellen.

• ClusterIP-Services sind nur von innerhalb des Clusters zugänglich.
• NodePort-Services sind über einen Port auf allen Knoten zugänglich.
• LoadBalancer-Services sind über einen externen Load-Balancer zugänglich.

Service-Entdeckung. Pods können Services über Umgebungsvariablen oder DNS entdecken. Dies ermöglicht es Anwendungen, andere Services zu finden und sich mit ihnen zu verbinden, ohne deren spezifische IP-Adressen oder Standorte zu kennen.

• Services sind über Umgebungsvariablen entdeckbar.
• Services sind über DNS entdeckbar.
• Services können über ihren FQDN (Fully Qualified Domain Name) aufgerufen werden.

5. Volumes: Verwaltung der Datenpersistenz

Volumes werden verwendet, um Daten zwischen Containern zu teilen.

Volumes als gemeinsamer Speicher. Kubernetes-Volumes bieten eine Möglichkeit für Container innerhalb eines Pods, Daten zu teilen und auf persistente Speicher zuzugreifen. Sie werden als Teil der Pod-Spezifikation definiert und haben denselben Lebenszyklus wie der Pod.

• Volumes werden verwendet, um Daten zwischen Containern zu teilen.
• Volumes werden verwendet, um auf persistente Speicher zuzugreifen.
• Volumes sind an den Lebenszyklus eines Pods gebunden.

Volume-Typen. Kubernetes unterstützt verschiedene Volume-Typen, darunter emptyDir (für temporären Speicher), hostPath (für den Zugriff auf Dateien auf dem Knoten), gitRepo (zum Klonen eines Git-Repositorys) und persistente Volumes (für den Zugriff auf persistenten Speicher). Jeder Typ dient einem anderen Zweck und bietet unterschiedliche Ebenen der Datenpersistenz.

• emptyDir-Volumes werden für temporären Speicher verwendet.
• hostPath-Volumes werden verwendet, um auf Dateien auf dem Knoten zuzugreifen.
• gitRepo-Volumes werden verwendet, um ein Git-Repository zu klonen.
• Persistente Volumes werden verwendet, um auf persistenten Speicher zuzugreifen.

Persistenter Speicher. Persistente Volumes (PVs) und PersistentVolumeClaims (PVCs) entkoppeln Pods von der zugrunde liegenden Speichertechnologie, sodass Entwickler Speicher anfordern können, ohne die Einzelheiten der Infrastruktur zu kennen. Diese Abstraktion macht Anwendungen portabler und einfacher zu verwalten.

• PersistentVolumes werden von Cluster-Administratoren bereitgestellt.
• PersistentVolumeClaims werden von Pods verwendet, um Speicher anzufordern.
• PersistentVolumes und PersistentVolumeClaims entkoppeln Pods von der zugrunde liegenden Speichertechnologie.

6. ConfigMaps und Secrets: Externe Konfiguration

ConfigMaps und Secrets werden verwendet, um Konfigurationsdaten und sensible Informationen wie Anmeldeinformationen an Anwendungen zu übergeben, die in Pods ausgeführt werden.

ConfigMaps für nicht-sensible Daten. ConfigMaps werden verwendet, um nicht-sensible Konfigurationsdaten wie Anwendungseinstellungen, Umgebungsvariablen und Befehlszeilenargumente zu speichern. Sie ermöglichen es, die Konfiguration vom Anwendungscode zu entkoppeln, was die Verwaltung und Aktualisierung erleichtert.

• ConfigMaps werden verwendet, um nicht-sensible Konfigurationsdaten zu speichern.
• ConfigMaps werden verwendet, um Befehlszeilenargumente an Container zu übergeben.
• ConfigMaps werden verwendet, um Umgebungsvariablen für Container festzulegen.

Secrets für sensible Daten. Secrets werden verwendet, um sensible Informationen wie Passwörter, API-Schlüssel und Zertifikate zu speichern. Sie werden sicher gespeichert und können in Pods als Volumes eingebunden oder als Umgebungsvariablen bereitgestellt werden.

• Secrets werden verwendet, um sensible Daten zu speichern.
• Secrets werden sicher gespeichert.
• Secrets können in Pods als Volumes eingebunden werden.

Entkopplung der Konfiguration. Durch die Verwendung von ConfigMaps und Secrets können Sie die Konfiguration vom Anwendungscode und den Container-Images entkoppeln, was die Verwaltung und Aktualisierung Ihrer Anwendungen erleichtert. Diese Trennung der Anliegen ist entscheidend für den Aufbau wartbarer und skalierbarer Systeme.

• ConfigMaps und Secrets entkoppeln die Konfiguration vom Anwendungscode.
• ConfigMaps und Secrets erleichtern die Verwaltung und Aktualisierung von Anwendungen.
• ConfigMaps und Secrets machen Anwendungen portabler.

7. Kubernetes sichern: Authentifizierung, Autorisierung und Netzwerk-Richtlinien

Kubernetes ermöglicht es Ihnen, Ihren Kubernetes-API-Server und damit den Cluster mithilfe von Authentifizierung und Autorisierung zu sichern.

Authentifizierung. Kubernetes verwendet Authentifizierungs-Plugins, um die Identität von Clients zu überprüfen, die sich mit dem API-Server verbinden. Diese Plugins können verschiedene Methoden verwenden, wie z. B. Client-Zertifikate, Authentifizierungstoken oder grundlegende HTTP-Authentifizierung.

• Authentifizierungs-Plugins überprüfen die Identität von Clients.
• Authentifizierungs-Plugins geben den Benutzernamen und die Gruppen des authentifizierten Benutzers zurück.
• ServiceAccounts werden verwendet, um Pods zu authentifizieren.

Autorisierung. Sobald ein Client authentifiziert ist, verwendet der API-Server Autorisierungs-Plugins, um zu bestimmen, ob der Client die angeforderte Aktion auf der angeforderten Ressource ausführen darf. Das RBAC (Role-Based Access Control)-Plugin ist das Standard-Autorisierungs-Plugin in Kubernetes.

• Autorisierungs-Plugins bestimmen, ob ein Client eine Aktion ausführen darf.
• RBAC ist das Standard-Autorisierungs-Plugin in Kubernetes.
• RBAC verwendet Rollen und RoleBindings, um Berechtigungen zu gewähren.

Netzwerk-Richtlinien. Netzwerk-Richtlinien ermöglichen es Ihnen, den Netzwerkverkehr zwischen Pods zu steuern und einzuschränken, welche Pods miteinander kommunizieren können. Dies hilft, Anwendungen zu isolieren und unbefugten Zugriff zu verhindern.

• Netzwerk-Richtlinien beschränken den Netzwerkverkehr zwischen Pods.
• Netzwerk-Richtlinien verwenden Pod-Selektoren und Namespace-Selektoren.
• Netzwerk-Richtlinien verwenden Eingangs- und Ausgangsregeln.

8. Ressourcenmanagement: Anfragen, Limits und QoS

Kubernetes kann so konfiguriert werden, dass die Anzahl der laufenden Replikate Ihrer Anwendung automatisch skaliert wird.

Ressourcenanfragen. Ressourcenanfragen geben die minimale Menge an CPU und Speicher an, die ein Container benötigt, um ordnungsgemäß zu funktionieren. Der Scheduler verwendet diese Anfragen, um zu bestimmen, welche Knoten den Pod aufnehmen können.

• Ressourcenanfragen beeinflussen die Planung.
• Ressourcenanfragen beeinflussen die CPU-Zeitverteilung.
• Ressourcenanfragen werden pro Container angegeben.

Ressourcenlimits. Ressourcenlimits geben die maximale Menge an CPU und Speicher an, die ein Container verbrauchen darf. Wenn ein Container sein Speicherlimit überschreitet, wird er vom OOM-Killer beendet.

• Ressourcenlimits verhindern, dass Container zu viele Ressourcen verbrauchen.
• Ressourcenlimits werden pro Container angegeben.
• Das Überschreiten von Speicherlimits führt dazu, dass der Container beendet wird.

QoS-Klassen. Kubernetes kategorisiert Pods in drei Klassen der Dienstgüte (QoS): BestEffort, Burstable und Guaranteed. Diese Klassen bestimmen, welche Pods zuerst beendet werden, wenn der Speicher knapp wird.

• BestEffort-Pods werden zuerst beendet.
• Guaranteed-Pods werden zuletzt beendet.
• Burstable-Pods werden dazwischen beendet.

LimitRanges und ResourceQuotas. LimitRanges ermöglichen es Ihnen, Standard-, Mindest- und Höchstwerte für Ressourcenanfragen und -limits für Pods in einem Namespace festzulegen, während ResourceQuotas die Gesamtmenge an Ressourcen in einem Namespace begrenzen. Diese Ressourcen helfen, den Ressourcenverbrauch zu verwalten und zu verhindern, dass Benutzer Clusterressourcen überbeanspruchen.

• LimitRanges legen Standard-, Mindest- und Höchstwerte für Ressourcenanfragen und -limits für Pods fest.
• ResourceQuotas begrenzen die Gesamtmenge an Ressourcen, die in einem Namespace verfügbar sind.
• ResourceQuotas begrenzen die Anzahl der erstellbaren Objekte.

9. Autoskalierung: Dynamische Anpassung an die Nachfrage

Kubernetes kann so konfiguriert werden, dass die Anzahl der laufenden Replikate Ihrer Anwendung automatisch skaliert wird.

Horizontale Pod-Autoskalierung. Der Horizontale Pod Autoscaler (HPA) skaliert automatisch die Anzahl der Pod-Replikate basierend auf der CPU-Auslastung, dem Speicherverbrauch oder anderen benutzerdefinierten Metriken. Dies ermöglicht es Anwendungen, sich dynamisch an sich ändernde Verkehrs- und Ressourcenanforderungen anzupassen.

• Horizontale Pod-Autoskalierung skaliert die Anzahl der Pod-Replikate.
• Horizontale Pod-Autoskalierung basiert auf CPU-Auslastung, Speicherverbrauch oder anderen benutzerdefinierten Metriken.
• Horizontale Pod-Autoskalierung verwendet die Ressource HorizontalPodAutoscaler.

Autoskalierungsprozess. Der Autoskalierungsprozess umfasst das Abrufen von Pod-Metriken, das Berechnen der erforderlichen Anzahl von Pods und das Aktualisieren des Replikate-Feldes der skalierten Ressource. Der HPA-Controller überprüft regelmäßig die Pod-Metriken und passt die Anzahl der Replikate an, um den Zielwert der Metrik zu erreichen.

• Der Autoskalierungsprozess ruft Pod-Metriken von Heapster ab.
• Der Autoskalierungsprozess berechnet die erforderliche Anzahl von Pods.
• Der Autoskalierungsprozess aktualisiert das Replikate-Feld der skalierten Ressource.

Vertikale Pod-Autoskalierung. Während die horizontale Skalierung die primäre Methode zur Skalierung von Anwendungen in Kubernetes ist, wird auch die vertikale Pod-Autoskalierung (automatische Anpassung von Ressourcenanfragen und -limits) entwickelt. Diese Funktion wird es Pods ermöglichen, ihren Ressourcenverbrauch basierend auf ihren Bedürfnissen dynamisch anzupassen.

• Vertikale Pod-Autoskalierung wird noch nicht vollständig unterstützt.
• Vertikale Pod-Autoskalierung wird automatisch Ressourcenanfragen konfigurieren.
• Vertikale Pod-Autoskalierung wird Ressourcenanfragen ändern, während ein Pod läuft.

Cluster-Autoskalierung. Der Cluster Autoscaler provisioniert automatisch zusätzliche Knoten, wenn er feststellt, dass Pods aufgrund von Ressourcenmangel nicht geplant werden können. Er entprovisioniert auch Knoten, wenn sie unterausgelastet sind. Diese Funktion ermöglicht es Kubernetes-Clustern, ihre Größe dynamisch an die Bedürfnisse der bereitgestellten Anwendungen anzupassen.

• Cluster-Autoskalierung skaliert die Anzahl der Clusterknoten.
• Cluster-Autoskalierung basiert auf den Bedürfnissen der bereitgestellten Anwendungen.
• Cluster-Autoskalierung ist bei Cloud-Anbietern verfügbar.

10. Kubernetes erweitern: Benutzerdefinierte Ressourcen und Service-Katalog

Kubernetes kann mit eigenen benutzerdefinierten Objekten erweitert werden.

Benutzerdefinierte Ressourcen. Kubernetes ermöglicht es Ihnen, Ihre eigenen API-Objekte über CustomResourceDefinitions (CRDs) zu definieren. Dies ermöglicht es Ihnen, höherwertige Abstraktionen zu erstellen, die spezifisch für Ihre Anwendung oder Ihr Fachgebiet sind.

• CustomResourceDefinitions definieren benutzerdefinierte API-Objekte.
• Benutzerdefinierte Ressourcen können erstellt, gelesen, aktualisiert und gelöscht werden.
• Benutzerdefinierte Ressourcen können mit benutzerdefinierten Controllern automatisiert werden.

Benutzerdefinierte Controller. Um benutzerdefinierte Ressourcen funktionsfähig zu machen, müssen Sie einen benutzerdefinierten Controller erstellen, der Änderungen an diesen Ressourcen überwacht und basierend auf diesen Änderungen Aktionen ausführt. Dies ermöglicht es Ihnen, die Bereitstellung und Verwaltung Ihrer benutzerdefinierten Ressourcen zu automatisieren.

• Benutzerdefinierte Controller überwachen Änderungen an benutzerdefinierten Ressourcen.
• Benutzerdefinierte Controller führen Aktionen basierend auf Änderungen an benutzerdefinierten Ressourcen aus.
• Benutzerdefinierte Controller können andere Kubernetes-Ressourcen erstellen.

Service-Katalog. Der Kubernetes Service-Katalog ermöglicht es Ihnen, externe Dienste innerhalb Ihres Kubernetes-Clusters bereitzustellen und zu nutzen. Er bietet eine Möglichkeit für Benutzer, Dienste zu entdecken und zu konsumieren, ohne die Einzelheiten der zugrunde liegenden Infrastruktur zu kennen.

• Der Service-Katalog bietet ein Verzeichnis von Diensten.
• Der Service-Katalog verwendet Service-Broker, um Dienste bereitzustellen.
• Der Service-Katalog verwendet

Zuletzt aktualisiert: January 25, 2025