HAQM EKS – Häufig gestellte Fragen

HAQM-EKS-Automatikmodus ist für neue und bestehende EKS-Cluster mit Kubernetes 1.29+ in allen AWS-Regionen verfügbar, in denen EKS verfügbar ist, mit Ausnahme der Regionen AWS GovCloud (USA) und China. Verwenden Sie zunächst einfach die EKS-API, die AWS-Konsole, eksctl oder Ihr bevorzugtes Infrastructure-as-Code-Tool (IaC), um EKS-Automatikmodus in einem neuen oder vorhandenen Cluster zu aktivieren, und geben Sie die IAM-Rolle an, die die von AWS verwaltete Recheninfrastruktur verwenden soll. Standardmäßig erstellt der EKS-Automatikmodus in Ihrem Cluster Allzweckkonfigurationen zur Rechenskalierung nach bewährten Methoden, sodass Sie schnell mit der Ausführung von Anwendungen beginnen können. Für eine umfassendere Anpassung können Sie diese Standardeinstellungen deaktivieren und mithilfe der Kubernetes-API in Ihrem Cluster zusätzliche Rechenskalierungs- und Infrastrukturkonfigurationen erstellen.

Mithilfe des HAQM EKS Auto Mode erweitert AWS seine Verantwortung im Vergleich zur kundenverwalteten AWS-Infrastruktur in EKS-Clustern. Neben dem Betrieb der Kubernetes-Cluster-Steuerungsebene mit aktiviertem EKS-Automatikmodus übernimmt AWS auch die Verantwortung für die Sicherung, Konfiguration und Verwaltung der AWS-Infrastruktur in EKS-Clustern, die Ihre Anwendungen ausführen müssen. Zu diesem Zweck unterliegen AWS-Infrastrukturressourcen, wie EC2-Instances, in EKS-Clustern, die den EKS-Auto-Modus verwenden, im Vergleich zu ihren kundenseitig verwalteten Gegenstücken Einschränkungen. Sie können beispielsweise keine Remote-Verbindung über SSH oder SSM herstellen, die Instance-IAM-Rolle ändern, das Root-Volume ersetzen oder zusätzliche elastische Netzwerkschnittstellen an EC2-Instances anhängen, die von EKS Auto Mode verwaltet werden, da dies die Fähigkeit von AWS einschränken würde, sie zu sichern und zu verwalten.

HAQM EKS mit AWS Fargate bleibt eine Option für Kunden, die EKS ausführen möchten, aber HAQM-EKS-Automatikmodus ist in Zukunft der empfohlene Ansatz. EKS-Automatikmodus ist vollständig Kubernetes-konform und unterstützt alle Upstream-Kubernetes-Primitive und Plattformtools wie Istio, die Fargate nicht unterstützen kann. EKS-Autmatikmodus unterstützt auch alle EC2-Laufzeit-Kaufoptionen, einschließlich GPU- und Spot-Instances, vollständig, sodass Kunden ausgehandelte EC2-Rabatte und andere Sparmechanismen nutzen können. Diese Funktionen sind nicht verfügbar, wenn EKS mit Fargate verwendet wird. Darüber hinaus ermöglicht EKS-Automatikmodus Kunden, dasselbe Isolationsmodell wie Fargate zu erreichen und dabei die standardmäßigen Kubernetes-Planungsfunktionen zu verwenden, um sicherzustellen, dass auf jeder EC2-Instance ein einziger Anwendungscontainer ausgeführt wird. Durch die Einführung des HAQM EKS-Automatikmodus können Kunden alle Vorteile der Ausführung von Kubernetes auf AWS nutzen – einer vollständig Kubernetes-konformen Plattform, die die Flexibilität bietet, die gesamte Bandbreite der EC2- und Kaufoptionen zu nutzen und gleichzeitig die Benutzerfreundlichkeit und die Abstraktion vom Infrastrukturmanagement beizubehalten, die Fargate bietet.

HAQM-EKS-Automatikmodus trägt auf drei Arten zur Verbesserung der Sicherheit Ihrer EKS-Cluster bei: 1/ Die von EKS-Automatikmodus erstellte AWS-verwaltete Infrastruktur ist gemäß den bewährten AWS-Sicherheitsmethoden konfiguriert und gemäß den Level-1-Benchmarks des Center for Internet Security (CIS) gehärtet. Dazu gehören: kein Fernzugriff, ein unveränderliches Root-Dateisystem und obligatorische Zugriffskontrollen auf Kernel-Ebene. 2/ Die AWS-verwalteten EC2-Instances von EKS Auto Mode werden automatisch mit den neuesten Sicherheits- und Bugfixes aktualisiert, sobald sie verfügbar sind. Wenn möglich, werden diese Patches direkt installiert, ohne dass laufende Anwendungen unterbrochen oder Instances ausgetauscht werden. 3/ Standardmäßig legt EKS Auto Mode eine maximale Lebensdauer von 14 Tagen für seine AWS-verwalteten EC2-Instances fest, sodass Sie branchenweite Best Practices für Sicherheit und Compliance einhalten können. Wenn Ihr Anwendungsfall eine kürzere oder längere Instance-Lebensdauer erfordert, können Sie EKS-Automatikmodus mit einer Dauer konfigurieren, die Ihren Anforderungen entspricht, bis zu einem Maximum von 21 Tagen.

Ja, nach dem Upgrade der EKS-Steuerungsebene auf eine neue Kubernetes-Version werden neue Instances, die von EKS-Automatikmodus gestartet wurden, aufgrund von Anwendungsüberlastungen mit der neuesten Kubernetes-Software ausgeführt, die der Version der Steuerungsebene entspricht. Gleichzeitig werden bestehende Instances schrittweise mit der Kubernetes-Software für die neue Kubernetes-Version aktualisiert. In Kombination mit der standardmäßigen maximalen Lebensdauer von 14 Tagen für Instances, die im EKS-Automatikmodus gestartet werden, bedeutet dies, dass Ihr Cluster standardmäßig vollständig und automatisch aktualisiert wird, spätestens 14 Tage nach dem Upgrade der Kubernetes-Version Ihres EKS-Clusters.

HAQM-EKS-Automatikmodus bietet integrierte und verwaltete Versionen wichtiger Kubernetes-Funktionen wie Datenverarbeitungs-, Speicher- und Netzwerkfunktionen. Dazu gehören verwaltete Versionen von: 1/ dem Agent von EKS-Automatikmodus, der die Sicherheits- und Instance-Verwaltung erleichtert, 2/ die Containerd -Container-Laufzeit, eine grundlegende Komponente, die es Kubernetes ermöglicht, Container effektiv auszuführen, 3/ das Kubelet, das den Lebenszyklus und den Zustand der Kubernetes-Pods auf jeder Satenverarbeitungs-Instance verwaltet, 4/ ein Netzwerk-Proxy, der Cluster-Routing ermöglicht, 5/ eine verwaltete, Upstream-kompatible Karpenter-Steuerung, 6/ der Controller für HAQM EBS Container Storage Interface (CSI) für Speicher, 7/ eine verwaltete Version des AWS VPC Container Network Interface (CNI) für IP-Adressverwaltung, Pod-Netzwerke und Netzwerkrichtlinien, 8/ CoreDNS für Cluster-Serviceerkennung, 9/ und AWS Load Balancer Controller für die Orchestrierung externer Load Balancer Controller.

Mit HAQM EKS Auto Mode müssen Sie bestimmte EKS-Add-Ons wie VPC CNI, CoreDNS, Kube-Proxy und den CloudWatch Observability Agent nicht installieren oder verwalten. Mit EKS Auto Mode enthält Ihr EKS-Cluster integrierte Versionen der Funktionen, die diese Add-Ons bieten. Wenn Sie jedoch immer noch Workloads haben, die noch nicht in EKS Auto Mode migriert wurden, müssen Sie diese EKS-Add-Ons weiterhin für sie verwenden. Andere EKS-Add-Ons, außer denen, die durch die integrierten Funktionen von EKS-Automatikmodus ersetzt wurden, können mithilfe des EKS-Automatikmodus auf Clustern ausgeführt werden.

Ja, die von EKS Auto Mode gestarteten verwalteten EC2-Instances können standardmäßig mit der EC2 DescribeInstances API oder der AWS-Konsole angezeigt werden. Da diese Instances von AWS verwaltet werden, sind die Aktionen, die Sie mit den EC2-APIs ergreifen können, auf diejenigen beschränkt, die sich nicht auf die Fähigkeit von EKS auswirken, seine erweiterten betrieblichen Aufgaben zu erfüllen. Standardmäßig verfügt der EKS-Automatikmodus über allgemeine Rechenkonfigurationen, die sich für gängige Anwendungsfälle gut eignen. Bei Bedarf können Sie die von EKS-Automatikmodus gestarteten EC2-Instances anpassen. Änderungen an den Laufzeitkonfigurationseinstellungen der EKS-Automatikmodus-Instances können mithilfe der Node-Class-Kubernetes-API von EKS-Automatikmodus vorgenommen werden.

Ja. Compute Savings Plans und Reserved Instances werden automatisch angewendet, wenn berechtigte EC2-Instances gestartet werden. Weitere Informationen erhalten Sie auf der Seite mit den Preisangaben.

Die Kubernetes-Funktionen des HAQM-EKS-Automatikmodus werden über eine Reihe integrierter Controller bereitgestellt, die eine Vielzahl von Kubernetes-Ereignissen ausgeben, anhand derer ihr Verhalten verstanden werden kann.