Fabian Roos Privater AKS-Cluster – mehr Aufwand?
Im ersten Teil der Artikelreihe haben wir eine Beispielarchitektur für einen privaten AKS-Cluster in der Azure Public Cloud entworfen. Aber wenn wir die Infrastruktur nun in Azure aufbauen wollen, haben wir dann mehr Aufwand als bei einem öffentlich zugänglichen Cluster?
Die kurze Antwort lautet: Ja. Bei einem privaten AKS-Cluster müssen weitere Ressourcen erstellt werden, die bei einem öffentlichen Cluster nicht notwendig wären. Des Weiteren sind einige Abhängigkeiten zu beachten.
Aufbau der Netzwerkinfrastruktur
Um die Frage noch etwas ausführlicher zu beantworten und um zu zeigen, wie wir den Aufwand minimieren können, ist es wichtig, die Abhängigkeiten zwischen den Ressourcen zu verstehen. Vor diesem Hintergrund widmen wir uns zuerst der Netzwerkinfrastruktur. Diese bildet die Grundlage für die AKS-Cluster und muss daher zuerst aufgebaut werden. Sie besteht aus zentralen Ressourcen, wie zum Beispiel dem Hub-Netzwerk und den darin befindlichen zentralen Netzwerkressourcen, und dezentralen Ressourcen, wie zum Beispiel den Spoke-Netzwerken mit ihren jeweils verbundenen Ressourcen. Zwischen diesen bestehen Abhängigkeiten, sodass sie nicht in einer beliebigen Reihenfolge erstellt werden können.
Was muss also bei der Erstellung der Infrastruktur beachtet werden, um AKS-Cluster schnell und fehlerfrei bereitstellen zu können?
Abhängigkeit 1: Zentrale Netzwerkressourcen
Virtuelle Netzwerke und zentrale Netzwerkressourcen, wie zum Beispiel eine Firewall, ein Virtual Network Gateway für eine VPN-Verbindung, private DNS-Zonen und der Private DNS Resolver müssen zuerst erstellt werden. Anschließend können die Spoke-Netzwerke mit Hilfe von „Network Peering“ an das Hub-Netzwerk angebunden werden.
In vielen Fällen wird die Verwaltung von zentralen und dezentralen Netzwerkkomponenten von unabhängigen Teams durchgeführt oder erfolgt zumindest als Teil unterschiedlicher Prozesse. Zentrale Ressourcen werden beispielsweise häufig als Teil einer „Azure Landing Zone“ verwaltet, während dezentrale Ressourcen durch andere Teams – z. B. einzelne Fachbereiche – bereitgestellt und genutzt werden.
In solchen Fällen sollte geprüft werden, ob die zentrale Netzwerkinfrastruktur die Anforderungen erfüllt. Es sollte beispielsweise möglich sein, die Spoke-Netzwerke an das zentrale Hub-Netzwerk anzubinden. Es müssen also getrennte Netzwerksegmente definiert werden. Darüber hinaus sollten die benötigten privaten DNS-Zonen und eine zentrale DNS-Lösung vorhanden sein, sodass die Namensauflösung in Azure, aber auch im On-Premises-Netzwerk möglich ist.
Abhängigkeit 2: Private DNS-Zonen – ein Teufelskreis?
Betrachten wir noch einmal die zu Beginn erläuterte Architektur. Die privaten DNS-Zonen müssen mit allen virtuellen Netzwerken verknüpft werden, in denen die Auflösung von Namen der jeweiligen Zone möglich sein soll. Demnach werden die beiden Zonen für Azure Container Registries („privatelink.azurecr.io“) und für die AKS-Cluster („privatelink.germanywestcentral.azmk8s.io“, für Cluster in der Region „Germany West Central“) mit allen dargestellten Netzwerken verknüpft. Die umgebungsspezifischen Zonen „test.myapp.com“ und „myapp.com“ werden mit dem Netzwerk der jeweiligen Umgebung sowie dem Hub-Netzwerk und dem Spoke-Netzwerk für CI/CD-Agents verknüpft.
Sobald die Netzwerkinfrastruktur bereitsteht, kann prinzipiell mit der Erstellung der AKS-Cluster begonnen werden. Hierbei ergibt sich jedoch folgende Herausforderung: Bei der Erstellung eines AKS-Clusters wird ein DNS-Eintrag für den Kubernetes API-Server erstellt, um dessen Adresse zu einer IP-Adresse auflösen zu können. Bei einem öffentlich zugänglichen Cluster wird dieser DNS-Eintrag automatisch in einer DNS-Zone erstellt, die durch Microsoft verwaltet wird. Entscheiden wir uns jedoch für einen privaten AKS-Cluster, obliegt die Verwaltung dieses DNS-Eintrags uns.
Für die Erstellung des DNS-Eintrags verwendet AKS die sogenannte „Control Plane Identity“. Diese Identität muss also berechtigt sein, einen DNS-Eintrag zu erstellen und die DNS-Zone muss mit dem Netzwerk verknüpft werden, in dem sich die Worker Nodes befinden. Dies ist eine Voraussetzung für das erfolgreiche Beitreten der Worker Nodes in den Cluster.
Um dies zu gewährleisten, bietet Microsoft uns die Möglichkeit, sowohl die Control Plane Identity als auch die private DNS-Zone automatisch im Rahmen der Clustererstellung mit zu erstellen und die Identität auf diese zu berechtigen. Die Control Plane Identity ist in diesem Fall eine „systemseitig zugewiesene Identität (engl. „system-assigned managed identity“), die an den Lebenszyklus des AKS-Clusters gebunden ist. Dies bedeutet jedoch auch, dass für jeden AKS-Cluster eine eigene private DNS-Zone angelegt wird. In einer Hub-Spoke-Netzwerktopologie ist dies nicht praktikabel, da die Namensauflösung auch im Hub-Netzwerk möglich sein muss, wir jedoch nicht mehrere gleichnamige private DNS-Zonen mit einem Netzwerk verknüpfen können.
Aus diesem Grund sollten die privaten DNS-Zonen als zentrale Ressourcen einmalig erstellt und dann mit den gewünschten Netzwerken verknüpft werden. Um einen AKS-Cluster zu erstellen, müssen wir also zunächst dessen Identität auf die zentrale DNS-Zone berechtigen. Wie können wir aber Berechtigungen an eine Identität vergeben, die noch gar nicht existiert? Ein Teufelskreis.
Abhängigkeit 3: Benutzerseitig zugewiesene Identitäten
Die Lösung für das beschriebene Problem liegt in der Verwendung von benutzerseitig zugewiesenen Identitäten (engl. „user-assigned managed identities“). Wie der etwas sperrige Name bereits verrät, wird eine solche Identität anders als systemseitig zugewiesene Identitäten unabhängig von anderen Azure-Ressourcen erstellt. Wir können also bereits vor der Erstellung eines AKS-Clusters eine Identität erstellen und auf unsere private DNS-Zone berechtigen. Diese Identität muss dann dem Cluster als Control Plane Identity zugewiesen werden. Dieser Ansatz wird in der Microsoft-Dokumentation auch als „Bring your own managed identity“ bezeichnet.
Durch diese Vorgehensweise ist es möglich, eine einzelne private DNS-Zone zentral für mehrere AKS-Cluster zu verwenden. Im Falle unserer Beispielarchitektur ist dies also die Grundlage für die Erstellung der Cluster.
Sofern wir benutzerseitig zugewiesene Identitäten erstellt und berechtigt haben, können wir die AKS-Cluster bilden. Insgesamt erstellen wir die Ressourcen also in folgender Reihenfolge:
- Netzwerkinfrastruktur inkl. einer privaten DNS-Zone für AKS
- Verknüpfungen der privaten DNS-Zone mit den Netzwerken
- Benutzerseitig zugewiesene Identitäten für die AKS-Cluster
- Berechtigung der Identitäten auf die zuvor erstellte private DNS-Zone
- AKS-Cluster inkl. Zuweisung der Identitäten
Ein AKS-Cluster – zwei Ressourcengruppen
Bei der Erstellung eines AKS-Clusters wird im Hintergrund eine weitere Ressourcengruppe für Ressourcen angelegt, die automatisch durch AKS selbst verwaltet werden. In dieser Ressourcengruppe würde auch die private DNS-Zone Platz finden, falls diese, wie zuvor beschrieben, automatisch erstellt wird. In unserem Szenario ist dies jedoch nicht der Fall. Andere Ressourcen, wie zum Beispiel Virtual Machine Scale Sets als Grundlage für Kubernetes Node Pools, der Azure Load Balancer für ausgehende (und optional eingehende) Verbindungen, oder der Private Endpoint des Clusters, werden dennoch in dieser Ressourcengruppe platziert.
Die Control Plane Identity wird übrigens automatisch auf diese Ressourcengruppe berechtigt, auch wenn eine benutzerseitig zugewiesene Identität genutzt wird.
Einschränkungen des Azure Portals
An dieser Stelle sei erwähnt, dass das beschriebene Szenario nicht mit Hilfe des Azure Portals umsetzbar ist, da dort keine user-assigned Identity für die Kubernetes Control Plane definiert werden kann (Stand: Januar 2024). Für die Bereitstellung der Ressourcen muss stattdessen ein Kommandozeilenwerkzeug (Azure CLI oder PowerShell), ein Azure Resource Manager Template oder ein Infrastructure as Code Werkzeug (z. B. Bicep oder HashiCorp Terraform) genutzt werden.
Im nachfolgenden Abschnitt werden an den Beispielen Azure CLI und Terraform die Parameter/Argumente näher betrachtet, die bei der Bereitstellung eines privaten AKS-Clusters besonders wichtig sind.
Wichtige Parameter (Azure CLI und Terraform)
Um private AKS-Cluster nach der beschriebenen Vorgehensweise mit der Azure CLI oder mit Terraform zu erstellen, müssen verschiedene Parameter bzw. Argumente definiert werden. Diese Argumente ähneln sich größtenteils, wie in den nachfolgenden Tabellen dargestellt.
Bei Verwendung der Azure CLI sind folgende Argumente von besonderer Bedeutung:
Analog dazu sehen die Argumente bei Terraform wie folgt aus:
Mit Hilfe der angegebenen Argumente lassen sich die Cluster letztendlich erstellen und so konfigurieren, wie es in der Beispielarchitektur dargestellt ist.
Zusammenfassung
Im zweiten Teil dieser Artikelreihe wurden die Abhängigkeiten zwischen unterschiedlichen Ressourcen und die sich daraus ergebende Vorgehensweise bei der Provisionierung der Infrastruktur in den Fokus gerückt.
Sofern Terraform für die Bereitstellung der Infrastruktur genutzt wird, können die beschriebenen Abhängigkeiten dort implizit oder explizit angegeben werden. Darauf basierend bestimmt Terraform die Reihenfolge, in der die Ressourcen erstellt werden – in unserem Fall zum Beispiel:
- Benutzerseitig zugewiesene Identität
- Rollenzuweisung der Identität (Berechtigung auf private DNS-Zone)
- AKS-Cluster inkl. Zuweisung der Identität
Nachdem die Bereitstellung der AKS-Cluster abgeschlossen ist, können Anwendungen in dem jeweiligen AKS-Cluster ausgerollt werden. Da hierfür auf den Kubernetes API-Server zugegriffen wird, ist die Vorgehensweise bei einem privaten Cluster anders als bei einem Cluster mit öffentlich erreichbarem Endpunkt. Eine genauere Betrachtung dieser Thematik folgt im dritten, noch ausstehenden Teil dieser Artikelreihe.