Visuaalne juhend Kubernetes'e tõrgete diagnoosimiseks

Märk. tõlge.: See artikkel kuulub vabalt kergesti kättesaadavate materjalide kogusse, learnk8s, mis õpetab Kubernetesega töötamist ettevõtte ja isiklike administraatorite jaoks. Selles jagab Daniele Polencic, projekti juht, visuaalset juhendit selle kohta, milliseid samme tuleks astuda, kui tekib üldise iseloomuga probleeme K8s klastris käivitatud rakendustega.

TL;DR: siin on Skeem, mis aitab teil Kuberneteses rakenduste juurutamist siluda:

Vigade leidmise ja parandamise vooskeem klastris. Originaalis (inglise keeles) on see saadaval PDF ja pildina.

Rakenduse juurutamise ajal Kuberneteses tuleb tavaliselt määratleda kolm komponenti:

• Deployment — see on retsept rakenduse koopiate, mida nimetatakse pod'ideks, loomiseks;
• Teenused — sisemine koormuse tasandaja, mis jagab liiklust pod'ide vahel;
• Ingress — kirjeldus selle kohta, kuidas liiklus jõuab välismaailmast teenuseni.

Siin on lühike graafiline kokkuvõte:

1) Kuberneteses saavad rakendused liiklust välismaailmast kahe koormuse tasandaja kihi kaudu: sisemine ja väline.

2) Sisemine koormuse tasandaja nimetatakse Teenuseks, väline – Ingress.

3) Juhtimine loob pod'id ja jälgib neid (need ei väljastata käsitsi).

Oletame, et soovite käivitada lihtsa rakenduse nagu Hello World. Selle YAML-konfigureerimine näeb välja järgmine:

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

Määratlemine on üsna pikk ja lihtne on segadusse minna selles, kuidas komponendid omavahel seondub.

Näiteks:

• Millal tuleks kasutada porti 80 ja millal 8080?
• Kas iga teenuse jaoks tuleks luua uus port, et vältida konflikte?
• Kas siltide nimed on olulised? Kas need peaksid olema kõikjal samad?

Enne silumise keskendumist meenutame, kuidas kolm komponenti omavahel seondub. Alustame Deployment’ist ja Service’ist.

Deployment’i ja Service’i seos

Te üllatute, kuid Deployment’id ja Service’id ei ole omavahel seotud. Selle asemel osutab Service otse Pod’idele, mööda Deployment’i.

Seega huvitab meid, kuidas Pods ja Service'id omavahel seotud on. Tuleb meeles pidada kolme asja:

1. Valija (selector) peavad Service'il vastama vähemalt ühele Pod'i sildile.
2. targetPort peab vastama containerPort Pod'i sees oleva konteineri.
3. port Service'i port võib olla ükskõik milline. Erinevad teenused võivad kasutada sama porti, kuna neil on erinevad IP-aadressid.

Järgmine diagramm esindab kõike eespoolt graafiliselt:

1) Kujutame ette, et teenus suunab liikluse mingisse pod'i:

2) Pod'i loomisel tuleb määrata containerPort iga konteineri jaoks pod'ides:

3) Teenuse loomisel tuleb määrata port ja targetPort. Aga mille kaudu toimub ühendus konteineriga?

4) A kaudu. targetPortSee peab olema sama, containerPort.

5) Oletame, et konteineris on avatud port 3000. Seega peab väärtus targetPort olema sama.

YAML-failis peavad sildid ja ports / targetPort olema ühilduvad:

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

Kuidas on lood sildiga track: canary Deployment sektsiooni ülaosas? Kas see peaks olema sama?

See silt kuulub juurutamisele ja seda ei kasutata teenuse jaoks liikluse suunamiseks. Teisisõnu, selle võib eemaldada või anda sellele teise väärtuse.

Aga kuidas on selektoriga matchLabels?

See peab alati olema sama nagu Pod'i sildid, kuna seda kasutatakse juurutamise poolt pod'ide jälgimiseks.

Oletame, et olete teinud õiged muudatused. Kuidas neid kontrollida?

Pod'i silte saab kontrollida järgmise käsuga:

kubectl get pods --show-labels

Või, kui pod'id kuuluvad mitmesse rakendusse:

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

Kus any-name=my-app — see on silt any-name: my-app.

Kas on veel probleeme?

Saate pod'iga ühendust võtta! Selleks peate kasutama käsku port-forward kubectl. See võimaldab ühendust võtta teenusega ja kontrollida ühendust.

kubectl port-forward service/ 3000:80

Siin:

• service/ — teenus nime; meie puhul on see my-service;
• 3000 — port, mida tuleb arvutis avada;
• 80 — port, mis on määratud port teenuses.

Kui ühendus on loodud, on seaded õiged.

Kui ühendust ei õnnestu luua, siis on probleem siltides või portide kokkulangevuses.

Teenuse ja Ingressi vaheline seos

Järgmine samm rakenduse juurdepääsu tagamisel hõlmab Ingressi seadistamist. Ingress peab teadma, kuidas teenust leida, seejärel leidma pod’id ja suunama nende suunas liiklust. Ingress leiab õige teenuse nime ja avatud porta järgi.

Ingressi ja Teenuse kirjelduses peavad olema kaks vastavust:

1. servicePort Ingressis peab vastama sellele parameetrile port Teenuses;
2. serviceName Ingressis peab olema kooskõlas name Teenuses.

Järgmine skeem toob kokku portsede ühendamise:

1) Nagu juba teate, Teenus kuulab mingit port:

2) Ingressil on parameeter, mida nimetatakse servicePort:

3) See parameeter (servicePort) peab alati vastama port Teenuse määratlemises:

4) Kui Teenuses on määratud port 80, siis peab servicePort olema samuti 80:

Praktikas tuleb tähelepanu pöörata järgmistele ridadele:

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

Kuidas kontrollida, kas Ingress töötab?

Saab kasutada meetodit kubectl port-forward, kuid teenuse asemel tuleb ühenduda Ingressi kontrolleriga.

Esiteks tuleb leida Ingressi kontrolleri pod'i nimi:

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

Leia Ingressi pod (see võib kuuluda teise nimede ruumi) ja käivita käsk describe, et teada saada portide numbrid:

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

Lõpuks ühendu pod'iga:

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

Nüüd, iga kord, kui saadad päringu pordile 3000 arvutis, suunatakse see Ingressi kontrolleri pod'i pordile 80. Minge aadressile http://localhost:3000, peate nägema rakenduse poolt loodud lehte.

Sadamate ülevaade

Kordame veel kord, millised sadamad ja sildid peaksid olema ühtivad:

1. Teenuse määratluses olev selektor peab olema ühtiv podi sildiga;
2. targetPort teenuse määratluses peab olema ühtiv containerPort podis oleva konteineri;
3. port teenuse määratluses võib olla mistahes. Erinevad teenused võivad kasutada sama sadamat, kuna neil on erinevad IP-aadressid;
4. servicePort Ingressi peab olema ühtiv port teenuse määratlusega;
5. Teenuse nimi peab olema ühtiv serviceName Ingressis.

Kahjuks ei piisa sellest, et teate, kuidas õigesti YAML-konfiguratsiooni struktureerida.

Mis juhtub, kui midagi läheb valesti?

Võib-olla pod ei käivitu või see kukub ära.

3 sammu rakenduste tõrkeotsingu jaoks Kuberneteses

K before debugging the deployment, it is essential to have a good understanding of how Kubernetes works.

Kuna igas K8s rakenduses on kolm komponenti, tuleb neid tõrkeotsingul käsitleda kindlas järjekorras, alustades altpoolt.

1. Esmalt tuleb veenduda, et podid töötavad, seejärel...
2. Kontrollige, kas teenus toimetab liikluse podidele, ja siis...
3. Kontrolli, kas Ingress on õigesti seadistatud.

Visuaalne ülevaade:

1) Probleemide leidmist tuleks alustada alt. Esiteks kontrolli, et pod’id oleksid staatustes Valmis ja Running:

2) Kui pod’id on valmis (Valmis), tuleb välja selgitada, kas teenus suunab liiklust pod’ide vahel:

3) Lõpuks tuleb analüüsida teenuse ja Ingress’i vahelist seost:

1. Pod’ide diagnostika

Enamikul juhtudel on probleem seotud pod’iga. Veendu, et pod’id on nimekirjas kui Valmis ja Running. Seda saab kontrollida käsu abil:

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

Ülaltoodud käsu väljundis on viimane pod märgitud kui Running ja Valmis, kuid kahe teiste puhul see nii ei ole.

Kuidas mõista, et midagi on valesti?

Pod’ide diagnoosimiseks on neli kasulikku käsku:

1. kubectl logs loputab logid pod’i konteineritest;
2. kubectl describe pod näitab pod’iga seotud sündmuste loetelu;
3. kubectl get pod tagastab pod’i YAML-konfiguratsiooni, mis on salvestatud Kubernetesesse;
4. kubectl exec -ti bash võimaldab käivitada interaktiivset käsurealiidese ühes pod'i konteineris

Millist neist valida?

Asi on selles, et ei ole ühte universaalset käsku. Tuleb kasutada nende kombinatsiooni.

Tüüpilised pod’ide probleemid

On kaks peamist pod’i tõrgete tüüpi: käivitustõrked (startup) ja tööaegsed tõrked (runtime).

Käivitustõrked:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• InvalidImageName

Tööaegsed tõrked:

• CrashLoopBackOff
• RunContainerError
• KillContainerError
• VerifyNonRootError
• RunInitContainerError
• CreatePodSandboxError
• ConfigPodSandboxError
• KillPodSandboxError
• SetupNetworkError
• TeardownNetworkError

Mõned tõrked esinevad sagedamini kui teised. Siin on mõned kõige levinumad tõrked ja nende lahendamise viisid.

ImagePullBackOff

See tõrge ilmneb, kui Kubernetes ei saa pod’i ühe konteineri jaoks pilti hankida. Siin on kolm kõige levinumat põhjust:

1. Pildi nimi on valesti määratud — näiteks olete teinud selles vea või pilti ei eksisteeri;
2. Määratud on mittesihitud pildi silt;
3. Pilt on salajases repositooriumis ja Kubernetesel puuduvad õigused sellele juurdepääsuks.

Esimese kahe probleemi lahendamine on lihtne — piisab, kui muuta pildi nime ja sildi. Viimase korral tuleb lisada sulgudele juurdepääsuandmed ja viidata neile pod'ides. Kubernetes'i dokumentatsioonis on näide kuidas seda teha.

CrashLoopBackOff

Kubernetes väljastab vea CrashLoopBackOff, kui konteinerit ei suudeta käivitada. Tavaline põhjus selle ekslemiseks on see, et:

1. Rakenduses on viga, mis ei lase sel käivituda;
2. Konteiner on vale seadistusega;
3. Liveness'i test nurjus liiga palju kordi.

Peate proovima logide juurde pääseda konteinerist, et välja selgitada selle kokkuvarisemise põhjus. Kui logide juurde pääsemine on keeruline, kuna konteiner taaskäivitub liiga kiiresti, saate kasutada järgmist käsku:

kubectl logs  --previous

See väljastab veateateid konteineri eelmisest reinkarnatsioonist.

RunContainerError

See viga ilmneb, kui konteiner ei suuda käivituda. See vastab hetkele enne rakenduse käivitamist. Tavaline põhjus on vale seadistus, näiteks:

• katse kinnitada mittesoovitud mahtu, näiteks ConfigMap või Secrets;
• proovitakse montaaži mahuti tüüpi read-only kui read-write.

Sarnaste vigade analüüsimiseks sobib hästi käsk kubectl describe pod.

Pod’id on olekus Pending

Pärast loomist jääb pod olekusse Ootel.

Miks see nii juhtub?

Siin on võimalikud põhjused (eeldan, et planeerija töötab normaalselt):

1. Klastris pole piisavalt ressursse, nagu arvutusvõime ja mälu, podi käivitamiseks.
2. Seotud nimedesisest on seadistatud objekt ResourceQuota ja podi loomine toob kaasa nimede ületamise limiidi.
3. Pod on seotud Pending PersistentVolumeClaim.

Selles olukorras soovitatakse kasutada käsku kubectl describe ja kontrollida jaotust Üritused:

kubectl describe pod

Vigade korral, mis on seotud ResourceQuotas, soovitatakse vaadata klastri logisid käsku

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

Pod’id ei ole olekus Ready

Kui pod on märgitud kui Running, kuid ei ole olekus Valmis, siis tähendab see, et selle valmisoleku kontroll (readiness probe) kukkub läbi.

Kui selline olukord tekib, ei saa pod teenusele ühendust ja sellele ei suunata liiklust. Valmiduse testimise ebaõnnestumine on põhjustatud rakenduse probleemidest. Sellisel juhul tuleb vea leidmiseks analüüsida lõiku Üritused käskluse tulemuses kubectl describe.

2. Teenuste diagnostika

Kui pod'id on loetletud kui Running ja Valmis, kuid rakenduselt ei tule endiselt vastust, tuleks kontrollida teenuse seadeid.

Teenused tegelevad liikluse suunamisega pod'idele vastavalt nende silte. Seetõttu on esimene asi, mida tuleb teha — kontrollida, mitu pod'i teenusega töötavad. Selleks saab kontrollida teenuse lõpp-punkte:

kubectl describe service  | grep Endpoints

Lõpp-punkt on väärtuste paar vormis <IP-адрес:порт>, ja väljundis peaks olema vähemalt üks selline paar (see tähendab, et vähemalt üks pod töötab teenusega).

Kui lõik Endpoints on tühi, on kaks võimalikku varianti:

1. ühtki pod'i ei ole õigete siltega (vihje: kontrollige, kas nimekiri on korrektne);
2. teenuse silte on selektoris vale.

Kui näete lõpp-punktide loendit, kuid ei pääse siiski rakendusele, on tõenäoliseks süüdlaseks vea esinemine targetPort teenuse kirjelduses.

Kuidas kontrollida teenuse töökorrasolekut?

Sõltumata teenuse tüübist on võimalik kasutada käsku kubectl port-forward ühendamiseks sellega:

kubectl port-forward service/ 3000:80

Siin:

• <service-name> — teenuse nimi;
• 3000 — port, mille avate arvutis;
• 80 — port teenuse poolel.

3. Ingressi diagnostika

Kui olete siiani lugenud, siis:

• pod'id on märgitud kui Running ja Valmis;
• teenus suunab liiklust pod'ide vahel edukalt.

Kuid te ei saa siiski rakendusele „jõuda”.

See tähendab, et tõenäoliselt on Ingressi juhitaja vale seadistusega. Kuna Ingressi juhitaja on klastris kolmas osaline komponent, sõltuvad tõrkeotsingu meetodid selle tüübist.

Kuid enne, kui kasutate erivahendeid Ingressi seadistamiseks, saate teha midagi väga lihtsat. Ingress kasutab serviceName ja servicePort teenusele ühendamiseks. Peate kontrollima, kas need on õigesti seadistatud. Seda saab teha käsuga:

kubectl describe ingress

Kui veerg Backend on tühi, on suur tõenäosus seadistuse viga. Kui tagaküljed on olemas, kuid rakendusele pole endiselt juurdepääsu, võib probleem olla seotud:

• Ingressi kättesaadavuse seadistustega avalikust internetist;
• klastrite kättesaadavuse seadistused avalikult internetist.

Probleeme infrastruktuuriga saab tuvastada, ühendudes otse Ingress’i pod’iga. Selleks leidke esmalt Ingress-kontrolleri pod (see võib olla teises nimede ruumis):

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

Kasutage käsku describe, et määrata port:

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

Lõpuks ühendu pod'iga:

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

Nüüd suunatakse kõik 3000 pordi päringud arvutis pod'i 80 pordile.

Kas see töötab nüüd?

• Kui jah, siis on probleem infrastruktuuris. Tuleb välja selgitada, kuidas täpselt toimub liikluse suunamine klastrisse.
• Kui ei, siis on probleem Ingress-kontrolleris.

Kui Ingress-kontrollerit ei õnnestu tööle panna, tuleb selle tõrkeotsing läbi viia.

Ingress-kontrollerite variatsioone on palju. Kõige populaarsemad on Nginx, HAProxy, Traefik jne. (lisateabe saamiseks vaadake meie ülevaatest — kt. tõlge) Tuleb kasutada vastava kontrolleri dokumentatsioonis sisalduvat tõrkeotsingu guide'i. Kuna Ingress Nginx on kõige populaarsem Ingress-kontroller, oleme pannud artiklisse mitmeid näpunäiteid selle seotud probleemide lahendamiseks.

Nginx Ingress kontrolleri silumise juhend

Ingress-nginx projektil on ametlik plugina kubectl jaoks. Käsku kubectl ingress-nginx võib kasutada järgmiseks:

• logide, taustateenuste, sertifikaatide jne analüüsimiseks;
• Ingress'iga ühendamiseks;
• praeguse konfiguratsiooni uurimiseks.

Selleks aitavad teid järgmised kolm käsku:

• kubectl ingress-nginx lint — kontrollib nginx.conf;
• kubectl ingress-nginx backend — uurib taustateenust (sarnaselt kubectl describe ingress);
• kubectl ingress-nginx logs — kontrollib logisid.

Pange tähele: mõnel juhul võib olla vajalik määrata õige nimede ruum Ingress kontrolleri jaoks lipuga --namespace.

Kokkuvõte

Kubernetes'is tõrkeotsing võib osutuda keeruliseks, kui ei tea, kust alustada. Probleemi tuleks alati läheneda alt üles: alustage pod'idest ja liikuge seejärel teenuse ja Ingress'i poole. Artiklis kirjeldatud tõrkeotsingu meetodeid saab rakendada ka teiste objektide, nagu:

• töötavad Job'id ja CronJob'id;
• StatefulSet'id ja DaemonSet'id.

Soovin tänada Gergely Riskot, Daniel Weibeli ja Charles Christyraj hindamatute märkuste ja täienduste eest.

P.S. tõlkija märkused

Lugege ka meie blogist:

• «kubectl-debug plugina abil Kuberneteses pod'ide tõrkeotsimiseks»;
• «6 huvitavat süsteemi tõrget Kubernetes'e kasutamise käigus [ja nende lahendamine]»;
• «Arendustööriistad Kuberneteses töötavatele rakendustele»;
• «6 praktilist lugu meie SRE igapäevaelust ».

Allikas: habr.com