Beslissingscriteria
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 |