ಕುಬರ್ನೆಟ್ಸ್ ದೋಷನಿವಾರಣೆಗೆ ದೃಶ್ಯ ಮಾರ್ಗದರ್ಶಿ

ಸೂಚನೆ. ಅನುವಾದ.: ಈ ಲೇಖನವು ಸಾರ್ವಜನಿಕ ಡೊಮೇನ್‌ನಲ್ಲಿ ಪ್ರಕಟವಾದ ಯೋಜನಾ ಸಾಮಗ್ರಿಗಳ ಭಾಗವಾಗಿದೆ ಕಲಿಕೆ8ಗಳು, ತರಬೇತಿ ಕಂಪನಿಗಳು ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಜೊತೆ ಕೆಲಸ ಮಾಡಲು ವೈಯಕ್ತಿಕ ನಿರ್ವಾಹಕರು. ಇದರಲ್ಲಿ, ಡೇನಿಯಲ್ ಪೋಲೆನ್ಸಿಕ್, ಪ್ರಾಜೆಕ್ಟ್ ಮ್ಯಾನೇಜರ್, K8s ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಯಾವ ಕ್ರಮಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಎಂಬುದರ ಕುರಿತು ದೃಶ್ಯ ಸೂಚನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತಾರೆ.

TL;DR: ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನಿಯೋಜನೆಯನ್ನು ಡೀಬಗ್ ಮಾಡಲು ನಿಮಗೆ ಸಹಾಯ ಮಾಡುವ ರೇಖಾಚಿತ್ರ ಇಲ್ಲಿದೆ:

ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ದೋಷಗಳನ್ನು ಹುಡುಕಲು ಮತ್ತು ಸರಿಪಡಿಸಲು ಫ್ಲೋಚಾರ್ಟ್. ಮೂಲ (ಇಂಗ್ಲಿಷ್‌ನಲ್ಲಿ) ಇಲ್ಲಿ ಲಭ್ಯವಿದೆ ಪಿಡಿಎಫ್ и ಚಿತ್ರವಾಗಿ.

ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸುವಾಗ, ನೀವು ಸಾಮಾನ್ಯವಾಗಿ ಮೂರು ಘಟಕಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬೇಕಾಗಿದೆ:

• ನಿಯೋಜನೆ - ಇದು ಪಾಡ್ಸ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಅಪ್ಲಿಕೇಶನ್‌ನ ನಕಲುಗಳನ್ನು ರಚಿಸಲು ಒಂದು ರೀತಿಯ ಪಾಕವಿಧಾನವಾಗಿದೆ;
• ಸೇವೆ - ಪಾಡ್‌ಗಳ ನಡುವೆ ದಟ್ಟಣೆಯನ್ನು ವಿತರಿಸುವ ಆಂತರಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್;
• ಪ್ರವೇಶ - ಹೊರಗಿನ ಪ್ರಪಂಚದಿಂದ ಸೇವೆಗೆ ಟ್ರಾಫಿಕ್ ಹೇಗೆ ಬರುತ್ತದೆ ಎಂಬುದರ ವಿವರಣೆ.

ತ್ವರಿತ ಚಿತ್ರಾತ್ಮಕ ಸಾರಾಂಶ ಇಲ್ಲಿದೆ:

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'а> ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಪಾಡ್‌ನ 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

ಇದು ಕಂಟೇನರ್‌ನ ಹಿಂದಿನ ಅವತಾರದಿಂದ ದೋಷ ಸಂದೇಶಗಳನ್ನು ಪ್ರದರ್ಶಿಸುತ್ತದೆ.

ರನ್ ಕಂಟೈನರ್ ದೋಷ

ಕಂಟೇನರ್ ಪ್ರಾರಂಭಿಸಲು ವಿಫಲವಾದಾಗ ಈ ದೋಷ ಸಂಭವಿಸುತ್ತದೆ. ಇದು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಕ್ಷಣಕ್ಕೆ ಅನುರೂಪವಾಗಿದೆ. ಇದು ಸಾಮಾನ್ಯವಾಗಿ ತಪ್ಪಾದ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಂದ ಉಂಟಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ:

• ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್ ಅಥವಾ ಸೀಕ್ರೆಟ್ಸ್‌ನಂತಹ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಪರಿಮಾಣವನ್ನು ಆರೋಹಿಸಲು ಪ್ರಯತ್ನಿಸುವುದು;
• ಓದಲು-ಬರೆಯುವಂತೆ ಓದಲು-ಮಾತ್ರ ಪರಿಮಾಣವನ್ನು ಆರೋಹಿಸುವ ಪ್ರಯತ್ನ.

ಅಂತಹ ದೋಷಗಳನ್ನು ವಿಶ್ಲೇಷಿಸಲು ತಂಡವು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ 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

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

• «ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್‌ಗಳಲ್ಲಿ ಡೀಬಗ್ ಮಾಡಲು kubectl-debug ಪ್ಲಗಿನ್";
• «ಕುಬರ್ನೆಟ್ಸ್ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ 6 ಮನರಂಜನಾ ಸಿಸ್ಟಮ್ ದೋಷಗಳು [ಮತ್ತು ಅವುಗಳ ಪರಿಹಾರ]";
• «ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ಪರಿಕರಗಳು";
• «ನಮ್ಮ SRE ದೈನಂದಿನ ಜೀವನದಿಂದ 6 ಪ್ರಾಯೋಗಿಕ ಕಥೆಗಳು ».

ಮೂಲ: www.habr.com