Panoramica del cluster Kubernetes Nexus
Questo articolo descrive i concetti di base del cluster Nexus Kubernetes, un servizio Kubernetes gestito che è possibile usare per distribuire e gestire applicazioni in contenitori in Piattaforma Operatore Nexus di Azure
Che cos'è Kubernetes?
Kubernetes è una piattaforma in rapida evoluzione che gestisce le applicazioni basate su contenitori e i componenti di rete e archiviazione associati. Kubernetes è incentrato sui carichi di lavoro applicativi e non sui componenti dell'infrastruttura sottostante. Offre un approccio dichiarativo alle distribuzioni, supportato da un solido set di API per le operazioni di gestione. Per informazioni su Kubernetes, vedere Informazioni su Kubernetes.
Servizio Nexus Kubernetes
Il servizio cluster Nexus Kubernetes è una distribuzione Kubernetes progettata per la distribuzione locale su istanze Nexus. È progettato per semplificare la creazione automatica dei contenitori ed è ottimizzato per eseguire carichi di lavoro associati alle funzioni di rete a elevato utilizzo di dati.
Come qualsiasi cluster Kubernetes, il cluster Kubernetes Nexus ha due componenti:
Piano di controllo: fornisce servizi Kubernetes di base e gestisce il ciclo di vita dei carichi di lavoro dell'applicazione.
Nodi: per eseguire le applicazioni e i servizi di supporto, è necessario un nodo Kubernetes. Fornisce l'ambiente di runtime del contenitore. Ogni cluster NKS ha almeno un nodo. Il nodo è ospitato in una VM (VM) che esegue i componenti del nodo Kubernetes. La VM viene creata come parte della distribuzione del cluster NKS nell'istanza Nexus. Esistono due tipi di pool di nodi nei cluster Nexus Kubernetes
- Quando si crea un cluster del servizio Azure Kubernetes, si definisce il numero iniziale di nodi e le relative dimensioni (SKU), che crea un pool di nodi di sistema. I pool di nodi di sistema ospitano pod di sistema critici.
- D'altra parte, per supportare applicazioni con esigenze di calcolo o archiviazione differenti, è possibile creare pool di nodi utente, noti anche come pool di agenti Nexus. Ogni VM in un pool di agenti Nexus è conforme a una configurazione uniforme, ad esempio CPU, memoria, disco e così via. Dopo aver stabilito un pool di agenti, il numero di VM al suo interno rimane fisso. Per ridimensionare la capacità di un cluster Kubernetes Nexus, è possibile creare e integrare più pool di agenti nel cluster esistente. In altre parole, il pool di Nexus Agent supporta il ridimensionamento orizzontale consentendo l'aggiunta o la rimozione di pool di agenti all'interno del cluster Kubernetes Nexus.
Tuttavia, i pod dell'applicazione possono essere pianificati nei pool di nodi di sistema nel caso in cui l'utente voglia un solo pool di nodi nel cluster. Ogni cluster Nexus Kubernetes deve contenere almeno un pool di nodi di sistema con almeno un nodo.
Componenti aggiuntivi per cluster Nexus Kubernetes
I componenti aggiuntivi del cluster Kubernetes Nexus sono una funzionalità della piattaforma Nexus che consente ai clienti di migliorare i cluster Kubernetes Nexus con pacchetti o funzionalità aggiuntivi. I componenti aggiuntivi sono classificati in due tipi: obbligatorio e facoltativo.
Componenti aggiuntivi necessari: i componenti aggiuntivi vengono distribuiti automaticamente nei cluster Kubernetes Nexus di cui è stato effettuato il provisioning. I componenti aggiuntivi principali, ad esempio Calico, MetalLB, Nexus Storage CSI, plug-in di Gestione indirizzi IP, metrics-server, node-local-dns, Arc per Kubernetes e Arc per server vengono inclusi per impostazione predefinita quando vengono creati i cluster. Il completamento corretto del processo di provisioning del cluster dipende da questi componenti aggiuntivi installati correttamente. Se un'installazione del componente aggiuntivo necessaria non riesce e non può essere corretta, lo stato del cluster viene contrassegnato come non riuscito.
Componenti aggiuntivi facoltativi: i componenti aggiuntivi sono servizi supplementari associati a una risorsa cluster Kubernetes. I clienti possono scegliere di attivare o disattivare questi componenti aggiuntivi su richiesta. Ad esempio, i servizi supplementari possono includere la distribuzione del registro di memorizzazione nella cache delle immagini locali a livello di cluster all'interno del cluster NKS per supportare scenari disconnessi. NKS consente al cliente di osservare lo stato, l'integrità e la versione di ogni componente aggiuntivo obbligatorio e facoltativo, che può essere monitorato nel portale di Azure oppure lo stato può essere recuperato usando le API di Azure Resource Manager.
I componenti aggiuntivi vengono installati una sola volta e possono essere aggiornati o aggiornati solo quando il cliente aggiorna il cluster Kubernetes Nexus. Consente ai clienti di applicare hotfix di produzione critici senza interferenze dalle operazioni dell'infrastruttura sottostanti, che altrimenti potrebbero sovrascrivere le modifiche del cluster.
Zone disponibili Nexus
Nexus ha introdotto un concetto di zona di disponibilità. Viene delineata a livello di rack e consente ai clienti di distribuire i carichi di lavoro nell'istanza per ottenere una migliore disponibilità. Per un'istanza Nexus con otto rack, i clienti ottengono otto zone di disponibilità. Ogni zona comprende una coppia di server di gestione con ridondanza e una raccolta di server di calcolo che funzionano come pool di risorse. Durante le distribuzioni multi-rack in Nexus e quando si eseguono aggiornamenti del bundle di runtime, le zone di disponibilità offrono il vantaggio aggiuntivo di fungere da dominio di aggiornamento. Ciò garantisce che, al massimo, solo i server all'interno di un singolo rack vengano portati offline per questi aggiornamenti.
Dominio di errore
Operator Nexus garantisce che i nodi del cluster Nexus Kubernetes vengano distribuiti tra domini di aggiornamento. Questa distribuzione viene eseguita in modo da migliorare la resilienza e la disponibilità del cluster. Operator Nexus usa le regole di affinità Kubernetes per pianificare i nodi in zone specifiche. Garantisce che le VM sottostanti non siano posizionate nello stesso server fisico o nello stesso dominio di aggiornamento, migliorando la tolleranza di errore del cluster.