Delen via

Overzicht van CNI-netwerken (Azure Kubernetes Service)

  • Artikel

Kubernetes maakt gebruik van CNI-invoegtoepassingen (Container Networking Interface) voor het beheren van netwerken in Kubernetes-clusters. CNIs zijn verantwoordelijk voor het toewijzen van IP-adressen aan pods, netwerkroutering tussen pods, Kubernetes Service-routering en meer.

AKS biedt meerdere CNI-invoegtoepassingen die u in uw clusters kunt gebruiken, afhankelijk van uw netwerkvereisten.

Netwerkmodellen in AKS

Het kiezen van een CNI-invoegtoepassing voor uw AKS-cluster is grotendeels afhankelijk van welk netwerkmodel het beste past bij uw behoeften. Elk model heeft zijn eigen voor- en nadelen die u moet overwegen bij het plannen van uw AKS-cluster.

AKS maakt gebruik van twee hoofdnetwerkmodellen: overlaynetwerk en plat netwerk.

Beide netwerkmodellen hebben meerdere ondersteunde CNI-invoegtoepassingsopties. De belangrijkste verschillen tussen de modellen zijn hoe IP-adressen van pods worden toegewezen en hoe verkeer het cluster verlaat.

Overlaynetwerken

Overlay-netwerken is het meest voorkomende netwerkmodel dat wordt gebruikt in Kubernetes. In overlaynetwerken krijgen pods een IP-adres van een privé,logisch gescheiden CIDR van het Azure VNet-subnet waarin AKS-knooppunten worden geïmplementeerd. Dit maakt eenvoudiger en vaak betere schaalbaarheid mogelijk dan het platte netwerkmodel.

In overlaynetwerken kunnen pods rechtstreeks met elkaar communiceren. Verkeer dat het cluster verlaat, is Het vertaalde bronnetwerkadres (SNAT'd) naar het IP-adres van het knooppunt en binnenkomend POD-IP-verkeer wordt gerouteerd via een bepaalde service, zoals een load balancer. Dit betekent dat het IP-adres van de pod 'verborgen' is achter het IP-adres van het knooppunt. Deze aanpak vermindert het aantal vereiste VNet-IP-adressen voor uw clusters.

Een diagram met twee knooppunten met drie pods die elk worden uitgevoerd in een Overlay-netwerk. Podverkeer naar eindpunten buiten het cluster wordt gerouteerd via NAT.

Azure Kubernetes Service biedt de volgende CNI-invoegtoepassingen voor overlaynetwerken:

  • Azure CNI Overlay, de aanbevolen CNI-invoegtoepassing voor de meeste scenario's.
  • kubenet, het verouderde overlaymodel CNI.

Platte netwerken

In tegenstelling tot een overlaynetwerk wijst een plat netwerkmodel in AKS IP-adressen toe aan pods vanuit een subnet van hetzelfde Azure VNet als de AKS-knooppunten. Dit betekent dat verkeer dat uw clusters verlaat niet SNAT is en dat het IP-adres van de pod rechtstreeks beschikbaar is voor de bestemming. Dit kan handig zijn voor sommige scenario's, zoals wanneer u IP-adressen van pods moet beschikbaar maken voor externe services.

Een diagram met twee knooppunten met drie pods die elk worden uitgevoerd in een plat netwerkmodel.

Azure Kubernetes Service biedt twee CNI-invoegtoepassingen voor platte netwerken. Dit artikel gaat niet dieper in op elke invoegtoepassingsoptie. Zie de gekoppelde documentatie voor meer informatie:

  • Azure CNI Pod Subnet, de aanbevolen CNI-invoegtoepassing voor platte netwerkscenario's.
  • Azure CNI Node Subnet, een verouderd plat netwerkmodel CNI raadt u over het algemeen alleen aan om te gebruiken als u een beheerd VNet voor uw cluster nodig hebt .

Een CNI kiezen

Bij het kiezen van een CNI zijn er verschillende factoren waarmee u rekening moet houden. Elk netwerkmodel heeft zijn eigen voor- en nadelen, en de beste keuze voor uw cluster is afhankelijk van uw specifieke vereisten.

Een netwerkmodel kiezen

De twee belangrijkste netwerkmodellen in AKS zijn overlay- en platte netwerken.

  • Overlaynetwerken:

    • Bewaar de IP-adresruimte van het VNet met behulp van logisch gescheiden CIDR-bereiken voor pods.
    • Maximale ondersteuning voor clusterschaal.
    • Eenvoudig IP-adresbeheer.

  • Platte netwerken:

    • Pods krijgen volledige VNet-connectiviteit en kunnen rechtstreeks worden bereikt via hun privé-IP-adres van verbonden netwerken.
    • Grote, niet-gefragmenteerde VNet-IP-adresruimte vereisen.

Use-casevergelijking

Houd bij het kiezen van een netwerkmodel rekening met de gebruiksvoorbeelden voor elke CNI-invoegtoepassing en het type netwerkmodel dat wordt gebruikt:

CNI-invoegtoepassing Netwerkmodel Use case highlights
Azure CNI-overlay Overlay - Het beste voor het behoud van IP-adressen van VNET
- Maximaal aantal knooppunten dat wordt ondersteund door API Server + 250 pods per knooppunt
- Eenvoudigere configuratie
-Geen directe IP-toegang tot externe pods
Subnet van Azure CNI-pod (preview) Vast - Directe toegang tot externe pods
- Modi voor efficiënt VNet IP-gebruik of ondersteuning voor grootschalige clusterschaal
Kubenet (verouderd) Overlay - Prioriteit geeft aan IP-behoud
- Beperkte schaal
- Handmatig routebeheer
Azure CNI Node-subnet (verouderd) Vast - Directe toegang tot externe pods
- Eenvoudigere configuratie
- Beperkte schaal
- Inefficiënt gebruik van VNet-IP's

Vergelijking van functies

U kunt ook de functies van elke CNI-invoegtoepassing vergelijken. De volgende tabel bevat een vergelijking op hoog niveau van de functies die worden ondersteund door elke CNI-invoegtoepassing:

Functie Azure CNI-overlay Azure CNI Pod-subnet Azure CNI Node-subnet (verouderd) Kubenet
Cluster implementeren in bestaand of nieuw VNet Ondersteund Ondersteund Ondersteund Ondersteund - handmatige UDR's
Pod-VM-connectiviteit met VM in hetzelfde of gekoppeld VNet Pod geïnitieerd Beide manieren Beide manieren Pod geïnitieerd
On-premises toegang via VPN/Express Route Pod geïnitieerd Beide manieren Beide manieren Pod geïnitieerd
Toegang tot service-eindpunten Ondersteund Ondersteund Ondersteund Ondersteund
Services beschikbaar maken met behulp van load balancer Ondersteund Ondersteund Ondersteund Ondersteund
Services beschikbaar maken met Behulp van App Gateway Momenteel niet ondersteund Ondersteund Ondersteund Ondersteund
Services beschikbaar maken met behulp van toegangsbeheerobjectcontroller Ondersteund Ondersteund Ondersteund Ondersteund
Windows-knooppuntgroepen Ondersteund Ondersteund Ondersteund Niet ondersteund
Standaard Azure DNS en privézones Ondersteund Ondersteund Ondersteund Ondersteund
VNet-subnet delen tussen meerdere clusters Ondersteund Ondersteund Ondersteund Niet ondersteund

Ondersteuningsbereik tussen netwerkmodellen

Afhankelijk van de CNI die u gebruikt, kunnen de resources van het virtuele clusternetwerk 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. zoals in Azure CNI Overlay, Azure CNI Node-subnet en Kubenet.
  • 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, 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.

Vereisten

Er zijn verschillende vereisten en overwegingen waarmee u rekening moet houden bij het plannen van uw netwerkconfiguratie voor AKS:

  • 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.
  • In BYO CNI-scenario's moet de clusteridentiteit die wordt gebruikt door het AKS-cluster ten minste machtigingen voor netwerkbijdrager hebben voor het subnet in 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.

Volgende stappen