ຄູ່ມືສາຍຕາເພື່ອແກ້ໄຂບັນຫາ Kubernetes

ຫມາຍ​ເຫດ​. ແປ.: ບົດ​ຄວາມ​ນີ້​ແມ່ນ​ສ່ວນ​ຫນຶ່ງ​ຂອງ​ເອ​ກະ​ສານ​ຂອງ​ໂຄງ​ການ​ໄດ້​ຈັດ​ພີມ​ມາ​ໃນ​ໂດ​ເມນ​ສາ​ທາ​ລະ​ນະ​ ຮຽນ​ຮູ້ 8s, ການຝຶກອົບຮົມບໍລິສັດແລະຜູ້ບໍລິຫານສ່ວນບຸກຄົນເພື່ອເຮັດວຽກກັບ Kubernetes. ໃນນັ້ນ, Daniele Polencic, ຜູ້ຈັດການໂຄງການ, ແບ່ງປັນຄໍາແນະນໍາທາງສາຍຕາກ່ຽວກັບຂັ້ນຕອນທີ່ຈະປະຕິບັດໃນກໍລະນີຂອງບັນຫາທົ່ວໄປກັບແອັບພລິເຄຊັນທີ່ເຮັດວຽກຢູ່ໃນກຸ່ມ K8s.

TL;DR: ນີ້ແມ່ນແຜນວາດທີ່ຈະຊ່ວຍໃຫ້ທ່ານດີບັກການນຳໃຊ້ໃນ Kubernetes:

ແຜນຜັງວຽກສໍາລັບການຊອກຫາ ແລະແກ້ໄຂຂໍ້ຜິດພາດໃນກຸ່ມ. ຕົ້ນສະບັບ (ໃນພາສາອັງກິດ) ແມ່ນມີຢູ່ PDF и ຕາມຮູບ.

ເມື່ອນຳໃຊ້ແອັບພລິເຄຊັນໄປໃສ່ Kubernetes, ໂດຍທົ່ວໄປແລ້ວມີສາມອົງປະກອບທີ່ເຈົ້າຕ້ອງກຳນົດ:

• ການປະຕິບັດ - ນີ້ແມ່ນປະເພດຂອງສູດສໍາລັບການສ້າງສໍາເນົາຄໍາຮ້ອງສະຫມັກ, ເອີ້ນວ່າຝັກ;
• ການບໍລິການ — ຕົວດຸ່ນດ່ຽງການໂຫຼດພາຍໃນທີ່ແຈກຢາຍການຈະລາຈອນລະຫວ່າງຝັກ;
• Ingress — ລາຍ​ລະ​ອຽດ​ຂອງ​ການ​ຈະ​ລາ​ຈອນ​ຈະ​ໄດ້​ຮັບ​ຈາກ​ໂລກ​ພາຍ​ນອກ​ການ​ບໍ​ລິ​ການ​.

ນີ້ແມ່ນສະຫຼຸບແບບກຣາຟິກດ່ວນ:

1) ໃນ Kubernetes, ແອັບພລິເຄຊັນໄດ້ຮັບການຈະລາຈອນຈາກໂລກພາຍນອກຜ່ານສອງຊັ້ນຂອງຕົວດຸ່ນດ່ຽງການໂຫຼດ: ພາຍໃນແລະພາຍນອກ.

2) ຕົວດຸ່ນດ່ຽງພາຍໃນເອີ້ນວ່າບໍລິການ, ພາຍນອກເອີ້ນວ່າ Ingress.

3) ການປະຕິບັດສ້າງຝັກແລະຕິດຕາມພວກມັນ (ພວກມັນບໍ່ໄດ້ຖືກສ້າງດ້ວຍຕົນເອງ).

ໃຫ້ເວົ້າວ່າທ່ານຕ້ອງການປັບໃຊ້ຄໍາຮ້ອງສະຫມັກທີ່ງ່າຍດາຍ a la ສະບາຍດີໂລກ. ການຕັ້ງຄ່າ 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?
• ຂ້ອຍຄວນສ້າງພອດໃຫມ່ສໍາລັບແຕ່ລະບໍລິການເພື່ອໃຫ້ພວກເຂົາບໍ່ຂັດແຍ້ງ?
• ຊື່ປ້າຍຊື່ສຳຄັນບໍ? ພວກເຂົາຄວນຈະຄືກັນຢູ່ທົ່ວທຸກແຫ່ງບໍ?

ກ່ອນທີ່ຈະສຸມໃສ່ການ debugging, ໃຫ້ພວກເຮົາຈື່ວິທີການສາມອົງປະກອບທີ່ກ່ຽວຂ້ອງກັນ. ເລີ່ມຕົ້ນດ້ວຍການໃຊ້ງານ ແລະການບໍລິການ.

ຄວາມສໍາພັນລະຫວ່າງການນໍາໄປໃຊ້ແລະການບໍລິການ

ທ່ານຈະປະຫລາດໃຈ, ແຕ່ການຈັດສົ່ງແລະການບໍລິການບໍ່ໄດ້ເຊື່ອມຕໍ່ໃນທາງໃດກໍ່ຕາມ. ແທນທີ່ຈະ, ການບໍລິການຊີ້ໂດຍກົງໃສ່ Pods, ຂ້າມການໃຊ້ງານ.

ດັ່ງນັ້ນ, ພວກເຮົາມີຄວາມສົນໃຈໃນວິທີການ Pods ແລະການບໍລິການແມ່ນກ່ຽວຂ້ອງກັບກັນແລະກັນ. ສາມ​ສິ່ງ​ທີ່​ຄວນ​ຈື່​ຈໍາ​:

1. ຕົວເລືອກ (selector) ສໍາລັບການບໍລິການຕ້ອງກົງກັບປ້າຍ Pod ຢ່າງໜ້ອຍໜຶ່ງອັນ.
2. targetPort ຕ້ອງກົງກັນ containerPort ບັນຈຸພາຍໃນ Pod ໄດ້.
3. port ການບໍລິການສາມາດເປັນອັນໃດກໍໄດ້. ບໍລິການທີ່ແຕກຕ່າງກັນສາມາດນໍາໃຊ້ພອດດຽວກັນເພາະວ່າພວກເຂົາມີທີ່ຢູ່ IP ທີ່ແຕກຕ່າງກັນ.

ແຜນວາດຕໍ່ໄປນີ້ເປັນຕົວແທນທັງໝົດຂ້າງເທິງໃນຮູບແບບກາຟິກ:

1) ຈິນຕະນາການວ່າການບໍລິການນໍາພາການຈະລາຈອນໄປຫາຝັກທີ່ແນ່ນອນ:

2) ເມື່ອສ້າງຝັກ, ທ່ານຕ້ອງລະບຸ containerPort ສໍາລັບແຕ່ລະຖັງໃນຝັກ:

3) ເມື່ອສ້າງການບໍລິການ, ທ່ານຕ້ອງລະບຸ port и targetPort. ແຕ່ອັນໃດທີ່ໃຊ້ເພື່ອເຊື່ອມຕໍ່ກັບຕູ້ຄອນເທນເນີ?

4) ຜ່ານ targetPort. ມັນຕ້ອງກົງກັນ containerPort.

5) ໃຫ້ເວົ້າວ່າ port 3000 ເປີດຢູ່ໃນ container. ຫຼັງຈາກນັ້ນ, ຄ່າ 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 ເພື່ອຕິດຕາມຝັກ.

ໃຫ້ສົມມຸດວ່າທ່ານໄດ້ເຮັດການແກ້ໄຂທີ່ຖືກຕ້ອງ. ກວດເບິ່ງພວກມັນແນວໃດ?

ທ່ານສາມາດກວດເບິ່ງປ້າຍ pod ດ້ວຍຄໍາສັ່ງຕໍ່ໄປນີ້:

kubectl get pods --show-labels

ຫຼື, ຖ້າ pods ເປັນຂອງຄໍາຮ້ອງສະຫມັກຈໍານວນຫນຶ່ງ:

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

ຂັ້ນຕອນຕໍ່ໄປໃນການສະຫນອງການເຂົ້າເຖິງຄໍາຮ້ອງສະຫມັກແມ່ນກ່ຽວຂ້ອງກັບການຕັ້ງຄ່າ Ingress. Ingress ຕ້ອງການຮູ້ວິທີການຊອກຫາບໍລິການ, ຫຼັງຈາກນັ້ນຊອກຫາຝັກແລະການຈະລາຈອນໂດຍກົງກັບພວກເຂົາ. Ingress ຊອກຫາການບໍລິການທີ່ຕ້ອງການໂດຍຊື່ແລະພອດເປີດ.

ໃນລາຍລະອຽດຂອງ Ingress ແລະ Service ສອງພາລາມິເຕີຕ້ອງກົງກັນ:

1. servicePort ໃນ Ingress ຕ້ອງກົງກັບພາລາມິເຕີ port ໃນການບໍລິການ;
2. serviceName ໃນ Ingress ຕ້ອງກົງກັບພາກສະຫນາມ name ໃນການບໍລິການ.

ແຜນວາດຕໍ່ໄປນີ້ສະຫຼຸບການເຊື່ອມຕໍ່ພອດ:

1) ດັ່ງທີ່ເຈົ້າຮູ້ແລ້ວ, ບໍລິການຟັງສິ່ງທີ່ແນ່ນອນ port:

2) Ingress ມີພາລາມິເຕີທີ່ເອີ້ນວ່າ 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 (ມັນອາດຈະຢູ່ໃນ namespace ທີ່ແຕກຕ່າງກັນ) ແລະດໍາເນີນການຄໍາສັ່ງ describeເພື່ອຊອກຫາຕົວເລກທີ່ Port:

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 ໃນຄອມພິວເຕີຂອງທ່ານ, ມັນຈະຖືກສົ່ງຕໍ່ໄປຫາພອດ 80 ຂອງຝັກດ້ວຍຕົວຄວບຄຸມ Ingress. ໂດຍການໄປ http://localhost:3000, ທ່ານຄວນຈະເຫັນຫນ້າທີ່ສ້າງໂດຍຄໍາຮ້ອງສະຫມັກ.

ສະຫຼຸບຂອງພອດ

ຂໍໃຫ້ຈື່ອີກເທື່ອຫນຶ່ງວ່າພອດແລະປ້າຍຊື່ໃດຕ້ອງກົງກັນ:

1. ຕົວເລືອກໃນຄໍານິຍາມການບໍລິການຕ້ອງກົງກັບປ້າຍຊື່ຂອງຝັກ;
2. targetPort ໃນຄໍານິຍາມການບໍລິການຕ້ອງກົງກັນ containerPort ບັນຈຸພາຍໃນຝັກ;
3. port ໃນຄໍານິຍາມການບໍລິການສາມາດເປັນອັນໃດກໍໄດ້. ບໍລິການທີ່ແຕກຕ່າງກັນສາມາດນໍາໃຊ້ພອດດຽວກັນເພາະວ່າພວກເຂົາມີທີ່ຢູ່ IP ທີ່ແຕກຕ່າງກັນ;
4. servicePort Ingress ຕ້ອງກົງກັນ port ໃນຄໍານິຍາມຂອງການບໍລິການ;
5. ຊື່ບໍລິການຕ້ອງກົງກັບຊ່ອງຂໍ້ມູນ serviceName ໃນ Ingress.

ແຕ່ຫນ້າເສຍດາຍ, ມັນບໍ່ພຽງພໍທີ່ຈະຮູ້ວິທີການຈັດໂຄງສ້າງ YAML ຢ່າງຖືກຕ້ອງ.

ຈະເກີດຫຍັງຂຶ້ນເມື່ອສິ່ງທີ່ຜິດພາດ?

ຝັກອາດຈະບໍ່ເລີ່ມຫຼືມັນອາດຈະຂັດ.

3 ຂັ້ນຕອນໃນການວິນິດໄສບັນຫາແອັບພລິເຄຊັນໃນ Kubernetes

ກ່ອນທີ່ທ່ານຈະເລີ່ມຕົ້ນການດີບັກການໃຊ້ງານຂອງທ່ານ, ທ່ານຈໍາເປັນຕ້ອງມີຄວາມເຂົ້າໃຈດີກ່ຽວກັບວິທີເຮັດວຽກ 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

ໃນຜົນໄດ້ຮັບຄໍາສັ່ງຂ້າງເທິງ, ຝັກສຸດທ້າຍແມ່ນລະບຸໄວ້ເປັນ Running и Readyຢ່າງໃດກໍຕາມ, ນີ້ບໍ່ແມ່ນກໍລະນີສໍາລັບອີກສອງຄົນ.

ວິທີການເຂົ້າໃຈສິ່ງທີ່ຜິດພາດ?

ມີສີ່ຄໍາສັ່ງທີ່ເປັນປະໂຫຍດສໍາລັບການວິນິດໄສ pods:

1. kubectl logs <имя pod'а> ອະນຸຍາດໃຫ້ທ່ານສາມາດສະກັດໄມ້ທ່ອນຈາກບັນຈຸຢູ່ໃນຝັກ;
2. kubectl describe pod <имя pod'а> ອະນຸຍາດໃຫ້ທ່ານເບິ່ງບັນຊີລາຍຊື່ຂອງເຫດການທີ່ກ່ຽວຂ້ອງກັບຝັກ;
3. kubectl get pod <имя pod'а> ອະນຸຍາດໃຫ້ທ່ານໄດ້ຮັບການຕັ້ງຄ່າ YAML ຂອງຝັກທີ່ເກັບໄວ້ໃນ Kubernetes;
4. kubectl exec -ti <имя pod'а> bash ອະນຸຍາດໃຫ້ທ່ານເປີດ shell ຄໍາສັ່ງແບບໂຕ້ຕອບຢູ່ໃນຫນຶ່ງໃນບັນຈຸຝັກ

ເຈົ້າຄວນເລືອກອັນໃດ?

ຄວາມຈິງແມ່ນວ່າບໍ່ມີຄໍາສັ່ງທົ່ວໄປ. ການປະສົມປະສານຂອງສິ່ງເຫຼົ່ານີ້ຄວນຈະຖືກນໍາໃຊ້.

ບັນຫາຝັກທົ່ວໄປ

ມີ​ສອງ​ປະ​ເພດ​ຕົ້ນ​ຕໍ​ຂອງ​ຄວາມ​ຜິດ​ພາດ pod ແມ່ນ​: ຄວາມ​ຜິດ​ພາດ​ການ​ເລີ່ມ​ຕົ້ນ​ແລະ​ຄວາມ​ຜິດ​ພາດ runtime​.

ຄວາມ​ຜິດ​ພາດ​ການ​ເລີ່ມ​ຕົ້ນ​:

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

Runtime ຜິດ​ພາດ​:

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

ຂໍ້ຜິດພາດບາງຢ່າງແມ່ນພົບເລື້ອຍກວ່າຄົນອື່ນ. ນີ້ແມ່ນບາງຂໍ້ຜິດພາດທົ່ວໄປທີ່ສຸດແລະວິທີການແກ້ໄຂພວກມັນ.

ຮູບພາບPullBackOff

ຂໍ້ຜິດພາດນີ້ປາກົດຂຶ້ນເມື່ອ Kubernetes ບໍ່ສາມາດໄດ້ຮັບຮູບພາບສໍາລັບຫນຶ່ງໃນບັນຈຸ pod ໄດ້. ນີ້ແມ່ນສາມເຫດຜົນທົ່ວໄປທີ່ສຸດສໍາລັບການນີ້:

1. ຊື່ຂອງຮູບພາບແມ່ນບໍ່ຖືກຕ້ອງ - ຕົວຢ່າງ, ທ່ານໄດ້ເຮັດຜິດພາດໃນມັນ, ຫຼືຮູບພາບບໍ່ມີ;
2. ໂຄດຄໍາສັ່ງທີ່ບໍ່ມີຢູ່ແລ້ວແມ່ນໄດ້ລະບຸໄວ້ສໍາລັບຮູບພາບ;
3. ຮູບພາບຖືກເກັບໄວ້ໃນທະບຽນສ່ວນຕົວ ແລະ Kubernetes ບໍ່ມີການອະນຸຍາດເຂົ້າເຖິງມັນ.

ສອງເຫດຜົນທໍາອິດແມ່ນງ່າຍທີ່ຈະກໍາຈັດ - ພຽງແຕ່ແກ້ໄຂຊື່ຮູບພາບແລະແທັກ. ໃນກໍລະນີສຸດທ້າຍ, ທ່ານຈໍາເປັນຕ້ອງໃສ່ຂໍ້ມູນປະຈໍາຕົວສໍາລັບການລົງທະບຽນທີ່ຖືກປິດໄວ້ໃນຄວາມລັບແລະເພີ່ມການເຊື່ອມຕໍ່ກັບມັນໃນຝັກ. ໃນເອກະສານ Kubernetes ມີຕົວຢ່າງ ວິທີການນີ້ສາມາດເຮັດໄດ້.

Crash Loop Back Off

Kubenetes ຖິ້ມຄວາມຜິດພາດ CrashLoopBackOff, ຖ້າຖັງບໍ່ສາມາດເລີ່ມຕົ້ນໄດ້. ນີ້ມັກຈະເກີດຂຶ້ນເມື່ອ:

1. ມີ bug ໃນຄໍາຮ້ອງສະຫມັກທີ່ປ້ອງກັນບໍ່ໃຫ້ມັນຈາກການເປີດຕົວ;
2. Container ຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ;
3. ການທົດສອບ Liveness ໄດ້ລົ້ມເຫລວຫຼາຍເທື່ອເກີນໄປ.

ທ່ານຕ້ອງພະຍາຍາມໄປຫາໄມ້ທ່ອນຈາກຕູ້ຄອນເທນເນີເພື່ອຊອກຫາເຫດຜົນສໍາລັບຄວາມລົ້ມເຫຼວຂອງມັນ. ຖ້າມັນມີຄວາມຫຍຸ້ງຍາກໃນການເຂົ້າເຖິງບັນທຶກເນື່ອງຈາກວ່າ container restarts ໄວເກີນໄປ, ທ່ານສາມາດນໍາໃຊ້ຄໍາສັ່ງຕໍ່ໄປນີ້:

kubectl logs <pod-name> --previous

ມັນສະແດງຂໍ້ຄວາມຜິດພາດຈາກ incarnation ທີ່ຜ່ານມາຂອງບັນຈຸ.

RunContainerError

ຄວາມຜິດພາດນີ້ເກີດຂຶ້ນເມື່ອກ່ອງບັນຈຸບໍ່ສາມາດເລີ່ມຕົ້ນໄດ້. ມັນກົງກັບປັດຈຸບັນກ່ອນທີ່ແອັບພລິເຄຊັນຈະເປີດຕົວ. ມັນມັກຈະເກີດມາຈາກການຕັ້ງຄ່າທີ່ບໍ່ຖືກຕ້ອງ, ຕົວຢ່າງ:

• ພະຍາຍາມຕິດຕັ້ງປະລິມານທີ່ບໍ່ມີຢູ່ເຊັ່ນ ConfigMap ຫຼືຄວາມລັບ;
• ຄວາມພະຍາຍາມທີ່ຈະເຊື່ອມຕໍ່ປະລິມານອ່ານເທົ່ານັ້ນເປັນ read-write.

ທີມງານແມ່ນເຫມາະສົມດີສໍາລັບການວິເຄາະຄວາມຜິດພາດດັ່ງກ່າວ kubectl describe pod <pod-name>.

Pods ຢູ່ໃນສະຖານະທີ່ຍັງຄ້າງຢູ່

ເມື່ອສ້າງແລ້ວ, ຝັກຍັງຢູ່ໃນສະຖານະ Pending.

ເປັນຫຍັງສິ່ງນີ້ເກີດຂຶ້ນ?

ນີ້ແມ່ນເຫດຜົນທີ່ເປັນໄປໄດ້ (ຂ້ອຍສົມມຸດວ່າຕົວກໍານົດເວລາເຮັດວຽກໄດ້ດີ):

1. ກຸ່ມບໍ່ມີຊັບພະຍາກອນພຽງພໍ, ເຊັ່ນ: ພະລັງງານປະມວນຜົນ ແລະໜ່ວຍຄວາມຈຳ, ເພື່ອແລ່ນພອດ.
2. ວັດຖຸໄດ້ຖືກຕິດຕັ້ງຢູ່ໃນ namespace ທີ່ເຫມາະສົມ ResourceQuota ແລະການສ້າງ pod ຈະເຮັດໃຫ້ namespace ໄປເກີນໂຄຕ້າ.
3. Pod ຖືກຜູກມັດກັບ Pending PersistentVolumeClaim.

ໃນກໍລະນີນີ້, ແນະນໍາໃຫ້ໃຊ້ຄໍາສັ່ງ kubectl describe ແລະກວດເບິ່ງພາກສ່ວນ Events:

kubectl describe pod <pod name>

ໃນກໍລະນີຂອງຄວາມຜິດພາດທີ່ກ່ຽວຂ້ອງກັບ ResourceQuotas, ມັນແນະນໍາໃຫ້ເບິ່ງບັນທຶກຂອງກຸ່ມໂດຍໃຊ້ຄໍາສັ່ງ

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

ຝັກບໍ່ພ້ອມ

ຖ້າຝັກຖືກລະບຸໄວ້ເປັນ Running, ແຕ່ບໍ່ໄດ້ຢູ່ໃນສະຖານະ Ready, ຫມາຍຄວາມວ່າການກວດສອບຄວາມພ້ອມຂອງມັນ (ການ​ສໍາ​ຫຼວດ​ຄວາມ​ພ້ອມ​) ລົ້ມເຫລວ.

ເມື່ອສິ່ງດັ່ງກ່າວເກີດຂຶ້ນ, ຝັກບໍ່ເຊື່ອມຕໍ່ກັບການບໍລິການແລະບໍ່ມີການຈະລາຈອນໄຫລໄປຫາມັນ. ຄວາມລົ້ມເຫຼວຂອງການທົດສອບຄວາມພ້ອມແມ່ນເກີດຈາກບັນຫາໃນຄໍາຮ້ອງສະຫມັກ. ໃນກໍລະນີນີ້, ເພື່ອຊອກຫາຂໍ້ຜິດພາດ, ທ່ານຈໍາເປັນຕ້ອງວິເຄາະສ່ວນ Events ໃນ​ການ​ອອກ​ຄໍາ​ສັ່ງ​ kubectl describe.

2. ການວິນິດໄສການບໍລິການ

ຖ້າຝັກຖືກລະບຸໄວ້ເປັນ Running и Ready, ແຕ່ຍັງບໍ່ທັນມີຄໍາຕອບຈາກຄໍາຮ້ອງສະຫມັກ, ທ່ານຄວນກວດເບິ່ງການຕັ້ງຄ່າການບໍລິການ.

ການບໍລິການແມ່ນຮັບຜິດຊອບສໍາລັບເສັ້ນທາງການຈະລາຈອນໄປຫາຝັກໂດຍຂຶ້ນກັບປ້າຍຊື່ຂອງພວກເຂົາ. ດັ່ງນັ້ນ, ສິ່ງທໍາອິດທີ່ທ່ານຈໍາເປັນຕ້ອງເຮັດແມ່ນກວດເບິ່ງຈໍານວນຝັກທີ່ເຮັດວຽກກັບການບໍລິການ. ເພື່ອເຮັດສິ່ງນີ້, ທ່ານສາມາດກວດເບິ່ງຈຸດສິ້ນສຸດໃນການບໍລິການ:

kubectl describe service <service-name> | grep Endpoints

ຈຸດສິ້ນສຸດແມ່ນຄູ່ຂອງຄ່າຂອງແບບຟອມ <IP-адрес:порт>, ແລະຢ່າງຫນ້ອຍຫນຶ່ງຄູ່ດັ່ງກ່າວຕ້ອງມີຢູ່ໃນຜົນຜະລິດ (ນັ້ນແມ່ນ, ຢ່າງຫນ້ອຍຫນຶ່ງຝັກເຮັດວຽກກັບການບໍລິການ).

ຖ້າພາກສ່ວນ Endpoins ຫວ່າງເປົ່າ, ສອງທາງເລືອກແມ່ນເປັນໄປໄດ້:

1. ບໍ່ມີຝັກທີ່ມີປ້າຍຊື່ທີ່ຖືກຕ້ອງ (ຄໍາແນະນໍາ: ກວດເບິ່ງວ່າ namespace ຖືກເລືອກຢ່າງຖືກຕ້ອງ);
2. ມີຂໍ້ຜິດພາດໃນປ້າຍບໍລິການຢູ່ໃນຕົວເລືອກ.

ຖ້າທ່ານເຫັນລາຍຊື່ຂອງຈຸດສິ້ນສຸດແຕ່ຍັງບໍ່ສາມາດເຂົ້າຫາແອັບພລິເຄຊັນໄດ້, ຫຼັງຈາກນັ້ນ, ຜູ້ຖືກເຄາະຮ້າຍທີ່ອາດຈະແມ່ນແມງໄມ້ໃນ. targetPort ໃນຄໍາອະທິບາຍການບໍລິການ.

ວິທີການກວດສອບການເຮັດວຽກຂອງການບໍລິການ?

ໂດຍບໍ່ຄໍານຶງເຖິງປະເພດຂອງການບໍລິການ, ທ່ານສາມາດນໍາໃຊ້ຄໍາສັ່ງ kubectl port-forward ເພື່ອເຊື່ອມຕໍ່ກັບມັນ:

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

ທີ່ນີ້:

• <service-name> — ຊື່​ບໍ​ລິ​ການ​;
• 3000 ແມ່ນພອດທີ່ທ່ານເປີດຢູ່ໃນຄອມພິວເຕີ;
• 80 - ພອດຢູ່ດ້ານການບໍລິການ.

3. ການວິນິດໄສ Ingress

ຖ້າທ່ານໄດ້ອ່ານມາຮອດນີ້, ຫຼັງຈາກນັ້ນ:

• ຝັກແມ່ນລະບຸໄວ້ເປັນ Running и Ready;
• ການ​ບໍ​ລິ​ການ​ສົບ​ຜົນ​ສໍາ​ເລັດ​ການ​ແຜ່​ກະ​ຈາຍ​ໃນ​ທົ່ວ pods​.

ຢ່າງໃດກໍຕາມ, ທ່ານຍັງບໍ່ສາມາດເຂົ້າຫາ app ໄດ້.

ນີ້ຫມາຍຄວາມວ່າຕົວຄວບຄຸມ Ingress ສ່ວນຫຼາຍອາດຈະບໍ່ຖືກຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ. ເນື່ອງຈາກຕົວຄວບຄຸມ Ingress ເປັນອົງປະກອບຂອງພາກສ່ວນທີສາມໃນກຸ່ມ, ມີວິທີການ debugging ທີ່ແຕກຕ່າງກັນຂຶ້ນກັບປະເພດຂອງມັນ.

ແຕ່ກ່ອນທີ່ທ່ານຈະໃຊ້ເຄື່ອງມືພິເສດເພື່ອກໍານົດ Ingress, ທ່ານສາມາດເຮັດບາງສິ່ງບາງຢ່າງທີ່ງ່າຍດາຍຫຼາຍ. Ingress ໃຊ້ serviceName и servicePort ເພື່ອເຊື່ອມຕໍ່ກັບການບໍລິການ. ທ່ານຈໍາເປັນຕ້ອງກວດເບິ່ງວ່າພວກເຂົາຖືກຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ. ທ່ານສາມາດເຮັດໄດ້ໂດຍໃຊ້ຄໍາສັ່ງ:

kubectl describe ingress <ingress-name>

ຖ້າຖັນ Backend ຫວ່າງເປົ່າ, ມີຄວາມເປັນໄປໄດ້ສູງທີ່ຈະເກີດຄວາມຜິດພາດໃນການຕັ້ງຄ່າ. ຖ້າ backends ຢູ່ໃນສະຖານທີ່, ແຕ່ແອັບພລິເຄຊັນຍັງບໍ່ສາມາດເຂົ້າເຖິງໄດ້, ບັນຫາອາດຈະກ່ຽວຂ້ອງກັບ:

• Ingress ການຕັ້ງຄ່າການເຂົ້າເຖິງຈາກອິນເຕີເນັດສາທາລະນະ;
• ການຕັ້ງຄ່າການຊ່ວຍເຂົ້າເຖິງກຸ່ມຈາກອິນເຕີເນັດສາທາລະນະ.

ທ່ານສາມາດກໍານົດບັນຫາກ່ຽວກັບໂຄງສ້າງພື້ນຖານໂດຍການເຊື່ອມຕໍ່ໂດຍກົງກັບຝັກ Ingress. ເພື່ອເຮັດສິ່ງນີ້, ທໍາອິດຊອກຫາ Ingress Controller pod (ມັນອາດຈະຢູ່ໃນ 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

ໃຊ້ຄໍາສັ່ງ 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 ໃນຄອມພິວເຕີຈະຖືກໂອນໄປຫາພອດ 80 ຂອງຝັກ.

ມັນເຮັດວຽກແລ້ວບໍ?

• ຖ້າແມ່ນ, ບັນຫາແມ່ນຂຶ້ນກັບໂຄງສ້າງພື້ນຖານ. ມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະຊອກຫາວິທີທີ່ການຈະລາຈອນຖືກນໍາໄປຫາກຸ່ມ.
• ຖ້າບໍ່ແມ່ນ, ບັນຫາແມ່ນຂຶ້ນກັບຕົວຄວບຄຸມ Ingress.

ຖ້າທ່ານບໍ່ສາມາດເອົາຕົວຄວບຄຸມ Ingress ເຮັດວຽກໄດ້, ທ່ານຈະຕ້ອງດີບັກມັນ.

ມີຫຼາຍຊະນິດຂອງຕົວຄວບຄຸມ Ingress. ທີ່ນິຍົມຫຼາຍທີ່ສຸດແມ່ນ Nginx, HAProxy, Traefik, ແລະອື່ນໆ. (ສໍາລັບຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບການແກ້ໄຂທີ່ມີຢູ່ແລ້ວ, ເບິ່ງ ການທົບທວນຄືນຂອງພວກເຮົາ — ປະ​ມານ​. ແປ.) ທ່ານຄວນເບິ່ງຄູ່ມືການແກ້ໄຂບັນຫາໃນເອກະສານຄວບຄຸມທີ່ກ່ຽວຂ້ອງ. ເນື່ອງຈາກວ່າ ຂາເຂົ້າ Nginx ເປັນຕົວຄວບຄຸມ Ingress ທີ່ນິຍົມທີ່ສຸດ, ພວກເຮົາໄດ້ລວມເອົາຄໍາແນະນໍາບາງຢ່າງໃນບົດຄວາມເພື່ອແກ້ໄຂບັນຫາທີ່ກ່ຽວຂ້ອງກັບມັນ.

ການດີບັກຕົວຄວບຄຸມ Ingress Nginx

ໂຄງການ Ingress-nginx ມີເຈົ້າຫນ້າທີ່ plugin ສໍາລັບ kubectl. ທີມງານ kubectl ingress-nginx ສາ​ມາດ​ຖືກ​ນໍາ​ໃຊ້​ສໍາ​ລັບ​ການ​:

• ການວິເຄາະບັນທຶກ, backends, ໃບຢັ້ງຢືນ, ແລະອື່ນໆ;
• ການເຊື່ອມຕໍ່ກັບ Ingress;
• ການ​ສຶກ​ສາ​ການ​ຕັ້ງ​ຄ່າ​ໃນ​ປັດ​ຈຸ​ບັນ​.

ສາມຄໍາສັ່ງຕໍ່ໄປນີ້ຈະຊ່ວຍເຈົ້າໃນເລື່ອງນີ້:

• kubectl ingress-nginx lint — ການ​ກວດ​ສອບ​ nginx.conf;
• kubectl ingress-nginx backend — ສຳຫຼວດເບື້ອງຫຼັງ (ຄ້າຍກັບ kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs — ກວດ​ສອບ​ບັນ​ທຶກ​.

ໃຫ້ສັງເກດວ່າໃນບາງກໍລະນີທ່ານອາດຈະຕ້ອງລະບຸ namespace ທີ່ຖືກຕ້ອງສໍາລັບ Ingress controller ໂດຍໃຊ້ທຸງ --namespace <name>.

Summary

ການແກ້ໄຂບັນຫາ Kubernetes ສາມາດເປັນສິ່ງທ້າທາຍຖ້າທ່ານບໍ່ຮູ້ວ່າຈະເລີ່ມຕົ້ນຈາກໃສ. ທ່ານສະເຫມີຄວນເຂົ້າຫາບັນຫາໃນລັກສະນະລຸ່ມສຸດ: ເລີ່ມຕົ້ນດ້ວຍຝັກ, ແລະຫຼັງຈາກນັ້ນຍ້າຍໄປບໍລິການແລະ Ingress. ເຕັກນິກການດີບັກທີ່ອະທິບາຍໄວ້ໃນບົດຄວາມນີ້ສາມາດຖືກນໍາໃຊ້ກັບວັດຖຸອື່ນໆ, ເຊັ່ນ:

• idle Jobs ແລະ CronJobs;
• StatefulSets ແລະ DaemonSets.

ຂ້າພະເຈົ້າສະແດງຄວາມກະຕັນຍູ Gergely Risko, Daniel Weibel и Charles Christyraj ສໍາລັບຄໍາຄິດເຫັນທີ່ມີຄຸນຄ່າແລະການເພີ່ມເຕີມ.

PS ຈາກນັກແປ

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ປັ໊ກອິນ kubectl-debug ສຳລັບການດີບັກໃນພອດ Kubernetes"
• «6 ແມງໄມ້ລະບົບທີ່ຫນ້າສົນໃຈເມື່ອໃຊ້ Kubernetes [ແລະການແກ້ໄຂຂອງມັນ]"
• «ເຄື່ອງມືສໍາລັບນັກພັດທະນາແອັບພລິເຄຊັນທີ່ເຮັດວຽກຢູ່ໃນ Kubernetes"
• «6 ເລື່ອງປະຕິບັດຈາກ SRE ຂອງພວກເຮົາປະຈໍາວັນ ".

ແຫຼ່ງຂໍ້ມູນ: www.habr.com