View a markdown version of this page

Kubernetes-Konzepte - Amazon EKS

Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Kubernetes-Konzepte

Amazon Elastic Kubernetes Service (Amazon EKS) ist ein AWS verwalteter Service, der auf dem Open-Source-Kubernetes-Projekt basiert. Es gibt zwar Dinge, die Sie über die Integration des Amazon EKS-Service in die AWS Cloud wissen müssen (insbesondere, wenn Sie zum ersten Mal einen Amazon EKS-Cluster erstellen), aber sobald er betriebsbereit ist, verwenden Sie Ihren Amazon EKS-Cluster auf die gleiche Weise wie jeden anderen Kubernetes-Cluster. Um mit der Verwaltung von Kubernetes-Clustern und dem Bereitstellen von Workloads zu beginnen, benötigen Sie daher zumindest ein grundlegendes Verständnis der Kubernetes-Konzepte.

Auf dieser Seite werden die Kubernetes-Konzepte in drei Abschnitte unterteilt: Warum Kubernetes?, Cluster und Workloads. Der erste Abschnitt beschreibt den Wert der Ausführung eines Kubernetes-Services, insbesondere als verwalteter Service wie Amazon EKS. Der Abschnitt „Workloads“ behandelt, wie Kubernetes-Anwendungen erstellt, gespeichert, ausgeführt und verwaltet werden. Im Abschnitt „Cluster“ werden die verschiedenen Komponenten erläutert, aus denen Kubernetes-Cluster bestehen, und welche Aufgaben Sie beim Erstellen und Verwalten von Kubernetes-Clustern haben.

Beim Durchgehen dieser Inhalte führen Sie Links zu weiteren Beschreibungen der Kubernetes-Konzepte in der Amazon-EKS- und Kubernetes-Dokumentation, falls Sie tiefer in die hier behandelten Themen eintauchen möchten. Weitere Informationen zur Implementierung der Kubernetes-Steuerebene und der Rechenfunktionen in Amazon EKS finden Sie unter Amazon-EKS-Architektur.

Warum Kubernetes?

Kubernetes wurde entwickelt, um die Verfügbarkeit und Skalierbarkeit beim Ausführen unternehmenskritischer containerisierter Anwendungen in Produktionsqualität zu verbessern. Anstatt Kubernetes nur auf einem einzelnen Rechner auszuführen (obwohl dies möglich ist), erreicht Kubernetes diese Ziele, indem es Ihnen ermöglicht, Anwendungen auf einer Reihe von Rechnern auszuführen, die je nach Bedarf erweitert oder reduziert werden können. Kubernetes enthält Funktionen, die Ihnen Folgendes vereinfachen:

  • Anwendungen auf mehreren Rechnern (mithilfe von in Pods bereitgestellten Containern) bereitstellen

  • Container-Zustand und Neustart ausgefallener Container überwachen

  • Container je nach Auslastung nach oben und unten zu skalieren

  • Container mit neuen Versionen aktualisieren

  • Ressourcen zwischen Containern zuzuweisen

  • Datenverkehr über mehrere Rechner hinweg ausgleichen

Durch die Automatisierung dieser komplexen Aufgaben durch Kubernetes kann sich ein Anwendungsentwickler auf die Erstellung und Verbesserung seiner Anwendungs-Workloads konzentrieren, anstatt sich um die Infrastruktur zu kümmern. Der Entwickler erstellt in der Regel Konfigurationsdateien im YAML-Format, die den gewünschten Zustand der Anwendung beschreiben. Dies kann beinhalten, welche Container ausgeführt werden sollen, Ressourcenlimits, Anzahl der Pod-Replikate, CPU/memory Zuweisung, Affinitätsregeln und mehr.

Eigenschaften von Kubernetes

Um seine Ziele zu erreichen, verfügt Kubernetes über die folgenden Eigenschaften:

  • Containerisiert – Kubernetes ist ein Container-Orchestrierungstool. Um Kubernetes verwenden zu können, müssen Sie zunächst Ihre Anwendungen containerisieren. Je nach Art der Anwendung kann dies als eine Reihe von Microservices, als Batch-Aufträge oder in anderen Formen erfolgen. Anschließend können Ihre Anwendungen die Vorteile eines Kubernetes-Workflows nutzen, der ein umfangreiches Ökosystem von Tools beinhaltet, in dem Container als Images in einer Container-Registry gespeichert, in einem Kubernetes-Cluster bereitgestellt und in einem verfügbaren Knoten ausgeführt werden können. Sie können einzelne Container auf Ihrem lokalen Computer mit Docker oder einer anderen Container-Laufzeitumgebung erstellen und testen, bevor Sie sie in Ihrem Kubernetes-Cluster bereitstellen.

  • Skalierbar – Wenn die Nachfrage nach Ihren Anwendungen die Kapazität der auszuführenden Instances dieser Anwendungen übersteigt, kann Kubernetes entsprechend hochskaliert werden. Bei Bedarf kann Kubernetes erkennen, ob Anwendungen mehr CPU oder Speicher benötigen, und darauf reagieren, indem es entweder automatisch die verfügbare Kapazität erweitert oder mehr der vorhandenen Kapazität nutzt. Die Skalierung kann auf Pod-Ebene erfolgen, wenn genügend Rechenleistung für die Ausführung mehrerer Anwendungs-Instances zur Verfügung steht (horizontale Pod-Autoskalierung), oder auf Knotenebene, wenn mehr Knoten für die erhöhte Kapazität hochgefahren werden müssen (Cluster Autoscaler oder Karpenter). Da keine Kapazität mehr benötigt wird, können diese Services unnötige Pods löschen und nicht mehr benötigte Knoten herunterfahren.

  • Verfügbar – Wenn eine Anwendung oder ein Knoten fehlerhaft oder nicht mehr verfügbar ist, kann Kubernetes die ausgeführten Workloads auf einen anderen verfügbaren Knoten verschieben. Sie können das Problem beheben, indem Sie einfach eine ausgeführte Instance einer Workload oder einen Knoten löschen, auf dem Ihre Workload ausgeführt wird. Im Endeffekt können Workloads an anderen Standorten hochgefahren werden, wenn sie dort nicht mehr ausgeführt werden können.

  • Deklarativ – Kubernetes verwendet aktive Abstimmung, um ständig zu überprüfen, ob der von Ihnen für Ihren Cluster deklarierte Status mit dem tatsächlichen Status übereinstimmt. Durch die Anwendung von Kubernetes-Objekten auf einen Cluster, in der Regel über Konfigurationsdateien im YAML-Format, können Sie beispielsweise den Start der Workloads anfordern, die Sie in Ihrem Cluster ausführen möchten. Sie können die Konfigurationen später ändern, um beispielsweise eine neuere Version eines Containers zu verwenden oder mehr Speicher zuzuweisen. Kubernetes wird die erforderlichen Maßnahmen ergreifen, um den gewünschten Zustand herzustellen. Dazu gehört unter anderem das Hoch- oder Herunterfahren von Knoten, das Beenden und Neustarten von Workloads oder das Abrufen aktualisierter Container.

  • Zusammensetzbar – Da eine Anwendung in der Regel aus mehreren Komponenten besteht, ist es wünschenswert, eine Reihe dieser Komponenten (oft durch mehrere Container repräsentiert) gemeinsam verwalten zu können. Während Docker Compose eine Möglichkeit bietet, dies direkt mit Docker zu tun, kann Ihnen der Befehl Kubernetes Kompose dabei helfen, dies mit Kubernetes zu erreichen. Ein Beispiel hierfür finden Sie unter Übersetzen einer Docker-Compose-Datei in Kubernetes-Ressourcen.

  • Erweiterbar — Im Gegensatz zu proprietärer Software ist das Open-Source-Kubernetes-Projekt so konzipiert, dass Sie Kubernetes nach Belieben erweitern können, um Ihren Bedürfnissen gerecht zu werden. APIs und Konfigurationsdateien können direkt geändert werden. Drittanbieter werden aufgefordert, eigene Controller zu schreiben, um sowohl die Infrastruktur- als auch die Endbenutzer-Feature von Kubernetes zu erweitern. Mit Webhooks können Sie Cluster-Regeln einrichten, um Richtlinien durchzusetzen und sich an veränderte Bedingungen anzupassen. Weitere Informationen zur Erweiterung von Kubernetes-Clustern finden Sie unter Erweiterung von Kubernetes.

  • Portabel – Viele Unternehmen haben ihre Abläufe in Kubernetes standardisiert, da sie damit alle ihre Anwendungsanforderungen auf einheitliche Weise verwalten können. Entwickler können dieselben Pipelines zum Entwickeln und Speichern von containerisierten Anwendungen verwenden. Diese Anwendungen können dann auf Kubernetes-Clustern bereitgestellt werden, die vor Ort, in Clouds, auf point-of-sales Terminals in Restaurants oder auf IOT-Geräten laufen, die über die Remote-Standorte des Unternehmens verteilt sind. Da es sich um eine Open-Source-Software handelt, können Nutzer diese speziellen Kubernetes-Distributionen sowie die für deren Verwaltung erforderlichen Tools entwickeln.

Verwaltung von Kubernetes

Der Quellcode von Kubernetes ist kostenlos verfügbar, sodass Sie Kubernetes mit Ihrer eigenen Ausrüstung selbst installieren und verwalten können. Die eigenständige Verwaltung von Kubernetes erfordert jedoch fundierte Fachkenntnisse und ist mit einem erheblichen Zeit- und Arbeitsaufwand verbunden. Aus diesen Gründen entscheiden sich die meisten Anwender, die Produktions-Workloads bereitstellen, für einen Cloud-Anbieter (z. B. Amazon EKS) oder einen On-Premises-Anbieter (z. B. Amazon EKS Anywhere) mit einer eigenen erprobten Kubernetes-Verteilung und Support durch Kubernetes-Experten. Dadurch können Sie einen Großteil der undifferenzierten, aufwändigen Aufgaben, die für die Wartung Ihrer Cluster erforderlich sind, auslagern, darunter:

  • Hardware — Wenn Sie keine Hardware zur Verfügung haben, um Kubernetes gemäß Ihren Anforderungen auszuführen, kann Ihnen ein Cloud-Anbieter wie AWS Amazon EKS Vorabkosten sparen. Mit Amazon EKS bedeutet dies, dass Sie die besten Cloud-Ressourcen nutzen können, die Ihnen zur Verfügung stehen AWS, darunter Computer-Instances (Amazon Elastic Compute Cloud), Ihre eigene private Umgebung (Amazon VPC), zentrales Identitäts- und Berechtigungsmanagement (IAM) und Speicher (Amazon EBS). AWS verwaltet die Computer, Netzwerke, Rechenzentren und alle anderen physischen Komponenten, die für den Betrieb von Kubernetes erforderlich sind. Ebenso müssen Sie Ihr Rechenzentrum nicht für die maximale Kapazität an Tagen mit höchster Auslastung auslegen. Bei Amazon EKS Anywhere oder anderen lokalen Kubernetes-Clustern sind Sie für die Verwaltung der Infrastruktur verantwortlich, die in Ihren Kubernetes-Bereitstellungen verwendet wird, aber Sie können sich trotzdem darauf verlassen, dass wir Sie dabei unterstützen, Kubernetes auf dem AWS neuesten Stand zu halten.

  • Verwaltung der Kontrollebene — Amazon EKS verwaltet die Sicherheit und Verfügbarkeit der AWS gehosteten Kubernetes-Steuerebene, die für die Planung von Containern, die Verwaltung der Verfügbarkeit von Anwendungen und andere wichtige Aufgaben verantwortlich ist, sodass Sie sich auf Ihre Anwendungs-Workloads konzentrieren können. Sollte Ihr Cluster ausfallen, AWS sollten Sie über die Mittel verfügen, Ihren Cluster wieder in den Betriebszustand zu versetzen. Bei Amazon EKS Anywhere verwalten Sie die Steuerebene selbst.

  • Geprüfte Upgrades – Bei der Aktualisierung Ihrer Cluster können Sie sich darauf basieren, dass Amazon EKS oder Amazon EKS Anywhere geprüfte Versionen ihrer Kubernetes-Verteilungen bereitstellen.

  • Add-Ons – Es gibt Hunderte von Projekten, die für die Erweiterung und Arbeit mit Kubernetes entwickelt wurden und die Sie der Infrastruktur Ihres Clusters hinzufügen oder zur Unterstützung der Ausführung Ihrer Workloads verwenden können. Anstatt diese Add-Ons selbst zu erstellen und zu verwalten AWS Amazon-EKS-Add-ons, können Sie diese mit Ihren Clustern verwenden. Amazon EKS Anywhere bietet kuratierte Pakete, die Entwicklungen vieler beliebter Open-Source-Projekte enthalten. Daher ist es nicht erforderlich, die Software selbst zu entwickeln oder wichtige Sicherheitspatches, Fehlerbehebungen oder Upgrades zu verwalten. Wenn die Standardeinstellungen Ihren Anforderungen entsprechen, ist in der Regel nur ein sehr geringer Konfigurationsaufwand für diese Add-Ons erforderlich. Weitere Informationen zur Erweiterung Ihres Clusters mit Add-Ons finden Sie unter Cluster erweitern.

Kubernetes in Aktion

Das folgende Diagramm zeigt die wichtigsten Aktivitäten, die Sie als Kubernetes-Administrator oder Anwendungsentwickler zum Erstellen und zur Nutzung eines Kubernetes-Clusters durchführen würden. Dabei wird veranschaulicht, wie Kubernetes-Komponenten miteinander interagieren, wobei die AWS Cloud als Beispiel für den zugrunde liegenden Cloud-Anbieter verwendet wird.

Ein Kubernetes-Cluster in Aktion.

Ein Kubernetes-Administrator erstellt den Kubernetes-Cluster mit einem Tool, das speziell auf den Anbietertyp zugeschnitten ist, auf dem der Cluster entwickelt wird. In diesem Beispiel wird die AWS Cloud als Anbieter verwendet, der den verwalteten Kubernetes-Dienst namens Amazon EKS anbietet. Der verwaltete Service weist automatisch die zum Erstellen des Clusters erforderlichen Ressourcen zu. Dazu gehört das Erstellen von zwei neuen Virtual Private Clouds (Amazon VPCs) für den Cluster, die Einrichtung des Netzwerks und die Zuordnung von Kubernetes-Berechtigungen zu den neuen VPCs für die Verwaltung von Cloud-Ressourcen. Der verwaltete Service erkennt auch, dass die Dienste der Steuerungsebene über Ausführungsplätze verfügen, und weist null oder mehr Amazon EC2 EC2-Instances als Kubernetes-Knoten für die Ausführung von Workloads zu. AWS verwaltet eine Amazon-VPC selbst für die Kontrollebene, während die andere Amazon-VPC die Kundenknoten enthält, die Workloads ausführen.

Viele Aufgaben des Kubernetes-Administrators werden in Zukunft mithilfe von Kubernetes-Tools wie kubectl ausgeführt. Dieses Tool stellt Service-Anfragen direkt an die Steuerebene des Clusters. Die Vorgehensweise bei Abfragen und Änderungen am Cluster entspricht im Wesentlichen der Vorgehensweise, die Sie bei jedem Kubernetes-Cluster anwenden würden.

Ein Anwendungsentwickler, der Workloads in diesem Cluster bereitstellen möchte, kann mehrere Aufgaben ausführen. Der Entwickler muss die Anwendung in ein oder mehrere Container-Images integrieren und diese Images dann in eine Container-Registry übertragen, auf die der Kubernetes-Cluster zugreifen kann. AWS bietet zu diesem Zweck das Amazon Elastic Container Registry (Amazon ECR) an.

Um die Anwendung auszuführen, kann der Entwickler Konfigurationsdateien im YAML-Format erstellen, die dem Cluster mitteilen, wie die Anwendung ausgeführt werden soll, einschließlich der Angabe, welche Container aus der Registry abgerufen und wie diese Container in Pods verpackt werden sollen. Die Steuerebene (Scheduler) plant die Container für einen oder mehrere Knoten ein und die Container-Laufzeit auf jedem Knoten ruft die benötigten Container ab und führt sie aus. Der Entwickler kann auch einen Application Load Balancer einrichten, um den Datenverkehr auf die verfügbaren Container zu verteilen, die im jeweiligen Knoten ausgeführt werden, und die Anwendung so freizugeben, dass sie in einem öffentlichen Netzwerk für die Außenwelt verfügbar ist. Anschließend kann sich jeder, der die Anwendung nutzen möchte, mit dem Anwendungsendpunkt verbinden und darauf zugreifen.

In den folgenden Abschnitten werden die einzelnen Features aus der Perspektive von Kubernetes-Clustern und -Workloads detailliert beschrieben.

Cluster

Wenn Sie Kubernetes-Cluster starten und verwalten, sollten Sie wissen, wie Kubernetes-Cluster erstellt, erweitert, verwaltet und gelöscht werden. Sie sollten außerdem wissen, aus welchen Komponenten ein Cluster besteht und wie Sie diese Komponenten warten.

Tools zur Cluster-Verwaltung verwalten die Überschneidungen zwischen den Kubernetes-Services und dem zugrunde liegenden Hardware-Anbieter. Aus diesem Grund wird die Automatisierung dieser Aufgaben in der Regel vom Kubernetes-Anbieter (z. B. Amazon EKS oder Amazon EKS Anywhere) mithilfe von anbieterspezifischen Tools durchgeführt. Um beispielsweise einen Amazon-EKS-Cluster zu starten, können Sie eksctl create cluster verwenden, während Sie für Amazon EKS Anywhere eksctl anywhere create cluster verwenden können. Beachten Sie, dass diese Befehle zwar einen Kubernetes-Cluster erstellen, jedoch spezifisch für den Anbieter sind und nicht Teil des Kubernetes-Projekts selbst sind.

Tools zur Erstellung und Verwaltung von Clustern

Das Kubernetes-Projekt bietet Tools zur manuellen Erstellung eines Kubernetes-Clusters. Wenn Sie Kubernetes auf einem einzelnen Rechner installieren oder die Steuerebene auf einem Rechner ausführen und Knoten manuell hinzufügen möchten, können Sie CLI-Tools wie kind, minikube oder kubeadm verwenden, die unter Kubernetes-Installations-Tools aufgeführt sind. Um den gesamten Lebenszyklus der Cluster-Erstellung und -Verwaltung zu vereinfachen und zu automatisieren, ist es viel einfacher, Tools zu verwenden, die von einem etablierten Kubernetes-Anbieter unterstützt werden, wie z. B. Amazon EKS oder Amazon EKS Anywhere.

In AWS Cloud können Sie Amazon EKS-Cluster mithilfe von CLI-Tools wie eksctl oder deklarativeren Tools wie Terraform erstellen (siehe Amazon EKS Blueprints for Terraform). Sie können auch einen Cluster aus dem AWS-Managementkonsole erstellen. Eine Liste der Funktionen von Amazon EKS finden Sie unter Amazon-EKS-Feature. Zu den Kubernetes-Aufgaben, die Amazon EKS für Sie übernimmt, gehören:

  • Verwaltete Kontrollebene —AWS stellt sicher, dass der Amazon EKS-Cluster verfügbar und skalierbar ist, da er die Kontrollebene für Sie verwaltet und sie in allen AWS Availability Zones verfügbar macht.

  • Knotenverwaltung – Anstatt Knoten manuell hinzuzufügen, können Sie Amazon EKS Knoten bei Bedarf automatisch erstellen lassen, indem Sie verwaltete Knotengruppen (siehe Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen) oder Karpenter verwenden. Verwaltete Knotengruppen verfügen über Integrationen mit Kubernetes Cluster Autoscaling. Mithilfe von Knotenverwaltungstools können Sie Kosteneinsparungen erzielen, beispielsweise durch Spot Instances und Knotenkonsolidierung, sowie die Verfügbarkeit verbessern, indem Sie Feature zur Planung verwenden, um festzulegen, wie Workloads bereitgestellt und Knoten ausgewählt werden.

  • Cluster-Netzwerk — Richtet mithilfe von CloudFormation Vorlagen eksctl die Vernetzung zwischen Komponenten der Steuerungsebene und der Datenebene (Knoten) im Kubernetes-Cluster ein. Außerdem werden Endpunkte für die interne und externe Kommunikation eingerichtet. Weitere Informationen finden Sie unter Entmystifizierung von Cluster-Netzwerken für Amazon-EKS-Worker-Knoten. Die Kommunikation zwischen Pods in Amazon EKS erfolgt über Amazon EKS Pod Identities (sieheErfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt), wodurch Pods AWS Cloud-Methoden zur Verwaltung von Anmeldeinformationen und Berechtigungen nutzen können.

  • Add-Ons – Mit Amazon EKS entfällt die Notwendigkeit, Software-Komponenten zu erstellen und hinzuzufügen, die üblicherweise zur Unterstützung von Kubernetes-Clustern verwendet werden. Wenn Sie beispielsweise einen Amazon EKS-Cluster aus dem erstellen AWS-Managementkonsole, werden automatisch die Amazon EKS kube-proxy (Verwaltung von kube-proxy in Amazon-EKS-Clustern), das Amazon VPC CNI-Plug-In für Kubernetes (Pods mit dem Amazon VPC CNI zuweisen IPs) und CoreDNS () hinzugefügt. Verwalten von CoreDNS für DNS in Amazon-EKS-Clustern Weitere Informationen zu diesen Add-Ons, einschließlich einer Liste der verfügbaren Add-Ons, finden Sie unter Amazon-EKS-Add-ons.

Um Ihre Cluster auf Ihren eigenen On-Premises-Computern und -Netzwerken auszuführen, bietet Amazon Amazon EKS Anywhere an. Anstatt dass die AWS Cloud der Anbieter ist, haben Sie die Wahl, Amazon EKS Anywhere auf VMWare vSphere -, Bare Metal- (Tinkerbell-Anbieter), Snow - oder Nutanix-Plattformen CloudStackmit Ihren eigenen Geräten auszuführen.

Amazon EKS Anywhere basiert auf derselben Amazon EKS Distro-Software, die auch von Amazon EKS verwendet wird. Amazon EKS Anywhere stützt sich jedoch auf verschiedene Implementierungen der Kubernetes Cluster API (CAPI) -Schnittstelle, um den gesamten Lebenszyklus der Maschinen in einem Amazon EKS Anywhere Anywhere-Cluster zu verwalten (wie CAPV für vSphere und CAPC für). CloudStack Da der gesamte Cluster auf Ihrer Ausrüstung ausgeführt wird, übernehmen Sie die zusätzliche Verantwortung für die Verwaltung der Steuerebene und die Datensicherung (sieheetcd weiter unten in diesem Dokument).

Cluster-Komponenten

Die Komponenten eines Kubernetes-Clusters lassen sich in zwei Hauptbereiche unterteilen: die Steuerebene und die Worker-Knoten. Komponenten der Steuerungsebene verwalten den Cluster und ermöglichen den Zugriff darauf. APIs Worker-Knoten (manchmal auch einfach als Knoten bezeichnet) stellen die Orte bereit, an denen die eigentlichen Workloads ausgeführt werden. Knotenkomponente bestehen aus Services, die in jedem Knoten ausgeführt werden, um mit der Steuerebene zu kommunizieren und Container auszuführen. Die Gruppe der Worker-Knoten, die für Ihren Cluster festgelegt ist, wird als Datenebene bezeichnet.

Steuerebene

Die Steuerebene besteht aus einer Reihe von Services, die den Cluster verwalten. Diese Services können alle auf einem einzigen Computer ausgeführt werden oder auf mehrere Computer verteilt sein. Intern werden diese als Control Plane Instances (CPIs) bezeichnet. Wie CPIs sie ausgeführt werden, hängt von der Größe des Clusters und den Anforderungen an die Hochverfügbarkeit ab. Bei steigender Nachfrage im Cluster kann ein Service der Steuerebene skaliert werden, um mehr Instances dieses Services bereitzustellen, wobei die Anfragen zwischen den Instances lastverteilt werden.

Zu den Aufgaben, die von Komponenten der Kubernetes-Steuerebene ausgeführt werden, gehören:

  • Kommunikation mit Cluster-Komponenten (API-Server) – Der API-Server (kube-apiserver) stellt die Kubernetes-API bereit, sodass Anfragen an den Cluster sowohl innerhalb als auch außerhalb des Clusters gestellt werden können. Mit anderen Worten: Anforderungen zum Hinzufügen oder Ändern von Objekten eines Clusters (Pods, Services, Knoten usw.) können von externen Befehlen stammen, beispielsweise Anforderungen von kubectl zum Ausführen eines Pods. Ebenso können vom API-Server Anfragen an Komponenten innerhalb des Clusters gestellt werden, beispielsweise eine Abfrage an den kubelet-Service zum Status eines Pods.

  • Speichern von Daten über den Cluster (etcd-Schlüsselwertspeicher) – Der etcd-Service übernimmt die wichtige Aufgabe, den aktuellen Status des Clusters zu verfolgen. Wenn der etcd-Service nicht mehr erreichbar ist, können Sie den Status des Clusters nicht mehr aktualisieren oder abfragen, obwohl die Workloads noch eine Weile ausgeführt werden. Aus diesem Grund werden in kritischen Clustern in der Regel mehrere Instances des etcd-Services mit Lastausgleich gleichzeitig ausgeführt und regelmäßige Backups des etcd-Schlüsselwertspeichers für den Fall eines Datenverlusts oder einer Datenbeschädigung durchgeführt. Denken Sie daran, dass dies alles in Amazon EKS standardmäßig automatisch für Sie erledigt wird. Amazon EKS Anywhere bietet Anweisungen für die Sicherung und Wiederherstellung von etcd. Informationen darüber, wie etcd Daten verwaltet, finden Sie im etcd-Datenmodell.

  • Pods für Knoten planen (Scheduler) – Anfragen zum Starten oder Stoppen eines Pods in Kubernetes werden an den Kubernetes Scheduler (kube-scheduler) weitergeleitet. Da ein Cluster über mehrere Knoten verfügen kann, auf denen der Pod ausgeführt werden kann, muss Scheduler auswählen, in welchem Knoten (oder auf welchen Knoten im Falle von Replikaten) der Pod ausgeführt werden soll. Wenn nicht genügend Kapazität verfügbar ist, um den angeforderten Pod in einem vorhandenen Knoten auszuführen, schlägt die Anforderung fehl, sofern Sie keine anderen Vorkehrungen getroffen haben. Zu diesen Vorkehrungen könnte die Aktivierung von Services wie verwaltete Knotengruppen (Vereinfachung des Knotenlebenszyklus mit verwalteten Knotengruppen) oder Karpenter gehören, die automatisch neue Knoten starten können, um die Workloads zu bewältigen.

  • Komponenten im gewünschten Zustand belassen (Controller Manager) — Der Kubernetes Controller Manager wird als Daemon-Prozess (kube-controller-manager) ausgeführt, um den Status des Clusters zu beobachten und Änderungen am Cluster vorzunehmen, um die erwarteten Zustände wiederherzustellen. Insbesondere gibt es mehrere Controller, die verschiedene Kubernetes-Objekte überwachen, darunter statefulset-controller, endpoint-controller, cronjob-controller, node-controller und andere.

  • Cloud-Ressourcen verwalten (Cloud Controller Manager) — Interaktionen zwischen Kubernetes und dem Cloud-Anbieter, der Anfragen für die zugrunde liegenden Rechenzentrumsressourcen ausführt, werden vom Cloud Controller Manager () abgewickelt. cloud-controller-manager Zu den vom Cloud Controller Manager verwalteten Controllern können ein Route Controller (für die Einrichtung von Cloud-Netzwerkweiterleitungen), ein Service Controller (für die Nutzung von Cloud-Lastausgleichsservices) und ein Knoten-Lebenszyklus-Controller (um Knoten während ihres Lebenszyklus mit Kubernetes synchron zu halten) gehören.

Worker-Knoten (Datenebene)

Bei einem Kubernetes-Cluster mit einem Knoten werden Workloads auf demselben Rechner wie die Steuerebene ausgeführt. Eine gängigere Konfiguration ist jedoch ein oder mehrere separate Computersysteme (Knoten), die für die Ausführung von Kubernetes-Workloads vorgesehen sind.

Wenn Sie zum ersten Mal einen Kubernetes-Cluster erstellen, können Sie mit einigen Tools zur Cluster-Erstellung eine bestimmte Anzahl von Knoten konfigurieren, die dem Cluster hinzugefügt werden sollen (entweder durch die Identifizierung vorhandener Computersysteme oder durch die Erstellung neuer Systeme durch den Anbieter). Bevor Workloads zu diesen Systemen hinzugefügt werden, werden jedem Knoten Services hinzugefügt, um diese Features zu implementieren:

  • Knoten einzeln verwalten (kubelet) – Der API-Server kommuniziert mit dem Kubelet-Service, der in jedem Knoten ausgeführt wird, um sicherzustellen, dass der Knoten ordnungsgemäß registriert ist und die vom Scheduler angeforderten Pods ausgeführt werden. Das Kubelet kann die Pod-Manifeste lesen und Speicher-Volumes oder andere von den Pods benötigte Feature auf dem lokalen System einrichten. Es kann auch den Zustand der lokal ausgeführten Container überprüfen.

  • Container in einem Knoten ausführen (Container-Laufzeit) – Die Container-Laufzeit in jedem Knoten verwaltet die Container, die für jeden dem Knoten zugewiesenen Pod angefordert werden. Das bedeutet, dass es Container-Images aus der entsprechenden Registry abrufen, den Container starten und anhalten kann und auf Anfragen zum Container antwortet. Die Standard-Container-Laufzeit ist containerd. Ab Kubernetes 1.24 wurde die spezielle Integration von Docker (dockershim), die als Container-Laufzeit verwendet werden konnte, aus Kubernetes entfernt. Sie können Docker zwar weiterhin zum Testen und Ausführen von Containern auf Ihrem lokalen System verwenden, aber um Docker mit Kubernetes zu verwenden, müssen Sie jetzt Docker Engine auf jedem Knoten installieren, um es mit Kubernetes zu verwenden.

  • Netzwerk zwischen Containern verwalten (kube-proxy) – Um die Kommunikation zwischen Pods zu unterstützen, verwendet Kubernetes eine als Service bezeichnetes Feature zum Einrichten von Pod-Netzwerken, welche die mit diesen Pods verknüpften IP-Adressen und Ports verfolgen. Der Service kube-proxy wird in jedem Knoten ausgeführt, damit die Kommunikation zwischen Pods stattfinden kann.

Cluster erweitern

Es gibt einige Services, die Sie zu Kubernetes hinzufügen können, um den Cluster zu unterstützen, die aber nicht in der Steuerebene ausgeführt werden. Diese Services werden oft direkt in Knoten im kube-system-Namespace oder in einem eigenen Namespace ausgeführt (wie dies bei Drittanbietern oft der Fall ist). Ein gängiges Beispiel ist der CoreDNS-Service, der DNS-Services für den Cluster bereitstellt. Informationen dazu, wie Sie feststellen können, welche Cluster-Services in Ihrem Cluster im Kube-System ausgeführt werden, finden Sie unter Integrierte Services ermitteln.

Es gibt verschiedene Arten von Add-Ons, die Sie Ihren Clustern hinzufügen können. Um die Funktionsfähigkeit Ihrer Cluster zu gewährleisten, können Sie Beobachtbarkeitsfunktionen hinzufügen (siehe Überwachung der Cluster-Leistung und Anzeige von Protokollen), mit denen Sie beispielsweise Protokollierung, Überwachung und Metriken durchführen können. Mit diesen Informationen können Sie auftretende Probleme beheben, oft über dieselben Beobachtbarkeitsschnittstellen. Beispiele für diese Arten von Diensten sind Amazon CloudWatch (sieheÜberwachen Sie Clusterdaten mit Amazon CloudWatch) GuardDuty, AWS Distro for OpenTelemetry, das Amazon VPC CNI-Plugin für Kubernetes (siehePods mit dem Amazon VPC CNI zuweisen IPs) und Grafana Kubernetes Monitoring. Für Speicher (sieheVerwendung von Anwendungsdatenspeichern für Ihren Cluster) gehören zu den Add-Ons für Amazon EKS der Amazon Elastic Block Store CSI Driver (sieheKubernetes-Volume-Speicher mit Amazon EBS verwenden), der Amazon Elastic File System CSI Driver (sieheVerwendung von elastischem Dateisystemspeicher mit Amazon EFS) und mehrere Speicher-Add-Ons von Drittanbietern (z. B. der Amazon FSx for NetApp ONTAP CSI-TreiberVerwendung von leistungsstarkem App-Speicher mit FSx für NetApp ONTAP).

Eine umfassendere Liste der verfügbaren Amazon-EKS-Add-Ons finden Sie unter Amazon-EKS-Add-ons.

Workloads

Kubernetes definiert einen Workload als „eine in Kubernetes ausgeführte Anwendung“. Diese Anwendung kann aus einer Reihe von Microservices bestehen, die als Container in Pods ausgeführt werden, oder als Batch-Auftrag oder als eine andere Art von Anwendung. Kubernetes stellt sicher, dass Ihre Anforderungen für die Einrichtung oder Bereitstellung dieser Objekte ausgeführt werden. Als jemand, der Anwendungen bereitstellt, sollten Sie lernen, wie Container erstellt werden, wie Pods definiert werden und welche Methoden Sie für deren Bereitstellung verwenden können.

Container

Das grundlegendste Element eines Anwendungs-Workloads, den Sie in Kubernetes bereitstellen und verwalten, ist ein Pod . Ein Pod stellt eine Möglichkeit dar, die Komponenten einer Anwendung zu speichern und Spezifikationen zu definieren, die die Attribute des Pods beschreiben. Im Gegensatz dazu bietet beispielsweise ein RPM- oder Deb-Paket Software für ein Linux-System, das selbst jedoch nicht als Einheit ausgeführt wird.

Da der Pod die kleinste bereitstellbare Einheit ist, enthält er in der Regel einen einzigen Container. In Fällen, in denen Container eng miteinander verbunden sind, können sich jedoch mehrere Container in einem Pod befinden. Ein Webserver-Container kann beispielsweise in einem Pod mit einem Sidecar-Container verpackt sein, der die Protokollierung, Überwachung oder einen anderen Service bereitstellt, der eng mit dem Webserver-Container verbunden ist. In diesem Fall wird durch die Zugehörigkeit zum selben Pod sichergestellt, dass für jede ausgeführte Instance des Pods beide Container immer auf demselben Knoten ausgeführt werden. Ebenso teilen sich alle Container in einem Pod die gleiche Umgebung, wobei die Container in einem Pod so ausgeführt werden, als würden sie sich in demselben isolierten Host befinden. Dies hat zur Folge, dass die Container eine einzige IP-Adresse gemeinsam nutzen, die Zugriff auf den Pod bietet, und die Container miteinander kommunizieren können, als würden sie auf ihrem eigenen lokalen Host ausgeführt.

Die Pod-Spezifikationen (PodSpec) definieren den gewünschten Status des Pods. Sie können einen einzelnen Pod oder mehrere Pods bereitstellen, indem Sie Workload-Ressourcen zur Verwaltung von Pod-Vorlagen verwenden. Zu den Workload-Ressourcen gehören Bereitstellungen (zur Verwaltung mehrerer Pod-Repliken), StatefulSets(zur Bereitstellung von Pods, die einzigartig sein müssen, z. B. Datenbank-Pods) und DaemonSets(bei denen ein Pod kontinuierlich auf jedem Knoten ausgeführt werden muss). Dazu später mehr.

Während ein Pod die kleinste Einheit ist, die Sie bereitstellen, ist ein Container die kleinste Einheit, die Sie entwickeln und verwalten.

Entwicklung von Containern

Der Pod ist eigentlich nur eine Struktur um einen oder mehrere Container, wobei jeder Container selbst das Dateisystem, ausführbare Dateien, Konfigurationsdateien, Bibliotheken und andere Komponenten enthält, um die Anwendung tatsächlich auszuführen. Da Container erstmals von einem Unternehmen namens Docker Inc. eingeführt wurden, werden sie manchmal als Docker-Container bezeichnet. Inzwischen hat die Open Container Initiative seitdem Container-Laufzeiten, Images und Verteilungsmethoden für die Branche definiert. Hinzu kommt, dass Container aus vielen vorhandenen Linux-Features erstellt wurden. Andere bezeichnen Container oft als OCI-Container, Linux-Container oder einfach nur als Container.

Wenn Sie einen Container entwickeln, beginnen Sie in der Regel mit einer Docker-Datei (die wörtlich so heißt). Innerhalb dieser Docker-Datei identifizieren Sie:

  • Ein Basis-Image – Ein Basis-Container-Image ist ein Container, der normalerweise entweder aus einer Minimalversion des Dateisystems eines Betriebssystems (wie Red Hat Enterprise Linux oder Ubuntu) oder einem Minimalsystem erstellt wird, das erweitert wurde, um Software zum Ausführen bestimmter Arten von Anwendungen bereitzustellen (wie Node.js- oder Python-Apps).

  • Anwendungssoftware – Sie können Ihre Anwendungssoftware Ihrem Container auf die gleiche Weise hinzufügen, wie Sie sie einem Linux-System hinzufügen würden. Beispielsweise können Sie in Ihrer Docker-Datei npm und yarn ausführen, um eine Java-Anwendung zu installieren, oder yum und dnf, um RPM-Pakete zu installieren. Anders ausgedrückt: Mit einem RUN-Befehl in einer Dockerdatei können Sie jeden Befehl ausführen, der im Dateisystem Ihres Basis-Images verfügbar ist, um Software zu installieren oder innerhalb des resultierenden Container-Images zu konfigurieren.

  • Anweisungen – Die Dockerfile-Referenz beschreibt die Anweisungen, die Sie einer Docker-Datei hinzufügen können, wenn Sie es konfigurieren. Dazu gehören Anweisungen zum Erstellen des Inhalts des Containers selbst (ADD oder COPY-Dateien aus dem lokalen System), zum Identifizieren von Befehlen, die beim Ausführen des Containers ausgeführt werden sollen (CMD oder ENTRYPOINT), und zum Verbinden des Containers mit dem System, in dem er ausgeführt wird (durch Identifizieren des auszuführenden USER, eines einzubindenden lokalen VOLUME oder der Ports zu EXPOSE).

Während der docker-Befehl und der Service üblicherweise zur Erstellung von Containern verwendet werden (docker build), gibt es auch andere Tools wie podman und nerdctl, die zur Erstellung von Container-Images verwendet werden können. Weitere Informationen zur Erstellung von Containern finden Sie unter Entwicklung besserer Container-Images oder Überblick über Docker Build.

Aufbewahrungscontainer

Sobald Sie Ihr Container-Image entwickelt haben, können Sie es in einer Registry für die Container-Verteilung in Ihrer Workstation oder in einer öffentlichen Container-Registry speichern. Durch die Ausführung einer privaten Container-Registry in Ihrer Workstation können Sie Container-Images lokal speichern und haben so jederzeit Zugriff darauf.

Um Container-Images auf eine öffentlichere Art und Weise zu speichern, können Sie sie in eine öffentliche Container-Registry verschieben. Öffentliche Container-Registries bieten einen zentralen Ort zum Speichern und Verteilen von Container-Images. Beispiele für öffentliche Container-Registrys sind die Amazon Elastic Container Registry, Red Hat Quay Registry und Docker Hub Registry.

Bei Ausführung von containerisierten Workloads in Amazon Elastic Kubernetes Service (Amazon EKS) empfehlen wir, Kopien der offiziellen Docker-Images abzurufen, die in der Amazon Elastic Container Registry gespeichert sind. Amazon ECR speichert diese Images seit 2021. Sie können in der Amazon ECR Public Gallery nach beliebten Container-Images suchen, und speziell nach den Docker-Hub-Images in der Amazon ECR Docker Gallery suchen.

Ausführung von Containern

Da Container in einem Standardformat entwickelt werden, kann ein Container auf jedem Rechner ausgeführt werden, auf dem eine Container-Laufzeitumgebung (wie Docker) ausgeführt werden kann und dessen Inhalt der Architektur des lokalen Rechners entspricht (z. B. x86_64 oder arm). Um einen Container zu testen oder ihn einfach auf Ihrem lokalen Desktop auszuführen, können Sie die Befehle docker run oder podman run verwenden, um einen Container auf dem lokalen Host zu starten. Bei Kubernetes hingegen ist auf jedem Worker-Knoten eine Container-Laufzeitumgebung bereitgestellt und es liegt an Kubernetes, einen Knoten aufzufordern, einen Container auszuführen.

Sobald ein Container zur Ausführung auf einem Knoten zugewiesen wurde, prüft der Knoten, ob die angeforderte Version des Container-Images bereits auf dem Knoten vorhanden ist. Ist dies nicht der Fall, weist Kubernetes die Container-Laufzeitumgebung an, den Container aus der entsprechenden Container-Registry abzurufen und ihn dann lokal auszuführen. Beachten Sie, dass sich ein Container-Image auf das Softwarepaket bezieht, das zwischen Ihrem Laptop, der Container-Registry und den Kubernetes-Knoten verschoben wird. Ein Container bezieht sich auf eine ausgeführte Instance dieses Images.

Pods

Sobald Ihre Container bereit sind, umfasst die Arbeit mit Pods das Konfigurieren, Bereitstellen und Zugänglichmachen der Pods.

Konfigurierung von Pods

Wenn Sie einen Pod definieren, weisen Sie ihm eine Reihe von Attributen zu. Diese Attribute müssen mindestens den Pod-Namen und das auszuführende Container-Image enthalten. Es gibt jedoch noch viele andere Dinge, die Sie mit Ihren Pod-Definitionen konfigurieren möchten (Einzelheiten darüber, was in einen Pod aufgenommen werden kann, finden Sie auf der PodSpecSeite). Dazu zählen:

  • Speicher – Wenn ein ausgeführter Container angehalten und gelöscht wird, verschwindet der Datenspeicher in diesem Container, sofern Sie keinen dauerhafteren Speicher einrichten. Kubernetes unterstützt viele verschiedene Speicher und fasst diese unter dem Begriff Volumes zusammen. Zu den Speichertypen gehören CephFS, NFS, iSCSI und andere. Sie können sogar ein lokales Blockgerät vom lokalen Computer aus verwenden. Mit einem dieser in Ihrem Cluster verfügbaren Speichertypen können Sie das Speichervolume an einem ausgewählten Einbindepunkt im Dateisystem Ihres Containers einbinden. Ein persistentes Volume ist ein Volume, das nach dem Löschen des Pods weiterhin vorhanden ist, während ein flüchtiges Volume gelöscht wird, wenn der Pod gelöscht wird. Wenn Ihr Cluster-Administrator verschiedene Speicherklassen für Ihren Cluster erstellt hat, haben Sie möglicherweise die Möglichkeit, die Attribute des von Ihnen verwendeten Speichers auszuwählen, z. B. ob das Volume nach der Verwendung gelöscht oder wiederhergestellt wird, ob es erweitert wird, wenn mehr Speicherplatz benötigt wird, und sogar, ob es bestimmte Leistungsanforderungen erfüllt

  • Secrets — Indem Sie Secrets in Pod-Spezifikationen für Container verfügbar machen, können Sie die Berechtigungen bereitstellen, die diese Container für den Zugriff auf Dateisysteme, Datenbanken oder andere geschützte Ressourcen benötigen. Schlüssel, Passwörter und Token gehören zu den Elementen, die als Geheimnisse gespeichert werden können. Durch die Verwendung von Geheimnissen müssen Sie diese Informationen nicht in Container-Images speichern, sondern müssen sie nur ausgeführten Containern zur Verfügung stellen. Ähnlich wie Secrets sind ConfigMaps. Ein ConfigMap enthält in der Regel weniger kritische Informationen, wie beispielsweise Schlüssel-Wert-Paare zur Konfiguration eines Service.

  • Container-Ressourcen – Objekte zur weiteren Konfiguration von Containern können in Form von Ressourcenkonfigurationen vorliegen. Sie können für jeden Container die Speicher- und CPU-Menge anfordern, die er verwenden kann, und auch Beschränkungen für die Gesamtmenge dieser Ressourcen festlegen, die der Container verwenden kann. Beispiele finden Sie unter Ressource-Verwaltung für Pods und Container.

  • Störungen – Pods können unfreiwillig (wenn ein Knoten ausfällt) oder freiwillig (wenn ein Upgrade gewünscht wird) unterbrochen werden. Durch die Konfiguration eines Budgets für Pod-Unterbrechungen können Sie eine gewisse Kontrolle darüber ausüben, wie verfügbar Ihre Anwendung bleibt, wenn Störungen auftreten. Beispiele finden Sie unter Festlegen eines Budgets für Unterbrechung für Ihre Anwendung.

  • Namespaces – Kubernetes bietet verschiedene Möglichkeiten, Kubernetes-Komponenten und -Workloads voneinander zu isolieren. Das Ausführen aller Pods für eine bestimmte Anwendung im selben Namespace ist eine gängige Methode, um diese Pods gemeinsam zu sichern und zu verwalten. Sie können Ihre eigenen Namespaces erstellen oder keinen Namespace angeben (was dazu führt, dass Kubernetes den default-Namespace verwendet). Die Komponenten der Kubernetes-Steuerebene werden in der Regel im Namespace kube-system ausgeführt.

Die soeben beschriebene Konfiguration wird in der Regel in einer YAML-Datei zusammengefasst, die auf den Kubernetes-Cluster angewendet wird. Für persönliche Kubernetes-Cluster können Sie diese YAML-Dateien einfach auf Ihrem lokalen System speichern. Bei kritischeren Clustern und Workloads GitOpsist dies jedoch eine beliebte Methode, um Speicher und Updates sowohl für Workloads als auch für Kubernetes-Infrastrukturressourcen zu automatisieren.

Die zum Erfassen und Bereitstellen von Pod-Informationen verwendeten Objekte werden durch eine der folgenden Bereitstellungsmethoden definiert.

Bereitstellen von Pods

Die Methode, die Sie zum Bereitstellen von Pods wählen, hängt von der Art der Anwendung ab, die Sie mit diesen Pods ausführen möchten. Hier finden Sie einige Optionen:

  • Zustandslose Anwendungen – Eine zustandslose Anwendung speichert die Sitzungsdaten eines Clients nicht, sodass eine andere Sitzung nicht auf die Vorgänge einer vorherigen Sitzung zurückgreifen muss. Dies vereinfacht das Ersetzen von Pods durch neue, wenn sie fehlerhaft werden, oder das Verschieben ohne Speicherung des Zustands. Wenn Sie eine statuslose Anwendung (z. B. einen Webserver) ausführen, können Sie ein Deployment verwenden, um Pods und bereitzustellen. ReplicaSets A ReplicaSet definiert, wie viele Instanzen eines Pods gleichzeitig ausgeführt werden sollen. Obwohl Sie einen ReplicaSet direkt ausführen können, ist es üblich, Replikate direkt in einem Deployment auszuführen, um zu definieren, wie viele Replikate eines Pods gleichzeitig ausgeführt werden sollen.

  • Zustandsbehaftete Anwendungen – Bei einer zustandsbehafteten Anwendung sind die Identität des Pods und die Reihenfolge, in der die Pods gestartet werden, wichtig. Diese Anwendungen benötigen einen stabilen persistenten Speicher und müssen auf konsistente Weise bereitgestellt und skaliert werden. Um eine statusbehaftete Anwendung in Kubernetes bereitzustellen, können Sie verwenden. StatefulSets Ein Beispiel für eine Anwendung, die normalerweise als ausgeführt wird, StatefulSet ist eine Datenbank. In einer StatefulSet könnten Sie Replikate, den Pod und seine Container, zu mountende Speichervolumes und Speicherorte im Container, an denen Daten gespeichert werden, definieren. Ein Beispiel für eine Datenbank, die als bereitgestellt wird, finden Sie unter Ausführen einer replizierten Stateful-Anwendung. ReplicaSet

  • Anwendungen pro Knoten – Es kann vorkommen, dass Sie eine Anwendung auf jedem Knoten in Ihrem Kubernetes-Cluster ausführen möchten. Beispielsweise könnte Ihr Rechenzentrum die Ausführung einer Überwachungsanwendung oder eines bestimmten Fernzugriffs auf jedem Computer verlangen. Für Kubernetes können Sie a verwenden, DaemonSetum sicherzustellen, dass die ausgewählte Anwendung auf jedem Knoten in Ihrem Cluster ausgeführt wird.

  • Anwendungen werden vollständig ausgeführt – Es gibt einige Anwendungen, die Sie ausführen möchten, um eine bestimmte Aufgabe abzuschließen. Dazu könnten beispielsweise Anwendungen gehören, die monatliche Statusberichte erstellen oder alte Daten bereinigen. Mit einem Objekt vom Typ Job kann eine Anwendung so eingerichtet werden, dass sie gestartet und ausgeführt wird und nach Abschluss der Aufgabe beendet wird. Mit einem CronJobObjekt können Sie eine Anwendung so einrichten, dass sie zu einer bestimmten Stunde, Minute, an einem bestimmten Tag des Monats, Monats oder Wochentags ausgeführt wird. Dabei wird eine Struktur verwendet, die durch das Linux-Crontab-Format definiert ist.

Anwendungen über das Netzwerk zugänglich machen

Da Anwendungen häufig als eine Reihe von Microservices bereitgestellt werden, die an verschiedene Orte verschoben werden, benötigte Kubernetes eine Möglichkeit, damit diese Microservices einander finden können. Damit andere auf eine Anwendung außerhalb des Kubernetes-Clusters zugreifen können, benötigte Kubernetes außerdem eine Möglichkeit, diese Anwendung über externe Adressen und Ports verfügbar zu machen. Diese netzwerkbezogenen Features werden mit Service- und Ingress-Objekten durchgeführt:

  • Services – Da sich ein Pod zu verschiedenen Knoten und Adressen bewegen kann, kann es für einen anderen Pod, der mit dem ersten Pod kommunizieren muss, schwierig sein, dessen Standort zu ermitteln. Um dieses Problem zu lösen, ermöglicht Kubernetes die Darstellung einer Anwendung als Service. Mit einem Service können Sie einen Pod oder eine Gruppe von Pods mit einem bestimmten Namen identifizieren und dann angeben, welcher Port den Service dieser Anwendung vom Pod aus verfügbar macht und welche Ports eine andere Anwendung verwenden könnte, um diesen Service zu kontaktieren. Ein anderer Pod innerhalb eines Clusters kann einfach einen Service nach Namen anfordern und Kubernetes leitet diese Anforderung an den richtigen Port für eine Instance des Pods weiter, auf dem dieser Service ausgeführt wird.

  • Ingress – Ingress ermöglicht es, Anwendungen, die durch Kubernetes-Services dargestellt werden, für Clients außerhalb des Clusters verfügbar zu machen. Zu den grundlegenden Features von Ingress gehören ein Load Balancer (verwaltet von Ingress), der Ingress-Controller und Regeln für die Weiterleitung von Anfragen vom Controller an den Service. Es gibt mehrere Ingress-Controller, aus denen Sie mit Kubernetes auswählen können.

Nächste Schritte

Das Verständnis der grundlegenden Kubernetes-Konzepte und ihrer Beziehung zu Amazon EKS wird Ihnen dabei helfen, sowohl die Amazon-EKS-Dokumentation als auch die Kubernetes-Dokumentation zu durchsuchen, um die Information zu finden, die Sie für die Verwaltung von Amazon-EKS-Clustern und das Bereitstellen von Workloads in diesen Clustern benötigen. Um mit der Nutzung von Amazon EKS zu beginnen, wählen Sie eine der folgenden Optionen aus: