કુબરનેટ્સના મુશ્કેલીનિવારણ માટે વિઝ્યુઅલ માર્ગદર્શિકા

નૉૅધ. અનુવાદ: આ લેખ સાર્વજનિક ડોમેનમાં પ્રકાશિત પ્રોજેક્ટ સામગ્રીનો એક ભાગ છે learnk8s, તાલીમ કંપનીઓ અને વ્યક્તિગત વહીવટકર્તાઓને કુબરનેટ્સ સાથે કામ કરવા માટે. તેમાં, ડેનિયલ પોલેન્સિક, પ્રોજેક્ટ મેનેજર, K8s ક્લસ્ટર પર ચાલતી એપ્લિકેશન્સમાં સામાન્ય સમસ્યાઓના કિસ્સામાં શું પગલાં લેવા તે અંગે વિઝ્યુઅલ સૂચનાઓ શેર કરે છે.

TL;DR: અહીં એક આકૃતિ છે જે તમને કુબરનેટ્સમાં ડિપ્લોયમેન્ટ ડિબગ કરવામાં મદદ કરશે:

ક્લસ્ટરમાં ભૂલો શોધવા અને સુધારવા માટે ફ્લોચાર્ટ. મૂળ (અંગ્રેજીમાં) અહીં ઉપલબ્ધ છે પીડીએફ и ચિત્ર તરીકે.

કુબરનેટ્સ પર એપ્લિકેશન જમાવતી વખતે, ત્યાં સામાન્ય રીતે ત્રણ ઘટકો છે જેને તમારે વ્યાખ્યાયિત કરવાની જરૂર છે:

• ડિપ્લોયમેન્ટ - આ એપ્લિકેશનની નકલો બનાવવા માટેની એક પ્રકારની રેસીપી છે, જેને શીંગો કહેવાય છે;
• સેવા - આંતરિક લોડ બેલેન્સર જે શીંગો વચ્ચે ટ્રાફિકનું વિતરણ કરે છે;
• પ્રવેશ - બહારની દુનિયાથી સેવામાં ટ્રાફિક કેવી રીતે આવશે તેનું વર્ણન.

અહીં એક ઝડપી ગ્રાફિકલ સારાંશ છે:

1) કુબરનેટ્સમાં, એપ્લિકેશનો લોડ બેલેન્સર્સના બે સ્તરો દ્વારા બાહ્ય વિશ્વમાંથી ટ્રાફિક મેળવે છે: આંતરિક અને બાહ્ય.

2) આંતરિક બેલેન્સરને સર્વિસ કહેવામાં આવે છે, બાહ્યને ઇન્ગ્રેસ કહેવામાં આવે છે.

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 ક્યારે વાપરવું જોઈએ?
• શું મારે દરેક સેવા માટે નવું પોર્ટ બનાવવું જોઈએ જેથી તેઓ સંઘર્ષ ન કરે?
• શું લેબલ નામો મહત્વ ધરાવે છે? શું તેઓ દરેક જગ્યાએ સમાન હોવા જોઈએ?

ડીબગીંગ પર ધ્યાન કેન્દ્રિત કરતા પહેલા, ચાલો યાદ કરીએ કે ત્રણ ઘટકો એકબીજા સાથે કેવી રીતે સંબંધિત છે. ચાલો જમાવટ અને સેવા સાથે પ્રારંભ કરીએ.

જમાવટ અને સેવા વચ્ચેનો સંબંધ

તમને આશ્ચર્ય થશે, પરંતુ જમાવટ અને સેવા કોઈ રીતે સંબંધિત નથી. તેના બદલે, ડિપ્લોયમેન્ટને બાયપાસ કરીને, સેવા સીધા પોડ્સ તરફ નિર્દેશ કરે છે.

આમ, પોડ્સ અને સેવાઓ એકબીજા સાથે કેવી રીતે સંબંધિત છે તેમાં અમને રસ છે. યાદ રાખવા જેવી ત્રણ બાબતો:

1. પસંદગીકાર (selector) સેવા માટે ઓછામાં ઓછા એક પોડ લેબલ સાથે મેળ ખાતી હોવી જોઈએ.
2. targetPort મેળ ખાતો હોવો જોઈએ containerPort પોડની અંદર કન્ટેનર.
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?

તે હંમેશા પોડના લેબલ્સ સાથે મેળ ખાતું હોવું જોઈએ, કારણ કે તેનો ઉપયોગ પોડ્સ ટ્રૅક કરવા માટે ડિપ્લોયમેન્ટ દ્વારા થાય છે.

ચાલો ધારીએ કે તમે યોગ્ય સંપાદનો કર્યા છે. તેમને કેવી રીતે તપાસવું?

તમે નીચેના આદેશ સાથે પોડ લેબલને ચકાસી શકો છો:

kubectl get pods --show-labels

અથવા, જો શીંગો ઘણી એપ્લિકેશનોની હોય તો:

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 સેવા

જો કનેક્શન સ્થાપિત થયું હોય, તો સેટિંગ્સ સાચી છે.

જો કનેક્શન નિષ્ફળ જાય, તો લેબલ્સ સાથે સમસ્યા છે અથવા બંદરો મેળ ખાતા નથી.

સેવા અને પ્રવેશ વચ્ચેનો સંબંધ

એપ્લિકેશનની ઍક્સેસ પ્રદાન કરવાના આગળના પગલામાં ઇન્ગ્રેસ સેટ કરવાનો સમાવેશ થાય છે. ઇન્ગ્રેસને સેવા કેવી રીતે શોધવી તે જાણવાની જરૂર છે, પછી પોડ્સ શોધો અને તેમના પર સીધો ટ્રાફિક. પ્રવેશ નામ અને ઓપન પોર્ટ દ્વારા જરૂરી સેવા શોધે છે.

પ્રવેશ અને સેવાના વર્ણનમાં બે પરિમાણો મેળ ખાતા હોવા જોઈએ:

1. servicePort ઇનગ્રેશન પેરામીટર સાથે મેળ ખાતું હોવું જોઈએ port સેવા માં;
2. serviceName ઇનગ્રેસ ક્ષેત્ર સાથે મેળ ખાતી હોવી જોઈએ 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: /

પ્રવેશ ચાલી રહ્યો છે કે કેમ તે કેવી રીતે તપાસવું?

તમે સાથે પદ્ધતિનો ઉપયોગ કરી શકો છો kubectl port-forward, પરંતુ સેવાને બદલે તમારે ઇન્ગ્રેસ નિયંત્રક સાથે કનેક્ટ કરવાની જરૂર છે.

પ્રથમ તમારે ઇન્ગ્રેસ નિયંત્રક સાથે પોડનું નામ શોધવાની જરૂર છે:

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
Ports:         80/TCP, 443/TCP, 18080/TCP

છેલ્લે, પોડ સાથે કનેક્ટ કરો:

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

હવે જ્યારે પણ તમે તમારા કમ્પ્યુટર પર પોર્ટ 3000 પર વિનંતી મોકલો છો, ત્યારે તેને ઇન્ગ્રેસ કંટ્રોલર સાથે પોડના પોર્ટ 80 પર ફોરવર્ડ કરવામાં આવશે. પર જઈને http://localhost:3000, તમારે એપ્લિકેશન દ્વારા જનરેટ કરેલું પૃષ્ઠ જોવું જોઈએ.

બંદરોનો સારાંશ

ચાલો ફરી એક વાર યાદ કરીએ કે કયા પોર્ટ અને લેબલ્સ મેળ ખાતા હોવા જોઈએ:

1. સેવા વ્યાખ્યામાં પસંદગીકાર પોડના લેબલ સાથે મેળ ખાતો હોવો જોઈએ;
2. targetPort વ્યાખ્યામાં સેવા મેળ ખાતી હોવી જોઈએ containerPort પોડની અંદર કન્ટેનર;
3. port વ્યાખ્યામાં સેવા કંઈપણ હોઈ શકે છે. વિવિધ સેવાઓ સમાન પોર્ટનો ઉપયોગ કરી શકે છે કારણ કે તેમની પાસે અલગ અલગ IP સરનામાં છે;
4. servicePort પ્રવેશ મેળ ખાતો હોવો જોઈએ port સેવાની વ્યાખ્યામાં;
5. સેવાનું નામ ફીલ્ડ સાથે મેળ ખાતું હોવું જોઈએ serviceName પ્રવેશ માં.

કમનસીબે, YAML રૂપરેખાંકનને યોગ્ય રીતે કેવી રીતે બનાવવું તે જાણવું પૂરતું નથી.

જ્યારે વસ્તુઓ ખોટી થઈ જાય ત્યારે શું થાય છે?

પોડ શરૂ ન થઈ શકે અથવા તે તૂટી શકે છે.

કુબરનેટ્સમાં એપ્લિકેશન સમસ્યાઓનું નિદાન કરવા માટેના 3 પગલાં

તમે તમારા જમાવટને ડીબગ કરવાનું શરૂ કરો તે પહેલાં, તમારે કુબરનેટ્સ કેવી રીતે કાર્ય કરે છે તેની સારી સમજ હોવી જરૂરી છે.

K8s માં ડાઉનલોડ થયેલ દરેક એપ્લિકેશનમાં ત્રણ ઘટકો હોય છે, તેથી તે ખૂબ જ નીચેથી શરૂ કરીને, ચોક્કસ ક્રમમાં ડીબગ કરવા જોઈએ.

1. પ્રથમ તમારે ખાતરી કરવાની જરૂર છે કે શીંગો કામ કરી રહી છે, પછી ...
2. તપાસો કે શું સેવા પોડ્સને ટ્રાફિક સપ્લાય કરે છે, અને પછી...
3. તપાસો કે શું પ્રવેશ યોગ્ય રીતે ગોઠવાયેલ છે.

વિઝ્યુઅલ રજૂઆત:

1) તમારે ખૂબ જ નીચેથી સમસ્યાઓ શોધવાનું શરૂ કરવું જોઈએ. પહેલા ચકાસો કે શીંગો સ્ટેટસ ધરાવે છે Ready и Running:

2) જો શીંગો તૈયાર હોય (Ready), તમારે એ શોધવું જોઈએ કે શું સેવા પોડ્સ વચ્ચે ટ્રાફિકનું વિતરણ કરે છે:

3) છેલ્લે, તમારે સેવા અને પ્રવેશ વચ્ચેના જોડાણનું વિશ્લેષણ કરવાની જરૂર છે:

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જો કે, આ અન્ય બે માટે કેસ નથી.

શું ખોટું થયું તે કેવી રીતે સમજવું?

શીંગોનું નિદાન કરવા માટે ચાર ઉપયોગી આદેશો છે:

1. kubectl logs <имя pod'а> તમને પોડમાંના કન્ટેનરમાંથી લોગ કાઢવા માટે પરવાનગી આપે છે;
2. kubectl describe pod <имя pod'а> તમને પોડ સાથે સંકળાયેલ ઇવેન્ટ્સની સૂચિ જોવાની મંજૂરી આપે છે;
3. kubectl get pod <имя 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. છબી ખાનગી રજિસ્ટ્રીમાં સંગ્રહિત છે અને કુબરનેટ્સને તેને ઍક્સેસ કરવાની પરવાનગી નથી.

પ્રથમ બે કારણો દૂર કરવા સરળ છે - ફક્ત છબીનું નામ અને ટેગ સુધારો. બાદમાંના કિસ્સામાં, તમારે સિક્રેટમાં બંધ રજિસ્ટ્રી માટે ઓળખપત્રો દાખલ કરવાની અને પોડ્સમાં તેની લિંક્સ ઉમેરવાની જરૂર છે. કુબરનેટ્સ દસ્તાવેજીકરણમાં એક ઉદાહરણ છે આ કેવી રીતે કરી શકાય.

ક્રેશ લૂપ બેક ઓફ

કુબેનેટેસ ભૂલ ફેંકે છે CrashLoopBackOff, જો કન્ટેનર શરૂ ન થઈ શકે. આ સામાન્ય રીતે થાય છે જ્યારે:

1. એપ્લિકેશનમાં એક બગ છે જે તેને લોન્ચ કરવાથી અટકાવે છે;
2. કન્ટેનર ખોટી રીતે ગોઠવેલ;
3. લાઈવનેસ ટેસ્ટ ઘણી વખત ફેલ થઈ છે.

તમારે તેની નિષ્ફળતાનું કારણ શોધવા માટે કન્ટેનરમાંથી લોગ્સ પર જવાનો પ્રયાસ કરવો આવશ્યક છે. જો લોગ્સ એક્સેસ કરવું મુશ્કેલ છે કારણ કે કન્ટેનર ખૂબ ઝડપથી પુનઃપ્રારંભ થાય છે, તો તમે નીચેના આદેશનો ઉપયોગ કરી શકો છો:

kubectl logs <pod-name> --previous

તે કન્ટેનરના અગાઉના અવતારમાંથી ભૂલ સંદેશાઓ દર્શાવે છે.

RunContainerError

જ્યારે કન્ટેનર શરૂ થવામાં નિષ્ફળ જાય ત્યારે આ ભૂલ થાય છે. તે એપ્લિકેશન શરૂ થાય તે પહેલાંની ક્ષણને અનુરૂપ છે. તે સામાન્ય રીતે ખોટી સેટિંગ્સને કારણે થાય છે, ઉદાહરણ તરીકે:

• કોન્ફિગમેપ અથવા સિક્રેટ્સ જેવા અવિદ્યમાન વોલ્યુમને માઉન્ટ કરવાનો પ્રયાસ;
• ફક્ત વાંચવા માટેના વોલ્યુમને વાંચવા-લેખવા તરીકે માઉન્ટ કરવાનો પ્રયાસ.

ટીમ આવી ભૂલોનું વિશ્લેષણ કરવા માટે યોગ્ય છે kubectl describe pod <pod-name>.

શીંગો બાકી સ્થિતિમાં છે

એકવાર બનાવ્યા પછી, પોડ રાજ્યમાં રહે છે Pending.

આવું કેમ થાય છે?

અહીં સંભવિત કારણો છે (હું ધારી રહ્યો છું કે શેડ્યૂલર બરાબર કામ કરી રહ્યું છે):

1. પોડ ચલાવવા માટે ક્લસ્ટર પાસે પર્યાપ્ત સંસાધનો નથી, જેમ કે પ્રોસેસિંગ પાવર અને મેમરી.
2. ઑબ્જેક્ટ યોગ્ય નેમસ્પેસમાં ઇન્સ્ટોલ કરેલું છે ResourceQuota અને પોડ બનાવવાથી નેમસ્પેસ ક્વોટાની બહાર જશે.
3. પોડ પેન્ડિંગ માટે બંધાયેલ છે 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. સાચા લેબલ સાથે કોઈ શીંગો નથી (સંકેત: તપાસો કે નેમસ્પેસ યોગ્ય રીતે પસંદ થયેલ છે કે નહીં);
2. પસંદગીકારમાં સેવા લેબલ્સમાં ભૂલ છે.

જો તમે અંતિમ બિંદુઓની સૂચિ જુઓ છો પરંતુ તેમ છતાં એપ્લિકેશનને ઍક્સેસ કરી શકતા નથી, તો સંભવિત ગુનેગાર એક બગ છે targetPort સેવા વર્ણનમાં.

સેવાની કાર્યક્ષમતા કેવી રીતે તપાસવી?

સેવાના પ્રકારને ધ્યાનમાં લીધા વિના, તમે આદેશનો ઉપયોગ કરી શકો છો kubectl port-forward તેની સાથે જોડાવા માટે:

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

અહીં:

• <service-name> - સેવાનું નામ;
• 3000 એ પોર્ટ છે જે તમે કમ્પ્યુટર પર ખોલો છો;
• 80 - સેવા બાજુ પર પોર્ટ.

3. પ્રવેશ ડાયગ્નોસ્ટિક્સ

જો તમે આ અત્યાર સુધી વાંચ્યું છે, તો પછી:

• શીંગો તરીકે યાદી થયેલ છે Running и Ready;
• સેવા પોડ્સ વચ્ચે ટ્રાફિકનું સફળતાપૂર્વક વિતરણ કરે છે.

જો કે, તમે હજુ પણ એપ સુધી પહોંચી શકતા નથી.

આનો અર્થ એ છે કે પ્રવેશ નિયંત્રક મોટા ભાગે યોગ્ય રીતે ગોઠવાયેલ નથી. ઇન્ગ્રેસ કંટ્રોલર ક્લસ્ટરમાં તૃતીય-પક્ષ ઘટક હોવાથી, તેના પ્રકાર પર આધાર રાખીને વિવિધ ડિબગીંગ પદ્ધતિઓ છે.

પરંતુ તમે ઇન્ગ્રેસને રૂપરેખાંકિત કરવા માટે વિશેષ સાધનોનો ઉપયોગ કરો તે પહેલાં, તમે કંઈક ખૂબ જ સરળ કરી શકો છો. પ્રવેશ ઉપયોગ કરે છે serviceName и servicePort સેવા સાથે જોડાવા માટે. તમારે તપાસ કરવાની જરૂર છે કે શું તેઓ યોગ્ય રીતે ગોઠવેલ છે. તમે આદેશનો ઉપયોગ કરીને આ કરી શકો છો:

kubectl describe ingress <ingress-name>

જો કૉલમ Backend ખાલી, રૂપરેખાંકન ભૂલની ઉચ્ચ સંભાવના છે. જો બેકએન્ડ્સ સ્થાને છે, પરંતુ એપ્લિકેશન હજી પણ ઍક્સેસિબલ નથી, તો સમસ્યા આનાથી સંબંધિત હોઈ શકે છે:

• સાર્વજનિક ઈન્ટરનેટમાંથી પ્રવેશ સુલભતા સેટિંગ્સ;
• સાર્વજનિક ઇન્ટરનેટ પરથી ક્લસ્ટર ઍક્સેસિબિલિટી સેટિંગ્સ.

તમે ઇન્ગ્રેસ પોડ સાથે સીધા કનેક્ટ કરીને ઇન્ફ્રાસ્ટ્રક્ચરની સમસ્યાઓ ઓળખી શકો છો. આ કરવા માટે, પહેલા ઇન્ગ્રેસ કંટ્રોલર પોડ શોધો (તે અલગ નેમસ્પેસમાં હોઈ શકે છે):

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 પર રીડાયરેક્ટ કરવામાં આવશે.

શું તે હવે કામ કરે છે?

• જો હા, તો સમસ્યા ઈન્ફ્રાસ્ટ્રક્ચરની છે. ક્લસ્ટરમાં ટ્રાફિક કેવી રીતે રૂટ થાય છે તે શોધવાનું જરૂરી છે.
• જો નહિં, તો સમસ્યા ઇન્ગ્રેસ નિયંત્રક સાથે છે.

જો તમે ઇન્ગ્રેસ કંટ્રોલરને કામ કરવા માટે મેળવી શકતા નથી, તો તમારે તેને ડીબગ કરવું પડશે.

પ્રવેશ નિયંત્રકોની ઘણી જાતો છે. સૌથી વધુ લોકપ્રિય Nginx, HAProxy, Traefik, વગેરે છે. (હાલના ઉકેલો વિશે વધુ માહિતી માટે, જુઓ અમારી સમીક્ષા - આશરે. અનુવાદ.) તમારે સંબંધિત નિયંત્રક દસ્તાવેજીકરણમાં મુશ્કેલીનિવારણ માર્ગદર્શિકાનો સંદર્ભ લેવો જોઈએ. કારણ કે એન્ગ્રેસ Nginx સૌથી લોકપ્રિય ઇન્ગ્રેસ કંટ્રોલર છે, અમે તેને લગતી સમસ્યાઓ ઉકેલવા માટે લેખમાં કેટલીક ટીપ્સનો સમાવેશ કર્યો છે.

Ingress Nginx નિયંત્રકને ડીબગ કરી રહ્યું છે

Ingress-nginx પ્રોજેક્ટમાં એક અધિકારી છે kubectl માટે પ્લગઇન. ટીમ kubectl ingress-nginx માટે વાપરી શકાય છે:

• લોગ, બેકએન્ડ, પ્રમાણપત્રો, વગેરેનું વિશ્લેષણ;
• પ્રવેશ સાથે જોડાણો;
• વર્તમાન રૂપરેખાંકનનો અભ્યાસ.

નીચેના ત્રણ આદેશો તમને આમાં મદદ કરશે:

• kubectl ingress-nginx lint - તપાસો nginx.conf;
• kubectl ingress-nginx backend - બેકએન્ડની શોધ કરે છે (જેના જેવું kubectl describe ingress <ingress-name>);
• kubectl ingress-nginx logs - લોગ તપાસે છે.

નોંધ કરો કે કેટલાક કિસ્સાઓમાં તમારે ફ્લેગનો ઉપયોગ કરીને ઇન્ગ્રેસ કંટ્રોલર માટે યોગ્ય નેમસ્પેસનો ઉલ્લેખ કરવાની જરૂર પડી શકે છે --namespace <name>.

સારાંશ

જો તમને ક્યાંથી શરૂ કરવું તે ખબર ન હોય તો કુબરનેટ્સનું મુશ્કેલીનિવારણ કરવું પડકારરૂપ બની શકે છે. તમારે હંમેશા નીચેથી ઉપર સુધી સમસ્યાનો સંપર્ક કરવો જોઈએ: શીંગોથી પ્રારંભ કરો, અને પછી સેવા અને પ્રવેશ તરફ આગળ વધો. આ લેખમાં વર્ણવેલ ડીબગીંગ તકનીકો અન્ય વસ્તુઓ પર લાગુ કરી શકાય છે, જેમ કે:

• નિષ્ક્રિય નોકરીઓ અને ક્રોનજોબ્સ;
• સ્ટેટફુલસેટ્સ અને ડેમનસેટ્સ.

હું મારી કૃતજ્ઞતા વ્યક્ત કરું છું Gergely રિસ્કો, ડેનિયલ વેઇબેલ и ચાર્લ્સ ક્રિસ્ટીરાજ મૂલ્યવાન ટિપ્પણીઓ અને ઉમેરાઓ માટે.

અનુવાદક તરફથી પીએસ

અમારા બ્લોગ પર પણ વાંચો:

• «Kubernetes પોડ્સમાં ડિબગીંગ માટે kubectl-debug પ્લગઇન»;
• «કુબરનેટ્સના સંચાલનમાં 6 મનોરંજક સિસ્ટમ બગ્સ [અને તેમના ઉકેલ]»;
• «કુબરનેટ્સ પર ચાલતી એપ્લિકેશનના વિકાસકર્તાઓ માટેના સાધનો»;
• «અમારા SRE રોજિંદા જીવનમાંથી 6 વ્યવહારુ વાર્તાઓ ».

સોર્સ: www.habr.com