Informazioni di base sul Registro cluster

Migliorare la resilienza per le funzioni di rete nativa del cloud con registro cluster di Azure Operator Service Manager (AOSM)

Cronologia documenti

• Created & First Published: 26 luglio 2024
• Aggiornato per la disponibilità elevata: 16 ottobre 2024
• Aggiornamento per GC: 5 novembre 2024

Dipendenze delle funzionalità

Questa funzionalità richiede l'ambiente minimo seguente:

• Versione minima dell'API ARM AOSM: 2023-09-01
• Prima versione, nessuna disponibilità elevata (HA) per l'estensione kubernetes (NF): 1.0.2711-7
• Prima versione, con disponibilità elevata per l'estensione kubernetes NF: 2.0.2810-144
• Prima versione, con GC per l'estensione kubernetes NF: 2.0.2860-160

Panoramica del Registro di sistema del cluster

Il registro cluster di Azure Operator Service Manager (AOSM) consente una copia locale delle immagini del contenitore nel cluster Nexus K8s. Quando la funzione di rete in contenitori (CNF) viene installata con il registro cluster abilitato, le immagini del contenitore vengono estratte dall'archivio degli artefatti AOSM remoto e salvate in questo registro cluster locale. Usando un webhook modificante, il Registro di sistema del cluster intercetta automaticamente le richieste di immagine e sostituisce il percorso del Registro di sistema locale per evitare modifiche ai pacchetti dell'editore. Con il registro del cluster, l'accesso CNF alle immagini del contenitore sopravvive alla perdita di connettività all'archivio artefatto remoto.

Casi d'uso e vantaggi principali

Le funzioni di rete native del cloud (CNF) devono accedere alle immagini del contenitore, non solo durante la distribuzione iniziale usando l'archivio artefatti di AOSM, ma anche per mantenere operativa la funzione di rete. Alcuni di questi scenari includono:

• Riavvii del pod: l'arresto e l'avvio di un pod possono comportare il pull di immagini del contenitore dal registro.
• Operazioni dell'utilità di pianificazione Kubernetes: durante le assegnazioni da pod a nodo, in base alle regole del profilo dell'utilità di pianificazione, se il nuovo nodo non dispone delle immagini del contenitore memorizzate nella cache locale, il nodo esegue il pull delle immagini del contenitore dal registro.

Vantaggi dell'uso del registro cluster AOSM:

• Fornisce le immagini locali necessarie per evitare interruzioni CNF in cui viene persa la connettività all'archivio artefatti di AOSM.
• Riduce il numero di pull delle immagini nell'archivio degli artefatti di AOSM, poiché ogni nodo del cluster esegue ora il pull delle immagini solo dal registro locale.
• Supera i problemi relativi agli URL del Registro di sistema in formato non valido, usando un webhook modificante per sostituire il percorso dell'URL del Registro di sistema locale appropriato.

Funzionamento del Registro di sistema del cluster

Il Registro di sistema del cluster AOSM è abilitato tramite l'estensione Arc K8s NFO (Network Function Operator). L'interfaccia della riga di comando seguente illustra come il Registro di sistema del cluster è abilitato in un cluster Nexus K8s.

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]

Quando la funzionalità del Registro di sistema del cluster è abilitata nell'estensione Network Function Operator Arc K8s, tutte le immagini del contenitore distribuite dall'archivio artefatti AOSM sono accessibili localmente nel cluster Nexus K8s. L'utente può scegliere le dimensioni di archiviazione permanenti per il Registro di sistema del cluster.

Nota

Se l'utente non fornisce alcun input, viene usato un volume permanente predefinito di 100 GB.

Componenti del Registro di sistema del cluster

La funzionalità del Registro di sistema del cluster distribuisce pod helper nel cluster perimetrale di destinazione per facilitare l'estensione NFO.

Riconciliatore dei componenti

• Questo pod principale si occupa della riconciliazione dei componenti Custom Resource Objects (CROs) creati da K8sBridge con l'aiuto del provider di risorse Microsoft.Kubernetes (RP), dell'inoltro ibrido e dell'agente Arc in esecuzione nel cluster.

Webhook di modifica dei pod

• Questi pod implementano Kubernetes modificando i webhook di ammissione, servendo un'istanza dell'API mutata. L'API mutata esegue due operazioni:
  • Modifica il percorso del registro immagini all'INDIRIZZO IP del Registro di sistema locale, sostituendo l'archivio artefatto di Azure Container (ACR) dell'archivio artefatti di AOSM.
  • Crea un elemento CR nel cluster perimetrale.

Riconciliatore artefatto

• Questo pod riconcilia gli elementi CRO creati dal webhook modificante.

Registro

• Questo pod archivia e recupera le immagini del contenitore per CNF.

Garbage Collection del Registro di sistema del cluster

L'estensione del cluster AOSM esegue un processo di Garbage Collection (GC) in background per pulire regolarmente le immagini del contenitore. Questo processo verrà eseguito in base a una pianificazione, verificare se l'utilizzo del Registro di sistema del cluster ha raggiunto la soglia specificata e, in tal caso, avviare il processo di Garbage Collection. La pianificazione e la soglia del processo vengono configurate dall'utente finale, ma per impostazione predefinita il processo viene eseguito una volta al giorno a una soglia di utilizzo pari allo 0%.

Pulire i manifesti dell'immagine di Garbage

AOSM gestisce i riferimenti tra la risorsa proprietario del pod e l'utilizzo di immagini nel Registro di sistema del cluster. All'avvio del processo di pulizia delle immagini, le immagini verranno identificate che non sono collegate ad alcun pod, eseguendo un'eliminazione temporanea per rimuoverle dal Registro di sistema del cluster. Questo tipo di eliminazione temporanea non libera immediatamente lo spazio di archiviazione del Registro di sistema del cluster. La rimozione effettiva dei file di immagine dipende dalla Garbage Collection del Registro di distribuzione DI FRAMEWORKF descritta di seguito.

Nota

Il riferimento tra il proprietario di un pod e le relative immagini del contenitore garantisce che AOSM non elimini erroneamente le immagini. Ad esempio, se un pod del set di repliche diventa inattivo, AOSM non dereferenzierà le immagini del contenitore. AOSM dereferenzia solo le immagini del contenitore quando il set di repliche viene eliminato. Lo stesso principio si applica ai pod gestiti da processi e daemonset Kubernetes.

Distribuzione di Garbage Collection INF

AOSM configura il Registro di sistema del cluster usando il Registro di sistema di distribuzione KUBF open source. Di conseguenza, AOSM si basa sulle funzionalità di Garbage Collection fornite da Garbage Collection | Distribuzione DI FRAMEWORKF. Nel complesso, segue il processo standard "mark and sweep" fase 2 per eliminare i file di immagine per liberare spazio di archiviazione del Registro di sistema.

Nota

Questo processo richiede il Registro di sistema del cluster in modalità di sola lettura. Se le immagini vengono caricate quando il Registro di sistema non è in modalità di sola lettura, esiste il rischio che i livelli delle immagini vengano erroneamente eliminati causando un'immagine danneggiata. Il Registro di sistema richiede il blocco in modalità di sola lettura per una durata massima di 1 minuto. Di conseguenza, AOSM rinvierà altre distribuzioni NF quando il Registro di sistema del cluster è in modalità di sola lettura.

Parametri di configurazione di Garbage Collection

I parametri seguenti consentono di configurare la pianificazione e la soglia per il processo di Garbage Collection.

• global.networkfunctionextension.clusterRegistry.clusterRegistryGCCadence
• global.networkfunctionextension.clusterRegistry.clusterRegistryGCThreshold
• Per altre informazioni sulla configurazione, vedere le istruzioni più recenti per l'installazione dell'estensione della funzione di rete

Considerazioni sulla disponibilità elevata e sulla resilienza

L'estensione NF di AOSM usa un webhook e un Registro di sistema perimetrale mutevoli per supportare le funzionalità principali.

• Onboarding dei grafici Helm senza richiedere la personalizzazione del percorso dell'immagine.
• Registro cluster locale per accelerare le operazioni dei pod e abilitare il supporto in modalità disconnessa. Questi componenti essenziali devono essere altamente disponibili e resilienti.

Riepilogo delle modifiche per la disponibilità elevata

Con disponibilità elevata, i pod del registro cluster e del webhook ora supportano un set di repliche con almeno tre repliche e un massimo di cinque repliche. La configurazione della chiave del set di repliche è la seguente:

• Viene usata la strategia di aggiornamento graduale dell'implementazione.
• PodDisruptionBudgets (PDB) viene usato per la disponibilità durante interruzioni volontarie.
• L'anti-affinità dei pod viene usata per distribuire i pod in modo uniforme tra i nodi.
• I probe di idoneità vengono usati per assicurarsi che i pod siano pronti prima di gestire il traffico.
• I pod del carico di lavoro AOSM vengono assegnati solo al pool di nodi di sistema.
• I pod si ridimensionano orizzontalmente in base al carico della CPU e della memoria.

Repliche

• Un cluster che esegue più copie o repliche di un'applicazione fornisce il primo livello di ridondanza. Sia il registro cluster che il webhook sono definiti come "kind:deployment" con almeno tre repliche.

DeploymentStrategy

• Viene usata una strategia rollingUpdate per ottenere aggiornamenti senza tempi di inattività e supportare l'implementazione graduale delle applicazioni. La configurazione maxUnavailable predefinita consente di arrestare un solo pod alla volta fino a quando non vengono creati pod sufficienti per soddisfare i criteri di ridondanza.

Budget interruzione pod

• Un budget di interruzione dei criteri protegge i pod da interruzioni volontarie e viene distribuito insieme a oggetti Deployment, ReplicaSet o StatefulSet. Per i pod dell'operatore AOSM, viene usato un PDB con parametro minAvailable pari a 2.

Anti-affinità pod

• L'anti-affinità pod controlla la distribuzione dei pod dell'applicazione tra più nodi nel cluster. Con disponibilità elevata, l'anti-affinità dei pod AOSM usa i parametri seguenti:
  • Viene usata una modalità di pianificazione per definire il modo in cui viene applicata rigorosamente la regola.
    • requiredDuringSchedulingIgnoredDuringExecution(Hard): i pod devono essere pianificati in modo da soddisfare la regola definita. Se non sono disponibili topologie che soddisfano i requisiti della regola, il pod non è pianificato.
    • preferredDuringSchedulingIgnoredDuringExecution(Soft): questo tipo di regola esprime una preferenza per la pianificazione dei pod, ma non impone un requisito rigoroso. Se sono disponibili topologie che soddisfano i criteri di preferenza, Kubernetes pianifica il pod. Se non sono disponibili topologie di questo tipo, il pod può comunque essere pianificato in altri nodi che non soddisfano le preferenze.
  • Un selettore di etichette viene usato per specificare come destinazione pod specifici per cui viene applicata l'affinità.
  • Per definire le esigenze del nodo viene usata una chiave di topologia.
• Il posizionamento dei nodi Nexus viene distribuito uniformemente tra le zone in base alla progettazione, quindi la distribuzione dei pod tra i nodi offre anche ridondanza di zona.
• I pod dell'operatore AOSM usano un'anti-affinità soft con peso 100 e la chiave di topologia in base ai nomi host del nodo.

Storage

• Poiché il Registro di sistema perimetrale AOSM dispone di più repliche distribuite tra nodi, il volume permanente deve supportare la modalità di accesso ReadWriteMany (RWX). Il volume "nexus-shared" di PVC è disponibile nei cluster Nexus e supporta la modalità di accesso RWX.

Monitoraggio tramite probe di idoneità

• AOSM usa probe di idoneità HTTP per sapere quando un contenitore è pronto per iniziare ad accettare il traffico. Un pod è considerato pronto quando tutti i contenitori sono pronti. Quando un pod non è pronto, viene rimosso dai servizi di bilanciamento del carico del servizio.

Pool di nodi di sistema

• Tutti i pod dell'operatore AOSM vengono assegnati al pool di nodi di sistema. Questo pool impedisce che i pod dell'applicazione non configurati o rossi influiscano negativamente su pod di sistema.

Scalabilità orizzontale

• In Kubernetes, horizontalPodAutoscaler (HPA) aggiorna automaticamente una risorsa del carico di lavoro con l'obiettivo di ridimensionare automaticamente il carico di lavoro in base alla domanda. I pod degli operatori AOSM hanno i parametri dei criteri HPA seguenti configurati;
  • Una replica minima di tre.
  • Una replica massima di cinque.
  • TargetAverageUtilization per cpu e memoria pari all'80%.

Limiti delle risorse

• I limiti delle risorse vengono usati per impedire un overload di risorse nei nodi in cui sono in esecuzione i pod di AOSM. AOSM usa due parametri di risorsa per limitare sia l'utilizzo della CPU che della memoria.
  • Richiesta di risorsa: quantità minima che deve essere riservata per un pod. Questo valore deve essere impostato sull'utilizzo delle risorse con carico normale per l'applicazione.
  • Limite di risorse: quantità massima che un pod deve mai usare, se l'utilizzo raggiunge il limite che viene terminato. Tutti i contenitori degli operatori AOSM sono configurati con una richiesta appropriata, un limite per CPU e memoria.

Limitazioni note della disponibilità elevata

• I cluster Nexus AKS (NAKS) con un singolo nodo attivo nel pool di agenti di sistema non sono adatti per la disponibilità elevata. La topologia di produzione Nexus deve usare almeno tre nodi attivi nel pool di agenti di sistema.
• La classe di archiviazione nexus-shared è un servizio di archiviazione NFS (Network File System). Questo servizio di archiviazione NFS è disponibile per ogni rete del servizio cloud. Qualsiasi cluster Nexus Kubernetes collegato al CSN può effettuare il provisioning del volume permanente da questo pool di archiviazione condiviso. Il pool di archiviazione è attualmente limitato a una dimensione massima di 1 TiB a partire da Network Cloud (NC) 3.10 dove nc 3.12 ha un'opzione di 16 TiB.
• L'affinità pod Anti gestisce solo il posizionamento iniziale dei pod, il ridimensionamento e il ripristino successivi, segue la logica di pianificazione standard K8s.

Domande frequenti

È possibile usare il registro cluster AOSM con un'applicazione CNF distribuita in precedenza?

Se è già stata distribuita un'applicazione CNF senza registro cluster, le immagini del contenitore non sono disponibili automaticamente. Prima di distribuire la funzione di rete con AOSM, è necessario abilitare il Registro di sistema del cluster.

È possibile modificare le dimensioni di archiviazione dopo una distribuzione?

Le dimensioni di archiviazione non possono essere modificate dopo la distribuzione iniziale. È consigliabile configurare le dimensioni del volume da 3x a 4x delle dimensioni iniziali.

È possibile elencare i file attualmente archiviati nel repository del cluster?

Il comando seguente può essere usato per elencare i file in un formato leggibile:

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

Questo comando dovrebbe produrre un output simile al seguente:

 ppleltestpublisheras2f88b55037.azurecr.io/nginx:1.0.0