Pandhuan Visual kanggo Ngatasi Masalah Kubernetes

Cathetan. nerjemahake.: Artikel iki minangka bagéan saka materi proyek sing diterbitake ing domain umum sinau8s, perusahaan latihan lan administrator individu kanggo nggarap Kubernetes. Ing kono, Daniele Polencic, manajer proyek, nuduhake instruksi visual babagan langkah-langkah sing kudu ditindakake yen ana masalah umum karo aplikasi sing mlaku ing kluster K8s.

TL; DR: iki diagram sing bakal mbantu sampeyan debug penyebaran ing Kubernetes:

Flowchart kanggo nemokake lan ndandani kesalahan ing kluster. Asli (ing basa Inggris) kasedhiya ing PDF и minangka gambar.

Nalika masang aplikasi menyang Kubernetes, biasane ana telung komponen sing kudu ditetepake:

• penyebaran prajurit - iki minangka resep kanggo nggawe salinan aplikasi, sing diarani pods;
• Service - imbangan beban internal sing nyebarake lalu lintas ing antarane polong;
• Ingress - katrangan babagan carane lalu lintas bakal teka saka jagad njaba menyang Layanan.

Mangkene ringkesan grafis cepet:

1) Ing Kubernetes, aplikasi nampa lalu lintas saka donya njaba liwat rong lapisan load balancer: internal lan eksternal.

2) Penyeimbang internal diarani Service, sing njaba diarani Ingress.

3) Penyebaran nggawe pod lan ngawasi (ora digawe kanthi manual).

Ayo dadi ngomong sampeyan pengin masang aplikasi prasaja a la Hello World. Konfigurasi YAML bakal katon kaya iki:

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

Dhéfinisi kasebut cukup dawa lan gampang bingung babagan hubungane komponen.

Contone:

• Nalika sampeyan kudu nggunakake port 80 lan nalika sampeyan kudu nggunakake 8080?
• Apa aku kudu nggawe port anyar kanggo saben layanan supaya ora konflik?
• Apa jeneng label penting? Apa kudu padha nang endi wae?

Sadurunge fokus ing debugging, ayo elinga kepiye telung komponen kasebut ana gandhengane. Ayo miwiti karo Penyebaran lan Layanan.

Hubungan antarane Penyebaran lan Layanan

Sampeyan bakal kaget, nanging Penyebaran lan Layanan ora ana hubungane. Nanging, Layanan nunjuk langsung menyang Pods, ngliwati Deployment.

Dadi, kita kepengin weruh kepiye Pod lan Layanan ana gandhengane. Telung perkara sing kudu dielingi:

1. pemilih (selector) kanggo Layanan kudu cocog paling ora siji label Pod.
2. targetPort kudu cocog containerPort wadhah nang Pod.
3. port Layanan bisa apa wae. Layanan sing beda bisa nggunakake port sing padha amarga duwe alamat IP sing beda.

Diagram ing ngisor iki nggambarake kabeh ing ndhuwur ing wangun grafis:

1) Bayangake manawa layanan kasebut ngarahake lalu lintas menyang pod tartamtu:

2) Nalika nggawe pod, sampeyan kudu nemtokake containerPort kanggo saben wadhah ing pods:

3) Nalika nggawe layanan, sampeyan kudu nemtokake port и targetPort. Nanging kang digunakake kanggo nyambung menyang wadhah?

4) Liwat targetPort. Iku kudu cocog containerPort.

5) Ayo dadi ngomong port 3000 mbukak ing wadhah. Banjur nilai targetPort kudu padha.

Ing file YAML, label lan 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  # <<<

Apa bab label track: canary ing ndhuwur bagean Deployment? Apa kudu cocog?

Label iki khusus penyebaran lan ora digunakake dening layanan kanggo nuntun lalu lintas. Ing tembung liyane, bisa dibusak utawa diwenehi nilai beda.

Apa babagan pamilih matchLabels?

Iku kudu tansah cocog karo label Pod, amarga digunakake dening Deployment kanggo nglacak polong.

Ayo nganggep sampeyan nggawe suntingan sing bener. Carane mriksa wong?

Sampeyan bisa mriksa label pod kanthi printah ing ngisor iki:

kubectl get pods --show-labels

Utawa, yen pod kalebu sawetara aplikasi:

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

Ngendi any-name=my-app yaiku label any-name: my-app.

Apa ana alangan sing isih ana?

Sampeyan bisa nyambung menyang pod! Kanggo nindakake iki, sampeyan kudu nggunakake printah port-forward ing kubectl. Iku ngijini sampeyan kanggo nyambung menyang layanan lan mriksa sambungan.

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

Ing kene:

• service/<service name> - jeneng layanan; ing kasus kita iku my-service;
• 3000 minangka port sing kudu dibukak ing komputer;
• 80 - port kasebut ing lapangan port layanan

Yen sambungan digawe, banjur setelan wis bener.

Yen sambungan gagal, ana masalah karo label utawa bandar ora cocog.

Hubungan antarane Layanan lan Ingress

Langkah sabanjure kanggo nyedhiyakake akses menyang aplikasi kalebu nyetel Ingress. Ingress kudu ngerti carane golek layanan, banjur golek pods lan lalu lintas langsung menyang. Ingress nemokake layanan sing dibutuhake kanthi jeneng lan port mbukak.

Ing katrangan babagan Ingress lan Layanan rong paramèter kudu cocog:

1. servicePort ing Ingress kudu cocog parameter port ing Service;
2. serviceName ing Ingress kudu cocog lapangan name ing Service.

Diagram ing ngisor iki ngringkes sambungan port:

1) Nalika sampeyan wis ngerti, Service ngrungokake tartamtu port:

2) Ingress nduweni parameter sing diarani servicePort:

3) Parameter ikiservicePort) kudu tansah cocog port ing definisi Layanan:

4) Yen port 80 kasebut ing Service, iku perlu sing servicePort uga padha karo 80:

Ing laku, sampeyan kudu menehi perhatian marang garis ing ngisor iki:

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

Kepiye cara mriksa yen Ingress mlaku?

Sampeyan bisa nggunakake cara karo kubectl port-forward, nanging tinimbang layanan sampeyan kudu nyambung menyang controller Ingress.

Pisanan sampeyan kudu ngerteni jeneng pod karo pengontrol 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

Temokake pod Ingress (bisa uga ana ing papan jeneng sing beda) lan jalanake perintah kasebut describekanggo ngerteni nomer port:

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

Pungkasan, sambungake menyang pod:

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

Saiki saben-saben sampeyan ngirim panjalukan menyang port 3000 ing komputer, bakal diterusake menyang port 80 saka pod karo pengontrol Ingress. Kanthi arep http://localhost:3000, sampeyan kudu ndeleng kaca sing digawe dening aplikasi.

Ringkesan bandar

Ayo elinga maneh port lan label sing kudu cocog:

1. Pamilih ing definisi Layanan kudu cocog karo label pod;
2. targetPort ing Service definisi kudu cocog containerPort wadhah ing njero polong;
3. port ing definisi Service bisa apa wae. Layanan sing beda bisa nggunakake port sing padha amarga duwe alamat IP sing beda;
4. servicePort Ingress kudu cocog port ing definisi Service;
5. Jeneng layanan kudu cocog karo lapangan serviceName ing Ingress.

Sayange, ora cukup ngerti carane nggawe konfigurasi YAML kanthi bener.

Apa sing kedadeyan nalika ana masalah?

Pod bisa uga ora diwiwiti utawa bisa nabrak.

3 Langkah kanggo Diagnosa Masalah Aplikasi ing Kubernetes

Sadurunge miwiti debugging panyebaran, sampeyan kudu ngerti cara kerja Kubernetes.

Wiwit saben aplikasi diundhuh ing K8s wis telung komponen, padha kudu debugged ing urutan tartamtu, wiwit saka ngisor banget.

1. Pisanan sampeyan kudu mesthekake yen pods bisa digunakake, banjur ...
2. Priksa manawa layanan nyedhiyakake lalu lintas menyang pods, banjur...
3. Priksa manawa Ingress dikonfigurasi kanthi bener.

Representasi visual:

1) Sampeyan kudu miwiti nggoleki masalah saka ngisor. Pisanan priksa manawa pod duwe status Ready и Running:

2) Yen polong wis siap (Ready), sampeyan kudu ngerteni manawa layanan kasebut nyebarake lalu lintas ing antarane pods:

3) Pungkasan, sampeyan kudu nganalisa sambungan antarane layanan lan Ingress:

1. Diagnostik saka pods

Umume kasus, masalah kasebut ana gandhengane karo polong. Priksa manawa pods kadhaptar minangka Ready и Running. Sampeyan bisa mriksa iki nggunakake printah:

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

Ing output printah ndhuwur, polong pungkasan kadhaptar minangka Running и Ready, Nanging, iki ora cilik kanggo loro liyane.

Kepiye carane ngerti apa sing salah?

Ana papat prentah sing migunani kanggo diagnosa pod:

1. kubectl logs <имя pod'а> ngijini sampeyan kanggo extract log saka wadhah ing pod;
2. kubectl describe pod <имя pod'а> ngidini sampeyan ndeleng dhaptar acara sing ana gandhengane karo pod;
3. kubectl get pod <имя pod'а> ngidini sampeyan entuk konfigurasi YAML saka pod sing disimpen ing Kubernetes;
4. kubectl exec -ti <имя pod'а> bash ngidini sampeyan miwiti cangkang printah interaktif ing salah sawijining wadhah pod

Sampeyan kudu milih sing endi?

Kasunyatane ora ana prentah universal. Kombinasi iki kudu digunakake.

Masalah podho khas

Ana rong jinis utama kesalahan pod: kesalahan wiwitan lan kesalahan runtime.

Kesalahan wiwitan:

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

Kesalahan Runtime:

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

Sawetara kesalahan luwih umum tinimbang liyane. Ing ngisor iki sawetara kesalahan sing paling umum lan cara ndandani.

ImagePullBackOff

Kesalahan iki kedadeyan nalika Kubernetes ora bisa njupuk gambar kanggo salah sawijining wadhah pod. Mangkene telung alasan sing paling umum kanggo iki:

1. Jeneng gambar ora bener - contone, sampeyan nggawe kesalahan, utawa gambar kasebut ora ana;
2. Tag sing ora ana ditetepake kanggo gambar kasebut;
3. Gambar kasebut disimpen ing registri pribadi lan Kubernetes ora duwe idin kanggo ngakses.

Loro alasan pisanan gampang diilangi - mung mbenerake jeneng gambar lan tag. Ing kasus sing terakhir, sampeyan kudu ngetik kredensial kanggo registri sing ditutup ing Rahasia lan nambah pranala menyang pods. Ing dokumentasi Kubernetes ana conto carane iki bisa rampung.

Kacilakan Loop Mundur Mati

Kubenetes mbuwang kesalahan CrashLoopBackOff, yen wadhah ora bisa miwiti. Iki biasane kedadeyan nalika:

1. Ana bug ing aplikasi sing ngalangi saka diluncurake;
2. Container dikonfigurasi ora bener;
3. Tes Liveness wis gagal kaping pirang-pirang.

Sampeyan kudu nyoba kanggo njaluk menyang log saka wadhah kanggo mangerteni alesan kanggo Gagal. Yen angel ngakses log amarga wadhah diwiwiti maneh kanthi cepet, sampeyan bisa nggunakake printah ing ngisor iki:

kubectl logs <pod-name> --previous

Nampilake pesen kesalahan saka inkarnasi wadhah sadurunge.

RunContainerError

Kesalahan iki kedadeyan nalika wadhah gagal diwiwiti. Iku cocog karo wayahe sadurunge aplikasi dibukak. Biasane disebabake setelan sing salah, contone:

• nyoba masang volume sing ora ana kayata ConfigMap utawa Secrets;
• nyoba kanggo masang volume mung diwaca minangka diwaca-tulis.

Tim kasebut cocog kanggo nganalisa kesalahan kasebut kubectl describe pod <pod-name>.

Pods ana ing status Pending

Sawise digawe, pod tetep ing negara Pending.

Yagene iki kedadeyan?

Mangkene sebab-sebab sing bisa ditindakake (aku nganggep manawa panjadwal bisa digunakake kanthi becik):

1. Kluster ora duwe sumber daya sing cukup, kayata daya pangolahan lan memori, kanggo mbukak pod.
2. Objek kasebut dipasang ing ruang jeneng sing cocog ResourceQuota lan nggawe pod bakal nimbulaké namespace ngluwihi kuota.
3. Pod bound kanggo Pending PersistentVolumeClaim.

Ing kasus iki, dianjurake kanggo nggunakake printah kubectl describe lan mriksa bagean Events:

kubectl describe pod <pod name>

Ing cilik saka kasalahan related kanggo ResourceQuotas, dianjurake kanggo ndeleng log kluster nggunakake printah

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

Pods ora Siap

Yen pod kadhaptar minangka Running, nanging ora ing negara Ready, tegese mriksa kesiapane (Probe kesiapan) gagal.

Yen kedadeyan kasebut, pod ora nyambung menyang layanan lan ora ana lalu lintas sing mlebu. Gagal tes kesiapan disebabake masalah ing aplikasi kasebut. Ing kasus iki, kanggo nemokake kesalahan, sampeyan kudu nganalisa bagean kasebut Events ing output printah kubectl describe.

2. Diagnosa layanan

Yen pods kadhaptar minangka Running и Ready, nanging isih ora ana respon saka aplikasi, sampeyan kudu mriksa setelan layanan.

Layanan tanggung jawab kanggo nuntun lalu lintas menyang polong gumantung saka labele. Mula, sepisanan sing kudu ditindakake yaiku mriksa jumlah pod sing bisa digunakake karo layanan kasebut. Kanggo nindakake iki, sampeyan bisa mriksa titik pungkasan ing layanan kasebut:

kubectl describe service <service-name> | grep Endpoints

Endpoint minangka pasangan nilai saka formulir kasebut <IP-адрес:порт>, lan paling ora siji pasangan kasebut kudu ana ing output (yaiku, paling ora siji pod bisa digunakake karo layanan kasebut).

Yen bagean Endpoins kosong, ana rong pilihan:

1. ora ana pod kanthi label sing bener (petunjuk: priksa manawa spasi jeneng dipilih kanthi bener);
2. Ana kesalahan ing label layanan ing pamilih.

Yen sampeyan ndeleng dhaptar endpoint nanging isih ora bisa ngakses aplikasi kasebut, kemungkinan penyebabe yaiku bug targetPort ing katrangan layanan.

Kepiye cara mriksa fungsi layanan kasebut?

Preduli saka jinis layanan, sampeyan bisa nggunakake printah kubectl port-forward kanggo nyambung menyang:

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

Ing kene:

• <service-name> - jeneng layanan;
• 3000 minangka port sing dibukak ing komputer;
• 80 - port ing sisih layanan.

3. Diagnosa ingress

Yen sampeyan wis maca nganti saiki, banjur:

• pods kadhaptar minangka Running и Ready;
• layanan kasil mbagekke lalu lintas antarane pods.

Nanging, sampeyan isih ora bisa tekan app.

Iki tegese pengontrol Ingress kemungkinan ora dikonfigurasi kanthi bener. Wiwit controller Ingress minangka komponen pihak katelu ing kluster, ana cara debugging sing beda-beda gumantung saka jinise.

Nanging sadurunge sampeyan nggunakake alat khusus kanggo ngatur Ingress, sampeyan bisa nindakake sing gampang banget. Ingress nggunakake serviceName и servicePort kanggo nyambung menyang layanan. Sampeyan kudu mriksa yen lagi dikonfigurasi kanthi bener. Sampeyan bisa nindakake iki nggunakake printah:

kubectl describe ingress <ingress-name>

Yen kolom Backend kosong, ana kemungkinan dhuwur saka kesalahan konfigurasi. Yen backends ana, nanging aplikasi kasebut isih ora bisa diakses, mula masalah kasebut bisa uga ana gandhengane karo:

• Setelan aksesibilitas ingress saka Internet umum;
• setelan aksesibilitas cluster saka Internet umum.

Sampeyan bisa ngenali masalah karo infrastruktur kanthi nyambungake langsung menyang pod Ingress. Kanggo nindakake iki, goleki pod Ingress Controller dhisik (bisa uga ana ing ruang jeneng sing beda):

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

Gunakake printah describekanggo nyetel port:

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

Pungkasan, sambungake menyang pod:

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

Saiki kabeh panjalukan kanggo port 3000 ing komputer bakal dialihake menyang port 80 saka pod.

Apa saiki bisa digunakake?

• Yen ya, masalahe ana ing infrastruktur. Sampeyan perlu kanggo mangerteni persis carane lalu lintas wis routed menyang kluster.
• Yen ora, masalahe ana ing pengontrol Ingress.

Yen sampeyan ora bisa nindakake pengontrol Ingress, sampeyan kudu debug.

Ana akeh jinis pengontrol Ingress. Sing paling populer yaiku Nginx, HAProxy, Traefik, lsp. (kanggo informasi luwih lengkap babagan solusi sing wis ana, waca review kita - kira-kira. transl.) Sampeyan kudu ngrujuk menyang pandhuan ngatasi masalah ing dokumentasi controller sing cocog. Amarga ing Ingress Nginx punika Ingress controller paling populer, kita wis klebu sawetara tips ing artikel kanggo ngatasi masalah related kanggo.

Debugging pengontrol Ingress Nginx

Ingress-nginx project wis resmi plugin kanggo kubectl. tim kubectl ingress-nginx bisa digunakake kanggo:

• analisis log, backends, sertifikat, etc.;
• sambungan menyang Ingress;
• sinau konfigurasi saiki.

Telung printah ing ngisor iki bakal mbantu sampeyan:

• kubectl ingress-nginx lint - mriksa nginx.conf;
• kubectl ingress-nginx backend - njelajah backend (padha karo kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs - mriksa log.

Elinga yen ing sawetara kasus, sampeyan kudu nemtokake spasi jeneng sing bener kanggo pengontrol Ingress nggunakake gendera --namespace <name>.

Ringkesan

Ngatasi masalah Kubernetes bisa dadi tantangan yen sampeyan ora ngerti arep miwiti saka ngendi. Sampeyan kudu tansah nyedhaki masalah saka ngisor munggah: miwiti karo pods, banjur pindhah menyang layanan lan Ingress. Teknik debugging sing diterangake ing artikel iki bisa ditrapake kanggo obyek liyane, kayata:

• Proyek idle lan CronJobs;
• StatefulSets lan DaemonSets.

Kula aturaken matur nuwun Gergely Risko, Daniel Weibel и Charles Christyraj kanggo komentar terkenal lan tambahan.

PS saka penerjemah

Waca uga ing blog kita:

• «plugin kubectl-debug kanggo debugging ing pods Kubernetes";
• «6 bug sistem sing nyenengake ing operasi Kubernetes [lan solusine]";
• «Piranti kanggo pangembang aplikasi sing mlaku ing Kubernetes";
• «6 crita praktis saka urip saben dina SRE ".

Source: www.habr.com