Kubernetes ပြဿနာဖြေရှင်းခြင်းအတွက် အမြင်အာရုံလမ်းညွှန်

မှတ်ချက်။ ဘာသာပြန်: ဤဆောင်းပါးသည် အများသူငှာထုတ်ဝေသည့် ပရောဂျက်ပစ္စည်းများ၏ တစ်စိတ်တစ်ပိုင်းဖြစ်သည်။ learnk8sKubernetes နှင့် အလုပ်လုပ်ရန် ကုမ္ပဏီများနှင့် တစ်ဦးချင်း စီမံခန့်ခွဲသူများကို လေ့ကျင့်ပေးခြင်း။ ၎င်းတွင်၊ ပရောဂျက်မန်နေဂျာ Daniele Polencic သည် K8s အစုအဝေးတွင် လုပ်ဆောင်နေသည့် အက်ပ်လီကေးရှင်းများနှင့် အထွေထွေပြဿနာများနှင့်ပတ်သက်၍ လုပ်ဆောင်ရမည့်အဆင့်များနှင့်ပတ်သက်၍ အမြင်အာရုံလမ်းညွှန်ချက်များကို မျှဝေပါသည်။

TL;DR- ဤနေရာတွင် Kubernetes တွင် သင့်အား အသုံးပြုမှုကို အမှားရှာရန် ကူညီမည့် ပုံကားချပ်တစ်ခုဖြစ်သည်။

အစုအဝေးတစ်ခုရှိ အမှားများကို ရှာဖွေခြင်းနှင့် ပြုပြင်ခြင်းအတွက် အစီအစဥ်ဇယား။ မူရင်း (အင်္ဂလိပ်လို) မှာ ရနိုင်ပါတယ်။ PDF ဖိုင်ရယူရန် и ပုံကဲ့သို့.

အက်ပ်လီကေးရှင်းကို Kubernetes သို့ အသုံးချသောအခါ၊ သင်သတ်မှတ်ရန် လိုအပ်သော အစိတ်အပိုင်း သုံးခု ရှိသည်-

• ဖြန့်ကျက် - ဤသည် pods ဟုခေါ်သောလျှောက်လွှာကော်ပီများဖန်တီးရန်စာရွက်အမျိုးအစားတစ်ခုဖြစ်သည်။
• ဝန်ဆောင်မှု - pods များကြား အသွားအလာ ဖြန့်ဝေပေးသော internal load balancer;
• Ingress — ပြင်ပကမ္ဘာမှ ဝန်ဆောင်မှုသို့ မည်ကဲ့သို့ အသွားအလာများလာမည်ကို ဖော်ပြချက်။

ဤသည်မှာ အမြန်ဂရပ်ဖစ်အကျဉ်းချုပ်ဖြစ်သည်။

1) Kubernetes တွင်၊ အပလီကေးရှင်းများသည် ဝန်ချိန်ခွင်လျှာအလွှာနှစ်ခုမှတစ်ဆင့် ပြင်ပကမ္ဘာမှ လမ်းကြောင်းများကို လက်ခံရရှိသည်- အတွင်းနှင့် ပြင်ပ။

2) internal balancer ကို Service ဟုခေါ်ပြီး ပြင်ပကို Ingress ဟုခေါ်သည်။

3) ဖြန့်ကျက်ခြင်းသည် pods များကိုဖန်တီးပြီး ၎င်းတို့ကို စောင့်ကြည့်စစ်ဆေးသည် (၎င်းတို့ကို ကိုယ်တိုင်ဖန်တီးထားခြင်းမဟုတ်ပါ)။

ရိုးရှင်းသော အပလီကေးရှင်းကို 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: /

အဓိပ္ပာယ်ဖွင့်ဆိုချက်သည် အတော်လေးရှည်လျားပြီး အစိတ်အပိုင်းများ တစ်ခုနှင့်တစ်ခု ဆက်စပ်ပုံကို ရှုပ်ထွေးရန် လွယ်ကူသည်။

ဥပမာ:

• Port 80 ကို ဘယ်အချိန်မှာ သုံးသင့်သလဲ 8080 ကို ဘယ်အချိန်မှာ သုံးသင့်လဲ။
• ဝန်ဆောင်မှုတစ်ခုစီအတွက် ဆိပ်ကမ်းအသစ်တစ်ခု ဖန်တီးသင့်သလား။
• အညွှန်းအမည်များသည် အရေးကြီးပါသလား။ နေရာတိုင်း အတူတူရှိသင့်သလား။

အမှားရှာပြင်ခြင်းကို အာရုံစိုက်ခြင်းမပြုမီ အစိတ်အပိုင်းသုံးခုသည် တစ်ခုနှင့်တစ်ခု မည်သို့ဆက်စပ်သည်ကို သတိရကြပါစို့။ ဖြန့်ကျက်ခြင်းနှင့် ဝန်ဆောင်မှုဖြင့် စတင်ကြပါစို့။

Deployment နှင့် Service အကြား ဆက်စပ်မှု

သင်အံ့သြသွားလိမ့်မည်၊ သို့သော် ဖြန့်ကျက်ခြင်းနှင့် ဝန်ဆောင်မှုသည် မည်သို့မျှ မသက်ဆိုင်ပါ။ ယင်းအစား၊ ဝန်ဆောင်မှုသည် ဖြန့်ကျက်မှုကို ကျော်ဖြတ်ကာ Pods သို့ တိုက်ရိုက်ညွှန်ပြသည်။

ထို့ကြောင့် Pods နှင့် Services သည် တစ်ခုနှင့်တစ်ခု မည်သို့ဆက်စပ်နေသည်ကို ကျွန်ုပ်တို့ စိတ်ဝင်စားပါသည်။ မှတ်ထားရမည့်အချက်သုံးချက်

1. ရွေးချယ်မှု (selector) ဝန်ဆောင်မှုအတွက် အနည်းဆုံး Pod အညွှန်းတစ်ခုနှင့် ကိုက်ညီရမည်။
2. targetPort ကိုက်ညီရမည်။ containerPort Pod အတွင်းရှိကွန်တိန်နာ။
3. port ဝန်ဆောင်မှုက ဘာမဆိုဖြစ်နိုင်ပါတယ်။ မတူညီသောဝန်ဆောင်မှုများသည် မတူညီသော IP လိပ်စာများရှိသောကြောင့် တူညီသောဆိပ်ကမ်းကို အသုံးပြုနိုင်သည်။

အောက်ပါပုံသည် ဂရပ်ဖစ်ပုံစံဖြင့် အထက်ဖော်ပြပါအရာအားလုံးကို ကိုယ်စားပြုသည်-

1) ဝန်ဆောင်မှုသည် အချို့သော pod သို့ အသွားအလာကို ညွှန်ပြသည်ဟု မြင်ယောင်ကြည့်ပါ-

2) pod တစ်ခုကို ဖန်တီးသောအခါ၊ သင်သည် သတ်မှတ်ရပါမည်။ containerPort ဘူးခွံတစ်ခုစီအတွက်

3) ဝန်ဆောင်မှုတစ်ခုဖန်တီးသောအခါ၊ သင်သတ်မှတ်ရပါမည်။ port и targetPort. သို့သော် ကွန်တိန်နာသို့ ချိတ်ဆက်ရန် မည်သည့်အရာကို အသုံးပြုသနည်း။

4) မှတဆင့် targetPort. တိုက်ဆိုင်ရမယ်။ containerPort.

5) port 3000 သည် container တွင်ဖွင့်သည်ဆိုပါစို့။ထို့နောက် value 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 ၏ အညွှန်းများနှင့် အမြဲကိုက်ညီနေရပါမည်။pods များကိုခြေရာခံရန် ၎င်းကို Deployment မှအသုံးပြုသောကြောင့်ဖြစ်သည်။

သင်သည် မှန်ကန်သော တည်းဖြတ်မှုများ ပြုလုပ်ခဲ့သည်ဟု ယူဆကြပါစို့။ သူတို့ကို ဘယ်လိုစစ်ဆေးမလဲ။

အောက်ဖော်ပြပါ command ဖြင့် pod label ကိုစစ်ဆေးနိုင်ပါသည်။

kubectl get pods --show-labels

သို့မဟုတ် pods များသည် အပလီကေးရှင်းများစွာနှင့် သက်ဆိုင်ပါက-

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

ဘယ်မှာ any-name=my-app တံဆိပ်တစ်ခုဖြစ်သည်။ any-name: my-app.

အခက်အခဲတွေ ကျန်သေးလား

pod သို့ ချိတ်ဆက်နိုင်ပါသည်။ ဒီလိုလုပ်ဖို့သင် command ကိုအသုံးပြုဖို့လိုအပ်ပါတယ်။ port-forward kubectl တွင် ၎င်းသည် သင့်အား ဝန်ဆောင်မှုသို့ ချိတ်ဆက်ရန်နှင့် ချိတ်ဆက်မှုကို စစ်ဆေးရန် ခွင့်ပြုသည်။

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

ဤနေရာတွင်:

• service/<service name> - ဝန်ဆောင်မှုအမည်; ကျွန်ုပ်တို့၏ကိစ္စတွင်၊ my-service;
• 3000 သည် ကွန်ပြူတာတွင် ဖွင့်ရန် လိုအပ်သော port ဖြစ်သည်။
• 80 - အကွက်တွင် သတ်မှတ်ထားသော ဆိပ်ကမ်း port ဝန်ဆောင်မှု။

ချိတ်ဆက်မှုကို တည်ထောင်ပါက၊ ဆက်တင်များ မှန်ကန်ပါသည်။

ချိတ်ဆက်မှု ပျက်သွားပါက၊ အညွှန်းများနှင့် ပြဿနာရှိနေသည် သို့မဟုတ် ဆိပ်ကမ်းများ မကိုက်ညီပါ။

Service နှင့် Ingress အကြားဆက်ဆံရေး

အပလီကေးရှင်းသို့ဝင်ရောက်ခွင့်ပေးခြင်းတွင်နောက်တဆင့်တွင် Ingress ကိုထည့်သွင်းခြင်းပါဝင်သည်။ Ingress သည် ဝန်ဆောင်မှုတစ်ခုအား မည်သို့ရှာဖွေရမည်ကို သိရန်လိုအပ်ပြီး၊ ထို့နောက် pods များကို ရှာဖွေပြီး ၎င်းတို့ထံ လမ်းကြောင်းကို ညွှန်ပြရန် လိုအပ်သည်။ Ingress သည် လိုအပ်သော ဝန်ဆောင်မှုကို အမည်နှင့် ဖွင့်ထားသော ဆိပ်ကမ်းဖြင့် ရှာဖွေသည်။

Ingress နှင့် Service ၏ ဖော်ပြချက်တွင် ဘောင်နှစ်ခု တူညီရမည်-

1. servicePort Ingress တွင် parameter နှင့်ကိုက်ညီရမည်။ port ဝန်ဆောင်မှုတွင်;
2. serviceName Ingress တွင် အကွက်နှင့် ကိုက်ညီရမည်။ name ဝန်ဆောင်မှု။

အောက်ပါပုံသည် ဆိပ်ကမ်းချိတ်ဆက်မှုများကို အကျဉ်းချုပ်ဖော်ပြသည်-

1) သင်သိပြီးသားဖြစ်တဲ့အတိုင်း Service က သေချာနားထောင်တယ်။ port:

2) Ingress တွင် parameter ဟုခေါ်သည်။ servicePort:

3) ဤသတ်မှတ်ချက် (servicePort) အမြဲတမ်း ကိုက်ညီနေရမယ်။ port ဝန်ဆောင်မှု အဓိပ္ပါယ်ဖွင့်ဆိုချက်တွင်-

4) Port 80 ကို Service တွင်သတ်မှတ်ထားပါက၊ လိုအပ်ပါသည်။ 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 controller သို့ ချိတ်ဆက်ရန် လိုအပ်သည်။

ဦးစွာ 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

Ingress pod ကိုရှာပါ (၎င်းသည် မတူညီသော namespace တွင်ရှိနိုင်သည်) နှင့် command ကို run ပါ။ describeဆိပ်ကမ်းနံပါတ်များကို သိရှိရန်-

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

နောက်ဆုံးတွင် pod သို့ ချိတ်ဆက်ပါ။

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

ယခု သင့်ကွန်ပြူတာတွင် port 3000 သို့ ပို့ရန် တောင်းဆိုမှုတိုင်းတွင် ၎င်းသည် Ingress controller ဖြင့် pod ၏ port 80 သို့ ထပ်ဆင့်ပို့မည်ဖြစ်သည်။ သွားခြင်းဖြင့် http://localhost:3000၊ အပလီကေးရှင်းမှထုတ်ပေးသောစာမျက်နှာကိုသင်တွေ့ရပါမည်။

ဆိပ်ကမ်းများ၏အကျဉ်းချုပ်

ဘယ် port နဲ့ labels တွေ ကိုက်ညီရမယ်ဆိုတာ ထပ်ပြီး မှတ်သားကြည့်ရအောင်။

1. ဝန်ဆောင်မှု အဓိပ္ပါယ်ဖွင့်ဆိုချက်ရှိ ရွေးချယ်သူသည် pod ၏တံဆိပ်နှင့် ကိုက်ညီရမည်။
2. targetPort အဓိပ္ပါယ်ဖွင့်ဆိုချက်တွင် Service နှင့် ကိုက်ညီရမည်။ containerPort အိုးအတွင်း၌ ကွန်တိန်နာ၊
3. port အဓိပ္ပါယ်ဖွင့်ဆိုချက်ထဲမှာ Service က ဘာမဆိုဖြစ်နိုင်ပါတယ်။ မတူညီသောဝန်ဆောင်မှုများသည် မတူညီသော IP လိပ်စာများရှိသောကြောင့် တူညီသောဆိပ်ကမ်းကို အသုံးပြုနိုင်သည်။
4. servicePort Ingress ကိုက်ညီရမည်။ port ဝန်ဆောင်မှု၏အဓိပ္ပါယ်၌၊
5. ဝန်ဆောင်မှုအမည်သည် အကွက်နှင့် ကိုက်ညီရမည်။ serviceName Ingress တွင်။

ကံမကောင်းစွာပဲ၊ YAML configuration ကို မှန်ကန်စွာတည်ဆောက်ပုံကို သိရန် မလုံလောက်ပါ။

အရာတွေ မှားသွားရင် ဘာဖြစ်မလဲ။

ဘူးသည် မစတင်နိုင် သို့မဟုတ် ပျက်စီးသွားနိုင်သည်။

Kubernetes ရှိ အပလီကေးရှင်းပြဿနာများကို အဖြေရှာရန် အဆင့် 3 ခု

သင်၏အသုံးပြုမှုကို အမှားရှာမစတင်မီ၊ Kubernetes အလုပ်လုပ်ပုံကို ကောင်းစွာနားလည်ရန် လိုအပ်ပါသည်။

K8s တွင် ဒေါင်းလုဒ်လုပ်ထားသော အပလီကေးရှင်းတစ်ခုစီတွင် အစိတ်အပိုင်း သုံးခုပါသောကြောင့် ၎င်းတို့ကို အောက်ခြေမှစ၍ အချို့သော အစီအစဉ်ဖြင့် အမှားရှာရပါမည်။

1. ပထမဦးစွာ pods များအလုပ်လုပ်ကြောင်းသေချာစေရန်လိုအပ်ပါတယ်, ထို့နောက် ...
2. ဝန်ဆောင်မှုသည် pods များသို့ traffic များပေးဆောင်ခြင်းရှိမရှိစစ်ဆေးပါ၊ ထို့နောက်...
3. Ingress မှန်ကန်မှုရှိမရှိ စစ်ဆေးပါ။

အမြင်ဆိုင်ရာ ကိုယ်စားပြုမှု-

1) ပြဿနာတွေကို အောက်ခြေကနေ စပြီး ရှာသင့်တယ်။ ပထမဦးစွာ pods တွင် status ရှိမရှိစစ်ဆေးပါ။ Ready и Running:

2) အစေ့များ အဆင်သင့်ဖြစ်လျှင် (Ready) ဝန်ဆောင်မှုသည် pods များကြား အသွားအလာကို ဖြန့်ဝေခြင်း ရှိ၊မရှိ ရှာဖွေသင့်သည်-

3) နောက်ဆုံးအနေနဲ့၊ ဝန်ဆောင်မှုနဲ့ Ingress တို့ရဲ့ ချိတ်ဆက်မှုကို ပိုင်းခြားစိတ်ဖြာဖို့ လိုပါတယ်။

1. အစေ့များကို ရောဂါရှာဖွေခြင်း။

ကိစ္စအများစုတွင် ပြဿနာသည် အိုးနှင့် ပတ်သက်သည်။ အစေ့များအဖြစ် စာရင်းသွင်းထားကြောင်း သေချာပါစေ။ Ready и Running. ၎င်းကို 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

အထက်ဖော်ပြပါ command output တွင်၊ နောက်ဆုံး pod ကို စာရင်းသွင်းထားသည်။ Running и Readyသို့ရာတွင်၊ ဤကိစ္စသည် အခြားနှစ်ခုအတွက် မဟုတ်ပေ။

မှားသွားတာကို ဘယ်လိုနားလည်ရမလဲ။

pods ကိုစစ်ဆေးခြင်းအတွက်အသုံးဝင်သော command လေးခုရှိသည်။

1. kubectl logs <имя pod'а> pod တစ်ခုရှိ ကွန်တိန်နာများမှ သစ်လုံးများကို ထုတ်ယူနိုင်စေသည်၊
2. kubectl describe pod <имя pod'а> pod နှင့်ဆက်စပ်သောဖြစ်ရပ်များစာရင်းကိုသင်ကြည့်ရှုနိုင်သည်;
3. kubectl get pod <имя pod'а> Kubernetes တွင် သိမ်းဆည်းထားသည့် pod တစ်ခု၏ YAML ဖွဲ့စည်းမှုပုံစံကို သင်ရရှိရန် ခွင့်ပြုသည်။
4. kubectl exec -ti <имя pod'а> bash pod ကွန်တိန်နာများထဲမှတစ်ခုတွင်အပြန်အလှန်အကျိုးသက်ရောက်သော command shell ကိုဖွင့်နိုင်သည်။

ဘယ်ဟာကို ရွေးသင့်လဲ။

အမှန်မှာ universal command မရှိပါ။ ဒါတွေကို ပေါင်းစပ်အသုံးပြုသင့်ပါတယ်။

ရိုးရိုး pod ပြဿနာများ

pod error ၏ အဓိက အမျိုးအစား နှစ်မျိုးရှိသည်- startup errors နှင့် runtime errors များ။

စတင်မှု အမှားအယွင်းများ-

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

Runtime အမှားများ-

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

အချို့သော အမှားများသည် အခြားအရာများထက် ပိုအဖြစ်များပါသည်။ ဤသည်မှာ အဖြစ်များဆုံး အမှားအချို့နှင့် ၎င်းတို့ကို မည်သို့ပြုပြင်မည်နည်း။

ImagePullBackOff

ပေါ့ဒ်ကွန်တိန်နာများထဲမှတစ်ခုအတွက် Kubernetes သည် ပုံတစ်ပုံမရရှိနိုင်သောအခါတွင် ဤအမှားဖြစ်ပေါ်ပါသည်။ ဤသည်မှာ ဤအတွက် အဖြစ်များဆုံး အကြောင်းရင်း သုံးခု ဖြစ်သည် ။

1. ပုံ၏အမည်သည် မမှန်ကန်ပါ - ဥပမာအားဖြင့် သင်သည် ၎င်းတွင် အမှားတစ်ခုပြုလုပ်ခဲ့သည် သို့မဟုတ် ပုံမရှိပါ;
2. ပုံအတွက် တည်ရှိခြင်းမရှိသော တဂ်ကို သတ်မှတ်ထားသည်။
3. ရုပ်ပုံအား သီးသန့်မှတ်ပုံတင်ခြင်းတွင် သိမ်းဆည်းထားပြီး Kubernetes သည် ၎င်းကို ဝင်ရောက်ကြည့်ရှုရန် ခွင့်ပြုချက်မရှိပါ။

ပထမအကြောင်းရင်းနှစ်ခုကို ဖယ်ရှားရန် လွယ်ကူသည် - ပုံအမည်နှင့် tag ကိုပြင်ပါ။ နောက်ဆုံးအခြေအနေတွင်၊ သင်သည် Secret တွင် ပိတ်ထားသော registry အတွက် အထောက်အထားများကို ထည့်သွင်းပြီး ၎င်းထံသို့ လင့်ခ်များကို pods တွင် ထည့်ရပါမည်။ Kubernetes စာရွက်စာတမ်းများတွင် ဥပမာတစ်ခုရှိတယ်။ ဒါကို ဘယ်လိုလုပ်ဆောင်နိုင်မလဲ။

Crash Loop Back Off

Kubenetes သည် အမှားတစ်ခုကို လွှင့်ပစ်လိုက်သည်။ CrashLoopBackOffကွန်တိန်နာမစတင်နိုင်လျှင်။ ဤအရာသည် များသောအားဖြင့် ဖြစ်ပေါ်သည့်အခါ-

1. အပလီကေးရှင်းတွင် ၎င်းကို စတင်ခြင်းမှ တားဆီးသည့် ချွတ်ယွင်းချက်တစ်ခု ရှိသည်။
2. ထည့်သောအရာ မှားယွင်းစွာ ပြင်ဆင်ထားသည်။;
3. Liveness test သည် အကြိမ်များစွာ ကျရှုံးခဲ့သည်။

၎င်း၏ပျက်ကွက်ရခြင်းအကြောင်းရင်းကို ရှာဖွေရန် ကွန်တိန်နာမှ သစ်လုံးများဆီသို့ သင်ကြိုးစားရမည်။ ကွန်တိန်နာသည် မြန်လွန်းသောကြောင့် ပြန်လည်စတင်ရန် ခက်ခဲပါက၊ သင်သည် အောက်ပါ command ကို အသုံးပြုနိုင်ပါသည်။

kubectl logs <pod-name> --previous

၎င်းသည် ကွန်တိန်နာ၏ ယခင် လူ့ဇာတိခံယူမှုမှ အမှားအယွင်း မက်ဆေ့ချ်များကို ပြသသည်။

RunContainer အမှား

ကွန်တိန်နာကို စတင်ရန် ပျက်ကွက်သည့်အခါ ဤအမှားဖြစ်ပေါ်ပါသည်။ ၎င်းသည် အပလီကေးရှင်းမစတင်မီအချိန်နှင့် ကိုက်ညီပါသည်။ မှားယွင်းသော ဆက်တင်များကြောင့် ဖြစ်တတ်သည်၊ ဥပမာ-

• ConfigMap သို့မဟုတ် Secrets ကဲ့သို့သော တည်ရှိခြင်းမရှိသော volume တစ်ခုကို တပ်ဆင်ရန် ကြိုးပမ်းနေခြင်း၊
• read-write အဖြစ် read-only volume ကို တပ်ဆင်ရန် ကြိုးစားမှု။

အသင်းသည် ထိုသို့သော အမှားများကို ပိုင်းခြားရန် သင့်လျော်ပါသည်။ kubectl describe pod <pod-name>.

Pods များသည် ဆိုင်းငံ့ထားသော အခြေအနေတွင် ရှိနေသည်။

ဖန်တီးပြီးသည်နှင့်အမျှ pod သည်အခြေအနေတွင်ကျန်ရှိသည်။ Pending.

ဘာကြောင့် ဒီလိုဖြစ်တာလဲ။

ဤသည်မှာ ဖြစ်နိုင်ချေရှိသော အကြောင်းရင်းများဖြစ်သည် (အချိန်ဇယားဆွဲသူသည် ကောင်းမွန်စွာအလုပ်လုပ်နေသည်ဟု ကျွန်တော်ထင်ပါသည်)။

1. အစုအဝေးတွင် စီမံလုပ်ဆောင်ခြင်းပါဝါနှင့် မမ်မိုရီကဲ့သို့သော အရင်းအမြစ်များ မလုံလောက်ပါ။
2. အရာဝတ္ထုကို သင့်လျော်သော namespace တွင် ထည့်သွင်းထားသည်။ ResourceQuota pod တစ်ခုဖန်တီးခြင်းသည် namespace ကိုခွဲတမ်းထက်ကျော်လွန်သွားစေလိမ့်မည်။
3. Pod ကို ဆိုင်းငံ့ထားသည်။ PersistentVolumeClaim.

ဤကိစ္စတွင်၊ ၎င်းသည် command ကိုအသုံးပြုရန်အကြံပြုသည်။ kubectl describe အပိုင်းကို စစ်ဆေးပါ။ Events:

kubectl describe pod <pod name>

ဆက်စပ်အမှားအယွင်းများရှိပါက ResourceQuotascommand ကို အသုံးပြု၍ အစုအဝေးမှတ်တမ်းများကို ကြည့်ရှုရန် အကြံပြုထားသည်။

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

ဘူးများ အဆင်သင့် မဖြစ်သေးပါ။

အကယ်၍ pod အဖြစ်စာရင်းသွင်းပါ။ Runningဒါပေမယ့် အခြေအနေမှာ မရှိပါဘူး။ Readyအဆင်သင့်စစ်ဆေးခြင်းကို ဆိုလိုသည်။ (အဆင်သင့်စစ်ဆေးခြင်း) ပျက်သွားတယ်။

ထိုသို့ဖြစ်လာသောအခါ၊ ပေါ့ဒ်သည် ဝန်ဆောင်မှုနှင့် မချိတ်ဆက်ဘဲ ၎င်းထံ အသွားအလာ စီးဆင်းခြင်းမရှိပါ။ အဆင်သင့် စစ်ဆေးမှု ချို့ယွင်းမှုသည် အပလီကေးရှင်းရှိ ပြဿနာများကြောင့် ဖြစ်သည်။ ဤကိစ္စတွင်၊ အမှားကိုရှာဖွေရန်၊ အပိုင်းကိုခွဲခြမ်းစိတ်ဖြာရန်လိုအပ်သည်။ Events command output တွင် kubectl describe.

2. ဝန်ဆောင်မှုရောဂါရှာဖွေရေး

အစေ့များအဖြစ် စာရင်းသွင်းပါက၊ Running и Readyဒါပေမယ့် အပလီကေးရှင်းကနေ တုံ့ပြန်မှုမရှိသေးဘူး၊ ဝန်ဆောင်မှုဆက်တင်တွေကို စစ်ဆေးသင့်ပါတယ်။

ဝန်ဆောင်မှုများသည် ၎င်းတို့၏ အညွှန်းများပေါ် မူတည်၍ pods များသို့ လမ်းကြောင်းပြောင်းခြင်းအတွက် တာဝန်ရှိပါသည်။ ထို့ကြောင့်၊ သင်ပထမဆုံးလုပ်ရန်လိုအပ်သည်မှာ ဝန်ဆောင်မှုနှင့် pods မည်မျှအလုပ်လုပ်သည်ကို စစ်ဆေးပါ။ ထိုသို့လုပ်ဆောင်ရန်၊ သင်သည် ဝန်ဆောင်မှုရှိ အဆုံးမှတ်များကို စစ်ဆေးနိုင်သည်-

kubectl describe service <service-name> | grep Endpoints

Endpoint သည် ပုံစံ၏ တန်ဖိုးများ တစ်စုံဖြစ်သည်။ <IP-адрес:порт>နှင့် အနည်းဆုံး ထိုစုံတွဲတစ်တွဲသည် အထွက်တွင် ရှိနေရပါမည် (ဆိုလိုသည်မှာ၊ အနည်းဆုံး ပေါ့ဒ်တစ်ခုသည် ဝန်ဆောင်မှုနှင့် အလုပ်လုပ်သည်)။

ပုဒ်မရှိရင် Endpoins ဗလာ၊ ရွေးချယ်စရာ နှစ်ခု ဖြစ်နိုင်သည်-

1. မှန်ကန်သောတံဆိပ်ပါသည့် pods များမရှိပါ (အရိပ်အမြွက်- namespace ကိုမှန်ကန်စွာရွေးချယ်ထားခြင်းရှိမရှိစစ်ဆေးပါ)။
2. ရွေးချယ်သည့်ကိရိယာရှိ ဝန်ဆောင်မှုအညွှန်းများတွင် အမှားအယွင်းရှိနေပါသည်။

အဆုံးမှတ်များစာရင်းကို သင်တွေ့မြင်သော်လည်း အပလီကေးရှင်းကို မဝင်ရောက်နိုင်သေးပါက၊ ဖြစ်နိုင်ခြေရှိသော တရားခံမှာ bug တစ်ခုဖြစ်သည်။ targetPort ဝန်ဆောင်မှုဖော်ပြချက်တွင်။

ဝန်ဆောင်မှုရဲ့ လုပ်ဆောင်နိုင်စွမ်းကို ဘယ်လိုစစ်ဆေးမလဲ။

ဝန်ဆောင်မှုအမျိုးအစား မည်သို့ပင်ရှိစေကာမူ သင်သည် command ကို အသုံးပြုနိုင်ပါသည်။ kubectl port-forward ၎င်းကိုချိတ်ဆက်ရန်-

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

ဤနေရာတွင်:

• <service-name> - ဝန်ဆောင်မှုအမည်;
• 3000 သည် ကွန်ပြူတာပေါ်တွင် သင်ဖွင့်ထားသော port ဖြစ်သည်
• 80 - ဝန်ဆောင်မှုဘက်ခြမ်းရှိဆိပ်ကမ်း။

3. Ingress ရောဂါရှာဖွေရေး

ဒီအထိဖတ်ပြီးရင်၊

• အစေ့များအဖြစ် စာရင်းသွင်းထားသည်။ Running и Ready;
• ဝန်ဆောင်မှုသည် pods များအကြား traffic ကိုအောင်မြင်စွာဖြန့်ဝေပေးသည်။

သို့သော် သင်သည် အက်ပ်ကို မရောက်ရှိနိုင်သေးပါ။

ဆိုလိုသည်မှာ Ingress controller သည် မှန်ကန်စွာ configure မပြုလုပ်နိုင်ပေ။ Ingress controller သည် အစုအဝေးရှိ ပြင်ပအစိတ်အပိုင်းတစ်ခုဖြစ်သောကြောင့်၊ ၎င်း၏အမျိုးအစားပေါ် မူတည်၍ အမှားရှာပြင်ခြင်းနည်းလမ်းများ ကွဲပြားပါသည်။

သို့သော် Ingress ကို configure လုပ်ရန် အထူးကိရိယာများကို သင်မသုံးမီ၊ သင်သည် အလွန်ရိုးရှင်းသော အရာတစ်ခုကို ပြုလုပ်နိုင်သည်။ Ingress ကိုအသုံးပြုသည်။ serviceName и servicePort ဝန်ဆောင်မှုကိုချိတ်ဆက်ရန်။ ၎င်းတို့ကို မှန်ကန်စွာ ပြင်ဆင်ထားခြင်း ရှိမရှိ စစ်ဆေးရန် လိုအပ်ပါသည်။ သင်ဤအရာကို command ကိုသုံးပြီးလုပ်ဆောင်နိုင်သည်:

kubectl describe ingress <ingress-name>

ကော်လံရှိရင် Backend ဗလာ၊ ဖွဲ့စည်းမှုဆိုင်ရာ အမှားအယွင်း ဖြစ်နိုင်ခြေ မြင့်မားသည်။ နောက်ကွယ်တွင် ရှိနေသော်လည်း အပလီကေးရှင်းကို မသုံးစွဲနိုင်သေးပါက၊ ပြဿနာသည် ဆက်စပ်နေနိုင်သည်-

• အများသူငှာ အင်တာနက်မှ ဝင်ရောက်သုံးစွဲနိုင်မှု ဆက်တင်များ။
• အများသူငှာအင်တာနက်မှ စုပြုံဝင်ရောက်နိုင်မှု ဆက်တင်များ။

Ingress pod သို့တိုက်ရိုက်ချိတ်ဆက်ခြင်းဖြင့် အခြေခံအဆောက်အအုံဆိုင်ရာ ပြဿနာများကို ဖော်ထုတ်နိုင်ပါသည်။ ၎င်းကိုလုပ်ဆောင်ရန် 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

နောက်ဆုံးတွင် pod သို့ ချိတ်ဆက်ပါ။

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

ယခု ကွန်ပြူတာပေါ်ရှိ port 3000 အတွက် တောင်းဆိုမှုအားလုံးကို pod ၏ port 80 သို့ ပြန်ညွှန်းပါမည်။

ယခု အလုပ်ဖြစ်ပါသလား။

• ဟုတ်တယ်ဆိုရင်တော့ ပြဿနာက အခြေခံအဆောက်အအုံနဲ့ ဆိုင်တယ်။ အစုအဝေးသို့ အသွားအလာမည်ကဲ့သို့ လမ်းကြောင်းပြောင်းသည်ကို အတိအကျ သိရှိရန် လိုအပ်သည်။
• မဟုတ်ပါက ပြဿနာသည် Ingress controller တွင်ဖြစ်သည်။

Ingress controller ကို အလုပ်မလုပ်နိုင်ပါက၊ ၎င်းကို debug လုပ်ရပါမည်။

Ingress Controller အမျိုးအစားများစွာရှိသည်။ လူကြိုက်အများဆုံးများမှာ Nginx၊ HAProxy၊ Traefik စသည်တို့ဖြစ်သည်။ (ရှိပြီးသားဖြေရှင်းနည်းများအကြောင်း နောက်ထပ်အချက်အလက်များအတွက် ကြည့်ပါ။ ကျွန်ုပ်တို့၏သုံးသပ်ချက် - ခန့်မှန်းခြေ ဘာသာပြန်။) သက်ဆိုင်ရာ ထိန်းချုပ်ကိရိယာစာရွက်စာတမ်းများတွင် ပြဿနာဖြေရှင်းခြင်းလမ်းညွှန်ကို ကိုးကားသင့်သည်။ အကြောင်းမှာ၊ Nginx အဝင် ရေပန်းအစားဆုံး Ingress controller ဖြစ်သည်၊ ကျွန်ုပ်တို့သည် ၎င်းနှင့်ပတ်သက်သည့် ပြဿနာများကိုဖြေရှင်းရန် ဆောင်းပါးတွင် အကြံပြုချက်အချို့ကို ထည့်သွင်းထားသည်။

Ingress Nginx ထိန်းချုပ်ကိရိယာကို အမှားရှာခြင်း။

Ingress-nginx ပရောဂျက်တွင်တရားဝင်ရှိသည်။ kubectl အတွက် ပလပ်အင်. အသင်းအဖွဲ့ kubectl ingress-nginx အသုံးပြုနိုင်ပါတယ်:

• မှတ်တမ်းများ၊ နောက်ခံများ၊ လက်မှတ်များ စသည်တို့ကို ခွဲခြမ်းစိတ်ဖြာခြင်း၊
• Ingress သို့ချိတ်ဆက်မှုများ;
• လက်ရှိ configuration ကိုလေ့လာပါ။

အောက်ပါ command သုံးခုသည် သင့်အား ဤအရာကို ကူညီပေးလိမ့်မည်-

• kubectl ingress-nginx lint - စစ်ဆေးမှုများ nginx.conf;
• kubectl ingress-nginx backend - နောက်ကွယ်မှ စူးစမ်းလေ့လာသည် (ဆင်တူသည်။ kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs - မှတ်တမ်းများကိုစစ်ဆေးပါ။

အချို့ကိစ္စများတွင် အလံကိုအသုံးပြု၍ Ingress controller အတွက် မှန်ကန်သော namespace ကို သတ်မှတ်ရန် လိုအပ်ကြောင်း သတိပြုပါ။ --namespace <name>.

အကျဉ်းချုပ်

မည်သည့်နေရာတွင် စတင်ရမည်ကို မသိပါက Kubernetes ကို ပြဿနာဖြေရှင်းခြင်းသည် စိန်ခေါ်မှုဖြစ်နိုင်သည်။ သင်သည် ပြဿနာကို အောက်ခြေမှနေ၍ အမြဲတမ်းချဉ်းကပ်သင့်သည်- pods ဖြင့် စတင်ကာ ဝန်ဆောင်မှုနှင့် Ingress သို့ ဆက်သွားပါ။ ဤဆောင်းပါးတွင်ဖော်ပြထားသည့် အမှားရှာပြင်ခြင်းနည်းပညာများကို အခြားအရာဝတ္တုများဖြစ်သည့်၊

• idle Jobs နှင့် CronJobs;
• StatefulSets နှင့် DaemonSets

ကျေးဇူးတင်ကြောင်း ဖော်ပြပါတယ်။ Gergely Risko, Daniel Weibel и Charles Christyraj တန်ဖိုးရှိသော မှတ်ချက်များနှင့် ထပ်လောင်းများအတွက်။

PS ဘာသာပြန်မှ

ကျွန်ုပ်တို့၏ဘလော့ဂ်တွင်လည်းဖတ်ပါ

• «Kubernetes pods များတွင် အမှားရှာပြင်ခြင်းအတွက် kubectl-debug ပလပ်အင်";
• «Kubernetes လည်ပတ်မှုတွင် ဖျော်ဖြေရေးစနစ် ချို့ယွင်းချက် 6 ခု [နှင့် ၎င်းတို့၏ ဖြေရှင်းချက်]";
• «Kubernetes ပေါ်တွင် လုပ်ဆောင်နေသော အပလီကေးရှင်းများ ဖန်တီးသူများ အတွက် ကိရိယာများ";
• «ကျွန်ုပ်တို့၏ SRE နေ့စဉ်ဘဝမှ လက်တွေ့ကျသော ပုံပြင် 6 ခု "။

source: www.habr.com