कुबेरनेट्स #3 में कैनरी परिनियोजन: इस्तियो

कैनरी परिनियोजन को लॉन्च और विज़ुअलाइज़ करने के लिए इस्तियो+किआली का उपयोग करना

इस शृंखला के लेख

1. कुबेरनेट्स #1 में कैनरी परिनियोजन: गिटलैब सीआई
2. कुबेरनेट्स #2 में कैनरी परिनियोजन: अर्गो रोलआउट्स
3. (यह लेख)
4. जेनकिंस-एक्स इस्तियो फ़्लैगर का उपयोग करके कैनरी परिनियोजन

कैनरी परिनियोजन

हमें आशा है कि आप पढ़ेंगे पहला भाग, जहां हमने संक्षेप में बताया कि कैनरी परिनियोजन क्या हैं और दिखाया कि मानक कुबेरनेट्स संसाधनों का उपयोग करके उन्हें कैसे लागू किया जाए।

Istio

और हम मानते हैं कि इस लेख को पढ़कर आप पहले से ही जानते हैं कि इस्तियो क्या है। अगर नहीं तो आप इसके बारे में पढ़ सकते हैं यहां.

परीक्षण के लिए आवेदन

प्रत्येक पॉड में दो कंटेनर होते हैं: हमारा एप्लिकेशन और इस्तियो-प्रॉक्सी।

हम फ्रंटएंड-एनजीएनएक्स और बैकएंड पायथन पॉड्स के साथ एक सरल परीक्षण एप्लिकेशन का उपयोग करेंगे। नेग्नेक्स पॉड प्रत्येक अनुरोध को बैकएंड पॉड पर रीडायरेक्ट करेगा और प्रॉक्सी के रूप में काम करेगा। विवरण निम्नलिखित yamls में पाया जा सकता है:

• frontend.yaml
• बैकएंड.yaml
• istio.yaml

परीक्षण एप्लिकेशन स्वयं चलाएँ

यदि आप मेरे उदाहरण का अनुसरण करना चाहते हैं और स्वयं इस परीक्षण एप्लिकेशन का उपयोग करना चाहते हैं, तो देखें प्रोजेक्ट रीडमी.

प्रारंभिक तैनाती

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

और हम नेमस्पेस में इस्तियो गेटवे लोडबैलेंसर भी देखते हैं istio-system:

यातायात सृजन

हम ट्रैफ़िक उत्पन्न करने के लिए निम्नलिखित आईपी का उपयोग करेंगे जो फ्रंटएंड पॉड्स द्वारा प्राप्त किया जाएगा और बैकएंड पॉड्स को अग्रेषित किया जाएगा:

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 के अनुपात में हैं।

क्या होगा यदि हमें ट्रैफ़िक को फ्रंटएंड-वी2 से केवल बैकएंड-वी2 पर अग्रेषित करने की आवश्यकता है क्योंकि यह वी1 के साथ संगत नहीं है? ऐसा करने के लिए, हम फ्रंटएंड के लिए 1/10 अनुपात निर्धारित करेंगे, जो यह नियंत्रित करता है कि बातचीत का उपयोग करके बैकएंड-वी2 पर कितना ट्रैफ़िक आता है। 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 परिनियोजन का भी उपयोग किया। वहां हमने प्रतिकृतियों की संख्या को बदलकर अनुरोधों के अनुपात को नियंत्रित किया। यह दृष्टिकोण काम करता है, लेकिन इसमें गंभीर कमियां हैं।

इस्तियो प्रतिकृतियों की संख्या की परवाह किए बिना अनुरोधों का अनुपात निर्धारित करना संभव बनाता है। इसका मतलब है, उदाहरण के लिए, कि हम एचपीए (क्षैतिज पॉड ऑटोस्केलर्स) का उपयोग कर सकते हैं और कैनरी परिनियोजन की वर्तमान स्थिति के अनुसार कॉन्फ़िगर करने की आवश्यकता नहीं है।

संपूर्ण

इस्तियो बढ़िया काम करता है और किआली के साथ इसका उपयोग करने से एक बहुत शक्तिशाली संयोजन बनता है। मेरी रुचियों की सूची में अगला स्वचालन और कैनरी एनालिटिक्स के लिए स्पिनंकर को इस्तियो के साथ जोड़ना है।

स्रोत: www.habr.com