Pituduh Visual pikeun Ngungkulan Kubernetes

Catetan. narjamahkeun.: Artikel ieu mangrupa bagian tina bahan proyék diterbitkeun dina domain publik diajar 8s, pausahaan pelatihan sareng pangurus individu pikeun damel sareng Kubernetes. Di jerona, Daniele Polencic, manajer proyék, ngabagi petunjuk visual ngeunaan léngkah-léngkah anu kedah dilakukeun upami aya masalah umum sareng aplikasi anu dijalankeun dina kluster K8s.

TL; DR: ieu diagram anu bakal ngabantosan anjeun panyebaran debug di Kubernetes:

Flowchart pikeun manggihan jeung ngalereskeun kasalahan dina klaster. Aslina (dina basa Inggris) sayogi di PDF и sakumaha gambar.

Nalika nyebarkeun aplikasi ka Kubernetes, biasana aya tilu komponén anu anjeun kedah tangtoskeun:

• deployment - ieu mangrupikeun resep pikeun nyiptakeun salinan aplikasi, anu disebut pods;
• palayanan - balancer beban internal anu ngadistribusikaeun lalulintas diantara pods;
• Ingress - pedaran kumaha lalulintas bakal meunang ti dunya luar ka Service nu.

Ieu kasimpulan grafis gancang:

1) Dina Kubernetes, aplikasi nampi lalu lintas ti dunya luar ngaliwatan dua lapisan penyeimbang beban: internal sareng eksternal.

2) The balancer internal disebut Service, hiji éksternal disebut Ingress.

3) Deployment nyiptakeun pods sareng ngawas aranjeunna (henteu didamel sacara manual).

Hayu urang nyebutkeun rék nyebarkeun hiji aplikasi basajan a la Hello Dunya. Konfigurasi YAML pikeun éta bakal siga kieu:

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

Watesanna cukup panjang sareng gampang bingung ngeunaan kumaha hubungan komponén-komponén.

Contona:

• Iraha anjeun kedah nganggo port 80 sareng iraha anjeun kedah nganggo 8080?
• Naha kuring kedah ngadamel palabuhan énggal pikeun tiap jasa supados henteu konflik?
• Naha ngaran labél penting? Naha aranjeunna kedah sami di mana waé?

Sateuacan fokus kana debugging, hayu urang émut kumaha hubungan tilu komponén éta. Hayu urang mimitian ku Deployment and Service.

Hubungan antara Deployment jeung Service

Anjeun bakal reuwas, tapi Panyebaran sareng Jasa henteu aya hubunganana. Gantina, Service nunjuk langsung ka Pods, bypassing Deployment.

Ku kituna, urang kabetot dina kumaha Pods and Services aya hubunganana. Tilu hal anu kudu diinget:

1. Pamilih (selector) pikeun Service kudu cocog sahanteuna hiji labél Pod.
2. targetPort kudu cocog containerPort wadahna jero Pod.
3. port Service tiasa nanaon. Ladenan anu béda tiasa nganggo port anu sami sabab gaduh alamat IP anu béda.

Diagram di handap ieu ngagambarkeun sakabéh di luhur dina bentuk grafis:

1) Bayangkeun yén jasa éta ngarahkeun lalu lintas ka pod anu tangtu:

2) Nalika nyieun pod, Anjeun kudu nangtukeun containerPort pikeun tiap wadah dina pods:

3) Nalika nyieun jasa, anjeun kudu nangtukeun port и targetPort. Tapi anu mana anu dianggo pikeun nyambungkeun kana wadahna?

4) Liwat targetPort. Éta kedah cocog containerPort.

5) Hayu urang nyebutkeun port 3000 kabuka dina wadahna. Lajeng nilai targetPort kudu sarua.

Dina file YAML, labél jeung ports / targetPort kudu cocog:

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

Naon ngeunaan labél track: canary di luhureun bagian deployment? Kedah cocog?

labél ieu deployment husus sarta henteu dipaké ku jasa pikeun lalulintas ruteu. Dina basa sejen, eta bisa dihapus atawa ditugaskeun nilai béda.

Kumaha upami pamilih matchLabels?

Éta kedah salawasna cocog sareng labél Pod, saprak dipaké ku Deployment lagu pods.

Hayu urang anggap anjeun nyieun éditan bener. Kumaha pariksa aranjeunna?

Anjeun tiasa pariksa labél pod kalayan paréntah di handap ieu:

kubectl get pods --show-labels

Atawa, lamun pods milik sababaraha aplikasi:

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

di mana any-name=my-app mangrupa labél any-name: my-app.

Naha aya kasusah anu tinggaleun?

Anjeun tiasa nyambung ka pod! Jang ngalampahkeun ieu anjeun kudu make paréntah port-forward di kubectl. Eta ngidinan Anjeun pikeun nyambung ka layanan jeung pariksa sambungan.

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

Kieu:

• service/<service name> - ngaran jasa; dina hal urang éta my-service;
• 3000 mangrupikeun palabuhan anu kedah dibuka dina komputer;
• 80 - port dieusian dina widang port palayanan.

Upami sambungan didamel, maka setélanna leres.

Upami sambunganna gagal, aya masalah sareng labél atanapi palabuhan henteu cocog.

Hubungan antara Service jeung Ingress

Léngkah salajengna dina nyayogikeun aksés kana aplikasi ngalibatkeun nyetél Ingress. Ingress kedah terang kumaha milarian jasa, teras milarian pods sareng lalu lintas langsung ka aranjeunna. Ingress mendakan jasa anu diperyogikeun ku nami sareng port kabuka.

Dina pedaran Ingress sareng Service dua parameter kedah cocog:

1. servicePort dina Ingress kedah cocog parameter port dina Service;
2. serviceName di Ingress kedah cocog lapangan name dina Service.

Diagram di handap ieu nyimpulkeun sambungan port:

1) Sakumaha anjeun parantos terang, Service ngadangukeun anu tangtu port:

2) Ingress boga parameter disebut servicePort:

3) Parameter ieu (servicePort) kudu salawasna cocog port dina definisi Service:

4) Lamun port 80 dieusian dina Service, mangka diperlukeun éta servicePort éta ogé sarua jeung 80:

Dina prakték, Anjeun kudu nengetan garis handap:

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

Kumaha pariksa upami Ingress jalan?

Anjeun tiasa make metoda kalawan kubectl port-forward, Tapi tinimbang jasa anjeun kudu nyambung ka controller Ingress.

Mimiti anjeun kedah terang nami pod sareng pangontrol 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

Manggihan pod Ingress (bisa jadi dina spasi ngaran béda) tur ngajalankeun paréntah describepikeun manggihan nomer port:

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

Tungtungna, sambungkeun ka pod:

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

Ayeuna unggal waktos Anjeun ngirim pamenta ka port 3000 dina komputer Anjeun, eta bakal diteruskeun ka port 80 tina pod jeung controller Ingress. Ku akang http://localhost:3000, Anjeun kudu ningali kaca dihasilkeun ku aplikasi.

Ihtisar palabuhan

Hayu urang émut sakali deui palabuhan sareng labél mana anu kedah cocog:

1. Pamilih dina harti Service kudu cocog labél pod urang;
2. targetPort dina harti Service kudu cocog containerPort wadahna jero pod a;
3. port dina harti Service bisa nanaon. jasa béda bisa make port sarua sabab boga alamat IP béda;
4. servicePort Ingress kedah cocog port dina harti Service;
5. Ngaran jasa kedah cocog sareng sawah serviceName di Ingress.

Hanjakalna, teu cekap terang kumaha leres nyusun konfigurasi YAML.

Naon anu lumangsung nalika hal-hal anu salah?

Pod moal ngamimitian atanapi tiasa ngadat.

3 Léngkah pikeun Diagnosis Masalah Aplikasi dina Kubernetes

Sateuacan anjeun ngamimitian debugging panyebaran anjeun, anjeun kedah gaduh pamahaman anu hadé ngeunaan cara Kubernetes jalan.

Kusabab unggal aplikasi diundeur di K8s boga tilu komponén, maranéhanana kudu debugged dina urutan nu tangtu, mimitian ti pisan handap.

1. Mimiti anjeun kedah mastikeun yén pods berpungsi, teras ...
2. Pariksa naha jasa nyayogikeun lalu lintas ka pods, teras...
3. Pariksa lamun Ingress geus ngonpigurasi leres.

Répréséntasi visual:

1) Anjeun kudu ngamimitian néangan masalah ti pisan handap. Pariksa heula yén pods gaduh status Ready и Running:

2) Lamun polong geus siap (Ready), anjeun kedah terang naha jasa éta nyebarkeun lalu lintas antara pods:

3) Tungtungna, anjeun kedah nganalisis sambungan antara jasa sareng Ingress:

1. Diagnostics of pods

Dina kalolobaan kasus, masalahna aya hubunganana sareng pod. Pastikeun pods didaptarkeun salaku Ready и Running. Anjeun tiasa pariksa ieu nganggo paréntah:

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

Dina kaluaran paréntah di luhur, pod panungtungan didaptarkeun salaku Running и Ready, kumaha oge, ieu teu kasus pikeun dua lianna.

Kumaha ngartos naon anu salah?

Aya opat paréntah anu mangpaat pikeun ngadiagnosis pods:

1. kubectl logs <имя pod'а> ngamungkinkeun anjeun nimba log tina peti dina pod;
2. kubectl describe pod <имя pod'а> ngidinan Anjeun pikeun nempo daptar acara pakait sareng pod nu;
3. kubectl get pod <имя pod'а> ngidinan Anjeun pikeun meunangkeun konfigurasi YAML tina pod disimpen di Kubernetes;
4. kubectl exec -ti <имя pod'а> bash ngidinan Anjeun pikeun ngajalankeun cangkang paréntah interaktif dina salah sahiji wadah pod

Nu mana nu kudu dipilih?

Kanyataan yén teu aya paréntah universal. Kombinasi ieu kedah dianggo.

Masalah pod has

Aya dua jenis utama kasalahan pod: kasalahan ngamimitian jeung kasalahan runtime.

Kasalahan ngamimitian:

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

Kasalahan runtime:

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

Sababaraha kasalahan anu leuwih umum ti batur. Ieu sababaraha kasalahan anu paling umum sareng kumaha carana ngalereskeunana.

ImagePullBackOff

Kasalahan ieu lumangsung nalika Kubernetes henteu tiasa nyandak gambar pikeun salah sahiji wadah pod. Ieu tilu alesan anu paling umum pikeun ieu:

1. Ngaran gambar henteu leres - contona, anjeun ngalakukeun kasalahan dina éta, atanapi gambarna henteu aya;
2. A tag non-existent ieu dieusian pikeun gambar;
3. Gambar disimpen dina pendaptaran swasta sareng Kubernetes henteu gaduh idin pikeun ngaksés éta.

Dua alesan munggaran gampang pikeun ngaleungitkeun - ngan ngabenerkeun nami gambar sareng tag. Dina kasus anu terakhir, anjeun kedah ngalebetkeun kredensial pikeun pendaptaran anu ditutup dina Rahasia sareng nambihan tautan kana éta dina pods. Dina dokuméntasi Kubernetes aya conto kumaha ieu tiasa dilakukeun.

Kacilakaan Loop Balik Pareum

Kubenetes ngalungkeun kasalahan CrashLoopBackOff, lamun wadahna teu bisa ngamimitian. Ieu biasana lumangsung nalika:

1. Aya bug dina aplikasi nu nyegah eta ti launching;
2. wadah ngonpigurasi salah;
3. Tes Liveness parantos gagal sababaraha kali.

Anjeun kedah nyobian kéngingkeun log tina wadahna pikeun milari alesan gagalna. Upami sesah ngaksés log sabab wadahna dibalikan deui gancang, anjeun tiasa nganggo paréntah di handap ieu:

kubectl logs <pod-name> --previous

Ieu mintonkeun pesen kasalahan ti titisan saméméhna tina wadahna.

RunContainerError

Kasalahan ieu lumangsung nalika wadahna gagal ngamimitian. Éta pakait sareng waktos sateuacan aplikasi diluncurkeun. Biasana disababkeun ku setélan anu salah, contona:

• nyobian masang volume anu teu aya sapertos ConfigMap atanapi Secrets;
• usaha pikeun masang volume baca-hijina salaku baca-tulis.

Tim éta cocog pisan pikeun nganalisa kasalahan sapertos kitu kubectl describe pod <pod-name>.

Pods aya dina kaayaan Pending

Sakali dijieun, pod tetep dina kaayaan Pending.

Naha ieu kajadian?

Ieu mangrupikeun alesan anu mungkin (kuring nganggap yén scheduler berpungsi saé):

1. Kluster teu gaduh sumber anu cekap, sapertos kakuatan ngolah sareng mémori, pikeun ngajalankeun pod.
2. Obyék dipasang dina ngaranspasi luyu ResourceQuota jeung nyieun pod bakal ngabalukarkeun ngaranspasi kaluar kuota.
3. Pod kabeungkeut ka Pending PersistentVolumeClaim.

Dina hal ieu, disarankeun pikeun nganggo paréntah kubectl describe jeung pariksa bagian Events:

kubectl describe pod <pod name>

Dina hal kasalahan patali jeung ResourceQuotas, Disarankeun pikeun nempo log klaster maké paréntah

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

Pod henteu Siap

Lamun pod kadaptar salaku Running, tapi henteu dina kaayaan Ready, hartina mariksa kasiapanana (siaga kesiapan) gagal.

Nalika ieu kajantenan, pod henteu nyambung ka jasa sareng henteu aya lalulintas anu ngalir ka dinya. Gagalna tés kesiapan disababkeun ku masalah dina aplikasi. Dina hal ieu, pikeun manggihan kasalahan, Anjeun kudu nganalisis bagian Events dina kaluaran paréntah kubectl describe.

2. Diagnostik jasa

Lamun pods didaptarkeun salaku Running и Ready, tapi tetep teu aya réspon ti aplikasi, anjeun kedah parios setélan jasa.

Ladenan tanggung jawab pikeun routing lalu lintas ka pods gumantung kana labélna. Ku alatan éta, hal kahiji anu anjeun kedah laksanakeun nyaéta mariksa sabaraha pod anu tiasa dianggo sareng jasa éta. Jang ngalampahkeun ieu, anjeun tiasa pariksa titik tungtung dina jasa:

kubectl describe service <service-name> | grep Endpoints

Endpoint mangrupikeun sapasang nilai tina bentuk <IP-адрес:порт>, sarta sahanteuna hiji pasangan misalna kudu hadir dina kaluaran (nyaéta, sahanteuna hiji pod gawéna kalayan layanan nu).

Lamun bagian Endpoins kosong, dua pilihan mungkin:

1. euweuh pods kalawan labél bener (pitunjuk: pariksa lamun namespace dipilih leres);
2. Aya kasalahan dina labél jasa dina pamilih.

Upami anjeun ningali daptar titik tungtung tapi tetep teu tiasa ngaksés aplikasina, maka kamungkinan palakuna nyaéta bug targetPort dina pedaran jasa.

Kumaha pariksa pungsionalitas jasa?

Henteu paduli jinis jasa, anjeun tiasa nganggo paréntah kubectl port-forward pikeun nyambungkeunana:

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

Kieu:

• <service-name> - ngaran jasa;
• 3000 mangrupikeun port anu anjeun buka dina komputer;
• 80 - port di sisi jasa.

3. Diagnostik ingress

Upami anjeun parantos maca dugi ka ieu, teras:

• pods kadaptar salaku Running и Ready;
• jasa éta hasil ngadistribusikaeun lalulintas diantara pods.

Nanging, anjeun tetep henteu tiasa ngahontal aplikasi.

Ieu ngandung harti yén controller Ingress paling dipikaresep teu ngonpigurasi leres. Kusabab controller Ingress mangrupikeun komponén pihak katilu dina kluster, aya metode debugging anu béda-béda gumantung kana jinisna.

Tapi sateuacan anjeun nganggo alat khusus pikeun ngonpigurasikeun Ingress, anjeun tiasa ngalakukeun anu saderhana pisan. Panggunaan Ingress serviceName и servicePort pikeun nyambung ka layanan. Anjeun kedah parios upami aranjeunna dikonpigurasi leres. Anjeun tiasa ngalakukeun ieu nganggo paréntah:

kubectl describe ingress <ingress-name>

Lamun kolom Backend kosong, aya kamungkinan luhur kasalahan konfigurasi. Upami backends aya, tapi aplikasina masih teu tiasa diaksés, maka masalahna tiasa aya hubunganana sareng:

• Setelan aksesibilitas ingress tina Internét umum;
• setélan aksés kluster tina Internet umum.

Anjeun tiasa ngaidentipikasi masalah sareng infrastruktur ku cara ngahubungkeun langsung kana pod Ingress. Jang ngalampahkeun ieu, panggihan heula pod Ingress Controller (bisa jadi dina spasi ngaran béda):

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

Paké paréntah describepikeun nyetél port:

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

Tungtungna, sambungkeun ka pod:

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

Ayeuna sadaya pamundut ka port 3000 dina komputer bakal dialihkeun ka port 80 tina pod.

Dupi éta dianggo ayeuna?

• Upami enya, maka masalahna nyaéta infrastruktur. Ieu diperlukeun pikeun manggihan persis kumaha lalulintas routed ka klaster.
• Upami henteu, maka masalahna nyaéta pengontrol Ingress.

Upami anjeun henteu tiasa kéngingkeun pangontrol Ingress, anjeun kedah nga-debug éta.

Aya seueur jinis pengontrol Ingress. Anu pang populerna nyaéta Nginx, HAProxy, Traefik, jsb. (Pikeun inpormasi langkung seueur ngeunaan solusi anu tos aya, tingali ulasan urang - kira-kira. tarjamah.) Anjeun kedah tingal pituduh ngungkulan dina dokuméntasi controller relevan. Kusabab éta Ingress Nginx nyaeta pang populerna Ingress controller, kami geus kaasup sababaraha tips dina artikel pikeun ngajawab masalah nu patali jeung eta.

Debugging controller Ingress Nginx

Proyék Ingress-nginx ngagaduhan resmi plugin pikeun kubectl. Tim kubectl ingress-nginx bisa dipaké pikeun:

• analisis log, backends, sertipikat, jeung sajabana;
• sambungan kana Ingress;
• diajar konfigurasi ayeuna.

Tilu paréntah di handap ieu bakal ngabantosan anjeun:

• kubectl ingress-nginx lint - cék nginx.conf;
• kubectl ingress-nginx backend - ngajajah backend (sarupa jeung kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs - pariksa log.

Catet yén dina sababaraha kasus anjeun kedah netepkeun rohangan ngaran anu leres pikeun pangontrol Ingress nganggo bandéra --namespace <name>.

singgetan

Ngungkulan Kubernetes tiasa janten tantangan upami anjeun henteu terang dimana ngamimitian. Anjeun kedah salawasna ngadeukeutan masalah ti handap ka luhur: mimitian ku pods, lajeng ngaléngkah ka layanan na Ingress. Téhnik debugging anu dijelaskeun dina tulisan ieu tiasa diterapkeun ka objék sanés, sapertos:

• Jobs dianggurkeun sarta CronJobs;
• StatefulSets sareng DaemonSets.

Kuring ngucapkeun sukur Gergely Risko, Daniel Weibel и Charles Christyraj pikeun komentar berharga jeung tambahan.

PS ti penerjemah

Baca ogé dina blog urang:

• «plugin kubectl-debug pikeun debugging dina pods Kubernetes";
• «6 bug sistem anu pikaresepeun nalika nganggo Kubernetes [sareng solusina]";
• «Alat pikeun pamekar aplikasi anu dijalankeun dina Kubernetes";
• «6 carita praktis tina kahirupan sapopoe SRE urang ".

sumber: www.habr.com