Visuaalne juhend Kubernetesi tõrkeotsinguks

Märkus tõlke kohta.: See artikkel kuulub vabalt kättesaadavate projektimaterjalide hulka learnk8s, mis õpetavad Kubernetesega töötamist ettevõtte ja individuaalsete administraatorite jaoks. Siin jagab projekti juht Daniele Polencic selget juhendit, milliseid samme tuleks astuda, kui K8s-klastris käivitatud rakendustes tekivad üldised probleemid.

TL;DR: siin on skeem, mis aitab teil Kuberneteses deploymenti tõrkeotsingul:

Vigade leidmise ja parandamise plokkskeem klastris. Originaalis (inglise keeles) on see saadaval PDF ja nagu pilt.

Rakenduse käivitamisel Kuberneteses on tavaliselt kolm komponenti, mis tuleb määratleda:

• Deployment — see on retsept rakenduse koopiate, nn pod'ide, loomiseks;
• Teenused — sisemine koormuse tasandaja, mis jagab liiklust pod'ide vahel;
• Ingress — kirjeldus, kuidas liiklus välisest maailmast Service'isse jõuab.

Siin on lühike graafiline kokkuvõte:

1) Kuberneteses saavad rakendused liiklust välisest maailmast läbi kahe tüüpi koormuse tasandajate: sisemiste ja välistest.

2) Sisemise koormuse tasandaja nimetatakse Service'iks, välist nimetatakse Ingress'iks.

3) Deployment loob pod'id ja jälgib neid (need ei tohi olla käsitsi loodud).

Oletame, et soovite juurutada lihtsat rakendust nagu Tere maailm. YAML-konfigureerimine selle jaoks 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 komponente on lihtne omavahel segi ajada.

Näiteks:

• Millal tuleks kasutada porti 80 ja millal porti 8080?
• Kas peaks iga teenuse jaoks looma uue pordi, et nad ei konflikti?</
• Kas sildid on olulised? Kas nad peavad olema igal pool samad?

Enne tõrkeotsingule keskendumist tuletame meelde, kuidas kolm komponenti üksteisega seotud on. Alustame Deploymentist ja Service'ist.

Deployment'i ja Service'i seos

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

Seega meid huvitab, kuidas on seotud Pod'id ja Service'id. Meeles tuleb pidada kolme asja:

1. Valija (selector) Service'il peab vastama vähemalt ühele Pod'i märgisele.
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 skeem näitab kõike ülaltoodut graafiliselt:

1) Oletame, et teenus suunab liiklust mingisse pod'i:

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

3) Teenuse loomisel tuleb näidata port ja targetPort. Kuid millise kaudu toimub ühendus konteineriga?

4) A läbi targetPort. See peab vastama containerPort.

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

YAML-failis peavad märgid ja ports / targetPort vastama:

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

Aga kuidas on lood märgisega track: canary Deployment'i jaotuse ülaosas? Kas see peab vastama?

See märgis kuulub rakendusele ega ole teenuse poolt liikluse suunamiseks kasutusel. Teisisõnu, selle saab eemaldada või määrata sellele muu väärtus.

A kuidas on sellega, et valija matchLabels?

see peab alati vastama Pod'i märkidele, kuna seda kasutab Deployment pod'ide jälgimiseks.

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

Pod'i märke saab kontrollida järgmise käsklusega:

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 märk any-name: my-app.

Ükski probleem ei ole jäänud?

Sa saad ühenduda pod'iga! Selle jaoks tuleb kasutada käsku port-forward kubectl'is. See võimaldab ühenduda teenusega ja kontrollida ühendust.

kubectl port-forward service/<teenuse nimi> 3000:80

Siin:

• service/<teenuse nimi> — teenuse nimi; meie puhul on see my-service;
• 3000 — port, mis tuleb arvutis avada;
• 80 — port, mis on märgitud valdkonnas port teenusele.

Kui ühendus õnnestus, siis on sätted õiged.

Kui ühendust ei õnnestu luua, siis on probleem siltide või portide vastavuses.

Teenuse ja Ingressi vaheline ühendus

Järgmine samm rakenduse juurdepääsu tagamisel on Ingressi seadistamine. Ingress peab teadma, kuidas leida teenust, siis leida podid ja suunata liiklus nende poole. Ingress leiab vajaliku teenuse nime ja avatud pordi kaudu.

Ingressi ja Teenuse kirjelduse juures peavad olema ühesugused kaks parameetrit:

1. servicePort Ingressis peab vastama parameetrile port Teenuses;
2. serviceName Ingressis peab vastama väljale nimi Teenuses.

Järgmine skeem kogub portide ühendamise kokku:

1) Nagu juba teate, kuulab Teenus mingit port:

2) Ingressil on parameeter, mida nimetatakse servicePort:

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

4) Kui Teenuses on määratud port 80, siis on vajalik, et servicePort ka oleks 80:

Tavaolukorras tuleks 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?

Saate kasutada meetodit kubectl port-forward, kuid teenuse asemel peate ühenduse looma Ingressi kontrolleriga.

Esialgu peate välja selgitama podi nime, kus on Ingressi kontroller:

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

Leidke Ingressi pod (see võib kuuluda teise nimekasti) ja käivitage 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, ühendage podiga:

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

Iga kord, kui saadate päringu sadamale 3000 arvutis, suunatakse see Ingressi kontrolleri pod’i sadamale 80. Kui navigeerite http://localhost:3000, peaksite nägema rakenduse loodud lehte.

Kokkuvõte portidest

Vaatame veel kord, millised sadamad ja sildid peaksid sobima:

1. Teenuse määratlemine peab vastama podi sildile;
2. targetPort Teenuse määratlemine peab vastama containerPort pod’i sees oleva konteineri määratlemisega;
3. port Teenuste määratlemine võib olla mis tahes. Erinevad teenused võivad kasutada sama porti, kuna neil on erinevad IP-aadressid;
4. servicePort Ingress peab olema sama port teenuste määratlemises;
5. Teenuse nimi peab vastama väljal serviceName Ingressis.

Kahjuks ei piisa ainult YAML-konfiguratsiooni korrektse struktuuri tundmisest.

Mis juhtub, kui midagi läheb valesti?

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

3 sammu Kubernetesis rakenduste tõrkeotsimiseks

Enne, kui alustate juurutamise tõrkeotsingut, on vajalik omada head arusaamist sellest, kuidas Kubernetes töötab.

Kuna igas K8s rakenduses on kolm komponenti, tuleks nende tõrkeotsingut teha kindlas järjekorras, alustades kõige madalamast.

1. Esmalt peate veenduma, et podid töötavad, seejärel…
2. Kontrollima, kas teenus suunab liiklust podideni, ja seejärel…
3. Kontrollima, kas Ingress on õigesti seadistatud.

Visuaalne esitus:

1) Probleemide otsing tuleks alustada kõige madalamast. Kõigepealt kontrollige, et podid on staatusega Valmis ja Käimas:

2) Kui podid on valmis (Valmis), peate välja selgitama, kas teenus jaotab liiklust podide vahel:

3) Lõpuks tuleb analüüsida teenuse ja Ingressi vahelist seost:

1. Podide tõrkeotsing

Enamasti on probleem seotud podiga. Veenduge, et podid oleksid tähistatud kui Valmis ja Käimas. Seda saab kontrollida järgmise 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 tähistatud kui Käimas ja Valmis, kuid kahe teise puhul ei ole see nii.

Kuidas aru saada, mis valesti läks?

Podide tõrkeotsimiseks on neli kasulikku käsu:

1. kubectl logs võimaldab välja võtta logid podis olevatest konteineritest;
2. kubectl describe pod võimaldab vaadata podiga seotud sündmuste loetelu;
3. kubectl get pod võimaldab saada Kubernetesesse salvestatud pod'i YAML-konfiguratsiooni;
4. kubectl exec -ti bash võimaldab käivitada interaktiivse käsurea ühes pod'i konteineris

Millist neist valida?

Tegelikult ei ole ühte universaalset käsku. Tuleb kasutada nende kombinatsiooni.

Tüüpilised podide probleemid

On kaks peamist tüüpi podide vigu: käivitusvead ja töövead.

Käivitusvead:

• ImagePullBackoff
• ImageInspectError
• ErrImagePull
• ErrImageNeverPull
• RegistryUnavailable
• Vale Pildi Nimi

Käivitusvead:

• CrashLoopBackOff
• Käivita Kasti Viga
• Killi Kasti Viga
• Kontrolli Juurteta Viga
• Käivita Algkasti Viga
• Loo Pod'i Sandboxi Viga
• Kegita Pod'i Sandboxi Viga
• Killi Pod'i Sandboxi Viga
• Seadista Võrguviga
• Lahuta Võrguviga

Mõned vead esinevad sagedamini kui teised. Siin on mõned kõige levinumad vead ja nende lahendused.

ImagePullBackOff

See viga ilmneb, kui Kubernetes ei suuda saada aluspinda ühe pod'i konteineri jaoks. Siin on kolm kõige levinumat põhjust:

1. Vale pildi nimi on näidatud – näiteks olete teinud selles vea või pilti ei eksisteeri;
2. Kontseptsioonitoodang, mis ei eksisteeri;
3. Pilt on salajases registris ja Kubernetesel ei ole õigusi sellele juurde pääseda.

Kahte esimest põhjust on hõlbus lahendada – piisab, kui parandada pildi nimi ja kontseptsioon. Viimase puhul tuleb luua salajase registri sisselogimisdokumendid ja lisada viidud need pod'idesse. Kubernetes'i dokumentatsioonis on näide sellest, kuidas seda teha.

CrashLoopBackOff

Kubernetes kuvab vea CrashLoopBackOff, kui konteiner ei suuda käivituda. Tavaliselt juhtub see, kui:

1. Rakenduses on viga, mis ei luba sellel käivituda;
2. Konteiner vale seadistus;
3. Liveness testi ebaõnnestumine liiga palju kordi.

On vajalik proovida saada logisid konteinerist, et välja selgitada, miks see ebaõnnestus. Kui logide saamine on keeruline, kuna konteiner käivitub liiga kiiresti, saab kasutada järgmist käsku:

kubectl logs  --previous

See kuvab veateateid konteineri eelmistest reinkarnatsioonidest.

Käivita Kasti Viga

See viga esineb, kui konteiner ei suuda käivituda. See toimub enne rakenduse käivitamist. Tavaliselt on selle põhjuseks vale seadistamine, näiteks:

• katse mälu seadistada, mis ei eksisteeri, nagu ConfigMap või Secrets;
• katse mountida read-only tüüp kui read-write.

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

Pod'id on olekus Pending

Pärast pod'i loomist jääb see olekusse Pending.

Miks see juhtub?

Siin on võimalikud põhjused (lähenen oletusele, et planeerija töötab normaalselt):

1. Klastris puuduvad ressursid, näiteks arvutusvõime ja mälu, et pod'i käivitada.
2. Asjakohases nimedruumis on sisse seatud objekt ResourceQuota ja pod'i loomine toob kaasa, et nimepind ületab kvota.
3. Pod on seotud ootel PersistentVolumeClaim.

Sel juhul on soovitatav kasutada käsku kubectl describe ning kontrollida jaotist Üritused:

kubectl describe pod

Vigade korral, mis on seotud ResourceQuotas, on soovitatav vaadata klastrilogisid käsku kasutades

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

Pod'id ei ole olekus Ready

Kui pod on märgitud kui Käimas, kuid ei ole olekus Valmis, tähendab see, et selle valmisoleku kontrollimine (readiness probe) ei õnnestu.

Kui see toimub, ei saa pod teenusele ühendust ja sellele ei suunata liiklust. Ready testi ebaõnnestumine on tingitud rakenduse probleemidest. Sel juhul tuleb vea leidmiseks analüüsida jaotist Üritused käsku andmete väljastamise ajal kubectl describe.

2. Teenuste diagnostika

Kui pod'id on märgitud kui Käimas ja Valmis, kuid rakenduselt pole endiselt vastust, tuleb kontrollida teenuse seadeid.

Teenused tegelevad liikluse suunamisega pod'ide juurde vastavalt nende etikettidele. Seetõttu on esimene asi, mida teha — kontrollida, mitu pod'i töötavad teenusega. Selleks võib kontrollida teenuse lõpp-punkte:

kubectl describe service  | grep Endpoints

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

Kui jaotis Endpoints on tühi, võivad olla kaks varianti:

1. pole ühtegi pod'i õigete etikettidega (vihje: kontrollige, kas nimel on õige seadistuse valikud);
2. teenuse etikettides on selektoris viga.

Kui näete nimekirja lõpp-punkte, kuid ei pääse rakendusele ligi, on tõenäoliselt süüdlane viga targetPort teenuse kirjelduses.

Kuidas kontrollida teenuse töökorrasolekut?

Sõltumata teenuse tüübist, saate kasutada käsku kubectl port-forward sellega ühenduse loomiseks:

kubectl port-forward service/ 3000:80

Siin:

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

3. Ingressi diagnostika

Kui olete siiani lugenud, siis:

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

Kuid te ei pääse ikka rakendusele ligi.

See tähendab, et tõenäoliselt on Ingressi kontroller vale seade. Kuna Ingressi kontroller on klastris väline komponent, on erinevad tõrkeotsingu meetodid olenevalt selle tüübist.

Kuid enne kui kasutada spetsiaalseid tööriistu Ingressi seadistamiseks, on võimalik teha midagi üsna lihtsat. Ingress kasutab serviceName ja servicePort teenusele ühenduse loomiseks. Tuleb kontrollida, kas need on õigesti seadistatud. Seda saab teha käsuga:

kubectl describe ingress

Kui veerg Backend on tühi, siis on suur tõenäosus, et konfiguratsioonis on viga. Kui backend'id on kohal, kuid rakendusele ligipääs puudub, siis võib probleem olla seotud:

• Ingressi kättesaadavuse seadistustega avalikust internetist;
• klastri kättesaadavuse seadistustega avalikust internetist.

Probleemide tuvastamiseks infrastruktuuris saab otse Ingressi pod'iga ühendust võtta. Selleks leidke kõigepealt Ingressi kontrolleri pod (see võib olla teises nimedega 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 seada sadam:

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

Lõpuks, ühendage podiga:

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

Nüüd suunatakse kõik arvutisse suunatud päringud sadamasse 3000 pod'i 80 sadamasse.

Kas see nüüd töötab?

• Kui jah, siis on probleem infrastruktuuris. Tuleb välja selgitada, kuidas täpselt toimub liikluse ruteerimine klastrisse.
• Kui ei, siis on probleem Ingressi kontrolleriga.

Kui Ingressi kontrollerit ei saa töötama panna, tuleb selle tõrkeotsingut teha.

Ingressi kontrollerite jaoks on palju erinevaid variante. Kõige populaarsemad on Nginx, HAProxy, Traefik jpt. (olemasolevate lahenduste kohta vt meie ülevaates — toimetaja märkus) Tuleks kasutada vastava kontrolleri dokumentatsioonis tõrkeotsingu juhendit. Kuna Ingress Nginx on kõige populaarsem Ingressi kontroller, oleme artiklisse lisanud mõned nõuanded sellega seotud probleemide lahendamiseks.

Ingress Nginx kontrolleri tõrkeotsing

Ingress-nginx projekt omab ametlikku kubectl pluginit.Käsku kubectl ingress-nginx võib kasutada järgmiste jaoks:

• logide, backend'ide, sertifikaatide jne analüüsimiseks;
• Ingressiga ühenduse loomiseks;
• praeguse konfiguratsiooni uurimiseks.

Selleks aitavad teid järgmised kolm käsku:

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

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

Elulookirjeldus

Kubernetesi tõrkeotsing võib osutuda keeruliseks ülesandeks, kui ei tea, kust alustada. Probleemile tuleks alati läheneda „alates alt üles” põhimõttest: alustage pod'idest ja seejärel liikuge teenuse ja Ingress-i juurde. Artiklis kirjeldatud tõrkeotsingu meetodeid saab rakendada ka teistele objektidele, nagu:

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

Tänan Gergely Risko, Daniel Weibel ja Charles Christyraj kuldsete märkuste ja täienduste eest.

P.S. tõlkijalt

Lugege ka meie blogist:

• «Kubernetesi pod'ide tõrkeotsimiseks mõeldud kubectl-debug plugin»;
• «6 huvitavat süsteemiviga Kubernetes'i kasutamise ajal [ja nende lahendamine]»;
• «Rakenduste arendamise tööriistad, mis käivitatakse Kuberneteses»;
• «6 praktilist lugu meie SRE-päevadest ».

Allikas: habr.com