Considerazioni sulla sandbox dei pod su Servizio Azure Kubernetes (AKS)

L’isolamento in sandbox dei pod in Servizio Azure Kubernetes (AKS) comporta considerazioni relative alla gestione delle risorse, della memoria e della CPU, nonché alla sicurezza.

Gestione delle risorse nel sandboxing dei Pod

Esaminare queste considerazioni quando si specificano le risorse per una distribuzione, in particolare per carichi di lavoro di grandi dimensioni o sensibili alle risorse.

Componenti Kata

Una distribuzione Kata comprende componenti che vengono eseguiti sul nodo AKS e componenti che vengono eseguiti all'interno della macchina virtuale (VM) del pod. Questa suddivisione host e guest determina la modalità di utilizzo della memoria e della CPU.

Gestione della memoria nel sandboxing dei pod

Impostare il limite di memoria della macchina virtuale pod sufficientemente elevato per supportare il carico di lavoro e i componenti guest Kata senza allocare memoria inutilizzata.

Dimensioni della memoria VM del pod

Ogni VM pod dispone di memoria per il carico di lavoro e per tutti i componenti guest di Kata. Includere memoria oltre il consumo previsto del carico di lavoro per i componenti guest, ad esempio l'agente Kata e il kernel della macchina virtuale. Vedere i valori di utilizzo di riferimento per i valori di memoria tipici.

Il limite di memoria del pod Kubernetes determina la dimensione della memoria VM del pod. Modificare il limite di memoria del pod per modificare le dimensioni della memoria della macchina virtuale del pod.

RuntimeClass il sovraccarico di memoria aumenta in genere con le dimensioni della memoria della macchina virtuale del pod.

RuntimeClass sovraccarico di memoria

I carichi di lavoro di sandboxing dei pod includono un kata RuntimeClass predefinito (kata-vm-isolation) che include valori di overhead delle risorse predefiniti. Per un controllo più granulare delle quote delle risorse, configura una configurazione personalizzata RuntimeClass con overhead specifici delle risorse. Il limite di memoria del pod consente di ridimensionare la memoria lato guest disponibile per la macchina virtuale pod. RuntimeClass l'overhead riserva la capacità del nodo per i componenti Kata sul lato host e non deve tenere conto del consumo di memoria previsto dei componenti guest.

È possibile creare un runtime specializzato e specificare il sovraccarico di memoria tramite il overhead campo nel RuntimeClass manifesto. Ad esempio, il manifesto seguente crea un runtime per i carichi di lavoro con un consumo di risorse inferiore:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: small-kata-pods
handler: kata
overhead:
  podFixed:
    memory: "120Mi"

Il valore memory: "120Mi" aggiunge 120Mi di overhead fisso del pod quando Kubernetes pianifica il pod e ne dimensiona il cgroup. Il valore handler: kata deve corrispondere al gestore del runtime Kata configurato nei nodi di AKS.

Prima di usare un elemento personalizzato RuntimeClass, esegui kubectl get runtimeclass e verifica che il gestore associato sia supportato nel tuo cluster AKS.

Non è necessario specificare il sovraccarico, ma è consigliabile controllare le risorse riservate per i carichi di lavoro. Se si utilizza il valore predefinito kata-vm-isolationRuntimeClass e non si specifica un limite di memoria per il pod, la dimensione della VM del pod è impostata per impostazione predefinita su 512Mi. La configurazione predefinita RuntimeClass aggiunge circa 88Mi di sovraccarico di memoria per i componenti host, il che comporta un limite del pod di 600Mi cgroup.

Carichi di lavoro utente

Il carico di lavoro Kata può utilizzare la dimensione della memoria della VM del pod configurata, al netto della memoria consumata dai componenti della VM guest, come l'agente Kata e il kernel della VM guest.

Per stimare la memoria, usare i componenti seguenti:

1. Connettersi alla macchina virtuale pod (tramite kubectl exec o kubectl debug per aprire una shell all'interno del pod).
2. Eseguire il comando free.
3. Esaminare la colonna usata per stimare la memoria utilizzata dal kernel guest e dall'agente Kata.

Cgroups di memoria

Quando Kubernetes pianifica un pod Kata, kubelet assegna il pod a una memoria cgroup. cgroup applica le richieste di memoria e i limiti del pod in modo da poter definire le risorse disponibili per il pod.

La memoria cgroup ha due campi importanti:

In qualsiasi momento, se il memory.current valore supera quello di memory.max, il kernel potrebbe attivare un OOMKill nel pod se viene rilevata una pressione di memoria.

Valori di utilizzo di riferimento

Usare i valori seguenti come esempi di utilizzo tipico della memoria. Le dimensioni della memoria della VM pod inferiori a 128 MiB non sono supportate.

Come leggere questa tabella: memory.current include l'allocazione di memoria della macchina virtuale pod e l'utilizzo corrente dei componenti host. Il kubelet calcola memory.max a partire dal limite di memoria del pod più l'overhead RuntimeClass. La differenza tra questi valori indica la capacità disponibile per l'utilizzo aggiuntivo dei componenti host.

Procedure consigliate per la gestione della memoria

• Specificare le dimensioni di memoria della macchina virtuale del pod impostando limits.memory nei manifesti e definire quote di risorse appropriate per tutte le distribuzioni.
  • Usare una richiesta di memoria del pod diversa da zero per riservare la capacità del nodo per la VM del pod prima dell'avvio della VM. La richiesta deve tenere conto della macchina virtuale pod e dei contenitori in esecuzione.
  • Usare un sovraccarico RuntimeClass di memoria diverso da zero per tenere conto della capacità del nodo utilizzata dai componenti host Kata.
• Per i carichi di lavoro a elevato utilizzo di risorse, impostare un limite di memoria pod che fornisca memoria sufficiente per il carico di lavoro e i componenti guest.
• Impostare RuntimeClass un sovraccarico di memoria sufficientemente elevato per i componenti host Kata senza riservare una capacità di nodo notevolmente superiore a quella necessaria.

Gestione della CPU nel sandboxing dei pod

Allocare le risorse CPU ai carichi di lavoro Kata impostando i limiti CPU dei pod e l'overhead RuntimeClass. Senza un limite di CPU, i componenti host Kata possono usare qualsiasi capacità della CPU disponibile nel nodo.

Prenotazione della CPU

Impostare uno o entrambi i campi seguenti per riservare la capacità della CPU per i carichi di lavoro Kata:

• Sovraccarico della RuntimeClass CPU
• Limite della CPU del pod

Quando si specifica almeno uno dei due valori, il piano di controllo riserva il numero specificato di CPU nel nodo per il carico di lavoro. Altri pod nello stesso nodo non possono accedere a questa capacità riservata.

Limite CPU del pod

Dichiarare il limite di CPU del pod nel manifesto dell'applicazione. Il limite controlla il numero di CPU che possono essere usate dai contenitori nella macchina virtuale pod associata.

Se non viene dichiarato un limite di CPU del pod, AKS alloca una vCPU alla VM del pod quando il nodo ha capacità sufficiente. I componenti host Kata non hanno limiti di utilizzo della CPU.

RuntimeClass Sovraccarico della CPU

Specificare il sovraccarico per riservare la RuntimeClass capacità del nodo per i componenti host Kata prima di distribuire un carico di lavoro.

È possibile specificare l'overhead della CPU tramite il overhead campo nel RuntimeClass manifesto. Ad esempio:

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: custom-kata-runtime
handler: kata
overhead:
  podFixed:
    cpu: "250m"

Il valore cpu: "250m" aggiunge 0,25 vCPU di overhead fisso per il pod quando Kubernetes programma il pod e ridimensiona il relativo cgroup. Ottimizzare questo valore in base all'utilizzo previsto della CPU dei componenti host Kata.

Procedure consigliate per la gestione della CPU

• Se il nodo ha in genere molta capacità di CPU gratuita, queste prenotazioni potrebbero non essere necessarie.
• Se i nodi vengono generalmente eseguiti al limite di consumo della CPU, una prenotazione diversa da zero garantisce che i pod possano essere eseguiti in modo più affidabile.
  • Le richieste di CPU dei pod aiutano lo scheduler di Kubernetes a riservare una capacità sufficiente dei nodi per un carico di lavoro. La capacità riservata per un carico di lavoro specifico non è disponibile per altri carichi di lavoro nel nodo.
• Specificare le richieste di CPU che l'infrastruttura può soddisfare. Se la capacità disponibile si avvicina allo zero o se la richiesta è troppo elevata, i carichi di lavoro potrebbero non avviarsi.
• Allineare le richieste di CPU ai limiti della CPU. Le richieste influiscono sulla pianificazione di Kubernetes, ma lo shim Kata non le usa per dimensionare la VM del pod. Il limite della CPU determina l'allocazione di vCPU della macchina virtuale del pod. Se non viene dichiarato alcun limite di CPU, la macchina virtuale pod riceve una vCPU e i componenti host Kata non hanno limiti di utilizzo della CPU.

Dichiarazioni di esempio

Considerazioni sulla sicurezza per il sandboxing dei Pod

La sandbox dei pod isola i carichi di lavoro da altri carichi di lavoro e dall'host, ma è comunque necessario considerare i rischi di sicurezza seguenti.

Pod con privilegi

Alcuni carichi di lavoro richiedono pod con privilegi. È possibile creare pod con privilegi, ma i dispositivi host non sono collegati ai pod.

L'uso di contenitori con privilegi consente l'accesso come root nella VM guest, ma i contenitori rimangono isolati dall'host.

Usare pod con privilegi solo quando necessario, anche con la sandbox dei pod. Consentire solo agli utenti attendibili di gestire i pod con privilegi.

Volumi di archiviazione del percorso host

Il montaggio hostPath dei volumi nei pod Kata espone direttamente al container una parte del file system dell’host e può indebolire l’isolamento della sandbox dei pod. Applicare le linee guida upstream hostPath per la sicurezza ai workload di sandbox del pod.

I file in /dev sono un'eccezione perché vengono montati nel contenitore dal sistema guest anziché dal sistema host. Questo comportamento mantiene l'isolamento dei pod quando un carico di lavoro richiede questo percorso.

Blocca hostPath volumi tramite Criteri di Azure

Criteri di Azure fornisce misure di sicurezza e applicazione centralizzate e coerenti per i componenti del cluster.

AKS fornisce definizioni di criteri predefinite che impongono le procedure consigliate. Assegnare il criterio I pod del cluster Kubernetes devono usare solo tipi di volume consentiti con l'effetto Deny, ed escludere hostPath dai tipi di volume consentiti per bloccare i pod che tentano di montare volumi di tipo hostPath.

Passaggi successivi

Scoprire come distribuire il sandbox del pod nel servizio Azure Kubernetes.