Container-Orchestrierung mit AWS EKS, Teil 1 Netzwerk und Rollen für Kubernetes aufsetzen

Der Amazon Elastic Kubernetes Service, kurz EKS, ist einer von zwei verwalteten Container-Cluster-Managern auf AWS. In diesem dreiteiligen Workshop bringen wir eine Container-Anwendung zum Laufen, hierfür beginnen wir mit den Vorbereitungen zum Betrieb eines EKS-Clusters auf AWS.

Im Unterschied zu Amazon ECS stellt EKS einen vollständig verwalteten Kubernetes-Service in der Public Cloud dar. Dieser ist umfassend mit anderen AWS-Services integriert, z. B. Amazon CloudWatch, Auto Scaling Groups, AWS Identity and Access Management (IAM) und Amazon Virtual Private Cloud (VPC).

Vor dem Start mit dem Elastic Kubernetes Service bzw. konkret dem Erstellen eines EKS-Clusters muss der Nutzer eine IAM-Rolle anlegen, die Kubernetes zum Erstellen von AWS-Ressourcen übernehmen kann, etwa wenn später ein Load Balancer im Cluster erstellt werden soll.

 
Die von Amazon empfohlen, betreiben wir die EKS-Worker-Nodes in einem rein privaten Subnetz und machen nur den oder die Load Balancer öffentlich. (Bild: Amazon Web Services)

IAM-Rolle für EKS

Zum Erstellen der IAM-Rolle klickt man in der IAM Console unter „Zugriffsverwaltung / Rollen“ auf „Rolle erstellen“, wählt im Abschnitt „Oder wählen Sie einen Service aus, um seine Anwendungsfälle anzusehen“ den Eintrag „EKS“ und dann bei „Anwendungsfall“ den Eintrag „EKS – Allows EKS to manager clusters on your behalf“.

Als Anwendungsfall für die IAM-Rolle wählen wir „EKS – Allows EKS to manager clusters on your behalf“. (Bild: Drilling / AWS).

Da es sich hier um einen vorkonfigurierten „Anwendungsfall“ handelt, sind auch die passenden Berechtigungen „AmazonEKSClusterPolicy“ und „AmazonEKSServicePolicy“ bereits anhängt. Tags sind zunächst nicht erforderlich und der „Rollenname“ sollte aussagekräftig sein, z. B. „EKSServiceRole“.

Der Name der IAM-Rolle für Kubernetes sollte eindeutig sein. (Bild: Drilling / AWS)

VPC erstellen

Für das Erstellen des Cluster-VPCs stellt AWS dankenswerterweise eine passende CloudFormation-Vorlage auf Amazon S3 zur Verfügung. Diese geht aus Sicherheitsgründen davon aus, dass die Worker-Knoten in private Subnetzen stehen und ausschließlich über ein NAT-Gateway mit dem Internet kommunizieren, etwa zum Bezug von Updates. Ein Wartungs-Zugriff auf Kubernets-Nodes kann dann über Bastion Hosts erfolgen.

Der Zugriff auf die Container-Anwendung erfolgt dann über einen Loadbalancer in einem öffentlichen Subnetz. Der Nutzer muss sich also in der Console nur eine AWS-Region aussuchen, die EKS unterstützt, und dann in der Cloud-Formation-Console beim Erstellen eines Stacks auf das vorhandene Template in Amazon S3 verweisen. 

Hier weiterlesen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.