Isang Visual na Gabay sa Pag-troubleshoot ng Kubernetes

Tandaan. transl.: Ang artikulong ito ay bahagi ng mga materyales ng proyekto na inilathala sa pampublikong domain learnk8s, pagsasanay sa mga kumpanya at indibidwal na administrator upang makipagtulungan sa Kubernetes. Dito, si Daniele Polencic, project manager, ay nagbabahagi ng mga visual na tagubilin sa kung anong mga hakbang ang gagawin kung sakaling magkaroon ng mga pangkalahatang problema sa mga application na tumatakbo sa K8s cluster.

TL;DR: narito ang isang diagram na makakatulong sa iyong pag-debug ng deployment sa Kubernetes:

Flowchart para sa paghahanap at pag-aayos ng mga error sa isang cluster. Ang orihinal (sa Ingles) ay makukuha sa PDF и bilang larawan.

Kapag nagde-deploy ng application sa Kubernetes, karaniwang may tatlong bahagi ang kailangan mong tukuyin:

• paglawak - ito ay isang uri ng recipe para sa paglikha ng mga kopya ng application, na tinatawag na pods;
• serbisyo — internal load balancer na namamahagi ng trapiko sa mga pod;
• Pagpasok — isang paglalarawan kung paano mapupunta ang trapiko mula sa labas ng mundo patungo sa Serbisyo.

Narito ang isang mabilis na graphical na buod:

1) Sa Kubernetes, ang mga application ay tumatanggap ng trapiko mula sa labas ng mundo sa pamamagitan ng dalawang layer ng mga load balancer: panloob at panlabas.

2) Ang panloob na balanse ay tinatawag na Serbisyo, ang panlabas ay tinatawag na Ingress.

3) Ang deployment ay lumilikha ng mga pod at sinusubaybayan ang mga ito (hindi sila ginawa nang manu-mano).

Sabihin nating gusto mong mag-deploy ng isang simpleng application a la Kamusta Mundo. Ang configuration ng YAML para dito ay magiging ganito:

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 ay medyo mahaba at madaling malito kung paano nauugnay ang mga bahagi sa isa't isa.

Halimbawa:

• Kailan mo dapat gamitin ang port 80 at kailan mo dapat gamitin ang 8080?
• Dapat ba akong gumawa ng bagong port para sa bawat serbisyo para hindi sila magkasalungat?
• Mahalaga ba ang mga pangalan ng label? Dapat ba silang pareho sa lahat ng dako?

Bago tumuon sa pag-debug, tandaan natin kung paano nauugnay ang tatlong bahagi sa isa't isa. Magsimula tayo sa Deployment at Serbisyo.

Relasyon sa pagitan ng Deployment at Serbisyo

Magugulat ka, ngunit walang kaugnayan ang Deployment at Serbisyo. Sa halip, direktang tumuturo ang Serbisyo sa Mga Pod, na nilalampasan ang Deployment.

Kaya, interesado kami sa kung paano nauugnay ang Mga Pod at Serbisyo sa isa't isa. Tatlong bagay na dapat tandaan:

1. Tagapili (selector) para sa Serbisyo ay dapat tumugma sa kahit isang label ng Pod.
2. targetPort Dapat na tumugma containerPort lalagyan sa loob ng Pod.
3. port Ang serbisyo ay maaaring anuman. Ang iba't ibang mga serbisyo ay maaaring gumamit ng parehong port dahil mayroon silang iba't ibang mga IP address.

Ang sumusunod na diagram ay kumakatawan sa lahat ng nasa itaas sa graphical na anyo:

1) Isipin na ang serbisyo ay nagdidirekta ng trapiko sa isang partikular na pod:

2) Kapag gumagawa ng pod, dapat mong tukuyin containerPort para sa bawat lalagyan sa mga pod:

3) Kapag lumilikha ng isang serbisyo, dapat mong tukuyin port и targetPort. Ngunit alin ang ginagamit upang kumonekta sa lalagyan?

4) Sa pamamagitan ng targetPort. Dapat itong magkatugma containerPort.

5) Sabihin nating bukas ang port 3000 sa lalagyan. Pagkatapos ay ang halaga targetPort dapat pareho.

Sa YAML file, mga label at ports / targetPort Dapat na tumugma:

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

Ano ang tungkol sa label track: canary sa tuktok ng seksyong Deployment? Dapat ba itong tumugma?

Ang label na ito ay partikular sa deployment at hindi ginagamit ng serbisyo upang iruta ang trapiko. Sa madaling salita, maaari itong alisin o italaga ng ibang halaga.

Ano ang tungkol sa pumipili matchLabels?

Dapat itong palaging tumutugma sa mga label ng Pod, dahil ginagamit ito ng Deployment para subaybayan ang mga pod.

Ipagpalagay natin na ginawa mo ang mga tamang pag-edit. Paano suriin ang mga ito?

Maaari mong suriin ang pod label gamit ang sumusunod na command:

kubectl get pods --show-labels

O, kung nabibilang ang mga pod sa ilang application:

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

saan any-name=my-app ay isang label any-name: my-app.

Mayroon bang anumang mga paghihirap na natitira?

Maaari kang kumonekta sa pod! Upang gawin ito kailangan mong gamitin ang command port-forward sa kubectl. Pinapayagan ka nitong kumonekta sa serbisyo at suriin ang koneksyon.

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

Narito:

• service/<service name> - pangalan ng serbisyo; sa aming kaso ito ay my-service;
• 3000 ang port na kailangang buksan sa computer;
• 80 - port na tinukoy sa field port serbisyo.

Kung naitatag ang koneksyon, tama ang mga setting.

Kung nabigo ang koneksyon, may problema sa mga label o hindi tumutugma ang mga port.

Relasyon sa pagitan ng Serbisyo at Ingress

Ang susunod na hakbang sa pagbibigay ng access sa application ay kinabibilangan ng pag-set up ng Ingress. Kailangang malaman ni Ingress kung paano maghanap ng serbisyo, pagkatapos ay maghanap ng mga pod at direktang trapiko sa kanila. Hinahanap ng Ingress ang kinakailangang serbisyo ayon sa pangalan at bukas na port.

Sa paglalarawan ng Ingress at Serbisyo, dapat magkatugma ang dalawang parameter:

1. servicePort sa Ingress ay dapat tumugma sa parameter port sa serbisyo;
2. serviceName sa Ingress ay dapat tumugma sa field name sa serbisyo.

Ang sumusunod na diagram ay nagbubuod sa mga koneksyon sa port:

1) Tulad ng alam mo na, nakikinig ang Serbisyo sa isang tiyak port:

2) Ang Ingress ay may isang parameter na tinatawag servicePort:

3) Ang parameter na ito (servicePort) dapat palaging magkatugma port sa kahulugan ng Serbisyo:

4) Kung ang port 80 ay tinukoy sa Serbisyo, kung gayon kinakailangan iyon servicePort ay katumbas din ng 80:

Sa pagsasagawa, kailangan mong bigyang pansin ang mga sumusunod na 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: /

Paano suriin kung tumatakbo ang Ingress?

Maaari mong gamitin ang pamamaraan na may kubectl port-forward, ngunit sa halip na ang serbisyo ay kailangan mong kumonekta sa Ingress controller.

Una kailangan mong malaman ang pangalan ng pod na may 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

Hanapin ang Ingress pod (maaaring nasa ibang namespace ito) at patakbuhin ang command describepara malaman ang mga port number:

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

Panghuli, kumonekta sa pod:

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

Ngayon sa tuwing magpapadala ka ng kahilingan sa port 3000 sa iyong computer, ipapasa ito sa port 80 ng pod na may Ingress controller. Sa pamamagitan ng pagpunta sa http://localhost:3000, dapat mong makita ang pahina na nabuo ng application.

Buod ng mga port

Tandaan nating muli kung aling mga port at label ang dapat tumugma:

1. Ang tagapili sa kahulugan ng Serbisyo ay dapat tumugma sa label ng pod;
2. targetPort sa kahulugan Dapat tumugma ang Serbisyo containerPort lalagyan sa loob ng pod;
3. port sa kahulugan Serbisyo ay maaaring kahit ano. Ang iba't ibang serbisyo ay maaaring gumamit ng parehong port dahil mayroon silang iba't ibang mga IP address;
4. servicePort Dapat tumugma ang ingress port sa kahulugan ng Serbisyo;
5. Dapat tumugma ang pangalan ng serbisyo sa field serviceName sa Ingress.

Sa kasamaang palad, hindi sapat na malaman kung paano maayos na buuin ang isang configuration ng YAML.

Ano ang mangyayari kapag nagkamali?

Maaaring hindi magsimula ang pod o maaari itong mag-crash.

3 Mga Hakbang sa Pag-diagnose ng Mga Problema sa Application sa Kubernetes

Bago mo simulan ang pag-debug sa iyong deployment, kailangan mong magkaroon ng mahusay na pag-unawa sa kung paano gumagana ang Kubernetes.

Dahil ang bawat application na na-download sa K8s ay may tatlong bahagi, dapat silang i-debug sa isang tiyak na pagkakasunud-sunod, simula sa pinakaibaba.

1. Una kailangan mong tiyakin na ang mga pod ay gumagana, pagkatapos ay...
2. Suriin kung ang serbisyo ay nagbibigay ng trapiko sa mga pod, at pagkatapos...
3. Suriin kung ang Ingress ay na-configure nang tama.

Biswal na representasyon:

1) Dapat kang magsimulang maghanap ng mga problema mula sa pinakailalim. Suriin muna kung may mga status ang mga pod Ready и Running:

2) Kung handa na ang mga pods (Ready), dapat mong malaman kung ang serbisyo ay namamahagi ng trapiko sa pagitan ng mga pod:

3) Sa wakas, kailangan mong suriin ang koneksyon sa pagitan ng serbisyo at ng Ingress:

1. Diagnostics ng pods

Sa karamihan ng mga kaso ang problema ay nauugnay sa pod. Tiyaking nakalista ang mga pod bilang Ready и Running. Maaari mong suriin ito 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 itaas, ang huling pod ay nakalista bilang Running и Ready, gayunpaman, hindi ito ang kaso para sa iba pang dalawa.

Paano maintindihan kung ano ang naging mali?

Mayroong apat na kapaki-pakinabang na utos para sa pag-diagnose ng mga pod:

1. kubectl logs <имя pod'а> nagpapahintulot sa iyo na kunin ang mga log mula sa mga lalagyan sa isang pod;
2. kubectl describe pod <имя pod'а> nagbibigay-daan sa iyo upang tingnan ang isang listahan ng mga kaganapan na nauugnay sa pod;
3. kubectl get pod <имя pod'а> nagbibigay-daan sa iyong makuha ang configuration ng YAML ng isang pod na nakaimbak sa Kubernetes;
4. kubectl exec -ti <имя pod'а> bash nagbibigay-daan sa iyong maglunsad ng interactive na command shell sa isa sa mga pod container

Alin ang dapat mong piliin?

Ang katotohanan ay walang unibersal na utos. Ang kumbinasyon ng mga ito ay dapat gamitin.

Mga karaniwang problema sa pod

Mayroong dalawang pangunahing uri ng mga error sa pod: mga error sa pagsisimula at mga error sa runtime.

Mga error sa pagsisimula:

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

Mga error sa runtime:

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

Ang ilang mga error ay mas karaniwan kaysa sa iba. Narito ang ilan sa mga pinakakaraniwang error at kung paano ayusin ang mga ito.

ImagePullBackOff

Ang error na ito ay nangyayari kapag ang Kubernetes ay hindi makakuha ng isang imahe para sa isa sa mga pod container. Narito ang tatlong pinakakaraniwang dahilan para dito:

1. Ang pangalan ng imahe ay hindi tama - halimbawa, nagkamali ka dito, o ang imahe ay hindi umiiral;
2. Ang isang hindi umiiral na tag ay tinukoy para sa larawan;
3. Ang imahe ay naka-imbak sa isang pribadong registry at ang Kubernetes ay walang pahintulot na i-access ito.

Ang unang dalawang dahilan ay madaling alisin - itama lang ang pangalan ng larawan at tag. Sa kaso ng huli, kailangan mong magpasok ng mga kredensyal para sa saradong pagpapatala sa Lihim at magdagdag ng mga link dito sa mga pod. Sa dokumentasyon ng Kubernetes may isang halimbawa paano ito magagawa.

Pag-crash Loop Back Off

Naghagis ng error ang Kubenetes CrashLoopBackOff, kung hindi makapagsimula ang lalagyan. Karaniwan itong nangyayari kapag:

1. Mayroong isang bug sa application na pumipigil sa paglunsad nito;
2. Lalagyan na-configure nang hindi tama;
3. Ang Liveness test ay nabigo nang maraming beses.

Dapat mong subukang makarating sa mga log mula sa lalagyan upang malaman ang dahilan ng pagkabigo nito. Kung mahirap i-access ang mga log dahil masyadong mabilis mag-restart ang container, maaari mong gamitin ang sumusunod na command:

kubectl logs <pod-name> --previous

Nagpapakita ito ng mga mensahe ng error mula sa nakaraang pagkakatawang-tao ng lalagyan.

RunContainerError

Ang error na ito ay nangyayari kapag ang lalagyan ay nabigong magsimula. Ito ay tumutugma sa sandali bago ilunsad ang application. Karaniwan itong sanhi ng mga maling setting, halimbawa:

• sinusubukang i-mount ang isang hindi umiiral na volume gaya ng ConfigMap o Secrets;
• isang pagtatangkang mag-mount ng read-only na volume bilang read-write.

Ang koponan ay angkop na angkop para sa pagsusuri ng mga naturang pagkakamali kubectl describe pod <pod-name>.

Nasa Nakabinbing estado ang mga pod

Kapag nagawa na, mananatili ang pod sa estado Pending.

Bakit nangyayari ito?

Narito ang mga posibleng dahilan (Ipagpalagay ko na gumagana nang maayos ang scheduler):

1. Ang cluster ay walang sapat na mapagkukunan, tulad ng pagpoproseso ng kapangyarihan at memorya, upang patakbuhin ang pod.
2. Ang bagay ay naka-install sa naaangkop na namespace ResourceQuota at ang paggawa ng pod ay magiging sanhi ng namespace na lumampas sa quota.
3. Ang Pod ay nakasalalay sa Nakabinbin PersistentVolumeClaim.

Sa kasong ito, inirerekumenda na gamitin ang utos kubectl describe at suriin ang seksyon Events:

kubectl describe pod <pod name>

Sa kaso ng mga error na nauugnay sa ResourceQuotas, inirerekomendang tingnan ang mga cluster log gamit ang command

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

Ang mga pod ay hindi Handa

Kung nakalista ang pod bilang Running, ngunit wala sa estado Ready, ay nangangahulugan ng pagsuri sa kahandaan nito (readiness probe) nabigo.

Kapag nangyari ito, hindi kumonekta ang pod sa serbisyo at walang dumadaloy na trapiko dito. Ang pagkabigo sa pagsubok sa kahandaan ay sanhi ng mga problema sa aplikasyon. Sa kasong ito, upang mahanap ang error, kailangan mong pag-aralan ang seksyon Events sa output ng command kubectl describe.

2. Mga diagnostic ng serbisyo

Kung nakalista ang mga pod bilang Running и Ready, ngunit wala pa ring tugon mula sa application, dapat mong suriin ang mga setting ng serbisyo.

Responsable ang mga serbisyo para sa pagruruta ng trapiko sa mga pod depende sa kanilang mga label. Samakatuwid, ang unang bagay na kailangan mong gawin ay suriin kung gaano karaming mga pod ang gumagana sa serbisyo. Upang gawin ito, maaari mong suriin ang mga endpoint sa serbisyo:

kubectl describe service <service-name> | grep Endpoints

Ang Endpoint ay isang pares ng mga halaga ng form <IP-адрес:порт>, at hindi bababa sa isang ganoong pares ang dapat naroroon sa output (iyon ay, kahit isang pod ay gumagana sa serbisyo).

Kung seksyon Endpoins walang laman, dalawang opsyon ang posible:

1. walang mga pod na may tamang label (pahiwatig: tingnan kung tama ang napiling namespace);
2. May error sa mga label ng serbisyo sa selector.

Kung makakita ka ng listahan ng mga endpoint ngunit hindi pa rin ma-access ang application, ang malamang na salarin ay isang bug targetPort sa paglalarawan ng serbisyo.

Paano suriin ang pag-andar ng serbisyo?

Anuman ang uri ng serbisyo, maaari mong gamitin ang command kubectl port-forward para kumonekta dito:

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

Narito:

• <service-name> - pangalan ng serbisyo;
• 3000 ay ang port na binuksan mo sa computer;
• 80 - port sa gilid ng serbisyo.

3. Mga diagnostic sa pagpasok

Kung nabasa mo na hanggang dito, kung gayon:

• ang mga pod ay nakalista bilang Running и Ready;
• matagumpay na namamahagi ang serbisyo ng trapiko sa mga pod.

Gayunpaman, hindi mo pa rin maabot ang app.

Nangangahulugan ito na ang Ingress controller ay malamang na hindi na-configure nang tama. Dahil ang Ingress controller ay isang third-party na bahagi sa cluster, mayroong iba't ibang paraan ng pag-debug depende sa uri nito.

Ngunit bago ka gumamit ng mga espesyal na tool upang i-configure ang Ingress, magagawa mo ang isang bagay na napakasimple. Ginagamit ang ingress serviceName и servicePort upang kumonekta sa serbisyo. Kailangan mong suriin kung ang mga ito ay na-configure nang tama. Magagawa mo ito gamit ang command:

kubectl describe ingress <ingress-name>

Kung kolum Backend walang laman, may mataas na posibilidad ng isang error sa pagsasaayos. Kung ang mga backend ay nasa lugar, ngunit ang application ay hindi pa rin naa-access, kung gayon ang problema ay maaaring nauugnay sa:

• Mga setting ng accessibility sa pagpasok mula sa pampublikong Internet;
• mga setting ng cluster accessibility mula sa pampublikong Internet.

Matutukoy mo ang mga problema sa imprastraktura sa pamamagitan ng direktang pagkonekta sa Ingress pod. Upang gawin ito, hanapin muna ang Ingress Controller pod (maaaring nasa ibang namespace ito):

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

Gamitin ang command describeupang itakda ang port:

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

Panghuli, kumonekta sa pod:

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

Ngayon ang lahat ng mga kahilingan sa port 3000 sa computer ay ire-redirect sa port 80 ng pod.

Gumagana ba ito ngayon?

• Kung oo, ang problema ay sa imprastraktura. Ito ay kinakailangan upang malaman nang eksakto kung paano ang trapiko ay dinadala sa cluster.
• Kung hindi, ang problema ay nasa Ingress controller.

Kung hindi mo magawang gumana ang Ingress controller, kakailanganin mong i-debug ito.

Mayroong maraming mga uri ng Ingress controllers. Ang pinakasikat ay Nginx, HAProxy, Traefik, atbp. (para sa higit pang impormasyon tungkol sa mga kasalukuyang solusyon, tingnan aming pagsusuri — tinatayang. transl.) Dapat kang sumangguni sa gabay sa pag-troubleshoot sa nauugnay na dokumentasyon ng controller. Dahil ang Ingress Nginx ay ang pinakasikat na Ingress controller, nagsama kami ng ilang tip sa artikulo para malutas ang mga problemang nauugnay dito.

Pag-debug sa Ingress Nginx controller

Ang proyektong Ingress-nginx ay may opisyal plugin para sa kubectl. Koponan kubectl ingress-nginx maaaring magamit para sa:

• pagsusuri ng mga log, backend, sertipiko, atbp.;
• mga koneksyon sa Ingress;
• pag-aaral sa kasalukuyang configuration.

Ang sumusunod na tatlong utos ay makakatulong sa iyo dito:

• kubectl ingress-nginx lint - mga tseke nginx.conf;
• kubectl ingress-nginx backend — ginalugad ang backend (katulad ng kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs — sinusuri ang mga tala.

Tandaan na sa ilang mga kaso maaaring kailanganin mong tukuyin ang tamang namespace para sa Ingress controller gamit ang flag --namespace <name>.

Buod

Maaaring maging mahirap ang pag-troubleshoot ng Kubernetes kung hindi mo alam kung saan magsisimula. Dapat mong palaging lapitan ang problema mula sa ibaba pataas: magsimula sa mga pod, at pagkatapos ay magpatuloy sa serbisyo at Ingress. Ang mga diskarte sa pag-debug na inilarawan sa artikulong ito ay maaaring ilapat sa iba pang mga bagay, tulad ng:

• Mga idle na Trabaho at CronJobs;
• StatefulSets at DaemonSets.

Ipinapahayag ko ang aking pasasalamat Gergely Risko, Daniel Weibel и Charles Christyraj para sa mahahalagang komento at karagdagan.

PS mula sa tagasalin

Basahin din sa aming blog:

• «kubectl-debug plugin para sa pag-debug sa mga Kubernetes pod";
• «6 na nakakaaliw na system bug sa pagpapatakbo ng Kubernetes [at ang kanilang solusyon]";
• «Mga tool para sa mga developer ng mga application na tumatakbo sa Kubernetes";
• «6 praktikal na kwento mula sa ating pang-araw-araw na buhay sa SRE '.

Pinagmulan: www.habr.com