Delen via


Overzicht van Azure CNI-netwerken in Azure Kubernetes Service (AKS)

AKS-clusters maken standaard gebruik van kubenet en maken een virtueel netwerk en subnet. Met kubenet krijgen knooppunten een IP-adres van een subnet van een virtueel netwerk. Nat (Network Address Translation) wordt vervolgens geconfigureerd op de knooppunten en pods ontvangen een IP-adres 'verborgen' achter het IP-adres van het knooppunt. Deze aanpak vermindert het aantal IP-adressen dat u in uw netwerkruimte moet reserveren om pods te kunnen gebruiken.

Met Azure Container Networking Interface (CNI) krijgt elke pod een IP-adres van het subnet en kan deze rechtstreeks worden geopend. Systemen in hetzelfde virtuele netwerk als het AKS-cluster zien het IP-adres van de pod als het bronadres voor verkeer van de pod. Systemen buiten het virtuele netwerk van het AKS-cluster zien het IP-adres van het knooppunt als bronadres voor verkeer van de pod. Deze IP-adressen moeten uniek zijn binnen uw netwerkruimte en moeten van tevoren worden gepland. Elk knooppunt heeft een configuratieparameter voor het maximum aantal pods dat wordt ondersteund. Het equivalente aantal IP-adressen per knooppunt wordt vervolgens vooraf gereserveerd voor dat knooppunt. Deze aanpak vereist meer planning en leidt vaak tot uitputting van IP-adressen of tot de noodzaak om clusters in een groter subnet opnieuw samen te stellen naarmate de vraag naar uw toepassing toeneemt.

Notitie

In dit artikel maakt u alleen kennis met traditionele Azure CNI. Voor Azure CNI-overlay, Azure CNI VNet voor dynamische IP-toewijzing en Azure CNI VNet - Statische bloktoewijzing (preview). Raadpleeg in plaats daarvan hun documentatie.

Vereisten

  • Het virtuele netwerk voor het AKS-cluster moet uitgaande internetverbinding toestaan.

  • AKS-clusters kunnen het adresbereik van de Kubernetes-service, het adresbereik van de pod of het adresbereik van het virtuele clusternetwerk niet gebruiken169.254.0.0/16172.31.0.0/16172.30.0.0/16192.0.2.0/24.

  • De clusteridentiteit die door het AKS-cluster wordt gebruikt, moet ten minste machtigingen voor netwerkbijdrager hebben voor het subnet binnen uw virtuele netwerk. Als u een aangepaste rol wilt definiëren in plaats van de ingebouwde rol Netwerkbijdrager te gebruiken, zijn de volgende machtigingen vereist:

    • Microsoft.Network/virtualNetworks/subnets/join/action

    • Microsoft.Network/virtualNetworks/subnets/read

    • Microsoft.Authorization/roleAssignments/write

  • Het subnet dat is toegewezen aan de AKS-knooppuntgroep kan geen gedelegeerd subnet zijn.

  • AKS past geen netwerkbeveiligingsgroepen (NSG's) toe op het subnet en wijzigt geen NSG's die aan dat subnet zijn gekoppeld. Als u uw eigen subnet opgeeft en NSG's toevoegt die aan dat subnet zijn gekoppeld, moet u ervoor zorgen dat de beveiligingsregels in de NSG's verkeer toestaan binnen het CIDR-bereik van het knooppunt. Zie Netwerkbeveiligingsgroepen voor meer informatie.

Implementatieparameters

Wanneer u een AKS-cluster maakt, kunnen de volgende parameters worden geconfigureerd voor Azure CNI-netwerken:

Virtueel netwerk: het virtuele netwerk waarin u het Kubernetes-cluster wilt implementeren. Als u een nieuw virtueel netwerk voor uw cluster wilt maken, selecteert u Nieuw maken en volgt u de stappen in de sectie Virtueel netwerk maken. Als u een bestaand virtueel netwerk wilt selecteren, moet u ervoor zorgen dat het zich op dezelfde locatie en hetzelfde Azure-abonnement bevindt als uw Kubernetes-cluster. Zie azure-abonnements- en servicelimieten, quota en beperkingen voor azure voor informatie over de limieten en quota voor een virtueel Azure-netwerk.

Subnet: het subnet in het virtuele netwerk waar u het cluster wilt implementeren. Als u een nieuw subnet wilt maken in het virtuele netwerk voor uw cluster, selecteert u Nieuw maken en volgt u de stappen in de sectie Subnet maken. Voor hybride connectiviteit mag het adresbereik niet overlappen met andere virtuele netwerken in uw omgeving.

Azure Network Plugin: Wanneer de Azure-netwerkinvoegtoepassing wordt gebruikt, kan de interne LoadBalancer-service met 'externalTrafficPolicy=Local' niet worden geopend vanaf VM's met een IP in clusterCIDR die niet tot het AKS-cluster behoort.

Kubernetes-serviceadresbereik: deze parameter is de set virtuele IP-adressen die Kubernetes toewijst aan interne services in uw cluster. Dit bereik kan niet worden bijgewerkt nadat u het cluster hebt gemaakt. U kunt elk privéadresbereik gebruiken dat voldoet aan de volgende vereisten:

  • Mag zich niet binnen het IP-adresbereik van het virtuele netwerk van uw cluster bevinden
  • Mag niet overlappen met andere virtuele netwerken waarmee het virtuele clusternetwerk peers
  • Mag niet overlappen met on-premises IP-adressen
  • Mag niet binnen de bereiken169.254.0.0/16, 172.30.0.0/16, of 172.31.0.0/16192.0.2.0/24

Hoewel het technisch mogelijk is om een serviceadresbereik op te geven binnen hetzelfde virtuele netwerk als uw cluster, wordt dit niet aanbevolen. Onvoorspelbaar gedrag kan resulteren als overlappende IP-bereiken worden gebruikt. Zie de sectie Veelgestelde vragen van dit artikel voor meer informatie. Zie Services in de Kubernetes-documentatie voor meer informatie over Kubernetes-services .

IP-adres van kubernetes DNS-service: het IP-adres voor de DNS-service van het cluster. Dit adres moet binnen het adresbereik van Kubernetes Service liggen. Gebruik niet het eerste IP-adres in uw adresbereik. Het eerste adres in het subnetbereik wordt gebruikt voor het adres kubernetes.default.svc.cluster.local .

Veelgestelde vragen

  • Kan ik VM's implementeren in mijn clustersubnet?

    Ja. Maar voor Azure CNI voor dynamische IP-toewijzing kunnen de VM's niet worden geïmplementeerd in het subnet van de pod.

  • Welk bron-IP-adres zien externe systemen voor verkeer dat afkomstig is van een pod met Azure CNI?

    Systemen in hetzelfde virtuele netwerk als het AKS-cluster zien het IP-adres van de pod als het bronadres voor verkeer van de pod. Systemen buiten het virtuele netwerk van het AKS-cluster zien het IP-adres van het knooppunt als bronadres voor verkeer van de pod.

    Maar voor Azure CNI voor dynamische IP-toewijzing, ongeacht of de verbinding zich in hetzelfde virtuele netwerk of in meerdere virtuele netwerken bevindt, is het ip-adres van de pod altijd het bronadres voor verkeer van de pod. Dit komt doordat de Azure CNI voor dynamische IP-toewijzing microsoft Azure Container Networking-infrastructuur implementeert, wat end-to-end ervaring biedt. Daarom elimineert het gebruik van ip-masq-agent, dat nog steeds wordt gebruikt door traditionele Azure CNI.

  • Kan ik netwerkbeleid per pod configureren?

    Ja, Kubernetes-netwerkbeleid is beschikbaar in AKS. Zie Verkeer tussen pods beveiligen met behulp van netwerkbeleid in AKS om aan de slag te gaan.

  • Kan het maximum aantal pods worden geïmplementeerd op een knooppunt dat kan worden geconfigureerd?

    Ja, wanneer u een cluster implementeert met de Azure CLI of een Resource Manager-sjabloon. Zie Maximum aantal pods per knooppunt.

    U kunt het maximum aantal pods per knooppunt op een bestaand cluster niet wijzigen.

  • Hoe kan ik aanvullende eigenschappen configureren voor het subnet dat ik heb gemaakt tijdens het maken van een AKS-cluster? Bijvoorbeeld service-eindpunten.

    De volledige lijst met eigenschappen voor het virtuele netwerk en subnetten die u tijdens het maken van een AKS-cluster maakt, kan worden geconfigureerd op de standaardpagina voor configuratie van virtuele netwerken in Azure Portal.

  • Kan ik een ander subnet in mijn virtuele clusternetwerk gebruiken voor het adresbereik van de Kubernetes-service?

    Dit wordt niet aanbevolen, maar deze configuratie is mogelijk. Het serviceadresbereik is een set virtuele IP's (VIP's) die Kubernetes toewijst aan interne services in uw cluster. Azure Networking heeft geen inzicht in het IP-adresbereik van de service van het Kubernetes-cluster. Het gebrek aan zichtbaarheid in het servicebereik van het cluster kan leiden tot problemen. Het is mogelijk om later een nieuw subnet te maken in het virtuele clusternetwerk dat overlapt met het serviceadresbereik. Als een dergelijke overlapping optreedt, kan Kubernetes een service toewijzen aan een IP-adres dat al wordt gebruikt door een andere resource in het subnet, wat onvoorspelbaar gedrag of fouten veroorzaakt. Door ervoor te zorgen dat u een adresbereik buiten het virtuele netwerk van het cluster gebruikt, kunt u dit overlappingsrisico voorkomen.

Volgende stap

Meer informatie over netwerken in AKS vindt u in de volgende artikelen: