Orchestratori di contenitori in distribuzioni Azure Locale in formato compatto (anteprima)

Questo articolo descrive in che modo gli orchestratori di contenitori forniscono un livello di isolamento delle applicazioni per le distribuzioni Azure Locale in formato ridotto. Illustra le due opzioni principali, K3s e Docker, e spiega quando usarle.

Perché usare i container su dispositivi di piccolo formato?

Le distribuzioni compatte di Azure Locale sono progettate per sedi periferiche in cui l’ingombro fisico, il consumo energetico e i costi sono limitati. I carichi di lavoro tradizionali basati su macchine virtuali (VM) possono richiedere troppe risorse per le configurazioni hardware supportate dai dispositivi compatti.

I contenitori offrono un'alternativa leggera per l'esecuzione di carichi di lavoro applicativi su dispositivi di formato ridotto:

• Sovraccarico inferiore: i contenitori condividono il kernel del sistema operativo host e utilizzano una quantità significativa di memoria e CPU rispetto alle macchine virtuali, migliorando l'uso delle risorse limitate su hardware a fattore di forma ridotto.
• Avvio rapido: i carichi di lavoro dei contenitori iniziano in pochi secondi anziché in minuti, che è fondamentale per gli scenari perimetrali in cui il ripristino rapido è importante.
• Creazione di pacchetti coerenti: le immagini del contenitore forniscono un'unità di distribuzione riproducibile che funziona allo stesso modo indipendentemente dal modello hardware a fattore di forma ridotto sottostante.
• Isolamento: i contenitori isolano i processi dell'applicazione, le dipendenze e la rete tra loro e dal sistema operativo host, impedendo conflitti tra carichi di lavoro.

I contenitori sui dispositivi di piccolo formato fungono da livello di isolamento delle applicazioni posto sopra il sistema operativo Azure Locale. Il sistema operativo host, gestito tramite la risorsa macchina di cui è stato effettuato il provisioning, si occupa della gestione dell'hardware e della connettività ad Azure, mentre l'orchestratore di container gestisce il ciclo di vita dell'applicazione al di sopra di esso.

K3s

K3s è una distribuzione Kubernetes leggera e certificata DALLF creata per ambienti con vincoli di risorse. È una soluzione ideale per i dispositivi a fattore di forma di piccole dimensioni perché offre l'API Kubernetes completa con una frazione del footprint delle risorse delle distribuzioni Kubernetes standard.

Perché usare K3s su dispositivi compatti

• Ingombro ridotto: K3s viene distribuito come un unico file binario di meno di 100 MB e richiede circa 512 MB di RAM per l’esecuzione, il che lo rende adatto a hardware compatto a bassa capacità con memoria compresa tra 32 e 128 GB.
• Runtime containerd incluso: K3s include containerd come runtime per i container, quindi non è necessario installare un runtime per container separato sull'host.
• Compatibile con Kubernetes: K3s supera i test di conformità kubernetes completi, ovvero manifesti Kubernetes standard, grafici Helm e strumenti funzionano senza modifiche.
• Componenti predefiniti: K3s include un provider di archiviazione locale, CoreDNS e un servizio di bilanciamento del carico predefinito, riducendo il numero di componenti che è necessario installare e gestire separatamente.

Integrazione di Azure Arc

È possibile connettere i cluster K3s in esecuzione su dispositivi compatti a Kubernetes abilitato per Azure Arc, portando la gestione basata sul cloud al cluster perimetrale. Usando l'integrazione di Arc, è possibile:

• Visualizza e monitora il cluster nel portale di Azure insieme ad altre risorse di Azure.
• Apply Criteri di Azure per applicare gli standard di configurazione nei cluster Kubernetes perimetrali.
• Distribuisci i carichi di lavoro tramite GitOps (Flux) per la distribuzione automatizzata delle applicazioni gestita tramite controllo del codice sorgente.
• Abilita Azure RBAC in modo che le identità di Microsoft Entra ID e le assegnazioni di ruolo controllino l'accesso all'API Kubernetes, eliminando la necessità di gestire credenziali kubeconfig distinte.

Per connettere un cluster K3s a Azure Arc, usare il comando az connectedk8s connect. Poiché i dispositivi di formato ridotto in genere non hanno interfaccia della riga di comando di Azure installata sull'host, è possibile eseguire interfaccia della riga di comando di Azure dall'interno di un contenitore utilizzando il runtime containerd incluso in K3s. Questo approccio evita l'installazione di software aggiuntivo nel sistema operativo host. Per uno script in grado di installare in remoto K3s, avviare il cluster e abilitare Arc per il cluster, vedere lo script setup-k3s-arc.sh.

Quando usare K3s

Usare K3s quando i carichi di lavoro traggono vantaggio dalle funzionalità native di Kubernetes:

• Si vuole distribuire Operazioni di Azure IoT o Azure Foundry Local.
• È necessario eseguire più servizi interdipendenti con l'individuazione dei servizi e il bilanciamento del carico.
• Vuoi distribuzioni dichiarative con autoripristino e aggiornamenti progressivi.
• Si prevede di usare grafici Helm o operatori Kubernetes dall'ecosistema.
• È necessaria l'integrazione di Kubernetes abilitato per Azure Arc per la gestione centralizzata.
• Si vuole usare GitOps per la distribuzione automatizzata del carico di lavoro in una flotta di dispositivi perimetrali.

AKS

Servizio Azure Kubernetes (AKS) è un servizio Kubernetes completamente gestito che viene eseguito direttamente in dispositivi a fattore di forma di piccole dimensioni senza hypervisor. A differenza di K3s, che richiede di installare e gestire manualmente il cluster, si distribuisce e si gestisce il servizio Azure Kubernetes interamente da Azure, tra cui la creazione del cluster, gli aggiornamenti delle versioni di Kubernetes e il monitoraggio.

Perché usare AKS su dispositivi in formato ridotto

• Ciclo di vita completamente gestito: Gestisci la creazione, gli aggiornamenti e l'eliminazione del cluster tramite il portale di Azure, i modelli Bicep o i modelli ARM.
• Nessun hypervisor: AKS viene eseguito direttamente sul sistema operativo host bare metal, quindi si evita il sovraccarico di risorse di un livello di virtualizzazione sui dispositivi con memoria e CPU limitate.
• Integrazione predefinita di Azure Arc: il cluster è abilitato per Azure Arc fin dal momento della creazione. Non c'è un passaggio separato az connectedk8s connect . La visibilità nel portale di Azure, il controllo degli accessi in base al ruolo di Azure, Monitoraggio di Azure e Criteri di Azure sono disponibili immediatamente.
• Compatibile con Kubernetes: AKS esegue Kubernetes standard con Cilium CNI, quindi i file manifest Kubernetes esistenti, le chart Helm e i tool funzionano senza modifiche.
• Resilienza alla perdita di connettività: poiché il piano di controllo Kubernetes viene eseguito localmente nel dispositivo, i carichi di lavoro distribuiti continuano a funzionare normalmente durante la perdita di connettività. Solo la visibilità del portale e le azioni di gestione Azure vengono interrotte fino al ripristino della connessione.

Quando usare AKS

Usa AKS quando vuoi che Azure gestisca il ciclo di vita di Kubernetes sui tuoi dispositivi compatti:

• Si vogliono creare, aggiornare ed eliminare cluster dal portale di Azure senza accedere al dispositivo.
• È necessario il controllo degli accessi in base ai ruoli di Azure (Azure RBAC), con identità di Microsoft Entra ID che controllano l'accesso al cluster fin dal primo giorno.
• Stai gestendo una flotta di dispositivi edge e vuoi un'esperienza coerente con AKS tra cloud ed edge.
• Si vogliono Monitoraggio di Azure e Criteri di Azure predefiniti senza altre impostazioni.
• Si preferisce una piattaforma completamente gestita rispetto alla propria distribuzione kubernetes.

Docker

Docker offre un runtime di contenitori più semplice per l'esecuzione di singoli contenitori o piccoli gruppi di contenitori in un dispositivo a fattore di forma ridotto. Rispetto a K3s, Docker ha meno sovraccarico operativo, ma anche meno funzionalità di orchestrazione.

Perché Docker sui dispositivi compatti

• Semplicità: Docker usa un modello semplice docker run che non richiede conoscenze sui concetti di Kubernetes, ad esempio pod, distribuzioni o servizi.
• Minore complessità operativa: non esiste alcuno stato del cluster da gestire, nessun database etcd e nessun componente del piano di controllo. Docker esegue i contenitori direttamente nell'host.
• Strumenti familiari: Docker è ampiamente adottato e la maggior parte dei team di sviluppo ha già esperienza nella creazione e nell'esecuzione di contenitori Docker.
• Compose per app multi-contenitore: Docker Compose consente di definire ed eseguire applicazioni multi-contenitore usando un singolo file YAML, sufficiente per molti carichi di lavoro perimetrali.

Limitazioni rispetto a K3s

Docker autonomamente non fornisce:

• Riavvio automatico e ripianificazione: se un contenitore si arresta in modo anomalo, Docker può riavviarlo (tramite i criteri --restart), ma non ripianifica i carichi di lavoro né esegue il failover basato sullo stato di integrità.
• Individuazione dei servizi e bilanciamento del carico: i contenitori possono comunicare tramite reti Docker, ma non esiste un'individuazione dei servizi basata su DNS predefinita o il bilanciamento del carico automatico tra le repliche.
• Gestione dichiarativa dello stato desiderato: Docker Compose fornisce una configurazione dichiarativa di base, ma non riconcilia continuamente lo stato effettivo rispetto allo stato desiderato nel modo in cui Kubernetes esegue.
• Integrazione di Kubernetes abilitato per Azure Arc: i contenitori Docker non possono essere gestiti tramite Kubernetes abilitato per Azure Arc. La gestione centralizzata della flotta richiede strumenti aggiuntivi.

Quando usare Docker

Usare Docker quando i carichi di lavoro sono semplici e non richiedono l'orchestrazione di Kubernetes:

• Stai eseguendo una singola applicazione o un piccolo numero di container indipendenti.
• Vuoi il modo più rapido per eseguire un carico di lavoro containerizzato sul dispositivo.
• Il team ha familiarità con Docker ma non con Kubernetes.
• Non è necessaria la gestione centralizzata della flotta tramite Kubernetes abilitato per Azure Arc.

Scegliere tra AKS, K3s e Docker

La tabella seguente riepiloga le principali differenze per aiutarti a scegliere l'orchestratore di container più adatto per la tua distribuzione su dispositivi compatti:

I dispositivi a fattore di forma ridotto devono eseguire un solo orchestratore di container

Un dispositivo di piccole dimensioni deve eseguire AKS, K3s o Docker, non più di uno. Prendere questa decisione all'inizio della pianificazione della distribuzione, prima di iniziare a distribuire i carichi di lavoro in contenitori. Distribuisci tutte le tue applicazioni utilizzando l'orchestratore scelto.

Perché non entrambi?

Anche se tecnicamente è possibile installare sia il servizio Azure Kubernetes che K3s e Docker nello stesso dispositivo, in questo modo si creano problemi che si complicano nel tempo:

• Contesa di risorse: i dispositivi a fattore di forma di piccole dimensioni operano entro vincoli di risorse limitati (fino a 14 core fisici e 32 GB di RAM). Ogni agente di orchestrazione del contenitore riserva memoria e CPU per i propri componenti di runtime. Eseguirli entrambi significa pagare due volte il costo dell’overhead — i componenti del control plane di AKS o K3s (server API, scheduler, controller manager, etcd) insieme al daemon di Docker — lasciando meno capacità per i carichi di lavoro effettivi delle applicazioni.

• Conflitti di porte: entrambi gli agenti di orchestrazione gestiscono la rete dei contenitori e l'allocazione delle porte in modo indipendente. Quando due sistemi separati eseguono il mapping delle porte del contenitore all'host, le associazioni di porte in conflitto diventano probabili, soprattutto nei dispositivi con una singola interfaccia di rete. Capire quale orchestratore utilizza quale porta aggiunge un'inutile complessità operativa.

• Runtime dei container in conflitto: AKS o K3s include il proprio runtime containerd, mentre Docker esegue la propria istanza di containerd (o, nelle versioni precedenti, il proprio runtime). Due runtime di contenitori nello stesso host possono interferire tra loro con l'archiviazione, la rete e la gestione dei processi. Le immagini container scaricate da un runtime non sono visibili all’altro, con conseguente duplicazione dell’archiviazione delle immagini su un dispositivo con spazio di archiviazione già limitato.

• Modello operativo diviso: l'esecuzione di entrambi gli agenti di orchestrazione significa che il team deve mantenere due diversi set di procedure di distribuzione, approcci di monitoraggio e procedure di risoluzione dei problemi per lo stesso dispositivo. I contenitori gestiti dal servizio Azure Kubernetes o K3s sono visibili tramite kubectl e Azure Arc. I contenitori gestiti da Docker sono visibili tramite docker ps. Non esiste una visualizzazione unificata in entrambi i casi, rendendo difficile comprendere l'immagine completa del carico di lavoro in un dispositivo.

• Comportamento di aggiornamento imprevedibile: gli aggiornamenti a livello di sistema operativo applicati tramite il ciclo di vita del computer sottoposto a provisioning potrebbero interagire in modo diverso con ogni runtime del contenitore. La presenza di un singolo agente di orchestrazione semplifica la matrice di aggiornamento e riduce il rischio di interruzione di un runtime dopo una modifica del sistema operativo host.

Prendere la decisione in anticipo

Cambiare gli orchestratori di container dopo aver distribuito i carichi di lavoro è un'operazione destabilizzante. In genere richiede:

1. Ricomprimere le configurazioni di distribuzione dell'applicazione (conversione tra file Docker Compose e manifesti Kubernetes o viceversa).
2. Migrazione di dati persistenti da volumi gestiti da un runtime all'altro.
3. Aggiornamento di eventuali pipeline CI/CD, integrazioni di monitoraggio e runbook operativi.
4. Coordinare un periodo di inattività per la migrazione, che potrebbe non essere accettabile nei siti edge sempre attivi.

Per questi motivi, scegli il tuo orchestratore di container prima di distribuire il tuo primo carico di lavoro. Valuta i tuoi requisiti in base alla tabella di confronto, considerando non solo le tue esigenze attuali, ma anche verso dove si sta evolvendo la tua distribuzione edge. Se è possibile che in futuro sia necessaria la gestione di Kubernetes abilitata per Azure Arc o GitOps a livello di flotta, a partire da K3s evita una migrazione costosa in un secondo momento.

Un agente di orchestrazione per flotta, non solo per dispositivo

Se distribuisci dispositivi compatti in più siti, standardizza sullo stesso orchestratore di container in tutta la flotta. L'uso di un ambiente misto in cui alcuni dispositivi eseguono K3s e altri eseguono Docker aumenta il sovraccarico operativo.

• Gli strumenti di distribuzione devono supportare entrambi gli orchestratori.
• I playbook di risoluzione dei problemi variano a seconda del tipo di dispositivo.
• Il monitoraggio a livello di flotta richiede integrazioni separate per i dispositivi basati su Kubernetes e basati su Docker.
• I requisiti di formazione e personale aumentano, in quanto gli operatori necessitano di competenze in entrambi i sistemi.

La standardizzazione su un singolo agente di orchestrazione mantiene la flotta in modo operativo uniforme e consente di investire in un unico set di strumenti, training e automazione.

Passare da un dispositivo a un runtime del contenitore diverso

Il passaggio a un nuovo runtime di contenitori è semplice. Con az provisionedmachine resetè possibile reimpostare il computer, installare una nuova immagine del sistema operativo e considerarla come nuova.

Considerazioni sulla rete

Indipendentemente dall'orchestratore di container scelto, considerate i seguenti aspetti di rete per le distribuzioni con fattore di forma ridotto:

• Rete host: per i carichi di lavoro che devono essere associati direttamente alle interfacce di rete del dispositivo (ad esempio, protocolli di individuazione di rete), sia K3s che Docker supportano la modalità di rete host.
• Ingress: K3s include un bilanciatore del carico dei servizi integrato. Per Docker, si espongono le porte del contenitore direttamente all'host usando il mapping delle porte (-p flag).
• Firewall e proxy: i dispositivi compatti nelle sedi periferiche possono trovarsi dietro firewall restrittivi. Assicurarsi che gli endpoint necessari per il registro contenitori e (se applicabile) Azure Arc siano accessibili.

Considerazioni relative alla sicurezza

L'esecuzione di container su dispositivi di piccole dimensioni introduce un modello di sicurezza basato su un kernel condiviso. Tenere presente quanto segue:

• Provenienza dell'immagine: eseguire il pull delle immagini del contenitore solo da registri attendibili. Usare la firma delle immagini e l'analisi delle vulnerabilità, se possibile.
• Privilegio minimo: Evita di eseguire i contenitori come root, a meno che non sia necessario. Sia K3s che Docker supportano l'esecuzione di container con privilegi ridotti.

Passaggi successivi

• Eseguire carichi di lavoro in contenitori in un computer di cui è stato effettuato il provisioning
• Distribuire le applicazioni