Pod-livssyklus og tilstander

En Pod er i fasen Pending når den er godkjent av Kubernetes API-serveren, men én eller flere av containerne ennå ikke er opprettet eller konfigurert.

Vanlige årsaker er:

• Container-imaget lastes fortsatt ned.
• Klyngen har ikke nok ressurser (CPU/minne) til å planlegge Pod-en.
• Volumer klargjøres eller monteres fortsatt.

La oss se på et eksempel. Hvis du prøver å distribuere en Pod med et image som ikke finnes, kan den bli stående i «Pending» eller vise en feil ved henting av imaget.

Her er et eksempel på en Pod-definisjon:

apiVersion: v1
kind: Pod
metadata:
  name: pending-pod-demo
spec:
  containers:
  - name: my-container
    image: non-existent-image:latest
    ports:
    - containerPort: 80

For å kontrollere statusen bruker du kubectl get pod. Du kan se noe som dette:

$ kubectl get pod pending-pod-demo
NAME               READY   STATUS         RESTARTS   AGE
pending-pod-demo   0/1     ErrImagePull   0          5s

ErrImagePull viser at imaget ikke kunne hentes, slik at Pod-en ikke når tilstanden Running.

Fasen Running betyr at Pod-en er bundet til en node, og at alle containerne er opprettet. Minst én container kjører eller er i ferd med å starte eller starte på nytt.

Det er viktig å merke seg at en Pod i tilstanden Running ikke automatisk betyr at applikasjonen inni er frisk eller fungerer som den skal. Det betyr bare at containerne er aktive.

Her er en standarddefinisjon av en Pod for en Nginx-webserver. Når De har tatt denne i bruk, skal Pod-en raskt gå over i tilstanden «Running».

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

Når den er distribuert, vil kubectl get pod vise:

$ kubectl get pod nginx-pod
NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          10s

1/1 i READY bekrefter at én container er klar, av én som er definert.

Disse fasene representerer avslutningstilstandene for en Pod:

• Succeeded: En Pod går inn i denne fasen når alle containerne i den er avsluttet uten feil og ikke vil bli startet på nytt. Dette er vanlig for Pods som kjører engangsoppgaver eller batchjobber.
• Failed: En Pod er i fasen Failed når alle containerne i Pod-en er avsluttet, og minst én container ble avsluttet med feil (for eksempel med en statuskode som ikke er null).

Hvis De forstår disse fasene, blir det enklere å diagnostisere fullføring av jobber eller feil i applikasjoner.

Fasen Unknown betyr at det ikke var mulig å fastslå tilstanden til Pod-en. Dette er en sjelden, men kritisk fase.

Det skjer vanligvis når Kubelet (agenten) på noden der Pod-en kjører, slutter å kommunisere med Kubernetes API-serveren. Det kan skyldes et nettverksproblem, en Kubelet som har krasjet, eller et problem med selve noden.

Selv om Pods har overordnede faser, har de enkelte containerne i en Pod også mer detaljerte tilstander. Disse tilstandene påvirker Pod-ens overordnede fase direkte:

• Waiting: Containeren venter på å starte. Årsaker kan være henting av et image, tildeling av ressurser eller venting på at init-containere skal bli ferdige.
• Running: Containeren kjører aktivt uten problemer.
• Terminated: Containeren er ferdig med kjøringen. Den kan ha blitt fullført uten feil eller ha mislyktes.

De har lært at Kubernetes Pods går gjennom bestemte faser: Pending, Running, Succeeded, Failed og Unknown. Disse fasene gir et overordnet bilde av en Pod-ens driftsstatus.

Vi har også sett på individuelle containertilstander (Waiting, Running og Terminated), som bidrar til Pod-ens overordnede fase. Det er viktig å overvåke disse tilstandene med kubectl get pod og kubectl describe pod (som De skal utforske mer senere) for å forstå helsetilstanden til applikasjonen.

Deretter skal vi se nærmere på avanserte Pod-mønstre og utforske hvordan De kan kjøre flere samlokaliserte containere i én Pod ved hjelp av sidecar-mønsteret!