Grunnleggende Kubernetes · leksjon

Nodevelgere og affinitet

Styr hvor Pods planlegges, ved hjelp av nodevelgere og mer uttrykksfulle regler for node- og Pod-affinitet.

Leksjon 2 av 412 trinn

Nodevelgere og affinitet er en gratis leksjon i Grunnleggende Kubernetes på CoddyKit. Dette er leksjon 2 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Grunnleggende Kubernetes, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Grunnleggende Kubernetes inneholder totalt 4 leksjoner.

Bestem hvor Pods plasseres

Som standard planlegger Kubernetes Pods på enhver tilgjengelig node. Men hva om De trenger mer kontroll?

Noen ganger må Pods kjøre på bestemte noder. Kanskje disse nodene har spesialisert maskinvare eller lisenser, eller befinner seg i bestemte tilgjengelighetssoner.

I denne leksjonen utforsker De hvordan Kubernetes-planleggeren kan styres ved hjelp av Node Selectors og Node Affinity.

Hvorfor styre planleggeren?

Se for Dem at De har en database-Pod som må kjøre på en node med høytytende SSD-er, eller en GPU-intensiv applikasjon som krever bestemt maskinvare.

De vil kanskje også holde bestemte Pods adskilt av hensyn til feiltoleranse, eller sikre at de kjører på noder med bestemte operativsystemer.

Kubernetes tilbyr verktøy for å uttrykke slike planleggingspreferanser.

Noder har etiketter

Før vi kan fortelle Pods hvor de skal kjøre, trenger nodene identiteter! Kubernetes bruker etiketter til å identifisere noder basert på egenskapene deres.

  • Etiketter er nøkkel-verdi-par, for eksempel disk=ssd eller gpu=true.
  • De kan legge til egendefinerte etiketter på nodene med kubectl label nodes <node-name> <key>=<value>.
  • Disse etikettene brukes til å målrette bestemte noder for plassering av Pods.

Node Selectors: Enkelt samsvar

Den enkleste måten å begrense en Pod til et bestemt sett med noder på er å bruke nodeSelector.

Dette er et felt i Pod-spesifikasjonen som tar imot en tabell med nøkkel-verdi-par. Pod-en planlegges bare på noder som har alle disse etikettene.

Det tilsvarer å si: «Jeg trenger en node som er akkurat slik.»

Node Selector i praksis

La oss si at vi har noder med etiketten disk=ssd. Slik får De en Pod til å kjøre bare på disse nodene:

apiVersion: v1
kind: Pod
metadata:
  name: ssd-app
spec:
  containers:
  - name: my-container
    image: nginx
  nodeSelector:
    disk: ssd

Node Affinity: Avansert samsvar

Selv om nodeSelector er enkelt, er det svært strengt. Hva om De ønsker «foretrukne» noder eller mer komplekse samsvarsregler?

Node Affinity gir større fleksibilitet. Det lar Dem uttrykke «myke» eller «harde» krav til at Pods skal plasseres på noder med bestemte etiketter.

Det bruker en kraftigere syntaks med operatorer som In, NotIn, Exists, DoesNotExist, Gt og Lt.

Påkrevd og foretrukket affinitet

Node affinity har to hovedtyper:

  • requiredDuringSchedulingIgnoredDuringExecution: Pod-en må planlegges på en node som samsvarer med reglene. Hvis ingen slik node finnes, blir ikke Pod-en planlagt.
  • preferredDuringSchedulingIgnoredDuringExecution: Planleggeren prøver å finne en node som samsvarer med reglene, men hvis ingen er tilgjengelige, planlegges Pod-en likevel et annet sted. Dette er en «best mulig»-tilnærming.

Påkrevd Node Affinity

Her er en Pod som krever en node med etiketten env=production. Hvis ingen slik node finnes, forblir Pod-en ventende.

apiVersion: v1
kind: Pod
metadata:
  name: prod-app
spec:
  containers:
  - name: my-container
    image: httpd
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: env
            operator: In
            values:
            - production

Pod Affinity: Andre Pods er viktige

Hva om De vil planlegge Pods basert på hvor andre Pods kjører?

  • Pod Affinity: Trekker Pods mot noder der andre Pods med bestemte etiketter allerede kjører. Nyttig for å plassere tjenester som kommuniserer ofte, sammen.
  • Pod Anti-affinity: Holder Pods borte fra noder der andre Pods med bestemte etiketter kjører. Svært nyttig for å spre replikaer over flere noder for høy tilgjengelighet.

Pod Anti-affinity i praksis

Denne manifestfilen sikrer at ingen to Pods med etiketten app=my-web kan planlegges på samme node. Dette forbedrer feiltoleransen.

topologyKey angir domenet som anti-affinity gjelder for (for eksempel node eller sone).

apiVersion: v1
kind: Pod
metadata:
  name: web-app-pod
  labels:
    app: my-web
spec:
  containers:
  - name: web-container
    image: busybox
    command: ["sh", "-c", "echo 'Hello from web-app'; sleep 3600"]
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchLabels:
              app: my-web
          topologyKey: "kubernetes.io/hostname"

Test kunnskapene Deres

De vil sikre at kritiske database-Pods ikke må planlegges på noder med etiketten zone=dev. Hvilken type planleggingsregel vil De bruke for denne strenge ekskluderingen basert på nodeetiketter?

Oppsummering: Planleggingskontroll

Godt jobbet! De har lært effektive metoder for å styre hvor Pods kjører:

  • Node Labels: Nøkkel-verdi-par som identifiserer egenskaper ved noder.
  • Node Selectors: Enkelt og strengt samsvar for å planlegge Pods på noder med bestemte etiketter.
  • Node Affinity: Mer fleksible regler (påkrevd eller foretrukket) for nodevalg, med bruk av operatorer.
  • Pod Affinity/Anti-affinity: Samlokalisering eller separering av Pods basert på hvor andre Pods befinner seg.

Disse verktøyene er avgjørende for å optimalisere ressursbruken, sikre feiltoleranse og dekke spesifikke behov i applikasjonene.

Gratis å komme i gang

Lær deg Grunnleggende Kubernetes med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
12
Leksjoner
48

Ofte stilte spørsmål

Er leksjonen «Nodevelgere og affinitet» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Grunnleggende Kubernetes, inkludert «Nodevelgere og affinitet», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Grunnleggende Kubernetes inneholder totalt 4 leksjoner.

Hva lærer jeg i «Nodevelgere og affinitet»?

Styr hvor Pods planlegges, ved hjelp av nodevelgere og mer uttrykksfulle regler for node- og Pod-affinitet. Du øver på Grunnleggende Kubernetes med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Grunnleggende Kubernetes?

Ingen tidligere erfaring er nødvendig. Grunnleggende Kubernetes på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Nodevelgere og affinitet»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Grunnleggende Kubernetes-leksjonen?

Ja. Alle Grunnleggende Kubernetes-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. Ressursforespørsler og -grenser
  2. Nodevelgere og affinitet
  3. Taints og tolerations
  4. Pod-prioritet og preemption
← Tilbake til Grunnleggende Kubernetes