Kubernetes muammolarini bartaraf etish bo'yicha vizual qo'llanma

Eslatma. tarjima.: Ushbu maqola jamoat mulkida chop etilgan loyiha materiallarining bir qismidir Learnk8s, kompaniyalar va individual ma'murlarni Kubernetes bilan ishlashga o'rgatadi. Unda loyiha menejeri Daniele Polensic K8s klasterida ishlaydigan ilovalar bilan umumiy muammolar yuzaga kelganda qanday choralar ko‘rish kerakligi haqida vizual ko‘rsatmalar bilan bo‘lishdi.

TL; DR: bu erda sizga Kubernetes-da joylashtirishni tuzatishga yordam beradigan diagramma mavjud:

Klasterdagi xatolarni topish va tuzatish uchun oqim diagrammasi. Asl nusxasi (ingliz tilida) quyidagi manzilda mavjud PDF и rasm sifatida.

Kubernetes-ga ilovani o'rnatishda odatda uchta komponentni aniqlashingiz kerak:

• Tarqatish - bu pods deb nomlangan ilova nusxalarini yaratish uchun retseptning bir turi;
• xizmat — traffikni podalar orasida taqsimlovchi ichki yuk balanslagichi;
• Kirish — trafik tashqi dunyodan Xizmatga qanday etib borishi tavsifi.

Bu erda tezkor grafik xulosa:

1) Kubernetes-da ilovalar tashqi dunyodan trafikni ikki qatlamli yuk balansi orqali qabul qiladi: ichki va tashqi.

2) Ichki balanslashtirgich Xizmat deb ataladi, tashqisi esa Ingress deb ataladi.

3) Deployment podkastlarni yaratadi va ularni nazorat qiladi (ular qo'lda yaratilmaydi).

Aytaylik, siz oddiy dasturni ishga tushirmoqchisiz Salom Dunyo. Buning uchun YAML konfiguratsiyasi quyidagicha ko'rinadi:

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

Ta'rif juda uzun va komponentlarning bir-biriga qanday bog'liqligi haqida chalkashib ketish oson.

Masalan:

• 80-portdan qachon va qachon 8080-dan foydalanish kerak?
• Ular bir-biriga zid kelmasligi uchun har bir xizmat uchun yangi port yaratishim kerakmi?
• Yorliq nomlari muhimmi? Ular hamma joyda bir xil bo'lishi kerakmi?

Nosozliklarni tuzatishga e'tibor qaratishdan oldin, keling, uchta komponent bir-biriga qanday bog'liqligini eslaylik. Joylashtirish va xizmatdan boshlaylik.

Joylashtirish va xizmat ko'rsatish o'rtasidagi munosabatlar

Siz hayron qolasiz, lekin Joylashtirish va Xizmat hech qanday tarzda bog'lanmagan. Buning o'rniga, Xizmat joylashtirishni chetlab o'tib, to'g'ridan-to'g'ri podlarga ishora qiladi.

Shunday qilib, biz podlar va xizmatlarning bir-biri bilan qanday bog'liqligi bilan qiziqamiz. Esda tutish kerak bo'lgan uchta narsa:

1. Selektor (selector) Xizmat kamida bitta Pod yorlig'iga mos kelishi kerak.
2. targetPort mos kelishi kerak containerPort Pod ichidagi konteyner.
3. port Xizmat har qanday bo'lishi mumkin. Turli xil xizmatlar bir xil portdan foydalanishi mumkin, chunki ular turli IP manzillarga ega.

Quyidagi diagramma yuqorida aytilganlarning barchasini grafik shaklda aks ettiradi:

1) Tasavvur qiling-a, xizmat trafikni ma'lum bir podkastga yo'naltiradi:

2) Podni yaratishda siz belgilashingiz kerak containerPort podalardagi har bir konteyner uchun:

3) Xizmatni yaratishda siz ko'rsatishingiz kerak port и targetPort. Lekin qaysi biri konteynerga ulanish uchun ishlatiladi?

4) orqali targetPort. U mos kelishi kerak containerPort.

5) Konteynerda 3000 port ochiq deylik.Unda qiymat targetPort bir xil bo'lishi kerak.

YAML faylida teglar va ports / targetPort mos kelishi kerak:

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

Yorliq haqida nima deyish mumkin? track: canary Joylashtirish bo'limining yuqori qismida? Bu mos kelishi kerakmi?

Bu yorliq tarqatish uchun xos boʻlib, xizmat tomonidan trafikni yoʻnaltirish uchun foydalanilmaydi. Boshqacha qilib aytganda, uni olib tashlash yoki boshqa qiymat belgilash mumkin.

Selektor haqida nima deyish mumkin? matchLabels?

U har doim Pod yorliqlariga mos kelishi kerak, chunki u Deployment tomonidan podlarni kuzatish uchun ishlatiladi.

Faraz qilaylik, siz to'g'ri tahrir qildingiz. Ularni qanday tekshirish mumkin?

Pod yorlig'ini quyidagi buyruq bilan tekshirishingiz mumkin:

kubectl get pods --show-labels

Yoki, agar podlar bir nechta ilovalarga tegishli bo'lsa:

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

Qaerda any-name=my-app yorliq hisoblanadi any-name: my-app.

Hech qanday qiyinchiliklar qoldimi?

Podga ulanishingiz mumkin! Buning uchun siz buyruqni ishlatishingiz kerak port-forward kubectl ichida. Bu sizga xizmatga ulanish va ulanishni tekshirish imkonini beradi.

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

Bu erda:

• service/<service name> - xizmat nomi; bizning holatlarimizda shunday my-service;
• 3000 - kompyuterda ochilishi kerak bo'lgan port;
• 80 - maydonda ko'rsatilgan port port xizmat.

Agar ulanish o'rnatilgan bo'lsa, unda sozlamalar to'g'ri.

Agar ulanish muvaffaqiyatsiz bo'lsa, teglar bilan muammo bor yoki portlar mos kelmaydi.

Xizmat va kirish o'rtasidagi munosabat

Ilovaga kirishni ta'minlashning keyingi bosqichi kirishni sozlashni o'z ichiga oladi. Kirish xizmatni qanday topishni bilishi, keyin podslarni topishi va ularga trafikni yo'naltirishi kerak. Ingress kerakli xizmatni nomi va ochiq port bo'yicha topadi.

Ingress va Service tavsifida ikkita parametr mos kelishi kerak:

1. servicePort Ingress parametriga mos kelishi kerak port Xizmatda;
2. serviceName Ingressda maydonga mos kelishi kerak name Xizmatda.

Quyidagi diagramma port ulanishlarini umumlashtiradi:

1) Siz allaqachon bilganingizdek, Xizmat ma'lum bir narsani tinglaydi port:

2) Ingress deb nomlangan parametrga ega servicePort:

3) bu parametr (servicePort) har doim mos kelishi kerak port Xizmat ta'rifida:

4) Xizmatda 80-port ko'rsatilgan bo'lsa, bu kerak servicePort ham 80 ga teng edi:

Amalda siz quyidagi qatorlarga e'tibor berishingiz kerak:

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

Ingress ishlayotganligini qanday tekshirish mumkin?

bilan usuldan foydalanishingiz mumkin kubectl port-forward, lekin xizmat o'rniga siz Ingress boshqaruvchisiga ulanishingiz kerak.

Avval Ingress boshqaruvchisi bilan podaning nomini bilib olishingiz kerak:

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

Kirish podini toping (u boshqa nom maydonida bo'lishi mumkin) va buyruqni bajaring describeport raqamlarini bilish uchun:

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

Nihoyat, podkastga ulaning:

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

Endi siz har safar kompyuteringizdagi 3000-portga so'rov yuborganingizda, u Ingress kontrolleri bilan podning 80-portiga yo'naltiriladi. ga borish orqali http://localhost:3000, siz ilova tomonidan yaratilgan sahifani ko'rishingiz kerak.

Portlar haqida qisqacha ma'lumot

Qaysi portlar va teglar mos kelishi kerakligini yana bir bor eslaylik:

1. Xizmat ta'rifidagi selektor pod yorlig'iga mos kelishi kerak;
2. targetPort ta'rifda Xizmat mos kelishi kerak containerPort pod ichidagi idish;
3. port ta'rifda Xizmat har qanday bo'lishi mumkin. Turli xizmatlar bir xil portdan foydalanishi mumkin, chunki ular turli IP manzillarga ega;
4. servicePort Kirish mos kelishi kerak port Xizmat ta'rifida;
5. Xizmat nomi maydonga mos kelishi kerak serviceName Ingressda.

Afsuski, YAML konfiguratsiyasini qanday qilib to'g'ri tuzishni bilishning o'zi etarli emas.

Ishlar noto'g'ri ketsa nima bo'ladi?

Pod ishga tushmasligi yoki ishdan chiqishi mumkin.

Kubernetes-da dastur muammolarini aniqlash uchun 3 qadam

Joylashtirishni tuzatishni boshlashdan oldin, siz Kubernetes qanday ishlashini yaxshi tushunishingiz kerak.

K8s-da yuklab olingan har bir dastur uchta komponentdan iborat bo'lganligi sababli, ularni eng pastdan boshlab ma'lum bir tartibda tuzatish kerak.

1. Avval podkastlar ishlayotganiga ishonch hosil qilishingiz kerak, keyin...
2. Xizmat podkastlarga trafik yetkazib berishini tekshiring va keyin...
3. Ingress to'g'ri sozlanganligini tekshiring.

Vizual taqdimot:

1) Muammolarni eng pastdan qidirishni boshlashingiz kerak. Avval podkastlarning statuslari borligini tekshiring Ready и Running:

2) Agar podalar tayyor bo'lsa (Ready), siz xizmat podkastlar o'rtasida trafikni taqsimlaydimi yoki yo'qligini bilib olishingiz kerak:

3) Va nihoyat, siz xizmat va kirish o'rtasidagi aloqani tahlil qilishingiz kerak:

1. Po‘choqlarning diagnostikasi

Ko'p hollarda muammo podkast bilan bog'liq. Podkalar ro'yxatga kiritilganligiga ishonch hosil qiling Ready и Running. Buni buyruq yordamida tekshirishingiz mumkin:

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

Yuqoridagi buyruq chiqishida oxirgi pod kabi ro'yxatga olingan Running и Ready, ammo, bu qolgan ikkitasi uchun emas.

Nima noto'g'ri bo'lganini qanday tushunish mumkin?

Podkalarni diagnostika qilish uchun to'rtta foydali buyruq mavjud:

1. kubectl logs <имя pod'а> poddagi konteynerlardan jurnallarni chiqarish imkonini beradi;
2. kubectl describe pod <имя pod'а> pod bilan bog'liq voqealar ro'yxatini ko'rish imkonini beradi;
3. kubectl get pod <имя pod'а> Kubernetes-da saqlangan podning YAML konfiguratsiyasini olish imkonini beradi;
4. kubectl exec -ti <имя pod'а> bash pod konteynerlaridan birida interaktiv buyruq qobig'ini ishga tushirish imkonini beradi

Qaysi birini tanlash kerak?

Gap shundaki, universal buyruq yo'q. Bularning kombinatsiyasidan foydalanish kerak.

Odatda podkastlar muammolari

Pod xatolarining ikkita asosiy turi mavjud: ishga tushirish xatolari va ish vaqti xatolari.

Ishga tushirish xatolari:

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

Ishlash vaqtidagi xatolar:

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

Ba'zi xatolar boshqalarga qaraganda tez-tez uchraydi. Bu erda eng keng tarqalgan xatolar va ularni tuzatish usullari keltirilgan.

ImagePullBackOff

Bu xato, Kubernetes pod konteynerlaridan biri uchun tasvirni ololmaganida yuzaga keladi. Buning eng keng tarqalgan uchta sababi:

1. Rasm nomi noto'g'ri - masalan, siz unda xato qildingiz yoki rasm mavjud emas;
2. Rasm uchun mavjud bo'lmagan teg belgilandi;
3. Rasm shaxsiy registrda saqlanadi va Kubernetes unga kirish uchun ruxsatga ega emas.

Birinchi ikkita sababni yo'q qilish oson - shunchaki rasm nomi va tegini to'g'rilang. Ikkinchisi bo'lsa, maxfiy ro'yxatga olish kitobi uchun hisob ma'lumotlarini kiritishingiz va unga havolalarni qo'shishingiz kerak. Kubernetes hujjatlarida misol bor buni qanday qilish mumkin.

Crash Loop Back Off

Kubenetes xatoga yo'l qo'ydi CrashLoopBackOff, agar konteyner ishga tushmasa. Bu odatda quyidagi hollarda sodir bo'ladi:

1. Ilovada uni ishga tushirishga to'sqinlik qiladigan xatolik mavjud;
2. Konteyner noto'g'ri sozlangan;
3. Jonlilik testi juda ko'p marta muvaffaqiyatsiz tugadi.

Muvaffaqiyatsizligi sababini bilish uchun konteynerdan jurnallarga kirishga harakat qilishingiz kerak. Agar konteyner juda tez qayta ishga tushirilganligi sababli jurnallarga kirish qiyin bo'lsa, siz quyidagi buyruqdan foydalanishingiz mumkin:

kubectl logs <pod-name> --previous

U konteynerning oldingi mujassamlanishidagi xato xabarlarini ko'rsatadi.

RunContainer Error

Ushbu xato konteyner ishga tushirilmaganda paydo bo'ladi. Bu dastur ishga tushirilgunga qadar bo'lgan vaqtga to'g'ri keladi. Odatda noto'g'ri sozlamalar tufayli yuzaga keladi, masalan:

• ConfigMap yoki Secrets kabi mavjud bo'lmagan jildni o'rnatishga urinish;
• faqat o'qish uchun hajmni o'qish-yozish sifatida o'rnatishga urinish.

Jamoa bunday xatolarni tahlil qilish uchun juda mos keladi kubectl describe pod <pod-name>.

Podlar kutilayotgan holatda

Yaratilgandan so'ng, pod holatida qoladi Pending.

Nima uchun bu sodir bo'ladi?

Mana mumkin bo'lgan sabablar (men rejalashtiruvchi yaxshi ishlayapti deb o'ylayman):

1. Klasterda podani ishga tushirish uchun ishlov berish quvvati va xotira kabi resurslar yetarli emas.
2. Ob'ekt tegishli nomlar maydoniga o'rnatiladi ResourceQuota va pod yaratish nomlar maydonining kvotadan tashqariga chiqishiga olib keladi.
3. Pod Kutilmoqda PersistentVolumeClaim.

Bunday holda, buyruqni ishlatish tavsiya etiladi kubectl describe va bo'limni tekshiring Events:

kubectl describe pod <pod name>

bilan bog'liq xatolar bo'lsa ResourceQuotas, buyruq yordamida klaster jurnallarini ko'rish tavsiya etiladi

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

Podlar tayyor emas

Agar pod ro'yxatda bo'lsa Running, lekin holatda emas Ready, tayyorligini tekshirishni bildiradi (tayyorlik tekshiruvi) muvaffaqiyatsiz.

Bu sodir bo'lganda, pod xizmatga ulanmaydi va unga hech qanday trafik oqmaydi. Tayyorlik testining muvaffaqiyatsizligi dasturdagi muammolar tufayli yuzaga keladi. Bunday holda, xatoni topish uchun siz bo'limni tahlil qilishingiz kerak Events buyruq chiqishida kubectl describe.

2. Xizmat diagnostikasi

Agar podlar ro'yxatga kiritilgan bo'lsa Running и Ready, lekin ilovadan hali ham javob yo'q, siz xizmat sozlamalarini tekshirishingiz kerak.

Xizmatlar yorliqlariga qarab trafigi podlarga yo'naltirish uchun javobgardir. Shuning uchun, siz qilishingiz kerak bo'lgan birinchi narsa - bu xizmat bilan qancha pods ishlashini tekshirish. Buning uchun xizmatdagi so'nggi nuqtalarni tekshirishingiz mumkin:

kubectl describe service <service-name> | grep Endpoints

Yakuniy nuqta - bu shaklning juft qiymatlari <IP-адрес:порт>, va chiqishda kamida bitta bunday juftlik mavjud bo'lishi kerak (ya'ni kamida bitta pod xizmat bilan ishlaydi).

Agar bo'lim Endpoins bo'sh, ikkita variant mumkin:

1. to'g'ri yorliqli podalar yo'q (maslahat: nomlar maydoni to'g'ri tanlanganligini tekshiring);
2. Selektordagi xizmat yorliqlarida xatolik bor.

Agar siz so'nggi nuqtalar ro'yxatini ko'rsangiz, lekin hali ham dasturga kira olmasangiz, ehtimol aybdor xatolikdir targetPort xizmat tavsifida.

Xizmatning funksionalligini qanday tekshirish mumkin?

Xizmat turidan qat'i nazar, siz buyruqdan foydalanishingiz mumkin kubectl port-forward unga ulanish uchun:

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

Bu erda:

• <service-name> - xizmat nomi;
• 3000 - kompyuterda ochiladigan port;
• 80 - xizmat ko'rsatish tomonidagi port.

3. Kirish diagnostikasi

Agar siz shu paytgacha o'qigan bo'lsangiz, unda:

• podalar sifatida ro'yxatga olingan Running и Ready;
• xizmat podlar o'rtasida trafikni muvaffaqiyatli taqsimlaydi.

Biroq, siz hali ham ilovaga kira olmaysiz.

Bu shuni anglatadiki, Ingress boshqaruvchisi to'g'ri sozlanmagan. Ingress boshqaruvchisi klasterdagi uchinchi tomon komponenti bo'lganligi sababli, uning turiga qarab turli xil nosozliklarni tuzatish usullari mavjud.

Ammo Ingressni sozlash uchun maxsus vositalardan foydalanishga murojaat qilishdan oldin, siz juda oddiy narsani qilishingiz mumkin. Kirish foydalanadi serviceName и servicePort xizmatga ulanish uchun. Ularning to'g'ri sozlanganligini tekshirishingiz kerak. Buni buyruq yordamida amalga oshirishingiz mumkin:

kubectl describe ingress <ingress-name>

Agar ustun Backend bo'sh, konfiguratsiya xatosi ehtimoli yuqori. Agar orqa panellar joyida bo'lsa-da, lekin dastur hali ham mavjud bo'lmasa, muammo quyidagilar bilan bog'liq bo'lishi mumkin:

• Umumiy Internetdan kirish imkoniyati sozlamalariga kirish;
• umumiy Internetdan klasterga kirish sozlamalari.

Ingress podiga to'g'ridan-to'g'ri ulanish orqali infratuzilma bilan bog'liq muammolarni aniqlashingiz mumkin. Buni amalga oshirish uchun avval Ingress Controller podni toping (u boshqa nom maydonida bo'lishi mumkin):

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

Buyruqdan foydalaning describeportni o'rnatish uchun:

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

Nihoyat, podkastga ulaning:

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

Endi kompyuterdagi 3000 portiga barcha so'rovlar podning 80 portiga yo'naltiriladi.

Hozir ishlaydimi?

• Ha bo'lsa, muammo infratuzilmada. Klasterga trafik qanday yo'naltirilganligini aniq aniqlash kerak.
• Agar yo'q bo'lsa, muammo Ingress boshqaruvchisida.

Agar siz Ingress boshqaruvchisini ishga tushira olmasangiz, uni disk raskadrovka qilishingiz kerak bo'ladi.

Ingress kontrollerlarining ko'p navlari mavjud. Eng mashhurlari Nginx, HAProxy, Traefik va boshqalar. (mavjud echimlar haqida qo'shimcha ma'lumot olish uchun qarang bizning sharhimiz - taxminan. tarjima.) Tegishli tekshirgich hujjatlaridagi muammolarni bartaraf etish bo'yicha qo'llanmaga murojaat qilishingiz kerak. Chunki Nginx-ga kirish eng mashhur Ingress tekshiruvi bo'lib, biz maqolaga u bilan bog'liq muammolarni hal qilish uchun ba'zi maslahatlarni kiritdik.

Ingress Nginx kontrolleridagi nosozliklarni tuzatish

Ingress-nginx loyihasi rasmiy shaxsga ega kubectl uchun plagin. Jamoa kubectl ingress-nginx quyidagilar uchun ishlatilishi mumkin

• jurnallar, backendlar, sertifikatlar va boshqalarni tahlil qilish;
• Ingressga ulanish;
• joriy konfiguratsiyani o'rganish.

Bunda sizga quyidagi uchta buyruq yordam beradi:

• kubectl ingress-nginx lint - tekshiruvlar nginx.conf;
• kubectl ingress-nginx backend — orqa tomonni o'rganadi (o'xshash kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs — jurnallarni tekshiradi.

E'tibor bering, ba'zi hollarda siz bayroq yordamida Ingress kontroller uchun to'g'ri nom maydonini belgilashingiz kerak bo'lishi mumkin --namespace <name>.

Xulosa

Agar qaerdan boshlashni bilmasangiz, Kubernetes bilan bog'liq muammolarni bartaraf etish qiyin bo'lishi mumkin. Siz har doim muammoga pastdan yuqoriga yondashishingiz kerak: podlardan boshlang, so'ngra xizmat va kirishga o'ting. Ushbu maqolada tasvirlangan nosozliklarni tuzatish usullari boshqa ob'ektlarga nisbatan qo'llanilishi mumkin, masalan:

• bo'sh ish o'rinlari va CronJobs;
• StatefulSets va DaemonSets.

minnatdorchilik bildiraman Gergeli Risko, Daniel Vaybel и Charlz Kristiraj qimmatli mulohazalar va qo'shimchalar uchun.

Tarjimondan PS

Shuningdek, bizning blogimizda o'qing:

• «Kubernetes podslarida nosozliklarni tuzatish uchun kubectl-debug plagini";
• «Kubernetes ishidagi 6 ta qiziqarli tizim xatolari [va ularning yechimi]";
• «Kubernetes-da ishlaydigan ilovalarni ishlab chiquvchilar uchun asboblar";
• «Bizning SRE kundalik hayotimizdan 6 ta amaliy hikoyalar ".

Manba: www.habr.com