Hardening dei nodi (anteprima) in Servizio Azure Kubernetes (AKS)

Node Hardening è una funzionalità facoltativa per i pool di nodi Linux che protegge la stabilità dei nodi quando i carichi di lavoro mettono i nodi sotto pressione di CPU, memoria o disco. Quando si abilita la protezione avanzata dei nodi in un cluster, AKS modifica il modo in cui ogni nodo riserva e applica le risorse per i componenti e i servizi host Kubernetes e il modo in cui kubelet rimuove i pod quando le risorse scarseggiano.

Questo articolo illustra le modifiche apportate da Node Hardening, confronta le impostazioni predefinite con le impostazioni predefinite standard di AKS e illustra come abilitare, verificare, personalizzare e disabilitare la funzionalità.

Importante

Le funzionalità in anteprima di AKS sono disponibili in modalità self-service, su base volontaria. Le anteprime vengono fornite "così come sono" e "come disponibili" e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime di AKS sono coperte solo parzialmente dall'assistenza clienti nei limiti del possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

Vantaggi dell'hardening dei nodi

Nei nodi occupati o con picchi, i carichi di lavoro possono usare risorse necessarie per kubelet, il runtime del contenitore e i servizi host. In questo caso, i nodi possono non rispondere, segnalare uno stato NotReady o terminare improvvisamente i pod. La protezione avanzata dei nodi riduce questi rischi nei modi seguenti:

  • Prenotazioni forzate: Per impostazione predefinita, AKS usa i valori kube-reserved solo per calcolare quanta capacità l'utilità di pianificazione può allocare ai pod. Utilizzando Node Hardening, kubelet fa rispettare anche le risorse riservate kube-reserved e system-reserved tramite i gruppi di controllo Linux (cgroups). Il kubelet e containerd vengono eseguiti in un cgroup dedicato kubereserved.slice, in modo che mantengano la quota di CPU riservata e la memoria riservata anche quando i pod saturano il nodo.
  • Capacità dedicata per i servizi host: Node Hardening aggiunge un'allocazione riservata al sistema per i servizi del sistema operativo host, che vengono eseguiti in system.slice.
  • Più margine di memoria: La soglia hard di eviction per la memoria disponibile si adatta alla memoria del nodo, quindi kubelet rimuove i pod prima che il nodo raggiunga un livello di memoria criticamente basso.
  • Evizione graduale: Le soglie di evizione soft consentono al kubelet di espellere i pod in modo graduale, con un periodo di grazia per la terminazione, quando la memoria o lo spazio su disco sono insufficienti. L'evizione forzata, che termina immediatamente i pod, funge quindi da ultima risorsa.
  • Riserve che aumentano con la densità dei pod: Il calcolo della memoria riservata di kube aumenta con il numero massimo di pod per nodo, che tiene conto del sovraccarico di kubelet e containerd dell'esecuzione di più pod.

Cosa cambia quando si abilita Node Hardening

Le tabelle seguenti confrontano le impostazioni predefinite standard per i nodi Linux che eseguono Kubernetes 1.29 o versione successiva con le impostazioni predefinite applicate da AKS quando Node Hardening è abilitato.

Prenotazioni di risorse

Impostazione Senza hardening dei nodi Con hardening dei nodi
CPU riservata per kube In base al numero di core CPU. Per altre informazioni, vedere Prenotazioni CPU. Invariato
Memoria riservata di Kube min(20 × maxPods + 50, 25% of node memory) MiB min(35 × maxPods + max(250, 2% of node memory), 25% of node memory) MiB
ID di processo (PID) riservati per Kube 1000 Non prenotato
CPU riservata al sistema None 100m
Memoria riservata dal sistema None 200 MiB, più 100 MiB per ogni 32 GiB completi di memoria del nodo, più 100 MiB per i cluster che usano Azure CNI
Archiviazione temporanea riservata dal sistema None 1Gi

Soglie di espulsione

Impostazione Senza hardening dei nodi Con hardening dei nodi
Espulsione forzata: memory.available 100Mi 250Mi per i nodi con 8 GiB di memoria o minore, 375Mi per i nodi con più di 8 GiB e meno di 32 GiB e 512Mi per i nodi con 32 GiB o più
Hard eviction: nodefs.available e nodefs.inodesFree 10% e 5% Invariato
Espulsione forzata: pid.available 2000 Non impostato
Espulsione soft: memory.available None 500Mi, 750Mi o 1Gi, usando gli stessi livelli di memoria del nodo dell'evizione forzata, con un periodo di tolleranza di 30 secondi
Espulsione soft: nodefs.available e nodefs.inodesFree None 12% e 7%, ognuno con un periodo di tolleranza di 2 minuti
Periodo di tolleranza massimo di terminazione del pod durante la soft eviction Non impostato 60 secondi

Applicazione di Cgroup

Impostazione Senza hardening dei nodi Con hardening dei nodi
Allocazione del nodo imposta pods pods, kube-reserved e system-reserved
Kubelet e cgroup di containerd system.slice, senza limiti kubereserved.slice, con memoria limitata alla memoria kube-reserved e a una quota di CPU proporzionale alla CPU kube-reserved
cgroup dei servizi host system.slice, senza limiti system.slice, con memoria limitata alla memoria riservata dal sistema e una condivisione cpu proporzionale alla CPU riservata dal sistema

Poiché Node Hardening riserva più capacità, i nodi segnalano una minore capacità allocabile per i pod. Ad esempio, in un nodo con 4 vCPU e 16 GiB di memoria che usa Azure CNI, l'abilitazione di Node Hardening riduce la capacità allocabile come indicato di seguito:

  • Con il massimo predefinito di 250 pod per nodo, si arriva a circa 570 MiB di memoria, 100 millicore di CPU e 1 GiB di archiviazione temporanea.
  • Con un massimo di 30 pod per nodo, circa 1,3 GiB di memoria, 100 millicore di CPU e 1 GiB di archiviazione temporanea.

Le soglie di rimozione soft non riducono la capacità allocabile. Cambiano solo quando kubelet inizia a espellere i pod.

Considerations

Tenere presenti le considerazioni seguenti prima di abilitare Node Hardening:

  • Si abilita l'hardening dei nodi a livello di cluster e si applica a tutti i pool di nodi Linux nel cluster. Non è possibile abilitarlo per i singoli pool di nodi e non influisce sui pool di nodi Windows.
  • I nodi segnalano una capacità meno allocabile, quindi i pod che si adattano a un nodo prima di abilitare Node Hardening potrebbero non rientrare in un secondo momento. Esaminare le richieste di risorse del pod e le dimensioni del pool di nodi.
  • I servizi host in system.slice condividono un limite di memoria rigido uguale alla memoria riservata dal sistema. Se si eseguono agenti personalizzati nei nodi come servizi systemd, ad esempio sicurezza, monitoraggio o agenti di inoltro dei log, tali agenti vengono conteggiati rispetto a questo limite. Convalidate l'utilizzo della memoria e la stabilità prima di usare Node Hardening nell'ambiente di produzione.
  • I valori impostati nella configurazione kubelet personalizzata di un pool di nodi sostituiscono le impostazioni predefinite corrispondenti di hardening dei nodi. Per altre informazioni, vedere Personalizzare le impostazioni di protezione avanzata dei nodi.
  • Se si disabilita la protezione avanzata dei nodi in un secondo momento, i pool di nodi esistenti mantengono le impostazioni di soft eviction avanzate, anche dopo che i relativi nodi vengono nuovamente sottoposti a reimaging. Per rimuovere queste impostazioni, è necessario creare nuovi pool di nodi. Per altre informazioni, vedere Disabilitare l'hardening dei nodi.
  • I valori predefiniti possono cambiare mentre la funzionalità è in anteprima. Iniziare con un cluster non di produzione e convalidare i carichi di lavoro in condizioni rappresentative di pressione dei nodi.

Prerequisites

  • Una sottoscrizione di Azure. Se non ne hai uno, crea un account gratuito.
  • Un cluster del servizio Azure Kubernetes con pool di nodi Linux o autorizzazioni per crearne uno.
  • L'estensione aks-preview di interfaccia della riga di comando di Azure e il flag CustomNodeConfigPreview di funzionalità, come descritto nelle sezioni seguenti.

Installare l'estensione aks-preview interfaccia della riga di comando di Azure

  1. Installare l'estensione aks-preview usando il az extension add comando .

    az extension add --name aks-preview

  2. Eseguire l'aggiornamento alla versione più recente dell'estensione usando il az extension update comando .

    az extension update --name aks-preview

Registrare il flag di funzionalità CustomNodeConfigPreview

  1. Registra il feature flag CustomNodeConfigPreview usando il comando az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "CustomNodeConfigPreview"

    Sono necessari alcuni minuti per visualizzare lo stato Registered.

  2. Verificare lo stato della registrazione usando il az feature show comando .

    az feature show --namespace "Microsoft.ContainerService" --name "CustomNodeConfigPreview"

  3. Quando lo stato mostra Registrato, aggiornare la registrazione del provider di risorse Microsoft.ContainerService usando il comando az provider register.

    az provider register --namespace "Microsoft.ContainerService"

Abilita hardening dei nodi

Durante l'anteprima, Node Hardening non è abilitato per impostazione predefinita.

Abilita l'hardening dei nodi in un nuovo cluster

Creare un cluster con la protezione avanzata dei nodi abilitata usando il az aks create comando con il --enable-node-hardening parametro .

Questo comando richiede l'estensione aks-preview e il flag di funzionalità CustomNodeConfigPreview. Per altre informazioni, vedere Prerequisiti.

az aks create \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --enable-node-hardening \
    --generate-ssh-keys

Per confermare la modifica, vedere Verificare le impostazioni di protezione avanzata del nodo.

Abilitare l'hardening dei nodi in un cluster esistente

Abilita la protezione avanzata dei nodi in un cluster esistente usando il comando az aks update con il parametro --enable-node-hardening.

Questo comando richiede l'estensione aks-preview e il flag di funzionalità CustomNodeConfigPreview. Per altre informazioni, vedere Prerequisiti.

az aks update \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --enable-node-hardening

Per confermare la modifica, vedere Verificare le impostazioni di protezione avanzata del nodo.

Verificare le impostazioni di hardening del nodo

  1. Ottenere le credenziali per il cluster usando il az aks get-credentials comando .

    az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>

  2. Esaminare le impostazioni di prenotazione e di eviction kubelet effettive in un nodo eseguendo una query sull'endpoint di configurazione kubelet.

    kubectl get --raw "/api/v1/nodes/<node-name>/proxy/configz" | jq '.kubeletconfig | {kubeReserved, systemReserved, evictionHard, evictionSoft, evictionSoftGracePeriod, evictionMaxPodGracePeriod, enforceNodeAllocatable}'

    Su un nodo con protezione avanzata, systemReserved e evictionSoft contengono valori e enforceNodeAllocatable include kube-reserved e system-reserved.

  3. Confrontare la capacità del nodo con le sue risorse allocabili.

    kubectl get node <node-name> -o jsonpath='{.status.capacity}{"\n"}{.status.allocatable}{"\n"}'

    In un nodo rafforzato, la CPU, la memoria e l'archiviazione temporanea allocabili sono inferiori alla capacità. La differenza è uguale ai valori kube-reserved e system-reserved nelle Prenotazioni risorse, oltre alle soglie di sfratto rigide nelle Soglie di sfratto. Ad esempio, in un nodo con 4 vCPU e 16 GiB di memoria che usa Azure CNI, la CPU allocabile è di 240 millicores inferiore alla capacità: 140 millicores di CPU kube-reserved e 100 millicores di CPU riservata dal sistema.

Personalizzare le impostazioni di hardening dei nodi

È possibile eseguire l'override delle impostazioni predefinite di kube-reserved e di eviction per un pool di nodi Linux usando una configurazione kubelet personalizzata. Queste impostazioni richiedono il feature flag CustomNodeConfigPreview. È possibile usarli indipendentemente dal fatto che nel cluster sia abilitato o meno Node Hardening. Il servizio Azure Kubernetes gestisce i valori riservati dal sistema e l'imposizione di cgroup e non è possibile personalizzarli.

Ogni impostazione sovrascrive una riga della tabella Prenotazioni risorse o Soglie di rimozione. Le righe riservate di Kube corrispondono alle kubeReserved impostazioni. Le righe di rimozione hard corrispondono alle hardEvictionThreshold impostazioni. Le righe di espulsione soft corrispondono alle impostazioni softEvictionThreshold e softEvictionGracePeriod. Il periodo di tolleranza massimo di terminazione del pod corrisponde a evictionMaxPodGracePeriodInSeconds.

È possibile configurare le impostazioni seguenti:

Impostazione Overrides Description
kubeReserved.cpuMillicores CPU riservata per kube CPU riservata per i daemon di sistema Kubernetes, in millicores.
kubeReserved.memoryMB Memoria riservata per kube-reserved Memoria riservata per i daemon di sistema Kubernetes, in MiB.
hardEvictionThreshold.memoryAvailable Espulsione forzata: memory.available Soglia di espulsione rigida per la memoria disponibile.
hardEvictionThreshold.nodeFsAvailable Espulsione forzata: nodefs.available Soglia di sfratto rigida per lo spazio disponibile del file system del nodo.
hardEvictionThreshold.nodeFsInodesFree Espulsione forzata: nodefs.inodesFree Soglia di espulsione rigida per gli inode liberi del filesystem del nodo.
softEvictionThreshold.memoryAvailable Espulsione soft: memory.available Soglia di espulsione soft per la memoria disponibile.
softEvictionThreshold.nodeFsAvailable Espulsione soft: nodefs.available Soglia di eviction soft per lo spazio disponibile del file system del nodo.
softEvictionThreshold.nodeFsInodesFree Espulsione soft: nodefs.inodesFree Soglia di eviction temporanea per gli inodi liberi del file system del nodo.
softEvictionGracePeriod.memoryAvailable Espulsione soft: memory.available periodo di tolleranza Per quanto tempo la memoria disponibile deve rimanere al di sotto della soglia soft prima che il kubelet espella i pod.
softEvictionGracePeriod.nodeFsAvailable Soft eviction: nodefs.available periodo di tolleranza Per quanto tempo lo spazio disponibile del file system dei nodi deve rimanere al di sotto della soglia flessibile prima che kubelet espella i pod.
softEvictionGracePeriod.nodeFsInodesFree espulsione soft: nodefs.inodesFree periodo di tolleranza Per quanto tempo gli inode liberi del file system del nodo devono rimanere al di sotto della soglia flessibile prima che kubelet espella i pod.
evictionMaxPodGracePeriodInSeconds Periodo di tolleranza massimo di terminazione del pod durante la soft eviction Numero massimo di secondi che kubelet consente ai pod di terminare durante un'evizione soft.
  • Per i valori consentiti, i minimi e le regole di convalida per ogni impostazione, vedere Parametri di configurazione dei nodi personalizzati per AKS.
  • Per ogni segnale di espulsione, impostare sia la soglia di espulsione soft che il periodo di tolleranza corrispondente e assicurarsi che ogni soglia di espulsione soft sia maggiore della soglia di espulsione hard per lo stesso segnale.

  1. Creare un file di configurazione kubelet, ad esempio nodehardening-kubelet.json, con le impostazioni da personalizzare. Nell'esempio seguente vengono impostati tutti i valori configurabili. Imposta kube-reserved su 200 millicore di CPU e 1.024 MiB di memoria. Imposta soglie rigide di espulsione della 512Mi memoria disponibile, 10% dello spazio disponibile del file system e 5% degli inodi liberi. Imposta soglie di rimozione soft di 1Gi, 12%e 7% con periodi di tolleranza di 30 secondi, 2 minuti e 2 minuti. Imposta anche un periodo di grazia massimo di 60 secondi per la terminazione del pod.

    {
  "kubeReserved": {
    "cpuMillicores": 200,
    "memoryMB": 1024
  },
  "hardEvictionThreshold": {
    "memoryAvailable": "512Mi",
    "nodeFsAvailable": "10%",
    "nodeFsInodesFree": "5%"
  },
  "softEvictionThreshold": {
    "memoryAvailable": "1Gi",
    "nodeFsAvailable": "12%",
    "nodeFsInodesFree": "7%"
  },
  "softEvictionGracePeriod": {
    "memoryAvailable": "30s",
    "nodeFsAvailable": "2m",
    "nodeFsInodesFree": "2m"
  },
  "evictionMaxPodGracePeriodInSeconds": 60
}

  2. Creare un pool di nodi Linux che usa il file di configurazione usando il az aks nodepool add comando con il --kubelet-config parametro .

    az aks nodepool add \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --kubelet-config ./nodehardening-kubelet.json

    È anche possibile usare il --kubelet-config parametro con il az aks create comando per applicare la configurazione al pool di nodi iniziale del cluster.

Disabilita hardening del nodo

Disabilita la protezione avanzata dei nodi usando il comando az aks update con il parametro --disable-node-hardening.

Questo comando richiede l'estensione aks-preview e il flag di funzionalità CustomNodeConfigPreview. Per altre informazioni, vedere Prerequisiti.

az aks update \
    --resource-group <resource-group-name> \
    --name <cluster-name> \
    --disable-node-hardening

Disabilitando Node Hardening si disattiva l'impostazione a livello di cluster, ma non si modificano immediatamente i nodi esistenti. I nodi esistenti mantengono tutte le impostazioni avanzate fino a quando non viene rigenerata l'immagine del nodo, ad esempio durante l'aggiornamento dell'immagine di un nodo. Dopo la ricreazione dell'immagine di un nodo, si applicano le modifiche seguenti:

  • Ripristino delle impostazioni predefinite standard di AKS: Risorse riservate di Kube e riservate dal sistema, soglie di rimozione hard e applicazione del cgroup. La capacità allocabile del nodo aumenta di conseguenza.
  • Mantenuto: Le soglie di soft eviction, i periodi di grazia della soft eviction e il periodo di grazia massimo per la terminazione del pod durante la soft eviction.

È possibile impostare una configurazione kubelet personalizzata solo quando si crea un cluster o un pool di nodi, quindi non è possibile rimuovere le impostazioni di eviction soft mantenute da un pool di nodi esistente. Per rimuoverli, creare un nuovo pool di nodi che li reimposta esplicitamente, spostare i carichi di lavoro nel nuovo pool di nodi e quindi eliminare il pool di nodi precedente.

  1. Creare un file di configurazione kubelet, ad esempio remove-soft-eviction.json. Nell'esempio seguente vengono impostate tutte le soglie di soft eviction e il periodo di tolleranza su una stringa vuota, che disattiva la soft eviction per tale segnale. Imposta anche il periodo di tolleranza massimo di terminazione del pod su 0, che è il valore predefinito standard di AKS.

    {
  "softEvictionThreshold": {
    "memoryAvailable": "",
    "nodeFsAvailable": "",
    "nodeFsInodesFree": ""
  },
  "softEvictionGracePeriod": {
    "memoryAvailable": "",
    "nodeFsAvailable": "",
    "nodeFsInodesFree": ""
  },
  "evictionMaxPodGracePeriodInSeconds": 0
}

  2. Creare un pool di nodi Linux che usa il file di configurazione usando il az aks nodepool add comando con il --kubelet-config parametro .

    az aks nodepool add \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --kubelet-config ./remove-soft-eviction.json

  3. Spostare i carichi di lavoro nel nuovo pool di nodi e quindi eliminare il pool di nodi precedente. Per altre informazioni, vedere Ridimensionare i pool di nodi nel servizio Azure Kubernetes.

Per confermare le impostazioni su un nodo, vedere Verificare le impostazioni di protezione avanzata del nodo. Nei nodi del nuovo pool di nodi, evictionSoft è vuoto.

Contenuti correlati

  • Ultimo aggiornamento: