Kubernetes-də uğursuzluqları diaqnoz etməyə dair vizual rəhbərlik

Qeyd. tərc.: Bu məqalə açıq mənbədən yayımlanan materialların bir hissəsini təşkil edir learnk8s, Kubernetes ilə işləməyə öyrədən bir şirkət və fərdi administratorlar üçün. Burada layihə rəhbəri Daniele Polencic, K8s klasterində işləyən tətbiqlərdə baş verən ümumi problemlərlə bağlı hansı addımları atmağı izah edən aydın təlimat təqdim edir.

TL;DR: burada Kubernetes-də yerləşdirməni təhlil etməyə kömək edəcək sxem var:

Klasterdəki xətaları tapmaq və düzəltmək üçün axın sxemi. Orijinalı (ingilis dilində) burada mövcuddur PDF və şəkil kimi.

Kubernetes-də tətbiq yerləşdirərkən adətən üç komponent müəyyənləşdirilməlidir:

• Deployment — bu, pod adlanan tətbiqin nüsxələrinin yaradılması üçün bir reseptdir;
• Service — trafiki pod-lar arasında paylayan daxili yük balanslayıcı;
• Ingress — trafiğin xarici dünyadan Service-ə daxil olma formasının təsviridir.

Budur qısa qrafik özet:

1) Kubernetes-də tətbiqlər xarici dünyadan iki qat yük balanslayıcı vasitəsilə trafik alır: daxili və xarici.

2) Daxili yük balanslayıcı Service adlanır, xarici isə Ingress.

3) Deployment pod-ları yaradır və onlara nəzarət edir (onlar əl ilə yaradılmır).

Tutaq ki, sadə bir tətbiqi yerləşdirmək istəyirsiniz Hello World. YAML konfiqurasiyası belə görünəcək:

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

Təsvirdə bir az uzun olduğundan, komponentlərin bir-biri ilə ilişkisini anlamaq asandır.

Məsələn:

• Hansı zaman 80 portu, hansı zaman 8080 istifadə edilməlidir?
• Hər xidmət üçün yeni bir port yaratmaq lazımdırmı ki, konflikt olmasın?
• Etiket adları əhəmiyyətlimi? Hamısı eyni olmalıdırmı?

Düzəltməyə diqqət yetirmədən öncə, gəlin üç komponentin bir-biri ilə əlaqəsini xatırlayaq. Deployment və Service ilə başlayaq.

Deployment ilə Service arasındakı əlaqə

Sizi heyran edəcək, amma Deployment-lar və Service-lər bir-biri ilə əlaqəli deyil. Bunun əvəzinə Service birbaşa Pod-lara istinad edir, Deployment-ı keçərək.

Buna görə Pod-lar və Service-lər arasında necə bir əlaqə olduğunu öyrənmək bizi maraqlandırır. Üç şeyi xatırlamaq lazımdır:

1. Service-in seçicisi (selector) bir Pod-un azı bir etiketinə uyğun gəlməlidir.
2. targetPort containerPort Pod-dakı konteynerlə eyni olmalıdır. Service-in adı hər hansı ola bilər. Müxtəlif xidmətlər eyni portu istifadə edə bilərlər, çünki onların fərqli IP ünvanları var.
3. port Növbəti sxem yuxarıda sadalananların hamısını qrafik formada təqdim edir:

Следующая схема представляет все вышеперечисленное в графической форме:

1) Təsəvvür edək ki, xidmət trafiki müəyyən bir pod-a yönləndirir:

2) Pod yaradılarkən, hər bir pod-da Pod-dakı konteynerlə eyni olmalıdır. hər konteynər üçün:

3) Xidmət yaradılarkən, göstərin port və targetPort. Ancaq konteynərə bağlanma hansı yolla baş verir?

4) Aracılığı ilə targetPort. Bu, ilə üst-üstə düşməlidir Pod-dakı konteynerlə eyni olmalıdır..

5) Gəlin, konteynərdə 3000 portu açıqdır deyək. Onda dəyər targetPort bu ilə eyni olmalıdır.

YAML faylında etiketlər və ports / targetPort bir-birini uyğunlaşdırmalıdır:

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

Bəs etiketlə bağlı track: canary Deployment bölməsinin yuxarı hissəsində? O, uyğun olmalıdırmı?

Bu etiket yayılmaya aiddir və trafik yönləndirmək üçün xidmət tərəfindən istifadə edilmir. Başqa sözlə, onu silmək və ya başqa bir dəyər vermək olar.

Bəs seçici ilə bağlı matchLabels?

Həmişə Pod etiketləri ilə üst-üstə düşməlidir, çünki Deployment tərəfindən pod-ları izləmək üçün istifadə edilir.

Tutaq ki, düzgün dəyişikliklər etmisiniz. Onları necə yoxlamaq olar?

Pod etiketlərini yoxlamaq üçün aşağıdakı komandanı istifadə etmək olar:

kubectl get pods --show-labels

Və ya, əgər pod-lar bir neçə tətbiqə aiddirsə:

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

Burada any-name=my-app — bu etiketdir any-name: my-app.

Çətinliklər qaldı?

Pod-a qoşula bilərsiniz! Bunun üçün port-forward kubectl-da komandanı istifadə etmək lazımdır. Bu, xidmətə qoşulmağa və əlaqəni yoxlamağa imkan tanıyır.

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

Burada:

• service/<service name> — xidmətin adı; bizim vəziyyətimizdə my-service;
• 3000 — kompüterdə açılacaq port;
• 80 — xidmətin sahəsində qeyd olunan port. port Əgər əlaqə qurulubsa, demək ki, parametrlər düzgündür.

Əgər əlaqəni qurmaq mümkün olmayıbsa, demək ki, etiketlərdə və ya portlar arasında uyğunsuzluq vardır.

Xidmət və Ingress əlaqəsi

Tətbiqə giriş imkanı sağlamanın növbəti addımı Ingress-in konfiqurasiyası ilə bağlıdır. Ingress, xidmətin necə tapıldığını bilmək, sonra pod-ları tapmaq və onlara trafik yönləndirmək üçün ehtiyac duyur. Ingress, uyğun xidmətin adını və açıq portunu tapır.

Ingress və Xidmət təsvirində iki parametr uyğun olmalıdır:

servicePort

1. Ingress-də Xidmətin parametrlə uyğun olmalıdır; serviceName port Ingress-də Xidmət sahəsi ilə üst-üstə düşməlidir.
2. Növbəti sxem portların qoşulması ilə bağlı yekunlaşdırma verir: 1) Bildiyiniz kimi, Xidmət müəyyən bir Lisenziya, inkişaf etdiricilər və versiya idarəetmə sisteminin məlumatlarının mövcudluğu 2) Ingress-in 'service' adlandırılan bir parametri var.

3) Bu parametr (

) həmişə Xidmətin müəyyən edilməsində port:

4) Xidmətdə port 80 qeyd edilibsə, o zaman Ingress-də Xidmətin parametrlə uyğun olmalıdır;:

da 80-ə bərabər olmalıdır:Ingress-də Xidmətin parametrlə uyğun olmalıdır;Praktikada diqqət yetirmək lazımdır ki, aşağıdakı sətirlərə: port в определении Service:

4) Если в Service задан порт 80, то необходимо, чтобы Ingress-də Xidmətin parametrlə uyğun olmalıdır; также был равен 80:

На практике необходимо обращать внимание на следующие строки:

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'in işlədiyini necə yoxlamaq olar?

Metoddan istifadə edə bilərsiniz kubectl port-forward, amma xidmət əvəzinə Ingress controller-a qoşulmaq lazımdır.

Əvvəlcə Ingress controller-in pod adını öyrənmək lazımdır:

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

Ingress podunu tapın (o başqa bir adlandırma mühitinə aid ola bilər) və aşağıdakı əmri icra edin describe, port nömrələrini öyrənmək üçün:

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

Nəhayət, pod-a qoşulun:

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

İndi hər dəfə 3000 porta sorğu göndərdiyinizdə, bu sorğu Ingress controller pod-unun 80 portuna yönəldiləcək. Aşağıdakı linkə keçid etdikdə http://localhost:3000, tətbiq tərəfindən yaradılmış səhifəni görməlisiniz.

Portlar üzrə xülasə

Gəlin bir daha hansı portlar və etiketlərin üst-üstə düşməli olduğunu xatırlayaq:

1. Service tərifindəki selector pod-un etiketi ilə üst-üstə düşməlidir;
2. targetPort Service tərifində Pod-dakı konteynerlə eyni olmalıdır. pod içərisindəki konteynerin
3. port Service tərifindəki port hər hansı bir ola bilər. Fərqli xidmətlər eyni portdan istifadə edə bilər, çünki onların IP ünvanları fərqlidir;
4. Ingress-də Xidmətin parametrlə uyğun olmalıdır; Ingress'ın port Service tərifindəki
5. xidməti inqressdəki Növbəti sxem portların qoşulması ilə bağlı yekunlaşdırma verir: adının Ingress-dəki

Təəssüf ki, YAML konfiqurasiyasını düzgün qurmağı bilmək kifayət etmir.

Nə baş verdiyində, hər şey düzgün işləmir?

Bəlkə pod işə düşmür və ya düşür.

Kubernetes-də tətbiqlərdə problemləri diaqnoz etmənin 3 addımı

Deployment-i işə salmazdan qabaq, Kubernetes-in necə işlədiyini gözəl başa düşmək lazımdır.

Hər K8s tətbiqində üç komponent olduğu üçün, onları müvafiq ardıcıllıqla diaqnoz etmək lazımdır, altqatdan başlayaraq.

1. İlk əvvəl podların işlədiyinə əmin olun, sonra…
2. Xidmətin pod-lara trafik göndərdiyini yoxlayın, sonra…
3. Ingress-in düzgün qurulduğunu yoxlayın.

Vizuallaşdırma:

1) Problemlərin axtarışına altqatdan başlamaq lazımdır. İlk öncə podların statusunu yoxlayın: Ready və Running:

2) Əgər podlar hazırdır (Ready), xidmətin podlar arasında trafik yaydığını öyrənməlisiniz:

3) Nəhayət, xidmətlə Ingress-in əlaqəsini analiz etməlisiniz:

1. Podların diaqnostikası

Çox vaxt problem pod ilə bağlıdır. Podların Ready və Runningdeyildiyinə əmin olun. Bunu yoxlamaq üçün aşağıdakı əmri istifadə edə bilərsiniz:

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

Yuxarıda göstərilmiş əmrin çıxışında, son pod belə qeyd olunur Running və Ready, lakin digər iki pod üçün vəziyyət belə deyil.

Nəyin səhv getdiyini necə başa düşmək olar?

Podlar üçün diaqnostika etmək üçün dörd faydalı əmr var:

1. kubectl logs poddakı konteynerlərdən logları çıxarmağa imkan verir;
2. kubectl describe pod podla əlaqəli hadisələrin siyahısını görməyə imkan verir;
3. kubectl get pod Kubernetes-də saxlanılan podun YAML konfiqurasiyasını əldə etməyə imkan verir;
4. kubectl exec -ti bash poddakı konteynerlərdən birində interaktiv komanda xətti işlətməyə imkan verir

Hansını seçmək lazımdır?

Məsələ burasındadır ki, universal bir əmr yoxdur. Onların kombinasyonunu istifadə etmək lazımdır.

Podların tipik problemləri

Podlar üçün iki əsas xəta növü mövcuddur: başlanğıc (startup) və iş zamanı (runtime) xətaları.

Başlanğıc xətaları:

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

İş zamanı xətaları:

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

Bəzi xətalar digərlərindən daha tez-tez baş verir. Burada ən çox yayılmış xətalar və onların aradan qaldırılması yolları verilmişdir.

ImagePullBackOff

Bu xəta, Kubernetes-in podun konteynerlərindən biri üçün şəkil əldə edə bilmədiyi zaman yaranır. Bunun üç ən çox yayılmış səbəbi var:

1. Şəklin adı düzgün verilməmişdir - məsələn, siz səhv etmisiniz və ya şəkil mövcud deyil;
2. Şəkinin mövcud olmayan etiketini göstərmisiniz;
3. Şəkil gizli registrdə saxlanılır və Kubernetes-in ona daxil olmaq üçün icazəsi yoxdur.

İlk iki səbəbi düzəltmək asandır - sadəcə şəkilin adını və etiketini düzəltmək kifayətdir. Sonuncu halda gizli registr üçün giriş təsdiqini Secret-ə daxil etməli və podlara ona keçidlər əlavə etməlisiniz. Kubernetes sənədlərində bu işin necə yerinə yetiriləcəyinə dair bir nümunə var. Kubenetes, konteyner işə başlamadıqda xəta çıxarır. Bu, adətən, aşağıdakı səbəblərdən baş verir:

CrashLoopBackOff

Proqramda onu işə salmağa mane olan bir səhv var; CrashLoopBackOffdüzgün konfiqurasiya edilməmişdir

1. Liveness testində çox sayda uğursuzluq baş verir.
2. Konteyner Səhvin səbəbini öyrənmək üçün konteynerin loglarına daxil olmaq lazım olacaq. əgər loglara daxil olmaq çətindirsə, çünki konteyner çox tez bir şəkildə yenidən başlamaqdadırsa, aşağıdakı əmrdən istifadə edə bilərsiniz:;
3. kubectl logs --previous

Bu, konteynerin əvvəlki reinkarnasiyasından xətaların mesajlarını çıxarır.

Bu xəta, konteynerin işə başlamadığı zaman baş verir. Bu, tətbiqin işə salınmasından öncəki dövrə uyğundur. Adətən, səbəb düzgün olmayan konfiqurasiya olur, məsələn:

mövcud olmayan bir volumun kəsilməyə çalışılması, məsələn, ConfigMap və ya Secrets;

RunContainerError

Эта ошибка возникает, когда контейнер не в состоянии запуститься. Она соответствует моменту до запуска приложения. Обычно ее причиной является неправильная настройка, например:

• попытка примонтировать несуществующий том, такой как ConfigMap или Secrets;
• bir read-only tipli həcmi read-write olaraq mount etməyə cəhd.

Bu cür xətaları analiz etmək üçün yaxşı bir komandadır kubectl describe pod.

Pod-lar Pending vəziyyətindədir

Pod yaradıldıqdan sonra Pending vəziyyətində qalır Pending.

Niyə belə olur?

Bunlar mümkün səbəblərdir (planlayıcının düzgün çalışdığını nəzərdə tuturam):

1. Klasterdə podu işə salmaq üçün kifayət qədər resurs, məsələn, hesablamaya və yaddaşa malik deyil.
2. Müvafiq ad boşluğunda bir obyektin olmasıdır ResourceQuota və podun yaradılması ad boşluğunu kvotadan çıxaracaq.
3. Pod Pending vəziyyətinə bağlıdır PersistentVolumeClaim.

Bu halda komandanı istifadə etmək tövsiyə olunur kubectl describe və bölməni yoxlayın Events:

kubectl describe pod

Xətalarla əlaqədar olaraq ResourceQuotas, klasterin loglarını yoxlamağı tövsiyə edirəm

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

Pod-lar Ready vəziyyətində deyil

Əgər pod Runningkimi görünür, amma Ready vəziyyətində deyilsə Ready, o zaman onun hazır olma yoxlaması (readiness probe) uğursuzluqla nəticələnir.

Buna görə də, pod xidmətə qoşulmur və ona trafik gəlmir. readiness testinin uğursuzluğu tətbiqdəki problemlərlə bağlıdır. Bu halda xətanın tapılması üçün Events komandanın çıxışındakı bölməni analiz etmək lazımdır kubectl describe.

2. Xidmətlərin diaqnozu

Əgər pod-lar Running və Readykimi görünür, lakin hələ də tətbiqdən cavab almırsınızsa, xidmət parametrlərini yoxlamaq lazımdır.

Xidmətlər, pod-lara trafik yönləndirir onların etiketlərinə əsasən. Buna görə ilk növbədə, xidmətlə işləyən neçə pod olduğunu yoxlamaq lazımdır. Bunun üçün xidmətin endpoint-larını yoxlaya bilərsiniz:

kubectl describe service  | grep Endpoints

Endpoint — formato ilə bir dəyər cütüdür , və çıxışda ən azı bir cüt olmalıdır (yəni xidmətlə işləyən ən azı bir pod olmalıdır).Əgər

Endpoints boşdursa, iki variant mümkündür: doğru etiketə sahib heç bir pod yoxdur (ipucu: namespace-in doğru seçildiyini yoxlayın);

1. xidmətin seçicisində etiketlərdə səhv var.
2. Əgər endpoint-ların siyahısını görürsünüz, lakin hələ də tətbiqə daxil ola bilmirsinizsə, o zaman mümkün günahkar xidmətin

təsvirindəki xətadır. targetPort Xidmətin işləkliyini necə yoxlamaq olar?

Xidmətin növündən asılı olmayaraq, ona qoşulmaq üçün

komandanı istifadə edə bilərsiniz: kubectl port-forward kubectl port-forward service/ 3000:80

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

Burada:

• — xidmətin adı; 3000 — kompüterdə açdığınız port;
• 80 — xidmət tərəfindəki port.
• 3. Ingress-diaqnozu

Əgər bu yerə qədər oxumusunuzsa, deməli:

pod-lar

• xidmət artıq pod-lar arasında trafik yönləndirir. Running və Ready;
• Amma hələ də tətbiqə «dostlaşa» bilmirisiniz.

Однако вы по-прежнему не можете «достучаться» до приложения.

Bu, deməkdir ki, Ingress kontrolçusu düzgün qurulmamışdır. Ingress kontrolçusu klasterdə üçüncü tərəf komponenti olduğuna görə, onun tipinə görə müxtəlif debuq üsulları mövcuddur.

Amma Ingress-i konfiqurasiya etmək üçün xüsusi alətlərdən istifadə etməzdən əvvəl, daha sadə bir şey edə bilərsiniz. Ingress, Növbəti sxem portların qoşulması ilə bağlı yekunlaşdırma verir: və Ingress-də Xidmətin parametrlə uyğun olmalıdır; servisə qoşulmaq üçün istifadə olunur. Onların düzgün qurulduğuna əmin olun. Bunu aşağıdakı əmr vasitəsi ilə yoxlaya bilərsiniz:

kubectl describe ingress

Əgər sütun Backend boşdursa, konfiqurasiyada bir səhv olma ehtimalı yüksəkdir. Əgər backend-lər mövcuddursa, lakin tətbiqə giriş hələ də yoxdursa, problem aşağıdakılarla bağlı ola bilər:

• Ingress-in ictimai internetdən əlçatanlığı ilə bağlı konfiqurasiyalar;
• Klasterin ictimai internetdən əlçatanlığı ilə bağlı konfiqurasiyalar.

İnfrastruktur problemlərini müəyyən etmək üçün birbaşa Ingress poduna qoşulmaq olar. Bunun üçün əvvəlcə Ingress kontrolçusunun podunu tapın (o, başqa ad sahəsində ola bilər):

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

Port qurmaq üçün describekubectl describe pod nginx-ingress-controller-6fc5bcc --namespace kube-system | grep Ports

İndi sözdə port 3000-ə edilən bütün sorğular, pod-un 80 portuna yönləndiriləcək.

Nəhayət, pod-a qoşulun:

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

İndi çalışırmı?

Bəli, problem infrastrukturla bağlıdır. Trafik klasterə necə yönləndirilir, müəyyənləşdirmək lazımdır.

• Xeyr, problem Ingress kontrolçusundadır.
• Ingress kontrolçusunu işə sala bilmiriksə, onun debuqunu aparmaq lazım olacaq.

Ingress kontrolçularının bir çox növü mövcuddur. Ən populyarları Nginx, HAProxy, Traefik və digərləridir.

(Mövcud həll yolları haqqında daha ətraflı məlumat üçün baxın bizim icmalımızda bizim icmalımızda — redakt. qeydi) Müvafiq kontrolçunun sənədində problemləri aradan qaldırmaq üçün rəhbərliyi izləməlisiniz. Çünki Ingress Nginx ən populyar Ingress kontrolçusudur, biz məqaləyə onunla bağlı problemləri həll etmək üçün bir neçə məsləhət daxil etdik.

Ingress Nginx kontrolçusunu debuq etmək

Ingress-nginx layihəsinin rəsmi kubectl üçün plaqini var.Aşağıdakı əmri kubectl ingress-nginx çalışdıraraq:

• loqları, backend-ləri, sertifikatları və s. araşdıra bilərsiniz;
• Ingress-ə qoşulmaq;
• mövcud konfiqurasiyanı öyrənmək.

Sizdə bu üç əmr kömək edəcək:

• kubectl ingress-nginx lint — yoxlayır nginx.conf;
• kubectl ingress-nginx backend — backend-i araşdırır (kubectl ingress-nginx logs kubectl describe ingress);
• — loqları yoxlayır.) Qeyd edin: bəzən Ingress kontrolçusu üçün düzgün ad sahəsini göstərmək lazım ola bilər, bunu

--namespace flagi ilə edin. Kubernetes-də diaqnostika aparmaq çətindir, əgər haradan başlayacağınızı bilirsinizsə. Problemlə həmişə "aşağıdan yuxarıya" prinsipinə uyğun yanaşmaq lazımdır: öncə pod-lardan başlayın, sonra xidmətə və Ingress-ə keçin. Məqalədə təsvir olunan debuq üsulları digər obyektlərə, məsələn, aşağıdakıları da tətbiq oluna bilər:.

Xülasə

Диагностика в Kubernetes может оказаться непростой задачей, если не знать, с чего начать. К проблеме всегда следует подходить по принципу «снизу-вверх»: начинайте с pod’ов, а затем переходите к сервису и Ingress’у. Методы отладки, описанные в статье, могут применяться и к другим объектам, таким как:

• işləməyən Job’lar və CronJob’lar;
• StatefulSet’lər və DaemonSet’lər.

Təşəkkür edirəm Gergely Risko, Daniel Weibel və Charles Christyraj dəyərli şərhlər və əlavələr üçün.

Kubernetes-də təhlükəsizlik: identifikasiya, icazə, audit

Blogumuzda oxuyun:

• «Kubernetes pod-larında debug etmək üçün kubectl-debug plagin»;
• «Kubernetes-də baş verən 6 maraqlı sistem xətası [və onların həlli]»;
• «Kubernetes'te çalışan uygulamalar için geliştirici araçları»;
• «6 praktiki hekayə bizim SRE gündəliklərimizdən ».

Mənbə: habr.com