Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
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.slicecondividono 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-previewdi interfaccia della riga di comando di Azure e il flagCustomNodeConfigPreviewdi funzionalità, come descritto nelle sezioni seguenti.
Installare l'estensione aks-preview interfaccia della riga di comando di Azure
Installare l'estensione
aks-previewusando ilaz extension addcomando .az extension add --name aks-previewEseguire l'aggiornamento alla versione più recente dell'estensione usando il
az extension updatecomando .az extension update --name aks-preview
Registrare il flag di funzionalità CustomNodeConfigPreview
Registra il feature flag
CustomNodeConfigPreviewusando il comandoaz feature register.az feature register --namespace "Microsoft.ContainerService" --name "CustomNodeConfigPreview"Sono necessari alcuni minuti per visualizzare lo stato Registered.
Verificare lo stato della registrazione usando il
az feature showcomando .az feature show --namespace "Microsoft.ContainerService" --name "CustomNodeConfigPreview"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
Ottenere le credenziali per il cluster usando il
az aks get-credentialscomando .az aks get-credentials --resource-group <resource-group-name> --name <cluster-name>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,
systemReservedeevictionSoftcontengono valori eenforceNodeAllocatableincludekube-reservedesystem-reserved.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.
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 della512Mimemoria disponibile,10%dello spazio disponibile del file system e5%degli inodi liberi. Imposta soglie di rimozione soft di1Gi,12%e7%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 }Creare un pool di nodi Linux che usa il file di configurazione usando il
az aks nodepool addcomando con il--kubelet-configparametro .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-configparametro con ilaz aks createcomando 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.
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 su0, che è il valore predefinito standard di AKS.{ "softEvictionThreshold": { "memoryAvailable": "", "nodeFsAvailable": "", "nodeFsInodesFree": "" }, "softEvictionGracePeriod": { "memoryAvailable": "", "nodeFsAvailable": "", "nodeFsInodesFree": "" }, "evictionMaxPodGracePeriodInSeconds": 0 }Creare un pool di nodi Linux che usa il file di configurazione usando il
az aks nodepool addcomando con il--kubelet-configparametro .az aks nodepool add \ --resource-group <resource-group-name> \ --cluster-name <cluster-name> \ --name <node-pool-name> \ --kubelet-config ./remove-soft-eviction.jsonSpostare 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.