Container-Orchestrierung mit AWS EKS, Teil 3 Kubernetes Worker-Knoten unter Amazon EKS

Der Amazon Elastic Kubernetes Service, kurz EKS, stellt benötigte Worker Nodes zwar nicht automatisch bereit, wie wir im zweiten Teil dieses Tutorials erfahren haben. Hierfür gibt es aber passende CloudFormation-Vorlagen, die wir uns im Folgenden genauer anschauen.

Sofern noch nicht geschehen, muss am Kommando-Host zunächst eine kubeconfig-Datei (~.kube/config) erstellt oder (falls schon vorhanden) aktualisiert werden. Das klappt wie in Teil 2 dieses EKS-Tutorials beschrieben mit …

aws eks –region <region> update-kubeconfig –name <cluster_name>

Anmerkung: Der Befehl wird nur erfolgreich ausgeführt, wenn dem jeweiligen Konto die IAM-Berechtigung „eks:DescribeCluster“ für den im Befehl angegebenen Cluster-Namen zugewiesen wurde, wie in Teil 2 beschrieben. Anschließend sollte ein Testen der Konfiguration mit …

kubectl get svc

Testen der Konfiguration und Anzeigen der Cluster-IP.

… erfolgreich verlaufen und wie im vorangestellten Bild zu sehen die Cluster-IP auswerfen. Sollte die Fehlermeldung „aws-iam-authenticator: executable file not found in $PATH“ auftreten, ist kubectl nicht passend für EKS konfiguriert.

IAM-Rolle

Da nun VPC und Kubernetes-Control-Plane existieren können wir uns dem Starten und Einrichten der Worker-Knoten widmen. Dabei ruft der kubelet-Daemon jedes Worker-Knoten jeweils die AWS-APIs im Namen des IAM-Users auf.

Konkret erhalten die Worker-Knoten zugehörige Richtlinien und Berechtigungen für diese API-Aufrufe über das zugewiesene Instance-Profil (IAM-Rolle). Daher muss man vor dem Starten der Worker-Knoten und deren Registrierung in einem EKS-Cluster solche IAM-Rollen erstellt haben. Sie werden dann vom Worker-Knoten beim Start benutzt. AWS empfiehlt, für jeden Cluster eine neue Worker-Node-IAM-Rolle zu erstellen, damit sich nicht versehentlich ein Knoten an einem anderen Cluster authentifiziert, zu dem er gar nicht gehört.

AWS empfiehlt, für jeden Cluster eine eigene Worker-Node-IAM-Rolle zu erstellen.

Man kann die Rolle wie in Teil 1 unseres EKS-Tutorials beschrieben komfortabel in der IAM Management Console erstellen. Als „Service-Entität“ wählen wir „EC2“ und weisen dieser die drei AWS-verwalteten Richtlinien-Dokumente „AmazonEKSWorkerNodePolicy“, „AmazonEKS_CNI_Policy“ und „AmazonEC2ContainerRegistryReadOnly“ zu.

Wir wählen „EC2“ als Service-Entität und weisen ihr unsere drei AWS-verwalteten Richtlinien-Dokumente zu.

Worker-Nodes

Nun können wir uns der EKS-Cluster-Console zuwenden. Der EKS-Cluster-Control-Plane sollte inzwischen erfolgreich erstellt worden sein und den Status „Active“ zeigen.

nser EKS-Cluster-Control-Plane zeigt den Status „Active“.

Folgt man dem Link mit dem Cluster-Namen, findet man die Detail-Informationen zum Cluster. Diese Informationen sowie die darauf folgenden Konfiguration haben wir in der folgenden Bildergalerie gesammelt.