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

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

servizio Azure Kubernetes (servizio Azure Kubernetes) in Locale di Azure e Windows Server è una piattaforma di contenitori Kubernetes di livello aziendale con tecnologia locale di Azure. Include Kubernetes di base supportati da Microsoft, un host contenitore Windows appositamente compilato e un host contenitore Linux supportato da Microsoft, con l'obiettivo di avere una semplice esperienza di distribuzione e gestione del ciclo di vita.

Questo articolo presenta 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 tenendo presente la scalabilità.

L'operazione di distribuzione crea più macchine virtuali Linux o Windows e le unisce per creare cluster Kubernetes.

Il sistema distribuito è pronto per ricevere carichi di lavoro Kubernetes standard, ridimensionare questi carichi di lavoro o persino ridimensionare il numero di macchine virtuali e il numero di cluster 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 del carico di lavoro.
• I cluster del carico di lavoro (noti anche come cluster di destinazione) sono la posizione in cui vengono distribuite le 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 PowerShell supporta anche la distribuzione e la configurazione di altri cluster del 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.
• 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 nodi di lavoro Windows. Uno o più cluster del carico di lavoro possono essere gestiti 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 del 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 infine una regola di bilanciamento del carico nella macchina virtuale.

Nodi del ruolo 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 ha uno o più nodi di lavoro. I nodi di lavoro fungono da macchine virtuali (VM) che eseguono i componenti del nodo Kubernetes e ospitano i pod e i servizi che costituiscono il carico di lavoro dell'applicazione.

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

Pod

Kubernetes usa i 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 esistono 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.

Deployments

Una distribuzione rappresenta uno o più pod identici gestiti dal controller di distribuzione di 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 le distribuzioni 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 utilizzo delle distribuzioni potrebbe essere sufficiente per le applicazioni senza stato, ma non per le applicazioni che richiedono una convenzione di denominazione permanente 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 uno o più pod identici vengono creati e gestiti. Le repliche in un oggetto StatefulSet seguono un approccio normale e sequenziale alla distribuzione, alla scalabilità, agli aggiornamenti e alle terminazioni. Con un oggetto StatefulSet (poiché le repliche vengono riprogrammate) la convenzione di denominazione, i nomi di rete e l'archiviazione vengono mantenuti. 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 oggetto DaemonSet. Per altre informazioni, vedere Oggetti StatefulSet di Kubernetes.
• DaemonSets: per specifiche esigenze di raccolta o monitoraggio dei log, potrebbe essere necessario eseguire un determinato pod in tutti i nodi o selezionati. Un DaemonSet viene usato di nuovo per distribuire uno o più pod identici, ma il controller DaemonSet garantisce che ogni nodo specificato esegua un'istanza del pod. Per altre informazioni, vedere Oggetti DaemonSet di Kubernetes.

Namespaces (Spazi dei nomi)

Le risorse Kubernetes, ad esempio pod e distribuzioni, vengono raggruppate logicamente in uno spazio dei nomi. Questi raggruppamenti consentono di dividere logicamente i cluster del carico di lavoro e limitare l'accesso per 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: spazio dei nomi in cui i pod e le distribuzioni vengono creati per impostazione predefinita quando non viene specificato 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 sono presenti le 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 rendere visibili le risorse 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 all'API. Per altre informazioni, vedere Segreti Kubernetes.

Volumi permanenti

Un volume permanente è una risorsa di archiviazione in un cluster Kubernetes di cui è 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 tramite 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 in grado di 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 nodo è un campo semplice nella specifica del pod che vincola i pod solo ai 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 tolerations.

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:

• Sicurezza
• Rete di contenitori
• Storage