Overwegingen voor netwerktopologie en connectiviteit voor AKS

Ontwerpoverwegingen

Azure Kubernetes Service (AKS) biedt drie verschillende netwerkmodellen voor containernetwerken: Kubenet, CNI Overlay en CNI. Elk van deze modellen heeft zijn unieke set functies en voordelen, die flexibiliteit en schaalbaarheidsopties bieden voor containernetwerken in AKS.

Kubenet

Kubenet is een eenvoudige netwerkoplossing die IP-adresruimte bespaart en eenvoudige configuratie biedt. Het is ideaal voor kleine AKS-clusters met minder dan 400 knooppunten, waarbij het handmatig beheren en onderhouden van door de gebruiker gedefinieerde routes acceptabel is. Het is geschikt voor scenario's waarbij interne of externe load balancers voldoende zijn voor het bereiken van pods buiten het cluster.

Azure CNI

Azure CNI is een netwerkmodel dat is ontworpen voor geavanceerde netwerken. Het biedt volledige virtuele netwerkconnectiviteit voor pods, waardoor pod-naar-pod- en pod-naar-VM-connectiviteit mogelijk is. Het is ideaal voor scenario's waarin geavanceerde AKS-functies, zoals virtuele knooppunten, vereist zijn. Het is geschikt voor scenario's waarin voldoende IP-adresruimte beschikbaar is en externe resources rechtstreeks pods moeten bereiken. AKS-netwerkbeleid wordt ook ondersteund met Azure CNI.

Azure CNI-overlay

Azure CNI Overlay is ontworpen om tekorten aan IP-adressen aan te pakken en de netwerkconfiguratie te vereenvoudigen. Het is geschikt voor scenario's waarbij het schalen van maximaal 1000 knooppunten en 250 pods per knooppunt voldoende is en een extra hop voor podconnectiviteit acceptabel is. AKS-vereisten voor uitgaand verkeer kunnen ook worden voldaan aan Azure CNI-overlay.

Zie Netwerkmodellen vergelijken in AKS voor een overzicht van aanbevolen use cases per netwerkmodel.

Daarnaast is het belangrijk dat u bij het ontwerpen van uw AKS-cluster zorgvuldig de IP-adressering en grootte van het subnet van het virtuele netwerk plant ter ondersteuning van schalen. Virtuele knooppunten kunnen worden gebruikt voor snelle schaalaanpassing van clusters, maar er zijn enkele bekende beperkingen.

AKS-clusters ondersteunen Basic- en Standard Azure Load Balancer-SKU's en services kunnen worden weergegeven met openbare of interne load balancers. AKS maakt gebruik van CoreDNS om naamomzetting te bieden aan pods die in het cluster worden uitgevoerd en uitgaand (uitgaand) netwerkverkeer kan worden verzonden via een Azure Firewall- of virtueel netwerkapparaatcluster.

Standaard kunnen alle pods in een AKS-cluster zonder beperkingen verkeer verzenden en ontvangen. Kubernetes-netwerkbeleid kan echter worden gebruikt om de beveiliging te verbeteren en netwerkverkeer tussen pods in een AKS-cluster te filteren. Er zijn twee netwerkbeleidsmodellen beschikbaar voor AKS: Azure-netwerkbeleid en Calico.

Ten slotte stelt AKS een netwerkbeveiligingsgroep (NSG) in op het subnet waarin het cluster wordt geïmplementeerd. Het is raadzaam deze NSG niet handmatig te bewerken, maar services die in AKS zijn geïmplementeerd, kunnen dit beïnvloeden.

Over het algemeen kunt u het juiste netwerkmodel selecteren en netwerkbronnen zorgvuldig plannen om de prestaties, beveiliging en kosten van uw AKS-cluster te optimaliseren.

Privéclusters

Ip-zichtbaarheid van AKS-clusters kan openbaar of privé zijn. Privéclusters maken de Kubernetes-API beschikbaar via een privé-IP-adres, maar niet via een openbaar IP-adres. Dit privé-IP-adres wordt weergegeven in het virtuele AKS-netwerk via een privé-eindpunt. De Kubernetes-API mag niet worden geopend via het IP-adres, maar in plaats daarvan via de FQDN (Fully Qualified Domain Name). De oplossing van de Kubernetes-API-FQDN naar het IP-adres wordt doorgaans uitgevoerd door een Azure Privé-DNS-zone. Deze DNS-zone kan worden gemaakt door Azure in de resourcegroep van het AKS-knooppunt of u kunt een bestaande DNS-zone opgeven.

Volgens bewezen procedures op ondernemingsniveau wordt DNS-omzetting voor Azure-workloads aangeboden door gecentraliseerde DNS-servers die zijn geïmplementeerd in het connectiviteitsabonnement, in een virtueel hubnetwerk of in een virtueel netwerk van gedeelde services dat is verbonden met een Azure Virtual WAN. Met deze servers worden azure-specifieke en openbare namen voorwaardelijk omgezet met behulp van Azure DNS (IP-adres 168.63.129.16) en privénamen met behulp van bedrijfs-DNS-servers. Deze gecentraliseerde DNS-servers kunnen de AKS API-FQDN echter pas omzetten als ze zijn verbonden met de privézone DNS die voor het AKS-cluster is gemaakt. Elke AKS heeft een unieke PRIVÉ-DNS-zone, omdat een willekeurige GUID wordt voorbereid op de zonenaam. Voor elk nieuw AKS-cluster moet de bijbehorende privé-DNS-zone dus worden verbonden met het virtuele netwerk waar de centrale DNS-servers zich bevinden.

Alle virtuele netwerken moeten worden geconfigureerd voor het gebruik van deze centrale DNS-servers voor naamomzetting. Als het virtuele AKS-netwerk echter is geconfigureerd voor het gebruik van de centrale DNS-servers en deze DNS-servers nog niet zijn verbonden met de privé-DNS-zone, kunnen de AKS-knooppunten de FQDN van de Kubernetes-API niet omzetten en mislukt het maken van het AKS-cluster. Het virtuele AKS-netwerk moet alleen worden geconfigureerd voor het gebruik van de centrale DNS-servers nadat het cluster is gemaakt.

Zodra het cluster is gemaakt, wordt de verbinding gemaakt tussen de privé-DNS-zone en het virtuele netwerk waar de centrale DNS-servers worden geïmplementeerd. Het virtuele AKS-netwerk is ook geconfigureerd voor het gebruik van de centrale DNS-servers in het connectiviteitsabonnement en beheerderstoegang tot de AKS Kubernetes-API volgt deze stroom:

Notitie

De afbeeldingen in dit artikel weerspiegelen het ontwerp met behulp van het traditionele hub- en spoke-connectiviteitsmodel. Landingszones op ondernemingsniveau kunnen kiezen voor het Virtual WAN-connectiviteitsmodel, waarin de centrale DNS-servers zich in een virtueel netwerk van gedeelde services bevinden dat is verbonden met een Virtual WAN-hub.

1. De beheerder lost de FQDN van de Kubernetes-API op. De on-premises DNS-servers sturen de aanvraag door naar de gezaghebbende servers: de DNS-resolvers in Azure. Deze servers sturen de aanvraag door naar de Azure DNS-server (168.63.129.16), waarmee het IP-adres uit de Azure Privé-DNS-zone wordt opgehaald.
2. Nadat het IP-adres is omgezet, wordt verkeer naar de Kubernetes-API gerouteerd van on-premises naar de VPN- of ExpressRoute-gateway in Azure, afhankelijk van het connectiviteitsmodel.
3. Het privé-eindpunt heeft een /32 route geïntroduceerd in het virtuele hubnetwerk. De VPN- en ExpressRoute-gateways verzenden verkeer rechtstreeks naar het privé-eindpunt van de Kubernetes-API dat is geïmplementeerd in het virtuele AKS-netwerk.

Verkeer van toepassingsgebruikers naar het cluster

Binnenkomende controllers (inkomend verkeer) kunnen worden gebruikt om toepassingen beschikbaar te maken die worden uitgevoerd in de AKS-clusters.

• Toegangsbeheerobjectcontrollers bieden routering op toepassingsniveau ten koste van een lichte complexiteitsverhoging.
• Toegangsbeheerobjectcontrollers kunnen waf-functionaliteit (Web Application Firewall) bevatten.
• Toegangsbeheerobjectcontrollers kunnen off-cluster en in-cluster worden uitgevoerd:
  • Een controller voor inkomend verkeer buiten het cluster offload rekenkracht (zoals HTTP-verkeersroutering of TLS-beëindiging) naar een andere service buiten AKS, zoals de invoegtoepassing Azure-toepassing Gateway Ingress Controller (AGIC).
  • Een in-clusteroplossing verbruikt AKS-clusterresources voor berekening (zoals HTTP-verkeersroutering of TLS-beëindiging). Toegangsbeheerobjectcontrollers in het cluster kunnen lagere kosten bieden, maar ze vereisen zorgvuldige planning en onderhoud van resources.
• De eenvoudige HTTP-toepassingsrouteringsinvoegtoepassing is eenvoudig te gebruiken, maar heeft enkele beperkingen zoals beschreven in HTTP-toepassingsroutering.

Toegangsbeheerobjectcontrollers kunnen toepassingen en API's beschikbaar maken met een openbaar of privé-IP-adres.

• De configuratie moet worden afgestemd op het ontwerp voor uitgaand filteren om asymmetrische routering te voorkomen. UDR's kunnen asymmetrische routering (mogelijk) veroorzaken, maar niet noodzakelijkerwijs. Application Gateway kan SNAT gebruiken voor verkeer, wat betekent dat retourverkeer teruggaat naar het Application Gateway-knooppunt en niet naar UDR-route als UDR alleen is ingesteld voor internetverkeer.
• Als TLS-beëindiging vereist is, moet het beheer van TLS-certificaten worden overwogen.

Toepassingsverkeer kan afkomstig zijn van on-premises of het openbare internet. In de volgende afbeelding wordt een voorbeeld beschreven waarin een Azure-toepassing Gateway is geconfigureerd voor omgekeerde proxyverbindingen met de clusters, zowel on-premises als via het openbare internet.

Verkeer van on-premises volgt de stroom van de genummerde blauwe bijschriften in het vorige diagram.

1. De client lost de FQDN op die is toegewezen aan de toepassing, met behulp van de DNS-servers die zijn geïmplementeerd in het connectiviteitsabonnement of on-premises DNS-servers.
2. Nadat de FQDN van de toepassing is omgezet in een IP-adres (het privé-IP-adres van de toepassingsgateway), wordt verkeer gerouteerd via een VPN- of ExpressRoute-gateway.
3. Routering in het gatewaysubnet is geconfigureerd voor het verzenden van de aanvraag naar de webtoepassingsfirewall.
4. De Web Application Firewall verzendt geldige aanvragen naar de workload die wordt uitgevoerd in het AKS-cluster.

De Azure-toepassing Gateway in dit voorbeeld kan worden geïmplementeerd in hetzelfde abonnement als het AKS-cluster, omdat de configuratie nauw is gerelateerd aan de workloads die zijn geïmplementeerd in AKS en daarom wordt beheerd door hetzelfde toepassingsteam. Toegang vanaf internet volgt de stroom van de genummerde groene bijschriften in het vorige diagram.

1. Clients van het openbare internet zetten de DNS-naam voor de toepassing om met behulp van Azure Traffic Manager. U kunt ook andere wereldwijde taakverdelingstechnologieën, zoals Azure Front Door , gebruiken.
2. De openbare FQDN van de toepassing wordt door Traffic Manager omgezet in het openbare IP-adres van de toepassingsgateway, waartoe clients toegang hebben via het openbare internet.
3. De toepassingsgateway heeft toegang tot de workload die is geïmplementeerd in AKS.

Notitie

Deze stromen zijn alleen geldig voor webtoepassingen. Niet-webtoepassingen vallen buiten het bereik van dit artikel en kunnen worden weergegeven via de Azure Firewall in het virtuele hubnetwerk of de beveiligde virtuele hub als u het Virtual WAN-connectiviteitsmodel gebruikt.

U kunt ook de verkeersstromen voor webtoepassingen maken om zowel de Azure Firewall in het connectiviteitsabonnement als de WAF in het virtuele AKS-netwerk te doorlopen. Deze benadering biedt het voordeel van meer beveiliging, zoals het gebruik van filters op basis van Azure Firewall-intelligentie om verkeer van bekende schadelijke IP-adressen op internet te verwijderen. Het heeft echter ook enkele nadelen. Bijvoorbeeld het verlies van het oorspronkelijke CLIENT-IP-adres en de extra coördinatie tussen de firewall en de toepassingsteams bij het blootstellen van toepassingen. Dit komt doordat DNAT-regels (Destination Network Address Translation) nodig zijn in de Azure Firewall.

Verkeer van de AKS-pods naar back-endservices

De pods die in het AKS-cluster worden uitgevoerd, moeten mogelijk toegang hebben tot back-endservices, zoals Azure Storage, Azure SQL-databases of Azure Cosmos DB NoSQL-databases. Service-eindpunten voor virtuele netwerken en Private Link kunnen worden gebruikt om de connectiviteit met deze beheerde Azure-services te beveiligen.

Als u azure-privé-eindpunten gebruikt voor back-endverkeer, kan DNS-omzetting voor de Azure-services worden uitgevoerd met behulp van Azure Privé-DNS zones. Omdat de DNS-resolvers voor de hele omgeving zich in het virtuele hubnetwerk bevinden (of het virtuele netwerk van de gedeelde services als het virtual WAN-connectiviteitsmodel wordt gebruikt), moeten deze privézones worden gemaakt in het connectiviteitsabonnement. Als u de A-record wilt maken die is vereist om de FQDN van de privéservice om te zetten, kunt u de privé-DNS-zone (in het connectiviteitsabonnement) koppelen aan het privé-eindpunt (in het toepassingsabonnement). Voor deze bewerking zijn bepaalde bevoegdheden in deze abonnementen vereist.

Het is mogelijk om de A-records handmatig te maken, maar het koppelen van de privé-DNS-zone aan het privé-eindpunt resulteert in een installatie die minder gevoelig is voor onjuiste configuraties.

Back-endconnectiviteit van AKS-pods naar Azure PaaS-services die beschikbaar zijn via privé-eindpunten, volgen deze reeks:

1. De AKS-pods omzetten de FQDN van het Azure Platform as a Service (PaaS) met behulp van de centrale DNS-servers in het connectiviteitsabonnement, die zijn gedefinieerd als aangepaste DNS-servers in het virtuele AKS-netwerk.
2. Het opgeloste IP-adres is het privé-IP-adres van de privé-eindpunten, die rechtstreeks vanuit de AKS-pods worden geopend.

Verkeer tussen de AKS-pods en de privé-eindpunten per standaard gaat niet via de Azure Firewall in het virtuele hubnetwerk (of de beveiligde virtuele hub als u Virtual WAN gebruikt), zelfs niet als het AKS-cluster is geconfigureerd voor uitgaand filteren met Azure Firewall. De reden hiervoor is dat het privé-eindpunt een /32 route maakt in de subnetten van het virtuele netwerk van de toepassing, waar AKS wordt geïmplementeerd.

Ontwerpaanaanvelingen

• Als uw beveiligingsbeleid vereist dat de Kubernetes-API een privé-IP-adres heeft (in plaats van een openbaar IP-adres), implementeert u een privé-AKS-cluster.
  • Gebruik aangepaste privé-DNS-zones bij het maken van een privécluster in plaats van het maken van een privé-DNS-zone van het systeem te gebruiken.
• Gebruik Azure Container Networking Interface (CNI) als netwerkmodel, tenzij u een beperkt bereik van IP-adressen hebt die kunnen worden toegewezen aan het AKS-cluster.
  • Volg de documentatie over het plannen van IP-adressen met CNI.
  • Als u Windows Server-knooppuntgroepen en virtuele knooppunten wilt gebruiken om uiteindelijke beperkingen te controleren, raadpleegt u de veelgestelde vragen over Windows AKS-ondersteuning.
• Gebruik Azure DDoS Protection om het virtuele netwerk te beveiligen dat wordt gebruikt voor het AKS-cluster , tenzij u Azure Firewall of WAF in een gecentraliseerd abonnement gebruikt.
• Gebruik de DNS-configuratie die is gekoppeld aan de algehele netwerkinstallatie met Azure Virtual WAN of hub- en spoke-architectuur, Azure DNS-zones en uw eigen DNS-infrastructuur.
• Gebruik Private Link om netwerkverbindingen te beveiligen en privé-IP-verbindingen te gebruiken met andere beheerde Azure-services die ondersteuning bieden voor Private Link, zoals Azure Storage, Azure Container Registry, Azure SQL Database en Azure Key Vault.
• Gebruik een ingangscontroller om geavanceerde HTTP-routering en -beveiliging te bieden en om één eindpunt voor toepassingen te bieden.
• Alle webtoepassingen die zijn geconfigureerd voor het gebruik van inkomend verkeer, moeten TLS-versleuteling gebruiken en geen toegang toestaan via niet-versleutelde HTTP. Dit beleid wordt al afgedwongen als het abonnement de aanbevolen beleidsregels in Beleid bevat, inclusief referentie-implementaties van landingszones op ondernemingsniveau.
• Als u de reken- en opslagresources van uw AKS-cluster wilt besparen, gebruikt u een controller voor inkomend verkeer buiten het cluster.
  • Gebruik de invoegtoepassing Azure-toepassing Gateway Ingress Controller (AGIC), een door de eerste partij beheerde Azure-service.
  • Implementeer met AGIC een toegewezen Azure-toepassing Gateway voor elk AKS-cluster en deel niet dezelfde Application Gateway over meerdere AKS-clusters.
  • Als er geen resource- of operationele beperkingen zijn, of als AGIC de vereiste functies niet biedt, gebruikt u een controlleroplossing voor inkomend verkeer in clusters, zoals NGINX, Traefik of een andere door Kubernetes ondersteunde oplossing.
• Gebruik voor internetgerichte en beveiligingskritieke, interne webtoepassingen een webtoepassingsfirewall met de ingangscontroller.
  • Azure-toepassing Gateway en Azure Front Door integreren beide de Azure Web Application Firewall om webtoepassingen te beveiligen.
• Als uw beveiligingsbeleid vereist dat al het uitgaande internetverkeer dat wordt gegenereerd in het AKS-cluster wordt gecontroleerd, beveiligt u uitgaand netwerkverkeer met behulp van Azure Firewall of een virtueel netwerkapparaat van derden (NVA) dat is geïmplementeerd in het virtuele netwerk van de beheerde hub. Zie Uitgaand verkeer beperken voor meer informatie. Voor het uitgaande AKS-type UDR moet een routetabel worden gekoppeld aan het subnet van het AKS-knooppunt, zodat deze momenteel niet kan worden gebruikt met de dynamische route-injectie die wordt ondersteund door Azure Virtual WAN of Azure Route Server.
• Gebruik geautoriseerde IP-bereiken voor niet-privéclusters.
• Gebruik de Standard-laag in plaats van de Basic-laag van Azure Load Balancer.
• Bij het ontwerpen van een Kubernetes-cluster in Azure is een van de belangrijkste overwegingen het selecteren van het juiste netwerkmodel voor uw specifieke vereisten. Azure Kubernetes Service (AKS) biedt drie verschillende netwerkmodellen: Kubenet, Azure CNI en Azure CNI-overlay. Om een weloverwogen beslissing te nemen, is het essentieel om inzicht te hebben in de mogelijkheden en kenmerken van elk model.

Voor een functievergelijking tussen de drie netwerkmodellen in AKS; Kubenet, Azure CNI en Azure CNI Overlay, zie Netwerkmodellen vergelijken in AKS.