Gestire pod in cluster Kubernetes multi-pool
Gli sviluppatori Contoso stanno lavorando alla trasformazione di applicazioni Windows e Linux sviluppate internamente in immagini basate su Docker distribuibili tramite chart Helm. Nella pianificazione dell'implementazione di cluster Kubernetes in Azure Stack HCI, è necessario garantire il supporto per entrambe le piattaforme del sistema operativo.
Che cosa sono i pool di nodi nei cluster Kubernetes in Azure Stack HCI
AKS in Azure Stack HCI supporta più pool di nodi nello stesso cluster Kubernetes. Ogni pool è costituito da macchine virtuali configurate in modo identico, in base alle impostazioni specificate durante il provisioning del pool.
Raggruppando i nodi in pool separati, è possibile scegliere come destinazione le distribuzioni di pod nel set appropriato di macchine virtuali. Ad esempio, è possibile che siano presenti carichi di lavoro in contenitori supportati solo dal sistema operativo Windows o che richiedano hardware specializzato, ad esempio unità processore di grafica.
Controllare la distribuzione dei pod in pool di nodi nei cluster Kubernetes su Azure Stack HCI
Per impostazione predefinita, Kubernetes pianifica il provisioning dei carichi di lavoro in contenitori in tutti i nodi di lavoro disponibili in modo da ottimizzare l'utilizzo delle risorse. Per modificare questo comportamento, è possibile applicare vincoli alla scelta dei nodi in base ai criteri personalizzati specificati. Questi vincoli includono selettori nodi, taint e tolleranze.
Selettori nodi
Selettore nodi è un'impostazione all'interno della definizione basata su YAML di un pod o di una distribuzione che identifica i nodi di destinazione in cui può essere pianificato il pod corrispondente. Se si intende designare i nodi di destinazione in base al sistema operativo, è possibile fare affidamento sulle etichette predefinite assegnate automaticamente ai nodi da Kubernetes. A seconda del sistema operativo previsto, il selettore nodi avrà il formato kubernetes.io/os = Windows o kubernetes.io/os = Linux . Ad esempio, il manifesto del pod basato su YAML seguente designa i nodi Linux come destinazioni di distribuzione:
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
nodeSelector:
kubernetes.io/os = Linux
Taint e tolleranze
Taint e tolleranze offrono un approccio alternativo al controllo del posizionamento dei pod. Con questo approccio, i taint fanno parte della configurazione del nodo e le tolleranze fanno parte delle specifiche del pod. Contaminando un nodo, si impedisce in modo efficace che ospiti qualsiasi pod senza la corrispondente tolleranza specifica del taint.
Ad esempio, in AKS in Azure Stack HCI, se si vuole consentire la pianificazione di un pod in un nodo Windows, è necessario aggiungere la tolleranza seguente alla relativa definizione:
tolerations:
- key: node.kubernetes.io/os
operator: Equal
value: Windows
effect: NoSchedule
Inoltre, è necessario aggiungere il taint node.kubernetes.io/os=Windows:NoSchedule a ogni nodo di Windows che si vuole rendere disponibile esclusivamente per la distribuzione di pod con la tolleranza corrispondente. A tale scopo, è possibile usare l'utilità della riga di comando kubectl e quindi, dopo la connessione al cluster di destinazione, eseguire il comando seguente per ognuno dei nodi nell'ambito (dove il segnaposto <node_name> definisce il nome del nodo di destinazione):
kubectl taint node <node_name> node.kubernetes.io/os=Windows:NoSchedule
Nota
I selettori nodi applicano le posizioni dei pod in un set specifico di nodi. Le tolleranze consentono l'esecuzione dei pod in un set designato di nodi non contaminati, ma non ne impediscono il posizionamento nei nodi senza taint.