ಕುಬರ್ನೆಟ್ಸ್ #3 ರಲ್ಲಿ ಕ್ಯಾನರಿ ನಿಯೋಜನೆ: ಇಸ್ಟಿಯೊ

ಕ್ಯಾನರಿ ನಿಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು ಮತ್ತು ದೃಶ್ಯೀಕರಿಸಲು Istio+Kiali ಅನ್ನು ಬಳಸುವುದು

ಈ ಸರಣಿಯಲ್ಲಿನ ಲೇಖನಗಳು

1. ಕುಬರ್ನೆಟ್ಸ್ #1 ರಲ್ಲಿ ಕ್ಯಾನರಿ ನಿಯೋಜನೆ: ಗಿಟ್ಲಾಬ್ CI
2. ಕುಬರ್ನೆಟ್ಸ್ #2 ರಲ್ಲಿ ಕ್ಯಾನರಿ ನಿಯೋಜನೆ: ಅರ್ಗೋ ರೋಲ್ಔಟ್ಸ್
3. (ಈ ಲೇಖನ)
4. ಜೆಂಕಿನ್ಸ್-ಎಕ್ಸ್ ಇಸ್ಟಿಯೊ ಫ್ಲ್ಯಾಗರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕ್ಯಾನರಿ ನಿಯೋಜನೆ

ಕ್ಯಾನರಿ ನಿಯೋಜನೆ

ನೀವು ಓದುತ್ತೀರಿ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ ಮೊದಲ ಭಾಗ, ಅಲ್ಲಿ ನಾವು ಕ್ಯಾನರಿ ನಿಯೋಜನೆಗಳು ಏನೆಂದು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸಿದ್ದೇವೆ ಮತ್ತು ಪ್ರಮಾಣಿತ ಕುಬರ್ನೆಟ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಬೇಕು ಎಂಬುದನ್ನು ತೋರಿಸಿದ್ದೇವೆ.

ಇಸ್ಟಿಯೊ

ಮತ್ತು ಈ ಲೇಖನವನ್ನು ಓದುವ ಮೂಲಕ ನೀವು ಈಗಾಗಲೇ ಇಸ್ಟಿಯೊ ಏನೆಂದು ತಿಳಿದಿದ್ದೀರಿ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ. ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ಅದರ ಬಗ್ಗೆ ಓದಬಹುದು ಇಲ್ಲಿ.

ಪರೀಕ್ಷೆಗಳಿಗೆ ಅರ್ಜಿ

ಪ್ರತಿ ಪಾಡ್ ಎರಡು ಕಂಟೇನರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ: ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಇಸ್ಟಿಯೊ-ಪ್ರಾಕ್ಸಿ.

ನಾವು ಮುಂಭಾಗ-ಎನ್ಜಿಎನ್ಎಕ್ಸ್ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಪೈಥಾನ್ ಪಾಡ್ಗಳೊಂದಿಗೆ ಸರಳ ಪರೀಕ್ಷಾ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. nginx ಪಾಡ್ ಪ್ರತಿ ವಿನಂತಿಯನ್ನು ಬ್ಯಾಕೆಂಡ್ ಪಾಡ್‌ಗೆ ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ ಮತ್ತು ಪ್ರಾಕ್ಸಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ವಿವರಗಳನ್ನು ಈ ಕೆಳಗಿನ ಯಾಮ್ಲ್‌ಗಳಲ್ಲಿ ಕಾಣಬಹುದು:

• ಮುಂಭಾಗ.ಯಾಮ್ಲ್
• backend.yaml
• istio.yaml

ಪರೀಕ್ಷಾ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನೀವೇ ರನ್ ಮಾಡುವುದು

ನೀವು ನನ್ನ ಉದಾಹರಣೆಯನ್ನು ಅನುಸರಿಸಲು ಮತ್ತು ಈ ಪರೀಕ್ಷಾ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನೀವೇ ಬಳಸಲು ಬಯಸಿದರೆ, ನೋಡಿ ಯೋಜನೆಯ ಓದು.

ಆರಂಭಿಕ ನಿಯೋಜನೆ

ನಾವು ಮೊದಲ ನಿಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿದಾಗ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಪಾಡ್‌ಗಳು ಕೇವಲ 2 ಕಂಟೇನರ್‌ಗಳನ್ನು ಹೊಂದಿರುವುದನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ, ಅಂದರೆ, ಇಸ್ಟಿಯೊ ಸೈಡ್‌ಕಾರ್ ಅನ್ನು ಇದೀಗ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತಿದೆ:

ಮತ್ತು ನಾವು ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಇಸ್ಟಿಯೊ ಗೇಟ್‌ವೇ ಲೋಡ್‌ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಸಹ ನೋಡುತ್ತೇವೆ istio-system:

ಸಂಚಾರ ಉತ್ಪಾದನೆ

ಮುಂಭಾಗದ ಪಾಡ್‌ಗಳಿಂದ ಸ್ವೀಕರಿಸಲ್ಪಡುವ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಪಾಡ್‌ಗಳಿಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುವ ದಟ್ಟಣೆಯನ್ನು ಉತ್ಪಾದಿಸಲು ನಾವು ಈ ಕೆಳಗಿನ IP ಅನ್ನು ಬಳಸುತ್ತೇವೆ:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

ನಾವು ಕೂಡ ಸೇರಿಸುತ್ತೇವೆ frontend.istio-test ನಮ್ಮ ಅತಿಥೇಯಗಳ ಫೈಲ್‌ಗೆ.

ಕಿಯಾಲಿ ಮೂಲಕ ಮೆಶ್ ವೀಕ್ಷಿಸಿ

ನಾವು ಟ್ರೇಸಿಂಗ್, ಗ್ರಾಫನಾ, ಪ್ರಮೀತಿಯಸ್ ಮತ್ತು ಕಿಯಾಲಿ ಜೊತೆಗೆ ಪರೀಕ್ಷಾ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಇಸ್ಟಿಯೊವನ್ನು ಸ್ಥಾಪಿಸಿದ್ದೇವೆ (ವಿವರಗಳಿಗಾಗಿ ಕೆಳಗೆ ನೋಡಿ). ಯೋಜನೆಯ ಓದು) ಆದ್ದರಿಂದ ನಾವು ಕಿಯಾಲಿಯನ್ನು ಈ ಮೂಲಕ ಬಳಸಬಹುದು:

istioctl dashboard kiali # admin:admin

ಕಿಯಾಲಿ ಮೆಶ್ ಮೂಲಕ ಪ್ರಸ್ತುತ ಸಂಚಾರವನ್ನು ದೃಶ್ಯೀಕರಿಸುತ್ತದೆ

ನಾವು ನೋಡುವಂತೆ, 100% ದಟ್ಟಣೆಯು ಮುಂಭಾಗದ ಸೇವೆಗೆ ಹೋಗುತ್ತದೆ, ನಂತರ ಲೇಬಲ್ v1 ನೊಂದಿಗೆ ಮುಂಭಾಗದ ಪಾಡ್‌ಗಳಿಗೆ ಹೋಗುತ್ತದೆ, ಏಕೆಂದರೆ ನಾವು ಸರಳವಾದ nginx ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ ಅದು ಬ್ಯಾಕೆಂಡ್ ಸೇವೆಗೆ ವಿನಂತಿಗಳನ್ನು ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ, ಅದು ಅವುಗಳನ್ನು ಬ್ಯಾಕೆಂಡ್ ಪಾಡ್‌ಗಳಿಗೆ ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ. ಲೇಬಲ್ v1 ಜೊತೆಗೆ.

ಕಿಯಾಲಿ ಇಸ್ಟಿಯೊ ಜೊತೆಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಪೆಟ್ಟಿಗೆಯ ಮೆಶ್ ರೆಂಡರಿಂಗ್ ಪರಿಹಾರವನ್ನು ಒದಗಿಸುತ್ತದೆ. ಕೇವಲ ಅದ್ಭುತವಾಗಿದೆ.

ಕ್ಯಾನರಿ ನಿಯೋಜನೆ

ನಮ್ಮ ಬ್ಯಾಕೆಂಡ್ ಈಗಾಗಲೇ ಎರಡು k8s ನಿಯೋಜನೆಗಳನ್ನು ಹೊಂದಿದೆ, ಒಂದು v1 ಮತ್ತು ಒಂದು v2 ಗೆ. ಈಗ ನಾವು ಇಸ್ಟಿಯೊಗೆ ನಿರ್ದಿಷ್ಟ ಶೇಕಡಾವಾರು ವಿನಂತಿಗಳನ್ನು v2 ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡಲು ಹೇಳಬೇಕಾಗಿದೆ.

ಹಂತ 1: 10%

ಮತ್ತು ನಾವು ಮಾಡಬೇಕಾಗಿರುವುದು ವರ್ಚುವಲ್ ಸೇವೆಯ ತೂಕವನ್ನು ಸರಿಹೊಂದಿಸುವುದು istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

10% ವಿನಂತಿಗಳನ್ನು v2 ಗೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗಿದೆ ಎಂದು ನಾವು ನೋಡುತ್ತೇವೆ.

ಹಂತ 2: 50%

ಮತ್ತು ಈಗ ಅದನ್ನು 50% ಗೆ ಹೆಚ್ಚಿಸಲು ಸಾಕು:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

ಹಂತ 3: 100%

ಈಗ ಕ್ಯಾನರಿ ನಿಯೋಜನೆಯನ್ನು ಪೂರ್ಣಗೊಳಿಸಲಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಬಹುದು ಮತ್ತು ಎಲ್ಲಾ ದಟ್ಟಣೆಯನ್ನು v2 ಗೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ:

ಕ್ಯಾನರಿಯನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪರೀಕ್ಷಿಸಲಾಗುತ್ತಿದೆ

ನಾವು ಈಗ ಎಲ್ಲಾ ವಿನಂತಿಗಳಲ್ಲಿ 2% ಅನ್ನು v10 ಬ್ಯಾಕೆಂಡ್‌ಗೆ ಕಳುಹಿಸುತ್ತೇವೆ ಎಂದು ಹೇಳೋಣ. ನಾವು ನಿರೀಕ್ಷಿಸಿದಂತೆ ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು v2 ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪರೀಕ್ಷಿಸಲು ಬಯಸಿದರೆ ಏನು ಮಾಡಬೇಕು?

HTTP ಹೆಡರ್‌ಗಳನ್ನು ಆಧರಿಸಿ ನಾವು ವಿಶೇಷ ಹೊಂದಾಣಿಕೆಯ ನಿಯಮವನ್ನು ಸೇರಿಸಬಹುದು:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

ಈಗ ಕರ್ಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಹೆಡರ್ ಕಳುಹಿಸುವ ಮೂಲಕ v2 ವಿನಂತಿಯನ್ನು ಒತ್ತಾಯಿಸಬಹುದು:

ಶಿರೋಲೇಖವಿಲ್ಲದ ವಿನಂತಿಗಳನ್ನು ಇನ್ನೂ 1/10 ಅನುಪಾತದಿಂದ ನಡೆಸಲಾಗುತ್ತದೆ:

ಎರಡು ಅವಲಂಬಿತ ಆವೃತ್ತಿಗಳಿಗೆ ಕ್ಯಾನರಿ

ಮುಂಭಾಗ ಮತ್ತು ಬ್ಯಾಕೆಂಡ್ ಎರಡಕ್ಕೂ ನಾವು ಆವೃತ್ತಿ v2 ಅನ್ನು ಹೊಂದಿರುವ ಆಯ್ಕೆಯನ್ನು ಈಗ ನಾವು ಪರಿಗಣಿಸುತ್ತೇವೆ. ಎರಡಕ್ಕೂ, 10% ದಟ್ಟಣೆಯು v2 ಗೆ ಹೋಗಬೇಕೆಂದು ನಾವು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ್ದೇವೆ:

ನಾವು ಮುಂಭಾಗದ v1 ಮತ್ತು v2 ಎರಡೂ ಫಾರ್ವರ್ಡ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು 1/10 ಬ್ಯಾಕೆಂಡ್ v1 ಮತ್ತು v2 ಅನುಪಾತದಲ್ಲಿ ನೋಡುತ್ತೇವೆ.

v2 ಗೆ ಹೊಂದಿಕೆಯಾಗದ ಕಾರಣ ನಾವು ಮುಂಭಾಗ-v2 ನಿಂದ ಬ್ಯಾಕೆಂಡ್-v1 ಗೆ ಮಾತ್ರ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡಬೇಕಾದರೆ ಏನು ಮಾಡಬೇಕು? ಇದನ್ನು ಮಾಡಲು, ನಾವು ಮುಂಭಾಗಕ್ಕೆ 1/10 ಅನುಪಾತವನ್ನು ಹೊಂದಿಸುತ್ತೇವೆ, ಇದು ಸಮಾಲೋಚನೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಬ್ಯಾಕೆಂಡ್-v2 ಗೆ ಯಾವ ದಟ್ಟಣೆಯನ್ನು ಪಡೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

ಪರಿಣಾಮವಾಗಿ, ನಮಗೆ ಬೇಕಾದುದನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ:

ಹಸ್ತಚಾಲಿತ ಕ್ಯಾನರಿ ವಿಧಾನದಿಂದ ವ್ಯತ್ಯಾಸಗಳು

В ಮೊದಲ ಭಾಗ ನಾವು ಕ್ಯಾನರಿ ನಿಯೋಜನೆಯನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿರ್ವಹಿಸಿದ್ದೇವೆ, ಎರಡು k8s ನಿಯೋಜನೆಗಳನ್ನು ಸಹ ಬಳಸುತ್ತೇವೆ. ಅಲ್ಲಿ ನಾವು ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ವಿನಂತಿಗಳ ಅನುಪಾತವನ್ನು ನಿಯಂತ್ರಿಸುತ್ತೇವೆ. ಈ ವಿಧಾನವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಗಂಭೀರ ನ್ಯೂನತೆಗಳನ್ನು ಹೊಂದಿದೆ.

ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಲೆಕ್ಕಿಸದೆ ವಿನಂತಿಗಳ ಅನುಪಾತವನ್ನು ನಿರ್ಧರಿಸಲು ಇಸ್ಟಿಯೊ ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. ಇದರರ್ಥ, ಉದಾಹರಣೆಗೆ, ನಾವು HPA ಗಳನ್ನು (ಹಾರಿಜಾಂಟಲ್ ಪಾಡ್ ಆಟೋಸ್ಕೇಲರ್‌ಗಳು) ಬಳಸಬಹುದು ಮತ್ತು ಕ್ಯಾನರಿ ನಿಯೋಜನೆಯ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಗೆ ಅನುಗುಣವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗಿಲ್ಲ.

ಫಲಿತಾಂಶ

ಇಸ್ಟಿಯೊ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಕಿಯಾಲಿಯೊಂದಿಗೆ ಇದನ್ನು ಬಳಸುವುದರಿಂದ ಅತ್ಯಂತ ಶಕ್ತಿಯುತ ಸಂಯೋಜನೆಯನ್ನು ಮಾಡುತ್ತದೆ. ನನ್ನ ಆಸಕ್ತಿಗಳ ಪಟ್ಟಿಯಲ್ಲಿ ಮುಂದಿನದು ಆಟೊಮೇಷನ್ ಮತ್ತು ಕ್ಯಾನರಿ ಅನಾಲಿಟಿಕ್ಸ್‌ಗಾಗಿ ಇಸ್ಟಿಯೊ ಜೊತೆಗೆ ಸ್ಪಿನೇಕರ್ ಅನ್ನು ಸಂಯೋಜಿಸುವುದು.

ಮೂಲ: www.habr.com