AKS-Plattform: AKS on Azure Local¶
Diese Seite beschreibt die zweite Variante der Lösung: AKS on Azure Local (auch AKS Arc genannt). Der Kubernetes-Cluster läuft auf Azure-Local-Hardware in einem Rechenzentrum und wird über Azure Arc verwaltet. Die Management Plane liegt in Azure, die Runtime Plane On-Premises.
Weniger vollständig als die Azure-Variante
Die Quellen dokumentieren das Design, das Bootstrap-Skript und die pipelines für diese Variante. In den eingecheckten Konfigurationsdateien
ist jeder layer-Schalter (deploy_identity, deploy_cluster_baseline, deploy_arc_networking, deploy_argocd,
deploy_azure_policy_extension, deploy_security_policy, deploy_key_vault) auf false gesetzt. Diese Dokumentation kann nicht sagen,
welche layers in einer Live-Umgebung aktiv sind. Frag dein Plattform-Team.
Unterschiede zur Azure-Variante¶
| Aspekt | AKS in Azure | AKS on Azure Local |
|---|---|---|
| Management Plane | Azure | Azure und Azure Arc |
| Runtime Plane | Azure | Azure Local, On-Premises |
| Cluster-Ressource | Terraform (azurerm_kubernetes_cluster) |
Azure CLI (az aksarc create) in einem Bootstrap-Schritt |
| Netzwerk | VNet, Subnetze, NSG | Ein logisches Netzwerk, das bereits existiert. Terraform reicht nur seine ID durch |
| Control Plane | Von Azure verwaltet | Läuft auf Azure-Local-Hardware |
| Load Balancing | Azure Load Balancer | MetalLB, aktiviert durch die Arc-Networking-Extension und konfiguriert mit az k8s-runtime |
| GitOps | Argo CD aus dem GitOps-Repository | Argo CD als Arc-Extension (microsoft.argocd) |
| Policy | Azure-Policy-Add-on | Azure-Policy-Extension für Arc (microsoft.policyinsights) |
| Workload Identity | In AKS integriert | Wird beim Erstellen des Clusters aktiviert (--enable-oidc-issuer --enable-workload-identity) |
| Identität und Secrets | Entra ID, Managed Identities, Key Vault | Dieselben gemeinsamen Module |
| Defender for Containers | Optional | Auf Azure Local nicht unterstützt |
| Von AKS verwaltete Add-ons | Verfügbar | Nicht verfügbar, stattdessen werden Arc-Extensions verwendet |
| Pipeline | GitHub Actions | Azure DevOps (vom Kunden bereitgestellter Agent) oder GitHub Actions |
Was Terraform verwaltet und was nicht¶
| Nicht von Terraform verwaltet | Grund |
|---|---|
| Der Azure-Local-Cluster | Physische Infrastruktur mit eigenem Lebenszyklus |
| Arc Resource Bridge, Custom Location, logisches Netzwerk | Voraussetzungen, müssen existieren und gesund sein (Voraussetzungen) |
| VNets, Subnetze, NSGs, Firewall, NAT Gateway | Nicht zutreffend, physisches oder Software-defined Networking |
| API-Server-VNet-Integration | Nicht zutreffend, die Control Plane liegt On-Premises |
| AKS-Cluster, OIDC Issuer, Workload Identity | Werden vom Bootstrap erstellt |
| MetalLB Load Balancer und BGP Peers | Werden vom Bootstrap mit az k8s-runtime erstellt |
| Von Terraform verwaltet | Ressource |
|---|---|
| Arc-Extensions: Argo CD, Azure Policy, Arc Networking | azurerm_arc_kubernetes_cluster_extension |
| Entra-ID-Gruppen, Break-glass-Gruppe | azuread_group (gemeinsames Modul) |
| Managed Identities und Federated Credentials | azurerm_user_assigned_identity, azurerm_federated_identity_credential |
| Azure-Rollenzuweisungen | azurerm_role_assignment |
| Key Vault | azurerm_key_vault, in dieser Variante ohne Private Endpoint |
| Azure-Policy-Zuweisung (Pod-Security-Baseline) | azurerm_resource_group_policy_assignment |
| Resource groups | rg-<env>-identity-arc, rg-<env>-secrets-arc, rg-<env>-security-arc |
Reihenfolge des Deployments¶
flowchart TB
pre["Prerequisites:<br/>Azure Local, Arc Resource Bridge,<br/>custom location, logical network,<br/>firewall path to the control plane"] --> boot
boot["Phase 1: bootstrap<br/>(PowerShell and Azure CLI)"] --> tf
tf["Phase 2: Terraform<br/>(extensions, identity, policy, Key Vault)"] --> gitops
gitops["Argo CD applies the GitOps repositories"]Phase 1: Bootstrap¶
Das Bootstrap-Skript validiert seine Eingaben, stellt sicher, dass die Azure-CLI-Extensions aksarc und k8s-runtime vorhanden sind,
registriert die Resource Provider, die es braucht, und dann:
- erstellt es die Resource group, falls sie nicht existiert;
- erstellt es den AKS-Arc-Cluster mit der Custom Location, dem logischen Netzwerk, der Entra-ID-Admin-Gruppe, der Erzeugung eines SSH-Keys und eingeschaltetem OIDC Issuer und Workload Identity. Wenn der Cluster existiert, überspringt es die Erstellung;
- prüft es, ob der OIDC Issuer aktiviert ist, und liest seine URL;
- aktiviert es die Arc-Networking-Runtime für MetalLB (mit einem Fallback, der die Extension
microsoft.arcnetworkinginstalliert); - erstellt es den MetalLB Load Balancer mit dem IP-Bereich und dem Advertise-Modus (
ARP,BGPoderBoth); - erstellt es einen BGP Peer, wenn der Modus einen braucht (dann sind Peer-Name, beide AS-Nummern und die Peer-Adresse erforderlich);
- schreibt es die Cluster-ID und die OIDC-Issuer-URL in eine Output-Datei.
Registrierte oder geprüfte Resource Provider: Microsoft.Kubernetes, Microsoft.KubernetesConfiguration,
Microsoft.ExtendedLocation, Microsoft.AzureStackHCI, Microsoft.KubernetesRuntime. Das Design-Dokument nennt außerdem
Microsoft.HybridConnectivity und Microsoft.ResourceConnector.
Phase 2: Terraform¶
Terraform braucht zwei Werte aus dem Bootstrap, cluster_id und oidc_issuer_url. Die pipeline schreibt sie zur Laufzeit in
config/ci.auto.tfvars, aus dem Bootstrap-Output, wenn beide im selben Lauf liefen, sonst aus pipeline- oder
Umgebungsvariablen. Dann werden die layers mit den Schaltern aktiviert, in dieser Reihenfolge:
| Schritt | Schalter | Ergebnis |
|---|---|---|
| 1 | deploy_cluster_baseline |
Container für die Extensions |
| 2 | deploy_argocd |
Argo-CD-Extension, Release Train standardmäßig Stable |
| 3 | deploy_azure_policy_extension |
Azure Policy für Arc |
| 4 | deploy_arc_networking |
Arc-Networking-Extension für MetalLB |
| 5 | deploy_identity |
Gruppen, Identities, Federated Credentials |
| 6 | deploy_security_policy |
Initiative Pod-Security-Baseline auf der Resource group des Clusters, Effect Audit |
| 7 | deploy_key_vault |
Key Vault |
Terraform installiert nur die Argo-CD-Extension. Applications, Application Sets und Projects kommen aus den GitOps-Repositories.
Das erwartete GitOps-Layout ist ein Ordner pro Cluster und Umgebung (clusters/azure-local/nonprod, .../prod) sowohl im
Plattform- als auch im Anwendungs-Repository.
Arc Networking und ein Service Principal
Die Arc-Networking-Extension kann die Object-ID eines Microsoft-First-Party-Service-Principals brauchen
(arc_networking_fpa_object_id). Der Bootstrap versucht, sie in seinem Fallback-Pfad aufzulösen, und bricht mit einer Meldung ab, wenn er das
nicht kann. Wenn dein Konto keine Leseberechtigung für das Verzeichnis hat, gib die ID in der Konfiguration an.
Nicht verfügbar oder unklar¶
- Key-Vault-Zugriff vom Cluster aus. Das gemeinsame Key-Vault-Modul deaktiviert den öffentlichen Netzwerkzugriff, und die Azure-Local- Variante erstellt keinen Private Endpoint. Ein Cluster On-Premises erreicht den Vault dann nicht, es sei denn, das Netzwerkdesign ergänzt einen privaten Pfad. Die Quellen beschreiben keinen.
- Kubernetes-Policy und RBAC aus GitOps sind für die Azure-Variante beschrieben. Die Azure-Local-Seiten nennen nur die ArgoCD-Extension und das GitOps-Ordner-Layout.
- Node-Pool-Größen, Upgrades und Wartungsfenster des Azure-Local-Clusters legt diese Lösung nicht fest. Das
Bootstrap-Skript erstellt den Cluster mit den Standardgrößen von
az aksarc create. - Monitoring und Backup für Azure Local sind nicht beschrieben.