కుబెర్నెట్స్ ట్రబుల్షూటింగ్కు ఒక విజువల్ గైడ్

గమనిక. అనువాదం.: ఈ కథనం పబ్లిక్ డొమైన్‌లో ప్రచురించబడిన ప్రాజెక్ట్ మెటీరియల్‌లో భాగం నేర్చుకోండి8లు, శిక్షణ సంస్థలు మరియు వ్యక్తిగత నిర్వాహకులు Kubernetes పని. ఇందులో, K8s క్లస్టర్‌లో రన్ అయ్యే అప్లికేషన్‌లతో సాధారణ సమస్యల విషయంలో ఎలాంటి చర్యలు తీసుకోవాలనే దానిపై ప్రాజెక్ట్ మేనేజర్ డేనియల్ పోలెన్సిక్ దృశ్య సూచనలను పంచుకున్నారు.

TL;DR: ఇక్కడ మీరు కుబెర్నెట్స్‌లో డీబగ్ డిప్లాయ్‌మెంట్‌లో సహాయపడే రేఖాచిత్రం ఉంది:

క్లస్టర్‌లో లోపాలను కనుగొని పరిష్కరించడానికి ఫ్లోచార్ట్. అసలు (ఆంగ్లంలో) అందుబాటులో ఉంది PDF и చిత్రంగా.

Kubernetesకి అప్లికేషన్‌ను అమలు చేస్తున్నప్పుడు, మీరు నిర్వచించాల్సిన మూడు భాగాలు సాధారణంగా ఉన్నాయి:

• విస్తరణ - ఇది పాడ్స్ అని పిలువబడే అప్లికేషన్ యొక్క కాపీలను రూపొందించడానికి ఒక రకమైన రెసిపీ;
• సర్వీస్ - పాడ్‌ల మధ్య ట్రాఫిక్‌ను పంపిణీ చేసే అంతర్గత లోడ్ బ్యాలెన్సర్;
• లోపల ప్రవేశించుట — బయటి ప్రపంచం నుండి సర్వీస్‌కి ట్రాఫిక్ ఎలా వస్తుంది అనే వివరణ.

ఇక్కడ శీఘ్ర గ్రాఫికల్ సారాంశం ఉంది:

1) కుబెర్నెటీస్‌లో, అప్లికేషన్‌లు రెండు లేయర్‌ల లోడ్ బ్యాలెన్సర్‌ల ద్వారా బాహ్య ప్రపంచం నుండి ట్రాఫిక్‌ను అందుకుంటాయి: అంతర్గత మరియు బాహ్య.

2) ఇంటర్నల్ బ్యాలెన్సర్‌ని సర్వీస్ అంటారు, బయటి బ్యాలెన్సర్‌ని ఇన్‌గ్రెస్ అంటారు.

3) విస్తరణ పాడ్‌లను సృష్టిస్తుంది మరియు వాటిని పర్యవేక్షిస్తుంది (అవి మానవీయంగా సృష్టించబడవు).

మీరు ఒక సాధారణ అప్లికేషన్ ఒక లా అమలు చేయాలని అనుకుందాం హలో వరల్డ్. దాని కోసం 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'а> Kubernetesలో నిల్వ చేయబడిన పాడ్ యొక్క YAML కాన్ఫిగరేషన్‌ను పొందడానికి మిమ్మల్ని అనుమతిస్తుంది;
4. kubectl exec -ti <имя pod'а> bash పాడ్ కంటైనర్‌లలో ఒకదానిలో ఇంటరాక్టివ్ కమాండ్ షెల్‌ను ప్రారంభించేందుకు మిమ్మల్ని అనుమతిస్తుంది

మీరు ఏది ఎంచుకోవాలి?

వాస్తవం ఏమిటంటే సార్వత్రిక ఆదేశం లేదు. వీటి కలయికను ఉపయోగించాలి.

సాధారణ పాడ్ సమస్యలు

పాడ్ ఎర్రర్‌లలో రెండు ప్రధాన రకాలు ఉన్నాయి: ప్రారంభ లోపాలు మరియు రన్‌టైమ్ లోపాలు.

ప్రారంభ లోపాలు:

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

రన్‌టైమ్ లోపాలు:

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

కొన్ని లోపాలు ఇతరులకన్నా సర్వసాధారణం. అత్యంత సాధారణ లోపాలు మరియు వాటిని ఎలా పరిష్కరించాలో ఇక్కడ ఉన్నాయి.

ImagePullBackOff

Kubernetes పాడ్ కంటైనర్‌లలో ఒకదాని కోసం చిత్రాన్ని పొందలేనప్పుడు ఈ లోపం సంభవిస్తుంది. దీనికి మూడు అత్యంత సాధారణ కారణాలు ఇక్కడ ఉన్నాయి:

1. చిత్రం పేరు తప్పు - ఉదాహరణకు, మీరు దానిలో పొరపాటు చేసారు లేదా చిత్రం ఉనికిలో లేదు;
2. చిత్రం కోసం ఉనికిలో లేని ట్యాగ్ పేర్కొనబడింది;
3. చిత్రం ప్రైవేట్ రిజిస్ట్రీలో నిల్వ చేయబడింది మరియు దానిని యాక్సెస్ చేయడానికి Kubernetesకి అనుమతి లేదు.

మొదటి రెండు కారణాలను తొలగించడం సులభం - చిత్రం పేరు మరియు ట్యాగ్‌ని సరిచేయండి. తరువాతి విషయంలో, మీరు సీక్రెట్‌లో క్లోజ్డ్ రిజిస్ట్రీ కోసం ఆధారాలను నమోదు చేయాలి మరియు దానికి లింక్‌లను పాడ్‌లలో జోడించాలి. కుబెర్నెట్స్ డాక్యుమెంటేషన్‌లో ఒక ఉదాహరణ ఉంది ఇది ఎలా చేయవచ్చు.

క్రాష్ లూప్ బ్యాక్ ఆఫ్

కుబెనెటెస్ ఒక లోపాన్ని విసిరాడు 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>.

సారాంశం

ఎక్కడ ప్రారంభించాలో మీకు తెలియకుంటే కుబెర్నెట్‌లను పరిష్కరించడం సవాలుగా ఉంటుంది. మీరు ఎల్లప్పుడూ దిగువ నుండి సమస్యను సంప్రదించాలి: పాడ్‌లతో ప్రారంభించండి, ఆపై సేవ మరియు ప్రవేశానికి వెళ్లండి. ఈ కథనంలో వివరించిన డీబగ్గింగ్ పద్ధతులు ఇతర వస్తువులకు వర్తించవచ్చు, అవి:

• నిష్క్రియ ఉద్యోగాలు మరియు క్రాన్ జాబ్స్;
• స్టేట్‌ఫుల్‌సెట్‌లు మరియు డెమోన్‌సెట్‌లు.

నా కృతజ్ఞతలు తెలియజేస్తున్నాను గెర్గెలీ రిస్కో, డేనియల్ వీబెల్ и చార్లెస్ క్రిస్టీరాజ్ విలువైన వ్యాఖ్యలు మరియు చేర్పుల కోసం.

అనువాదకుని నుండి PS

మా బ్లాగులో కూడా చదవండి:

• «Kubernetes పాడ్‌లలో డీబగ్గింగ్ కోసం kubectl-debug ప్లగ్ఇన్";
• «కుబెర్నెటీస్ ఆపరేషన్‌లో 6 వినోదాత్మక సిస్టమ్ బగ్‌లు [మరియు వాటి పరిష్కారం]";
• «కుబెర్నెట్స్‌లో నడుస్తున్న అప్లికేషన్‌ల డెవలపర్‌ల కోసం సాధనాలు";
• «మా SRE రోజువారీ జీవితంలో 6 ఆచరణాత్మక కథనాలు ".

మూలం: www.habr.com