Kom igång med klusterregister

Förbättra återhämtning för molnbaserade nätverksfunktioner med Azure Operator Service Manager (AOSM) klusterregister (CR)

Dokumenthistorik

• Skapad & först publicerad: 26 juli 2024
• Uppdaterad för HA: 16 oktober 2024
• Uppdaterad för GC: 5 november 2024

Funktionsberoenden

Den här funktionen kräver följande minsta miljö:

• Lägsta version av AOSM ARM API: 2023-09-01
• Första versionen, ingen hög tillgänglighet (HA) för NF(Network Function) kubernetes-tillägget: 1.0.2711-7
• Första versionen, med HA för NF kubernetes-tillägget: 2.0.2810-144
• Första versionen, med GC för NF kubernetes-tillägget: 2.0.2860-160

Översikt över klusterregister

Azure Operator Service Manager (AOSM) klusterregister (CR) möjliggör en lokal kopia av containeravbildningar i Nexus K8s-klustret. När den containerbaserade nätverksfunktionen (CNF) installeras med klusterregistret aktiverat hämtas containeravbildningarna från det fjärranslutna AOSM-artefaktarkivet och sparas i det här lokala klusterregistret. Klusterregister, med hjälp av en muterande webhook, fångar automatiskt upp avbildningsbegäranden och ersätter den lokala registersökvägen för att undvika ändringar i utgivarens paketering. Med klusterregister överlever CNF-åtkomst till containeravbildningar att anslutningen till fjärrartefaktarkivet går förlorad.

Viktiga användningsfall och fördelar

Molnbaserade nätverksfunktioner (CNF) behöver åtkomst till containeravbildningar, inte bara under den första distributionen med hjälp av AOSM-artefaktarkivet, utan även för att hålla nätverksfunktionen i drift. Några av dessa scenarier är:

• Poddstarter: Om du stoppar och startar en podd kan det leda till att en klusternod hämtar containeravbildningar från registret.
• Kubernetes scheduler-åtgärder: Under podd-till-nodtilldelningar hämtar noden containeravbildningar från registret om den nya noden inte har containeravbildningarna lokalt cachelagrade.

Fördelar med att använda AOSM-klusterregister:

• Tillhandahåller nödvändiga lokala avbildningar för att förhindra CNF-avbrott där anslutningen till AOSM-artefaktarkivet går förlorad.
• Minskar antalet avbildningshämtningar i AOSM-artefaktarkivet, eftersom varje klusternod nu endast hämtar avbildningar från det lokala registret.
• Löser problem med felaktiga register-URL:er genom att använda en muterande webhook för att ersätta rätt url-sökväg för det lokala registret.

Kommandosyntax för klusterregister

AOSM-klusterregistret är aktiverat med tillägget NFO (Network Function Operator). Följande CLI visar hur klusterregistret är aktiverat i ett Nexus K8s-kluster.

az k8s-extension create --cluster-name
                        --cluster-type {connectedClusters}
                        --extension-type {Microsoft.Azure.HybridNetwork}
                        --name
                        --resource-group
                        --scope {cluster}
                        --release-namespace {azurehybridnetwork}
                        --release-train {preview, stable}
                        --config Microsoft.CustomLocation.ServiceAccount=azurehybridnetwork-networkfunction-operator
                        [--auto-upgrade {false, true}]
                        [--config global.networkfunctionextension.enableClusterRegistry={false, true}]
                        [--config global.networkfunctionextension.enableLocalRegistry={false, true}]
                        [--config global.networkfunctionextension.enableEarlyLoading={false,true}]
                        [--config global.networkfunctionextension.clusterRegistry.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.highAvailability.enabled={true, false}]
                        [--config global.networkfunctionextension.webhook.autoScaling.enabled={true, false}]
                        [--config global.networkfunctionextension.clusterRegistry.storageClassName=]
                        [--config global.networkfunctionextension.clusterRegistry.storageSize=]
                        [--config global.networkfunctionextension.webhook.pod.mutation.matchConditionExpression=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence=]
                        [--config global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold=]
                        [--version]

När klusterregisterfunktionen är aktiverad i Arc K8s-tillägget för nätverksfunktionsoperatorn är alla containeravbildningar som distribueras från AOSM-artefaktarkivet tillgängliga lokalt i Nexus K8s-klustret. Användaren kan välja den beständiga lagringsstorleken för klusterregistret.

Kommentar

Om användaren inte anger några indata används en permanent standardvolym på 100 GB.

Klusterregisterkomponenter

Funktionen klusterregister distribuerar hjälppoddar i målgränsklustret för att hjälpa NFO-tillägget.

Komponentstämning

• Den här huvudpodden tar hand om att förena komponenten Anpassade resursobjekt (CROs) som skapats av K8sBridge med hjälp av Microsoft.Kubernetes resursprovidern (RP), Hybrid Relay och Arc-agenten som körs på klustret.

Webhook för poddmuterande

• Dessa poddar implementerar Kubernetes som muterar webhooks för antagning och som betjänar en instans av mutate-API:et. Mutate-API:et gör två saker:
  • Den ändrar sökvägen för avbildningsregistret till ip-adressen för det lokala registret och ersätter AOSM-artefaktarkivet Azure Container Registry (ACR).
  • Den skapar en artefakt-CR på kantklustret.

Artefaktstämning

• Den här podden stäms av artefakt-CROs som skapats av den muterande webhooken.

Register

• Den här podden lagrar och hämtar containeravbildningar för CNF.

Överväganden för hög tillgänglighet och återhämtning

AOSM NF-tillägget använder en muterande webhook och edge-register för att stödja viktiga funktioner.

• Registrera helm-diagram utan att kräva anpassning av bildsökvägen.
• Ett lokalt klusterregister för att påskynda poddåtgärder och aktivera stöd för frånkopplat läge. Dessa viktiga komponenter måste vara mycket tillgängliga och motståndskraftiga.

Information om HA-driftläge

Med HA aktiverat stöder klusterregister- och webhook-poddar en replikuppsättning med minst tre repliker och högst fem repliker. Konfigurationen av replikuppsättningsnyckeln är följande:

• Strategi för gradvis distributionsuppgradering används.
• PodDisruptionBudgets (PDB) används för tillgänglighet vid frivilliga avbrott.
• Poddskyddstillhörighet används för att sprida poddar jämnt över noder.
• Beredskapsavsökning används för att se till att poddar är redo innan de betjänar trafik.
• AOSM-arbetsbelastningspoddar tilldelas endast till systemnodpoolen.
• Poddar skalas vågrätt under CPU- och minnesbelastning.

Repliker

• Ett kluster som kör flera kopior eller repliker av ett program ger den första redundansnivån. Både klusterregistret och webhooken definieras som "kind:deployment" med minst tre repliker och högst fem repliker.

Utplaceringsstrategi

• En rollingUpdate-strategi används för att uppnå noll avbrottsuppgraderingar och stödja gradvis distribution av program. Standardkonfigurationen maxUnavailable tillåter endast att en podd tas ned i taget, tills tillräckligt många poddar har skapats för att uppfylla redundanspolicyn.

Poddstörningsbudget

• En budget för principstörningar (PDB) skyddar poddar från frivilliga avbrott och distribueras tillsammans med distributions-, replikuppsättnings- eller statefulSet-objekt. För AOSM-operatorpoddar används en PDB med minAvailable-parametern 2.

Poddskyddstillhörighet

• Poddskyddstillhörighet styr distributionen av programpoddar över flera noder i klustret. Med HA aktiverat implementerar AOSM följande regler mot tillhörighet:
  • En regeltyp preferredDuringSchedulingIgnoredDuringExecution (Soft) används. Med mjuk schemaläggning är topologier som uppfyller inställningskriterierna tillgängliga, Kubernetes schemalägger podden. Om inga sådana topologier är tillgängliga kan podden fortfarande schemaläggas på andra noder som inte uppfyller inställningen.
  • En topologinyckel används baserat på värdet för kubernetes.io/hostname.
  • En vikt på 100 används.

Nodtillhörighet

Nexus-nodplacering sprids jämnt mellan zoner genom design, vilket resulterar i zonredundans. AOSM sprider poddar jämnt över noder med hjälp av följande regler:

• Föredrar noder utan rollen "kontrollplan" (vikt: 10)
• Föredrar noder med systemläge (vikt: 20)

Förvaring

• Eftersom AOSM edge-registret har flera repliker, som är spridda över noder, måste den beständiga volymen ha stöd för åtkomstläge för ReadWriteManyX (RWX). PVC "nexus-shared; volymen är tillgänglig i Nexus-kluster och stöder RWX-åtkomstläge.

Övervakning via beredskapsavsökningar

• AOSM använder http-beredskapsavsökningar för att veta när en container är redo att börja ta emot trafik. En podd anses vara klar när alla containrar är klara. När en podd inte är klar tas den bort från tjänstens lastbalanserare.

Systemnodpool

• Alla AOSM-operatorpoddar tilldelas till systemnodpoolen. Den här poolen förhindrar att felkonfigurerade programpoddar eller rouge-programpoddar påverkar systempoddar.

Horisontell skalning

• I Kubernetes uppdaterar en HorizontalPodAutoscaler (HPA) automatiskt en arbetsbelastningsresurs i syfte att automatiskt skala arbetsbelastningen så att den matchar efterfrågan. AOSM-operatörspoddar har följande HPA-principparametrar konfigurerade.
  • En minsta replik på tre.
  • En maximal replik på fem.
  • En targetAverageUtilization för cpu och minne på 80 %.

Resursgränser

• Resursbegränsningar används för att förhindra en resursöverbelastning på noderna där AOSM-poddar körs. AOSM använder två resursparametrar för att begränsa både PROCESSOR- och minnesförbrukning.
  • Resursbegäran – det minsta belopp som ska reserveras för en podd. Det här värdet ska anges till resursanvändning under normal belastning för ditt program.
  • Resursgräns – Den maximala mängd som en podd någonsin ska använda, om användningen når gränsen den avslutas. Alla AOSM-operatorcontainrar konfigureras med lämplig begäran, gräns för processor och minne.

Kända ha-begränsningar

• Nexus AKS-kluster (NAKS) med en enda aktiv nod i systemagentpoolen lämpar sig inte för hög tillgänglighet. Nexus-produktionstopologi måste använda minst tre aktiva noder i systemagentpoolen.
• Den nexus-delade lagringsklassen är en NFS-lagringstjänst (Network File System). Den här NFS-lagringstjänsten är tillgänglig per Cloud Service Network (CSN). Alla Nexus Kubernetes-kluster som är anslutna till CSN kan etablera beständiga volymer från den här delade lagringspoolen. Lagringspoolen är för närvarande begränsad till en maximal storlek på 1 TiB från och med Network Cloud (NC) 3.10 där som NC 3.12 har ett 16-TiB-alternativ.
• Poddskyddstillhörighet hanterar endast den inledande placeringen av poddar, efterföljande poddskalning och reparation, följer standardlogik för K8s-schemaläggning.

Automatisk rensning av klusterregister

När det är aktiverat kör AOSM NFO-tillägget ett GC-jobb (Background Garbage Collection) för att regelbundet rensa NAKS-klusterregistret. Skräpinsamling är processen för att ta bort artefakter från filsystemet när de inte längre refereras till av några manifest. Med skräpinsamling kan en användare bättre hantera diskutrymmet som används av klusterregistret. Skräpinsamling är också ett säkerhetsövervägande när det är önskvärt att se till att vissa lager inte längre finns i filsystemet. GC-jobbet körs baserat på ett schema, kontrollerar om klusterregisteranvändningen når det angivna tröskelvärdet och initierar i så fall skräpinsamlingsprocessen.

Rensa oanvända bildmanifest

AOSM underhåller referenser mellan poddägarens resurs och använder artefakter i klusterregistret. När rensningsprocessen för klusterregistret har påbörjats identifieras artefakter som inte är länkade till poddar och en mjuk borttagning utfärdas för att ta bort dem från klusterregistret. Den här typen av mjuk borttagning frigör inte omedelbart klusterregisterlagringsutrymme. Faktisk borttagning av avbildningsfiler beror på inställningarna för den faktiska registerskräpainsamlingen.

Kommentar

Referensen mellan en podds ägare och dess containerartefakter säkerställer att AOSM inte tar bort artefakter av misstag. Om en replikuppsättningspodd till exempel slutar fungera, avrefererar inte AOSM artefakterna. AOSM avrefereras endast artefakter när replikuppsättningen tas bort. Samma princip gäller för poddar som hanteras av Kubernetes-jobb och daemonsets.

Distribution av skräpinsamling

AOSM är beroende av skräpinsamlingsfunktioner som tillhandahålls av skräpinsamling | Offentlig distribution. AOSM implementerar en standardprocess med två faser för att ta bort artefakter och ledigt registerlagringsutrymme. Först markeras berättigade bilder och sedan rensas de under en svepning endast om vissa kriterier uppfylls.

Kommentar

GC-processen kräver att klusterregistret är i skrivskyddat läge. Annars finns det en risk att artefakter kan tas bort av misstag, vilket leder till artefaktskada. När GC körs låser det registret i skrivskyddat läge i upp till 1 minut. Under den här tiden defersar AOSM nya åtgärder tills registerlåset släpps.

Parametrar för automatisk rensning av klusterregister

Följande parametrar konfigurerar schemat och tröskelvärdet för skräpinsamlingsjobbet.

• (global.nätverksfunktionförlängning.klusterregister.klusterregisterGCCadens)
• global.nätverksfunktionutvidgning.klusterRegister.klusterRegisterGCThreshold
• Mer konfigurationsinformation finns i de senaste installationsanvisningarna för nätverksfunktionens tillägg

Vanliga frågor och svar

Kan jag använda AOSM-klusterregister med ett CNF-program som tidigare distribuerats?

Om det redan finns ett CNF-program som har distribuerats utan klusterregister är containeravbildningarna inte tillgängliga automatiskt. Klusterregistret måste vara aktiverat innan du distribuerar nätverksfunktionen med AOSM.

Kan jag ändra lagringsstorleken efter en distribution?

Lagringsstorleken kan inte ändras efter den första distributionen. Vi rekommenderar att du konfigurerar volymstorleken med 3x till 4x av startstorleken.

Kan jag lista de filer som för närvarande lagras i klusterlagringsplatsen?

Följande kommando kan användas för att visa filer i ett läsbart format:

 kubectl get artifacts -A -o jsonpath='{range .items[*]}{.spec.sourceArtifact}'

Det här kommandot bör generera följande utdata:

 ppleltestpublisheras2f88b55037.azurecr.io/nginx:1.0.0