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
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.
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:
curl -o kubectl https://amazon-eks.s3-us-west-2.amazonaws.com/1.14.6/2019-08-22/bin/linux/amd64/kubectl
Dann machen wir die Datei ausführbar:
chmod +x ./kubectl
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:
mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin
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:
curl -o aws-iam-authenticator https://amazon-eks.s3-us-west-2.amazonaws.com/1.14.6/2019-08-22/bin/linux/amd64/aws-iam-authenticator
