Jeder Plattform- und Service-Anbieter spricht mittlerweile „Kubernetes“. Für all jene, die bereits im Cloud-Umfeld agieren, bieten sich AWS, Google Cloud oder Microsoft Azure an. Den Kubernetes-Dienst der Microsoft-Plattform wollen wir hier näher beleuchten.
Nachdem wir die Vorgehensweise zum Einrichten eines Kubernetes-Cluster unter AWS EKS bereits beleuchtet haben, stellen wir in diesem und im folgenden Artikel eine Kubernetes-basierte App auf Azure bereit. Allerdings werden wir hier nicht noch einmal die Kubernetes-Grundlagen bis zur Architektur eines Kubernetes-Clusters hinunter erörtern. Diese lassen sich in den oben verlinkten Artikeln nachlesen, zumal die Prinzipien überall gleich sind.
In Google, AWS und Azure laufen die Agenten-Knoten als virtuelle Maschinen auf dem jeweiligen Hypervisor, die ihrerseits die Dienste kubelet-, kube-proxy und die Container-Runtime ausführen. Der Azure Kubernetes Service (AKS) verwendet übrigens „Moby“ als Container-Runtime. Wie auch bei AWS zahlen Nutzer nur für die Agenten-Knoten in den Clustern, nicht für Bereitstellung und Betrieb des Kubernetes-Masters. Die Knoten des Kubernetes-Masters werden beim Einrichten eines AKS-Clusters automatisch bereitgestellt und konfiguriert. Dabei lassen sich im Rahmen der Bereitstellung recht einfach zusätzliche Features wie erweiterte Netzwerke oder eine „Azure Active Directory“-Integration konfigurieren.
Eine Besonderheit von AKS ist, dass alternativ zu Linux-Knoten auch Windows Server-Container unterstützt werden. Zudem ist es mit der „Virtual Kubelet“-Funktion bei Bedarf jederzeit möglich, auch „Azure Container Instances“ zum horizontalen Skalieren zu verwenden. Das Erstellen eines AKS-Cluster klappt relativ problemlos wahlweise im Azure-Portal, mit der Azure-CLI oder mit vorlagenbasierten Bereitstellungsoptionen wie etwa Resource-Manager-Vorlagen (ARM-Templates) oder Terraform. Da wir aber die grundsätzlichen Kubernetes-Basics bereits mehrfach erläutert haben, wollen wir uns in diesem Artikel eher auf die Entwickler-Seite konzentrieren. Das ist letztendlich genau das, was mit dem Container-Thema erreichen werden soll, nämlich das einfache Bereitstellen „containerisierter“ Workloads, ohne sich um die Infrastruktur kümmern zu müssen. Wir verwenden daher auch in diesem Beispiel wie schon in unserem Google-Kubernetes-Artikel ein klassisches NGINX-Deployment, nur diesmal auf AKS, und skalieren anschließend die Anwendung.
Kubernetes-Cluster erstellen
Beginnen wir also mit dem Bereitstellen des Kubernetes-Clusters. Bevor wir das tun können, müssen wir im verwendeten Azure-Abonnement die Resource-Provider „Microsoft.Kubernetes“ und „Microsoft.KubernetesConfiguration“ aktivieren.
Dazu suchen wir im Azure-Portal den Dienst „Abonnements“, navigieren dann links zum Menü „Ressourcenanbieter“, filtern oben nach „Kub..“ und bestätigen die beiden genannten Anbieter mit einem Klick auf „Registrieren“.
Das Azure-Portal durchsuchen wir anschließend nach „Kubernetes-Dienste“, klicken auf „+ Hinzufügen“ und wählen im Klappmenü den Eintrag „Kubernetes-Cluster hinzufügen“. Auf der Seite „Kubernetes-Cluster erstellen“ wählen wir dann wir üblich das gewünschte Abonnement, erstellen eine neue Ressourcengruppe, geben dem Cluster einen Namen, bestimmen eine Region, nutzen ggf. Verfügbarkeitszonen und geben die zu verwendende Kubernetes-Version an.
Schließlich wählen wir noch die Größe der Instanz-Typen (für das NGINX-Beispiel genügt es völlig, wenn man die vorgeschlagene Größe „Standard DS2 v2“ mit „Größe ändern“ durch etwas „Kleineres“ ersetzt, z. B. einen Burstable-Typ, allerdings mit mindestens 2 vCPUs) und die Anzahl der Knoten. Wir reduzieren den Standard-Vorschlag 3 mit Hilfe des Schiebereglers auf 1.
Bei der Größe geht es übrigens nur um die Anzahl der Knoten im so genannten „primären Knotenpool“, einer Azure-spezifische Bezeichnung für den primären Workload-Cluster. Admins können später jederzeit zusätzliche Knotenpools einfügen. Auf die Größe und Konfiguration des Verwaltungs-Clusters (Master) hat man hier keinen Einfluss.
Nun klickt man auf „Weiter: Knotenpools“. Im Abschnitt „Knotenpools“ ist zu erkennen, dass wir gerade den Linux-basierten „agentpool (primär)“, also den primären Knotenpool einrichten. Neben der Möglichkeit, weitere Knotenpools einzurichten, lässt sich der primäre Knotenpool hier noch weiter konfigurieren, also etwa „Virtuelle Knoten aktivieren“ (Azure Container Instances) oder VM-Scalesets einrichten, damit die Anzahl der Knoten pro Knotenpool später skalieren kann.
Hat man auf der vorherigen Seite „Grundeinstellungen“ bereits Verfügbarkeitszonen ausgewählt, so ist diese Option mit Scaleset und Loadbalancer voreingestellt. Sie lässt sich dementsprechend nicht abwählen bzw. ist ausgewählt und ausgegraut. Bei einem Scaleset wird der Loadbalancer automatisch erstellt.
Wir übernehmen also die Defaults und klicken rechts unten auf „Weiter: Authentifizierung“. Bei der Authentifizierung verwenden wir die Option „Dienstprinzipal“ und lassen einen neuen Standarddienstprinzipal erstellen.
Die Kubernetes-Authentifizierung und -Autorisierung erfolgt wahlweise über die Rollenbasierte Zugriffssteuerung (RBAC) von Azure oder Active Directory. Wir übernehmen mit der Default-Einstellung die erste Option. Auf bei der Verschlüsselung ruhender Daten nehmen wir die Standardeinstellung mit plattformseitig verwalteten Schlüsseln.
Wir klicken auf „Weiter: Netzwerk“ und haben jetzt theoretisch die Möglichkeit, die Netzwerkeinstellungen für unseren Cluster zu ändern, also z. B. HTTP-Anwendungsroutings für den Lastausgleich zu aktivieren oder einen rein privaten Cluster einzurichten. Grundsätzlich muss man sich aber zunächst bei der Konfiguration des Netzwerks zwischen „kubenet“ oder „Azure CNI“ entscheiden. Wir verwenden die Default-Einstellung „kubenet“.
Der Unterschied: Bei Kubenet-Netzwerken werden die Netzwerkressourcen bei der Bereitstellung des AKS-Clusters erstellt und konfiguriert. Allerdings unterstützen Kubenet-Netzwerke keine Netzwerkrichtlinien, z. B. mit Calico. „Azure-Container Networking-Interface“-Netzwerke (CNI) erlauben es dagegen, den AKS-Cluster mit vorhandenen virtuellen Netzwerkressourcen und –Konfigurationen in Azure zu verbinden, was für unser einfaches Beispiel aber nicht erforderlich ist. Der DNS-Namenspräfix wird übrigens automatisch vorgeschlagen.
Wir klicken erneut auf „Weiter: Integration“ und übernehmen die Default-Einstellungen, d. h. wir Aktivieren die Container-Überwachung mit „Azure Monitor“ und deaktivieren Azure-Richtlinien, z. B. die Durchsetzung sowie Schutzvorrichtungen für AKS-Cluster.
Da wir keine weiteren Tags verwenden, können wir entweder jetzt links unten auf „Überprüfen und erstellen“ klicken oder navigieren mit der Weiter-Schaltfläche rechts unten zu „Überprüfen und erstellen“ und klicken nach erfolgreicher Überprüfung auf „Erstellen“.
Wurde der Cluster erstellt, kann man zunächst im Portal zur „Ressource wechseln“ unter im Menü unter „Einstellungen / Knotenpools“ verifizieren, dass der neue Knotenpool korrekt erstellt wurde. Im nächsten Teil werden wir mithilfe der bekannten kubectl-Schnittstelle unser NGINX-Deployment auf dem Knotenpool bereitstellen und anschließend einen Blick auf die Skalierungsoptionen werfen.
