Overzicht van CNI-netwerken (Azure Kubernetes Service)
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.
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.
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 |
| Azure CNI Pod-subnet | Vast | - Directe toegang tot externe pods - Modi voor efficiënt VNet-IP-gebruik of ondersteuning voor grootschalige clusterschaal (preview) |
| 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 gebruiken
169.254.0.0/16172.31.0.0/16172.30.0.0/16192.0.2.0/24. - In BYO VNet-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/actionMicrosoft.Authorization/roleAssignments/writeMicrosoft.Network/virtualNetworks/subnets/read(alleen nodig als u uw eigen subnetten en CIDR's definieert)
- 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
Azure Kubernetes Service