Kubernetes #3 मा क्यानरी तैनाती: Istio

क्यानरी डिप्लोइमेन्ट सुरु गर्न र कल्पना गर्न Istio+Kiali प्रयोग गर्दै

यस श्रृंखलामा लेखहरू

1. Kubernetes #1 मा क्यानरी तैनाती: Gitlab CI
2. Kubernetes #2 मा क्यानरी तैनाती: Argo रोलआउटहरू
3. (यो लेख)
4. Jenkins-X Istio Flagger प्रयोग गरेर क्यानरी डिप्लोइमेन्ट

क्यानरी तैनाती

हामी आशा गर्छौं तपाईंले पढ्नुभयो पहिलो भाग, जहाँ हामीले क्यानरी डिप्लोइमेन्टहरू के हो भनेर संक्षिप्त रूपमा व्याख्या गऱ्यौं र मानक Kubernetes स्रोतहरू प्रयोग गरेर तिनीहरूलाई कसरी लागू गर्ने भनेर देखायौं।

इस्तिओ

र हामी मान्दछौं कि यो लेख पढेर तपाईलाई पहिले नै थाहा छ Istio के हो। यदि छैन भने, तपाईं यसको बारेमा पढ्न सक्नुहुन्छ यहाँ.

परीक्षणको लागि आवेदन

प्रत्येक पोडले दुईवटा कन्टेनरहरू समावेश गर्दछ: हाम्रो आवेदन र istio-proxy।

हामी फ्रन्टएन्ड-nginx र ब्याकएन्ड पाइथन पोडहरूको साथ एक साधारण परीक्षण अनुप्रयोग प्रयोग गर्नेछौं। nginx पोडले प्रत्येक अनुरोधलाई ब्याकएन्ड पोडमा पुन: निर्देशित गर्नेछ र प्रोक्सीको रूपमा काम गर्नेछ। विवरणहरू निम्न yamls मा पाउन सकिन्छ:

• frontend.yaml
• backend.yaml
• istio.yaml

परीक्षण आवेदन आफै चलाउँदै

यदि तपाइँ मेरो उदाहरण पछ्याउन र यो परीक्षण अनुप्रयोग आफै प्रयोग गर्न चाहनुहुन्छ भने, हेर्नुहोस् परियोजना पढ्नुहोस्.

प्रारम्भिक परिनियोजन

जब हामी पहिलो डिप्लोयमेन्ट सुरु गर्छौं, हामी देख्छौं कि हाम्रो एप्लिकेसनको पोडहरूमा केवल 2 कन्टेनरहरू छन्, त्यो हो, Istio साइडकार भर्खरै लागू भइरहेको छ:

र हामीले नेमस्पेसमा Istio गेटवे लोडब्यालेन्सर पनि देख्छौं 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 हाम्रो होस्ट फाइलमा।

Kiali मार्फत जाल हेर्नुहोस्

हामीले Tracing, Grafana, Prometheus र Kiali सँग परीक्षण एप र Istio स्थापना गर्यौं (विवरणका लागि तल हेर्नुहोस्)। परियोजना पढ्नुहोस्)। त्यसैले हामी Kiali मार्फत प्रयोग गर्न सक्छौं:

istioctl dashboard kiali # admin:admin

Kiali मेष मार्फत वर्तमान ट्राफिक कल्पना गर्दछ

हामी देख्न सक्छौं, ट्राफिकको 100% फ्रन्टएन्ड सेवामा जान्छ, त्यसपछि लेबल v1 को साथ फ्रन्टएन्ड पोडहरूमा, किनकि हामीले एक साधारण nginx प्रोक्सी प्रयोग गरिरहेका छौं जसले अनुरोधहरूलाई ब्याकएन्ड सेवामा पुन: निर्देशित गर्दछ, जसले तिनीहरूलाई ब्याकएन्ड पोडहरूमा पुन: निर्देशित गर्दछ। लेबल v1 संग।

Kiali Istio सँग राम्रो काम गर्दछ र बक्स गरिएको मेष रेन्डरिङ समाधान प्रदान गर्दछ। बस महान।

क्यानरी तैनाती

हाम्रो ब्याकइन्डमा पहिले नै दुई k8s परिनियोजनहरू छन्, एउटा v1 का लागि र अर्को v2 का लागि। अब हामीले Istio लाई 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 मा रिडिरेक्ट गरिएको छ:

क्यानरी म्यानुअल रूपमा परीक्षण गर्दै

मानौं हामी अब सबै अनुरोधहरूको १०% v2 ब्याकइन्डमा पठाउँछौं। के हुन्छ यदि हामी म्यानुअल रूपमा v10 परीक्षण गर्न चाहन्छौं कि सबै कुरा हामीले अपेक्षा गरे अनुसार काम गर्छ भनेर सुनिश्चित गर्न?

हामी 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 छ। दुबैका लागि, हामीले ट्राफिकको १०% v10 मा जानुपर्छ भनेर निर्दिष्ट गरेका छौं:

हामी त्यो फ्रन्टएन्ड 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 डिप्लोयमेन्टहरू पनि प्रयोग गरेर। त्यहाँ हामीले प्रतिकृतिहरूको संख्या परिवर्तन गरेर अनुरोधहरूको अनुपातलाई नियन्त्रण गर्यौं। यो दृष्टिकोण काम गर्दछ, तर गम्भीर कमजोरीहरू छन्।

Istio ले प्रतिकृतिहरूको संख्यालाई ध्यान नदिई अनुरोधहरूको अनुपात निर्धारण गर्न सम्भव बनाउँछ। यसको मतलब, उदाहरणका लागि, हामीले HPAs (Horizontal Pod Autoscalers) प्रयोग गर्न सक्छौं र क्यानरी डिप्लोइमेन्टको हालको अवस्था अनुसार कन्फिगर गर्न आवश्यक छैन।

परिणाम

Istio ले राम्रो काम गर्दछ र Kiali सँग सँगै प्रयोग गरेर धेरै शक्तिशाली संयोजन बनाउँछ। मेरो रुचिहरूको सूचीमा अर्को भनेको स्वचालन र क्यानरी एनालिटिक्सको लागि Istio सँग Spinnaker संयोजन गर्दैछ।

स्रोत: www.habr.com