Kubernetes, auch als K8s abgekürzt, ist eine Open-Source-Plattform zur Automatisierung und Orchestrierung der Bereitstellung, Skalierung und Verwaltung von containerisierten Applications und Workloads. Es bietet eine Computerinfrastruktur mit integrierter Flexibilität, Skalierbarkeit, Zuverlässigkeit, hoher Verfügbarkeit und Portabilität für Apps, die als Container in jeder Umgebung ausgeführt werden – vor Ort, in der Cloud und am Edge.
Kubernetes automatisiert die gängigsten Aufgaben im Zusammenhang mit der Verwaltung containerisierter Workloads im großen Maßstab, einschließlich Bereitstellung, Lastausgleich, horizontale Skalierung, Rollouts und Rollbacks sowie Selbstheilung.
Viele Organisationen nutzen Kubernetes bereits in der Produktion – sei es für einige oder die Mehrheit ihrer Apps – und andere prüfen es. Aufgrund seiner Popularität ist Kubernetes zum De-facto-Standard für die Orchestrierung und Verwaltung von Containern geworden.
Die Akzeptanz von Kubernetes nimmt rasch zu, da es folgende Vorteile bietet:
Durch die Umstrukturierung herkömmlicher monolithischer Applications in kleinere, lose gekoppelte Teile (so genannte Microservices) lässt sich die Geschäftsflexibilität verbessern, da neue App-Funktionen und -Updates schneller veröffentlicht und einfacher skaliert werden können. Die Einführung einer Cloud-nativen Microservices-Architektur erfordert die Weiterentwicklung der zugrunde liegenden Computerinfrastruktur. Daher betrachten wir den Übergang von physischen Systemen und virtuellen Maschinen zu Containern als eine der effizientesten Möglichkeiten zum Ausführen von Microservices.
Mit der wachsenden Anzahl von Microservices und Containern steigt auch der Bedarf an einer Automatisierung der Containerverwaltung. Hier kommt Kubernetes ins Spiel.
Kubernetes orchestriert und führt containerisierte Apps in großem Maßstab aus. Es bietet jedoch keine Möglichkeit, Application zur Verteilung und Ausführung in ein containerisiertes Format zu packen (ein Container-Image umfasst den App-Code sowie die erforderlichen Laufzeiten, Bibliotheken und andere Softwareabhängigkeiten). Damit Pods ausgeführt werden können, erfordert Kubernetes außerdem, dass auf jedem Knoten eine Container-Runtime installiert ist. Kubernetes verwendete ursprünglich Docker Engine als Container-Laufzeitumgebung. Ab Kubernetes 1.24 muss die Container-Laufzeit jedoch der Container Runtime Interface (CRI) entsprechen, was bei Docker Engine nicht der Fall ist. Zwei beliebte CRI-kompatible Containerlaufzeiten sind CRI-O und containerd (ursprünglich ein Docker-Projekt).
Um Apps in Container zu packen, benötigen Sie ein Tool wie Docker , eines der beliebtesten Tools zum Erstellen, Teilen und Ausführen von Container-Apps. Es rationalisiert und automatisiert das Verpacken von Apps in portable Container-Images, die vor Ort, in der Cloud und auch in Kubernetes-Umgebungen ausgeführt und bereitgestellt werden können. Mit Docker gepackte Container können nativ auf Containerd- und CRI-O-Laufzeiten ausgeführt werden.
Eine Kubernetes-Plattform besteht aus Knoten, die zu einem Cluster zusammengeschlossen sind, in dem sie gemeinsame Rechenressourcen nutzen. Jeder Cluster verwaltet Pods, die kleinsten bereitstellbaren Einheiten in der Kubernetes-Architektur. Ein Pod enthält einen oder mehrere App-Container. Pods werden zu Gruppen zusammengefasst, um einen Dienst zu bilden. Auf Apps innerhalb eines Kubernetes-Clusters kann von außen über mehrere Methoden zugegriffen werden, wobei der Ingress-Controller eine der beliebtesten und effizientesten Methoden ist.
Schauen wir uns die Komponenten in einer Kubernetes-Umgebung genauer an:
Ein Kubernetes-Pod ist die kleinste ausführbare Einheit, die in Kubernetes bereitgestellt werden kann. Der Pod ist ein „virtueller Host“ für das oder die App-Container-Images (wie ein physischer Server oder eine virtuelle Maschine für herkömmliche Apps) und kapselt einen oder mehrere Container ein, die dieselben Rechen-, Speicher- und Netzwerkressourcen gemeinsam nutzen (und daher als relativ eng gekoppelt betrachtet werden können). Pods werden auf Kubernetes-Knoten bereitgestellt und ausgeführt.
Ein Kubernetes-Knoten ist die kleinste Einheit einer Computerinfrastruktur. Der Knoten kann eine virtuelle Maschine oder ein physischer Server sein, der Prozessor-, Speicher-, Speicher- und Netzwerkressourcen zuweist, um Pods bereitzustellen, auszuführen, zu skalieren und zu verwalten. Knoten werden zu einem Cluster zusammengefügt.
Ein Kubernetes-Cluster ist eine Gruppe von Knoten, in denen gepoolte Rechenressourcen über Pods hinweg gemeinsam genutzt werden. Es gibt zwei Arten von Knoten in einem Cluster:
Normalerweise gibt es in einem Kubernetes-Cluster mehr als einen Knoten jedes Typs, um eine hohe Verfügbarkeit und Fehlertoleranz zu gewährleisten.
Eine Kubernetes-Bereitstellung beschreibt, wie eine App als Satz von Replikaten (oder Instanzen) des Pods in einem Cluster ausgeführt wird. Eine Bereitstellung definiert:
Kubernetes unterstützt einen dualen IPv4/IPv6-Stack, um Netzwerkkonnektivität für containerisierte Apps bereitzustellen, die in einem Cluster ausgeführt werden. Sowohl die Kommunikation zu und von Apps im Kubernetes-Cluster als auch die Kommunikation zwischen Diensten innerhalb des Clusters werden auf Ebene 4 (IP-Adresse, Port) und Ebene 7 (Hostname, Universal Resource Identifier [URI]) verwaltet und umfassen Routing-, Lastausgleichs-, Sicherheits-, Überwachungs- und Sichtbarkeitsfunktionen.
Im Kubernetes-Netzwerkmodell verfügt jeder Pod über eine eindeutige IP-Adresse, die dynamisch aus dem Pool privater Adressen des Clusters zugewiesen wird. Alle Pods, die auf allen Knoten im selben Cluster ausgeführt werden, gehören zum selben IP-Netzwerk und können über dieses Netzwerk miteinander kommunizieren. Mehrere Container innerhalb eines Pods kommunizieren über die Loopback-Schnittstelle miteinander.
Ein Kubernetes-Dienst macht die App oder den Microservice, der als ein oder mehrere Pods im Cluster ausgeführt wird, im Netzwerk zugänglich („stellt sie bereit“). Ein Kubernetes-Dienst stellt die App als logische Gruppe bestimmter Pods dar, die dieselbe Funktion ausführen, beispielsweise Web-Serving. Derselbe Selektor (oder die gleiche Bezeichnung) wird auf alle Pods in einem Dienst angewendet, um ihre Mitgliedschaft im Dienst zu kennzeichnen. Kubernetes verwendet das Label, um den Pod-Satz für einen Dienst zu verfolgen, wenn neue Pods bereitgestellt oder laufende Pods beendet werden.
Kubernetes-Dienste können gemäß den definierten Konnektivitätsrichtlinien innerhalb des Clusters miteinander kommunizieren und von außerhalb des Clusters zugänglich gemacht werden, beispielsweise durch die Verwendung eines Ingress-Controllers.
Das Ingress-Objekt, ein Teil der Kubernetes Ingress-API, kann verwendet werden, um in Kubernetes ausgeführte Applications extern über Layer-7-Protokolle (Application ) wie HTTP verfügbar zu machen. Ingress-Gateways und Ingress-Controller sind Tools zur Steuerung des Ingress-Objekts und zur Verwaltung der Kommunikation zwischen Benutzern und Applications (Benutzer-zu-Dienst- bzw. Nord-Süd-Konnektivität).
Das Ingress-Objekt bietet konstruktionsbedingt nur eingeschränkte Unterstützung für benutzerdefinierte Richtlinien zur Anforderungsverarbeitung. Sie können beispielsweise keine Sicherheitsrichtlinien definieren und daran anfügen. Daher verwenden viele Anbieter benutzerdefinierte Ressourcendefinitionen (CRDs), um die Funktionen ihrer Ingress-Controller zu erweitern und so den sich entwickelnden Kundenanforderungen gerecht zu werden.
Beispielsweise definiert der NGINX Ingress Controller benutzerdefinierte Ressourcen (VirtualServer, VirtualServerRoute, TransportServer und Policy), um Leistung, Belastbarkeit, Verfügbarkeit, Sicherheit und Beobachtbarkeit für API-Gateway, Load Balancer und Ingress-Funktionalität am Rand eines Kubernetes-Clusters zu verbessern.
NGINX bietet Dienste für Lastausgleich, Authentifizierung, Autorisierung, Zugriffskontrolle, Verschlüsselung, Beobachtung und Verkehrsaufteilung (Leistungsschalter, A/B-Tests sowie Blue-Green- und Canary-Bereitstellungen), um eine schnelle, zuverlässige und sichere Kommunikation zu gewährleisten. Zur Unterstützung häufiger App-Releases ermöglichen benutzerdefinierte NGINX-Ressourcen auch die Self-Service-Governance für Multi-Tenant-Entwicklungs- und DevOps-Teams.
Die Gateway-API ist ein Open-Source-Projekt, das die Servicevernetzung in Kubernetes verbessern und standardisieren soll. Die von der Kubernetes-Community verwaltete Gateway-API-Spezifikation wurde aus der Kubernetes Ingress API weiterentwickelt, um Einschränkungen der Ingress-Ressource in Produktionsumgebungen zu beheben. Dazu gehört die Möglichkeit, feinkörnige Richtlinien für die Anforderungsverarbeitung zu definieren und die Kontrolle über die Konfiguration an mehrere Teams und Rollen zu delegieren.
Weitere Informationen zur Implementierung der Gateway-API durch NGINX finden Sie in unserem Blog unter „5 Dinge, die Sie über NGINX Gateway Fabric wissen sollten“ .
Ein Service Mesh ist eine Infrastrukturschicht, die die Kommunikation zwischen Diensten in einem Kubernetes-Cluster steuert (Dienst-zu-Dienst- oder Ost-West-Konnektivität). Zu den häufigsten Service-Mesh-Anwendungsfällen gehören mTLS-Authentifizierung/-Verschlüsselung und Beobachtbarkeit der Kommunikation zwischen Diensten in einem K8s-Cluster.
Weitere Informationen zur einheitlichen App-Bereitstellung mit NGINX Gateway Fabric , das darauf ausgelegt ist, Ingress-Controller- und Service-Mesh-Anwendungsfälle effektiv in einem Tool zu kombinieren, finden Sie in unserem Blog unter „Ankündigung von NGINX Gateway Fabric Version 1.0“ .
Kubernetes-Sicherheit ist ein mehrschichtiger Ansatz zum Schutz der Infrastruktur (lokale und Cloud-Rechenressourcen, Netzwerkkommunikation und Verwaltungsebene) und der Applications, die in einem Kubernetes-Cluster ausgeführt werden.
Befolgen Sie zum Sichern der Infrastruktur die allgemeinen Sicherheitsempfehlungen, Tutorials und Best Practices zum Schutz von Cloud- und lokalen Implementierungen.
Implementieren Sie für sichere Applications starke Sicherheitskontrollen am Rand und innerhalb eines Kubernetes-Clusters, um Authentifizierung, Autorisierung, Zugriffskontrolle, Verschlüsselung, Überwachung und Sichtbarkeit mit optionaler Web Application Firewall und Denial-of-Service-Schutz für die gesamte Kommunikation zu/von und innerhalb eines Clusters bereitzustellen.
Weitere Informationen zur Sicherung von Kubernetes finden Sie in unserem Blog „Sechs Möglichkeiten zur Sicherung von Kubernetes mithilfe von Traffic-Management-Tools“ .
Zu Beginn der Einführung von Kubernetes war ein Do-It-Yourself-Ansatz (DIY) vorherrschend. Dieser ist jedoch für viele Organisationen komplex und schwer aufzubauen und zu betreiben. Aus diesem Grund übernehmen Unternehmen für Produktionsbereitstellungen cloudverwaltete Kubernetes-Plattformen und vorgefertigte Kubernetes-Distributionen, die verschiedene Technologiekomponenten integrieren, den Wartungslebenszyklus vereinfachen und in Hybrid- und Multi-Cloud-Umgebungen bereitgestellt werden können.
Nachfolgend sind einige Beispiele für die verwalteten und vorgefertigten Kubernetes-Plattformen aufgeführt:
Cloudverwaltetes Kubernetes:
Vorgefertigte Kubernetes-Distributionen:
Der Kubernetes-native Konnektivitäts- und Sicherheits-Stack von NGINX trägt dazu bei, das Kundenerlebnis durch reduzierte Komplexität, erhöhte Betriebszeit und detaillierte Echtzeit-Sichtbarkeit im großen Maßstab für Kubernetes Applications zu verbessern, die vor Ort, in der Cloud und am Edge ausgeführt werden.
Konnektivitäts-Stack für Kubernetes – Optimieren, skalieren und sichern Sie Kubernetes-Apps in hybriden Multi-Cloud-Umgebungen.
Fordern Sie zunächst Ihre kostenlose 30-Tage-Testversion von NGINX Ingress Controller mit NGINX App Protect WAF und DoS an.