Sergey Nivens - stock.adobe.com
Anleitung: Ressourcen mit Azure-Arc-Kubernetes verwalten
Je mehr Cloud-Ressourcen Sie nutzen, desto komplexer wird Ihre Umgebung. Kubernetes mit Azure-Arc-Aktivierung kann Ihnen dabei helfen, aufwendige Verwaltungsaufgaben zu bewältigen.
Viele moderne Unternehmen haben Schwierigkeiten, ihre komplexen Hybrid- und Multi-Cloud-Umgebungen zu organisieren, zu verwalten und zu kontrollieren. Es ist eine beträchtliche Herausforderung, diese unterschiedlichen Umgebungen mit einer Reihe unzusammenhängender Verwaltungs-Tools mit verschiedenen Oberflächen und Werkzeugen zu verwalten.
Diese Lücke wird immer größer, da Microsoft Azure und Google Cloud mit AWS konkurrieren und Endbenutzern mehr Optionen zum Hosten und Verwalten ihrer Dienste bieten. Die großen Cloud-Anbieter haben auf unterschiedliche Art und Weise versucht, dieses Problem mit Produkten wie AWS Outposts, Google Cloud Anthos und Microsoft Azure Arc zu lösen, auf die wir in diesem Tutorial eingehen.
Mit Azure Arc können Benutzer ihre Microsoft-Azure-Resource-Manager-Steuerungsebene (ARM) auf Ressourcen außerhalb der Cloud-Umgebung erweitern, von lokalen Standorten auf Multi-Cloud-Umgebungen. IT-Organisationen können die Governance und Organisation von virtuellen Maschinen (VMs) mit Windows, Linux und SQL vereinfachen, unabhängig davon, ob sie in Rechenzentren auf Hyper-V- oder VMware-Plattformen oder in einer Cloud laufen. Das Tool eignet sich auch für Container-Workloads, die mit Kubernetes verwaltet werden.
Dazu verfügt Azure Arc über die folgenden Funktionen:
- Azure-Arc-Aktivierung für Server – sowohl für physische als auch für virtuelle (Windows- und Linux-Betriebssystem);
- Azure-Arc-Aktivierung für Kubernetes – für alle wichtigen Kubernetes-Distributionen;
- Azure-Arc-Aktivierung für Datendienste (zum Zeitpunkt der Veröffentlichung in Preview) – SQL Managed und PostgreSQL Hyperscale; und
- Azure-Arc-Aktivierung für SQL Server (zum Zeitpunkt der Veröffentlichung in Preview) – SQL-Server-Instanzen, die außerhalb von Azure gehostet sind.
Sobald ein Dienst an Azure Arc angebunden ist, ergeben sich drei Hauptvorteile:
- IT-Administratoren können diese Ressourcen wie jede andere Azure-Ressource über das Portal verwalten.
- Rollenbasierte Zugriffssteuerungen (Role Based Access Control, RBAC) und Azure Policy gelten auch für den Dienst.
- Überwachung durch Azure Monitor und Azure-Aktivitätsprotokolle schließen die Ressource mit ein.
Public-Cloud-Angebote haben sich weiterentwickelt, um eine breite Palette unterschiedlicher Kunden und ihrer Anforderungen für das Hosting von Container-Workloads zu erfüllen. Anwender haben außerdem mehrere Möglichkeiten, ihre Workloads mit der Infrastruktur verschiedener Cloud-Anbieter bereitzustellen, zum Beispiel Azure Kubernetes Services, Amazon Elastic Kubernetes Services (EKS) und Google Kubernetes Engine (GKE). Die Komplexität, die diese Zusammenarbeit in die Verwaltung bringt, ist soll Azure Arc bewältigen.
Azure-Arc-Aktivierung für Kubernetes
Mit ARM können Nutzer Ressourcen kontrollieren und verwalten; Azure Arc erweitert diese Steuerungsebene, indem es Benutzern ermöglicht, der Azure-Umgebung externe Ressourcen hinzuzufügen. Solche Ressourcen verfügen in Azure über Ressourcen-IDs und Zugriff auf andere Azure-Governance-Features wie Azure Policy und einen kompletten Observability Stack. Dieser umfasst Azure-Monitor-Infrastruktur- und Anwendungsprotokolle, Metriken, Ereignisse und Traces. Lesen Sie mehr über die Azure-Arc-Aktivierung in der offiziellen Microsoft-Dokumentation.
Zusätzlich zu den Azure-Richtlinien und integrierten Überwachungs-Tools können IT-Organisationen über GitOps Azure-Arc-Aktivierte Kubernetes-Cluster konfigurieren, wodurch einheitliche Konfigurationen an alle Kubernetes-Cluster auf der Steuerungsebene übertragen werden. Azure Arc und GitOps vereinfachen und rationalisieren die Bereitstellung von Konfigurationen durch verbesserte Steuerelemente.
Was ist GitOps?
GitOps ist eine Kombination aus Git und Kubernetes, mit der Nutzer Infrastruktur als Code (IaC) und Continuous-Integration-und-Delivery-Pipelines (CI/CD) für die deklarative Bereitstellung von Softwareanwendungen und Infrastruktur modellieren.
Wenn die kontinuierliche Integration in einem traditionellen CI/CD-System angestoßen wird, werden bestimmte Konfigurationen in der Pipeline nach vorne gepushed. GitOps hingegen überwacht laufend alle Änderungen an einem Git-Repository –die Pull-Konfiguration ändert sich von diesem Repository aus. Es fungiert als Single Source of Truth (SSOT) für die deklarative Infrastruktur- und Anwendungsbereitstellung. Unter der Haube von Azure Arc arbeitet Flux, um diese Konfigurationsaktualisierungen, Bereitstellungen und den gewünschten Zustand des Kubernetes-Clusters zu überwachen.
Wie funktionieren Azure Arc und GitOps?
Das System durchläuft aus Sicht des Nutzers drei Schritte, um ein externes Kubernetes-Cluster mit Azure Arc zu verbinden:
- Azure Arc installiert Metriken und Flux-Agents auf dem lokalen Cluster.
- Azure Arc richtet automatisch eine verwaltete Identität im Kubernetes-Cluster ein. Alternativ wählen Benutzer selbst einen Dienstprinzipal – verwaltete Identitäten vereinfachen aber das Management.
- Ist Azure Arc erfolgreich eingerichtet, beginnt der Agent, Metadaten vom Cluster an Azure zu senden.
Wenn ein Benutzer eine Kubernetes-GitOps-Konfiguration auf einem Azure-Arc-aktivierten Kubernetes erstellt, werden auch die folgenden Schritte ausgeführt:
- Ein Flux-Agent überwacht die Git-Repository-URL auf IaC-Manifestdateien hin.
- Erkennt Flux eine Änderung, zieht es die Manifestdateien in ein lokales Repository.
- Flux konfiguriert das lokale Kubernetes-Cluster, um die Änderungen einzupflegen.
Doch bevor wir uns näher mit diesen drei Schritten auseinandersetzen, müssen wir erst einmal ein Cluster und eine Umgebung einrichten.
Eine Umgebung aufbauen
Diese Anleitung erklärt den Prozess exemplarisch anhand eines Kubernetes-Clusters auf Minikube, das auf einem gewöhnlichen Windows-10-Desktop läuft. Wir werden Sie Schritt für Schritt durch das Onboarding Ihres ersten Kubernetes-Clusters in Azure Arc führen. Zu Beginn benötigen Sie:
- ein Microsoft Azure-Konto und Zugriff auf das Azure-Portal;
- die neueste stabile Version der Azure-CLI zum Verwalten von Azure-Ressourcen;
- die neueste stabile Version von Helm Charts, einem Paketmanager für Kubernetes;
- ein laufendes Kubernetes-Cluster, mit dem Sie eine Verbindung herstellen und in Azure Arc konfigurieren können; und
- öffentliches Git-Repository mit Kubernetes-Bereitstellungsmanifesten; In diesem Tutorial verwenden wir ein grundlegendes Nginx-Bereitstellungsmanifest.
Verbinden des lokalen Kubernetes-Clusters mit Azure Arc
Der Einfachheit halber führt dieses Tutorial das Kubernetes-Cluster auf Minikube aus. Minikube ist eine schlanke Kubernetes-Implementierung, die eine VM auf Ihrem lokalen System startet, sowie ein Single-Node-Kubernetes-Cluster für die täglichen Entwicklungsanforderungen bereitstellt.
Der erste Schritt besteht darin, sicherzustellen, dass das Cluster betriebsbereit ist. Starten wir Minikube also von einer beliebigen CLI aus – dieses Tutorial verwendet PowerShell – mit Administratorenrechten.
minikube start
Bevor wir unser Cluster integrieren können, müssen wir ihm ein Zuhause geben, also eine neue Azure-Ressourcengruppe. Melden wir uns über die Azure CLI bei unserer Azure-Konsole an:
az login
Sobald Sie über die CLI bei Azure Ihre Anmeldung absolviert haben, zeigt die Konsole Abonnementinformationen an, wie in Abbildung 2 dargestellt.
Erstellen wir nun mit dem folgenden Befehl eine neue Ressourcengruppe namens erste-azure-arc-k8s in der Region westus2. Wir weisen das Cluster der Gruppe im Laufe dieser Anleitung später zu.
az group create --name erste-azure-arc-k8s --location westus2
Haben Sie die Ressourcengruppe erstellt, müssen Sie sicherstellen, dass die Azure CLI-Erweiterung connectedk8s installiert ist. Das ist eine Voraussetzung, damit Sie die az-CLI-Befehle nutzen können, um das Cluster mit Azure Arc zu verbinden.
Überprüfen Sie, ob die Erweiterung installiert ist:
az extension show --name connectedk8s
Installieren Sie, wenn nötig, die Erweiterung:
az extension add --name connectedk8s
Führen Sie nun den folgenden Befehl aus, um das lokale Kubernetes-Cluster als Azure-Ressource – minikube-k8s – mit Azure in der von uns erstellten Ressourcengruppe zu verbinden.
az connectedk8s connect --name minikube-k8s --resource-group erste-azure-arc-k8s
Sie verifizieren die Verbindung, indem sie diese im Azure-Portal suchen. Die Konsole sollte eine neue Azure-Arc-aktivierte Kubernetes-Ressource anzeigen, wie in Abbildung 5.
Um diese Verbindung herzustellen, werden einige Bereitstellungen und Agenten auf dem lokalen Cluster im azure-arc-Namespace konfiguriert. Sie können wie in Abbildung 6 überprüfen, ob ein Flux-Agent ausgeführt wird, um IaC aufzurufen und GitOps zu unterstützen. Wir können auch überprüfen, ob ein Azure-Monitor-Agent vorhanden ist, um Überwachungsdaten zu sammeln. Führen Sie den folgenden Befehl aus, um diese Azure-Arc-Bereitstellungen und Pods im lokalen Cluster zu testen:
kubectl -n azure-arc get deployments,pods
Konfigurieren von Azure-Arc-aktivierten Clustern mit GitOps
Es gibt zwei Methoden zum Einrichten von GitOps in einem Azure-Arc-aktivierten Cluster. Die erste Option besteht darin, das Azure-Portal über die verbundene Kubernetes-Ressource zu verwenden und dann zu Einstellungen > GitOps > Konfiguration hinzufügen zu navigieren.
Der zweite Ansatz erfolgt über die Azure CLI. Um GitOps zu konfigurieren, installieren wir eine Az-CLI-Erweiterung namens k8skonfiguration.
az extension show --name k8skonfiguration
az extension add --name k8skonfiguration
Nachdem die Erweiterung installiert ist, konfigurieren Sie das lokale Kubernetes-Cluster mit GitOps über eine öffentliches Git-Repository, das auf GitHub gehostet ist.
Stellen Sie sicher, dass Sie den richtigen Cluster- und Ressourcengruppennamen für den Befehl angeben.
az k8sconfiguration create \
--name azure-arc-config \
--cluster-name minikube-k8s \
--resource-group erste-azure-arc-k8s \
--repository-url https://github.com/PrateekKumarSingh/azure-arc-demo \
--scope cluster \
--cluster-type connectedClusters
Das im obigen Befehl erwähnte Repository enthält eine Manifestdatei deploy.yaml, mit der Sie einen Nginx-Server auf einem Kubernetes-Cluster bereitstellen. Wir konfigurieren dieses Manifest in GitOps in unserem Azure-Arc-fähigen Kubernetes-Cluster, damit es dort automatisch bereitgestellt wird. Der Flux-Agent kann dieses Repository auf Änderungen hin überwachen und den Cluster gemäß der Änderungen in der Datei anpassen.
Standardmäßig überwacht diese GitOps-Konfiguration den master-Zweig auf der von Ihnen angegebenen öffentlichen Repository-URL. Neuere Repositories haben jedoch einen Root-Zweig namens main und aus diesem Grund kann die Konfiguration Ihre Änderungen möglicherweise nicht finden.
Wenn Ihr öffentliches Repository einen Root-Zweig namens main hat, stellen Sie sicher, dass Sie den Namen des Git-Zweigs mit --operator-params='--git-branch=main' an den im vorherigen Schritt erwähnten Befehl az k8sconfiguration create übergeben. Weitere Informationen zu diesem Parameter finden Sie in der Azure-Dokumentation.
Wenn Sie die Konfiguration erstellt und installiert haben, können Sie überprüfen, ob neue Nginx-Pods in Ihrem lokalen Kubernetes-Cluster bereitgestellt werden.
Es handelt sich um denselben Aufbau, wie er in der Manifestdatei aus dem GitHub-Repository hinterlegt ist. In Abbildung 10 sehen Sie, wie Sie überprüfen, ob der Kubernetes-Namespace – zusammen mit der Bereitstellung mit zwei Replikaten und dem Dienst – in der Manifestdatei erwähnt wird.
GitOps in Aktion
Sobald GitOps für das Azure-Arc-aktivierte Kubernetes-Cluster eingerichtet ist, ruft das System die Konfigurationen aus dem öffentlichen Git-Repository ab. Aber kann GitOps Bereitstellungen in den lokalen Kubernetes-Clustern gemäß den Änderungen an der Manifestdatei im Repository neu konfigurieren?
Sie können dies folgendermaßen prüfen:
Zuerst klonen Sie das GitHub-Repository lokal und bearbeiten die YAML-Datei, um die Anzahl der bereitgestellten Replikate von zwei auf drei zu ändern.
git clone https://github.com/PrateekKumarSingh/azure-arc-demo/
cat .\azure-arc-demo\nginx\deployment.yaml | grep replica
notepad .\azure-arc-demo\nginx\deployment.yaml
cat .\azure-arc-demo\nginx\deployment.yaml | grep replica
Sobald die Änderungen lokal vorgenommen wurden, übergeben wir diese Änderungen über den Befehl git commit und übertragen die Änderungen stromaufwärts in das öffentliche Repository.
cd .\azure-arc-demo\
git add .
git commit -m "changing replica set to 3"
git push origin master
Innerhalb einer Minute nach dem Pushen der Änderung identifiziert der Flux-Agent diese im Repository und beginnt mit einer weiteren Replikatbereitstellung. Sie fügt einen weiteren Nginx-Pod in Ihrem Cluster hinzu, den wir wie in Abbildung 11 überprüfen können.
kubectl Get Pods -n nginx-webserver -w
