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
… 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.
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.
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.
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.
