Visuelt guide til fejlfinding i Kubernetes

Bem. overs.: Denne artikel er en del af de offentligt tilgængelige materialer fra projektet learnk8s, der træner brugen af Kubernetes for virksomheder og individuelle administratorer. I denne vejledning deler Daniele Polencic, projektleder, en visuel instruktionsguide om de skridt, der skal tages ved generelle problemer med applikationer, der kører i K8s-klyngen.

TL;DR: her er et diagram, der kan hjælpe dig med at debugge deployment i Kubernetes:

Flowchart til at finde og løse fejl i klyngen. Den originale (på engelsk) kan findes i PDF og som billede.

Ved deployment af en applikation i Kubernetes er det normalt nødvendigt at definere tre komponenter:

• Deployment — en opskrift på at oprette kopier af applikationen, kaldet pods;
• Service — en intern load balancer, der fordeler trafik til pods;
• Ingress — en beskrivelse af, hvordan trafikken vil nå fra den eksterne verden til Service.

Her er et kort grafisk resumé:

1) I Kubernetes får applikationer trafik fra den eksterne verden gennem to lag af load balancere: intern og ekstern.

2) Den interne load balancer kaldes Service, den eksterne – Ingress.

3) Deployment opretter pods og overvåger dem (de oprettes ikke manuelt).

Lad os antage, at du ønsker at deployere en simpel applikation, som f.eks. Hello World. YAML-konfigurationen for den vil se således ud:

apiVersion: apps/v1
kind: Deployment # <<<
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service # <<<
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress # <<<
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

Definitionen er ret lang, og det er let at blive forvirret over, hvordan komponenterne hænger sammen.

For eksempel:

• Hvornår skal man bruge port 80, og hvornår skal man bruge 8080?
• Skal der oprettes en ny port for hver service for at undgå konflikter?
• Har navnet på labels nogen betydning? Skal de være ens overalt?

Før vi fokuserer på debugging, lad os huske på, hvordan de tre komponenter hænger sammen. Lad os starte med Deployment og Service.

Forholdet mellem Deployment og Service

Du vil blive overrasket, men Deployments og Services er ikke direkte forbundet. I stedet angiver Service direkte til Pods uden om Deployment.

Således er vi interesserede i, hvordan Pods og Services er relateret til hinanden. Husk tre ting:

1. Vælger (selector) for Service skal svare til mindst én label fra Pod.
2. targetPort skal svare til containerPort i containere inden for Pod.
3. port Porten for Service kan være hvilken som helst. Forskellige services kan bruge den samme port, da de har forskellige IP-adresser.

Næste skema præsenterer alt det ovenstående i grafisk form:

1) Antag, at servicen dirigerer trafik til en pod:

2) Når du opretter en pod, skal du angive containerPort for hver container i pods:

3) Når du opretter en service, skal du angive port og targetPort. Men gennem hvilken går forbindelsen til containeren?

4) Gennem targetPort. Det skal svare til containerPort.

5) Antag, at port 3000 er åben i containeren. Så skal værdien targetPort være den samme.

I YAML-filen skal labels og ports / targetPort svare til:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
     labels:  # <<<
        any-name: my-app  # <<<
   spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
       - containerPort: 8080  # <<<
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
   targetPort: 8080  # <<<
 selector:  # <<<
    any-name: my-app  # <<<

Hvad med label track: canary i toppen af Deployment-sektionen? Skal den svare til?

Denne label tilhører deploymenten, og den bruges ikke af servicen til at dirigere trafik. Med andre ord kan den slettes eller tildeles en anden værdi.

Hvad med vælgeren matchLabels?

Den skal altid svare til labels fra Pod,, da den bruges af Deployment til at spore pods.

Antag, at du har foretaget de korrekte ændringer. Hvordan tjekker du dem?

Du kan kontrollere labels for pods med følgende kommando:

kubectl get pods --show-labels

Eller, hvis pods tilhører flere applikationer:

kubectl get pods --selector any-name=my-app --show-labels

Where any-name=my-app — dette er label any-name: my-app.

Har du stadig problemer?

Du kan tilslutte til pod! For dette skal du bruge kommandoen port-forward i kubectl. Den giver mulighed for at oprette forbindelse til servicen og kontrollere forbindelsen.

kubectl port-forward service/<service name> 3000:80

Her:

• service/<service name> — navnet på servicen; i vores tilfælde er det my-service;
• 3000 — den port, der skal åbnes på computeren;
• 80 — den port, der er angivet i feltet port for servicen.

Hvis forbindelsen kunne etableres, så er indstillingerne korrekte.

Hvis forbindelsen ikke kunne oprettes, er der et problem med etiketterne, eller portene stemmer ikke overens.

Forbindelsen mellem Service og Ingress

Det næste skridt for at sikre adgang til applikationen involverer opsætning af Ingress. Ingress skal vide, hvordan man finder servicen, derefter finde pods og dirigere trafik til dem. Ingress finder den nødvendige service ud fra navn og åben port.

I beskrivelsen af Ingress og Service skal to parametre være ens:

1. servicePort i Ingress skal svare til parameteren port i Service;
2. serviceName i Ingress skal svare til feltet name i Service.

Følgende skema opsummerer tilslutningen af porte:

1) Som du allerede ved, lytter Service til en given port:

2) Ingress har en parameter, der kaldes servicePort:

3) Denne parameter (servicePort) skal altid svare til port i definitionen af Service:

4) Hvis porten i Service er sat til 80, skal servicePort også være lig med 80:

I praksis er det vigtigt at være opmærksom på følgende linjer:

apiVersion: v1
kind: Service
metadata:
 name: my-service  # <<<
spec:
  ports:
 - port: 80  # <<<
   targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
       serviceName: my-service  # <<<
       servicePort: 80  # <<<
     path: /

Hvordan kan man kontrollere, om Ingress fungerer?

Man kan bruge metoden med kubectl port-forward, men i stedet for at forbinde til servicen skal man forbinde til Ingress-controlleren.

Først skal du finde navnet på pod'en med Ingress-controlleren:

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

Find Ingress-pod'en (den kan tilhøre et andet navnerum) og udfør kommandoen describe, for at finde portnumrene:

kubectl describe pod nginx-ingress-controller-6fc5bcc 
--namespace kube-system 
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

Endelig skal du forbinde til pod'en:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

Nu, hver gang du sender en forespørgsel til port 3000 på din computer, vil den blive videresendt til port 80 på pod'en med Ingress-controlleren. Ved at gå til http://localhost:3000, skal du kunne se siden oprettet af applikationen.

Resume om porte

Lad os endnu en gang huske, hvilke porte og etiketter der skal stemme overens:

1. Vælgeren i definitionen af Service skal svare til etiketten på pod'en;
2. targetPort i definitionen af Service skal svare til containerPort containeren inde i pod'en;
3. port I definitionen af Service kan være hvilken som helst. Forskellige tjenester kan bruge den samme port, da de har forskellige IP-adresser;
4. servicePort Ingress'ens skal matche port i definitionen af Service;
5. Navnet på tjenesten skal matche feltet serviceName i Ingress.

Desværre er det ikke nok at vide, hvordan man korrekt strukturerer YAML-konfigurationen.

Hvad sker der, når noget går galt?

Måske starter pod'en ikke, eller den falder.

3 trin til fejlfinding af applikationer i Kubernetes

Før du begynder at debugge deployment'en, er det nødvendigt at have en god forståelse af, hvordan Kubernetes fungerer.

Da hver K8s-applikation har tre komponenter, skal du debugge dem i en bestemt rækkefølge, startende fra bunden.

1. Først skal du sikre dig, at pod'erne fungerer, og derefter …
2. Kontrollerer, om tjenesten leverer trafik til pod'erne, og derefter …
3. Kontrollerer, om Ingress er korrekt konfigureret.

Visualisering:

1) Begynd at lede efter problemer fra bunden. Først skal du kontrollere, at pod'erne har status Klar og Kørende:

2) Hvis pod'erne er klar (Klar), skal du finde ud af, om tjenesten distribuerer trafik mellem pod'erne:

3) Endelig skal du analysere forbindelsen mellem tjenesten og Ingress:

1. Fejlfinding af pod'er

I de fleste tilfælde er problemet relateret til pod'en. Sørg for, at pod'erne er angivet som Klar og Kørende. Dette kan kontrolleres med kommandoen:

kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

I outputtet fra ovenstående kommando er den sidste pod angivet som Kørende og Klar, men for de to andre er det ikke tilfældet.

Hvordan forstår man, hvad der gik galt?

Der er fire nyttige kommandoer til fejlfinding af pod'er:

1. kubectl logs giver mulighed for at hente logfiler fra containere i pod'en;
2. kubectl describe pod giver mulighed for at se en liste over begivenheder relateret til pod'en;
3. kubectl get pod giver mulighed for at få YAML-konfigurationen for pod'en gemt i Kubernetes;
4. kubectl exec -ti bash giver mulighed for at starte en interaktiv kommandolinje i en af containerne i pod'en

Hvilken skal man vælge?

Problemet er, at der ikke er en universel kommando. Du skal bruge en kombination af dem.

Typiske problemer med pod'er

Der er to hovedtyper af fejl i pod'er: opstartsfejl (startup) og runtime-fejl.

Opstartsfejl:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• UgyldigBilledeNavn

Runtime-fejl:

• CrashLoopBackOff
• KørContainerFejl
• DræbContainerFejl
• BekræftIkkeRodBrugerFejl
• KørInitContainerFejl
• OpretPodSandboxFejl
• KonfigPodSandboxFejl
• DræbPodSandboxFejl
• OpsætteNetværkFejl
• NedbrydeNetværkFejl

Nogle fejl forekommer oftere end andre. Her er nogle af de mest almindelige fejl og måder at løse dem på.

ImagePullBackOff

Denne fejl opstår, når Kubernetes ikke kan hente et billede til en af pod’ens containere. Her er tre af de mest almindelige årsager til dette:

1. Billednavnet er forkert angivet – for eksempel har du lavet en fejl i det, eller billedet eksisterer ikke;
2. En ikke-eksisterende tag er angivet for billedet;
3. Billedet opbevares i et privat register, og Kubernetes har ikke de nødvendige tilladelser til at få adgang til det.

De to første årsager er lette at løse – du skal blot rette billednavnet og taggen. I tilfælde af den sidste skal du indtaste legitimationsoplysninger til det private register i Secret og tilføje referencer til det i pod’erne. I Kubernetes-dokumentationen er der et eksempel på, hvordan dette kan gøres.

CrashLoopBackOff

Kubernetes viser en fejl CrashLoopBackOff, hvis containeren ikke kan starte. Dette sker normalt, når:

1. Der er en fejl i applikationen, der forhindrer den i at starte;
2. Container det er forkert konfigureret;
3. Liveness-testen er mislykket for mange gange.

Det er nødvendigt at forsøge at få fat i loggene fra containeren for at finde ud af årsagen til dens nedbrud. Hvis adgangen til loggene er svær, da containeren genstarter for hurtigt, kan følgende kommando bruges:

kubectl logs  --previous

Den viser fejlmeddelelser fra den tidligere inkarnation af containeren.

KørContainerFejl

Denne fejl opstår, når containeren ikke er i stand til at starte. Den svarer til øjeblikket før applikationen starter. Årsagen til dette er normalt en forkert konfiguration, såsom:

• forsøger at montere et ikke-eksisterende volumen, som ConfigMap eller Secrets;
• forsøger at montere et read-only volumen som read-write.

Til analyse af sådanne fejl er kommandoen kubectl describe pod.

Pod’ene er i Pending-status

Efter oprettelsen forbliver pod’en i status Pending.

Hvorfor sker dette?

Her er mulige årsager (jeg forudsætter, at planlæggeren fungerer korrekt):

1. Der er ikke nok ressourcer i klyngen, såsom beregningskraft og hukommelse, til at starte pod’en.
2. I det relevante navnerum er der oprettet et objekt ResourceQuota Og oprettelsen af en pod vil føre til, at navnerummet overskrider kvoten.
3. Pod er knyttet til Pending PersistentVolumeClaim.

I dette tilfælde anbefales det at bruge kommandoen kubectl describe og tjekke sektionen Begivenheder:

kubectl describe pod

I tilfælde af fejl relateret til ResourceQuotas, anbefales det at se gennem klyngens logs med kommandoen

kubectl get events --sort-by=.metadata.creationTimestamp

Pods er ikke i Ready tilstand

Hvis pod'en er markeret som Kørende, men ikke er i tilstanden Klar, betyder det, at pod'ens beredskabsprøve (readiness probe) mislykkes.

Når dette sker, opretter pod'en ikke forbindelse til tjenesten, og trafikken faktisk tilgår den ikke. Fejlen i beredskabsprøven skyldes problemer i applikationen. I så fald skal sektionen Begivenheder i udgangen af kommandoen kubectl describe.

2. Diagnostik af tjenester

Hvis pods er markeret som Kørende og Klar, men der stadig ikke er noget svar fra applikationen, skal tjenesteindstillingerne kontrolleres.

Tjenester håndterer trafikdirigering til pods baseret på deres labels. Derfor er det første, man skal gøre, at tjekke, hvor mange pods der arbejder med tjenesten. Dette kan gøres ved at kontrollere endpoints i tjenesten:

kubectl describe service  | grep Endpoints

Endpoint er et par værdier af typen <IP-адрес:порт>, og der skal være mindst et sådant par i udgangen (det vil sige, at mindst én pod arbejder med tjenesten).

Hvis sektionen Endpoints er tom, er der to mulige scenarier:

1. der er ingen pod's med den rigtige label (tip: tjek om navnerummet er korrekt valgt);
2. der er en fejl i tjenestens labels i vælgeren.

Hvis du ser en liste over endpoints, men stadig ikke kan få adgang til applikationen, er den sandsynlige skyldner en fejl i targetPort den beskrivelse af tjenesten.

Hvordan tjekker man, om tjenesten fungerer?

Uanset hvilken type tjeneste kan man bruge kommandoen kubectl port-forward til at oprette forbindelse til den:

kubectl port-forward service/ 3000:80

Her:

• <service-name> — navn på tjenesten;
• 3000 — porten, som du åbner på computeren;
• 80 — porten på servicesiden.

3. Diagnostik af Ingress

Hvis du er nået hertil, så:

• pods er markeret som Kørende og Klar;
• tjenesten distribuerer trafik til pods med succes.

Men du kan stadig ikke "nå" applikationen.

Det betyder, at Ingress-controllernes opsætning sandsynligvis er forkert. Da Ingress-controlleren er en ekstern komponent i klyngen, er der forskellige fejlfindingsmetoder afhængigt af dens type.

Men før du bruger specielle værktøjer til at konfigurere Ingress, kan du gøre noget ganske simpelt. Ingress bruger serviceName og servicePort til at oprette forbindelse til tjenesten. Det er nødvendigt at kontrollere, om de er korrekt konfigureret. Dette kan gøres med kommandoen:

kubectl describe ingress

Hvis kolonnen Backend er tom, er der stor sandsynlighed for en fejl i konfigurationen. Hvis backend'en er på plads, men du stadig ikke kan tilgå applikationen, kan problemet være relateret til:

• indstillingerne for tilgængelighed af Ingress fra internettet;
• indstillingerne for tilgængelighed af klyngen fra internettet.

For at finde problemer med infrastrukturen kan du forbinde direkte til Ingress-pod'en. Find først pod'en for Ingress-controlleren (den kan være i et andet navnerum):

kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

Brug kommandoen describe, for at sætte porten:

kubectl describe pod nginx-ingress-controller-6fc5bcc
--namespace kube-system 
 | grep Ports

Endelig skal du forbinde til pod'en:

kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

Nu vil alle forespørgsler til port 3000 på computeren blive omdirigeret til port 80 af pod'en.

Fungerer det nu?

• Hvis ja, så er der et problem med infrastrukturen. Det er nødvendigt at finde ud af, hvordan trafikken rutes til klyngen.
• Hvis nej, så er problemet med Ingress-controlleren.

Hvis du ikke kan få Ingress-controlleren til at fungere, skal den fejlfinding.

Der findes mange varianter af Ingress-controllere. De mest populære er Nginx, HAProxy, Traefik og andre. (mere om de eksisterende løsninger, se vores gennemgang — red. anm.) Det anbefales at følge fejlfindingguiden i dokumentationen for den relevante controller. Da Ingress Nginx er den mest populære Ingress-controller, har vi inkluderet nogle tips til løsning af relaterede problemer i artiklen.

Fejlfinding af Ingress Nginx-controlleren

Projektet Ingress-nginx har en officiel plugin til kubectl. Kommandoen kubectl ingress-nginx kan bruges til:

• analyse af logs, backends, certifikater osv.;
• tilslutning til Ingress;
• undersøgelse af den aktuelle konfiguration.

De følgende tre kommandoer vil hjælpe dig med dette:

• kubectl ingress-nginx lint — tjekker nginx.conf;
• kubectl ingress-nginx backend — undersøger backend (på samme måde som kubectl describe ingress);
• kubectl ingress-nginx logs — tjekker logs.

Bemærk: i nogle tilfælde kan det være nødvendigt at angive det korrekte navnerum for Ingress-controlleren med flaget --namespace.

CV

Fejlfinding i Kubernetes kan være en udfordring, hvis man ikke ved, hvor man skal starte. Problemet bør altid angrebet fra bunden opad: begynd med pod’ene, og gå derefter videre til tjenesten og Ingress. De debugmetoder, der beskrives i artiklen, kan også anvendes på andre objekter såsom:

• fejlende Job’ere og CronJob’ere;
• StatefulSet’ere og DaemonSet’ere.

Jeg vil gerne takke Gergely Risko, Daniel Weibel og Charles Christyraj for værdifulde bemærkninger og tilføjelser.

P.S. fra oversætteren

Læs også på vores blog:

• «kubectl-debug plugin til debugging i Kubernetes pods»;
• «6 interessante systemfejl ved brug af Kubernetes [og hvordan man løser dem]»;
• «Værktøjer til udviklere af applikationer, der køres i Kubernetes»;
• «6 praktiske historier fra vores SRE-hverdag ».

Kilde: habr.com