Container-Orchestrierung mit AWS EKS, Teil 2 Kubernetes Master und Tools für die Steuerebene

Mit dem Amazon Elastic Kubernetes Service, kurz EKS, erhalten AWS-Kunden einen vollständig verwalteten Kubernetes-Service in der Public Cloud. Im zweiten Teil unseres EKS-Workshops geht es um die Bereitstellung der EKS-Steuerebene mit einem oder mehreren Kubernetes-Mastern, API-Servern und kubectl-Clients.

Im ersten Teil dieses Workshops haben wir das Netzwerk und die Berechtigungen für die Kubernetes-Steuerebene vorbereitet. Bevor wir den verwalteten Teil des EKS-Clusters (noch nicht die Worker Nodes) bereitstellen können, müssen wir das Kubernetes-Tools kubectl installieren und uns um die Cluster-Authentifizierung kümmern.

Installieren und Konfigurieren von kubectl für Amazon EKS

Bekanntlich verwendet Kubernetes das CLI-Tool „kubectl“ für die Kommunikation mit dem Cluster-API-Server. AWS-Nutzern zwei Möglichkeiten zum Installieren von kubectl:

Über den Paketmanager des als Verwaltungs-Schnittstelle verwendeten PCs, etwa in Form einer EC2-Instanz. Das Tool ist in den Repositories der meisten Linux-Distributionen enthalten.

Mithilfe der direkt von Amazon EKS angebotenen kubectl-Binaries.

In jedem Fall ist dafür zunächst die AWS-CLI zu installieren und mit den gewünschten IAM-Credentials zu konfigurieren. Allerdings muss die jeweilige Python-Version mindestens 2.7.9 sein, damit die AWS-CLI unsere EKS-Aufrufe sauber unterstützt.

Wer kubectl mit seinen Amazon EKS-Clustern verwenden möchte, muss zudem eine Binärdatei installieren, mit der man das erforderliche Client-Sicherheitstoken für die Cluster-API-Server-Kommunikation erstellen kann. Der zugehörige Befehl „aws eks get-token“ ist mit dem aws-iam-authenticator in Version 1.16.308 für die AWS CLI verfügbar. Dazu später mehr.

Wir verwenden für alle weiteren Schritte eine EC2-Instanz auf AWS mit Amazon Linux als Command-Host; u. a. zum Ausführen von kubectl. Das Installieren von kubectl direkt von AWS kann z. B. für Version 1.14 wie folgt erfolgen. Zuerst laden wir die Binärdatei herunter:

Dann machen wir die Datei ausführbar:

Schließlich kopieren wir die Binärdatei in ein Verzeichnis, das Bestandteil der PATH-Variable ist. Wer bereits vorher eine Version von kubectl installiert hatte, kann die Datei unter $HOME/bin/ als kubectl-Datei ablegen und stellt sicher, dass $HOME/bin in der $PATH-Variablen zuerst vorkommt:

Erstellen des EKS-Clusters

Jetzt sind alle Voraussetzungen zum Erstellen der Steuerebene des EKS-Clusters gegeben. Wir verwenden die jeweils neueste Version von Kubernetes, die in Amazon EKS verfügbar ist, um auch neueste Funktionen verwenden zu können.

Beim Erstellen eines EKS-Clusters wird die IAM-Entität (Benutzer oder Rolle), die den Cluster erstellt, automatisch zur Kubernetes-RBAC-Autorisierungstabelle als Administrator (mittels system:master-Berechtigungen) hinzugefügt. Anfangs kann nur dieser IAM-Benutzer mit kubectl Aufrufe an den Kubernetes-API-Server tätigen.

Nun wechselt man in der AWS Management Console zu EKS. Ab hier ist ein Hinweis auf die Preise angebracht. Während bei den Worker-Nodes ganz normale EC2-Instanzen zugrunde liegen, deren Preise sich nach Anzahl und Größe der Knoten richten, handelt es sich beim EKS-Control-Plane um einen vollständig von AWS verwalteten Dienst, der in Frankfurt mit 0,10 US-Dollar/Stunde berechnet wird.

Verzichtet man auf selbst erstellte EC2-Worker-Nodes zugunsten von AWS Fargate, berechnet AWS die Preise anhand der vCPU- und Arbeitsspeicher-Ressourcen, die für die Zeitdauer des Container-Image-Downloads verwendet werden, bis der Amazon EKS Pod beendet wird, auf Basis der nächsten Sekunde. Es wird immer mindestens 1 Minute berechnet. Im ersten Schritt legt man in der EKS Console einen Namen für den EKS Cluster fest und klickt dann auf „Next Step“.

Im Konfigurations-Dialog „Create cluster“ wählt man in der Regel die neuste Kubernetes-Version (aktuell 1-14), im Feld „Role name“ die oben erstelle Service-Rolle und bei Network die oben erstellte Virtual Private Cloud (VPC).

Bei den Subnetzen wählt man dann für die Worker-Nodes die privaten Subnetze aus. Den Namen der Security-Group kann man wie oben erwähnt dem Ressourcen-Tab der CloudFormation-Console entnehmen.

Ferner zeigt die Console den „API server endpoint“ und die „OpenID Connect provider URL“. Mit „Private access“ (Zugriff über privaten Endpunkt) wird der private Zugriff für den Kubernetes-API-Server-Endpunkt des Clusters aktiviert oder deaktiviert. Erlaubt man den privaten Zugriff, verwenden Kubernetes-API-Anfragen aus der VPC des Clusters den privaten VPC-Endpunkt.

Mit „Public access“ (Endpunkt für öffentlichen Zugriff) wird der öffentliche Zugriff für den Kubernetes API-Server-Endpunkt Ihres des Clusters aktiviert oder deaktiviert. Deaktiviert man den öffentlichen Zugriff, kann der Kubernetes-API-Server des Clusters nur Anfragen aus der VPC des Clusters empfangen. Bei Logging kann der Nutzer für jeden einzelnen Protokolltyp auswählen, ob dieser Enabled (Aktiviert) oder Disabled (Deaktiviert) sein soll. Standardmäßig ist jeder Protokolltyp deaktiviert.

Sind alle Angaben korrekt, klickt man auf „Create“ und man kann das Erstellen des EKS Cluster im Menüpunkts „Clusters“ der EKS Console verfolgen. Nach wenigen Minuten wechselt der Status des Clusters auf „Active“.

Cluster-Authentifizierung

Amazon EKS verwendet wie oben beschrieben zur Bereitstellung der Authentifizierung des Kubernetes-Cluster AWS IAM. Dau wird der Befehl „aws eks get-token“ benutzt, der ab der AWS-CLI-Version 1.16.308 des https://github.com/kubernetes-sigs/aws-iam-authenticator aws iam athenticator für Kubernetes verfügbar ist. Allerdings greift dieser für die Autorisierung wiederum auf die native rollenbasierte Zugriffskontrolle (Role Based Access Control, RBAC) von Kubernetes zurück.

Konkret wird also AWS IAM nur für die Authentifizierung von gültigen IAM-Entitäten verwendet. Alle Berechtigungen für die Interaktion mit der Kubernetes-API des Amazon EKS-Clusters hingegen werden über das Kubernetes-native RBAC-System verwaltet, wie vorangestellte Abbildung zeigt.

Nachdem wir das Installieren des Kubernetes-Befehlszeilendienstprogramms kubectl erledigt haben, müssen wir uns jetzt noch den Authenticator installieren, weil Amazon EKS für die Bereitstellung der Authentifizierung des Kubernetes-Clusters IAM verwendet. Konkret muss man den kubectl-Client für die Arbeit mit Amazon EKS konfigurieren.

Dies geschieht dadurch, dass man den „aws iam authenticator“ für Kubernetes installiert und danach die kubectl-Konfigurationsdatei so ändert, dass sie zur Authentifizierung verwendet werden kann. Wie man den IAM-Authenticator unter Linux, Windows (via Chocolatey oder Powershell) bzw. Mac OS (Homebrew) installieren kann, ist in der EKS Dokumentation hinreichend beschrieben.

Da wir im Beispiel eine EC2-Instanz mit Amazon Linux als Kommando-Host verwenden, wählen wir die Linux-Variante. Zunächst laden wie die Binärdatei von AWS herunter:

Diese machen wir dann wie folgt ausführbar:

Dann legt man am besten ein Unterverzeichnis „aws-iam-authenticator“ unterhalb von $HOME/bin (weil $HOME/bin Bestandteil der PATH-Variablen ist) an und kopiert die eben heruntergeladene Binär-Datei dorthin. Außerdem muss man sicherstellen, dass $HOME/bin in Ihrem $PATH zuerst kommt.

Um die angepasste PATH-Variable auch für den nächsten Reboot persistent zu machen, verewigen wir sie in der .bashrc-Datei.

Ob der Authenticator erfolgreich installiert wurde, erfahren wir mittels:

Kubeconfig

Bevor man nun endlich die Worker-Knoten bereitstellen kann, benötigt man noch die kubeconfig-Datei. Diese lässt sich z. B. mit dem AWS-CLI-Befehl „update-kubeconfig“ für den EKS Cluster erzeugen. Vorab muss aber sichergestellt sein, dass der IAM-Authenticator installiert ist. Per Default erstellt kubeconfig die Konfigurationsdatei im kubeconfig-Standardpfad (.kube/config) im Stammverzeichnis oder führt sie mit einer vorhandenen kubeconfig an diesem Speicherort zusammen.

Mit der Option --kubeconfig lässt sich aber auch ein anderer Pfad angeben. Beim Angeben von kubectl-Befehlen kann man mit der Option --role-arn einen IAM-Rollen-ARN für die Authentifizierung verwenden, andernfalls wird stets die IAM-Entität in der Default-Anbieterkette von AWS CLI - oder SDK-Anmeldeinformationen benutzt. Welche das ist, zeigt der Befehl:

Mit …

… erzeugen wir nun die kubeconfig-Datei.

Was jetzt noch fehlt, sind die Worker-Knoten und eine Kubernetes-Beispiel-App. Die Worker-Knoten stellt EKS nicht automatisch bereit, allerdings gibt es auch hierfür passende CloudFormation-Vorlagen. Diese sehen wir ins im dritten Teil näher an.

(ID:46385234)