Användningsfall för nätverk mellan kluster för Azure Kubernetes Fleet Manager (förhandsversion)

Nätverk mellan kluster för Azure Kubernetes Fleet Manager (Fleet) är ett hanterat erbjudande som bygger på Cilium Cluster Mesh som gör att du kan upprätta direkt pod-till-pod-kommunikation över flera Azure Kubernetes Service (AKS) kluster. Genom att skapa ett nätverk mellan kluster kan du aktivera sömlös öst-väst-anslutning utan behov av gatewayer, samtidigt som du får observerbarhet för flera kluster och konsekvent säkerhet.

Arkitektur och funktioner

I en nätverkskonfiguration mellan kluster gör ett platt virtuellt nätverk att poddar i olika kluster kan dirigera trafik direkt över klustergränser. Varje kluster tilldelas vanligtvis två undernät: ett för noder och ett för poddar. Den här konsekventa arkitekturen säkerställer att poddnätverket förblir platt över nätverket mellan kluster, utan användning av överlägg eller tunnlar.

Diagram som visar arkitekturen för Azure Kubernetes Fleet Manager som hanterar anslutningar mellan kluster, öst-väst. Poddar i olika kluster kommunicerar direkt via Cilium-agenter mellan peer-kopplade virtuella nätverk.

Viktiga komponenter och funktioner för det här scenariot är:

  • Azure CNI med Cilium-dataplanet: Båda AKS-kluster måste använda Azure CNI med Azure CNI som drivs av Cilium-dataplanet.
  • Advanced Container Networking Services (ACNS): ACNS måste vara aktiverat i klustren för att stödja det här scenariot.
  • Azure Kubernetes Fleet Manager: Fleet hanterar livscykeln och konfigurationen av nätverket mellan kluster via resurser som profilen ClusterMesh.
  • Intern prestanda: Podd-IP-routning sker mellan kluster med inbyggda prestanda via direktdirigering, vilket kringgår behovet av gatewayer eller proxyservrar.
  • Enhetlig nätverksprinciptillämpning: Utökar Ciliums layer 3-7-nätverksprinciptillämpning till alla kluster i nätverket mellan kluster, vilket säkerställer en konsekvent säkerhetsmetod.
  • Observerbarhet för flera kluster: Ger insyn i trafikflöden mellan kluster från slutpunkt till slutpunkt. Den här synligheten hjälper dig att övervaka programmets hälsa, felsöka anslutningsproblem och analysera trafikmönster i nätverket mellan kluster.

Användningsfall

Nätverk mellan kluster möjliggör flera viktiga scenarier med flera kluster. I följande avsnitt beskrivs de vanligaste användningsfallen för nätverk mellan kluster med Fleet.

Användningsfall: Transparent tjänstidentifiering och belastningsutjämning

När du använder Kubernetes-standardtjänster och markerar dem som globala identifierar Cilium automatiskt slutpunkter för dessa tjänster i alla kluster i nätverket mellan kluster. All trafik som är avsedd för en global tjänst ClusterIP lastbalanseras automatiskt över alla bidragande kluster, vilket förenklar kommunikationen mellan kluster.

Program kan identifiera och interagera med tjänster oavsett vilket kluster de finns i, utan att kräva ändringar på programnivå eller externa tjänstregister.

Användningsfall: Hög tillgänglighet och feltolerans

Hög tillgänglighet är det vanligaste användningsfallet för nätverk mellan kluster. Det här användningsfallet omfattar att använda Kubernetes-kluster i flera regioner eller tillgänglighetszoner och köra repliker av samma tjänster i varje kluster. Om ett fel uppstår kan begäranden växlas över till andra kluster i det klusteröverskridande nätverket.

Det felscenario som beskrivs i det här användningsfallet är inte i första hand fullständig otillgänglighet för en hel region eller feldomän. Ett mer troligt scenario är den tillfälliga otillgängligheten av resurser eller felkonfiguration i ett kluster, vilket leder till att det inte går att köra eller skala vissa tjänster i klustret. Med nätverk mellan kluster dirigeras trafik som är avsedd för den berörda tjänsten automatiskt till felfria slutpunkter i andra kluster, vilket håller programmet tillgängligt.

Diagram som visar två AKS-kluster över flera regioner. Frontendkomponenter i varje kluster dirigerar trafik till en lokal ordertjänst som stöds av orderpoddar. När poddarna i kluster B blir felaktiga växlar ordertjänsten i kluster B över till ordertjänsten i kluster A.

Användningsfall: Delade tjänster

Den inledande trenden med Kubernetes-baserade plattformar var att skapa stora kluster med flera klienter, men det blir allt vanligare att skapa enskilda kluster per klientorganisation eller att skapa kluster för olika kategorier av tjänster, till exempel olika nivåer av säkerhetskänslighet.

Vissa tjänster som hantering av hemligheter, loggning, övervakning eller DNS delas dock ofta fortfarande mellan alla kluster. Genom att centralisera dessa tjänster i ett delat "tjänstkluster" undviker du driftkostnaderna för att underhålla dem i varje klientkluster.

Den primära motivationen för den här modellen är isolering mellan klientkluster. För att upprätthålla det målet är klientkluster endast anslutna till klustret för delade tjänster och är inte anslutna till andra klientkluster.

Diagram som visar två AKS-klientkluster med program som anropar en hemlighetsklient. Båda klientkluster dirigeras till ett kluster för delade tjänster som är värd för den hemlighetstjänst som backas upp av poddar för valv-1 och valv-2. Klientkluster ansluter endast till klustret för delade tjänster, inte till varandra.

Användningsscenario: Separation mellan med tillstånd och utan tillstånd

Du kan isolera driftskomplexiteten för tillståndskänsliga tjänster, till exempel databaser och lagring, i dedikerade kluster. Den här separationen gör tillståndslösa programkluster flexibla och enkla att migrera. Det förbättrar också säkerheten, förenklar hanteringen av klustrets livscykel och gör att du kan skala tillståndslösa arbetsbelastningar oberoende av tillståndsfulla arbetsbelastningar.

Diagram som visar två tillståndslösa AKS-kluster, vart och ett med ingressdirigering till en frontend och en datalagerklient. Båda tillståndslösa klustren ansluter till ett dedikerat tillståndsfullt kluster som är värd för datalagertjänsten, med stöd av data-1-, data-2- och data-n-poddar.

Användningsfall: Säkerhet och principtillämpning för flera kluster

Nätverk över kluster utökar Ciliums framtvingande av nätverkspolicyer på lager 3–7 i alla kluster i nätverket över kluster. Den här enhetliga tillämpningen säkerställer en konsekvent säkerhetsstatus och förenklar principhanteringen genom att undvika behovet av att manuellt replikera principer i varje miljö. Principer som tillämpas på ett kluster respekteras i de andra klustren, vilket ger enhetlig, identitetsmedveten säkerhet i hela din flotta.

Användningsfall: Observerbarhet för flera kluster

Nätverk mellan kluster ger insyn i trafik som flödar mellan tjänster mellan kluster från slutpunkt till slutpunkt. Genom att aggregera flödesdata från varje kluster i nätverket mellan kluster kan du visualisera trafik mellan öst och väst, övervaka programmets hälsa mellan regioner, felsöka anslutningsproblem mellan kluster och analysera trafikmönster för kapacitetsplanering.

Med containernätverksloggar får operatörerna en enhetlig vy över podd-till-pod-kommunikation oavsett vilket kluster källan eller målet finns i, utan att instrumentera program.

Globala tjänster

Om du vill aktivera trafikflödet mellan kluster måste du konfigurera dina Kubernetes-tjänster som globala tjänster. I ett nätverk mellan kluster är en global tjänst en Kubernetes-standardtjänst som delas mellan flera kluster. När du markerar en tjänst som global identifierar Cilium automatiskt slutpunkter för den tjänsten i alla kluster i nätverket mellan kluster och utför belastningsutjämning över dem.

När en tjänst har markerats som global respekteras alla principer som tillämpas på ett kluster i de andra klustren i nätverket mellan kluster, vilket ger en konsekvent säkerhetsstatus. Med den här konfigurationen kan du:

  • Transparent tjänstidentifiering: Program kan identifiera och interagera med tjänster oavsett vilket kluster de finns i.
  • Hög tillgänglighet: Om en tjänst i ett kluster blir otillgänglig flyttas trafiken automatiskt till en felfri instans i ett annat kluster.

Cilium hanterar den här identifieringen genom att titta efter tjänster med anteckningen io.cilium/global-service: "true" . För dessa tjänster sammanfogas alla slutpunkter med samma namn och namnområde mellan kluster till en enda global tjänst. All trafik som är avsedd för tjänsten ClusterIP lastbalanseras sedan över alla bidragande kluster.

Limitations

  • Ett medlemskluster kan bara delta i ett nätverk mellan kluster i taget.
  • Ett enda nätverk mellan kluster stöder upp till 255 medlemskluster.
  • Självhanterade Cilium-konfigurationer för flera kluster stöds inte tillsammans med fleethanterade nätverk mellan kluster.
  • Cilium CLI-kommandon som ändrar nätet, till exempel cilium clustermesh connect eller cilium upgrade, stöds inte eftersom Fleet hanterar dessa åtgärder.
  • Nätverk mellan kluster är begränsade till kluster inom samma nåbara platta routningsdomän. Den stöder inte mesh-anslutning över icke-kopplade virtuella nätverk.

Nästa steg

  • Last updated on