Concepten voor containernetwerken

Artikel
04/27/2023

Van toepassing op: AKS in Azure Stack HCI 22H2, AKS op Windows Server

Toepassingsonderdelen moeten samenwerken om hun taken te verwerken in een op containers gebaseerde microservicebenadering. Kubernetes biedt bronnen die communicatie tussen toepassingen mogelijk maken en waarmee u intern of extern verbinding kunt maken met toepassingen en deze beschikbaar kunt maken. U kunt de taken van uw toepassingen verdelen om toepassingen met hoge beschikbaarheid te bouwen.

Complexere toepassingen vereisen mogelijk configuratie van inkomend verkeer voor SSL/TLS-beëindiging of routering van meerdere onderdelen. Mogelijk moet u ook de stroom van netwerkverkeer naar of tussen pods en knooppunten beperken voor beveiliging.

In dit artikel worden de belangrijkste concepten beschreven die netwerken bieden voor uw toepassingen in AKS die worden ingeschakeld door Arc:

Kubernetes-services
Toegangscontroller
Netwerkbeleid

Kubernetes-services

Om de netwerkconfiguratie voor toepassingsworkloads te vereenvoudigen, gebruikt Kubernetes services om een set pods logisch te groeperen en netwerkconnectiviteit te bieden. De volgende servicetypen zijn beschikbaar:

Cluster-IP: maakt een intern IP-adres voor gebruik in het Kubernetes-cluster. Gebruik cluster-IP voor interne toepassingen die ondersteuning bieden voor andere workloads binnen het cluster.

NodePort: maakt een poorttoewijzing op het onderliggende knooppunt waarmee de toepassing rechtstreeks kan worden geopend met het IP-adres en de poort van het knooppunt.

LoadBalancer: maakt een Azure load balancer-resource, configureert een extern IP-adres en verbindt de aangevraagde pods met de back-endpool van de load balancer. Om het verkeer van klanten toe te staan de toepassing te bereiken, worden er taakverdelingsregels gemaakt op de gewenste poorten.

Voor andere controle en routering van het binnenkomende verkeer kunt u een controller voor inkomend verkeer gebruiken.

Notitie

Wanneer u een doelcluster implementeert dat een netwerk deelt met een ander doelcluster, is er een kans op een conflict met het IP-adres van de load balancer. Dit kan gebeuren als u twee workloads implementeert die gebruikmaken van verschillende poorten in doelclusters die hetzelfde AksHciClusterNetwork object delen. Vanwege de manier waarop de IP-adressen en poorttoewijzingen worden toegewezen binnen de ha-proxy, kan dit leiden tot een dubbele IP-adrestoewijzing. Als dit gebeurt, kunnen een of beide workloads willekeurige netwerkverbindingsproblemen ondervinden totdat u uw workloads opnieuw implementeert. Wanneer u uw workloads opnieuw implementeert, kunt u dezelfde poort gebruiken die ervoor zorgt dat elke workload een afzonderlijk SERVICE-IP-adres ontvangt, of u kunt uw workloads opnieuw implementeren op doelclusters die verschillende AksHciClusterNetwork objecten gebruiken.

ExternalName: maakt een specifieke DNS-vermelding voor eenvoudigere toegang tot toepassingen. De IP-adressen voor load balancers en services kunnen interne of externe adressen zijn, afhankelijk van uw algehele netwerkinstellingen en kunnen dynamisch worden toegewezen. U kunt ook een bestaand statisch IP-adres opgeven dat u wilt gebruiken. Een bestaand statisch IP-adres is vaak gekoppeld aan een DNS-vermelding. Aan interne load balancers wordt alleen een privé-IP-adres toegewezen, zodat ze niet toegankelijk zijn via internet.

Basisbeginselen van Kubernetes-netwerken in Azure Stack HCI

Kubernetes biedt een abstractielaag voor virtuele netwerken om toegang tot uw toepassingen toe te staan of om toepassingsonderdelen met elkaar te laten communiceren. Kubernetes-knooppunten zijn verbonden met het virtuele netwerk en kunnen binnenkomende en uitgaande connectiviteit bieden voor pods. Het kube-proxy-onderdeel dat op elk knooppunt wordt uitgevoerd, biedt deze netwerkfuncties.

In Kubernetes groepeert Services pods logisch om het volgende toe te staan:

Directe toegang via één IP-adres of DNS-naam en een specifieke poort.
Verkeer distribueren met behulp van een load balancer tussen meerdere pods die dezelfde service of toepassing hosten.

Het Azure Stack HCI-platform helpt ook bij het vereenvoudigen van virtuele netwerken voor AKS op Azure Stack HCI-clusters door het 'underlay'-netwerk op een maximaal beschikbare manier te bieden. Wanneer u een AKS-cluster maakt, maken en configureren we ook een onderliggende HAProxy load balancer-resource. Wanneer u toepassingen in een Kubernetes-cluster implementeert, worden IP-adressen geconfigureerd voor uw pods en Kubernetes-services als eindpunten in deze load balancer.

IP-adresresources

Om de netwerkconfiguratie voor toepassingsworkloads te vereenvoudigen, wijst AKS Arc IP-adressen toe aan de volgende objecten in een implementatie:

Kubernetes-cluster-API-server: de API-server is een onderdeel van het Kubernetes-besturingsvlak dat de Kubernetes-API beschikbaar maakt. De API-server is de front-end voor het Kubernetes-besturingsvlak. Statische IP-adressen worden altijd toegewezen aan API-servers, ongeacht het onderliggende netwerkmodel.
Kubernetes-knooppunten (virtuele machines): een Kubernetes-cluster bestaat uit een set werkmachines, knooppunten genoemd, en de knooppunten hosten toepassingen in containers. Naast de besturingsvlakknooppunten heeft elk cluster ten minste één werkknooppunt. Voor een AKS-cluster worden Kubernetes-knooppunten geconfigureerd als virtuele machines. Deze virtuele machines worden gemaakt als maximaal beschikbare virtuele machines in Azure Stack HCI. Zie Concepten van knooppuntnetwerken voor meer informatie.
Kubernetes-services: in Kubernetes groepeert Services pod-IP-adressen logisch om directe toegang mogelijk te maken via één IP-adres of DNS-naam op een specifieke poort. Services kunnen ook verkeer distribueren met behulp van een load balancer. Statische IP-adressen worden altijd toegewezen aan Kubernetes-services, ongeacht het onderliggende netwerkmodel.
HAProxy-load balancers: HAProxy is een TCP/HTTP-load balancer en proxyserver die binnenkomende aanvragen over meerdere eindpunten verspreidt. Voor elk workloadcluster in een AKS in Azure Stack HCI-implementatie is een HAProxy-load balancer geïmplementeerd en geconfigureerd als een gespecialiseerde virtuele machine.
Microsoft On-premises cloudservice: dit is de Azure Stack HCI-cloudprovider die het maken en beheren van de gevirtualiseerde omgeving die als host fungeert voor Kubernetes in een on-premises Azure Stack HCI-cluster of Windows Server-cluster mogelijk maakt. Het netwerkmodel gevolgd door uw Azure Stack HCI- of Windows Server-cluster bepaalt de ip-adrestoewijzingsmethode die wordt gebruikt door de On-Premises Cloud Service van Microsoft. Zie Concepten voor knooppuntnetwerken voor meer informatie over de netwerkconcepten die zijn geïmplementeerd door de Microsoft On-Premises Cloud Service.

Kubernetes-netwerken

In AKS op Azure Stack HCI kunt u een cluster implementeren dat gebruikmaakt van een van de volgende netwerkmodellen:

Flannel Overlay-netwerken: de netwerkresources worden doorgaans gemaakt en geconfigureerd wanneer het cluster wordt geïmplementeerd.
Project Calico-netwerken: dit model biedt aanvullende netwerkfuncties, zoals netwerkbeleid en stroombeheer.

Beide netwerk-implementaties maken gebruik van een overlay-netwerkconfiguratiemodel, dat een IP-adrestoewijzing biedt die is losgekoppeld van de rest van het datacenternetwerk.

Zie Inleiding: Kubernetes Overlay-netwerken voor Windows voor meer informatie over overlaynetwerken.

Zie Aan de slag met Calico-netwerkbeleid voor meer informatie over de Calico Network-invoegtoepassing en -beleid.

Netwerkmodellen vergelijken

Flanel

Flanel is een virtuele netwerklaag die speciaal is ontworpen voor containers. Flanel maakt een plat netwerk dat over het hostnetwerk heen loopt. Alle containers/pods krijgen één IP-adres toegewezen in dit overlaynetwerk en communiceren rechtstreeks door verbinding te maken met elkaars IP-adres.

Calico

Calico is een opensource-oplossing voor netwerk- en netwerkbeveiliging voor containers, virtuele machines en systeemeigen werkbelastingen op basis van een host. Calico ondersteunt meerdere gegevensvlakken, waaronder: een Linux eBPF-gegevensvlak, een Linux-netwerkgegevensvlak en een Windows HNS-gegevensvlak.

Functies

Mogelijkheid	Flanel	Calico
Netwerkbeleid	Nee	Ja
IPv6	Nee	Ja
Gebruikte lagen	L2 (VxLAN)	L2 (VxLAN)
Cluster implementeren in een bestaand of nieuw virtueel netwerk	Ja	Ja
Windows-ondersteuning	Ja	Ja
Pod-Pod verbinding	Ja	Ja
Pod-VM-verbinding, VM in hetzelfde netwerk	Nee	Ja
Pod-VM-verbinding, VM in een ander netwerk	Ja	Ja
Kubernetes Services	Ja	Ja
Beschikbaar maken via load balancer	Ja	Ja
Netwerken	Veel netwerken op hetzelfde cluster met meerdere daemon	Veel netwerken in hetzelfde cluster
Implementatie	Linux: DaemonSet	Linux: DaemonSet
	Windows: Service	Windows: Service
Opdrachtregel	geen	calicoctl

Belangrijk

Op dit moment is de standaardselectie om Calico te gebruiken in een overlay-netwerkmodus. Als u Flanel wilt inschakelen, gebruikt u de -primaryNetworkPlugin parameter van de New-AksHciCluster PowerShell-opdracht en geeft u flannel op als de waarde. Deze waarde kan niet worden gewijzigd nadat u het cluster hebt geïmplementeerd en is van toepassing op zowel Windows- als Linux-clusterknooppunten.

Hier volgt een voorbeeld:

New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'

Volgende stappen

In dit artikel worden netwerkconcepten voor containers in AKS-knooppunten in Azure Stack HCI besproken. Zie de volgende artikelen voor meer informatie over AKS in Azure Stack HCI-concepten:

Share via