Panoramica del sandboxing dei pod in Servizio Azure Kubernetes (AKS)

Man mano che i cluster AKS si espandono e ospitano carichi di lavoro di più team o tenant diversi, l'infrastruttura condivisa può rendere più complesso l'isolamento. Potrebbe essere necessario un maggiore isolamento per evitare che carichi di lavoro ad alto consumo di risorse o con picchi improvvisi compromettano carichi di lavoro prevedibili. Potrebbe anche essere necessario isolare i carichi di lavoro sensibili per soddisfare i requisiti di sicurezza.

Per soddisfare questi requisiti, è possibile isolare i carichi di lavoro tramite strategie di isolamento logico o fisico. Per l'isolamento logico, usare gli spazi dei nomi Kubernetes per separare risorse e distribuzioni. I namespace condividono l'infrastruttura cluster sottostante, quindi non forniscono lo stesso livello di isolamento fisico dei cluster separati. Sebbene i cluster separati forniscano un limite fisico, questa strategia può aumentare i costi quando i cluster non usano la capacità completa.

La sandbox del pod nel servizio Azure Kubernetes introduce la possibilità di eseguire i carichi di lavoro in macchine virtuali pod (VM) separate. Ogni macchina virtuale pod fornisce un limite di isolamento del calcolo: il carico di lavoro viene eseguito con il proprio kernel guest ed è isolato dal kernel host e dai carichi di lavoro in altre macchine virtuali pod.

Il sandboxing dei pod è basato sul progetto Kata Containers open source.

Architettura e componenti

Il sandbox del pod usa il runtime Kata Containers per creare una macchina virtuale pod leggera per ogni pod in modalità sandbox. Il diagramma seguente mostra come i componenti lato host creano e gestiscono la macchina virtuale pod isolata e come i componenti lato guest eseguono il carico di lavoro.

• Nel manifesto del pod, impostare runtimeClassName: kata-vm-isolation per selezionare il runtime Kata Containers.
• Containerd richiama lo shim Kata (containerd-shim-kata-v2) anziché lo shim di runtime standard.
• Lo shim di Kata avvia il monitor di macchina virtuale (VMM) Cloud Hypervisor, che crea una VM pod con un kernel guest separato e l'agente Kata.
• L'agente Kata crea e gestisce i contenitori e i processi del carico di lavoro all'interno della macchina virtuale pod.
• Quando la VM del pod viene eliminata, lo shim Kata arresta la VM del pod e restituisce le relative risorse all'host del container.

Vantaggi e casi d'uso

Il sandboxing dei pod isola ogni pod sottoposto a sandboxing in una VM pod leggera con il proprio kernel guest. Questo limite di calcolo separa il carico di lavoro dal kernel host e dai carichi di lavoro in altre macchine virtuali pod. Combina l'isolamento dei pod con controlli quali le policy di rete e Criteri di Azure per attenuare i rischi di rete e di governance che il confine della VM del pod non copre. Per indicazioni sulla selezione dei controlli per le distribuzioni multi-tenant, vedere Linee guida di AKS per soluzioni multi-tenant.

Casi d'uso comuni

Il sandboxing dei pod consente di:

• Ospitare carichi di lavoro di tenant diversi nello stesso cluster AKS, garantendo al contempo un confine di isolamento del calcolo separato per ogni pod con sandbox.
• Isolare i carichi di lavoro non attendibili dal kernel host e dai carichi di lavoro in altre macchine virtuali pod, continuando a usare la capacità del cluster condiviso.
• Proteggere carichi di lavoro sensibili o di alto valore dai carichi di lavoro in esecuzione in altre macchine virtuali pod.
• Ridurre l'effetto di carichi di lavoro a elevato consumo di risorse o con picchi sugli altri pod isolati in modalità sandbox applicando richieste e limiti di CPU e memoria a ogni VM del pod.
• Limitare il raggio di azione del calcolo di un errore del carico di lavoro alla macchina virtuale pod.

Isolamento dei carichi di lavoro

Il sandboxing dei pod consente di raggruppare i carichi di lavoro nei nodi del cluster condiviso mantenendo al tempo stesso un limite di isolamento di calcolo separato per ogni pod in modalità sandbox.

È possibile dichiarare richieste di risorse e limiti per i carichi di lavoro. AKS applica i valori predefiniti quando li ometti. La macchina virtuale pod limita un carico di lavoro a elevato utilizzo di risorse alla CPU e alla memoria allocata a tale macchina virtuale. Se un carico di lavoro causa un errore della macchina virtuale pod, il limite di isolamento del calcolo protegge i carichi di lavoro in altre macchine virtuali pod da tale errore.

Flessibilità

È possibile eseguire pod in modalità sandbox e standard nello stesso cluster. Questa flessibilità consente di applicare l'isolamento della macchina virtuale pod solo ai carichi di lavoro che lo richiedono.

Componenti open source

Il sandboxing dei pod usa componenti open source, tra cui il VMM Cloud Hypervisor e il runtime Kata Containers. Lo sviluppo aperto offre trasparenza nei componenti di isolamento e consente la revisione della community. L'architettura separa inoltre il kernel guest in ogni VM pod dal kernel host Azure Linux.

Eseguire la migrazione di carichi di lavoro esistenti

Per una distribuzione di base, aggiungere la classe di runtime Kata a una specifica di pod esistente per eseguire il carico di lavoro in una macchina virtuale pod. Questa modifica al manifesto non garantisce un comportamento identico a un pod che usa il runtime standard runc . Prima della migrazione, convalidare il comportamento operativo del carico di lavoro e la compatibilità delle funzionalità kubernetes e tenere conto del dimensionamento e del sovraccarico delle risorse della macchina virtuale pod. Per altre informazioni, vedere Considerazioni per il sandboxing dei pod.

Passaggi successivi

• Consulta le considerazioni sull'isolamento dei pod prima della distribuzione.
• Distribuire la sandbox del pod nel servizio Azure Kubernetes.