ਕੁਬਰਨੇਟਸ ਦੇ ਨਿਪਟਾਰੇ ਲਈ ਇੱਕ ਵਿਜ਼ੂਅਲ ਗਾਈਡ

ਨੋਟ ਕਰੋ। ਅਨੁਵਾਦ: ਇਹ ਲੇਖ ਜਨਤਕ ਡੋਮੇਨ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਪ੍ਰੋਜੈਕਟ ਸਮੱਗਰੀ ਦਾ ਹਿੱਸਾ ਹੈ learnk8s, ਸਿਖਲਾਈ ਕੰਪਨੀਆਂ ਅਤੇ ਵਿਅਕਤੀਗਤ ਪ੍ਰਸ਼ਾਸਕਾਂ ਨੂੰ 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ਸੇਵਾ ਲਈ ਘੱਟੋ-ਘੱਟ ਇੱਕ Pod ਲੇਬਲ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
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?

ਇਹ ਹਮੇਸ਼ਾ Pod ਦੇ ਲੇਬਲਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਡਿਪਲਾਇਮੈਂਟ ਦੁਆਰਾ ਪੌਡਾਂ ਨੂੰ ਟਰੈਕ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ ਸਹੀ ਸੰਪਾਦਨ ਕੀਤੇ ਹਨ। ਉਹਨਾਂ ਦੀ ਜਾਂਚ ਕਿਵੇਂ ਕਰੀਏ?

ਤੁਸੀਂ ਹੇਠ ਦਿੱਤੀ ਕਮਾਂਡ ਨਾਲ ਪੌਡ ਲੇਬਲ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ:

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 ਸੇਵਾ.

ਜੇ ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਸੈਟਿੰਗਾਂ ਸਹੀ ਹਨ.

ਜੇਕਰ ਕੁਨੈਕਸ਼ਨ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਲੇਬਲਾਂ ਵਿੱਚ ਕੋਈ ਸਮੱਸਿਆ ਹੈ ਜਾਂ ਪੋਰਟਾਂ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀਆਂ।

ਸੇਵਾ ਅਤੇ ਪ੍ਰਵੇਸ਼ ਵਿਚਕਾਰ ਸਬੰਧ

ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚ ਪ੍ਰਦਾਨ ਕਰਨ ਦਾ ਅਗਲਾ ਕਦਮ Ingress ਸਥਾਪਤ ਕਰਨ ਨਾਲ ਸਬੰਧਤ ਹੈ। ਪ੍ਰਵੇਸ਼ ਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੁੰਦੀ ਹੈ ਕਿ ਇੱਕ ਸੇਵਾ ਕਿਵੇਂ ਲੱਭਣੀ ਹੈ, ਫਿਰ ਪੌਡ ਲੱਭੋ ਅਤੇ ਉਹਨਾਂ 'ਤੇ ਸਿੱਧਾ ਟ੍ਰੈਫਿਕ. Ingress ਨਾਮ ਅਤੇ ਓਪਨ ਪੋਰਟ ਦੁਆਰਾ ਲੋੜੀਂਦੀ ਸੇਵਾ ਲੱਭਦੀ ਹੈ।

ਪ੍ਰਵੇਸ਼ ਅਤੇ ਸੇਵਾ ਦੇ ਵਰਣਨ ਵਿੱਚ ਦੋ ਮਾਪਦੰਡਾਂ ਦਾ ਮੇਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:

1. servicePort Ingress ਪੈਰਾਮੀਟਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ port ਸੇਵਾ ਵਿੱਚ;
2. serviceName ਦਾਖਲੇ ਵਿੱਚ ਖੇਤਰ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ 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: /

ਇਹ ਕਿਵੇਂ ਪਤਾ ਲਗਾਇਆ ਜਾਵੇ ਕਿ ਕੀ ਪ੍ਰਵੇਸ਼ ਚੱਲ ਰਿਹਾ ਹੈ?

ਨਾਲ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ kubectl port-forward, ਪਰ ਸੇਵਾ ਦੀ ਬਜਾਏ ਤੁਹਾਨੂੰ 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

ਇੰਗ੍ਰੇਸ ਪੌਡ ਲੱਭੋ (ਇਹ ਕਿਸੇ ਵੱਖਰੇ ਨੇਮਸਪੇਸ ਵਿੱਚ ਹੋ ਸਕਦਾ ਹੈ) ਅਤੇ ਕਮਾਂਡ ਚਲਾਓ 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

ਕੁਝ ਗਲਤੀਆਂ ਦੂਜਿਆਂ ਨਾਲੋਂ ਵਧੇਰੇ ਆਮ ਹਨ। ਇੱਥੇ ਕੁਝ ਸਭ ਤੋਂ ਆਮ ਗਲਤੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਠੀਕ ਕਰਨਾ ਹੈ।

ਚਿੱਤਰਪੁੱਲਬੈਕਆਫ

ਇਹ ਗਲਤੀ ਉਦੋਂ ਪ੍ਰਗਟ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕੁਬਰਨੇਟਸ ਪੌਡ ਕੰਟੇਨਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਲਈ ਇੱਕ ਚਿੱਤਰ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਹੁੰਦਾ ਹੈ। ਇੱਥੇ ਇਸਦੇ ਤਿੰਨ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹਨ:

1. ਚਿੱਤਰ ਦਾ ਨਾਮ ਗਲਤ ਹੈ - ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਇਸ ਵਿੱਚ ਗਲਤੀ ਕੀਤੀ ਹੈ, ਜਾਂ ਚਿੱਤਰ ਮੌਜੂਦ ਨਹੀਂ ਹੈ;
2. ਚਿੱਤਰ ਲਈ ਇੱਕ ਗੈਰ-ਮੌਜੂਦ ਟੈਗ ਦਿੱਤਾ ਗਿਆ ਸੀ;
3. ਚਿੱਤਰ ਨੂੰ ਇੱਕ ਨਿੱਜੀ ਰਜਿਸਟਰੀ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਕੁਬਰਨੇਟਸ ਨੂੰ ਇਸ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ।

ਪਹਿਲੇ ਦੋ ਕਾਰਨਾਂ ਨੂੰ ਖ਼ਤਮ ਕਰਨਾ ਆਸਾਨ ਹੈ - ਸਿਰਫ਼ ਚਿੱਤਰ ਦੇ ਨਾਮ ਅਤੇ ਟੈਗ ਨੂੰ ਠੀਕ ਕਰੋ। ਬਾਅਦ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਸੀਕਰੇਟ ਵਿੱਚ ਬੰਦ ਰਜਿਸਟਰੀ ਲਈ ਪ੍ਰਮਾਣ ਪੱਤਰ ਦਾਖਲ ਕਰਨ ਅਤੇ ਪੌਡ ਵਿੱਚ ਇਸ ਦੇ ਲਿੰਕ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ। ਕੁਬਰਨੇਟਸ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਇਹ ਕਿਵੇਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਕਰੈਸ਼ ਲੂਪ ਬੈਕ ਆਫ

ਕੁਬੇਨੇਟਸ ਇੱਕ ਗਲਤੀ ਸੁੱਟਦਾ ਹੈ CrashLoopBackOff, ਜੇਕਰ ਕੰਟੇਨਰ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਉਦੋਂ ਵਾਪਰਦਾ ਹੈ ਜਦੋਂ:

1. ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਇੱਕ ਬੱਗ ਹੈ ਜੋ ਇਸਨੂੰ ਲਾਂਚ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ;
2. ਕੰਟੇਨਰ ਗਲਤ ਢੰਗ ਨਾਲ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ;
3. ਲਿਵਨੇਸ ਟੈਸਟ ਵੀ ਕਈ ਵਾਰ ਫੇਲ ਹੋਇਆ ਹੈ।

ਤੁਹਾਨੂੰ ਇਸਦੀ ਅਸਫਲਤਾ ਦੇ ਕਾਰਨ ਦਾ ਪਤਾ ਲਗਾਉਣ ਲਈ ਕੰਟੇਨਰ ਤੋਂ ਲੌਗਸ ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਜੇਕਰ ਲੌਗਸ ਨੂੰ ਐਕਸੈਸ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ ਕਿਉਂਕਿ ਕੰਟੇਨਰ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਰੀਸਟਾਰਟ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਹੇਠ ਦਿੱਤੀ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ:

kubectl logs <pod-name> --previous

ਇਹ ਕੰਟੇਨਰ ਦੇ ਪਿਛਲੇ ਅਵਤਾਰ ਤੋਂ ਗਲਤੀ ਸੁਨੇਹੇ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਦਾ ਹੈ।

RunContainerError

ਇਹ ਗਲਤੀ ਉਦੋਂ ਵਾਪਰਦੀ ਹੈ ਜਦੋਂ ਕੰਟੇਨਰ ਚਾਲੂ ਹੋਣ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦਾ ਹੈ। ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਲਾਂਚ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਦੇ ਪਲ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਗਲਤ ਸੈਟਿੰਗਾਂ ਕਾਰਨ ਹੁੰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ:

• ਇੱਕ ਗੈਰ-ਮੌਜੂਦ ਵਾਲੀਅਮ ਨੂੰ ਮਾਊਂਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਾ ਜਿਵੇਂ ਕਿ ConfigMap ਜਾਂ ਸੀਕਰੇਟਸ;
• ਇੱਕ ਰੀਡ-ਓਨਲੀ ਵਾਲੀਅਮ ਨੂੰ ਰੀਡ-ਰਾਈਟ ਵਜੋਂ ਮਾਊਂਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼।

ਟੀਮ ਅਜਿਹੀਆਂ ਗਲਤੀਆਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ ਢੁਕਵੀਂ ਹੈ kubectl describe pod <pod-name>.

ਫਲੀਆਂ ਲੰਬਿਤ ਅਵਸਥਾ ਵਿੱਚ ਹਨ

ਇੱਕ ਵਾਰ ਬਣਨ ਤੋਂ ਬਾਅਦ, ਪੌਡ ਰਾਜ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ Pending.

ਅਜਿਹਾ ਕਿਉਂ ਹੁੰਦਾ ਹੈ?

ਇੱਥੇ ਸੰਭਵ ਕਾਰਨ ਹਨ (ਮੈਂ ਮੰਨ ਰਿਹਾ ਹਾਂ ਕਿ ਸ਼ਡਿਊਲਰ ਵਧੀਆ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ):

1. ਪੋਡ ਨੂੰ ਚਲਾਉਣ ਲਈ ਕਲੱਸਟਰ ਕੋਲ ਲੋੜੀਂਦੇ ਸਰੋਤ ਨਹੀਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਪ੍ਰੋਸੈਸਿੰਗ ਪਾਵਰ ਅਤੇ ਮੈਮੋਰੀ।
2. ਆਬਜੈਕਟ ਨੂੰ ਉਚਿਤ ਨੇਮਸਪੇਸ ਵਿੱਚ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਹੈ ResourceQuota ਅਤੇ ਇੱਕ ਪੌਡ ਬਣਾਉਣ ਨਾਲ ਨੇਮਸਪੇਸ ਕੋਟੇ ਤੋਂ ਪਰੇ ਹੋ ਜਾਵੇਗਾ।
3. Pod ਲੰਬਿਤ ਨਾਲ ਬੰਨ੍ਹਿਆ ਹੋਇਆ ਹੈ 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. ਦਾਖਲਾ ਨਿਦਾਨ

ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਹੁਣ ਤੱਕ ਪੜ੍ਹਿਆ ਹੈ, ਤਾਂ:

• pods ਦੇ ਤੌਰ ਤੇ ਸੂਚੀਬੱਧ ਹਨ 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 'ਤੇ ਰੀਡਾਇਰੈਕਟ ਕੀਤੀਆਂ ਜਾਣਗੀਆਂ।

ਕੀ ਇਹ ਹੁਣ ਕੰਮ ਕਰਦਾ ਹੈ?

• ਜੇਕਰ ਹਾਂ, ਤਾਂ ਸਮੱਸਿਆ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਹੈ। ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਲੱਸਟਰ ਤੱਕ ਕਿਵੇਂ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ.
• ਜੇ ਨਹੀਂ, ਤਾਂ ਸਮੱਸਿਆ ਇੰਗਰੈਸ ਕੰਟਰੋਲਰ ਨਾਲ ਹੈ.

ਜੇਕਰ ਤੁਸੀਂ Ingress ਕੰਟਰੋਲਰ ਨੂੰ ਕੰਮ ਕਰਨ ਲਈ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਡੀਬੱਗ ਕਰਨਾ ਪਵੇਗਾ।

ਇੰਗਰੈਸ ਕੰਟਰੋਲਰਾਂ ਦੀਆਂ ਕਈ ਕਿਸਮਾਂ ਹਨ। ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਸਿੱਧ ਹਨ 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 Risko, ਡੈਨੀਅਲ ਵੇਇਬਲ и ਚਾਰਲਸ ਕ੍ਰਿਸਟੀਰਾਜ ਕੀਮਤੀ ਟਿੱਪਣੀਆਂ ਅਤੇ ਜੋੜਾਂ ਲਈ।

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਕੁਬਰਨੇਟਸ ਪੌਡਸ ਵਿੱਚ ਡੀਬੱਗ ਕਰਨ ਲਈ kubectl-debug ਪਲੱਗਇਨ";
• «ਕੁਬਰਨੇਟਸ [ਅਤੇ ਉਨ੍ਹਾਂ ਦੇ ਹੱਲ] ਦੇ ਸੰਚਾਲਨ ਵਿੱਚ 6 ਮਨੋਰੰਜਕ ਸਿਸਟਮ ਬੱਗ";
• «ਕੁਬਰਨੇਟਸ 'ਤੇ ਚੱਲ ਰਹੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਡਿਵੈਲਪਰਾਂ ਲਈ ਟੂਲ";
• «ਸਾਡੇ SRE ਰੋਜ਼ਾਨਾ ਜੀਵਨ ਤੋਂ 6 ਵਿਹਾਰਕ ਕਹਾਣੀਆਂ ".

ਸਰੋਤ: www.habr.com