Vizuāls ceļvedis Kubernetes problēmu novēršanai

Piezīme. tulk.: Šis raksts ir daļa no publiskajā domēnā publicētajiem projekta materiāliem mācīties8s, apmācīt uzņēmumus un individuālos administratorus darbam ar Kubernetes. Tajā Daniele Polencic, projektu vadītāja, dalās ar vizuāliem norādījumiem par to, kādas darbības jāveic, ja rodas vispārējas problēmas ar lietojumprogrammām, kas darbojas K8s klasterī.

TL;DR: šeit ir diagramma, kas palīdzēs atkļūdot izvietošanu Kubernetes:

Blokshēma kļūdu atrašanai un labošanai klasterī. Oriģināls (angļu valodā) ir pieejams vietnē PDF и kā attēls.

Izvietojot lietojumprogrammu Kubernetes, parasti ir jādefinē trīs komponenti:

• Izvietošanas - šī ir sava veida recepte, lai izveidotu lietojumprogrammas kopijas, ko sauc par pākstīm;
• Serviss — iekšējais slodzes balansētājs, kas sadala trafiku starp podiem;
• Iekļūšana — apraksts par to, kā satiksme no ārpasaules nonāks Pakalpojumā.

Šeit ir ātrs grafisks kopsavilkums:

1) Programmā Kubernetes lietojumprogrammas saņem trafiku no ārpasaules, izmantojot divus slodzes balansētāju slāņus: iekšējo un ārējo.

2) Iekšējo balansētāju sauc par Service, ārējo sauc par Ingress.

3) Izvietošana rada podi un uzrauga tos (tie netiek izveidoti manuāli).

Pieņemsim, ka vēlaties izvietot vienkāršu lietojumprogrammu a la Sveiki World. Tā YAML konfigurācija izskatīsies šādi:

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

Definīcija ir diezgan gara, un ir viegli sajaukt, kā komponenti ir saistīti viens ar otru.

Piemēram:

• Kad jāizmanto ports 80 un kad jāizmanto 8080?
• Vai katram pakalpojumam jāizveido jauns ports, lai tie nebūtu pretrunā?
• Vai etiķešu nosaukumiem ir nozīme? Vai tiem visur jābūt vienādiem?

Pirms pievērsties atkļūdošanai, atcerēsimies, kā šie trīs komponenti ir saistīti viens ar otru. Sāksim ar izvietošanu un apkalpošanu.

Saistība starp izvietošanu un pakalpojumu

Jūs būsiet pārsteigts, taču izvietošana un pakalpojums nekādā veidā nav saistīti. Tā vietā pakalpojums norāda tieši uz Pods, apejot izvietošanu.

Tādējādi mēs esam ieinteresēti, kā podi un pakalpojumi ir saistīti viens ar otru. Trīs lietas, kas jāatceras:

1. Atlasītājs (selector) pakalpojumam ir jāatbilst vismaz vienai Pod etiķetei.
2. targetPort ir jāsakrīt containerPort konteiners podā.
3. port Pakalpojums var būt jebkas. Dažādi pakalpojumi var izmantot vienu un to pašu portu, jo tiem ir atšķirīgas IP adreses.

Sekojošā diagramma attēlo visu iepriekš minēto grafiskā formā:

1) Iedomājieties, ka pakalpojums novirza trafiku uz noteiktu podziņu:

2) Veidojot podiņu, jānorāda containerPort katram konteineram pākstīs:

3) Veidojot pakalpojumu, jānorāda port и targetPort. Bet kuru izmanto, lai izveidotu savienojumu ar konteineru?

4) caur targetPort. Tam jāsakrīt containerPort.

5) Pieņemsim, ka konteinerā ir atvērts ports 3000. Tad vērtība targetPort jābūt vienādam.

YAML failā etiķetes un ports / targetPort ir jāsakrīt:

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

Kas par etiķeti track: canary sadaļas Izvietošana augšpusē? Vai tam jāsakrīt?

Šis apzīmējums ir specifisks izvietošanai, un pakalpojums to neizmanto satiksmes maršrutēšanai. Citiem vārdiem sakot, to var noņemt vai piešķirt citu vērtību.

Kas par atlasītāju matchLabels?

Tam vienmēr jāatbilst Pod etiķetēm, jo to izmanto izvietošana, lai izsekotu podi.

Pieņemsim, ka esat veicis pareizos labojumus. Kā tos pārbaudīt?

Varat pārbaudīt apavu etiķeti ar šādu komandu:

kubectl get pods --show-labels

Vai arī, ja podi pieder vairākām lietojumprogrammām:

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

Kur any-name=my-app ir etiķete any-name: my-app.

Vai ir palikušas kādas grūtības?

Var pieslēgties podam! Lai to izdarītu, jums ir jāizmanto komanda port-forward in kubectl. Tas ļauj izveidot savienojumu ar pakalpojumu un pārbaudīt savienojumu.

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

Здесь:

• service/<service name> — pakalpojuma nosaukums; mūsu gadījumā tā ir my-service;
• 3000 ir ports, kas ir jāatver datorā;
• 80 - laukā norādītais ports port serviss.

Ja savienojums tika izveidots, iestatījumi ir pareizi.

Ja savienojums neizdodas, ir problēma ar etiķetēm vai porti nesakrīt.

Attiecības starp Service un Ingress

Nākamais solis, lai nodrošinātu piekļuvi lietojumprogrammai, ir Ingress iestatīšana. Ingress ir jāzina, kā atrast pakalpojumu, pēc tam atrast podi un novirzīt trafiku uz tiem. Ingress atrod vajadzīgo pakalpojumu pēc nosaukuma un atvērtā porta.

Ingress un Service aprakstā ir jāsakrīt diviem parametriem:

1. servicePort in Ingress ir jāatbilst parametram port Pakalpojumā;
2. serviceName Ingress ir jāatbilst laukam name Pakalpojumā.

Šajā diagrammā ir apkopoti portu savienojumi:

1) Kā jūs jau zināt, Serviss ieklausās noteiktā port:

2) Ingress ir parametrs, ko sauc servicePort:

3) Šis parametrs (servicePort) vienmēr jāsakrīt port pakalpojuma definīcijā:

4) Ja Service ir norādīts ports 80, tad tas ir nepieciešams servicePort arī bija vienāds ar 80:

Praksē jums jāpievērš uzmanība šādām rindām:

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

Kā pārbaudīt, vai Ingress darbojas?

Jūs varat izmantot metodi ar kubectl port-forward, bet pakalpojuma vietā ir nepieciešams izveidot savienojumu ar Ingress kontrolleri.

Vispirms ar Ingress kontrolleri jānoskaidro poda nosaukums:

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

Atrodiet Ingress pod (tas var būt citā nosaukumvietā) un palaidiet komandu describelai uzzinātu portu numurus:

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

Visbeidzot, izveidojiet savienojumu ar podziņu:

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

Tagad katru reizi, kad nosūtāt pieprasījumu uz datora 3000. portu, tas tiks pārsūtīts uz podziņas 80. portu ar Ingress kontrolleri. Dodoties uz http://localhost:3000, jums vajadzētu redzēt lietojumprogrammas ģenerēto lapu.

Ostu kopsavilkums

Vēlreiz atcerēsimies, kuriem portiem un etiķetēm ir jāatbilst:

1. Pakalpojuma definīcijas atlasītājam ir jāatbilst aplikuma etiķetei;
2. targetPort definīcijā Pakalpojumam ir jāatbilst containerPort konteiners pāksts iekšpusē;
3. port definīcijā Pakalpojums var būt jebkas. Dažādi pakalpojumi var izmantot vienu un to pašu portu, jo tiem ir atšķirīgas IP adreses;
4. servicePort Iekļūšanai ir jāsakrīt port pakalpojuma definīcijā;
5. Pakalpojuma nosaukumam ir jāatbilst laukam serviceName in Ingress.

Diemžēl nepietiek tikai zināt, kā pareizi strukturēt YAML konfigurāciju.

Kas notiek, kad lietas noiet greizi?

Pāksts var nedarboties vai avarēt.

3 soļi, lai diagnosticētu lietojumprogrammas problēmas pakalpojumā Kubernetes

Pirms sākat izvietošanas atkļūdošanu, jums ir labi jāizprot, kā darbojas Kubernetes.

Tā kā katrai K8s lejupielādētajai lietojumprogrammai ir trīs komponenti, tie ir jāatkļūdo noteiktā secībā, sākot no pašas apakšas.

1. Vispirms jāpārliecinās, vai pākstis darbojas, tad...
2. Pārbaudiet, vai pakalpojums nodrošina trafiku uz podiem, un pēc tam...
3. Pārbaudiet, vai Ingress ir pareizi konfigurēts.

Vizuāls attēlojums:

1) Jums vajadzētu sākt meklēt problēmas no pašas apakšas. Vispirms pārbaudiet, vai pākstīm ir statusi Ready и Running:

2) Ja pākstis ir gatavas (Ready), jums vajadzētu noskaidrot, vai pakalpojums sadala trafiku starp aplikācijām:

3) Visbeidzot, jums jāanalizē saikne starp pakalpojumu un Ingress:

1. Pākšu diagnostika

Vairumā gadījumu problēma ir saistīta ar pāksti. Pārliecinieties, vai pākstis ir norādītas kā Ready и Running. To var pārbaudīt, izmantojot komandu:

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

Iepriekš esošajā komandas izvadē pēdējais pods ir norādīts kā Running и Readytomēr tas neattiecas uz pārējiem diviem.

Kā saprast, kas nogāja greizi?

Ir četras noderīgas komandas, lai diagnosticētu pākstis:

1. kubectl logs <имя pod'а> ļauj izvilkt baļķus no konteineriem podā;
2. kubectl describe pod <имя pod'а> ļauj skatīt ar podziņu saistīto notikumu sarakstu;
3. kubectl get pod <имя pod'а> ļauj iegūt Kubernetes saglabātā podziņa YAML konfigurāciju;
4. kubectl exec -ti <имя pod'а> bash ļauj palaist interaktīvu komandu apvalku vienā no pod konteineriem

Kuru izvēlēties?

Fakts ir tāds, ka nav universālas komandas. Jāizmanto to kombinācija.

Tipiskas podziņas problēmas

Ir divi galvenie aplikācijas kļūdu veidi: startēšanas kļūdas un izpildlaika kļūdas.

Startēšanas kļūdas:

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

Izpildlaika kļūdas:

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

Dažas kļūdas ir biežākas nekā citas. Šeit ir dažas no visbiežāk sastopamajām kļūdām un to novēršanas metodes.

ImagePullBackOff

Šī kļūda rodas, ja Kubernetes nevar iegūt attēlu vienam no pod konteineriem. Šeit ir trīs visbiežāk sastopamie iemesli:

1. Attēla nosaukums ir nepareizs – piemēram, jūs tajā esat kļūdījies vai attēls neeksistē;
2. Attēlam tika norādīts neesošs tags;
3. Attēls tiek glabāts privātā reģistrā, un Kubernetes nav atļaujas tam piekļūt.

Pirmos divus iemeslus ir viegli novērst — vienkārši izlabojiet attēla nosaukumu un atzīmi. Pēdējā gadījumā jums ir jāievada slēgtā reģistra akreditācijas dati sadaļā Secret un jāpievieno saites uz to podiņos. Kubernetes dokumentācijā ir piemērs kā to var izdarīt.

Crash Loop Back Off

Kubenetes iemet kļūdu CrashLoopBackOff, ja konteineru nevar palaist. Tas parasti notiek, ja:

1. Lietojumprogrammā ir kļūda, kas neļauj to palaist;
2. Konteiners nepareizi konfigurēts;
3. Pārāk daudz reižu dzīvīguma tests ir izgāzies.

Lai noskaidrotu tā neveiksmes iemeslu, jums jāmēģina nokļūt pie žurnāliem no konteinera. Ja ir grūti piekļūt žurnāliem, jo ​​konteiners tiek restartēts pārāk ātri, varat izmantot šādu komandu:

kubectl logs <pod-name> --previous

Tas parāda kļūdu ziņojumus no iepriekšējā konteinera iemiesojuma.

RunContainerError

Šī kļūda rodas, ja konteineru neizdodas palaist. Tas atbilst brīdim pirms lietojumprogrammas palaišanas. To parasti izraisa nepareizi iestatījumi, piemēram:

• mēģinājums pievienot neesošu sējumu, piemēram, ConfigMap vai Secrets;
• mēģinājums montēt tikai lasāmu sējumu kā lasāmu un rakstāmu.

Komanda ir labi piemērota šādu kļūdu analīzei kubectl describe pod <pod-name>.

Pāksti atrodas gaidīšanas stāvoklī

Pēc izveides pāksts paliek stāvoklī Pending.

Kāpēc tas notiek?

Šeit ir iespējamie iemesli (es pieņemu, ka plānotājs darbojas labi):

1. Klasterim nav pietiekami daudz resursu, piemēram, apstrādes jaudas un atmiņas, lai palaistu podziņu.
2. Objekts ir instalēts attiecīgajā nosaukumu telpā ResourceQuota un izveidojot aplikumu, nosaukumvieta pārsniegs kvotu.
3. Aplikācija ir saistīta ar statusu Gaida PersistentVolumeClaim.

Šajā gadījumā ieteicams izmantot komandu kubectl describe un pārbaudiet sadaļu Events:

kubectl describe pod <pod name>

Kļūdu gadījumā, kas saistītas ar ResourceQuotas, ieteicams skatīt klasteru žurnālus, izmantojot komandu

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

Pākstis nav gatavas

Ja pods ir norādīts kā Running, bet nav stāvoklī Ready, nozīmē pārbaudīt tā gatavību (gatavības zonde) neizdodas.

Ja tas notiek, pods nepievienojas pakalpojumam un uz to neplūst satiksme. Gatavības pārbaudes kļūmi izraisa problēmas lietojumprogrammā. Šajā gadījumā, lai atrastu kļūdu, jums ir jāanalizē sadaļa Events komandas izvadē kubectl describe.

2. Servisa diagnostika

Ja pākstis ir norādītas kā Running и Ready, taču no lietojumprogrammas joprojām nav atbildes, jums jāpārbauda pakalpojuma iestatījumi.

Pakalpojumi ir atbildīgi par trafika novirzīšanu uz podiem atkarībā no to etiķetēm. Tāpēc pirmā lieta, kas jums jādara, ir pārbaudīt, cik daudz podi darbojas ar pakalpojumu. Lai to izdarītu, pakalpojumā varat pārbaudīt galapunktus:

kubectl describe service <service-name> | grep Endpoints

Galapunkts ir formas vērtību pāris <IP-адрес:порт>, un izvadā ir jābūt vismaz vienam šādam pārim (tas ir, vismaz viens pods darbojas ar pakalpojumu).

Ja sadaļa Endpoins tukšs, ir iespējamas divas iespējas:

1. nav nevienas pākstis ar pareizo etiķeti (padoms: pārbaudiet, vai nosaukumvieta ir atlasīta pareizi);
2. Atlasītājā pakalpojumu etiķetēs ir kļūda.

Ja redzat galapunktu sarakstu, bet joprojām nevarat piekļūt lietojumprogrammai, iespējams, vaininieks ir kļūda targetPort pakalpojuma aprakstā.

Kā pārbaudīt pakalpojuma funkcionalitāti?

Neatkarīgi no pakalpojuma veida varat izmantot komandu kubectl port-forward lai izveidotu savienojumu ar to:

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

Здесь:

• <service-name> — pakalpojuma nosaukums;
• 3000 ir ports, ko atverat datorā;
• 80 - ports servisa pusē.

3. Iekļūšanas diagnostika

Ja esat izlasījis tik tālu, tad:

• pākstis ir uzskaitītas kā Running и Ready;
• pakalpojums veiksmīgi sadala trafiku starp podiem.

Tomēr jūs joprojām nevarat sasniegt lietotni.

Tas nozīmē, ka Ingress kontrolleris, visticamāk, nav pareizi konfigurēts. Tā kā Ingress kontrolleris ir klastera trešās puses komponents, atkarībā no tā veida ir dažādas atkļūdošanas metodes.

Bet, pirms izmantojat īpašus rīkus Ingress konfigurēšanai, varat izdarīt kaut ko ļoti vienkāršu. Ingress lietojumi serviceName и servicePort lai izveidotu savienojumu ar pakalpojumu. Jums jāpārbauda, ​​​​vai tie ir pareizi konfigurēti. To var izdarīt, izmantojot komandu:

kubectl describe ingress <ingress-name>

Ja kolonna Backend tukšs, pastāv liela konfigurācijas kļūdas iespējamība. Ja aizmugursistēmas ir izveidotas, bet lietojumprogramma joprojām nav pieejama, problēma var būt saistīta ar:

• Piekļuves pieejamības iestatījumi no publiskā interneta;
• klasteru pieejamības iestatījumi no publiskā interneta.

Jūs varat noteikt problēmas ar infrastruktūru, izveidojot tiešu savienojumu ar Ingress pod. Lai to izdarītu, vispirms atrodiet ieejas kontrollera podziņu (tas var būt citā nosaukumvietā):

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

Izmantojiet komandu describelai iestatītu portu:

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

Visbeidzot, izveidojiet savienojumu ar podziņu:

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

Tagad visi datora 3000. porta pieprasījumi tiks novirzīti uz podziņas 80. portu.

Vai tas tagad darbojas?

• Ja jā, tad problēma ir infrastruktūrā. Ir precīzi jānoskaidro, kā satiksme tiek novirzīta uz klasteri.
• Ja nē, tad problēma ir Ingress kontrollerī.

Ja nevarat panākt, lai Ingress kontrolieris darbotos, jums tas būs jāatkļūdo.

Ir daudz dažādu Ingress kontrolieru. Populārākie ir Nginx, HAProxy, Traefik utt. (lai iegūtu plašāku informāciju par esošajiem risinājumiem, sk mūsu pārskats — apm. tulk.) Skatiet traucējummeklēšanas rokasgrāmatu attiecīgā kontrollera dokumentācijā. Tāpēc ka Ingress Nginx ir vispopulārākais Ingress kontrolieris, rakstā esam iekļāvuši dažus padomus ar to saistīto problēmu risināšanai.

Ingress Nginx kontrollera atkļūdošana

Ingress-nginx projektam ir amatpersona kubectl spraudnis. Komanda kubectl ingress-nginx var izmantot:

• žurnālu, aizmugursistēmu, sertifikātu uc analīze;
• savienojumi ar Ingress;
• pašreizējās konfigurācijas izpēte.

Šīs trīs komandas jums to palīdzēs:

• kubectl ingress-nginx lint - pārbaudes nginx.conf;
• kubectl ingress-nginx backend — pēta aizmuguri (līdzīgi kā kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs — pārbauda žurnālus.

Ņemiet vērā, ka dažos gadījumos, izmantojot karodziņu, var būt nepieciešams norādīt pareizo Ingress kontrollera nosaukumvietu --namespace <name>.

Kopsavilkums

Kubernetes problēmu novēršana var būt sarežģīta, ja nezināt, ar ko sākt. Problēmai vienmēr vajadzētu pievērsties no apakšas uz augšu: sāciet ar podiem un pēc tam pārejiet uz pakalpojumu un Ingress. Šajā rakstā aprakstītās atkļūdošanas metodes var izmantot citiem objektiem, piemēram:

• dīkstāves darbi un CronJobs;
• StatefulSets un DaemonSets.

Es izsaku savu pateicību Gergely Risko, Daniels Veibels и Čārlzs Kristirajs par vērtīgiem komentāriem un papildinājumiem.

PS no tulka

Lasi arī mūsu emuārā:

• «kubectl-debug spraudnis atkļūdošanai Kubernetes podiņos";
• «6 izklaidējošas sistēmas kļūdas Kubernetes darbībā [un to risinājums]";
• «Rīki lietojumprogrammu izstrādātājiem, kas darbojas Kubernetes";
• «6 praktiski stāsti no mūsu SRE ikdienas '.

Avots: www.habr.com