AKS-Plattform: Netzwerk¶

Diese Seite beschreibt das Netzwerkdesign der Azure-Variante: den spoke, die beiden Netzwerkmodi, Egress, DNS, Private Endpoints und Ingress. Die Azure-Local-Variante verwendet stattdessen ein bestehendes logisches Netzwerk (AKS on Azure Local).

Referenzdesign, dein Deployment kann abweichen

Adressbereiche und Namen sind die Defaults der Referenzkonfiguration. Verwende Bereiche, die sich nicht mit deinen anderen Netzwerken überschneiden. Die Design-Dokumente beschreiben ein auf Azure Firewall basierendes Egress-Modell. Wo der Terraform-Code weniger macht, als das Design sagt, steht das auf dieser Seite.

Netzwerkmodi¶

Der Networking-layer hat zwei Modi und stellt in beiden die gleichen Outputs bereit, damit die layers darüber (Cluster Baseline, Secrets, Security Policy) sich nicht ändern. Der Modus ist die Variable network_mode; der Default ist standalone, damit bestehende Deployments weiter funktionieren.

	`standalone`	`hub_integrated`
Spoke-VNet und Subnetze	Von der Lösung erstellt	Von hub und landing zone erstellt, per Name nachgeschlagen
Resource group	`rg-<env>-network`, erstellt	Die Resource group des spokes, nachgeschlagen
Route Table	`rt-<env>-aks`, erstellt, ohne Routen, dem Node-Subnet zugeordnet	Keine. Egress folgt dem, was der hub propagiert (Routing Intent oder Firewall-Route)
Private DNS zones	Im spoke erstellt (Default: `privatelink.vaultcore.azure.net`) und mit dem VNet verknüpft	Gehören dem hub. Ihre IDs werden in einer Map `zone_ids` übergeben. Der hub verknüpft sie mit dem spoke
AKS Outbound Type	`loadBalancer`	`userDefinedRouting`
Öffentliche IP für externes Ingress	Erstellt (statisch, Standard-SKU)	Nicht erstellt. Eingehender Verkehr kommt über den hub an einem internen Load Balancer an
Provider	Standard-`azurerm`	Zweiter `azurerm`-Provider (Alias `hub`) für die spoke subscription, die eine andere subscription als der State sein kann

Die bestehenden Standalone-Umgebungen wurden mit moved-Blöcken in die neue Struktur überführt. Ein plan auf dem Live-State der Nicht-Produktion zeigte keine Änderungen.

Die Regeln der Modi werden durch Output-Preconditions erzwungen: spoke_config und hub_dns_config sind im hub-integrierten Modus erforderlich, und die CIDRs für VNet und Subnetze sind im Standalone-Modus erforderlich. Preconditions wurden gegenüber variablenübergreifender Validierung bevorzugt, damit Terraform bei Version 1.5 oder höher bleiben kann.

Spoke-Layout¶

In beiden Modi gibt es vier Subnetze (im hub-integrierten Modus werden die Namen explizit übergeben).

Subnet	Zweck	Referenzgröße	Hinweise
`snet-aks-nodes-<env>`	Node-VMs	`/21` (etwa 2.000 Adressen)	Ausgelegt für die maximale Node-Anzahl plus Upgrade-Surge. Die NSG erlaubt eingehend Verkehr vom VNet und vom Azure Load Balancer und verweigert den Rest.
`snet-ingress-<env>`	Load-Balancer-Frontends des Ingress-Gateways	`/24`
`snet-private-endpoints-<env>`	Netzwerkschnittstellen der Private Endpoints	`/24`	Die Netzwerk-Policies für Private Endpoints sind auf diesem Subnet deaktiviert.
`snet-aks-api-<env>`	API-Server-VNet-Integration	`/28`	Delegiert an `Microsoft.ContainerService/managedClusters`.

Pods verwenden keine VNet-Adressen (Overlay), die Größe der Subnetze hängt also nur von Nodes und Surge ab. Subnetze lassen sich nicht ohne Neuerstellung in der Größe ändern, plane sie also großzügig. Das Design erlaubt einen hub mit eigenem Adressraum für Firewall, Bastion und DNS Resolver; diese werden von dieser Lösung nicht erstellt.

AKS-Netzwerkprofil¶

Einstellung	Wert
Network Plugin	Azure CNI, Overlay-Modus
Network Policy	Calico
Pod-CIDR	Ein Bereich, der virtuell und im VNet nicht geroutet ist, daher kann er im Standalone-Modus für beide Cluster derselbe sein
Service-CIDR und DNS-Service-IP	Ein anderer Bereich pro Cluster; die DNS-IP muss innerhalb des Service-CIDR liegen
Outbound Type	`loadBalancer` (Standalone), `userDefinedRouting` (hub-integriert)

Das Design-Dokument nennt die Network-Policy-Engine im Kapitel zur Cluster Baseline Azure Network Policy und im Kapitel zum Netzwerk Calico. Der Code setzt Calico.

Egress¶

Design und Code

Das Design beschreibt, dass der gesamte Egress über Azure Firewall läuft (Default-Route 0.0.0.0/0 zur Firewall), mit einem NAT Gateway am Firewall-Subnet für skalierbares SNAT. Das Repository enthält Module für Firewall, NAT Gateway und DNS Resolver, aber die Root der Azure-Umgebung verwendet sie nicht. Im Standalone-Modus nutzt der Cluster den AKS Load Balancer für ausgehenden Verkehr, und die Route Table hat keine Routen.

Im hub-integrierten Modus verwendet der Cluster User-defined Routing, und der hub bestimmt den Pfad. Die Code-Kommentare beschreiben den hub-Egress als Routing Intent, der den Verkehr zur Azure Firewall im hub zwingt. Das Design-Dokument beschreibt stattdessen eine Default-Route zur privaten IP der hub-Firewall, angewendet auf alle vier Subnetze, mit einer Variable, um eine Route Table des hubs zu erweitern. Wem die endgültige Route Table gehört, ist im Design als offen aufgeführt.

Wenn eine Firewall den Egress kontrolliert, muss sie mindestens die von AKS benötigten Endpoints erlauben. Das Design listet:

Endpoint	Zweck
`*.hcp.<region>.azmk8s.io`	Kommunikation mit dem AKS-API-Server
`mcr.microsoft.com`, `*.data.mcr.microsoft.com`	Microsoft Container Registry
`management.azure.com`	Azure Resource Manager
`login.microsoftonline.com`	Entra ID
`packages.microsoft.com`, `acs-mirror.azureedge.net`	Node-Komponenten und Binaries
`*.blob.core.windows.net`	Node-Bootstrapping
Endpoints für OS-Updates (Ubuntu oder Azure Linux)	Security-Updates
`dc.services.visualstudio.com` und die Azure-Monitor-Endpoints	Telemetrie, wenn Monitoring an ist

Fehlende Regeln lassen den Cluster-Bootstrap unter User-defined Routing scheitern. Regeln für Anwendungsteams gelten pro Team und pro Umgebung; siehe Firewallregeln und IP-Gruppen, wie der MCP-hub das handhabt.

Privater Zugriff auf Azure-Services¶

Azure-PaaS-Services werden über Private Endpoints im Private-Endpoint-Subnet erreicht, mit deaktiviertem öffentlichem Netzwerkzugriff am Service. Heute erstellt die Lösung einen Private Endpoint: für das Key Vault (Sub-Ressource vault, Zone privatelink.vaultcore.azure.net). Das Design listet außerdem Zonen für Container Registry, Storage und Datenbanken als Muster für spätere Services.

Im hub-integrierten Modus muss der hub privatelink.vaultcore.azure.net und privatelink.azurecr.io bereitstellen. Die Zone für die Container Registry verlangt das Design, aber die Lösung erstellt keinen Private Endpoint für die Registry. Entweder stellt ihn der hub bereit, oder er wird diesem Repository später hinzugefügt.

DNS¶

Aspekt	Design
Private DNS zones	Eine Zone pro Service-Typ, mit dem spoke-VNet verknüpft. Im hub-integrierten Modus gehören sie dem hub.
Auflösung von Private-Endpoint-Namen	Über die verknüpfte Zone, wobei DNS Zone Groups die Einträge erstellen.
Hybrides DNS	Das Design verlangt die Auflösung On-Premises über einen Azure DNS Private Resolver im hub, mit Inbound- und Outbound-Endpoints und Forwarding-Regeln. Das Resolver-Modul existiert im Repository, ist aber nicht in die Umgebung eingebunden.
Interne Anwendungsnamen	Private DNS zone oder interner DNS-Eintrag für das interne Gateway.

Siehe DNS-Design, wie der MCP-hub DNS handhabt.

Ingress¶

Das Design verwendet die Kubernetes Gateway API, damit die Plattform nicht an einen Ingress Controller gebunden ist.

Eigentümer	Ressourcen
Plattform-Team	`GatewayClass`, gemeinsames `Gateway`, TLS-Zertifikate, Load Balancer und Ingress-Subnet
Workload-Team	`HTTPRoute` (oder `GRPCRoute`), die auf seinen Service zeigt. Keine Konfiguration von Load Balancer, Zertifikat oder Controller

Es können sowohl ein internes als auch ein externes Gateway existieren, gebunden an dieselbe GatewayClass. TLS wird standardmäßig am Gateway terminiert; Passthrough und Re-Encrypt sind Optionen. Den Controller zu ersetzen bedeutet eine neue GatewayClass und eine geänderte Gateway- Referenz, und die HTTPRoute-Objekte bleiben unverändert. Der Controller und die Gateway-Objekte werden vom GitOps-Repository der Plattform deployt. Das Lasttest-Design nennt Traefik als Controller des Referenz-Nicht-Produktions-Clusters.

Voraussetzungen im hub-integrierten Modus¶

Der hub und die landing zone müssen vor dem ersten Lauf bereitstellen:

Ein spoke-VNet mit den vier benannten Subnetzen in passender Größe.
Peering zwischen hub und spoke.
Eine Firewall oder einen Routing Intent mit Regeln für den von AKS benötigten Egress.
Private DNS zones für das Key Vault und die Container Registry, mit dem spoke-VNet verknüpft, deren Ressourcen-IDs für hub_dns_config verfügbar sind.
Berechtigungen für die pipeline-Identity dieser Lösung auf der spoke subscription: das VNet und die Subnetze lesen und die Rollenzuweisung Network Contributor auf dem spoke-VNet erstellen.
Eingehend: Der Application Gateway oder die Firewall im hub zeigt auf den internen Load Balancer des spokes. Die Lösung stellt in diesem Modus keine öffentliche IP bereit.

Die vollständige Checkliste steht unter Voraussetzungen.

Umgebungsisolation¶

Ebene	Mechanismus
Produktion gegenüber Nicht-Produktion	Getrennte Cluster in getrennten spokes, kein spoke-zu-spoke-Peering, getrennte Identities, Gruppen und State
Zwischen Teams und Umgebungen im Nicht-Produktions-Cluster	Namespaces `<team>-dev`, `<team>-test`, `<team>-accp`, Namespace-bezogenes RBAC, Default-Deny-Network-Policy, Quotas und Limit Ranges (Security Policy)

Das Design akzeptiert Namespace-Isolation nur für die Nicht-Produktion. Namespace-Isolation schützt nicht vor einem Container Escape, einer der Gründe, warum die Produktion auf einem eigenen Cluster läuft.