Beslissingscriteria

Voltooid

Het kiezen van de beste netwerkinvoegtoepassing voor uw use case is afhankelijk van uw criteria. Elke optie heeft zijn eigen voor- en nadelen en afwegingen die moeten worden overwogen bij het maken van een selectie.

Beslissingscriteria op hoog niveau

IPv4-uitputting

Kubenet is ontworpen met het behoud van IP-adresruimte in gedachten. Azure CNI biedt pods met volledige netwerkconnectiviteit, maar vereist meer IP-adresruimte en -planning. IPv4-uitputting is wanneer het aantal adressen de limiet bereikt en knooppunten stopt met een schaal- of upgradebewerking. Tijdens uitputting vraagt uw toepassing te veel resources en is er te veel om bij te blijven.

Met Kubenet kunnen de knooppunten gedefinieerde IP-adressen ontvangen, zonder dat een groot aantal IP-adressen vooraf hoeft te worden gereserveerd voor alle potentiële pods die in het cluster kunnen worden uitgevoerd. Met kubenet maakt u zich minder zorgen over IPv4-uitputting en verwerkt u een klein IP-adresbereik voor grote clusterondersteuning en toepassingsvereisten.

Met de volgende basisberekeningen worden adresruimte in de netwerkmodellen vergeleken:

  • kubenet: een eenvoudig /24 IP-adresbereik kan maximaal 251 knooppunten in het cluster ondersteunen (elk subnet van het virtuele Azure-netwerk behoudt de eerste drie IP-adressen voor beheerbewerkingen). Dit aantal knooppunten kan maximaal 27.610 pods ondersteunen (met een standaard maximum van 110 pods per knooppunt met kubenet).
  • Azure CNI: hetzelfde basis-/24-subnetbereik kan maximaal acht knooppunten in het cluster ondersteunen. Dit aantal knooppunten kan maximaal 240 pods ondersteunen (met een standaard maximum van 30 pods per knooppunt met Azure CNI).

Grootte van cluster

Kubenet heeft een hard maximum van 400 knooppunten per cluster, terwijl Azure CNI afhankelijk is van de configuratie van de invoegtoepassing.

Connectiviteit

In Kubenet moet u door de gebruiker gedefinieerde routes (UDR's) handmatig beheren en onderhouden. Als u pods van buiten het cluster wilt bereiken, moet een load balancer worden gebruikt. Met Azure CNI krijgen pods volledige virtuele netwerkconnectiviteit en kunnen ze rechtstreeks worden bereikt via hun privé-IP-adres van verbonden netwerken.

Ondersteuning voor meerdere clusters

In kubenet kunnen meerdere clusters hetzelfde subnet voor knooppunten niet gebruiken. Met Azure CNI is deze configuratie mogelijk.

Latentie

In vergelijking met Azure CNI heeft Kubenet een extra hop nodig, wat een kleine latentie kan veroorzaken. Latentiegevoelige workloads moeten worden geïmplementeerd op clusters met behulp van Azure CNI.

Extra mogelijkheden

Azure CNI ondersteunt complexe netwerktopologieën met Azure CNI-netwerken, zoals virtuele knooppunten of Azure-netwerkbeleid.

Deze extra mogelijkheden zijn:

  • Subnet per knooppuntgroep
  • Dynamische toewijzing van IP-adressen
  • Toewijzingen van knooppunten versus subnetten van pods

Gedragsverschillen tussen Kubenet en Azure CNI

Naast criteria op hoog niveau zijn er veel gedragsverschillen en verschillen in functieondersteuning:

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
Toegang tot resources die beschikbaar zijn gesteld door privé-eindpunten 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
Standaard Azure DNS en privézones Ondersteund Ondersteund Ondersteund
Ondersteuning voor Windows-knooppuntgroepen Niet ondersteund Ondersteund Ondersteund Alleen beschikbaar voor Linux
Virtuele knooppunten Niet ondersteund Ondersteund Niet ondersteund
Meerdere clusters die één subnet delen Niet ondersteund Ondersteund Ondersteund
Ondersteunde netwerkbeleidsregels Calico Calico en Azure-netwerkbeleid Calico, Azure-netwerkbeleid, Cilium Ciliuim