Architettura del cluster Kubernetes e carichi di lavoro per il servizio Azure Kubernetes abilitato da Azure Arc

Articolo
02/15/2024

Si applica a: Servizio Azure Kubernetes in Azure Stack HCI 22H2, servizio Azure Kubernetes in Windows Server

servizio Azure Kubernetes (AKS) in Azure Stack HCI e Windows Server è una piattaforma contenitore Kubernetes di livello aziendale basata su Azure Stack HCI. Include Kubernetes di base supportati da Microsoft, un host contenitore Windows progettato e un host contenitore Linux supportato da Microsoft, con un obiettivo per avere un'esperienza di gestione semplice del ciclo di vita e distribuzione.

Questo articolo introduce i componenti principali dell'infrastruttura Kubernetes, ad esempio il piano di controllo, i nodi e i pool di nodi. Sono presentate anche risorse del carico di lavoro come pod, distribuzioni e set, nonché la procedura per raggruppare risorse in spazi dei nomi.

Architettura del cluster Kubernetes

Kubernetes è il componente principale del servizio Azure Kubernetes abilitato da Azure Arc. Il servizio Azure Kubernetes usa un set di configurazioni predefinite per distribuire in modo efficace i cluster Kubernetes e con scalabilità.

L'operazione di distribuzione crea più macchine virtuali Linux o Windows e li aggiunge insieme per creare cluster Kubernetes.

Nota

Per migliorare l'affidabilità del sistema, se si eseguono più volumi condivisi cluster nel cluster, per impostazione predefinita i dati delle macchine virtuali vengono distribuiti automaticamente in tutte le macchine virtuali disponibili nel cluster. Ciò garantisce che le applicazioni siano sopravvissute in caso di interruzioni CSV. Questo vale solo per le nuove installazioni (non gli aggiornamenti).

Il sistema distribuito è pronto per ricevere carichi di lavoro Kubernetes standard, ridimensionare questi carichi di lavoro o anche ridimensionare il numero di macchine virtuali e il numero di cluster su e giù in base alle esigenze.

Un cluster servizio Azure Kubernetes include i componenti seguenti:

Il cluster di gestione (noto anche come host del servizio Azure Kubernetes) fornisce il meccanismo di orchestrazione principale e l'interfaccia per la distribuzione e la gestione di uno o più cluster di carico di lavoro.
I cluster del carico di lavoro (noti anche come cluster di destinazione) sono dove vengono distribuite applicazioni in contenitori.

Gestire il servizio Azure Kubernetes abilitato da Arc

È possibile gestire il servizio Azure Kubernetes usando le opzioni di gestione seguenti:

Windows Admin Center offre un'interfaccia utente intuitiva per l'operatore Kubernetes per gestire il ciclo di vita dei cluster.
Un modulo di PowerShell semplifica il download, la configurazione e la distribuzione del servizio Azure Kubernetes. Il modulo di PowerShell supporta anche la distribuzione e la configurazione di altri cluster di carico di lavoro e la riconfigurazione di quelli esistenti.

Cluster di gestione

Quando si crea un cluster Kubernetes, viene creato e configurato automaticamente un cluster di gestione. Questo cluster di gestione è responsabile del provisioning e della gestione dei cluster del carico di lavoro in cui vengono eseguiti i carichi di lavoro. Un cluster di gestione include i componenti principali di Kubernetes seguenti:

Server API: il server API è il modo in cui vengono esposte le API Kubernetes sottostanti. Questo componente fornisce l'interazione per gli strumenti di gestione, ad esempio Windows Admin Center, moduli di PowerShell o kubectl.
Servizio di bilanciamento del carico: il servizio di bilanciamento del carico è una singola macchina virtuale Linux dedicata con una regola di bilanciamento del carico per il server API del cluster di gestione.

Cluster del carico di lavoro

Il cluster del carico di lavoro è una distribuzione a disponibilità elevata di Kubernetes usando macchine virtuali Linux per l'esecuzione di componenti del piano di controllo Kubernetes e nodi di lavoro Linux. Le macchine virtuali basate su Windows Server Core vengono usate per stabilire i nodi di lavoro di Windows. È possibile gestire uno o più cluster di carico di lavoro da un cluster di gestione.

Componenti del cluster del carico di lavoro

Il cluster del carico di lavoro include molti componenti, descritti nelle sezioni seguenti.

Piano di controllo

Server API: il server API consente l'interazione con l'API Kubernetes. Questo componente fornisce l'interazione per gli strumenti di gestione, ad esempio Windows Admin Center, moduli di PowerShell o kubectl.
Etcd: Etcd è un archivio chiave-valore distribuito che archivia i dati necessari per la gestione del ciclo di vita del cluster. Archivia lo stato del piano di controllo.

Bilanciamento del carico

Il servizio di bilanciamento del carico è una macchina virtuale che esegue Linux e HAProxy + KeepAlive per fornire servizi con carico bilanciato per i cluster di carico di lavoro distribuiti dal cluster di gestione. Per ogni cluster del carico di lavoro, il servizio Azure Kubernetes aggiunge almeno una macchina virtuale del servizio di bilanciamento del carico. Qualsiasi servizio Kubernetes di tipo LoadBalancer creato nel cluster del carico di lavoro crea una regola di bilanciamento del carico nella macchina virtuale.

Nodi di lavoro

Per eseguire le applicazioni e i servizi di supporto, è necessario un nodo Kubernetes. Un cluster del carico di lavoro del servizio Azure Kubernetes dispone di uno o più nodi di lavoro. I nodi di lavoro fungono da macchine virtuali che eseguono i componenti del nodo Kubernetes e ospitano i pod e i servizi che costituiscono il carico di lavoro dell'applicazione.

Sono disponibili componenti del carico di lavoro Kubernetes di base che possono essere distribuiti nei cluster del carico di lavoro del servizio Azure Kubernetes, ad esempio pod e distribuzioni.

Pod

Kubernetes usa pod per eseguire un'istanza dell'applicazione. Un pod rappresenta una singola istanza dell'applicazione. In genere, i pod hanno un mapping 1:1 con un contenitore, anche se sono presenti scenari avanzati in cui un pod può contenere più contenitori. I pod multi-contenitore vengono pianificati insieme nello stesso nodo e consentono ai contenitori di condividere le risorse correlate. Per altre informazioni, vedere Pod di Kubernetes e Ciclo di vita dei pod di Kubernetes.

Distribuzioni

Una distribuzione rappresenta uno o più pod identici, gestiti dal controller di distribuzione Kubernetes. Una distribuzione definisce il numero di repliche (pod) da creare e l'utilità di pianificazione Kubernetes garantisce che se i pod o i nodi riscontrano problemi, i pod aggiuntivi vengono pianificati in nodi integri. Per altre informazioni, vedere Distribuzioni di Kubernetes.

Oggetti StatefulSet e DaemonSet

Il controller di distribuzione usa l'utilità di pianificazione Kubernetes per eseguire un determinato numero di repliche in qualsiasi nodo disponibile con risorse disponibili. Questo approccio di uso delle distribuzioni potrebbe essere sufficiente per le applicazioni senza stato, ma non per le applicazioni che richiedono una convenzione di denominazione persistente o un'archiviazione. Per le applicazioni che richiedono l'esistenza di una replica in ogni nodo (o nodi selezionati) all'interno di un cluster, il controller di distribuzione non esamina il modo in cui le repliche vengono distribuite tra i nodi.

StatefulSets: un oggetto StatefulSet è simile a una distribuzione in cui vengono creati e gestiti uno o più pod identici. Le repliche in un oggetto StatefulSet seguono un approccio sequenziale di distribuzione, scalabilità, aggiornamenti e terminazioni. Con un oggetto StatefulSet (come le repliche vengono riprogrammate) la convenzione di denominazione, i nomi di rete e l'archiviazione persistenti. Le repliche in un oggetto StatefulSet vengono pianificate ed eseguite in qualsiasi nodo disponibile in un cluster Kubernetes. Se è necessario assicurarsi che almeno un pod nel set venga eseguito in un nodo, è invece possibile usare un DaemonSet. Per altre informazioni, vedere Oggetti StatefulSet di Kubernetes.
DaemonSets: per esigenze specifiche di raccolta di log o monitoraggio, potrebbe essere necessario eseguire un determinato pod in tutti i nodi o selezionati. Un DaemonSet viene nuovamente usato per distribuire uno o più pod identici, ma il controller DaemonSet garantisce che ogni nodo specificato esegue un'istanza del pod. Per altre informazioni, vedere Oggetti DaemonSet di Kubernetes.

Spazi dei nomi

Le risorse Kubernetes, ad esempio pod e distribuzioni, vengono raggruppate logicamente in uno spazio dei nomi. Questi raggruppamenti offrono un modo per dividere logicamente i cluster del carico di lavoro e limitare l'accesso a creare, visualizzare o gestire le risorse. Ad esempio, è possibile creare spazi dei nomi per separare gruppi aziendali. Gli utenti possono interagire solo con le risorse all'interno degli spazi dei nomi assegnati. Per altre informazioni, vedere Spazi dei nomi di Kubernetes.

Quando si crea un cluster servizio Azure Kubernetes nel servizio Azure Kubernetes abilitato da Arc, sono disponibili gli spazi dei nomi seguenti:

default: uno spazio dei nomi in cui vengono creati pod e distribuzioni per impostazione predefinita quando non viene fornito nessuno. Negli ambienti più piccoli è possibile distribuire le applicazioni direttamente nello spazio dei nomi predefinito senza creare altre suddivisioni logiche. Quando si interagisce con l'API di Kubernetes, ad esempio kubectl get pods, viene usato lo spazio dei nomi predefinito se non ne viene specificato un altro.
kube-system: uno spazio dei nomi in cui esistono risorse principali, ad esempio funzionalità di rete, ad esempio DNS e proxy, o il dashboard kubernetes. In genere non si distribuiscono le proprie applicazioni in questo spazio dei nomi.
kube-public: uno spazio dei nomi in genere non usato, ma può essere usato per le risorse da visualizzare nell'intero cluster e può essere visualizzato da qualsiasi utente.

Segreti

I segreti Kubernetes consentono di archiviare e gestire informazioni riservate, ad esempio password, token OAuth e chiavi SSH (Secure Shell). Per impostazione predefinita, Kubernetes archivia i segreti come stringhe con codifica base64 non crittografate e possono essere recuperate come testo normale da chiunque abbia accesso alle API. Per altre informazioni, vedere Segreti kubernetes.

Volumi permanenti

Un volume persistente è una risorsa di archiviazione in un cluster Kubernetes che è stato effettuato il provisioning dall'amministratore o sottoposto a provisioning dinamico usando le classi di archiviazione. Per usare volumi persistenti, i pod richiedono l'accesso usando un PersistentVolumeClaim. Per altre informazioni, vedere Volumi persistenti.

Distribuzioni di sistemi operativi misti

Se un determinato cluster del carico di lavoro è costituito da nodi di lavoro Linux e Windows, deve essere pianificato in un sistema operativo che può supportare il provisioning del carico di lavoro. Kubernetes offre due meccanismi per garantire che i carichi di lavoro vengano terreni nei nodi con un sistema operativo di destinazione:

Il selettore di nodi è un campo semplice nella specifica del pod che limita i pod a essere pianificato solo in nodi integri corrispondenti al sistema operativo.
I contenitori e le tolleranze interagiscono per garantire che i pod non siano pianificati in modo involontario nei nodi. Un nodo può essere "tainted" in modo che non accetti pod che non tollerano esplicitamente il suo taint tramite una "tollerazione" nella specifica del pod.

Per altre informazioni, vedere Selettori di nodo e taints e tolleranze.

Passaggi successivi

In questo articolo è stata illustrata l'architettura del cluster del servizio Azure Kubernetes abilitata da Azure Arc e i componenti del cluster del carico di lavoro. Per altre informazioni su questi concetti, vedere gli articoli seguenti: