AKS-platform: netwerk¶
Deze pagina beschrijft het netwerkontwerp van de Azure-variant: de spoke, de twee netwerkmodi, egress, DNS, private endpoints en ingress. De Azure Local-variant gebruikt in plaats daarvan een bestaand logical network (AKS op Azure Local).
Referentieontwerp, jouw deployment kan afwijken
Adresbereiken en namen zijn de standaardwaarden van de referentieconfiguratie. Gebruik bereiken die niet overlappen met je andere netwerken. De ontwerpdocumenten beschrijven een egressmodel op basis van Azure Firewall. Waar de Terraform-code minder doet dan het ontwerp zegt, staat dat op deze pagina.
Netwerkmodi¶
De networking layer heeft twee modi en geeft in beide dezelfde outputs, zodat de layers erboven (cluster baseline,
secrets, security policy) niet veranderen. De modus is de variabele network_mode; de standaardwaarde is standalone, dus bestaande
deployments blijven werken.
standalone |
hub_integrated |
|
|---|---|---|
| Spoke VNet en subnets | Aangemaakt door de oplossing | Aangemaakt door de hub en landing zone, opgezocht op naam |
| Resource group | rg-<env>-network, aangemaakt |
De resource group van de spoke, opgezocht |
| Route table | rt-<env>-aks, aangemaakt, zonder routes, gekoppeld aan het node-subnet |
Geen. Egress volgt wat de hub propageert (routing intent of firewallroute) |
| Private DNS-zones | Aangemaakt in de spoke (standaard: privatelink.vaultcore.azure.net) en gekoppeld aan het VNet |
Eigendom van de hub. Hun ID's worden doorgegeven in een map zone_ids. De hub koppelt ze aan de spoke |
| Outbound type van AKS | loadBalancer |
userDefinedRouting |
| Publiek IP voor externe ingress | Aangemaakt (statisch, Standard SKU) | Niet aangemaakt. Inkomend verkeer komt via de hub binnen op een interne load balancer |
| Provider | Standaard azurerm |
Tweede azurerm-provider (alias hub) voor de spoke subscription, die een andere subscription kan zijn dan die van de state |
De bestaande standalone-omgevingen zijn met moved-blokken naar de nieuwe structuur verplaatst. Een plan op de live
non-productiestate toonde geen wijzigingen.
Regels per modus worden afgedwongen met output preconditions: spoke_config en hub_dns_config zijn verplicht in de hub-integrated modus,
en de CIDR's van het VNet en de subnets zijn verplicht in de standalone modus. Preconditions zijn boven validatie over meerdere variabelen
gekozen om Terraform op versie 1.5 of hoger te houden.
Indeling van de spoke¶
In beide modi zijn er vier subnets (in de hub-integrated modus worden de namen expliciet doorgegeven).
| Subnet | Doel | Referentiegrootte | Opmerkingen |
|---|---|---|---|
snet-aks-nodes-<env> |
Node-VM's | /21 (ongeveer 2.000 adressen) |
Bemeten op het maximale aantal nodes plus upgrade surge. De NSG staat VNet- en Azure load balancer-verkeer inkomend toe en weigert de rest. |
snet-ingress-<env> |
Frontends van de load balancer voor de ingress gateway | /24 |
|
snet-private-endpoints-<env> |
Netwerkinterfaces van private endpoints | /24 |
Netwerkbeleid voor private endpoints staat uit op dit subnet. |
snet-aks-api-<env> |
API server VNet integration | /28 |
Gedelegeerd aan Microsoft.ContainerService/managedClusters. |
Pods gebruiken geen VNet-adressen (overlay), dus de grootte van de subnets hangt alleen af van nodes en surge. Subnets kunnen niet worden aangepast zonder ze opnieuw aan te maken, dus bemeet ze ruim. Het ontwerp staat een hub met een eigen adresruimte toe voor de firewall, Bastion en DNS resolver; die worden niet door deze oplossing aangemaakt.
Netwerkprofiel van AKS¶
| Instelling | Waarde |
|---|---|
| Netwerkplugin | Azure CNI, overlay-modus |
| Network policy | Calico |
| Pod CIDR | Een bereik dat virtueel is en niet op het VNet wordt gerouteerd, dus het kan voor beide clusters hetzelfde zijn in standalone modus |
| Service CIDR en DNS service-IP | Een ander bereik per cluster; het DNS-IP moet binnen de service CIDR liggen |
| Outbound type | loadBalancer (standalone), userDefinedRouting (hub-integrated) |
Het ontwerpdocument zegt dat de network policy engine Azure Network Policy is in het hoofdstuk over de cluster baseline en Calico in het hoofdstuk over netwerk. De code stelt Calico in.
Egress¶
Ontwerp versus code
Het ontwerp beschrijft alle egress via Azure Firewall (default route 0.0.0.0/0 naar de firewall) met een NAT
gateway op het firewallsubnet voor schaalbare SNAT. De repository bevat modules voor de firewall, de NAT gateway en de DNS
resolver, maar de Azure-omgevingsroot gebruikt ze niet. In de standalone modus gebruikt het cluster de AKS load
balancer voor uitgaand verkeer en heeft de route table geen routes.
In de hub-integrated modus gebruikt het cluster user-defined routing en bepaalt de hub het pad. De codecommentaren beschrijven de hub-egress als routing intent die verkeer naar de Azure Firewall van de hub dwingt. Het ontwerpdocument beschrijft in plaats daarvan een default route naar het private IP van de hubfirewall, toegepast op alle vier de subnets, met een variabele om een route table van de hub uit te breiden. Het definitieve eigenaarschap van de route table staat in het ontwerp als open punt.
Als een firewall de egress controleert, moet die minimaal de door AKS vereiste endpoints toestaan. Het ontwerp noemt:
| Endpoint | Doel |
|---|---|
*.hcp.<region>.azmk8s.io |
Communicatie met de 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 |
Nodecomponenten en binaries |
*.blob.core.windows.net |
Bootstrappen van nodes |
| Endpoints voor OS-updates (Ubuntu of Azure Linux) | Securityupdates |
dc.services.visualstudio.com en de Azure Monitor-endpoints |
Telemetrie, als monitoring aan staat |
Ontbrekende regels laten de bootstrap van het cluster mislukken onder user-defined routing. Regels voor applicatieteams gelden per team en per omgeving; zie Firewallregels en IP groups voor hoe de MCP-hub dit doet.
Privétoegang tot Azure-services¶
Azure PaaS-services worden bereikt via private endpoints in het private endpoint-subnet, met public network access
uitgeschakeld op de service. Op dit moment maakt de oplossing één private endpoint aan: voor de Key Vault (sub-resource vault, zone
privatelink.vaultcore.azure.net). Het ontwerp noemt ook zones voor container registry, storage en databases als het patroon voor
latere services.
In de hub-integrated modus moet de hub privatelink.vaultcore.azure.net en privatelink.azurecr.io leveren. De
zone voor de container registry is volgens het ontwerp vereist, maar de oplossing maakt geen private endpoint voor de registry aan. Of de
hub levert er een, of die wordt later aan deze repository toegevoegd.
DNS¶
| Aspect | Ontwerp |
|---|---|
| Private DNS-zones | Eén zone per servicetype, gekoppeld aan het spoke VNet. In de hub-integrated modus eigendom van de hub. |
| Resolutie van namen van private endpoints | Via de gekoppelde zone, waarbij DNS zone groups de records aanmaken. |
| Hybrid DNS | Het ontwerp vereist on-premises resolutie via een Azure DNS Private Resolver in de hub, met inbound- en outbound-endpoints en forwarding rules. De resolvermodule bestaat in de repository maar is niet aan de omgeving gekoppeld. |
| Interne applicatienamen | Private DNS-zone of interne DNS-record voor de interne gateway. |
Zie DNS-ontwerp voor hoe de MCP-hub DNS afhandelt.
Ingress¶
Het ontwerp gebruikt de Kubernetes Gateway API, zodat het platform niet aan één ingress controller is gebonden.
| Eigenaar | Resources |
|---|---|
| Platformteam | GatewayClass, gedeelde Gateway, TLS-certificaten, load balancer en ingress-subnet |
| Workload team | HTTPRoute (of GRPCRoute) die naar zijn service wijst. Geen configuratie van load balancer, certificaat of controller |
Er kunnen zowel een interne als een externe Gateway bestaan, gebonden aan dezelfde GatewayClass. TLS eindigt standaard op de gateway;
passthrough en re-encrypt zijn opties. Het vervangen van de controller betekent een nieuwe GatewayClass en een gewijzigde verwijzing in de Gateway,
en de HTTPRoute-objecten blijven zoals ze zijn. De controller en de gateway-objecten worden door de platform
GitOps-repository gedeployd. Het loadtestontwerp noemt Traefik als controller van het referentiecluster voor non-productie.
Vereisten voor hub-integrated¶
De hub en landing zone moeten vóór de eerste run het volgende leveren:
- Een spoke VNet met de vier genoemde subnets, correct bemeten.
- Peering tussen hub en spoke.
- Een firewall of routing intent met regels voor de door AKS vereiste egress.
- Private DNS-zones voor de Key Vault en de container registry, gekoppeld aan het spoke VNet, met hun resource-ID's
beschikbaar voor
hub_dns_config. - Rechten voor de pipeline identity van deze oplossing op de spoke subscription: het VNet en de subnets lezen, en de role assignment Network Contributor op het spoke VNet aanmaken.
- Inkomend: de Application Gateway of firewall van de hub wijst naar de interne load balancer van de spoke. De oplossing stelt in deze modus geen publiek IP beschikbaar.
Zie Vereisten voor de volledige checklist.
Isolatie van omgevingen¶
| Niveau | Mechanisme |
|---|---|
| Productie versus non-productie | Aparte clusters in aparte spokes, geen spoke-naar-spoke-peering, aparte identities, groepen en state |
| Tussen teams en omgevingen in het non-productiecluster | Namespaces <team>-dev, <team>-test, <team>-accp, RBAC per namespace, default-deny network policy, quota's en limit ranges (Security policy) |
Het ontwerp accepteert isolatie via namespaces alleen voor non-productie. Namespace-isolatie beschermt niet tegen een container escape, wat een van de redenen is dat productie op een eigen cluster draait.