Udhëzues vizual për diagnostikimin e defekteve në Kubernetes

Shën. përkth.: Kyçti i këtij artikulli është në përbërje të materialeve të publikuara në akses të lirë nga projekti learnk8s, duke edukuar për përdorimin e Kubernetes për kompani dhe administratorë individualë. Në të, Daniele Polencic, drejtuesi i projektit, ndan një udhëzues të qartë mbi hapat që duhen ndjekur në rast se hasni në probleme të përgjithshme me aplikacionet e ekzekutuara në klasterin K8s.

TL;DR: ja skema që do t'ju ndihmojë të diagnostikoni vendosjen në Kubernetes:

Diagrami për gjetjen dhe rregullimin e gabimeve në klaster. Në origjinal (në anglisht) ajo është e disponueshme në PDF dhe si një imazh.

Kur vendosni një aplikacion në Kubernetes, zakonisht është e nevojshme të përcaktoni tre komponente:

• Zhvillimi — një recetë për krijimin e kopjeve të aplikacionit, të quajtura pod’a;
• Shërbimi — një balansues ngarkese të brendshëm, që shpërndan trafikun midis pod’ave;
• Ingress — një përshkrim se si do të kalojë trafiku nga bota e jashtme në Shërbimin.

Ja një përmbledhje grafike:

1) Në Kubernetes aplikacionet marrin trafik nga bota e jashtme përmes dy niveleve të balansuesve të ngarkesës: të brendshëm dhe të jashtëm.

2) Balansuesi i brendshëm quhet Shërbim, ndërsa ai i jashtëm – Ingress.

3) Vendosja krijon pod’a dhe i monitoron ato (ato nuk krijohen manualisht).

Supozoni se dëshironi të vendosni një aplikacion të thjeshtë si Përshëndetje Botë. Konfiguracioni YAML për të do të duket si vijon:

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: /

Përkufizimi është mjaft i gjatë dhe është e lehtë të humbasësh se si janë të lidhura komponentët.

Për shembull:

• Kur duhet të përdoret porta 80 dhe kur 8080?
• A duhet të krijohet një port i ri për çdo shërbim, që të mos ndodhin konflikte?
• A kanë rëndësi emrat e etiketimeve? A duhet të jenë të njëjta kudo?

Para se të përqendrohemi në diagnostikimin, le të kujtojmë se si janë të lidhura tre komponentët. Le të fillojmë me Vendosjen dhe Shërbimin.

Lidhja midis Vendosjes dhe Shërbimit

Do të habiteni, por Vendosjet dhe Shërbimet nuk janë aspak të lidhura. Në vend të kësaj, Shërbimi tregon drejtpërdrejt për pod’at, duke anashkaluar Vendosjen.

Pra ndaj, na intereson si lidhen midis tyre Pod’ët dhe Shërbimet. Duhet të mbani mend tri gjëra:

1. Selekori (selector) i Shërbimit duhet të përputhet me të paktën një etiketë të Pod’it.
2. targetPort duhet të përputhet me containerPort të kontejnerit brenda Pod’it.
3. port Porti i Shërbimit mund të jetë çfarëdo. Shërbime të ndryshme mund të përdorin të njëjtin port, pasi kanë adresa IP të ndryshme.

Skema e mëposhtme paraqet të gjitha të mësipërmet në një formë grafike:

1) Le të supozojmë se shërbimi drejton trafik në një pod:

2) Kur krijohet pod’i, duhet të specifikohet containerPort për çdo kontejner në pod’ët:

3) Kur krijohet shërbimi, duhet të tregoni port dhe targetPort. Por përmes cilit kalon lidhja me kontejnerin?

4) Nëpërmjet targetPort. Ai duhet të përputhet me containerPort.

5) Supozoni se porti 3000 është i hapur në kontejner. Atëherë vlera targetPort duhet të jetë e njëjtë.

Në skedarin YAML, etiketat dhe ports / targetPort duhet të përputhen:

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  # <<<

Por çfarë ndodh me etiketën track: canary në pjesën më të lartë të seksionit Deployment? A duhet të përputhet?

Kjo etiketë i takon vendosjes dhe nuk përdoret nga shërbimi për të drejtuar trafik. Me fjalë të tjera, mund ta fshini ose t’i jepni një vlerë tjetër.

Çfarë ndodh me selektorin matchLabels?

Ai gjithmonë duhet të përputhet me etiketat e Pod’it, pasi përdoret nga Deployment’i për ndjekjen e pod’ëve.

Supozoni se keni bërë ndryshimet e sakta. Si t’i verifikoni ato?

Kontrolloni etiketat e pod’ëve me komandën e mëposhtme:

kubectl get pods --show-labels

Ose, nëse pod’ët i takojnë disa aplikacionesh:

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

Ku any-name=my-app — kjo është një etiketë any-name: my-app.

Keni akoma vështirësi?

Mund të lidhesh me pod’in! Për këtë duhet të përdorësh komandën port-forward në kubectl. Ajo lejon lidhjen me shërbimin dhe kontrollin e lidhjes.

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

Këtu:

• service/<service name> — emri i shërbimit; në rastin tonë është my-service;
• 3000 — porti që duhet të hapet në kompjuter;
• 80 — porti i specifikuar në fushën port të shërbimit.

Nëse ka filluar lidhja, atëherë konfigurimet janë të sakta.

Nëse nuk arritët të shtoni lidhjen, do të thotë se problemi qëndron me etiketat ose portet nuk përputhen.

Lidhja midis Shërbimit dhe Ingress-it

Hapi tjetër për të siguruar aksesin në aplikacion është konfigurimi i Ingress-it. Ingress duhet të dijë si të gjejë shërbimin, pastaj të gjejë pod-ët dhe të drejtojë trafikun tek ta. Ingress e gjen shërbimin e nevojshëm sipas emrit dhe portit të hapur.

Në përshkrimin e Ingress-it dhe Shërbimit duhet të përputhen dy parametra:

1. servicePort në Ingress duhet të përputhet me parametrin port në Shërbim;
2. serviceName në Ingress duhet të përputhet me fushën emri në Shërbim.

Diagrami i mëposhtëm përmbledh lidhjen e porteve:

1) Siç e dini, Shërbimi dëgjon një port:

2) Ingress-i ka një parametr të quajtur servicePort:

3) Ky parametër (servicePort) gjithmonë duhet të përputhet me port në definicionin e Shërbimit:

4) Nëse në Shërbim është caktuar porta 80, atëherë është e nevojshme që servicePort të jetë gjithashtu e barabartë me 80:

Në praktikë duhet të jepni vëmendje ndaj këtyre rreshtave:

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: /

Si të kontrolloni nëse Ingress funksionon?

Mund të përdorni metodën me kubectl port-forward, por në vend të shërbimit duhet të lidheni me kontrollorin e Ingress.

Së pari, duhet të zbuloni emrin e pod-it me kontrollorin e Ingress:

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

Gjeni pod-in e Ingress-it (ai mund të përkasë në një hapësirë tjetër emri) dhe ekzekutoni komandën përshkruaj, për të zbuluar numrat e porteve:

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

Së fundi, lidheni me pod-in:

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

Tani çdo herë që dërgoni një kërkesë në portin 3000 në kompjuterin tuaj, ajo do të redirektohet në portin 80 të pod-it me kontrollorin e Ingress. Pasi të kaloni në http://localhost:3000, duhet të shihni faqen e krijuar nga aplikacioni.

Përmbledhje mbi portat

Le të kujtojmë edhe një herë se cilat porte dhe etiketa duhet të përputhen:

1. Seletori në definimin e Shërbimit duhet të përputhet me etiketën e pod-it;
2. targetPort në definimin e Shërbimit duhet të përputhet me containerPort kontraktin brenda pod-it;
3. port Në përcaktimin e Shërbimit mund të jetë çfarëdo. Shërbime të ndryshme mund të përdorin të njëjtin port, pasi kanë adresa IP të ndryshme;
4. servicePort Ingress'it duhet të korrespondojë me port në përcaktimin e Shërbimit;
5. Emri i shërbimit duhet të përputhet me fushën serviceName në Ingress.

Fatkeqësisht, nuk mjafton të dish si ta strukturosh siç duhet konfigurimin YAML.

Çfarë ndodh kur diçka nuk shkon siç duhet?

Mund të ndodhë që pod'i nuk po fillon ose po bie.

3 hapa për diagnostikimin e problemeve në aplikacionet në Kubernetes

Para se të fillosh për të debuguar deployment'in, është e nevojshme të kesh një njohuri të mirë se si funksionon Kubernetes.

Duke qënë se çdo aplikacion e shkarkuar në K8s ka tre komponentë, duhen debuguar në një renditje të caktuar, duke filluar nga poshtë.

1. Së pari, duhet të sigurohemi që pod'ët po funksionojnë, pastaj...
2. Kontrollo nëse shërbimi po dërgon trafik te pod'ët, pastaj...
3. Kontrollo nëse Ingress është konfiguruar siç duhet.

Përfaqësimi vizual:

1) Duhet të fillosh kërkimin e problemeve nga fundi. Së pari, kontrollo nëse pod'ët kanë statuse Gati dhe Running:

2) Nëse pod'ët janë të gatshëm (Gati), duhen zbuluar nëse shërbimi po ndan trafik ndërmjet pod'ëve:

3) Së fundi, duhet të analizosh lidhjen midis shërbimit dhe Ingress'it:

1. Diagnostikimi i pod'ëve

Në shumicën e rasteve, problemi është i lidhur me pod'in. Sigurohu që pod'ët të shfaqen si Gati dhe Running. Mund ta kontrollosh këtë me komandën:

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

Në rezultatin e komandës të mësipërme, pod'i i fundit shfaqet si Running dhe Gati, por për dy të tjerët nuk është kështu.

Si të kuptosh se çka ka shkuar gabim?

Ka katër komanda të dobishme për diagnostikimin e pod'ëve:

1. kubectl logs lejon të nxjerrësh log-et nga kontejnerët në pod;
2. kubectl describe pod lejon të shikosh listën e ngjarjeve të lidhura me pod'in;
3. kubectl get pod lejon të marrësh konfigurimin YAML të pod'it, e cila ruhet në Kubernetes;
4. kubectl exec -ti bash lejon të ekzekutosh një shell interaktive komandash në njërin nga kontejnerët e pod'it

Cilën prej tyre të zgjedhim?

Çështja është se nuk ka një komandë universale. Duhet të përdoren kombinime të tyre.

Problemet tipike të pod'ëve

Ka dy lloje kryesore të gabimeve të pod'ëve: gabime gjatë fillimit (startup) dhe gabime gjatë funksionimit (runtime).

Gabime gjatë fillimit:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• Emri i pamjaftueshëm i imazhit

Gabime në ekzekutim:

• CrashLoopBackOff
• Gabim në ekzekutimin e konteinerit
• Gabim në vrasjen e konteinerit
• Gabim në verifikimin e jo-root
• Gabim në ekzekutimin e konteinerit fillestar
• Gabim në krijimin e sandbox-it të pod-it
• Gabim në konfigurimin e sandbox-it të pod-it
• Gabim në vrasjen e sandbox-it të pod-it
• Gabime të caktuara ndodhin më shpesh se të tjera. Ja disa nga gabimet më të zakonshme dhe mënyrat për t'i zgjidhur ato.
• ImagePullBackOff

Ky gabim ndodh kur Kubernetes nuk mund të marrë imazhin për një nga konteinerët e pod-it. Ja tre arsyet më të zakonshme për këtë:

Emri i imazhit është gabim — për shembull, keni bërë një gabim në të, ose imazhi nuk ekziston;

Teg i imazhit që nuk ekziston është specifikuar;

1. Imazhi ndodhet në një regjistër privat dhe Kubernetes nuk ka autorizim për t'u qasur atij.
2. Dy arsyet e para janë të lehta për t'u zgjidhur — mjafton të korrigjoni emrin e imazhit dhe tegun. Për arsye të fundit, duhet të shtoni kredencialet e regjistrit privat në Secret dhe t'i shtoni ato në pod-e. Në dokumentacionin e Kubernetes
3. ka një shembull

se si mund të bëhet kjo. Kubernetes tregon një gabim , nëse konteineri nuk mund të fillohet. Kjo ndodh zakonisht kur:

CrashLoopBackOff

Ka një gabim në aplikacion që nuk e lejon atë të fillohet; CrashLoopBackOffështë konfiguruar gabim

1. Testi Liveness ka dështuar shumë herë.
2. Konteineri Duhet të provoni të arrini log-et nga konteineri për të zbuluar shkakun e dështimit të tij. Nëse është e vështirë të merrni qasje në log-et pasi konteineri rimerr shumë shpejt, mund të përdorni komandën e mëposhtme:;
3. kubectl logs --previous

Ajo jep mesazhet e gabimeve nga rrethana të mëparshme të konteinerit.

Ky gabim ndodh kur konteineri nuk është në gjendje të fillohet. Kjo ndodh përpara fillimit të aplikacionit. Zakonisht shkaku është një konfigurim i gabuar, për shembull:

përpjekje për të montuar një volum që nuk ekziston, si ConfigMap ose Secrets;

Gabim në ekzekutimin e konteinerit

përpjekje për të montuar një volum të tipit read-only si read-write.

• Për analizimin e këtyre gabimeve, komanda
• kubectl describe pod

Pod-et janë në gjendjen Pending Pas krijimit, pod-i mbetet në gjendjen.

Pending

Pse ndodh kjo? Ja disa mundësi (po supozoj se planifikuesi po funksionon normalisht):.

Në klaster ka mungesë burimesh, si kapaciteti përpunues dhe memories, për të filluar pod-in.

Në hapësirën e duhur të emrit është vendosur një objekt

1. ResourceQuota
2. Objekti është vendosur në hapësirën përkatëse të emrave ResourceQuota krijimi i pod-it do të shkaktojë që hapësira emrit të kalojë përtej kuotës.
3. Pod-i është lidhur me Pending PersistentVolumeClaim.

Në këtë rast, rekomandohet të përdorni komandën kubectl describe dhe të verifikoni seksionin Ngjarjet:

kubectl describe pod

Në rast gabimesh që lidhen me Kufijtë e Burimeve, rekomandohet të shihni logët e klasterit duke përdorur komandën

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

Pod-et nuk janë në gjendjen Ready

Nëse pod-i është Running, por nuk është në gjendjen Gati, atëherë kontrolli i gatishmërisë (readiness probe) dështoi.

Kur ndodh një gjë e tillë, pod-i nuk lidhet me shërbimin dhe trafik nuk i dërgohet. Dështimi i provës së gatishmërisë shkaktohet nga probleme në aplikacion. Në këtë rast, për të gjetur gabimin, duhet të analizoni seksionin Ngjarjet në daljen e komandës kubectl describe.

2. Diagnoza e shërbimeve

Nëse pod-et janë Running dhe Gati, por ende nuk merrni përgjigje nga aplikacioni, duhet të kontrolloni konfigurimet e shërbimit.

Shërbimet trajtojnë rregullimin e trafikut tek pod-et në varësi të etiketave të tyre. Prandaj, gjëja e parë që duhet bërë është të kontrolloni se sa pod-e punojnë me shërbimin. Për këtë, mund të kontrolloni endpoint-et në shërbim:

kubectl describe service  | grep Endpoints

EndPoint është një çift vlerash formati <IP-адрес:порт>, dhe në daljen duhet të ketë të paktën një çift të tillë (dmth. me shërbimin punon të paktën një pod).

Nëse seksioni Endpoins është bosh, ka dy mundësi:

1. nuk ka asnjë pod me etiketën e saktë (këshillë: kontrolloni nëse namespace është i zgjedhur siç duhet);
2. ka një gabim në etiketat e shërbimit në selektor.

Nëse shihni një listë endpoint-esh, por ende nuk mund të qaseni në aplikacion, atëherë fajin e mundshëm e ka një gabim në targetPort përshkrimin e shërbimit.

Si të kontrolloni funksionalitetin e shërbimit?

Pavarësisht nga lloji i shërbimit, mund të përdorni komandën kubectl port-forward për t'u lidhur me të:

kubectl port-forward service/ 3000:80

Këtu:

• <service-name> — emri i shërbimit;
• 3000 — porta që po hapni në kompjuterin tuaj;
• 80 — porta në anën e shërbimit.

3. Diagnoza e Ingress

Nëse e keni lexuar deri këtu, atëherë:

• pod-et janë Running dhe Gati;
• shërbimi ndan me sukses trafik mes pod-eve.

Megjithatë, ende nuk mund të 'arrini' në aplikacion.

Kjo do të thotë se, me sa duket, është konfigurimi i gabuar i kontrolluesit të Ingress. Duke qenë se kontrolluesi i Ingress është një komponent i jashtëm në klaster, ka metoda të ndryshme diagnostikimi në varësi të llojit të tij.

Por antes se të përdorim mjete speciale për konfigurimin e Ingress-it, mund të bëjmë diçka shumë të thjeshtë. Ingress përdor serviceName dhe servicePort për t'u lidhur me shërbimin. Është e nevojshme të kontrolloni nëse janë konfigurime të sakta. Këtë mund ta bëni me komandën:

kubectl describe ingress

Nëse kolona Backend është e zbrazët, ka një probabilitet të lartë për një gabim në konfigurim. Nëse backend-et janë në vend, por ende nuk ka qasje në aplikacion, problemi mund të lidhet me:

• konfigurimet e aksesit të Ingress-it nga Interneti publik;
• konfigurimet e aksesit të klasterit nga Interneti publik.

Për të zbuluar problemet me infrastrukturën, mund të lidheni direkt me pod-in e Ingress-it. Për këtë, së pari gjeni pod-in e kontrolluesit të Ingress-it (ai mund të jetë në një hapësirë tjetër emri):

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

Përdorni komandën përshkruaj, për të vendosur portin:

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

Së fundi, lidheni me pod-in:

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

Tani të gjitha kërkesat në portin 3000 në kompjuterin tuaj do të redirektohen në portin 80 të pod-it.

A punon tani?

• Nëse po, atëherë problemi është me infrastrukturën. Është e nevojshme të kuptoni se si bëhet rrugëzimi i trafikut në klaster.
• Nëse jo, atëherë problemi është me kontrolluesin e Ingress-it.

Nëse nuk mund ta bëni të funksionojë kontrolluesin e Ingress-it, do të duhet ta debuggoni.

Ka shumë lloje kontrolluesish Ingress. Më të njohurit janë Nginx, HAProxy, Traefik etj. (më shumë rreth zgjidhjeve ekzistuese shihni në përmbledhjen tonë — shën. përkth.) Duhet të përdorni udhëzuesin për zgjidhjen e problemeve në dokumentacionin përkatës të kontrolluesit. Duke qenë se Ingress Nginx është kontrolluesi më i njohur i Ingress-it, ne përfshijmë në artikull disa këshilla për të zgjidhur problemet e lidhura me të.

Debugging i kontrolluesit Ingress Nginx

Projekti Ingress-nginx ka një plugin zyrtar për kubectl. Komanda kubectl ingress-nginx mund të përdoret për:

• analizimin e logëve, backend-eve, certifikatat etj.;
• lidhen me Ingress-in;
• shikimin e konfiguracionit aktual.

Tre komandat e mëposhtme do t'ju ndihmojnë në këtë:

• kubectl ingress-nginx lint — kontrollon nginx.conf;
• kubectl ingress-nginx backend — shqyrton backend-in (analogjia me kubectl describe ingress);
• kubectl ingress-nginx logs — kontrollon logët.

Vini re: në disa raste, mund të kërkohet të jepni hapësirën e saktë të emrit për kontrolluesin e Ingress-it me përdorimin e flamurit --namespace.

CV

Diagnostika në Kubernetes mund të jetë një detyrë e vështirë nëse nuk dini nga të filloni. Problemi duhet të trajtohet gjithmonë sipas parimit "nga poshtë lart": filloni me pod'ët, pastaj kaloni te shërbimi dhe Ingress. Metodat e depurimit të përshkruara në këtë artikull mund të aplikohen gjithashtu në objekte të tjera, si:

• job'ët dhe CronJob'ët që nuk funksionojnë;
• StatefulSet'ët dhe DaemonSet'ët.

Shpreh falënderime Gergely Risko, Daniel Weibel dhe Charles Christyraj për vërejtjet dhe shtesat e vyera.

P.S. nga përkthyesi

Lexoni gjithashtu në blogun tonë:

• «Plugini kubectl-debug për debugging në pod’et e Kubernetes»;
• «6 defekte tërheqëse sistemike gjatë operimit të Kubernetes [dhe zgjidhjet e tyre]»;
• «Mjetet për zhvilluesit e aplikacioneve që ekzekutohen në Kubernetes»;
• «6 histori praktike nga përditshmëria jonë SRE ».

Burimi: habr.com