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.
Stellen Sie Amazon EKS vor Ort bereit mit AWS Outposts
Sie können Amazon EKS verwenden, um lokale Kubernetes-Anwendungen auf Outposts auszuführen. AWS Sie können Amazon EKS auf Outposts folgendermaßen bereitstellen:
-
Erweiterte Cluster — Führen Sie die Kubernetes-Steuerebene in einer AWS Region und Knoten in Ihrem Outpost aus.
-
Lokale Cluster – Führen Sie die Kubernetes-Steuerebene und Knoten in Ihrem Outpost aus.
Für beide Bereitstellungsoptionen wird die Kubernetes-Steuerebene vollständig von AWS verwaltet. Sie können dieselben Amazon-EKS-APIs, -Tools und -Konsolen verwenden, die Sie in der Cloud zum Erstellen und Ausführen von Amazon EKS auf Outposts verwenden.
Das folgende Diagramm zeigt diese Optionen für die Bereitstellung.
Wann die einzelnen Bereitstellungsoptionen verwendet werden sollten
Sowohl lokale als auch erweiterte Cluster sind allgemeine Bereitstellungsoptionen und können für eine Reihe von Anwendungen verwendet werden.
Mit erweiterten Clustern können Sie Kapazität auf Ihrem Outpost sparen, da die Kubernetes-Steuerebene in der übergeordneten Region ausgeführt wird. AWS Diese Option ist geeignet, wenn Sie über eine zuverlässige Netzwerkkonnektivität von Ihrem Outpost zur Region verfügen. AWS Es wird empfohlen, Ihre Anwendungen so zu gestalten, dass sie auch bei Netzwerkunterbrechungen in der AWS Region statische Stabilität bieten. Die Art und Weise, wie Kubernetes Netzwerkunterbrechungen zwischen der -Steuerebene und den Knoten handhabt, kann zu Ausfallzeiten der Anwendung führen. Weitere Informationen zum Verhalten von Kubernetes finden Sie unter Planung, Vorkaufsrecht und Bereinigung
Mit lokalen Clustern können Sie den gesamten Amazon-EKS-Cluster lokal auf Outposts ausführen. Mit dieser Option können Sie das Risiko von Ausfallzeiten bei Anwendungen verringern, die durch vorübergehende Netzwerkunterbrechungen in der Cloud entstehen können. Diese Netzwerkunterbrechungen können durch Glasfaserausfälle oder Wetterereignisse verursacht werden. Da der gesamte Amazon-EKS-Cluster lokal auf Outposts ausgeführt wird, bleiben Anwendungen verfügbar. Sie können Cluster-Vorgänge während Netzwerkunterbrechungen mit der Cloud durchführen. Wählen Sie lokale Cluster, wenn Sie einen kontinuierlichen Kubernetes-Betrieb bei Netzwerkunterbrechungen benötigen oder wenn dies aufgrund von Vorschriften zur Datenresidenz erforderlich ist.
Zwei lokale Cluster-Implementierungen
Amazon EKS unterstützt zwei lokale Cluster-Implementierungen auf Outposts-Racks. Ein Outpost ist so konfiguriert, dass er entweder Amazon EBS oder Amazon EC2 EC2-Instance-Speicher als Root-Volume-Typ für die EC2-Instances verwendet, die darauf ausgeführt werden. Die Implementierung, die Amazon EKS für die Steuerungsebene Ihres lokalen Clusters verwendet, hängt von dieser Konfiguration ab:
-
AWS Mit Amazon EBS konfigurierte Outposts. Die Kubernetes-Steuerebene wird in Ihrem AWS Konto auf Ihrem Outpost ausgeführt und besteht aus drei Amazon EC2 EC2-Instances, die von Amazon EBS unterstützt werden.
etcdWeitere Informationen finden Sie unter Erstellen Sie lokale Amazon EKS-Cluster auf AWS Outposts für hohe Verfügbarkeit. -
AWS Outposts, die mit dem EC2-Instance-Speicher konfiguriert sind. Amazon EKS stellt eine aktualisierte lokale Cluster-Architektur bereit. Die Kubernetes-Steuerebene wird auf 6 Amazon EC2 EC2-Instances in einem AWS verwalteten Servicekonto auf Ihrem Outpost ausgeführt, wobei 3 Instanzen für die anderen Komponenten der Kontrollebene reserviert sind
etcdund 3 Instanzen für die anderen Komponenten der Kontrollebene vorgesehen sind. Die Implementierung hat eine größere Parität mit Amazon EKS in der Cloud, folgt dem Amazon EKS Kubernetes-Versionslebenszyklus und unterstützt zusätzliche Funktionen wie Amazon EKS-Add-Ons und Bottlerocket-based Worker-Knoten (zusätzlich zu AL2023). Es ist in allen AWS Standardregionen verfügbar, in denen AWS Outposts verfügbar ist. Weitere Informationen finden Sie unter Überblick über lokale Amazon EKS-Cluster auf AWS Mit EC2-Instance-Speicher konfigurierte Outposts.
Die in den einzelnen Implementierungen verfügbaren Funktionen sind in der folgenden Tabelle zusammengefasst.
Vergleich der Optionen für die Bereitstellung
In der folgenden Tabelle werden die Unterschiede zwischen erweiterten Clustern und den beiden lokalen Clusterimplementierungen verglichen.
| Feature | Erweiterter Cluster | Lokaler Cluster auf Outposts mit EBS | Lokaler Cluster auf Outposts mit EC2-Instanzspeicher |
|---|---|---|---|
|
Ort der Kubernetes-Steuerebene |
AWS Region |
Outpost |
Outpost |
|
Konto der Kubernetes-Steuerebene |
AWS Konto |
Dein AWS Konto |
AWS-verwaltetes Konto |
|
Topologie der Kubernetes-Steuerungsebene |
Cloud-managed |
3 Amazon EC2 EC2-Instances, gestapelt usw. |
6 Amazon EC2 EC2-Instances ( |
|
Speicher auf Kontrollebene |
Cloud-managed |
Amazon EBS |
Amazon-EC2-Instance-Speicher |
|
Regionale Verfügbarkeit |
Siehe Service-Endpunkte |
USA Ost (Ohio), USA Ost (Nord-Virginia),USA West (Nordkalifornien), USA West (Oregon), Asien-Pazifik (Seoul), Asien-Pazifik (Singapur), Asien-Pazifik (Sydney), Asien-Pazifik (Tokio), Kanada (Zentral), Europa (Frankfurt), Europa (Irland), Europa (London), Naher Osten (Bahrain), Naher Osten (Bahrain) und Südamerika (São Paulo) |
Alle AWS Handelsregionen, in denen AWS Outposts verfügbar ist |
|
Kubernetes-Nebenversionen |
Siehe Erfahren Sie mehr über die Plattformversionen von Kubernetes und Amazon EKS für AWS Outposts |
||
|
Plattformversionen |
Sehen Sie sich die Versionen der Amazon EKS-Plattform an |
Siehe Erfahren Sie mehr über die Plattformversionen von Kubernetes und Amazon EKS für AWS Outposts |
Sehen Sie sich die Versionen der Amazon EKS-Plattform an |
|
Outpost-Formfaktoren |
Outpost-Racks |
Outpost-Racks |
Outpost-Racks |
|
Benutzeroberflächen |
AWS-Managementkonsole, AWS CLI, Amazon EKS-API |
AWS-Managementkonsole, AWS CLI, Amazon EKS-API |
AWS-Managementkonsole, AWS CLI, Amazon EKS-API, AWS CloudFormation |
|
Verwaltete Richtlinien |
AmazonEKSClusterPolicy und AWS verwaltete Richtlinie: AmazonEKSServiceRolePolicy |
AmazonEKSLocalOutpostClusterPolicy und AWS verwaltete Richtlinie: AmazonEKSLocalOutpostServiceRolePolicy |
AmazonEKSClusterPolicy und AWS verwaltete Richtlinie: AmazonEKSServiceRolePolicy |
|
Cluster-VPC und Subnetze |
Siehe Erstellen Sie eine VPC und Subnetze für Amazon EKS-Cluster auf AWS Outposts |
||
|
Cluster-Endpunktzugriff |
Öffentlich oder privat oder beides |
Nur privat |
Privat oder öffentlich und privat |
|
Kubernetes-API-Server-Authentifizierung |
AWS Identity and Access Management (IAM), OIDC und Zugriffseinträge |
IAM und |
IAM, OIDC, Zugriffseinträge und |
|
Knotentypen |
Self-managed nur |
Self-managed nur |
Self-managed nur |
|
Knoten-Berechnungstypen |
Amazon EC2 On-Demand |
Amazon EC2 On-Demand |
Amazon EC2 On-Demand |
|
Knoten-Speichertypen |
Amazon EBS |
Amazon EBS |
Lokale NVMe SSD |
|
Amazon EKS-optimierte AMIs |
Amazon Linux, Windows und Bottlerocket |
Amazon Linux |
Amazon Linux und Bottlerocket |
|
IP-Versionen |
Nur |
Nur |
Nur |
|
Add-ons |
Amazon-EKS-Add-Ons oder selbstverwaltete Add-Ons |
Self-managed Add-Ons |
Amazon EKS-Add-Ons (validierte Liste) oder selbstverwaltete Add-Ons |
|
Standard-Container-Netzwerkschnittstelle |
Amazon-VPC-CNI-Plugin für Kubernetes |
Amazon-VPC-CNI-Plugin für Kubernetes |
Amazon-VPC-CNI-Plugin für Kubernetes |
|
Kubernetes-Steuerebene-Protokolle |
CloudWatch Amazon-Protokolle |
CloudWatch Amazon-Protokolle |
CloudWatch Amazon-Protokolle |
|
|
Cloud-managed |
Customer-managed ( |
Verwaltet von Amazon EKS |
|
Lastausgleich |
Verwenden Sie den AWS Load Balancer Controller nur zum Bereitstellen von Application Load Balancern (keine Network Load Balancer) |
Verwenden Sie den AWS Load Balancer Controller nur zum Bereitstellen von Application Load Balancern (keine Network Load Balancer) |
Verwenden Sie den AWS Load Balancer Controller nur zum Bereitstellen von Application Load Balancern (keine Network Load Balancer) |
|
Secrets-Umschlagverschlüsselung |
Wird unterstützt, siehe Verschlüsselung von Kubernetes-Geheimnissen mit KMS in vorhandenen Clustern |
Nicht unterstützt |
Nicht unterstützt |
|
IAM-Rollen für Dienstkonten (IRSA) |
Wird unterstützt, siehe IAM-Rollen für Servicekonten |
Nicht unterstützt |
Unterstützt (erfordert Konnektivität mit der AWS Region; nicht verfügbar bei Netzwerkunterbrechungen) |
|
EKS Pod Identity |
Wird unterstützt, siehe Erfahren Sie, wie EKS Pod Identity Pods Zugriff gewährt auf AWS service |
Nicht unterstützt |
Unterstützt (erfordert Konnektivität mit der AWS Region; nicht verfügbar bei Netzwerkunterbrechungen) |
|
Fehlerbehebung |
Siehe Beheben von Problemen mit Amazon-EKS-Clustern und -Knoten |
Siehe Problembehandlung bei lokalen Amazon EKS-Clustern auf AWS Outposts |
Wichtig
-
Durch die Erstellung eines lokalen Clusters auf einem RAM-shared Outpost wird die Steuerungsebene des Clusters dem physischen Zugriff des Outpost-Besitzers unterstellt
-
Im EC2-Instance-Speicher hängen Outposts, IRSA und EKS Pod Identity von AWS STS in der Region ab. AWS Bei Netzwerkunterbrechungen können Workloads, die IRSA oder Pod Identity verwenden, keine neuen Anmeldeinformationen abrufen. Weitere Informationen finden Sie unter Bereiten Sie lokale Amazon EKS-Cluster vor auf AWS Outposts, die mit EC2-Instance-Speicher für Netzwerkunterbrechungen konfiguriert sind.
Themen
