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.
Bewährte Verfahren für Zuverlässigkeit
Dieser Abschnitt enthält Anleitungen dazu, wie Sie Workloads, die auf EKS ausgeführt werden, widerstandsfähig und hochverfügbar machen
Verwendung dieses Leitfadens
Dieses Handbuch richtet sich an Entwickler und Architekten, die hochverfügbare und fehlertolerante Dienste in EKS entwickeln und betreiben möchten. Der Leitfaden ist zur leichteren Nutzung in verschiedene Themenbereiche gegliedert. Jedes Thema beginnt mit einem kurzen Überblick, gefolgt von einer Liste mit Empfehlungen und bewährten Methoden für die Zuverlässigkeit Ihrer EKS-Cluster.
Einführung
Die bewährten Verfahren zur Zuverlässigkeit von EKS wurden den folgenden Themen zugeordnet:
-
Anwendungen
-
Steuerebene
-
Datenebene
Was macht ein System zuverlässig? Wenn ein System trotz Änderungen in seiner Umgebung im Laufe der Zeit konsistent funktioniert und die Anforderungen erfüllt, kann es als zuverlässig bezeichnet werden. Um dies zu erreichen, muss das System Fehler erkennen, sich automatisch selbst reparieren und in der Lage sein, je nach Bedarf zu skalieren.
Kunden können Kubernetes als Grundlage für den zuverlässigen Betrieb unternehmenskritischer Anwendungen und Dienste verwenden. Doch neben der Berücksichtigung containerbasierter Anwendungsdesignprinzipien ist für die zuverlässige Ausführung von Workloads auch eine zuverlässige Infrastruktur erforderlich. In Kubernetes umfasst die Infrastruktur die Steuerungsebene und die Datenebene.
EKS bietet eine Kubernetes-Steuerungsebene in Produktionsqualität, die so konzipiert ist, dass sie hochverfügbar und fehlertolerant ist.
In EKS ist AWS für die Zuverlässigkeit der Kubernetes-Steuerungsebene verantwortlich. EKS führt die Kubernetes-Steuerungsebene in drei Verfügbarkeitszonen in einer AWS-Region aus. Es verwaltet automatisch die Verfügbarkeit und Skalierbarkeit der Kubernetes-API-Server und des etcd-Clusters.
Die Verantwortung für die Zuverlässigkeit der Datenebene teilen sich Sie, der Kunde, und AWS. EKS bietet vier Worker-Knoten-Optionen für die Bereitstellung der Kubernetes-Datenebene.
EKS Auto Mode, die am häufigsten verwaltete Option, kümmert sich um die Bereitstellung, Skalierung und Aktualisierung der Datenebene sowie um verwaltete Rechen-, Netzwerk- und Speicherfunktionen. AMIs für den automatischen Modus werden regelmäßig veröffentlicht und Cluster werden automatisch auf das neueste AMI aktualisiert, um CVE-Fixes und Sicherheitspatches bereitzustellen. Sie haben die Möglichkeit, zu kontrollieren, wann dies geschieht, indem Sie die Störungskontrolle in Ihrem Auto-Modus NodePools konfigurieren.
Fargate kümmert sich um die Bereitstellung und Skalierung der Datenebene, indem es einen Pod pro Knoten ausführt. Die dritte Option, verwaltete Knotengruppen, kümmert sich um die Bereitstellung und Aktualisierung der Datenebene. Und schließlich sind selbstverwaltete Knoten die am wenigsten verwaltete Option für die Datenebene. Je mehr AWS-managed Datenebenen Sie verwenden, desto weniger Verantwortung tragen Sie.
Verwaltete Knotengruppen automatisieren die Bereitstellung und das Lebenszyklusmanagement von EC2-Knoten. Sie können die EKS-API (mithilfe der EKS-Konsole, der AWS-API, der AWS-CLICloudFormation, Terraform odereksctl) verwenden, um verwaltete Knoten zu erstellen, zu skalieren und zu aktualisieren. Auf verwalteten Knoten werden EKS-optimized Amazon Linux 2 EC2-Instances in Ihrem Konto ausgeführt, und Sie können benutzerdefinierte Softwarepakete installieren, indem Sie den SSH-Zugriff aktivieren. Wenn Sie verwaltete Knoten bereitstellen, werden diese als Teil einer EKS-managed Auto Scaling-Gruppe ausgeführt, die sich über mehrere Availability Zones erstrecken kann. Sie steuern dies über die Subnetze, die Sie bei der Erstellung verwalteter Knoten angeben. EKS kennzeichnet verwaltete Knoten außerdem automatisch, sodass sie mit Cluster Autoscaler verwendet werden können.
Amazon EKS folgt dem Modell der gemeinsamen Verantwortlichkeit für CVEs und Sicherheitspatches in verwalteten Knotengruppen. Da auf verwalteten Knoten die EKS-optimized Amazon-AMIs ausgeführt werden, ist Amazon EKS dafür verantwortlich, gepatchte Versionen dieser AMIs zu erstellen, wenn Fehler behoben werden. Sie sind jedoch dafür verantwortlich, diese gepatchten AMI-Versionen für Ihre verwalteten Knotengruppen bereitzustellen.
EKS verwaltet auch die Aktualisierung der Knoten, obwohl Sie den Aktualisierungsvorgang einleiten müssen. Der Vorgang der Aktualisierung des verwalteten Knotens wird in der EKS-Dokumentation erläutert.
Wenn Sie selbstverwaltete Knoten ausführen, können Sie Amazon EKS-optimized Linux AMI verwenden, um Worker-Knoten zu erstellen. Sie sind dafür verantwortlich, das AMI und die Knoten zu patchen und zu aktualisieren. Es hat sich bewährt eksctl CloudFormation, oder Infrastruktur als Code-Tools für die Bereitstellung selbstverwalteter Knoten zu verwenden, da Sie so ein Upgrade selbstverwalteter Knoten leicht durchführen können. Erwägen Sie, bei der Aktualisierung von Worker-Knoten auf neue Knoten zu migrieren, da der Migrationsprozess die alte Knotengruppe beeinträchtigt NoSchedule und die Knoten entleert, nachdem ein neuer Stack bereit ist, die vorhandene Pod-Arbeitslast zu akzeptieren. Sie können jedoch auch ein direktes Upgrade von selbstverwalteten Knoten durchführen.
Modell der geteilten Verantwortung — Fargate
Modell der geteilten Verantwortung - MNG
Dieses Handbuch enthält eine Reihe von Empfehlungen, anhand derer Sie die Zuverlässigkeit Ihrer EKS-Datenebene, der Kubernetes-Kernkomponenten und Ihrer Anwendungen verbessern können.
Feedback
Dieser Leitfaden wird am veröffentlicht, GitHub um direktes Feedback und Vorschläge aus der breiteren EKS/Kubernetes Community zu sammeln. Wenn Sie eine bewährte Methode haben, die wir Ihrer Meinung nach in den Leitfaden aufnehmen sollten, reichen Sie bitte ein Problem ein oder reichen Sie eine PR im GitHub Repository ein. Wir beabsichtigen, den Leitfaden regelmäßig zu aktualisieren, wenn dem Service neue Funktionen hinzugefügt werden oder wenn sich eine neue bewährte Methode entwickelt.