✅ VIDEO: Node Affinity
(affinità verso i nodi)
Questo video spiega come decidere su quali nodi devono andare i pod, ma in modo
più avanzato rispetto ai NodeSelectors e ai Taints/Tolerations.
🔵 1. Perché serve la Node Affinity?
Con nodeSelector puoi dire:
nodeSelector:
size: Large
👉 Significa: “Metti il pod solo sui nodi con label size=Large”.
MA:
❌ Non puoi usare operatori complessi (In, NotIn, Exists...)
❌ Non puoi combinare condizioni
❌ Non puoi dire “preferisco questo nodo ma accetto anche altri”
🔵 2. Node Affinity: versione avanzata
La Node Affinity permette regole molto più flessibili, ad esempio:
✔ usare operatori
✔ definire gruppi di valori
✔ dire se la regola è obbligatoria o solo preferita
✔ gestire comportamento quando il nodo cambia etichetta
🔵 3. Formato base YAML
Esempio (come nel video):
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: size
operator: In
values:
- Large
Significa:
👉 Al momento dello scheduling, il pod DEVE essere messo su un nodo con size=Large.
🔵 4. Operatori disponibili
Il video introduce operatori per le espressioni delle labels:
Operatore Significato
In l’etichetta deve avere uno dei
valori
NotIn l’etichetta NON deve avere quei
valori
Exists la label deve esistere (qualunque
valore)
DoesNotExist la label NON deve esistere
Esempi del video:
“size Large OPPURE Medium”
operator: In
values: ["Large", "Medium"]
“voglio solo nodi che abbiano la label size”:
operator: Exists
🔵 5. Tipi di Node Affinity (MOLTO IMPORTANTE)
Il video spiega che esistono due modalità (per ora):
A. requiredDuringSchedulingIgnoredDuringExecution
Il pod può essere schedulato solo su nodi che rispettano la regola
Dopo che il pod gira, se il nodo cambia, il pod continua a girare
Non viene sfrattato
Il video dice:
➡ “ignoredDuringExecution significa che il pod non viene toccato se la label viene rimossa
dal nodo.”
Questo è il comportamento attuale di Kubernetes.
B. preferredDuringSchedulingIgnoredDuringExecution
È solo una preferenza
Kubernetes prova a metterlo su nodi che rispettano la regola
MA se non trova un nodo valido → lo schedula altrove
🔵 6. Futuro: Required durante l’esecuzione
Il video dice che stanno arrivando nuovi tipi:
requiredDuringSchedulingRequiredDuringExecution
→ se la label cambia, il pod verrà sfrattato.
Questo NON esiste ancora al 100% ma è in sviluppo.
🔵 7. Nodo cambia label → cosa succede?
Esempio del video:
➡ Nodo1 ha label size=Large
➡ Il pod è programmato con NodeAffinity richiesta su “Large”
➡ Il pod va su Node1
Poi:
🚨 L’amministratore rimuove la label dal nodo!
Risultato con IgnoredDuringExecution:
✔ Il pod continua a vivere
✔ Kubernetes non lo sposta
✔ Non viene terminato
🔵 8. Differenza con i Taints
Il secondo video spiega la differenza:
🔸 Taints/Tolerations
Servono a dire:
👉 “Questo nodo NON accetta pod che non hanno la giusta toleration.”
È il nodo che rifiuta i pod.
🔸 Node Affinity
Serve a dire:
👉 “Questo pod vuole andare solo su questi nodi etichettati.”
È il pod che chiede un nodo specifico.
🔵 9. Quando usarli insieme?
Il video propone un esercizio:
abbiamo 3 nodi: Blue, Red, Green
e 3 pod Blue, Red, Green
Obiettivo:
✔ il pod Blue va solo sul nodo Blue
✔ il pod Red sul nodo Red
✔ il pod Green sul nodo Green
❌ nessun altro pod deve andare su quei nodi
Soluzione:
1. Taints sui nodi
→ impediscono ad altri pod di finire su quei nodi
2. Tolerations sui pod
→ permettono solo ai pod giusti di atterrare su quei nodi
3. Node Affinity
→ assicura che quei pod preferiscano proprio quei nodi
Risultato:
💯 Assegnazione perfetta e nessuna collisione.
Esempio pratico dell'esempio appena esposto :
⭐ Esempio Completo (3 nodi + 3 pod) — Come nel video
Obiettivo:
Pod BLUE deve finire sul nodo BLUE
Pod RED deve finire sul nodo RED
Pod GREEN deve finire sul nodo GREEN
Nessun altro pod deve andare su quei nodi
Nessuno dei 3 pod deve andare su nodi sbagliati
🔵 1. Etichettiamo i nodi
kubectl label node node-blue color=blue
kubectl label node node-red color=red
kubectl label node node-green color=green
🚫 2. Applichiamo TAINT ai nodi
Così i nodi accettano solo pod che tollerano il loro colore:
kubectl taint node node-blue color=blue:NoSchedule
kubectl taint node node-red color=red:NoSchedule
kubectl taint node node-green color=green:NoSchedule
🟩 3. Creiamo i 3 Pod con TOLERATIONS + NODE AFFINITY
Questo garantisce DOPPIA protezione:
✔️ TOLERATIONS → il nodo li accetta
✔️ AFFINITY → il pod cerca proprio quel nodo
🔵 Pod Blue ([Link])
apiVersion: v1
kind: Pod
metadata:
name: blue-pod
spec:
containers:
- name: c1
image: nginx
tolerations:
- key: "color"
operator: "Equal"
value: "blue"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: color
operator: In
values:
- blue
🔴 Pod Red ([Link])
apiVersion: v1
kind: Pod
metadata:
name: red-pod
spec:
containers:
- name: c1
image: nginx
tolerations:
- key: "color"
operator: "Equal"
value: "red"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: color
operator: In
values:
- red
🟩 Pod Green ([Link])
apiVersion: v1
kind: Pod
metadata:
name: green-pod
spec:
containers:
- name: c1
image: nginx
tolerations:
- key: "color"
operator: "Equal"
value: "green"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: color
operator: In
values:
- green
✔️ Applichiamo tutto
kubectl apply -f [Link]
kubectl apply -f [Link]
kubectl apply -f [Link]
🔍 Controllo dove sono finiti
kubectl get pod -o wide
🎉 RISULTATO
Pod Nodo
blue-pod node-blue
red-pod node-red
green-pod node-
green
E NESSUN altro pod può essere schedulato su questi nodi.