Scenario's voor cross-clusternetwerken voor Azure Kubernetes Fleet Manager (preview)

Netwerken tussen clusters voor Azure Kubernetes Fleet Manager (Fleet) is een beheerd aanbod dat is gebouwd op Cilium Cluster Mesh waarmee u directe pod-naar-pod-communicatie kunt tot stand brengen in meerdere Azure Kubernetes Service (AKS) clusters. Door een cross-clusternetwerk te creëren, kunt u naadloze oost-west-connectiviteit mogelijk maken zonder dat gateways nodig zijn, terwijl u ook inzicht in meerdere clusters krijgt en de beveiliging consistent kunt handhaven.

Architectuur en mogelijkheden

In een netwerkconfiguratie tussen clusters kan een vlak virtueel netwerk pods in verschillende clusters in staat stellen verkeer rechtstreeks over clustergrenzen heen te routeren. Aan elk cluster worden doorgaans twee subnetten toegewezen: één voor knooppunten en één voor pods. Deze consistente architectuur zorgt ervoor dat het podnetwerk vlak blijft in het netwerk tussen clusters, zonder gebruik te maken van overlays of tunnels.

Diagram met de architectuur van Azure Kubernetes Fleet Manager die connectiviteit tussen clusters oost-west beheert. Pods in verschillende clusters communiceren rechtstreeks via Cilium Agents via gekoppelde virtuele netwerken.

Belangrijke onderdelen en mogelijkheden voor dit scenario zijn:

  • Azure CNI met het gegevensvlak Cilium: Beide AKS-clusters moeten Azure CNI gebruiken met de Azure CNI mogelijk gemaakt door het gegevensvlak Cilium.
  • Advanced Container Networking Services (ACNS): ACNS moet zijn ingeschakeld op de clusters om dit scenario te ondersteunen.
  • Azure Kubernetes Fleet Manager: Fleet beheert de levenscyclus en configuratie van het netwerk tussen clusters via resources zoals het profiel ClusterMesh.
  • Systeemeigen prestaties: IP-routering van pods vindt plaats in clusters met systeemeigen prestaties via directe routering, waardoor de noodzaak voor gateways of proxy's wordt omzeild.
  • Unified Network Policy Enforcement: Breidt het afdwingen van laag 3-7-netwerkbeleid van Cilium uit naar alle clusters in het netwerk tussen clusters, waardoor een consistente beveiligingsbenadering wordt gegarandeerd.
  • Waarneembaarheid van meerdere clusters: biedt end-to-end zichtbaarheid in verkeersstromen tussen clusters. Deze zichtbaarheid helpt u bij het bewaken van de toepassingsstatus, het oplossen van verbindingsproblemen en het analyseren van verkeerspatronen in het netwerk tussen clusters.

Gebruikssituaties

Netwerken tussen clusters maken verschillende belangrijke scenario's met meerdere clusters mogelijk. In de volgende secties worden de meest voorkomende use cases beschreven voor netwerken tussen clusters met Fleet.

Use case: Transparante servicedetectie en taakverdeling

Wanneer u standaard Kubernetes-services gebruikt en deze als globaal markeert, detecteert Cilium automatisch eindpunten voor deze services in alle clusters in het netwerk tussen clusters. Verkeer dat is bestemd voor een globale service ClusterIP , wordt automatisch verdeeld over alle bijdragende clusters, waardoor communicatie tussen clusters wordt vereenvoudigd.

Toepassingen kunnen services detecteren en ermee werken, ongeacht het cluster waarin ze zich bevinden, zonder dat wijzigingen op toepassingsniveau of externe serviceregisters nodig zijn.

Use case: Hoge beschikbaarheid en fouttolerantie

Hoge beschikbaarheid is de meest voorkomende use-case voor netwerken tussen clusters. Deze use case omvat het uitvoeren van Kubernetes-clusters in meerdere regio's of beschikbaarheidszones en het uitvoeren van replica's van dezelfde services in elk cluster. Als er een storing optreedt, kunnen aanvragen worden omgeleid naar andere clusters in het clusteroverschrijdende netwerk.

Het foutscenario dat in deze use-case wordt behandeld, is niet voornamelijk de volledige onbeschikbaarheid van een hele regio of foutdomein. Een waarschijnlijker scenario is de tijdelijke niet-beschikbaarheid van resources of onjuiste configuratie in één cluster, wat ertoe leidt dat bepaalde services in dat cluster niet kunnen worden uitgevoerd of geschaald. Met netwerken tussen clusters wordt verkeer dat is bestemd voor de betreffende service, automatisch doorgestuurd naar gezonde eindpunten in andere clusters, zodat uw toepassing beschikbaar blijft.

Diagram met twee AKS-clusters verspreid over regio's. Front-ends in elk cluster routeren naar een lokale orderservice met daarachter orderpods. Wanneer de pods in cluster B niet meer gezond zijn, schakelt de orderservice in cluster B over naar de orderservice in cluster A.

Toepassingsscenario: Gedeelde diensten

Hoewel de eerste trend van op Kubernetes gebaseerde platforms was om grote, multitenant-clusters te bouwen, wordt het steeds vaker gebruikelijk om afzonderlijke clusters per tenant te bouwen of clusters te bouwen voor verschillende categorieën services, zoals verschillende beveiligingsgevoeligheidsniveaus.

Sommige services, zoals geheimenbeheer, logboekregistratie, bewaking of DNS, worden echter vaak nog steeds gedeeld tussen alle clusters. Het centraliseren van deze services in een gedeeld servicecluster voorkomt de operationele overhead van het onderhouden ervan in elk tenantcluster.

De belangrijkste motivatie van dit model is isolatie tussen tenantclusters. Om dat doel te behouden, zijn tenantclusters alleen verbonden met het cluster met gedeelde services en zijn ze niet verbonden met andere tenantclusters.

Diagram van twee AKS-tenantclusters met toepassingen die een geheimenclient aanroepen. Beide tenantclusters worden gerouteerd naar een cluster met gedeelde services dat als host fungeert voor de geheimenservice die wordt ondersteund door kluis-1 en vault-2-pods. Tenantclusters maken alleen verbinding met het cluster met gedeelde services, niet met elkaar.

Toepassingsgeval: scheiding tussen toestandsafhankelijk en toestandloos

U kunt de operationele complexiteit van stateful services, zoals databases en opslag, isoleren in toegewezen clusters. Met deze scheiding blijven stateless toepassingsclusters flexibel en eenvoudig te migreren. Het verbetert ook de beveiliging, vereenvoudigt het levenscyclusbeheer van clusters en stelt u in staatloze workloads onafhankelijk van stateful workloads te schalen.

Diagram met twee staatloze AKS-clusters, elk met ingangsroutering naar een front-end- en gegevensopslagclient. Beide stateless clusters maken verbinding met een toegewezen stateful cluster dat als host fungeert voor de gegevensopslagservice die wordt ondersteund door data-1, data-2 en data-n pods.

Use case: beveiligings- en beleidshandhaving met meerdere clusters

Cross-clusternetwerken breidt Ciliums handhaving van Layer 3-7-netwerkbeleid uit naar alle clusters in het cross-clusternetwerk. Deze uniforme afdwinging zorgt voor een consistente beveiligingspostuur en vereenvoudigt beleidsbeheer door te voorkomen dat beleidsregels in elke omgeving handmatig moeten worden gerepliceerd. Beleidsregels die op het ene cluster worden toegepast, worden toegepast op de andere clusters en bieden geïntegreerde, identiteitsbewuste beveiliging binnen uw vloot.

Use case: waarneembaarheid voor meerdere clusters

Netwerken tussen clusters bieden end-to-end zichtbaarheid van verkeer tussen services in clusters. Door stroomgegevens van elk cluster in het netwerk tussen clusters samen te voegen, kunt u oost-west-verkeer visualiseren, de status van toepassingen bewaken in verschillende regio's, verbindingsproblemen tussen clusters oplossen en verkeerspatronen analyseren voor capaciteitsplanning.

Met containernetwerklogboeken krijgen operators een uniforme weergave van pod-naar-pod-communicatie, ongeacht in welk cluster de bron of bestemming zich bevindt, zonder toepassingen te instrumenteren.

Wereldwijde services

Als u de verkeersstroom tussen clusters wilt inschakelen, moet u uw Kubernetes-services configureren als globale services. In een netwerk tussen clusters is een globale service een standaard Kubernetes-service die wordt gedeeld in meerdere clusters. Wanneer u een service als globaal markeert, detecteert Cilium automatisch eindpunten voor die service in alle clusters binnen het netwerk tussen clusters en voert taakverdeling tussen deze clusters uit.

Zodra een service als globaal is gemarkeerd, gelden alle beleidsregels die op één cluster worden toegepast ook voor de andere clusters in het clusteroverschrijdende netwerk, wat zorgt voor een consistente beveiligingshouding. Met deze configuratie kunt u het volgende doen:

  • Transparent Service Discovery: toepassingen kunnen services detecteren en ermee werken, ongeacht het cluster waarin ze zich bevinden.
  • Hoge beschikbaarheid: als een service in een cluster niet meer beschikbaar is, wordt verkeer automatisch verplaatst naar een goed exemplaar in een ander cluster.

Cilium beheert deze detectie door te kijken naar services met de io.cilium/global-service: "true" aantekening. Voor deze services worden alle eindpunten met dezelfde naam en naamruimte in clusters samengevoegd tot één globale service. Verkeer dat bestemd is voor die service ClusterIP , wordt vervolgens verdeeld over alle bijdragende clusters.

Beperkingen

  • Een lidcluster kan slechts in één clusternetwerk tegelijk deelnemen.
  • Een enkel clusternetwerk ondersteunt maximaal 255 lidclusters.
  • Zelfbeheerde Cilium-configuraties met meerdere clusters worden niet ondersteund naast door Fleet beheerde cross-clusternetwerken.
  • Cilium CLI-opdrachten die de mesh wijzigen, zoals cilium clustermesh connect of cilium upgrade, worden niet ondersteund omdat Fleet deze bewerkingen beheert.
  • Netwerken tussen clusters zijn beperkt tot clusters binnen hetzelfde bereikbare domein voor platte routering. Het biedt geen ondersteuning voor mesh-connectiviteit tussen niet-gekoppelde virtuele netwerken.

Volgende stappen 

  • Last updated on