Kubernetes Cluster mit Azure Arc verbinden – Mein Erfahrungsbericht

Einleitung

Die Verwaltung eines Kubernetes-Clusters kann eine Herausforderung sein, besonders wenn verschiedene Umgebungen ins Spiel kommen. Mit Azure Arc lässt sich dieser Prozess vereinfachen, indem es eine zentrale Verwaltungsplattform für hybride Kubernetes-Umgebungen bietet.

In diesem Blogpost zeige ich, wie ich meinen Kubernetes-Cluster eingerichtet und mit Azure Arc verbunden habe. Ich gehe Schritt für Schritt durch die Installation, Registrierung und Verwaltung, um dir einen praxisnahen Einblick zu geben.

Kubernetes Cluster bereitstellen

Bevor der Cluster mit Azure Arc verbunden werden kann, muss zunächst ein Kubernetes-Cluster eingerichtet werden. Ich habe mich für eine Installation mit k3s auf einem Bare-Metal-Server entschieden. Alternativ können auch AKS (Azure Kubernetes Service), EKS (Amazon Elastic Kubernetes Service) oder GKE (Google Kubernetes Engine) genutzt werden.

Voraussetzungen

• Ein Linux-Server mit mindestens 4 vCPUs und 8 GB RAM
• Ubuntu Server 24.04 LTS (meine Wahl)
• Kubernetes-Version 1.13 oder neuer
• Konnektivität sicherstellen (Firewall-/Proxy-Verbindungen konfigurieren):
  • Ports 443 und 9418 müssen offen sein
  • Outbound-URLs müssen erreichbar sein
  • Optionen: Public Endpoint, Proxy Server oder Private Endpoint
• Ein Azure-Konto mit aktivierter Azure Arc-Unterstützung

Azure CLI und Erweiterungen installieren

Falls noch nicht geschehen, muss das Azure CLI mit dem Arc-Erweiterungsmodul installiert werden. Installationsmöglichkeiten für andere Systeme sind hier zu finden.

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
az login
az extension add --name connectedk8s

K3s-Kubernetes Cluster installieren

Die Installation von K3s erfolgt über das offizielle Installationsskript, andere Möglichkeiten sind in der Schnellstartanleitung zu finden:

curl -sfL https://get.k3s.io | sh -

Installation prüfen

kubectl version --client

K3s-Konfiguration erstellen

mkdir ~/.kube
sudo KUBECONFIG=~/.kube/config:/etc/rancher/k3s/k3s.yaml kubectl config view --flatten > ~/.kube/merged
mv ~/.kube/merged ~/.kube/config
chmod  0600 ~/.kube/config
export KUBECONFIG=~/.kube/config
#switch to k3s context
kubectl config use-context default
sudo chmod 644 /etc/rancher/k3s/k3s.yaml

Systemoptimierungen

Um die Performance zu verbessern, erhöhen wir einige Systemlimits:

echo fs.inotify.max_user_instances=8192 | sudo tee -a /etc/sysctl.conf
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf

sudo sysctl -p

Um eine bessere Leistung zu erzielen, erhöhe den Grenzwert für Dateideskriptor:

echo fs.file-max = 100000 | sudo tee -a /etc/sysctl.conf

sudo sysctl -p

Vorbereitungen für Azure Arc

Stelle sicher, dass du noch im Azure CLI angemeldet bist

az login

Registriere folgende Ressourcenanbieter:

az provider register -n "Microsoft.ExtendedLocation"
az provider register -n "Microsoft.Kubernetes"
az provider register -n "Microsoft.KubernetesConfiguration"
az provider register -n "Microsoft.SecretSyncController"

💡 Hinweis: Dieser Schritt muss nur einmal pro Abonnement durchgeführt werden. Zum Registrieren von Ressourcenanbietern benötigst du die Berechtigung zum Ausführen des /register/action-Vorgangs, welche in den Rollen „Contributor“ und „Owner“ des Abonnements enthalten ist. Weitere Informationen findest du unter Azure-Ressourcenanbieter und -typen.

Kubernetes-Cluster mit Azure Arc verbinden

Damit der Kubernetes Cluster mit Azure Arc im Azure Portal angelegt werden kann, muss zuerst eine Resource Group angelegt werden oder via Azure CLI.

Ressourcengruppe in Azure erstellen

az group create --name AzureArcTest --location WestEurope --output table

Anschließend wird eine neue Ressource angelegt. Dafür kann im Suchfeld z.B. nach "kubernetes arc" gesucht werden.

Anschließend werden alle Voraussetzungen für ein Kubernetes Cluster und für die lokale Maschine inklusive hilfreicher Links gezeigt.

Dann können wir die Subscription, Ressource Group, sowie Cluster Details wie Name und Region und die Netzwerkkonfiguration anpassen.

Für die Identifizierung der Cluster, gerade wenn es mehrere gibt, können Tags im nächsten Schritt vergeben werden:

Verbindung herstellen

# This script creates an Azure Arc resource to connect a Kubernetes cluster to Azure
# Documentation: https://aka.ms/AzureArcK8sDocs

# Log into Azure
az login --use-device-code

# Set Azure subscription
az account set --subscription "<Subscription_ID>"

# Create connected cluster
az connectedk8s connect --name "MeinCluster" --resource-group "<Ressource_Group_Name>" --location "westeurope" --correlation-id "<Correlation_ID>" --tags 'Datacenter=Tim CountryOrRegion=Germany'

Wenn alle Schritte erfolgreich ausgeführt wurden, sollte im nächsten Schritt eine Verbindung zum Cluster hergestellt werden. Den Status könnt ihr anschließend in Azure einsehen.

Nach der erfolgreichen Registrierung läuft ein Azure Arc-Agent auf dem Cluster, der die Verwaltung über Azure ermöglicht.

Verbindung prüfen

Sobald die Registrierung abgeschlossen ist, kann der Status des Clusters auch lokal überprüft werden:

az connectedk8s show --name MeinCluster --resource-group MeinResourceGroup

Schauen wir uns das jetzt im Azure Portal an:

Der Status sollte auf Connected stehen. Im rot markierten Bereich auf der rechten Seite oder auch in den Properties im unteren Bereich siehst du mehr Details deines Clusters. Wie etwa die Distribution, Agent- und Kubernetes Version und den Total node bzw. total core count.

Verwaltung von Kubernetes Ressourcen (Preview)

Azure Arc ermöglicht die Verwaltung von Kubernetes-Ressourcen direkt im Azure-Portal (aktuell in Preview). Dazu wird ein Service Account Bearer Token benötigt.

Serviceaccount erstellen

kubectl create serviceaccount tim-serviceaccount -n default

Cluster-Admin Role mit dem neuen Service Account verbinden:

kubectl create clusterrolebinding tim-serviceaccount-binding --clusterrole cluster-admin --serviceaccount default:tim-serviceaccount

Secret für den Serviceaccount anlegen

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: tim-serviceaccount-secret
  annotations:
    kubernetes.io/service-account.name: tim-serviceaccount
type: kubernetes.io/service-account-token
EOF

Token abrufen

TOKEN=$(kubectl get secret tim-serviceaccount-secret -o jsonpath='{$.data.token}' | base64 -d | sed 's/$/\n/g')

echo $TOKEN

Das Token muss anschließend im Azure-Portal eingetragen werden.

💡 Tipp: Speichert das Token an einem sicheren Ort. Das Azure Portal wird euch bei einer neuen Session wieder danach fragen

Übersicht der Azure Arc-Deployments

Im Namespace azure-arc sind alle relevanten Deployments enthalten und wurden durch den connect Befehl automatisiert eingerichtet. Hierbei werden mehrere Agents automatisch eingerichtet, die verschiedene Verwaltungsaufgaben übernehmen, wie folgende Beispiele zeigen:

• clusterconnect-agent: Verwaltung der Clusterverbindung
• metrics-agent: Überwachung und Metriken-Erfassung
• flux-logs-agent: Log-Verarbeitung für GitOps-Deployments

Diese Agents sorgen für eine nahtlose Integration des Clusters in Azure und ermöglichen ein zentrales Management über das Portal.

Verwaltung mit Azure Policy und GitOps

Ein großer Vorteil von Azure Arc ist, dass Azure Policy und GitOps zur Verwaltung des Clusters genutzt werden können.

Einsatzmöglichkeiten von Azure Policies für Kubernetes

Azure Policies für Kubernetes bieten eine zentrale Möglichkeit, Sicherheits-, Governance- und Compliance-Richtlinien innerhalb von Clustern durchzusetzen. Sie können in verschiedenen Bereichen eingesetzt werden, darunter:

• Sicherheitshärtung: Policies helfen dabei, Container sicherer zu machen, indem sie Root-Rechte einschränken, Berechtigungseskalationen verhindern und signierte Images erzwingen.
• Compliance- und Governance-Anforderungen: Unternehmen können sicherstellen, dass ihre Kubernetes-Cluster regulatorischen Vorgaben entsprechen, indem beispielsweise Verschlüsselungsrichtlinien oder Zugriffskontrollen automatisch angewendet werden.
• Ressourcenverwaltung und -optimierung: Policies ermöglichen die Standardisierung von Ressourcenkonfigurationen, indem sie CPU- und Speicherlimits vorgeben, Pod-Disruptionsbudgets definieren und sicherstellen, dass Dienste eindeutige Selektoren haben.
• Automatisierte Konfiguration: Durch die automatische Bereitstellung von Erweiterungen wie Microsoft Defender für Cloud oder Open Service Mesh können Sicherheits- und Netzwerkmanagementfunktionen direkt in Kubernetes integriert werden.

Sicherheitsrichtlinien setzen

Mit Azure Policy lassen sich Sicherheitsrichtlinien durchsetzen:

az policy assignment create --name "KubernetesSecurity" --policy-set-definition "[BUILTIN-POLICY-ID]" --scope /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Kubernetes/connectedClusters/MeinCluster

Hier ist eine komplette Liste mit Beispielen zu finden.

GitOps mit Flux v2 für automatisierte Deployments

Ein wesentlicher Bestandteil der modernen Kubernetes-Verwaltung ist die automatisierte Bereitstellung und Konfigurationsverwaltung. Mit GitOps wird dieser Prozess optimiert, indem der gewünschte Zustand von Anwendungen und Clustern in einem Git-Repository versioniert und gespeichert wird.

Azure Arc ermöglicht die Nutzung von Flux v2, einem leistungsstarken Open-Source-Tool, das Kubernetes-Cluster kontinuierlich mit der definierten Konfiguration im Git-Repository synchronisiert. Änderungen werden automatisch erkannt und auf den Cluster angewendet – das minimiert manuelle Fehler und sorgt für konsistente Deployments.

Wie funktioniert GitOps mit Flux v2?

1. Definieren der Cluster- und Anwendungs-Konfiguration in einem Git-Repository.
2. Automatische Synchronisation: Flux v2 gleicht den aktuellen Zustand des Clusters mit der gespeicherten Konfiguration ab.
3. Erkennen von Änderungen: Falls Unterschiede festgestellt werden (z. B. ein neues Deployment), übernimmt Flux v2 die Aktualisierung.
4. Nachvollziehbare Deployments: Jede Änderung ist versioniert, wodurch eine einfache Nachverfolgung und Wiederherstellung möglich ist.

Vorteile von GitOps mit Flux v2 in Azure Arc

• Automatisierte Bereitstellungen ohne manuelle Eingriffe
• Versionskontrolle & Transparenz durch Git-Tracking
• Konsistenz und Sicherheit, da alle Änderungen dokumentiert sind
• Einfache Wiederherstellung, falls fehlerhafte Konfigurationen auftreten

GitOps mit Flux v2 ist somit eine ideale Lösung für Unternehmen, die hybride Kubernetes-Umgebungen mit Azure Arc verwalten und gleichzeitig CI/CD-Methoden für eine nahtlose Automatisierung integrieren möchten.

Fazit

Die Integration eines Kubernetes-Clusters mit Azure Arc bietet eine leistungsstarke Möglichkeit, hybride und Multi-Cloud-Umgebungen effizient zu verwalten. Mein Erfahrungsbericht zeigt, dass die Einrichtung mit K3s zwar grundsätzlich gut dokumentiert ist, aber dennoch einige Herausforderungen mit sich bringt, insbesondere bei der Systemkonfiguration und der richtigen Auswahl von Ressourcen.

Azure Arc ermöglicht eine zentrale Verwaltung von Clustern, ohne dass diese direkt in Azure laufen müssen, was eine enorme Flexibilität bietet. Besonders hervorzuheben ist die Möglichkeit, zentrale Sicherheitsrichtlinien und Governance-Mechanismen über Azure Policy durchzusetzen. Gleichzeitig sollten IT-Teams sich bewusst sein, dass die initiale Konfiguration und Optimierung je nach Umgebung variieren kann und ein gewisses Maß an Erfahrung mit Kubernetes und Azure-CLI erfordert.

Insgesamt überwiegen die Vorteile deutlich: Unternehmen können bestehende Kubernetes-Workloads ohne tiefgehende Umstrukturierung an die Azure-Managementebene anbinden. Wer sich mit hybriden Infrastrukturen auseinandersetzt, findet in Azure Arc eine starke Lösung – vorausgesetzt, man bringt die notwendige technische Expertise mit.

Nützliche Links

• Offizielle Dokumentation: Azure Arc Kubernetes
• Installation: Azure CLI
• Installation: K3s
• Kubernetes: Azure Policy Beispiele
• GitOps mit Flux: FluxCD Dokumentation