Netwerkconcepten voor toepassingen in Azure Kubernetes Service (AKS)
In een op containers gebaseerde benadering van microservices voor het ontwikkelen van toepassingen, 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 openbaar maken.
- U kunt toepassingen met hoge beschikbare toepassingen bouwen door taakverdeling voor uw toepassingen uit te brengen.
- Voor uw complexere toepassingen kunt u ingressverkeer configureren voor SSL/TLS-beëindiging of routering van meerdere onderdelen.
- Uit veiligheidsoverwegingen kunt u de stroom van netwerkverkeer naar of tussen pods en knooppunten beperken.
In dit artikel worden de belangrijkste concepten beschreven die netwerken bieden aan uw toepassingen in AKS:
Basisbeginselen voor Kubernetes
Kubernetes biedt een abstractielaag voor virtuele netwerken om toegang tot uw toepassingen of tussen toepassingsonderdelen toe te staan. Kubernetes-knooppunten maken verbinding met een virtueel netwerk en bieden binnenkomende en uitgaande connectiviteit voor pods. Het onderdeel kube-proxy wordt op elk knooppunt uitgevoerd om deze netwerkfuncties te bieden.
In Kubernetes:
- Services groeperen pods logisch om directe toegang op een specifieke poort mogelijk te maken via een IP-adres of DNS-naam.
- U kunt verkeer distribueren met behulp van een load balancer.
- Complexere routering van toepassingsverkeer kan ook worden bereikt met ingress-controllers.
- Beveiliging en filtering van het netwerkverkeer voor pods is mogelijk met Kubernetes-netwerkbeleid.
Het Azure-platform vereenvoudigt ook virtuele netwerken voor AKS-clusters. Wanneer u een Kubernetes-load balancer, maakt en configureert u ook de onderliggende Azure load balancer resource. Wanneer u netwerkpoorten voor pods opent, worden de bijbehorende regels voor Azure-netwerkbeveiligingsgroep geconfigureerd. Voor HTTP-toepassingsroutering kan Azure ook externe DNS configureren wanneer nieuwe toegangsroutes worden geconfigureerd.
Services
Ter vereenvoudiging van de netwerkconfiguratie maakt Kubernetes gebruik van Services om een set pods logisch te groeperen en netwerkconnectiviteit mogelijk te maken. De volgende servicetypen zijn beschikbaar:
CLUSTER-IP
Hiermee maakt u een intern IP-adres voor gebruik binnen het AKS-cluster. Goed voor interne toepassingen die ondersteuning bieden voor andere workloads in het cluster.
NodePort
Hiermee maakt u een poorttoewijzing op het onderliggende knooppunt waarmee de toepassing rechtstreeks kan worden gebruikt met het IP-adres en de poort van het knooppunt.
LoadBalancer
Hiermee maakt u een Azure load balancer-resource, configureert u een extern IP-adres en verbindt u de aangevraagde pods met de load balancer back-load balancer-pool. Om het verkeer van klanten de toepassing te laten bereiken, worden taakverdelingsregels gemaakt op de gewenste poorten.
Voor extra controle en routering van het inkomende verkeer kunt u in plaats daarvan een controller voor uitgaand verkeer gebruiken.
ExternalName
Hiermee maakt u een specifieke DNS-vermelding voor eenvoudigere toegang tot toepassingen.
Het IP-adres van de load balancers en services kan dynamisch worden toegewezen of u kunt een bestaand statisch IP-adres opgeven. U kunt zowel interne als externe statische IP-adressen toewijzen. Bestaande statische IP-adressen zijn vaak gekoppeld aan een DNS-vermelding.
U kunt zowel interne als externe load balancers maken. Interne load balancers krijgen alleen een privé-IP-adres toegewezen, zodat ze niet toegankelijk zijn via internet.
Virtuele netwerken van Azure.
In AKS kunt u een cluster implementeren dat gebruikmaakt van een van de volgende twee netwerkmodellen:
Kubenet-netwerken
De netwerkbronnen worden doorgaans gemaakt en geconfigureerd wanneer het AKS-cluster wordt geïmplementeerd.
Azure Container Networking Interface netwerken (CNI)
Het AKS-cluster is verbonden met bestaande virtuele netwerkbronnen en configuraties.
Kubenet-netwerken (basic)
De kubenet-netwerkoptie is de standaardconfiguratie voor het maken van een AKS-cluster. 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 naar het primaire IP-adres van het knooppunt.
Knooppunten maken gebruik van de kubenet Kubernetes-invoegvoegsel. U kunt:
- Laat het Azure-platform de virtuele netwerken voor u maken en configureren, of
- Kies ervoor om uw AKS-cluster te implementeren in een bestaand subnet van een virtueel netwerk.
Onthoud dat alleen de knooppunten een routeerbaar IP-adres ontvangen. De pods gebruiken NAT om te communiceren met andere resources buiten het AKS-cluster. Met deze aanpak vermindert u het aantal IP-adressen dat u in uw netwerkruimte moet reserveren voor gebruik door pods.
Zie Kubenet-netwerken configureren voor een AKS-cluster voor meer informatie.
Azure CNI (geavanceerd) netwerken
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 binnen 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. Zonder planning kan deze aanpak leiden tot uitputting van IP-adressen of de noodzaak om clusters opnieuw te bouwen in een groter subnet naarmate de vraag van uw toepassing groeit.
In tegenstelling tot kubenet is verkeer naar eindpunten in hetzelfde virtuele netwerk niet nat van het primaire IP-adres van het knooppunt. Het bronadres voor verkeer binnen het virtuele netwerk is het POD-IP-adres. Verkeer dat buiten het virtuele netwerk is, blijft NAT's naar het primaire IP-adres van het knooppunt.
Knooppunten maken gebruik van Azure CNI Kubernetes-invoegvoegsel.
Zie Configure Azure CNI for an AKS cluster (Een AKS-cluster configureren) voor meer informatie.
Netwerkmodellen vergelijken
Zowel kubenet als Azure CNI bieden netwerkconnectiviteit voor uw AKS-clusters. Er zijn echter voor- en nadelen voor elk ervan. Op hoog niveau zijn de volgende overwegingen van toepassing:
- kubenet
- Bespaart IP-adresruimte.
- Maakt gebruik van interne of externe kubernetes load balancer pods van buiten het cluster te bereiken.
- U beheert en onderhoudt handmatig door de gebruiker gedefinieerde routes (UDR's).
- 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.
De volgende gedragsverschillen bestaan tussen kubenet en Azure CNI:
| Mogelijkheid | Kubenet | Azure CNI |
|---|---|---|
| Cluster implementeren in bestaand of nieuw virtueel netwerk | Ondersteund: UDR's handmatig toegepast | Ondersteund |
| Pod-pod-connectiviteit | Ondersteund | Ondersteund |
| Pod-VM-connectiviteit; VM in hetzelfde virtuele netwerk | Werkt wanneer geïnitieerd door pod | Werkt op beide manieren |
| Pod-VM-connectiviteit; VM in een peered virtueel netwerk | Werkt wanneer geïnitieerd door pod | Werkt op beide manieren |
| On-premises toegang via VPN of Express Route | Werkt wanneer geïnitieerd door pod | Werkt op beide manieren |
| Toegang tot resources die worden beveiligd door service-eindpunten | Ondersteund | Ondersteund |
| Kubernetes-services blootstellen met behulp van een load balancer-service, App Gateway- of ingresscontroller | Ondersteund | Ondersteund |
| Standaardinstellingen Azure DNS privézones | Ondersteund | Ondersteund |
| Ondersteuning voor Windows-knooppuntgroepen | Niet ondersteund | Ondersteund |
Met betrekking tot DNS worden met zowel kubenet- als Azure CNI-invoegingen DNS aangeboden door CoreDNS, een implementatie die wordt uitgevoerd in AKS met een eigen automatische schaalverdeder. Zie Customizing DNS Service (DNS-serviceaanpassen) voor meer informatie over CoreDNS op Kubernetes. CoreDNS is standaard geconfigureerd voor het doorsturen van onbekende domeinen naar de DNS-functionaliteit van de Azure Virtual Network waar het AKS-cluster is geïmplementeerd. Daarom werken Azure DNS privézones voor pods die worden uitgevoerd in AKS.
Ondersteuningsbereik tussen netwerkmodellen
Welk netwerkmodel u ook gebruikt, kubenet en Azure CNI kunnen op een van de volgende manieren worden geïmplementeerd:
- Het Azure-platform kan de virtuele netwerkbronnen automatisch maken en configureren wanneer u een AKS-cluster maakt.
- U kunt de resources van het virtuele netwerk handmatig maken en configureren en aan deze resources koppelen wanneer u uw AKS-cluster maakt.
Hoewel mogelijkheden zoals service-eindpunten of UDR's worden ondersteund met zowel kubenet als Azure CNI, bepalen de ondersteuningsbeleidsregels voor AKS welke wijzigingen u kunt aanbrengen. Bijvoorbeeld:
- 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 UTU's of service-eindpunten te configureren.
Toegangsbeheerobjectcontrollers
Wanneer u een LoadBalancer-type-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.
LoadBalancer werkt alleen op laag 4. Op laag 4 is de service niet op de hoogte van de werkelijke toepassingen en kan de service geen routeringsoverwegingen meer maken.
Ingress-controllers werken op laag 7 en kunnen intelligentere regels gebruiken om toepassingsverkeer te distribueren. Controller voor uitgaand verkeer routeert doorgaans HTTP-verkeer naar verschillende toepassingen op basis van de binnenkomende URL.
Een resource voor ingress maken
In AKS kunt u een ingress-resource maken met behulp van NGINX, een vergelijkbaar hulpprogramma of de routeringsfunctie van de AKS HTTP-toepassing. Wanneer u HTTP-toepassingsroutering voor een AKS-cluster inschakelen, maakt het Azure-platform de controller voor het verkeer en een externe DNS-controller. Wanneer er nieuwe resources voor binnenkomend verkeer worden gemaakt in Kubernetes, worden de vereiste DNS A-records gemaakt in een clusterspecifieke DNS-zone.
Zie Http-toepassingsroutering implementeren voor meer informatie.
Application Gateway Ingress Controller (AGIC)
Met de Application Gateway Ingress Controller (AGIC) kunnen AKS-klanten gebruikmaken van de systeemeigen load balancer van Azure Application Gateway level 7 om cloudsoftware beschikbaar te maken op internet. AGIC bewaakt het Kubernetes-hostcluster en werkt continu een Application Gateway, wat geselecteerde services beschikbaar maakt op internet.
Zie What is Application Gateway Ingress Controller? voor meerinformatie over de AGIC-invoeg-on voor AKS.
SSL/TLS-beëindiging
SSL/TLS-beëindiging is een andere algemene functie van inkomende aanvallen. Bij grote webtoepassingen die toegankelijk zijn via HTTPS, verwerkt de toegangsbeheerbron de TLS-beëindiging in plaats van binnen de toepassing zelf. Als u het automatisch genereren en configureren van TLS-certificering wilt bieden, kunt u de ingress-resource configureren voor het gebruik van providers zoals 'Let's Encrypt'.
Zie Ingress and TLS (Ingress en TLS)voor meer informatie over het configureren van een NGINX-ingresscontroller met Let's Encrypt.
Behoud van IP-adres van clientbron
Configureer uw controller voor ingress om het clientbron-IP-adres te behouden bij aanvragen voor containers in uw AKS-cluster. Wanneer de toegangscontroller de aanvraag van een client naar een container in uw AKS-cluster routeert, is het oorspronkelijke bron-IP-adres van die aanvraag niet beschikbaar voor de doelcontainer. Wanneer u behoud van clientbron-IP inschakelen, is het bron-IP-adres voor de client beschikbaar in de aanvraagheader onder X-Forwarded-For.
Als u ip-behoud van clientbron op uw toegangscontroller gebruikt, kunt u geen TLS-pass-through gebruiken. Ip-behoud van clientbron en TLS-pass-through kunnen worden gebruikt met andere services, zoals het type LoadBalancer.
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 netwerkbeveiligingsgroep.
U hoeft de regels voor netwerkbeveiligingsgroep niet handmatig te configureren om verkeer voor pods in een AKS-cluster te filteren. Definieer alle vereiste poorten en doorsturen als onderdeel van uw Kubernetes Service-manifesten. Laat het Azure-platform de juiste regels maken of bijwerken.
U kunt ook netwerkbeleid gebruiken om automatisch verkeerfilterregels toe te passen op pods.
Netwerkbeleid
Standaard kunnen alle pods in een AKS-cluster zonder beperkingen verkeer verzenden en ontvangen. Voor een betere beveiliging definieert u regels die de verkeersstroom bepalen, zoals:
- Back-end-toepassingen worden alleen blootgesteld aan de 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 bepalen. 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, is netwerkbeleid een meer geschikt, cloudeigen manier om de verkeersstroom voor pods te controleren. 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
Om aan de slag te gaan 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 for network connectivity and security in AKS (Best practices voor netwerkconnectiviteit en -beveiliging in AKS) voor de bijbehorende best practices.
Zie de volgende artikelen voor meer informatie over kubernetes- en AKS-kernconcepten: