Usa ka Biswal nga Giya sa Pag-troubleshoot sa Kubernetes

Nota. transl.: Kini nga artikulo kabahin sa mga materyales sa proyekto nga gipatik sa publikong dominyo pagkat-on8s, pagbansay sa mga kompanya ug indibidwal nga mga administrador sa pagtrabaho uban sa Kubernetes. Diha niini, si Daniele Polencic, project manager, mipaambit sa biswal nga mga instruksyon sa unsa nga mga lakang ang buhaton sa kaso sa mga kinatibuk-ang problema sa mga aplikasyon nga nagdagan sa K8s cluster.

TL; DR: ania ang usa ka diagram nga makatabang kanimo sa pag-debug sa pag-deploy sa Kubernetes:

Flowchart alang sa pagpangita ug pag-ayo sa mga sayup sa usa ka cluster. Ang orihinal (sa English) anaa sa PDF и ingon nga hulagway.

Kung nag-deploy og aplikasyon sa Kubernetes, kasagaran adunay tulo ka mga sangkap nga kinahanglan nimong ipasabut:

• deployment - kini usa ka matang sa resipe alang sa paghimo og mga kopya sa usa ka aplikasyon, nga gitawag pods;
• nga pag-alagad - internal load balancer nga nag-apod-apod sa trapiko taliwala sa mga pod;
• Ingress — usa ka paghulagway kung giunsa makuha ang trapiko gikan sa gawas sa kalibutan hangtod sa Serbisyo.

Ania ang usa ka dali nga graphical summary:

1) Sa Kubernetes, ang mga aplikasyon makadawat og trapiko gikan sa gawas nga kalibutan pinaagi sa duha ka layer sa load balancers: internal ug external.

2) Ang internal balancer gitawag og Service, ang external nga gitawag og Ingress.

3) Ang deployment nagmugna og mga pod ug nag-monitor niini (wala kini gihimo nga mano-mano).

Ingnon ta nga gusto nimong i-deploy ang usa ka yano nga aplikasyon a la Kumusta Kalibutan. Ang YAML configuration alang niini tan-awon sama niini:

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

Ang kahulugan taas kaayo ug dali nga malibog kung giunsa ang kalabutan sa mga sangkap sa usag usa.

Pananglitan:

• Kanus-a nimo gamiton ang port 80 ug kanus-a nimo gamiton ang 8080?
• Kinahanglan ba ako maghimo usa ka bag-ong pantalan alang sa matag serbisyo aron dili sila magkasumpaki?
• Importante ba ang mga ngalan sa label? Kinahanglan ba sila nga managsama bisan asa?

Sa dili pa mag-focus sa pag-debug, atong hinumdoman kung giunsa ang tulo nga mga sangkap adunay kalabotan sa usag usa. Magsugod ta sa Deployment ug Serbisyo.

Relasyon tali sa Deployment ug Serbisyo

Matingala ka, apan ang Mga Deployment ug Serbisyo dili konektado sa bisan unsang paagi. Hinuon, ang Serbisyo direkta nga nagpunting sa Pods, nga nag-bypass sa Deployment.

Sa ingon, kami interesado kung giunsa ang mga Pod ug Mga Serbisyo nalambigit sa usag usa. Tulo ka butang nga hinumduman:

1. Tigpili (selector) para sa Serbisyo kinahanglang motakdo sa labing menos usa ka Pod label.
2. targetPort kinahanglan magkaparehas containerPort sudlanan sulod sa Pod.
3. port Ang serbisyo mahimong bisan unsa. Ang lainlaing mga serbisyo mahimong mogamit sa parehas nga pantalan tungod kay sila adunay lainlaing mga adres sa IP.

Ang mosunod nga diagram nagrepresentar sa tanan sa ibabaw sa graphical nga porma:

1) Hunahunaa nga ang serbisyo nagdumala sa trapiko sa usa ka piho nga pod:

2) Sa paghimo og usa ka pod, kinahanglan nimong ipiho containerPort alang sa matag sudlanan sa pods:

3) Kung maghimo ka usa ka serbisyo, kinahanglan nimo ipiho port и targetPort. Apan hain ang gigamit sa pagkonektar sa sudlanan?

4) Pinaagi sa targetPort. Kinahanglan nga magkatugma containerPort.

5) Ingnon ta nga ang port 3000 bukas sa sudlanan. Unya ang bili targetPort dapat pareho ra.

Sa YAML file, mga label ug ports / targetPort kinahanglan nga magkaparehas:

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

Unsa ang mahitungod sa label track: canary sa ibabaw nga bahin sa Deployment? Kinahanglan ba nga magkaparehas?

Kini nga label kay espesipiko sa deployment ug wala gigamit sa serbisyo sa pagruta sa trapiko. Sa laing pagkasulti, mahimo kining tangtangon o i-assign og lain nga kantidad.

Unsa ang mahitungod sa tigpili matchLabels?

Kinahanglan kini kanunay nga mohaum sa mga label sa Pod, tungod kay gigamit kini sa Deployment aron masubay ang mga pod.

Ibutang ta nga nakahimo ka sa husto nga mga pag-edit. Unsaon pagsusi kanila?

Mahimo nimong susihon ang pod label gamit ang mosunod nga sugo:

kubectl get pods --show-labels

O, kung ang mga pod nahisakop sa daghang mga aplikasyon:

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

Diin any-name=my-app usa ka label any-name: my-app.

Aduna bay mga kalisdanan nga nahabilin?

Mahimo ka makonektar sa pod! Aron mahimo kini kinahanglan nimo nga gamiton ang mando port-forward sa kubectl. Gitugotan ka niini nga makonektar sa serbisyo ug susihon ang koneksyon.

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

Здесь:

• service/<service name> - ngalan sa serbisyo; sa atong kaso mao kini my-service;
• Ang 3000 mao ang pantalan nga kinahanglan ablihan sa kompyuter;
• 80 - port nga gitakda sa field port serbisyo.

Kung ang koneksyon natukod, nan ang mga setting husto.

Kung mapakyas ang koneksyon, adunay problema sa mga label o dili magkatugma ang mga pantalan.

Relasyon tali sa Serbisyo ug Ingress

Ang sunod nga lakang sa paghatag og access sa aplikasyon may kalabutan sa pag-set up sa Ingress. Kinahanglan mahibal-an ni Ingress kung giunsa pagpangita ang usa ka serbisyo, dayon pangitaa ang mga pod ug direkta nga trapiko sa kanila. Gipangita sa Ingress ang gikinahanglan nga serbisyo pinaagi sa ngalan ug bukas nga pantalan.

Sa paghulagway sa Ingress ug Serbisyo duha ka mga parametro kinahanglan nga magkatugma:

1. servicePort sa Ingress kinahanglan nga motakdo sa parameter port sa Serbisyo;
2. serviceName sa Ingress kinahanglan nga motakdo sa uma name sa Serbisyo.

Ang mosunod nga diagram nag-summarize sa mga koneksyon sa pantalan:

1) Sama sa nahibal-an na nimo, ang Serbisyo naminaw sa usa ka piho port:

2) Ang Ingress adunay usa ka parameter nga gitawag servicePort:

3) Kini nga parameter (servicePort) kinahanglang magkaparehas kanunay port sa kahulugan sa Serbisyo:

4) Kung ang port 80 gipiho sa Serbisyo, nan kinahanglan kana servicePort katumbas usab sa 80:

Sa praktis, kinahanglan nimo nga hatagan pagtagad ang mosunod nga mga linya:

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

Giunsa pagsusi kung nagdagan ang Ingress?

Mahimo nimong gamiton ang pamaagi sa kubectl port-forward, apan imbis sa serbisyo kinahanglan nimo nga makonektar sa Ingress controller.

Una kinahanglan nimo nga mahibal-an ang ngalan sa pod nga adunay Ingress controller:

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

Pangitaa ang Ingress pod (mahimo kini sa lain nga namespace) ug padagana ang command describearon mahibal-an ang mga numero sa port:

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

Sa katapusan, sumpay sa pod:

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

Karon sa matag higayon nga magpadala ka og hangyo sa port 3000 sa imong computer, kini ipasa ngadto sa port 80 sa pod uban sa Ingress controller. Pinaagi sa pag-adto sa http://localhost:3000, kinahanglan nimong makita ang panid nga gihimo sa aplikasyon.

Sumaryo sa mga pantalan

Atong hinumdoman pag-usab kung unsang mga pantalan ug mga label ang kinahanglan nga magkatugma:

1. Ang tigpili sa kahulugan sa Serbisyo kinahanglang mohaum sa label sa pod;
2. targetPort sa kahulugan Ang serbisyo kinahanglan nga magkatugma containerPort sudlanan sulod sa pod;
3. port sa kahulugan Serbisyo mahimong bisan unsa. Ang lainlaing mga serbisyo mahimong mogamit sa parehas nga pantalan tungod kay adunay lainlaing mga adres sa IP;
4. servicePort Kinahanglan nga magkatugma ang ingres port sa kahulugan sa Serbisyo;
5. Ang ngalan sa serbisyo kinahanglang motakdo sa field serviceName sa Ingress.

Ikasubo, dili igo nga mahibal-an kung giunsa ang husto nga pag-istruktura sa usa ka pagsumpo sa YAML.

Unsa ang mahitabo kung ang mga butang mahimong dili maayo?

Ang pod mahimong dili magsugod o kini ma-crash.

3 Mga Lakang sa Pag-diagnose sa mga Problema sa Paggamit sa Kubernetes

Sa dili ka pa magsugod sa pag-debug sa imong deployment, kinahanglan nimo nga adunay maayo nga pagsabut kung giunsa ang Kubernetes molihok.

Tungod kay ang matag aplikasyon nga gi-download sa K8s adunay tulo ka mga sangkap, kini kinahanglan nga i-debug sa usa ka piho nga han-ay, sugod sa pinakaubos.

1. Una kinahanglan nimo nga masiguro nga ang mga pod nagtrabaho, unya ...
2. Susiha kung ang serbisyo naghatag ug trapiko sa mga pod, ug dayon...
3. Susiha kung ang Ingress gi-configure sa husto.

Biswal nga representasyon:

1) Kinahanglan ka magsugod sa pagpangita sa mga problema gikan sa pinakaubos. Susiha una kung ang mga pod adunay mga status Ready и Running:

2) Kung andam na ang mga pods (Ready), kinahanglan nimong mahibal-an kung ang serbisyo nag-apod-apod sa trapiko tali sa mga pod:

3) Sa katapusan, kinahanglan nimo analisa ang koneksyon tali sa serbisyo ug sa Ingress:

1. Diagnostics sa mga pod

Sa kadaghanan nga mga kaso, ang problema adunay kalabotan sa pod. Siguruha nga ang mga pod gilista ingon Ready и Running. Mahimo nimong susihon kini gamit ang command:

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

Sa command output sa ibabaw, ang katapusan nga pod gilista ingon Running и Ready, bisan pa niana, dili kini ang kahimtang sa laing duha.

Sa unsa nga paagi sa pagsabut kon unsa ang nahitabo?

Adunay upat ka mapuslanon nga mga sugo alang sa pag-diagnose sa mga pod:

1. kubectl logs <имя pod'а> nagtugot kanimo sa pagkuha sa mga troso gikan sa mga sudlanan sa usa ka pod;
2. kubectl describe pod <имя pod'а> nagtugot kanimo sa pagtan-aw sa usa ka lista sa mga panghitabo nga nalangkit sa pod;
3. kubectl get pod <имя pod'а> nagtugot kanimo sa pagkuha sa YAML configuration sa usa ka pod nga gitipigan sa Kubernetes;
4. kubectl exec -ti <имя pod'а> bash nagtugot kanimo sa paglansad sa usa ka interactive command shell sa usa sa mga sudlanan sa pod

Hain ang imong pilion?

Ang kamatuoran mao nga walay universal nga sugo. Ang kombinasyon niini kinahanglang gamiton.

Kasagaran pod nga mga problema

Adunay duha ka nag-unang matang sa pod errors: startup errors ug runtime errors.

Mga sayop sa pagsugod:

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

Mga sayop sa runtime:

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

Ang ubang mga sayop mas komon kay sa uban. Ania ang pipila sa labing kasagaran nga mga sayup ug kung giunsa kini pag-ayo.

ImagePullBackOff

Kini nga sayup makita kung ang Kubernetes dili makakuha usa ka imahe alang sa usa sa mga sudlanan sa pod. Ania ang tulo ka labing kasagarang mga hinungdan niini:

1. Ang ngalan sa imahe dili husto - pananglitan, nasayop ka niini, o wala ang imahe;
2. Ang usa ka wala nga tag gitino alang sa imahe;
3. Ang hulagway gitipigan sa usa ka pribadong rehistro ug ang Kubernetes walay permiso sa pag-access niini.

Ang unang duha ka rason sayon ​​nga mawagtang - itul-id lang ang ngalan sa imahe ug tag. Sa kaso sa naulahi, kinahanglan nimo nga ipasok ang mga kredensyal alang sa sirado nga rehistro sa Sekreto ug idugang ang mga link niini sa mga pod. Sa dokumentasyon sa Kubernetes adunay usa ka pananglitan unsaon kini pagbuhat.

Crash Loop Back Off

Ang Kubenetes nagbutang usa ka sayup CrashLoopBackOff, kon ang sudlanan dili makasugod. Kasagaran kini mahitabo kung:

1. Adunay usa ka bug sa aplikasyon nga nagpugong niini gikan sa paglansad;
2. Kontainer sayop nga gi-configure;
3. Ang Liveness test napakyas sa daghang mga higayon.

Kinahanglan nimong sulayan ang pagkuha sa mga troso gikan sa sudlanan aron mahibal-an ang hinungdan sa pagkapakyas niini. Kung lisud ang pag-access sa mga troso tungod kay ang sudlanan dali nga nagsugod pag-usab, mahimo nimong gamiton ang mosunud nga mando:

kubectl logs <pod-name> --previous

Nagpakita kini og mga mensahe sa sayup gikan sa miaging pagpakatawo sa sudlanan.

RunContainerError

Kini nga sayup mahitabo kung ang sudlanan mapakyas sa pagsugod. Kini katumbas sa higayon sa wala pa ang aplikasyon gilusad. Kasagaran kini tungod sa dili husto nga mga setting, pananglitan:

• misulay sa pag-mount sa usa ka wala nga gidaghanon sama sa ConfigMap o Mga Sekreto;
• pagsulay sa pag-mount sa usa ka read-only volume isip read-write.

Ang team haom kaayo sa pag-analisar sa maong mga sayop kubectl describe pod <pod-name>.

Ang mga pod anaa sa kahimtang sa Pending

Kung nahimo, ang pod nagpabilin sa estado Pending.

Nganong mahitabo ni?

Ania ang posible nga mga hinungdan (Nagtuo ko nga ang scheduler nagtrabaho nga maayo):

1. Ang cluster walay igo nga mga kapanguhaan, sama sa pagproseso sa gahum ug memorya, sa pagpadagan sa pod.
2. Ang butang gi-install sa angay nga namespace ResourceQuota ug ang paghimo og pod maoy hinungdan nga ang namespace molapas sa quota.
3. Ang Pod gigapos sa Pending PersistentVolumeClaim.

Sa kini nga kaso, girekomenda nga gamiton ang mando kubectl describe ug tan-awa ang seksyon Events:

kubectl describe pod <pod name>

Sa kaso sa mga sayop nga may kalabutan sa ResourceQuotas, girekomendar nga tan-awon ang cluster log gamit ang command

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

Ang mga pod dili andam

Kung nalista pod ingon Running, apan wala sa estado Ready, nagpasabot sa pagsusi sa pagkaandam niini (readiness probe) napakyas.

Kung kini mahitabo, ang pod dili magkonektar sa serbisyo ug walay trapiko nga moagos niini. Ang pagkapakyas sa pagsulay sa pagkaandam tungod sa mga problema sa aplikasyon. Sa kini nga kaso, aron makit-an ang sayup, kinahanglan nimo nga analisahon ang seksyon Events sa command output kubectl describe.

2. Mga diagnostic sa serbisyo

Kung ang mga pod gilista ingon Running и Ready, apan wala pa'y tubag gikan sa aplikasyon, kinahanglan nimong susihon ang mga setting sa serbisyo.

Ang mga serbisyo ang responsable sa pag-ruta sa trapiko sa mga pod depende sa ilang mga label. Busa, ang una nga butang nga kinahanglan nimong buhaton mao ang pagsusi kung pila ang mga pod nga nagtrabaho sa serbisyo. Aron mahimo kini, mahimo nimong susihon ang mga endpoint sa serbisyo:

kubectl describe service <service-name> | grep Endpoints

Ang Endpoint usa ka parisan sa mga kantidad sa porma <IP-адрес:порт>, ug labing menos usa sa ingon nga pares kinahanglan nga naa sa output (nga mao, labing menos usa ka pod ang nagtrabaho sa serbisyo).

Kung seksyon Endpoins walay sulod, duha ka opsyon ang posible:

1. walay mga pod nga adunay saktong etiketa (hint: susiha kon husto ba ang pagpili sa namespace);
2. Adunay usa ka sayup sa mga label sa serbisyo sa tigpili.

Kung nakakita ka usa ka lista sa mga endpoint apan dili gihapon maka-access sa aplikasyon, nan ang lagmit nga hinungdan mao ang usa ka bug sa targetPort sa deskripsyon sa serbisyo.

Giunsa pagsusi ang pagpaandar sa serbisyo?

Bisan unsa pa ang klase sa serbisyo, mahimo nimong gamiton ang mando kubectl port-forward aron makonektar niini:

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

Здесь:

• <service-name> - ngalan sa serbisyo;
• Ang 3000 mao ang pantalan nga imong giablihan sa kompyuter;
• 80 - pantalan sa kilid sa serbisyo.

3. Ingress diagnostics

Kung nabasa na nimo kini hangtod karon, unya:

• ang mga pod gilista isip Running и Ready;
• ang serbisyo malampuson nga nag-apod-apod sa trapiko sa mga pod.

Bisan pa, dili gihapon nimo maabot ang app.

Kini nagpasabot nga ang Ingress controller lagmit dili husto nga pag-configure. Tungod kay ang Ingress controller usa ka ikatulo nga partido nga sangkap sa cluster, adunay lainlaing mga pamaagi sa pag-debug depende sa tipo niini.

Apan sa dili ka pa mogamit sa mga espesyal nga himan aron ma-configure ang Ingress, mahimo nimo ang usa ka butang nga yano kaayo. Paggamit sa ingress serviceName и servicePort aron makonektar sa serbisyo. Kinahanglan nimong susihon kung husto ba sila nga gi-configure. Mahimo nimo kini gamit ang command:

kubectl describe ingress <ingress-name>

Kung kolum Backend walay sulod, adunay taas nga posibilidad sa usa ka sayup sa pag-configure. Kung ang mga backend naa sa lugar, apan ang aplikasyon dili gihapon ma-access, nan ang problema mahimong may kalabutan sa:

• Ingress accessibility setting gikan sa publiko nga Internet;
• cluster accessibility settings gikan sa publikong Internet.

Mahimo nimong mailhan ang mga problema sa imprastraktura pinaagi sa direktang pagkonektar sa Ingress pod. Aron mahimo kini, pangitaa una ang Ingress Controller pod (mahimo kini sa lahi nga namespace):

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

Gamita ang sugo describearon itakda ang pantalan:

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

Sa katapusan, sumpay sa pod:

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

Karon ang tanan nga mga hangyo sa port 3000 sa computer i-redirect sa port 80 sa pod.

Nagtrabaho ba kini karon?

• Kung oo, nan ang problema mao ang imprastraktura. Kinahanglan nga mahibal-an kung giunsa ang trapiko padulong sa cluster.
• Kung dili, nan ang problema anaa sa Ingress controller.

Kung dili nimo magamit ang Ingress controller, kinahanglan nimo nga i-debug kini.

Adunay daghang mga lahi sa Ingress controllers. Ang labing inila mao ang Nginx, HAProxy, Traefik, ug uban pa. (Para sa dugang nga impormasyon bahin sa kasamtangan nga mga solusyon, tan-awa atong review - gibanabana. transl.) Kinahanglang imong tan-awon ang giya sa pag-troubleshoot sa may kalabutan nga dokumentasyon sa controller. Tungod kay ang Ingress Nginx mao ang labing inila nga Ingress controller, gilakip namo ang pipila ka mga tip sa artikulo aron masulbad ang mga problema nga may kalabutan niini.

Pag-debug sa Ingress Nginx controller

Ang proyekto sa Ingress-nginx adunay opisyal plugin alang sa kubectl. Team kubectl ingress-nginx mahimong gamiton alang sa:

• pagtuki sa mga troso, backend, sertipiko, ug uban pa;
• koneksyon sa Ingress;
• pagtuon sa kasamtangan nga configuration.

Ang mosunod nga tulo ka mga sugo makatabang kanimo niini:

• kubectl ingress-nginx lint - mga tseke nginx.conf;
• kubectl ingress-nginx backend — nagsuhid sa backend (susama sa kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs - nagsusi sa mga troso.

Timan-i nga sa pipila ka mga kaso kinahanglan nimo nga ipiho ang husto nga namespace alang sa Ingress controller gamit ang bandila --namespace <name>.

Sumaryo

Ang pag-troubleshoot sa Kubernetes mahimong mahagiton kung wala ka kahibalo kung asa magsugod. Kinahanglan nimo nga kanunay nga duolon ang problema sa ubos nga paagi: magsugod sa mga pod, ug dayon magpadayon sa serbisyo ug Ingress. Ang mga pamaagi sa pag-debug nga gihulagway niini nga artikulo mahimong magamit sa ubang mga butang, sama sa:

• walay pulos nga mga Trabaho ug CronJobs;
• StatefulSets ug DaemonSets.

Akong ipahayag ang akong pasalamat Gergely Risko, Daniel Weibel и Charles Christyraj alang sa bililhong mga komento ug mga pagdugang.

PS gikan sa tighubad

Basaha usab sa among blog:

• «kubectl-debug plugin para sa pag-debug sa mga Kubernetes pod";
• «6 makapaikag nga mga bug sa sistema kung gigamit ang Kubernetes [ug ilang mga solusyon]";
• «Mga himan alang sa mga nag-develop sa mga aplikasyon nga nagdagan sa Kubernetes";
• «6 praktikal nga mga istorya gikan sa among SRE matag adlaw nga kinabuhi ".

Source: www.habr.com