EKS-Control-Plane und Worker-Nodes

Amazon Elastic Kubernetes Service (EKS) ist ein vollständig verwalteter Kubernetes-Service, der Ihnen die Installation, den Betrieb und die Wartung der Kubernetes-Steuerungsebene abnimmt. AWS betreibt, skaliert und aktualisiert die Steuerungsebene über mehrere Availability Zones hinweg und stellt so einen hochverfügbaren Cluster-Endpunkt bereit. Sie konzentrieren sich vollständig auf die Bereitstellung und Verwaltung Ihrer Anwendungs-Workloads.

Die EKS-Steuerungsebene besteht aus API-Server, etcd, Controller Manager und Scheduler – allesamt von AWS verwaltet. Diese Komponenten laufen in AWS-eigenen Konten, sodass Sie sich niemals per SSH mit ihnen verbinden. AWS garantiert eine 99,95-%-SLA für den EKS-API-Endpunkt und ersetzt fehlerhafte Knoten der Steuerungsebene automatisch. Für die Steuerungsebene zahlen Sie eine feste Gebühr pro Cluster und Stunde.

Sie können einen EKS-Cluster über die AWS-Konsole, eksctl oder CloudFormation erstellen. Der Cluster benötigt eine VPC mit Subnetzen in mindestens zwei AZs sowie eine IAM-Rolle, die der Kubernetes-Steuerungsebene Aufrufe von AWS-APIs erlaubt. Nach der Erstellung ist der Cluster-Endpunkt eine HTTPS-URL, die Sie in Ihrer kubeconfig konfigurieren.

Nach der Erstellung des Clusters aktualisieren Sie Ihre lokale kubeconfig, damit kubectl weiß, wie der EKS-API-Server erreichbar ist. Die AWS CLI erzeugt den erforderlichen Eintrag automatisch. Der EKS-API-Server verwendet AWS IAM zur Authentifizierung – Ihr IAM-Benutzer oder Ihre IAM-Rolle wird über die aws-auth-ConfigMap einer Kubernetes-RBAC-Identität zugeordnet.

Verwaltete Node-Gruppen ermöglichen es AWS, EC2-Worker-Nodes in Ihrem Auftrag bereitzustellen, zu registrieren und über ihren gesamten Lebenszyklus zu verwalten. Wenn Sie eine Aktualisierung oder einen Austausch anfordern, leert EKS automatisch die Pods, ersetzt die Instance und registriert sie erneut – alles ohne manuellen Eingriff. Verwaltete Node-Gruppen verwenden im Hintergrund Auto Scaling Groups. Dadurch erhalten Sie Kontrolle über minimale, maximale und gewünschte Kapazität sowie eine Integration mit Cluster Autoscaler.

Bei selbstverwalteten Node-Gruppen starten Sie EC2-Instances selbst (über CloudFormation oder Terraform) und registrieren sie im EKS-Cluster, indem Sie das Bootstrap-Skript ausführen. Das bietet maximale Flexibilität – Sie können benutzerdefinierte AMIs, Instance-Typen mit GPU oder stark angepasste Kernel-Konfigurationen verwenden –, aber Sie sind vollständig für das Patchen, Leeren und Ersetzen der Nodes verantwortlich.

Jeder Worker-Node muss mit einem EC2-Instance-Profil ausgeführt werden, dem drei von AWS verwaltete Richtlinien zugewiesen sind: AmazonEKSWorkerNodePolicy, AmazonEKS_CNI_Policy und AmazonEC2ContainerRegistryReadOnly. Diese ermöglichen es dem Node, dem Cluster beizutreten, das Pod-Netzwerk mit dem VPC-CNI-Plugin zu verwalten und Images aus ECR abzurufen. Ohne diese Richtlinien können sich Nodes nicht erfolgreich registrieren.

EKS verwendet die aws-auth ConfigMap im Namespace kube-system, um IAM-Benutzer und -Rollen Kubernetes-Benutzernamen und -Gruppen zuzuordnen. Beim Erstellen eines Clusters erhält nur die IAM-Identität des Erstellers automatisch Administratorzugriff. Damit andere Benutzer oder CI/CD-Rollen auf den Cluster zugreifen können, müssen Sie Einträge mit den korrekten Schlüsseln mapRoles oder mapUsers zu dieser ConfigMap hinzufügen.

EKS-Add-ons sind kuratierte, von AWS validierte Softwarekomponenten – beispielsweise VPC CNI, CoreDNS und kube-proxy –, die EKS in Ihrem Auftrag installieren und aktuell halten kann. Wenn Sie die Kubernetes-Version Ihres Clusters aktualisieren, aktualisieren Sie zuerst die Steuerungsebene und anschließend jede verwaltete Node-Gruppe auf die entsprechende Version. EKS unterstützt während des Rollout-Zeitraums eine Abweichung von einer Minor-Version zwischen Steuerungsebene und Nodes.

Der EKS-API-Server-Endpunkt kann als nur öffentlich, nur privat oder als Kombination aus beidem konfiguriert werden. Öffentliche Endpunkte werden durch IAM-Authentifizierung geschützt; bei Endpunkten, die nur privat erreichbar sind, muss Ihre kubeconfig die VPC über VPN oder Direct Connect erreichen können. Sie können außerdem die Envelope-Verschlüsselung von Kubernetes-Secrets im Ruhezustand mithilfe eines AWS-KMS-Schlüssels aktivieren. Dadurch erhalten vertrauliche Konfigurationsdaten eine zusätzliche Schutzschicht.

Der Cluster Autoscaler ist ein Kubernetes-Pod, der nicht planbare Pods überwacht und die Größe der Auto Scaling Groups verwalteter Node-Gruppen automatisch anpasst. Wenn Pods wegen unzureichender Ressourcen nicht eingeplant werden können, skaliert der Cluster Autoscaler aufwärts. Wenn Nodes nicht ausreichend ausgelastet sind und ihre Pods an anderer Stelle neu eingeplant werden können, skaliert er abwärts. Für Aufrufe der EC2-Auto-Scaling-API über IRSA benötigt er IAM-Berechtigungen.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: AWS verwaltet die EKS-Steuerungsebene mit einer SLA von 99,95 %, verwaltete Node-Gruppen ermöglichen es AWS, den Lebenszyklus der Nodes zu übernehmen, während selbst verwaltete Gruppen maximale Anpassungsmöglichkeiten bieten, und die aws-auth ConfigMap ordnet IAM-Identitäten Kubernetes-RBAC für die Zugriffskontrolle des Clusters zu. Als Nächstes sehen wir uns Fargate-Profile für die serverlose Ausführung von Pods an.