Concepten voor containernetwerken
Van toepassing op: AKS in Azure Local 22H2, AKS op Windows Server
Toepassingsonderdelen moeten samenwerken om hun taken te verwerken in een op containers gebaseerde microservicesbenadering. Kubernetes biedt resources waarmee toepassingscommunicatie mogelijk is en waarmee u intern of extern verbinding kunt maken met toepassingen en deze beschikbaar kunt maken. U kunt taken verdelen over uw toepassingen om maximaal beschikbare toepassingen 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 geïntroduceerd die netwerken bieden voor uw toepassingen in AKS die zijn ingeschakeld door Arc:
- Kubernetes-services
- Toegangscontroller
- Netwerkbeleid
Kubernetes-services
Om de netwerkconfiguratie voor toepassingsworkloads te vereenvoudigen, maakt Kubernetes gebruik van 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 binnen het Kubernetes-cluster. Cluster-IP gebruiken 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 taakverdelingsregels gemaakt op de gewenste poorten.
Voor andere besturings- en routering van inkomend verkeer kunt u een ingangscontroller gebruiken.
Notitie
Wanneer u een doelcluster implementeert dat een netwerk deelt met een ander doelcluster, is er sprake van een conflict tussen ip-adressen van een 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 in 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 IP-adres van de service 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 netwerkinstallatie en dynamisch kunnen 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. Interne load balancers krijgen alleen een privé-IP-adres toegewezen, zodat ze niet toegankelijk zijn via internet.
Basisbeginselen van Kubernetes-netwerken in Azure Local
Kubernetes biedt een abstractielaag voor virtuele netwerken om toegang te verlenen tot uw toepassingen of voor toepassingsonderdelen om met elkaar te communiceren. Kubernetes-knooppunten zijn verbonden met het virtuele netwerk en kunnen binnenkomende en uitgaande connectiviteit bieden voor pods. Het kube-proxyonderdeel 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 als host fungeren voor dezelfde service of toepassing.
Het Lokale Azure-platform helpt ook om virtuele netwerken voor AKS op lokale Azure-clusters te vereenvoudigen 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-adresbronnen
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 Local voor meer informatie. Zie De concepten van Node-netwerken voor meer informatie.
- Kubernetes-services: in Kubernetes groepeert Services ip-adressen van pods 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 op lokale Azure-implementatie is een HAProxy-load balancer geïmplementeerd en geconfigureerd als een gespecialiseerde virtuele machine.
- Microsoft On-premises cloudservice: dit is de lokale Azure-cloudprovider die het maken en beheren van de gevirtualiseerde omgeving mogelijk maakt die Als host fungeert voor Kubernetes op een lokaal Azure-cluster of Windows Server-cluster. Het netwerkmodel gevolgd door uw Lokale Azure- of Windows Server-cluster bepaalt de IP-adrestoewijzingsmethode die wordt gebruikt door de On-Premises Cloud Service van Microsoft. Zie Node-netwerkconcepten voor meer informatie over de netwerkconcepten die zijn geïmplementeerd door de On-Premises Cloud Service van Microsoft.
Kubernetes-netwerken
In AKS op Azure Local kunt u een cluster implementeren dat gebruikmaakt van een van de volgende netwerkmodellen:
- Flannel Overlay-netwerken: de netwerkresources worden doorgaans gemaakt en geconfigureerd als het cluster wordt geïmplementeerd.
- Project Calico-netwerken: dit model biedt extra 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 tot: Kubernetes Overlay-netwerken voor Windows voor meer informatie over overlaynetwerken.
Zie voor meer informatie over de Calico Network-invoegtoepassing en -beleid aan de slag met Calico-netwerkbeleid.
Netwerkmodellen vergelijken
Flanel
Notitie
Flannel CNI is in december 2023 buiten gebruik gesteld.
Flannel is een virtuele netwerklaag die speciaal is ontworpen voor containers. Flannel maakt een plat netwerk dat het hostnetwerk overlays. Aan alle containers/pods wordt één IP-adres toegewezen in dit overlaynetwerk en wordt rechtstreeks gecommuniceerd door verbinding te maken met elkaars IP-adres.
Calico
Calico is een opensource-netwerk- en netwerkbeveiligingsoplossing voor containers, virtuele machines en systeemeigen hostworkloads. Calico ondersteunt meerdere gegevensvlakken, waaronder: een Linux eBPF-gegevensvlak, een Linux-netwerkgegevensvlak en een Windows HNS-gegevensvlak.
Functies
| Mogelijkheid | Flanel | Calico |
|---|---|---|
| Netwerkbeleid | Nr. | Ja |
| IPv6 | Nr. | Ja |
| Gebruikte lagen | L2 (VxLAN) | L2 (VxLAN) |
| Cluster implementeren in bestaand of nieuw virtueel netwerk | Ja | Ja |
| Windows-ondersteuning | Ja | Ja |
| Pod-Pod-verbinding | Ja | Ja |
| Pod-VM-verbinding, VM in hetzelfde netwerk | Nr. | 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 in hetzelfde cluster met meerdere daemon | Veel netwerken in hetzelfde cluster |
| Implementatie | Linux: DaemonSet | Linux: DaemonSet |
| Windows: Service | Windows: Service | |
| Opdrachtregel | Geen | calicoctl |
Belangrijk
Momenteel is de standaardselectie het gebruik van Calico in een overlaynetwerkmodus. Als u Flannel wilt inschakelen, gebruikt u de -primaryNetworkPlugin parameter van de New-AksHciCluster PowerShell-opdracht en geeft u flannel deze 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.
Voorbeeld:
New-AksHciCluster -name MyCluster -primaryNetworkPlugin 'flannel'
Volgende stappen
In dit artikel worden netwerkconcepten voor containers in AKS-knooppunten in Azure Local besproken. Zie de volgende artikelen voor meer informatie over AKS op lokale azure-concepten: