Amazon-EKS-Knoten

Ein Kubernetes-Knoten ist ein Computer, die containerisierte Anwendungen ausführt. Jeder Knoten umfasst die folgenden Komponenten:

• Container-Laufzeit – Software, die für den Betrieb der Container verantwortlich ist.

• kubelet – Stellt sicher, dass die Container fehlerfrei sind und innerhalb ihres zugeordneten Pod ausgeführt werden.

• kube-proxy – Behält die Netzwerkregeln bei, die die Kommunikation mit Ihren Pods ermöglichen.

Weitere Informationen finden Sie unter Knoten in der Kubernetes-Dokumentation.

Ihr Amazon-EKS-Cluster kann Pods für eine beliebige Kombination von selbstverwalteten Knoten, von Amazon EKS verwalteten Knotengruppen und AWS Fargate planen. Weitere Informationen zu Knoten, die in Ihrem Cluster bereitgestellt werden, finden Sie unter Anzeigen der Kubernetes-Ressourcen.

Wichtig

AWS Fargate mit Amazon EKS ist in AWS GovCloud (USA-Ost) und AWS GovCloud (US-West) nicht verfügbar.

Anmerkung

Die Knoten müssen sich in derselben VPC wie die Subnetze befinden, die Sie beim Erstellen des Clusters ausgewählt haben. Die Knoten müssen sich jedoch nicht in denselben Subnetzen befinden.

Die folgende Tabelle enthält mehrere Kriterien, die bei der Entscheidung ausgewertet werden müssen, welche Optionen Ihren Anforderungen am besten entsprechen. Diese Tabelle enthält keine verbundenen Knoten, die außerhalb von Amazon EKS erstellt wurden, die nur eingesehen werden können.

Anmerkung

Bottlerocket weist einige spezifische Unterschiede zu den allgemeinen Informationen in dieser Tabelle auf. Weitere Informationen zu Bottlerocket finden Sie in der Dokumentation zu GitHub.

Kriterien	EKS-verwaltete Knotengruppen	Selbstverwaltete Knoten	AWS Fargate
Kann auf AWS Outposts bereitgestellt werden	Nein	Ja	Nein
Kann auf eine AWS Lokale Zone bereitgestellt werden	Nein	Ja – Weitere Informationen dazu finden Sie unter Amazon EKS und AWS Local Zones.	Nein
Kann Container ausführen, die Windows benötigen	Ja	Ja – Ihr Cluster benötigt jedoch immer noch mindestens einen Linux-Knoten (zwei für die Verfügbarkeit empfohlen).	Nein
Kann Container ausführen, die Linux benötigen	Ja	Ja	Ja
Kann Workloads ausführen, die den Inferentia-Chip benötigen	Ja – nur Amazon-Linux-Knoten	Ja – nur Amazon Linux	Nein
Kann Workloads ausführen, die eine GPU benötigen	Ja – nur Amazon-Linux-Knoten	Ja – nur Amazon Linux	Nein
Kann Workloads ausführen, die Arm-Prozessoren benötigen	Ja	Ja	Nein
Kann AWS Bottlerocket ausführen	Ja	Ja	Nein
Pods teilen eine Kernel-Laufzeitumgebung mit anderen Pods	Ja – Alle Ihre Pods auf jedem Ihrer Knoten	Ja – Alle Ihre Pods auf jedem Ihrer Knoten	Nein – Jeder Pod hat einen dedizierten Kernel
Pods teilen CPU, Arbeitsspeicher, Speicher und Netzwerkressourcen mit anderen Pods.	Ja – Kann zu ungenutzten Ressourcen auf jedem Knoten führen	Ja – Kann zu ungenutzten Ressourcen auf jedem Knoten führen	Nein – Jeder Pod hat dedizierte Ressourcen und kann unabhängig voneinander dimensioniert werden, um die Ressourcenauslastung zu maximieren
Pods können mehr Hardware und Speicher verwenden, als in den Pod-Spezifikationen angefordert	Ja – Wenn der Pod mehr Ressourcen benötigt als angefordert und Ressourcen auf dem Knoten verfügbar sind, kann der Pod zusätzliche Ressourcen verwenden.	Ja – Wenn der Pod mehr Ressourcen benötigt als angefordert und Ressourcen auf dem Knoten verfügbar sind, kann der Pod zusätzliche Ressourcen verwenden.	Nein – Der Pod kann jedoch mit einer größeren vCPU und Speicherkonfiguration erneut bereitgestellt werden.
Bereitstellen und Verwalten von Amazon-EC2-Instances	Ja – automatisiert über Amazon EKS, wenn Sie ein für Amazon EKS optimiertes AMI bereitgestellt haben. Wenn Sie ein benutzerdefiniertes AMI bereitgestellt haben, müssen Sie die Instance manuell aktualisieren.	Ja – Für die manuelle Konfiguration oder die Verwendung von Amazon EKS wurden AWS CloudFormation -Vorlagen für die Bereitstellung von Linux (x86)-, Linux (Arm)-, oder Windows-Knoten bereitgestellt.	Nein
Das Betriebssystem von Amazon-EC2-Instances muss gesichert, gewartet und gepatcht werden	Ja	Ja	Nein
Kann Bootstrap-Argumente bei der Bereitstellung eines Knotens bereitstellen, z. B. zusätzliche kubelet-Argumente.	Ja – mithilfe von eksctl oder einer Startvorlage mit einem benutzerdefinierten AMI	Weitere Informationen finden Sie in den Bootstrap-Skript-Nutzungsinformationen auf GitHub.	Nein
IP-Adressen können Pods aus einem anderen CIDR-Block als der dem Knoten zugewiesenen IP-Adresse zuweisen.	Ja – Verwenden einer Startvorlage mit einem benutzerdefinierten AMI. Weitere Informationen finden Sie unter Anpassen verwalteter Knoten mit Startvorlagen.	Ja – Weitere Informationen dazu finden Sie unter Benutzerdefinierte Netzwerke für Pods.	Nein
SSH im Knoten nicht möglich	Ja	Ja	Nein – Es gibt kein Knoten-Host-Betriebssystem für SSH.
Kann Ihr eigenes benutzerdefiniertes AMI auf Knoten bereitstellen	Ja – Verwenden eines Startvorlage	Ja	Nein
Kann Ihr eigenes benutzerdefiniertes CNI auf Knoten bereitstellen	Ja – Verwenden eines Startvorlage mit einem benutzerdefinierten AMI	Ja	Nein
Knoten-AMI muss selbst aktualisiert werden	Ja – Wenn Sie ein für Amazon EKS optimiertes AMI bereitgestellt haben, werden Sie in der Amazon-EKS-Konsole benachrichtigt, wenn Aktualisierungen verfügbar sind. Sie können die Aktualisierung mit einem Klick in der Konsole durchführen. Wenn Sie ein benutzerdefiniertes AMI bereitgestellt haben, werden Sie in der Amazon-EKS-Konsole nicht benachrichtigt, wenn Aktualisierungen verfügbar sind. Sie müssen die Aktualisierung selbst durchführen.	Ja – Verwenden anderer Tools als der Amazon-EKS-Konsole. Dies liegt daran, dass selbstverwaltete Knoten nicht mit der Amazon-EKS-Konsole verwaltet werden können.	Nein
Muss die Kubernetes-Version des Knotens selbst aktualisieren	Ja – Wenn Sie ein für Amazon EKS optimiertes AMI bereitgestellt haben, werden Sie in der Amazon-EKS-Konsole benachrichtigt, wenn Updates verfügbar sind. Sie können die Aktualisierung mit einem Klick in der Konsole durchführen. Wenn Sie ein benutzerdefiniertes AMI bereitgestellt haben, werden Sie in der Amazon-EKS-Konsole nicht benachrichtigt, wenn Aktualisierungen verfügbar sind. Sie müssen die Aktualisierung selbst durchführen.	Ja – Verwenden anderer Tools als der Amazon-EKS-Konsole. Dies liegt daran, dass selbstverwaltete Knoten nicht mit der Amazon-EKS-Konsole verwaltet werden können.	Nein – Sie verwalten keine Knoten.
Kann Amazon-EBS-Speicher mit Pods verwenden	Ja	Ja	Nein
Kann Amazon EFS Speicher mit Pods verwenden	Ja	Ja	Ja
Kann Speicher Amazon FSx für Lustre mit Pods verwenden	Ja	Ja	Nein
Kann Network Load Balancer für Services verwenden	Ja	Ja	Ja, wenn Sie die Erstellen eines Network Load Balancers
Pods können in einem öffentlichen Subnetz ausgeführt werden	Ja	Ja	Nein
Kann einzelnen Pods verschiedene VPC -Sicherheitsgruppen zuweisen	Ja – nur Linux-Knoten	Ja – nur Linux-Knoten	Ja
Kann Kubernetes DaemonSets ausführen	Ja	Ja	Nein
Unterstützen von HostPort und HostNetwork im Pod-Manifest	Ja	Ja	Nein
AWS-Region Verfügbarkeit	Alle von Amazon EKS unterstützten Regionen	Alle von Amazon EKS unterstützten Regionen	Einige von Amazon EKS unterstützte Regionen
Kann Container auf Amazon-EC2-Dedicated-Hosts ausführen	Ja	Ja	Nein
Preise	Die Kosten für Amazon-EC2-Instance, auf der mehrere Pods ausgeführt werden. Weitere Informationen dazu finden Sie unter Amazon EC2 – Preise.	Die Kosten für Amazon-EC2-Instance, auf der mehrere Pods ausgeführt werden. Weitere Informationen dazu finden Sie unter Amazon EC2 – Preise.	Kosten für eine individuelle Fargate-Speicher- und CPU-Konfiguration. Jeder Pod hat seine eigenen Kosten. Weitere Informationen finden Sie unter AWS Fargate Preise.