Podien (anti)affiniteetti

Pod-affiniteetin ja anti-affiniteetin avulla voit määrittää, mille solmuille Podisi ajoitetaan, sen perusteella, millaisia tunnisteita kyseisellä solmulla jo käynnissä olevilla Podeilla on. Tätä yleistä periaatetta voidaan käyttää myös tiettyjen solmujen valintaan (tai välttämiseen), jos niissä on tiettyjä laitteistokokoonpanoja, kuten GPU.

Tästä on hyötyä, koska joskus on tärkeää varmistaa affiniteetin avulla, että kaksi Podia jakaa saman liitetyn taltion ja välttää verkon synkronointiongelmat. Toisinaan taas anti-affiniteetin avulla halutaan varmistaa, etteivät kaksi Podia jaa samaa palvelinta, mikä parantaa sovelluksen käytettävyyttä.

Tässä käyttöönottoesimerkissä haluamme, että wes-deployment-käyttöönoton Podit suoritetaan samalla solmulla kuin celery-worker-Podit, jotta ne voivat molemmat liittää saman tallennustaltion (joka voidaan liittää vain yhteen fyysiseen solmuun).

diff --git a/charts/wes/templates/wes/wes-deployment.yaml b/charts/wes/templates/wes/wes-deployment.yaml
index 93ca230..e64349b 100644
--- a/charts/wes/templates/wes/wes-deployment.yaml
+++ b/charts/wes/templates/wes/wes-deployment.yaml
@@ -12,6 +12,16 @@ spec:
       labels:
         app: {{ .Values.wes.appName }}
     spec:
+      affinity:
+        podAffinity:
+          requiredDuringSchedulingIgnoredDuringExecution:
+          - labelSelector:
+              matchExpressions:
+              - key: app
+                operator: In
+                values:
+                - celery-worker
+            topologyKey: "kubernetes.io/hostname"
       initContainers:

affinity-lohkon on oltava spec-osion alla. Jos tätä sovelletaan toiseen käyttöönottoon, yleensä tarvitsee muuttaa vain value ja mahdollisesti key, jotta ne vastaavat sen Podin Labels-tunnisteiden key- ja value-paria, johon haluamme affiniteetin. Podin Labels-tunnisteet voi nähdä komentoriviltä tai selainkäyttöliittymästä.

Labels

Ja komentoriviltä:

$ oc describe pods celery-worker-6777488df4-s9tc7
Name:           celery-worker-6777488df4-s9tc7
Namespace:      wes
Priority:       0
Node:           rahti-comp-io-s25-d/192.168.54.13
Start Time:     Wed, 17 Jan 2024 14:55:57 +0200
Labels:         app=celery-worker
                deployment=celery-worker-57
(...)

Kun affinity-lohko lisätään tähän käyttöönottoon, ajastin käynnistää wes-deployment-käyttöönottoa vastaavat Podit (uudelleen) samalle solmulle, jolla celery-worker on käynnissä. Koska käytetty käytäntö on requiredDuringSchedulingIgnoredDuringExecution, käyttöönotto ei onnistu, jos valitulla solmulla ei ole tilaa. Toinen käytäntö on preferredDuringSchedulingIgnoredDuringExecution, mikä tarkoittaa, että ajoitus ei epäonnistu, vaikka valitulla solmulla ei olisi tilaa, vaan Podit ajoitetaan toiselle solmulle.

Pod anti-affiniteetin osalta syntaksi on hieman erilainen. Tässä on esimerkki:

diff --git a/charts/wes/templates/wes/wes-deployment.yaml b/charts/wes/templates/wes/wes-deployment.yaml
index 93ca230..e64349b 100644
--- a/charts/wes/templates/wes/wes-deployment.yaml
+++ b/charts/wes/templates/wes/wes-deployment.yaml
@@ -12,6 +12,16 @@ spec:
       labels:
         app: {{ .Values.wes.appName }}
     spec:
+      affinity:
+        podAntiAffinity:
+          requiredDuringSchedulingIgnoredDuringExecution:
+          - weight: 100
+            podAffinityTerm:
+              labelSelector:
+                matchExpressions:
+                - key: app
+                  operator: In
+                  values:
+                  - celery-worker
+            topologyKey: "kubernetes.io/hostname"
       initContainers:

Anti-affiniteettia varten tarvitaan kaksi uutta avainta:

weight (välillä 1–100): Ajastin pyrkii ajoittamaan Podit solmuille, jotka täyttävät anti-affiniteettilausekkeet. Ensisijaisin solmu on se, jolla on suurin painojen summa. Käytännössä jokaiselle solmulle, joka täyttää kaikki ajoitusvaatimukset (resurssipyynnöt, requiredDuringScheduling-anti-affiniteettilausekkeet jne.), lasketaan summa käymällä tämän kentän alkiot läpi ja lisäämällä "weight" summaan, jos solmulla on Podeja, jotka vastaavat kyseistä podAffinityTerm-määritystä. Solmu tai solmut, joilla on korkein summa, ovat ensisijaisimpia. Kaikkien täsmäävien WeightedPodAffinityTerm-kenttien painot lasketaan yhteen solmukohtaisesti ensisijaisimman solmun tai ensisijaisimpien solmujen löytämiseksi.
podAffinityTerm: Määrittää joukon Podeja, joiden kanssa tämän Podin ei pitäisi sijaita samalla solmulla (anti-affiniteetti). Samalla solmulla sijaitseminen määritellään siten, että Pod on käynnissä solmulla, jonka <topologyKey>-avaimella määritetyn tunnisteen arvo vastaa minkä tahansa sellaisen solmun arvoa, jolla jokin tähän joukkoon kuuluva Pod on käynnissä.

Lisätietoja ja lisää esimerkkejä löytyy osoitteesta:

https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity