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 maximaal beschikbare toepassingen bouwen door uw toepassingen te verdelen.
- 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.
Kube-proxyonderdeel: kube-proxy wordt uitgevoerd op elk knooppunt en is verantwoordelijk voor het leveren van de benodigde netwerkfuncties.
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 in Azure, wordt tegelijkertijd de bijbehorende Azure Load Balancer-resource ingesteld.
- Wanneer u netwerkpoorten opent voor pods, configureert Azure automatisch de benodigde regels voor netwerkbeveiligingsgroepen.
- Azure kan ook externe DNS-configuraties beheren voor HTTP-toepassingsroutering, omdat er nieuwe toegangsbeheerroutes tot stand worden gebracht.
Virtuele netwerken van Azure
In AKS kunt u een cluster implementeren dat gebruikmaakt van een van de volgende netwerkmodellen:
Kubenet-netwerken
De netwerkbronnen worden doorgaans gemaakt en geconfigureerd als het AKS-cluster wordt geïmplementeerd.
CNI-netwerken (Azure Container Networking Interface)
Het AKS-cluster wordt verbonden met resources en configuraties van het bestaande virtuele netwerk.
Kubenet-netwerken (basis)
De kubenet-netwerkoptie is de standaardconfiguratie voor het maken van AKS-clusters. Met kubenet:
- Knooppunten ontvangen een IP-adres van het subnet van het virtuele Azure-netwerk.
- Pods ontvangen een IP-adres van een logisch andere adresruimte dan het subnet van het virtuele Azure-netwerk van de knooppunten.
- NAT (Network Address Translation) wordt vervolgens zo geconfigureerd dat de pods resources kunnen bereiken in het virtuele Azure-netwerk.
- Het bron-IP-adres van het verkeer wordt omgezet in het primaire IP-adres van het knooppunt.
Knooppunten gebruiken de Kubenet Kubernetes-invoegtoepassing. U kunt het Azure-platform de virtuele netwerken laten maken en configureren, of ervoor kiezen om uw AKS-cluster te implementeren in een bestaand subnet van een virtueel netwerk.
Alleen de knooppunten ontvangen een routeerbaar IP-adres. De pods gebruiken NAT om te communiceren met andere resources buiten het AKS-cluster. Deze aanpak vermindert het aantal IP-adressen dat u in uw netwerkruimte moet reserveren om pods te kunnen gebruiken.
Notitie
Hoewel kubenet de standaardnetwerkoptie is voor een AKS-cluster om een virtueel netwerk en subnet te maken, wordt dit niet aanbevolen voor productie-implementaties. Voor de meeste productie-implementaties moet u Azure CNI-netwerken plannen en gebruiken vanwege de superieure schaalbaarheids- en prestatiekenmerken.
Zie Kubenet-netwerken configureren voor een AKS-cluster voor meer informatie.
Azure CNI-netwerken (geavanceerd)
Met Azure CNI krijgt elke pod een IP-adres van het subnet en is deze rechtstreeks toegankelijk. Deze IP-adressen moeten vooraf worden gepland en uniek zijn in uw netwerkruimte. Elk knooppunt heeft een configuratieparameter voor het maximum aantal pods dat wordt ondersteund. Het equivalente aantal IP-adressen per knooppunt wordt vervolgens vooraf gereserveerd. Deze aanpak kan leiden tot uitputting van IP-adressen of de noodzaak om clusters in een groter subnet opnieuw op te bouwen naarmate uw toepassing toeneemt, zodat het belangrijk is om goed te plannen. Om deze planningsproblemen te voorkomen, is het mogelijk om de functie Azure CNI-netwerken in te schakelen voor dynamische toewijzing van IP-adressen en verbeterde subnetondersteuning.
Notitie
Vanwege kubernetes-beperkingen moet de naam van de resourcegroep, de naam van het virtuele netwerk en de subnetnaam 63 tekens of minder zijn.
In tegenstelling tot kubenet wordt verkeer naar eindpunten in hetzelfde virtuele netwerk niet vertaald (NAT) naar het primaire IP-adres van het knooppunt. Het bronadres voor verkeer in het virtuele netwerk is het IP-adres van de pod. Verkeer dat zich buiten het virtuele netwerk bevindt, is nog steeds naT's naar het primaire IP-adres van het knooppunt.
Knooppunten maken gebruik van de Azure CNI Kubernetes-invoegtoepassing.
Zie Azure CNI configureren voor een AKS-cluster voor meer informatie.
Azure CNI Overlay-netwerken
Azure CNI-overlay vertegenwoordigt een evolutie van Azure CNI, die betrekking heeft op schaalbaarheids- en planningsuitdagingen die voortvloeien uit de toewijzing van IP-adressen van virtuele netwerken aan pods. Azure CNI Overlay wijst privé-CIDR-IP's toe aan pods. De privé-IP-adressen staan los van het virtuele netwerk en kunnen opnieuw worden gebruikt in meerdere clusters. Azure CNI-overlay kan worden geschaald buiten de limiet van 400 knooppunten die worden afgedwongen in Kubenet-clusters. Azure CNI-overlay is de aanbevolen optie voor de meeste clusters.
Azure CNI Powered by Cilium
Azure CNI Powered by Cilium maakt gebruik van Cilium om krachtige netwerken, waarneembaarheid en afdwinging van netwerkbeleid te bieden. Het is systeemeigen geïntegreerd met Azure CNI Overlay voor schaalbaar IP-adresbeheer (IPAM).
Daarnaast dwingt Cilium standaard netwerkbeleid af, zonder dat hiervoor een afzonderlijke engine voor netwerkbeleid is vereist. Azure CNI Powered by Cilium kan worden geschaald buiten de limieten van Azure Network Policy Manager van 250 knooppunten/20-K pods met behulp van ePBF-programma's en een efficiëntere API-objectstructuur.
Azure CNI Powered by Cilium is de aanbevolen optie voor clusters waarvoor afdwinging van netwerkbeleid is vereist.
Bring your own CNI (Eigen CNI gebruiken)
Het is mogelijk om in AKS een niet-Microsoft CNI te installeren met behulp van de functie Bring Your Own CNI .
Netwerkmodellen vergelijken
Kubenet en Azure CNI bieden netwerkconnectiviteit voor uw AKS-clusters. Er zijn echter voor- en nadelen voor elk. Op hoog niveau zijn de volgende overwegingen van toepassing:
kubenet
- Bespaart IP-adresruimte.
- Maakt gebruik van interne of externe Load Balancers van Kubernetes om pods van buiten het cluster te bereiken.
- U beheert en onderhoudt door de gebruiker gedefinieerde routes (UDR's) handmatig.
- Maximaal 400 knooppunten per cluster.
Azure CNI
- Pods krijgen volledige virtuele netwerkconnectiviteit en kunnen rechtstreeks worden bereikt via hun privé-IP-adres van verbonden netwerken.
- Vereist meer IP-adresruimte.
| Netwerkmodel | Wanneer gebruiken |
|---|---|
| Kubenet | • Ip-adresruimte gesprek is een prioriteit. • Eenvoudige configuratie. • Minder dan 400 knooppunten per cluster. • Kubernetes interne of externe load balancers zijn voldoende voor het bereiken van pods buiten het cluster. • Het handmatig beheren en onderhouden van door de gebruiker gedefinieerde routes is acceptabel. |
| Azure CNI | • Volledige virtuele netwerkconnectiviteit is vereist voor pods. • Er zijn geavanceerde AKS-functies (zoals virtuele knooppunten) nodig. • Er is voldoende IP-adresruimte beschikbaar. • Pod-naar-pod- en podverbinding met virtuele machines is nodig. • Externe resources moeten pods rechtstreeks bereiken. • AKS-netwerkbeleid is vereist. |
| Azure CNI-overlay | • Tekort aan IP-adressen is een probleem. • Het schalen van maximaal 1000 knooppunten en 250 pods per knooppunt is voldoende. • Extra hop voor podconnectiviteit is acceptabel. • Eenvoudigere netwerkconfiguratie. • Aan de vereisten voor uitgaand verkeer van AKS kan worden voldaan. |
De volgende gedragsverschillen bestaan tussen kubenet en Azure CNI:
| Mogelijkheid | Kubenet | Azure CNI | Azure CNI-overlay | Azure CNI Powered by Cilium |
|---|---|---|---|---|
| Cluster implementeren in bestaand of nieuw virtueel netwerk | Ondersteund - UDR's handmatig toegepast | Ondersteund | Ondersteund | Ondersteund |
| Pod-pod-connectiviteit | Ondersteund | Ondersteund | Ondersteund | Ondersteund |
| Pod-VM-connectiviteit; VM in hetzelfde virtuele netwerk | Werkt wanneer deze wordt gestart door pod | Werkt op beide manieren | Werkt wanneer deze wordt gestart door pod | Werkt wanneer deze wordt gestart door pod |
| Pod-VM-connectiviteit; VM in gekoppeld virtueel netwerk | Werkt wanneer deze wordt gestart door pod | Werkt op beide manieren | Werkt wanneer deze wordt gestart door pod | Werkt wanneer deze wordt gestart door pod |
| On-premises toegang via VPN of Express Route | Werkt wanneer deze wordt gestart door pod | Werkt op beide manieren | Werkt wanneer deze wordt gestart door pod | Werkt wanneer deze wordt gestart door pod |
| Toegang tot resources die worden beveiligd door service-eindpunten | Ondersteund | Ondersteund | Ondersteund | |
| Kubernetes-services beschikbaar maken met behulp van een load balancer-service, App Gateway of toegangsbeheerobjectcontroller | Ondersteund | Ondersteund | Ondersteund | Dezelfde beperkingen bij het gebruik van de Overlay-modus |
| Ondersteuning voor Windows-knooppuntgroepen | Niet ondersteund | Ondersteund | Ondersteund | Alleen beschikbaar voor Linux en niet voor Windows. |
| Standaard Azure DNS en privézones | Ondersteund | Ondersteund | Ondersteund |
Zie Azure CNI-netwerken configureren in AKS en Kubenet gebruiken in AKS voor meer informatie over Azure CNI en kubenet en om te bepalen welke optie het meest geschikt is voor u.
Ondersteuningsbereik tussen netwerkmodellen
Ongeacht het netwerkmodel dat u gebruikt, kunnen kubenet en Azure CNI op een van de volgende manieren worden geïmplementeerd:
- Het Azure-platform kan automatisch de virtuele netwerkbronnen maken en configureren wanneer u een AKS-cluster maakt.
- U kunt de virtuele netwerkbronnen handmatig maken en configureren en deze koppelen aan deze resources wanneer u uw AKS-cluster maakt.
Hoewel mogelijkheden zoals service-eindpunten of UDR's worden ondersteund met kubenet en Azure CNI, definiëren de ondersteuningsbeleidsregels voor AKS welke wijzigingen u kunt aanbrengen. Voorbeeld:
- Als u handmatig de virtuele netwerkresources voor een AKS-cluster maakt, wordt u ondersteund bij het configureren van uw eigen UDR's of service-eindpunten.
- Als het Azure-platform automatisch de virtuele netwerkresources voor uw AKS-cluster maakt, kunt u deze door AKS beheerde resources niet handmatig wijzigen om uw eigen UDR's of service-eindpunten te configureren.
Toegangsbeheerobjectcontrollers
Wanneer u een LoadBalancer-service maakt, maakt u ook een onderliggende Azure Load Balancer-resource. De load balancer is geconfigureerd voor het distribueren van verkeer naar de pods in uw service op een bepaalde poort.
De LoadBalancer werkt alleen op laag 4. Op laag 4 is de service niet op de hoogte van de werkelijke toepassingen en kan er geen rekening mee worden gehouden met routering.
Toegangsbeheerobjectcontrollers werken op laag 7 en kunnen intelligentere regels gebruiken om toepassingsverkeer te distribueren. Toegangsbeheerobjectcontrollers routeren doorgaans HTTP-verkeer naar verschillende toepassingen op basis van de binnenkomende URL.
Opties voor inkomend verkeer vergelijken
De volgende tabel bevat de functieverschillen tussen de verschillende opties voor toegangsbeheerobjectcontroller:
| Functie | Invoegtoepassing voor toepassingsroutering | Application Gateway voor containers | Azure Service Mesh/service mesh op basis van Istio |
|---|---|---|---|
| Ingangs-/gatewaycontroller | NGINX-ingangscontroller | Azure-toepassing Gateway voor containers | Istio-ingangsgateway |
| API | Toegangsbeheerobject-API | Toegangsbeheerobject-API en gateway-API | Gateway-API |
| Hosting | In-cluster | Azure gehost | In-cluster |
| Schalen | Automatisch schalen | Automatisch schalen | Automatisch schalen |
| Load balancing | Intern/extern | External | Intern/extern |
| SSL-beëindiging | In-cluster | Ja: Offloading en E2E SSL | In-cluster |
| mTLS | N.v.t. | Ja naar back-end | N.v.t. |
| Statisch IP-adres | N.v.t. | FQDN | N.v.t. |
| Opgeslagen SSL-certificaten in Azure Key Vault | Ja | Ja | N.v.t. |
| Azure DNS-integratie voor DNS-zonebeheer | Ja | Ja | N.v.t. |
De volgende tabel bevat de verschillende scenario's waarin u elke ingangscontroller kunt gebruiken:
| Optie Inkomend verkeer | Wanneer gebruiken |
|---|---|
| Beheerde NGINX - invoegtoepassing voor toepassingsroutering | • In-cluster gehoste, aanpasbare en schaalbare NGINX-ingangscontrollers. • Basismogelijkheden voor taakverdeling en routering. • Interne en externe load balancer-configuratie. • Configuratie van statisch IP-adres. • Integratie met Azure Key Vault voor certificaatbeheer. • Integratie met Azure DNS-zones voor openbaar en privé-DNS-beheer. • Ondersteunt de toegangsbeheerobject-API. |
| Application Gateway voor containers | • Door Azure gehoste toegangsbeheergateway. • Flexibele implementatiestrategieën die worden beheerd door de controller of bring your own Application Gateway for Containers. • Geavanceerde functies voor verkeersbeheer, zoals automatische nieuwe pogingen, tolerantie van beschikbaarheidszones, wederzijdse verificatie (mTLS) naar back-enddoel, verkeer splitsen/gewogen round robin en automatisch schalen. • Integratie met Azure Key Vault voor certificaatbeheer. • Integratie met Azure DNS-zones voor openbaar en privé-DNS-beheer. • Ondersteunt de ingangs- en gateway-API's. |
| Istio-ingangsgateway | • Op basis van Envoy, bij gebruik met Istio voor een service-mesh. • Geavanceerde functies voor verkeersbeheer, zoals snelheidsbeperking en circuitonderbreking. • Ondersteuning voor mTLS • Ondersteunt de Gateway-API. |
Een toegangsbeheerobjectresource maken
De invoegtoepassing voor toepassingsroutering is de aanbevolen manier om een ingangscontroller in AKS te configureren. De invoegtoepassing voor toepassingsroutering is een volledig beheerde ingangscontroller voor Azure Kubernetes Service (AKS) die de volgende functies biedt:
Eenvoudige configuratie van beheerde NGINX-ingangscontrollers op basis van kubernetes NGINX-ingangscontroller.
Integratie met Azure DNS voor beheer van openbare en privézones.
SSL-beëindiging met certificaten die zijn opgeslagen in Azure Key Vault.
Zie Beheerde NGINX-ingangen met de invoegtoepassing voor toepassingsroutering voor meer informatie over de invoegtoepassing voor toepassingsroutering.
IP-behoud van clientbron
Configureer uw ingangscontroller om het IP-adres van de clientbron te behouden voor aanvragen voor containers in uw AKS-cluster. Wanneer de ingangscontroller de aanvraag van een client doorstuurt naar een container in uw AKS-cluster, is het oorspronkelijke bron-IP-adres van die aanvraag niet beschikbaar voor de doelcontainer. Wanneer u behoud van clientbron-IP inschakelt , is het bron-IP-adres voor de client beschikbaar in de aanvraagheader onder X-Forwarded-For.
Als u het IP-adres van de clientbron op uw ingangscontroller gebruikt, kunt u GEEN TLS-passthrough gebruiken. Ip-behoud van clientbronnen en TLS-passthrough kunnen worden gebruikt met andere services, zoals het type LoadBalancer .
Zie Hoe het behoud van IP-adressen van clientbronnen werkt voor LoadBalancer Services in AKS voor meer informatie over het behoud van IP-adressen van clientbronnen.
Uitgaand (uitgaand) verkeer beheren
AKS-clusters worden geïmplementeerd in een virtueel netwerk en hebben uitgaande afhankelijkheden van services buiten dat virtuele netwerk. Deze uitgaande afhankelijkheden zijn bijna volledig gedefinieerd met FQDN's (Fully Qualified Domain Names). 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 Uitgaand verkeer voor clusterknooppunten in AKS beheren voor meer informatie.
Netwerkbeveiligingsgroepen
Een netwerkbeveiligingsgroep filtert verkeer voor VM's zoals de AKS-knooppunten. Wanneer u Services maakt, zoals een LoadBalancer, configureert het Azure-platform automatisch de benodigde regels voor netwerkbeveiligingsgroepen.
U hoeft geen regels voor netwerkbeveiligingsgroepen handmatig te configureren om verkeer voor pods in een AKS-cluster te filteren. U kunt alle vereiste poorten definiëren en doorsturen als onderdeel van uw Kubernetes Service-manifesten en het Azure-platform de juiste regels laten maken of bijwerken.
U kunt ook netwerkbeleid gebruiken om verkeerfilterregels automatisch toe te passen op pods.
Zie Hoe netwerkbeveiligingsgroepen netwerkverkeer filteren voor meer informatie.
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 Verkeer tussen pods beveiligen 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 kubenet 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: