Netwerkconcepten voor toepassingen in Azure Kubernetes Service (AKS)

In een containergebaseerde microservicesbenadering voor toepassingsontwikkeling werken toepassingsonderdelen samen om hun taken te verwerken. Kubernetes biedt verschillende resources die deze samenwerking mogelijk maken:

  • U kunt intern of extern verbinding maken met toepassingen en deze beschikbaar maken.
  • U kunt hoog beschikbare toepassingen bouwen door belastingsverdeling toe te passen op uw toepassingen.
  • U kunt de stroom van netwerkverkeer naar of tussen pods en knooppunten beperken om de beveiliging te verbeteren.
  • U kunt inkomend verkeer configureren voor SSL/TLS-beëindiging of routering van meerdere onderdelen voor uw complexere toepassingen.

In dit artikel worden de belangrijkste concepten geïntroduceerd die netwerken bieden voor uw toepassingen in AKS:

Basisbeginselen van Kubernetes-netwerken

Kubernetes maakt gebruik van een virtuele netwerklaag voor het beheren van toegang binnen en tussen uw toepassingen of hun onderdelen:

  • Kubernetes-knooppunten en virtueel netwerk: Kubernetes-knooppunten zijn verbonden met een virtueel netwerk. Met deze instelling kunnen pods (basiseenheden van implementatie in Kubernetes) zowel binnenkomende als uitgaande connectiviteit hebben.

  • Servicerouteringsonderdeel: afhankelijk van het netwerkgegevensvlak gebruiken kube-proxy knooppunten ofwel Cilium voor Kubernetes Service-routering. AKS-clusters die gebruikmaken van Azure CNI Powered by Cilium gebruiken kube-proxy niet.

Met betrekking tot specifieke Kubernetes-functies:

  • Load balancer: U kunt een load balancer gebruiken om netwerkverkeer gelijkmatig over verschillende resources te verdelen.
  • Ingangscontrollers: deze faciliteren laag 7-routering, wat essentieel is voor het omleiden van toepassingsverkeer.
  • Uitgaand verkeer beheren: Met Kubernetes kunt u uitgaand verkeer van clusterknooppunten beheren en beheren.
  • Netwerkbeleid: Met deze beleidsregels kunt u beveiligingsmaatregelen en filters voor netwerkverkeer in pods inschakelen.

In de context van het Azure-platform:

  • Azure stroomlijnt virtuele netwerken voor AKS-clusters (Azure Kubernetes Service).
  • Als u een Kubernetes-load balancer maakt op Azure stelt u tegelijkertijd de bijbehorende Azure load balancer-resource in.
  • Wanneer u een Kubernetes-service LoadBalancer maakt, configureert Azure de benodigde regels voor netwerkbeveiligingsgroepen voor serviceverkeer op resources die worden beheerd door AKS.
  • Azure kan ook externe DNS-configuraties beheren voor routering van HTTP-toepassingen, wanneer er nieuwe Ingress-routes worden vastgesteld.

virtuele netwerken Azure

In AKS kunt u een cluster implementeren dat gebruikmaakt van een van de volgende netwerkmodellen:

  • Overlay-netwerkmodel: Overlay-netwerken is het meest voorkomende netwerkmodel dat wordt gebruikt in Kubernetes. Pods krijgen een IP-adres van een privé,logisch gescheiden CIDR van het Azure subnet van het virtuele netwerk waarin AKS-knooppunten worden geïmplementeerd. Dit model maakt eenvoudigere, verbeterde schaalbaarheid mogelijk in vergelijking met het platte netwerkmodel.
  • Plat netwerkmodel: Een plat netwerkmodel in AKS wijst IP-adressen toe aan pods vanuit een subnet in hetzelfde Azure virtueel netwerk als de AKS-knooppunten. Voor privénetwerkverkeer is het bron-IP-adres dat een bestemming ziet, afhankelijk van de ip-adresbeheeroptie (IPAM). Azure CNI Pod Subnet behoudt het IP-adres van de pod in verbonden virtuele netwerken. Met Azure CNI-knooppuntsubnet wordt voor bestemmingen in het virtuele netwerk van het cluster het IP-adres van de pod weergegeven, maar voor bestemmingen buiten het virtuele netwerk van het cluster het IP-adres van het knooppunt. Voor uitgaand internetverkeer bepaalt de geconfigureerde uitgaande methode het openbare bron-IP-adres dat internetbestemmingen zien.

Zie CNI-netwerken in AKS voor meer informatie over netwerkmodellen in AKS.

Uitgaand verkeer beheren

AKS-clusters worden geïmplementeerd in een virtueel netwerk en hebben uitgaande afhankelijkheden van services buiten dat virtuele netwerk, die bijna volledig zijn gedefinieerd met FQDN's (Fully Qualified Domain Names). AKS biedt verschillende opties voor uitgaande configuratie waarmee u de manier kunt aanpassen waarop deze externe resources worden geopend.

Belangrijk

Vanaf March 31, 2026 biedt Azure Kubernetes Service (AKS) geen ondersteuning meer voor standaard uitgaande toegang voor virtuele machines (VM's). Nieuwe AKS-clusters die gebruikmaken van de optie voor het virtuele AKS-netwerk plaatsen clustersubnetten standaard in privésubnetten (defaultOutboundAccess = false). Deze instelling heeft geen invloed op door AKS beheerd clusterverkeer, dat expliciet geconfigureerde uitgaande paden gebruikt. Dit kan van invloed zijn op niet-ondersteunde scenario's, zoals het implementeren van andere resources in hetzelfde subnet. Clusters die gebruikmaken van BYO-VNets, worden niet beïnvloed door deze wijziging. In ondersteunde configuraties is geen actie vereist. Voor meer informatie over deze buitengebruikstelling, zie de Azure Updates aankondiging van de pensionering. Als u op de hoogte wilt blijven van aankondigingen en updates, volgt u de releaseopmerkingen van AKS.

Opties voor uitgaande configuratie

Zie voor meer informatie over de ondersteunde uitgaande configuratietypen van AKS-clusters Customize cluster egress with outbound types in Azure Kubernetes Service (AKS).

AKS-clusters hebben standaard onbeperkte uitgaande (uitgaande) internettoegang, waardoor de knooppunten en services die u uitvoert, naar behoefte toegang hebben tot externe resources. Desgewenst kunt u uitgaand verkeer beperken.

Zie voor meer informatie over het beperken van uitgaand verkeer van uw cluster Uitgaand verkeer voor clusterknooppunten beheren in AKS.

Netwerkbeveiligingsgroepen

Een netwerkbeveiligingsgroep filtert verkeer voor VM's zoals de AKS-knooppunten. Wanneer u Services maakt, zoals eenLoadBalancer, configureert het Azure-platform automatisch de benodigde regels voor netwerkbeveiligingsgroepen voor serviceverkeer op resources die worden beheerd door AKS.

AKS past geen netwerkbeveiligingsgroepen toe op het subnet of wijzigt netwerkbeveiligingsgroepen die u koppelt aan een door de klant verstrekt subnet. Als u een netwerkbeveiligingsgroep koppelt aan een aangepast subnet, moet u ervoor zorgen dat de regels het vereiste knooppunt- en podverkeer toestaan. Zie AKS CNI-netwerkvereisten voor meer informatie.

U kunt ook netwerkbeleid gebruiken om verkeerfilterregels automatisch toe te passen op pods.

Zie Hoe netwerkbeveiligingsgroepen netwerkverkeer filteren voor meer informatie.

Vereisten voor aangepast virtueel netwerk

Wanneer u een aangepast virtueel netwerk met AKS-clusters gebruikt en u regels voor netwerkbeveiligingsgroepen toevoegt om verkeer tussen subnetten te beperken, moet u ervoor zorgen dat de regels het verkeer toestaan dat is vereist voor de clusterconfiguratie.

VNet-integratie van API Server is vooraf geconfigureerd in AKS Automatic. In AKS Standard is de functie optioneel en moet u deze expliciet inschakelen. Wanneer uw cluster gebruikmaakt van API Server VNet-integratie, staat u het volgende verkeer toe:

Bestemming Bron protocol Porto Gebruik
APIServer Subnetwerk CIDR Clustersubnet TCP 443 en 4443 Vereist om communicatie tussen knooppunten en de API-server mogelijk te maken.
APIServer Subnetwerk CIDR Azure Load Balancer TCP 9988 Vereist om communicatie mogelijk te maken tussen Azure Load Balancer en de API-server. U kunt ook alle communicatie tussen de Azure Load Balancer en de CIDR van het API Server-subnet inschakelen.

Zie VNet-integratie van API Server voor meer informatie.

Sta voor communicatie tussen knooppunten en pods het volgende verkeer toe wanneer regels voor netwerkbeveiligingsgroepen de bijbehorende CIDR-bereiken beperken:

Bestemming Bron protocol Porto Gebruik
Knooppunt-CIDR Knooppunt-CIDR Alle protocollen Alle poorten Vereist om communicatie tussen knooppunten mogelijk te maken.
Pod CIDR Knooppunt-CIDR Alle protocollen Alle poorten Vereist voor serviceverkeersroutering.
Pod CIDR Pod CIDR Alle protocollen Alle poorten Vereist voor Pod-naar-Pod- en Pod-naar-Serviceverkeer, inclusief DNS.

Het toepasselijke knooppunt- en POD CIDR-bereik is afhankelijk van het netwerkmodel van uw cluster. Zie AKS CNI-netwerkvereisten voor meer informatie.

DNS-resolutie

DNS-omzetting is essentieel voor servicedetectie en -communicatie in AKS. AKS maakt standaard gebruik van CoreDNS om interne naamomzetting voor pods en services te bieden.

Voor verbeterde DNS-prestaties en betrouwbaarheid biedt AKS LocalDNS, waarmee een DNS-proxy op elk knooppunt wordt geïmplementeerd. LocalDNS lost queries lokaal op, vermindert latentie en elimineert conntrack druk op de tabel van DNS-verkeer. U kunt LocalDNS configureren om reacties in de cache te verwerken tijdens upstream DNS-storingen, maar verouderde-antwoordcaching werkt op basis van best effort. LocalDNS is met name nuttig in grote clusters of omgevingen met hoge DNS-queryvolumes.

LocalDNS is vooraf geconfigureerd in AKS Automatic. In AKS Standard is LocalDNS optioneel en geconfigureerd per knooppuntgroep. Voordat u deze inschakelt in AKS Standard, controleert u de Kubernetes-versie, het knooppuntbesturingssysteem en de VM-SKU-vereisten. Het inschakelen van LocalDNS op een bestaande nodepool zorgt ervoor dat de knooppunten opnieuw van een image worden voorzien. Zie LocalDNS configureren voor vereisten en implementatieplanning.

Netwerkbeleid

Standaard kunnen alle pods in een AKS-cluster zonder beperkingen verkeer verzenden en ontvangen. Voor een betere beveiliging definieert u regels waarmee de verkeersstroom wordt beheerd, zoals:

  • Back-endtoepassingen worden alleen blootgesteld aan vereiste front-endservices.
  • Databaseonderdelen zijn alleen toegankelijk voor de toepassingslagen die er verbinding mee maken.

Netwerkbeleid is een Kubernetes-functie die beschikbaar is in AKS waarmee u de verkeersstroom tussen pods kunt beheren. U kunt verkeer naar de pod toestaan of weigeren op basis van instellingen zoals toegewezen labels, naamruimte of verkeerspoort. Hoewel netwerkbeveiligingsgroepen beter zijn voor AKS-knooppunten, zijn netwerkbeleidsregels een meer geschikte, cloudeigen manier om de verkeersstroom voor pods te beheren. Omdat pods dynamisch worden gemaakt in een AKS-cluster, kunnen vereiste netwerkbeleidsregels automatisch worden toegepast.

Zie Onveilig verkeer tussen pods met behulp van netwerkbeleid in Azure Kubernetes Service (AKS) voor meer informatie.

Volgende stappen

Als u aan de slag wilt met AKS-netwerken, maakt en configureert u een AKS-cluster met uw eigen IP-adresbereiken met behulp van Azure CNI-overlay of Azure CNI.

Zie Best practices voor netwerkconnectiviteit en -beveiliging in AKS voor de bijbehorende aanbevolen procedures.

Zie de volgende artikelen voor meer informatie over de belangrijkste Kubernetes- en AKS-concepten:

  • Last updated on