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 treedt op wanneer het aantal beschikbare adressen de limiet bereikt en knooppunten verhindert bij schaal- of upgradebewerkingen. Bij overbelasting vraagt uw toepassing te veel middelen en kan het niet bijhouden.

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.

De volgende basisberekeningen vergelijken adresruimten in de netwerkmodellen.

  • 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).

Clustergrootte

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.

Wachttijd

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 node- en pod-subnetten

Gedragsverschillen tussen Kubenet en Azure CNI

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

Vermogen Kubenet Azure CNI Azure CNI-overlay Azure CNI Powered by Cilium
Cluster implementeren in bestaand of nieuw virtueel netwerk Ondersteund - UDR's worden 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 door de pod wordt gestart
Pod-VM connectiviteit; VM in gekoppeld virtueel netwerk Werkt wanneer deze door een pod wordt gestart Werkt op beide manieren Werkt wanneer deze wordt gestart door de pod Werkt wanneer gestart door de pod
Op locatie toegang via VPN of Express Route Werkt wanneer deze wordt gestart door de pod Werkt op beide manieren Werkt wanneer deze wordt gestart door de pod Werkt wanneer het door een pod wordt gestart.
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, App Gateway of ingress controller. 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 Cilium