Kubernetes-ийн алдааг олж засварлах харааны гарын авлага

Анхаарна уу. орчуулга.: Энэхүү нийтлэл нь олон нийтэд нийтлэгдсэн төслийн материалуудын нэг хэсэг юм сурах8s, Кубернетестэй хамтран ажиллах компаниуд болон хувь хүний ​​админуудыг сургадаг. Үүнд төслийн менежер Даниэле Поленчик K8s кластер дээр ажиллаж байгаа програмуудад ерөнхий асуудал гарсан тохиолдолд ямар арга хэмжээ авах талаар харааны зааврыг хуваалцжээ.

TL; DR: Kubernetes-д байршуулахад дибаг хийхэд тань туслах диаграмм энд байна:

Кластер дахь алдааг олж засварлах урсгал диаграм. Эх хувийг (англи хэл дээр) эндээс авах боломжтой PDF и зураг шиг.

Kubernetes-д програм байрлуулахдаа ихэвчлэн гурван бүрэлдэхүүн хэсгийг тодорхойлох шаардлагатай:

• байрлуулалт - энэ бол pods гэж нэрлэгддэг програмын хуулбарыг үүсгэх нэг төрлийн жор юм;
• үйлчилгээ - хонхорцог хоорондын урсгалыг хуваарилдаг дотоод ачаалал тэнцвэржүүлэгч;
• Ingress - гадаад ертөнцөөс Үйлчилгээ рүү чиглэсэн хөдөлгөөн хэрхэн ирэх тухай тайлбар.

Энд хурдан график хураангуй байна:

1) Kubernetes-д програмууд нь дотоод болон гадаад гэсэн хоёр давхар ачаалал тэнцвэржүүлэгчээр дамжуулан гадаад ертөнцөөс траффик хүлээн авдаг.

2) Дотоод тэнцвэржүүлэгчийг Үйлчилгээ, гадаадыг Ingress гэж нэрлэдэг.

3) Байрлуулалт нь pods үүсгэж, тэдгээрийг хянадаг (тэдгээрийг гараар үүсгээгүй).

Та энгийн программыг ашиглахыг хүсч байна гэж бодъё Сайн уу. Үүний YAML тохиргоо дараах байдлаар харагдах болно.

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

Тодорхойлолт нь нэлээд урт бөгөөд бүрэлдэхүүн хэсгүүд нь хоорондоо хэрхэн холбогдож байгааг эргэлзэхэд хялбар байдаг.

Жишээ нь:

• 80-р портыг хэзээ, 8080-ийг хэзээ ашиглах ёстой вэ?
• Үйлчилгээ тус бүрт зөрчилдөхгүйн тулд би шинэ порт үүсгэх ёстой юу?
• Шошгоны нэр чухал уу? Тэд хаа сайгүй адилхан байх ёстой юу?

Дибаг хийхэд анхаарлаа хандуулахын өмнө гурван бүрэлдэхүүн хэсэг хоорондоо хэрхэн холбогдож байгааг санацгаая. Байрлуулалт ба үйлчилгээнээс эхэлцгээе.

Байрлуулалт ба үйлчилгээний хоорондын хамаарал

Та гайхах болно, гэхдээ байршуулалт болон үйлчилгээ ямар ч байдлаар холбогдоогүй байна. Үүний оронд Үйлчилгээ нь Байршлыг алгасаж Pods руу шууд чиглэнэ.

Тиймээс бид Pods болон үйлчилгээнүүд хоорондоо хэрхэн холбоотой болохыг сонирхож байна. Гурван зүйлийг санаж байх хэрэгтэй:

1. Сонгогч (selector) Үйлчилгээнд дор хаяж нэг Pod шошго таарч байх ёстой.
2. targetPort Таарч байх ёстой containerPort Pod доторх сав.
3. port Үйлчилгээ нь юу ч байж болно. Өөр өөр үйлчилгээнүүд өөр IP хаягтай тул ижил портыг ашиглаж болно.

Дараах диаграмм дээр дурдсан бүх зүйлийг график хэлбэрээр харуулав.

1) Энэ үйлчилгээ нь урсгалыг тодорхой нэг хэсэг рүү чиглүүлдэг гэж төсөөлөөд үз дээ:

2) Под үүсгэх үед та зааж өгөх ёстой containerPort хонхорцог дахь сав бүрийн хувьд:

3) Үйлчилгээг бий болгохдоо та зааж өгөх ёстой port и targetPort. Гэхдээ аль нь саванд холбоход хэрэглэгддэг вэ?

4) дамжуулан targetPort. Энэ нь таарах ёстой containerPort.

5) Контейнер дотор 3000 порт нээлттэй байна гэж бодъё.Тэгээд утга targetPort адилхан байх ёстой.

YAML файлд шошго болон ports / targetPort Таарч байх ёстой:

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

Шошго нь яах вэ track: canary Байршуулах хэсгийн дээд хэсэгт? Энэ нь таарах ёстой юу?

Энэ шошго нь байршуулалтад зориулагдсан бөгөөд үйлчилгээ нь урсгалыг чиглүүлэхэд ашигладаггүй. Өөрөөр хэлбэл, үүнийг арилгах эсвэл өөр утгыг оноож болно.

Сонгогчийг яах вэ matchLabels?

Энэ нь үргэлж Pod-ийн шошготой таарч байх ёстой, учир нь үүнийг Deployment pods хянахад ашигладаг.

Та зөв засвар хийсэн гэж бодъё. Тэднийг хэрхэн шалгах вэ?

Та доорх командын тусламжтайгаар подвалын шошгыг шалгаж болно.

kubectl get pods --show-labels

Эсвэл, хэрэв pod нь хэд хэдэн програмд ​​хамаарах бол:

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

Хаана any-name=my-app шошго юм any-name: my-app.

Ямар нэгэн хүндрэл үлдсэн үү?

Та подволд холбогдож болно! Үүнийг хийхийн тулд та тушаалыг ашиглах хэрэгтэй port-forward kubectl дээр. Энэ нь танд үйлчилгээнд холбогдож холболтыг шалгах боломжийг олгоно.

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

Энд:

• service/<service name> - үйлчилгээний нэр; манай тохиолдолд тийм байна my-service;
• 3000 бол компьютер дээр нээх шаардлагатай порт юм;
• 80 - талбарт заасан порт port үйлчилгээ.

Хэрэв холболт хийгдсэн бол тохиргоо зөв байна.

Хэрэв холболт амжилтгүй болбол шошгон дээр асуудал гарсан эсвэл портууд таарахгүй байна.

Үйлчилгээ ба нэвтрэх хоорондын хамаарал

Аппликейшнд нэвтрэх дараагийн алхам нь Ingress-ийг тохируулах явдал юм. Оролцох нь үйлчилгээг хэрхэн олох, дараа нь pods олж, тэдгээрт урсгалыг чиглүүлэх талаар мэдэх шаардлагатай. Ingress нь шаардлагатай үйлчилгээг нэрээр нь олоод портыг нээнэ.

Оролтын болон Үйлчилгээний тайлбарт хоёр параметр тохирч байх ёстой:

1. servicePort Ingress нь параметртэй тохирч байх ёстой port Үйлчилгээнд;
2. serviceName Ingress талбарт тохирох ёстой name Үйлчилгээнд.

Дараах диаграмм нь портын холболтыг нэгтгэн харуулав.

1) Та аль хэдийн мэдэж байгаачлан Үйлчилгээ нь тодорхой зүйлийг сонсдог port:

2) Оролт нь нэртэй параметртэй servicePort:

3) Энэ параметр (servicePort) үргэлж таарч байх ёстой port Үйлчилгээний тодорхойлолтод:

4) Үйлчилгээнд 80 портыг зааж өгсөн бол үүнийг хийх шаардлагатай servicePort мөн 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 ажиллаж байгаа эсэхийг хэрхэн шалгах вэ?

Та аргыг ашиглаж болно kubectl port-forward, гэхдээ үйлчилгээний оронд та Ingress хянагчтай холбогдох хэрэгтэй.

Эхлээд та 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

Ingress pod (энэ нь өөр нэрийн зайд байж болно) олоод тушаалыг ажиллуулна уу describeпортын дугаарыг мэдэхийн тулд:

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

Эцэст нь подволд холбоно уу:

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

Одоо та өөрийн компьютер дээрх 3000 порт руу хүсэлт илгээх бүрд энэ нь Ingress хянагчтай подын 80-р порт руу шилжих болно. Очих замаар http://localhost:3000, та програмын үүсгэсэн хуудсыг харах ёстой.

Портуудын хураангуй

Ямар порт болон шошго таарах ёстойг дахин нэг удаа санацгаая.

1. Үйлчилгээний тодорхойлолт дахь сонгогч нь подын шошготой тохирч байх ёстой;
2. targetPort тодорхойлолтод Үйлчилгээ таарч байх ёстой containerPort савны доторх сав;
3. port тодорхойлолтод Үйлчилгээ нь юу ч байж болно. Өөр өөр үйлчилгээнүүд өөр IP хаягтай тул ижил портыг ашиглаж болно;
4. servicePort Оролтын хэмжээ таарч байх ёстой port Үйлчилгээний тодорхойлолтод;
5. Үйлчилгээний нэр талбартай тохирч байх ёстой serviceName Ингресст.

Харамсалтай нь YAML тохиргоог хэрхэн зөв зохион байгуулахыг мэдэх нь хангалтгүй юм.

Бүх зүйл буруу болвол юу болдог вэ?

Под ажиллахгүй эсвэл эвдэрч болзошгүй.

Kubernetes дахь програмын асуудлыг оношлох 3 алхам

Та байршуулалтаа дибаг хийж эхлэхээсээ өмнө Kubernetes хэрхэн ажилладаг талаар сайн ойлголттой байх хэрэгтэй.

K8s-д татаж авсан програм бүр нь гурван бүрэлдэхүүн хэсэгтэй тул тэдгээрийг доод талаас нь эхлээд тодорхой дарааллаар дибаг хийх ёстой.

1. Эхлээд та хонхорцог ажиллаж байгаа эсэхийг шалгах хэрэгтэй, дараа нь ...
2. Үйлчилгээ нь хонгилд урсгалыг хангаж байгаа эсэхийг шалгаад дараа нь...
3. Ingress зөв тохируулагдсан эсэхийг шалгана уу.

Харааны дүрслэл:

1) Та асуудлыг хамгийн доод талаас нь хайж эхлэх хэрэгтэй. Эхлээд хонхорцог статустай эсэхийг шалгана уу Ready и Running:

2) Хэрэв хонхорцог бэлэн бол (Ready), та үйлчилгээ нь подкуудын хооронд траффик хуваарилдаг эсэхийг олж мэдэх хэрэгтэй:

3) Эцэст нь, та үйлчилгээ болон Ingress хоорондын холболтыг шинжлэх хэрэгтэй:

1. Буурцагны оношлогоо

Ихэнх тохиолдолд асуудал нь хонхорхойтой холбоотой байдаг. Дотор нь жагсаалтад орсон эсэхийг шалгаарай Ready и Running. Та үүнийг дараах тушаалыг ашиглан шалгаж болно.

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

Дээрх командын гаралтад сүүлчийн pod нь дараах байдлаар бичигдсэн байна Running и Ready, гэхдээ энэ нь бусад хоёрын хувьд тийм биш юм.

Юу буруу болсныг яаж ойлгох вэ?

Дотор нь оношлох дөрвөн ашигтай тушаал байдаг:

1. kubectl logs <имя pod'а> хонхорцог дахь савнаас лог задлах боломжийг танд олгоно;
2. kubectl describe pod <имя pod'а> подтой холбоотой үйл явдлын жагсаалтыг харах боломжийг танд олгоно;
3. kubectl get pod <имя pod'а> Kubernetes-д хадгалагдсан pod-ийн YAML тохиргоог авах боломжийг танд олгоно;
4. kubectl exec -ti <имя pod'а> bash нь под контейнерийн аль нэгэнд интерактив командын бүрхүүлийг ажиллуулах боломжийг танд олгоно

Та алийг нь сонгох ёстой вэ?

Үнэн хэрэгтээ бүх нийтийн тушаал байдаггүй. Эдгээрийг хослуулан хэрэглэх нь зүйтэй.

Хавдрын ердийн асуудлууд

Үндсэн хоёр төрлийн под алдаа байдаг: эхлүүлэх алдаа болон ажиллах үеийн алдаа.

Эхлүүлэх алдаа:

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

Ажиллах үеийн алдаа:

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

Зарим алдаа нь бусдаасаа илүү түгээмэл байдаг. Хамгийн нийтлэг алдаанууд болон тэдгээрийг хэрхэн засах талаар энд оруулав.

ImagePullBackOff

Энэ алдаа нь Кубернетес аль нэг савны дүрсийг авах боломжгүй үед гардаг. Үүний хамгийн түгээмэл гурван шалтгааныг энд дурдав:

1. Зургийн нэр буруу байна - жишээлбэл, та алдаа гаргасан эсвэл зураг байхгүй байна;
2. Зурганд байхгүй шошгыг зааж өгсөн;
3. Зураг нь хувийн бүртгэлд хадгалагдсан бөгөөд Кубернетес үүнд хандах эрхгүй.

Эхний хоёр шалтгааныг арилгахад хялбар байдаг - зургийн нэр, шошгыг засахад л хангалттай. Сүүлчийн тохиолдолд та Нууц хэсэгт хаалттай бүртгэлийн итгэмжлэлийг оруулж, pods-д холбоосыг нэмэх хэрэгтэй. Kubernetes баримт бичигт жишээ бий үүнийг яаж хийх вэ.

Гэмтлийн давталтыг буцаах

Kubenetes алдаа гаргаж байна CrashLoopBackOff, хэрэв савыг эхлүүлэх боломжгүй бол. Энэ нь ихэвчлэн дараах үед тохиолддог:

1. Аппликешныг эхлүүлэхэд саад болж буй алдаа байна;
2. Контейнер буруу тохируулсан;
3. Амьдрах тест хэт олон удаа бүтэлгүйтсэн.

Та бүтэлгүйтлийн шалтгааныг олж мэдэхийн тулд савнаас лог руу орохыг хичээх хэрэгтэй. Хэрэв контейнер хэт хурдан дахин ачаалсны улмаас бүртгэлд хандахад хэцүү байвал та дараах тушаалыг ашиглаж болно.

kubectl logs <pod-name> --previous

Энэ нь савны өмнөх хувилгаан дээрх алдааны мэдэгдлүүдийг харуулдаг.

RunContainerError

Энэ алдаа нь савыг эхлүүлэх боломжгүй үед тохиолддог. Энэ нь програмыг эхлүүлэхийн өмнөх мөчтэй тохирч байна. Энэ нь ихэвчлэн буруу тохиргооноос үүдэлтэй байдаг, жишээлбэл:

• ConfigMap эсвэл Secrets гэх мэт байхгүй эзлэхүүнийг холбохыг оролдох;
• зөвхөн унших боломжтой ботьыг унших-бичих горимд холбох оролдлого.

Баг нь ийм алдааг шинжлэхэд маш тохиромжтой kubectl describe pod <pod-name>.

Подууд Хүлээгдэж буй төлөвт байна

Нэгэнт үүсгэсэн pod нь төлөв байдалд үлдэнэ Pending.

Яагаад ийм зүйл болдог вэ?

Боломжит шалтгаанууд энд байна (хуваарьлагч хэвийн ажиллаж байна гэж бодож байна):

1. Кластерт подыг ажиллуулахад боловсруулах хүч, санах ой зэрэг хангалттай нөөц байхгүй.
2. Объектыг зохих нэрийн талбарт суулгасан ResourceQuota мөн pod үүсгэх нь нэрийн орон зайг квотоос хэтрүүлэх болно.
3. Pod нь хүлээгдэж байгаа PersistentVolumeClaim.

Энэ тохиолдолд командыг ашиглахыг зөвлөж байна kubectl describe мөн хэсгийг шалгана уу Events:

kubectl describe pod <pod name>

холбоотой алдаа гарсан тохиолдолд ResourceQuotas, командыг ашиглан кластерын бүртгэлийг үзэхийг зөвлөж байна

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

Хос бэлэн биш байна

Хэрэв pod гэж жагсаасан бол Running, гэхдээ төлөвт ороогүй байна Ready, бэлэн байдлыг шалгах гэсэн үг (бэлэн байдлын шалгалт) бүтэлгүйтдэг.

Ийм зүйл тохиолдоход pod нь үйлчилгээнд холбогддоггүй бөгөөд түүн рүү ямар ч урсгал урсдаггүй. Бэлэн байдлын шалгалтын бүтэлгүйтэл нь програмын асуудлаас үүдэлтэй. Энэ тохиолдолд алдааг олохын тулд та хэсэгт дүн шинжилгээ хийх хэрэгтэй Events командын гаралтанд kubectl describe.

2. Үйлчилгээний оношлогоо

Хэрэв хонхорцог гэж жагсаасан бол Running и Ready, гэхдээ програмаас хариу ирээгүй байгаа тул та үйлчилгээний тохиргоог шалгах хэрэгтэй.

Үйлчилгээнүүд нь шошгоос хамааран трафикийг pods руу чиглүүлэх үүрэгтэй. Тиймээс та хамгийн түрүүнд хийх ёстой зүйл бол үйлчилгээтэй хэр олон pods ажиллаж байгааг шалгах явдал юм. Үүнийг хийхийн тулд та үйлчилгээний төгсгөлийн цэгүүдийг шалгаж болно:

kubectl describe service <service-name> | grep Endpoints

Төгсгөлийн цэг нь маягтын хос утгууд юм <IP-адрес:порт>, мөн гаралтад дор хаяж нэг ийм хос байх ёстой (өөрөөр хэлбэл, дор хаяж нэг pod нь үйлчилгээтэй ажилладаг).

Хэрэв хэсэг Endpoins хоосон, хоёр сонголт боломжтой:

1. зөв шошготой хонхорцог байхгүй (санамж: нэрийн орон зай зөв сонгогдсон эсэхийг шалгана уу);
2. Сонгогч дээрх үйлчилгээний шошгонд алдаа байна.

Хэрэв та төгсгөлийн цэгүүдийн жагсаалтыг харж байгаа ч програм руу нэвтэрч чадахгүй байгаа бол буруутан нь алдаа байж магадгүй юм targetPort үйлчилгээний тайлбарт.

Үйлчилгээний ажиллагааг хэрхэн шалгах вэ?

Үйлчилгээний төрлөөс үл хамааран та тушаалыг ашиглаж болно kubectl port-forward түүнтэй холбогдохын тулд:

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

Энд:

• <service-name> - үйлчилгээний нэр;
• 3000 бол таны компьютер дээр нээх порт юм;
• 80 - үйлчилгээний талын порт.

3. Оролтын оношлогоо

Хэрэв та энэ хүртэл уншсан бол:

• хонхорцог гэж жагсаасан байна Running и Ready;
• Энэ үйлчилгээ нь подкоор дамжуулан траффикийг амжилттай түгээдэг.

Гэсэн хэдий ч та апп-д холбогдох боломжгүй хэвээр байна.

Энэ нь Ingress хянагчийг зөв тохируулаагүй байх магадлалтай гэсэн үг юм. Ingress хянагч нь кластер дахь гуравдагч талын бүрэлдэхүүн хэсэг учраас түүний төрлөөс хамааран дибаг хийх янз бүрийн аргууд байдаг.

Гэхдээ та Ingress-ийг тохируулах тусгай хэрэгслийг ашиглахаасаа өмнө маш энгийн зүйлийг хийж болно. Ingress ашигладаг serviceName и servicePort үйлчилгээнд холбогдохын тулд. Та тэдгээрийг зөв тохируулсан эсэхийг шалгах хэрэгтэй. Та үүнийг дараах тушаалыг ашиглан хийж болно.

kubectl describe ingress <ingress-name>

Хэрэв багана Backend хоосон бол тохиргооны алдаа гарах магадлал өндөр байна. Хэрэв арын хэсгүүд байгаа боловч програмд ​​хандах боломжгүй хэвээр байвал асуудал дараахтай холбоотой байж магадгүй юм.

• Олон нийтийн интернетээс нэвтрэх тохиргоог хийх;
• нийтийн интернетээс кластерийн хүртээмжийн тохиргоо.

Та Ingress pod руу шууд холбогдож дэд бүтэцтэй холбоотой асуудлуудыг тодорхойлж болно. Үүнийг хийхийн тулд эхлээд Ingress Controller pod-ийг олоорой (энэ нь өөр нэрийн талбарт байж болно):

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

Командыг ашиглана уу describeпортыг тохируулахын тулд:

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

Эцэст нь подволд холбоно уу:

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

Одоо компьютер дээрх 3000 портын бүх хүсэлтийг pod 80 порт руу дахин чиглүүлэх болно.

Одоо ажиллаж байна уу?

• Хэрэв тийм бол асуудал нь дэд бүтцэд байгаа юм. Энэ нь кластер руу чиглэсэн хөдөлгөөнийг яг яаж чиглүүлж байгааг олж мэдэх шаардлагатай.
• Хэрэв тийм биш бол асуудал нь Ingress хянагчтай холбоотой.

Хэрэв та Ingress хянагчийг ажиллуулж чадахгүй бол дибаг хийх хэрэгтэй болно.

Ingress хянагч олон төрөл байдаг. Хамгийн алдартай нь Nginx, HAProxy, Traefik гэх мэт. (одоо байгаа шийдлүүдийн талаар дэлгэрэнгүй мэдээллийг үзнэ үү бидний тойм - ойролцоогоор. орчуул.) Та холбогдох хянагчийн баримт бичигт байгаа алдааг олж засварлах гарын авлагаас лавлана уу. Учир нь Nginx руу орох бол хамгийн алдартай Ingress хянагч бөгөөд бид үүнтэй холбоотой асуудлыг шийдвэрлэх зарим зөвлөмжийг нийтлэлд оруулсан болно.

Ingress Nginx хянагчийг дибаг хийж байна

Ingress-nginx төсөл нь албан тушаалтантай kubectl-д зориулсан залгаас. Баг kubectl ingress-nginx ашиглаж болно:

• бүртгэл, арын хуудас, гэрчилгээ гэх мэт дүн шинжилгээ хийх;
• Ingress-тэй холбогдох;
• одоогийн тохиргоог судалж байна.

Дараах гурван тушаал танд үүнийг хийхэд тусална.

• kubectl ingress-nginx lint - шалгалт nginx.conf;
• kubectl ingress-nginx backend — арын хэсгийг судалдаг (үүнтэй төстэй kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs - бүртгэлийг шалгана.

Зарим тохиолдолд та далбаа ашиглан Ingress хянагчийн нэрийн орон зайг зөв зааж өгөх шаардлагатай болохыг анхаарна уу --namespace <name>.

Хураангуй

Хэрэв та хаанаас эхлэхээ мэдэхгүй байгаа бол Kubernetes-ийн алдааг олж засварлах нь хэцүү байх болно. Та асуудалд үргэлж доороос нь хандах хэрэгтэй: pods-ээс эхэлж, дараа нь үйлчилгээ болон Ingress руу шилжинэ. Энэ нийтлэлд тайлбарласан дибаг хийх аргуудыг бусад объектуудад ашиглаж болно, тухайлбал:

• сул зогсолттой ажил болон CronJobs;
• StatefulSets болон DaemonSets.

Би талархлаа илэрхийлж байна Гергели Риско, Даниел Вайбель и Чарльз Кристираж үнэ цэнэтэй санал, нэмэлт.

Орчуулагчийн жич

Мөн манай блог дээрээс уншина уу:

• «Kubernetes pods дээр дибаг хийх kubectl-дибаг залгаас";
• «Kubernetes-ийн үйл ажиллагааны 6 хөгжилтэй системийн алдаа [болон тэдгээрийн шийдэл]";
• «Kubernetes дээр ажиллаж байгаа программ хөгжүүлэгчдэд зориулсан хэрэгслүүд";
• «Бидний SRE-ийн өдөр тутмын амьдралын 6 практик түүх ".

Эх сурвалж: www.habr.com