Kubernetes – 4. Node Affinity, Resource Requests a Limits

V tretej časti sme si ukázali základy textového konfiguračného súbor vo formáte YAML. Na jednoduchých YAML súboroch sme si ukázali, ako spustiť job a deployment. Ručne sme teda nasadili pody na pripravené worker nody, pričom sme dopredu neurčili, ktoré pody sa (ne)môžu nasadiť na určité nody.

Chcete si vytvoriť vlastný Kubernetes (K8s) klaster? Vyskúšajte si ho vo Virtuálnom dátovom centre od Websupportu.

Tento diel bude o obmedzovaní nasadenia podov iba na vybrané nody. Niekedy je totiž žiaduce, aby sme isté nody nezaťažovali príliš, pretože veľké zaťaženie by mohlo negatívne ovplyvniť rýchlosť, stabilitu a bezpečnosť Kubernetes Clustra ako celku. Budeme tiež obmedzovať využitie procesora (CPU) a operačnej pamäte (RAM), aby sa nestalo, že celý node bude využívať nepatrične veľa prostriedkov.

Mažeme nepotrebné služby a nasadenia

Pred tým, ako budeme pokračovať, vymažeme nepotrebné služby (services) a nasadenia (deployments), aby sme Kubernetes Cluster zbytočne nezaťazovali. Najskôr vypíšeme zoznam spustených služieb (prvý riadok) a aktívnych nasadení (druhý riadok) na VPS master:

kubectl get services

kubectl get deployments

Potom nepotrebné služby (prvý riadok) a nasadenia (druhý riadok) na VPS master zmažeme (tu je nepotrebná služba nazvaná nginx-service a nepotrebné nasadenie nginx-deployment):

kubectl delete service nginx-service

kubectl delete deployment nginx-deployment

Obmedzujeme nasadenie podov na konkrétne nody

Node Affinity je názov pre súbor pravidiel určujúcich podom, na ktoré nody sa môžu nasadiť. Pravidlá určujeme vo vzťahu k štítkom (labels) na nodoch. Na nod označený štítkom následne dokážeme nasadiť iba určité pody.

Existujú dva typy Node Affinity v Kubernetes Cluster: requiredDuringSchedulingIgnoredDuringExecution a preferredDuringSchedulingIgnoredDuringExecution, pričom v tomto návode budeme používať ten prvý (required…).

Aby sme mohli worker nodom nastaviť Node Affinity, musíme ich označiť štítkami. Označíme iba node worker-1:

kubectl label node worker-1 app=test

Overíme, že sa štítok zapísal:

kubectl describe node worker-1 | grep Labels

Vytvoríme textový konfiguračný súbor vo formáte YAML s názvom deployment-without-affinity.yaml (prvý riadok), do ktorého zapíšeme definíciu nasadenia bez Node Affinity (ostatné riadky):

nano ~/deployment-without-affinity.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-without-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx

Vložíme skopírovaný obsah, uložíme pomocou klávesovej skratky Ctrl + X a následne stlačením klávesu y a potvrdením klávesom Enter.

Nasadenie spustíme z vyššie vytvoreného konfiguračného súboru:

kubectl create -f ~/deployment-without-affinity.yaml

Takto zistíme (stĺpec NODE), že pody s názvom začínajúcim na app-without-affinity- sa nasadili na oba nody (worker-1 aj worker-2):

kubectl get pods -o wide

Ak ale potrebujeme všetky pody nasadiť iba na nod worker-1, musíme konfiguračný súbor upraviť (prvý riadok) s použitím Node Affinity takto (ostatné riadky):

nano ~/deployment-with-affinity.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-affinity
spec:
  replicas: 3
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: app
                operator: In
                values:
                - test

Vložíme skopírovaný obsah, uložíme pomocou klávesovej skratky Ctrl + X a následne stlačením klávesu y a potvrdením klávesom Enter.

Nasadenie spustíme z vyššie vytvoreného konfiguračného súboru:

kubectl create -f ~/deployment-with-affinity.yaml

Takto zistíme (stĺpec NODE), že pody s názvom začínajúcim na app-with-affinity- sa nasadili iba na nod worker-1:

kubectl get pods -o wide

Za pomoci odkázania na štítok app=test nodu worker-1 sme teda pri nasadení dosiahli, že sa pody vytvorili iba na štítkom označenom node.

Obmedzujeme spodnú a hornú hranicu využitia prostriedkov

Na VPS master vymažeme obe nasadenia, ktoré sme vyššie spustili:

kubectl delete deployment app-with-affinity

kubectl delete deployment app-without-affinity

Na VPS master nainštalujeme nástroj kubernetes-metrics-server:

sudo apt install git -y

cd ~

git clone https://github.com/kodekloudhub/kubernetes-metrics-server.git

cd ~/kubernetes-metrics-server/

kubectl create -f .

V závislosti na rýchlosti VPS a sieťového pripojenia počkáme, pokým sa nainštalovaný nástroj spustí a získa prvé štatistiky od nodov. Následne zadáme príkaz, ktorým budeme monitorovať vyťaženie procesora (CPU) a operačnej pamäte (RAM):

kubectl top node

Teraz máme pripravené všetko potrebné, aby sme mohli aplikovať spodnú hranicu využitia CPU a RAM (Resource Requests) a hornú hranicu využitia CPU a RAM (Resource Limits).

Vytvoríme textový konfiguračný súbor vo formáte YAML s názvom pod-with-ram.yaml (prvý riadok), do ktorého zapíšeme definíciu nasadenia podu s obmedzením využitia operačnej pamäte RAM (ostatné riadky):

nano ~/pod-with-ram.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-ram
spec:
  containers:
  - name: container-ram
    image: polinux/stress
    resources:
      limits:
        memory: "50Mi"
      requests:
        memory: "20Mi"
    command: ["stress"]
    args: ["--vm", "1", "--vm-bytes", "30M", "--vm-hang", "1"]

Vložíme skopírovaný obsah, uložíme pomocou klávesovej skratky Ctrl + X a následne stlačením klávesu y a potvrdením klávesom Enter.

Nasadenie spustíme z vyššie vytvoreného konfiguračného súboru:

kubectl create -f ~/pod-with-ram.yaml

Overíme, či pod s názvom pod-ram nezaberá menej ako 20 Mi a viac ako 50 Mi operačnej pamäte RAM (stĺpec MEMORY):

kubectl top pods

Vytvoríme textový konfiguračný súbor vo formáte YAML s názvom pod-with-cpu.yaml (prvý riadok), do ktorého zapíšeme definíciu nasadenia podu s obmedzením využitia procesora (ostatné riadky):

nano ~/pod-with-cpu.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pod-cpu
spec:
  containers:
  - name: container-cpu
    image: vish/stress
    resources:
      limits:
        cpu: "1"
      requests:
        cpu: "0.5"
    args:
    - -cpus
    - "2"

Vložíme skopírovaný obsah, uložíme pomocou klávesovej skratky Ctrl + X a následne stlačením klávesu y a potvrdením klávesom Enter.

Nasadenie spustíme z vyššie vytvoreného konfiguračného súboru:

kubectl create -f ~/pod-with-cpu.yaml

Overíme, či pod s názvom pod-cpu nezaberá menej ako 0,5 a viac ako 1 procesora (stĺpec CPU):

kubectl top pods

Aj keď sme vo vyššie uvedenom konfiguračnom súbore žiadali 2 CPU (args), limit nás nepustil na viac ako 1 CPU (ekvivalent 999m).

Hľadáte manažovaný Kubernetes? Využite služby našich skúsených profesionálov na cloud native – radi vám pripravíme riešnie na mieru.

Zhrnutie

Vo štvrtom diele sme ukázali, ako obmedziť nasadenie podov iba na konkrétne nody za pomoci štítkov (labels), ktorými sme označili požadovaný nod. Získali sme tak lepšiu kontrolu nad zaťažovaním jednotlivých nodov. Rovnako sme nastavili aj minimálne a maximálne využitie procesora (CPU) a operačnej pamäte (RAM). Predišli sme tak prípadnému výpadku podov, prípadne celého Kubernetes Clustra.