अपने Kubernetes क्लस्टर में Canary Release निर्णयों को स्वचालित करें

पृष्ठभूमि

आजकल, माइक्रोसर्विसेज एक सामान्य और व्यापक रूप से उपयोग किया जाने वाला सॉफ्टवेयर आर्किटेक्चर पैटर्न बन गया है। सेवाएं ढीले ढंग से जुड़ी होती हैं और एपीआई के माध्यम से सहयोग करती हैं। माइक्रोसर्विस पैटर्न प्रत्येक एप्लिकेशन को स्वतंत्र रूप से डिप्लॉय और मेंटेन करने योग्य बनाता है, इसलिए रिलीज़ अधिक बार होती है। जैसा कि हम सभी जानते हैं, रिलीज़ जोखिम भरी होती है; आप कभी नहीं जानते कि नए संस्करण में कोई बग है या नहीं। इसीलिए लोग कैनरी रिलीज़ और ब्लू-ग्रीन डिप्लॉयमेंट जैसी रणनीतियों का उपयोग करते हैं ताकि अपने नवीनतम संस्करण को धीरे-धीरे रोल आउट कर सकें और जोखिम को कम कर सकें।

कैनरी रिलीज़ ट्रैफ़िक को लक्ष्य सेवा के दो समूहों में विभाजित करती है, स्थिर समूह और कैनरी समूह। एपीआई गेटवे, जैसे कि Apache APISIX, माइक्रोसर्विस आर्किटेक्चर को एपीआई के लिए कुशलतापूर्वक और सुरक्षित रूप से एक्सपोज़ करता है। इसमें कैनरी रिलीज़ की सुविधा होती है। आमतौर पर ट्रैफ़िक को विभाजित करने के लिए दो तरीके होते हैं: वेट-आधारित तरीका और प्रिडिकेट एक्सप्रेशन तरीका।

वेट-आधारित तरीका

उपयोगकर्ताओं को यह निर्दिष्ट करना होगा कि कैनरी समूह पर कितना ट्रैफ़िक हिट होगा। ऊपर दी गई छवि में, 95% ट्रैफ़िक स्थिर सेवा पर जाएगा जबकि अन्य 5% कैनरी सेवा पर जाएगा।

प्रिडिकेट एक्सप्रेशन तरीका

रिक्वेस्ट प्रिडिकेट एक्सप्रेशन तरीका इंगित करता है कि केवल वही ट्रैफ़िक कैनरी समूह पर हिट होगा जो निर्दिष्ट विशेषताओं के साथ फिट होता है। उदाहरण के लिए, केवल वे HTTP रिक्वेस्ट जिनमें रिक्वेस्ट हेडर X-Debug और उसका वास्तविक मान होगा, कैनरी सेवा तक पहुंचेंगे।

कैनरी रिलीज़ को स्वचालित करें

जब आप एपीआई गेटवे को एपीआई या डैशबोर्ड के माध्यम से संचालित करते हैं, तो ट्रैफ़िक अनुपात (वेट-आधारित तरीके के लिए) या प्रिडिकेट्स (प्रिडिकेट एक्सप्रेशन तरीके के लिए) को समायोजित करने में समय लगता है। आजकल, अधिक से अधिक उपयोगकर्ता अपने माइक्रोसर्विसेज को ऑर्केस्ट्रेट करने के लिए Kubernetes का उपयोग कर रहे हैं। क्या लोग नई सेवा संस्करण बनने के बाद कैनरी रिलीज़ शुरू कर सकते हैं? इस लेख में, मैं आपको दिखाऊंगा कि कैसे API7 Cloud का उपयोग करके अपने Kubernetes क्लस्टर में कैनरी रिलीज़ को स्वचालित किया जाए।

API7 Cloud क्या है

API7 Cloud एक एनी-क्लाउड, मल्टी-लोकेशन SaaS प्लेटफॉर्म है जो एपीआई को बड़े पैमाने पर डिप्लॉय, नियंत्रित, विज़ुअलाइज़ और मॉनिटर करने के लिए है। अपने एपीआई को कहीं भी चलाएं लेकिन उन्हें केवल एक जगह पर प्रबंधित करें। API7 Cloud Apache APISIX को एपीआई गेटवे के रूप में उपयोग करता है ताकि आपके एपीआई को कुशलतापूर्वक और सुरक्षित रूप से एक्सपोज़ किया जा सके।

API7 Cloud का उपयोग करने के लिए, आपको अपने इंफ्रास्ट्रक्चर पर Apache APISIX को डिप्लॉय करना होगा, जैसे कि Docker और Kubernetes। आप डिप्लॉयमेंट को आसान बनाने के लिए Cloud CLI का उपयोग कर सकते हैं।

# API7 Cloud कंसोल से एक एक्सेस टोकन कॉन्फ़िगर करें।
cloud-cli configure --token {YOUR TOKEN}

# Apache APISIX (संस्करण 2.15.1) को namespace apisix में डिप्लॉय करें, केवल एक रेप्लिका के साथ।
cloud-cli deploy kubernetes \
  --name my-apisix \
  --namespace apisix \
  --replica-count 1 \
  --apisix-image apache/apisix:2.15.1-centos

कैनरी रिलीज़ API7 Cloud की अंतर्निहित सुविधाओं में से एक है। उपयोगकर्ता या तो कंसोल के माध्यम से कैनरी रिलीज़ नियम कॉन्फ़िगर कर सकते हैं या API7 Cloud Open API को कॉल कर सकते हैं। हमारा लक्ष्य कैनरी रिलीज़ निर्णयों को स्वचालित करना है, इसलिए हम बाद वाले तरीके का उपयोग करेंगे।

परिदृश्य

मान लीजिए कि हमारे Kubernetes क्लस्टर में एक सरल error-page एप्लिकेशन है, जो हमेशा एक एरर मैसेज लौटाता है। हम संस्करण 2.0 को रोल आउट कर रहे हैं और रिलीज़ जोखिम को कम करने के लिए कैनरी रिलीज़ रणनीति का उपयोग करना चाहते हैं। इसके अलावा, हम पूरी प्रक्रिया को स्वचालित भी करना चाहते हैं। इसलिए, हम एक कैनरी रिलीज़ कंट्रोलर बनाते हैं, जो Kubernetes सेवा संसाधनों में परिवर्तनों की निगरानी करता है, फिर API7 Cloud Go SDK के माध्यम से API7 Cloud पर कैनरी रिलीज़ बनाता / संशोधित करता है। हम केवल ट्रैफ़िक को विभाजित करने के लिए वेट-आधारित तरीके का उपयोग करते हैं। सभी घटक, जिसमें Apache APISIX API गेटवे भी शामिल है, Kubernetes पर डिप्लॉय किए जाएंगे ताकि डायग्राम इस प्रकार होगा:

कैनरी रिलीज़ कंट्रोलर सेवा परिवर्तनों को देखता है और कुछ एनोटेशन के अनुसार प्रतिक्रिया करता है, विशेष रूप से:

• यदि सेवा में एनोटेशन api7.cloud / published-service होता है, तो कैनरी रिलीज़ कंट्रोलर API7 Cloud पर एक एप्लिकेशन बनाने का प्रयास करेगा।
• यदि सेवा में एनोटेशन api7.cloud / published-canary-service होता है, तो कैनरी रिलीज़ कंट्रोलर API7 Cloud पर कैनरी रिलीज़ नियम सेट अप करने का प्रयास करेगा और एनोटेशन api7.cloud/published-service-canary-percentage प्रतिशत निर्धारित करेगा।

ध्यान दें कि यह कंट्रोलर स्व-निहित नहीं है (यदि सेवा हटा दी जाती है तो यह एप्लिकेशन को हटाता नहीं है), लेकिन यह स्वचालित कैनरी रिलीज़ प्रक्रिया को दिखाने के लिए पर्याप्त है।

चलिए शुरू करते हैं!

आइए Apache APISIX और कैनरी रिलीज़ कंट्रोलर को डिप्लॉय करके शुरू करें। जैसा कि ऊपर बताया गया है, हम Apache APISIX को डिप्लॉय करने के लिए Cloud CLI का उपयोग करते हैं। हमारे पास error-page एप्लिकेशन और कैनरी रिलीज़ कंट्रोलर को डिप्लॉय करने के लिए दो YAML फाइलें (error-page/manifest-v1.yaml और controller/manifest.yaml) भी हैं।

1. कृपया एक उपलब्ध Kubernetes क्लस्टर तैयार करें यदि आप निम्नलिखित कमांड्स को निष्पादित करना चाहते हैं।
2. कैनरी रिलीज़ कंट्रोलर को API7 Cloud API को कॉल करने के लिए एक एक्सेस टोकन की आवश्यकता होती है। हम इस डॉक्यूमेंट के अनुसार एक टोकन प्राप्त करते हैं और टोकन को एक K8s सीक्रेट में स्टोर करते हैं।

kubectl create namespace canary-release-demo
# error-page v1 संस्करण को डिप्लॉय करें।
kubectl apply -f https://raw.githubusercontent.com/tokers/canary-release-automation-demo/main/error-page/manifest-v1.yaml -n canary-release-demo

# API7 Cloud एक्सेस टोकन को सहेजने के लिए एक K8s सीक्रेट बनाएं।
kubectl create secret generic api7-cloud --namespace canary-release-demo --from-literal token={Your Access Token}

# कैनरी रिलीज़ कंट्रोलर को डिप्लॉय करें।
kubectl apply -f https://raw.githubusercontent.com/tokers/canary-release-automation-demo/main/controller/manifest.yaml -n canary-release-demo

# जांचें कि सभी वर्कलोड सामान्य हैं।
kubectl get all -n canary-release-demo

प्रॉक्सी की जांच करें

आइए इस सेवा को एनोटेट करके प्रकाशित करें।

kubectl annotate service -n canary-release-demo error-page-v1 "api7.cloud/published-service=error-page"

कैनरी रिलीज़ कंट्रोलर इस परिवर्तन को देखेगा और API7 Cloud पर एक एप्लिकेशन बनाएगा। अब आइए Apache APISIX तक पहुंचें और देखें कि प्रॉक्सी सामान्य है या नहीं।

kubectl port-forward -n canary-release-demo service/apisix-gateway 10080:80
curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s

यदि सब कुछ ठीक है, तो आप {"error": "injected by error_page service", "version": "v1"} देखेंगे।

वर्तमान में, कैनरी रिलीज़ कंट्रोलर एप्लिकेशन में एक "match-everything" API बनाता है, और होस्ट एप्लिकेशन नाम (error-page) के समान होता है।

V2 को रोल आउट करें

हम error page एप्लिकेशन के लिए संस्करण 2 को रोल आउट करना चाहते हैं। पहले, हम manifest-v2.yaml को लागू करके संस्करण 2 को डिप्लॉय करते हैं। हम error-page-v2 सेवा को कैनरी रिलीज़ एनोटेशन के साथ एनोटेट करते हैं।

kubectl apply -f https://raw.githubusercontent.com/tokers/canary-release-automation-demo/main/error-page/manifest-v2.yaml -n canary-release-demo

# कैनरी रिलीज़ कंट्रोलर को बताएं कि हम error-page-v2 के लिए कैनरी रिलीज़ सक्षम कर रहे हैं, और प्रतिशत 10% है।
kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-canary-service=true" "api7.cloud/published-service-canary-percentage=10"

# कैनरी शुरू करें।
kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-service=error-page"

अब आइए Apache APISIX को 100 रिक्वेस्ट भेजें और देखें कि क्या कुछ रिक्वेस्ट कैनरी सेवा error-page-v2 तक फॉरवर्ड हुई हैं।

kubectl port-forward -n canary-release-demo service/apisix-gateway 10080:80
for ((i=0; i<100; i++)); do
  curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s
done

यदि सब कुछ ठीक है, तो केवल लगभग 10% रिक्वेस्ट error-page-v2 तक पहुंचेंगी (Apache APISIX द्वारा बैकएंड चुनने की आंतरिक रणनीति के कारण ठीक 10% नहीं)।

रोलबैक

हमने पाया कि संस्करण 2 अस्थिर है और हम इसे रोलबैक करना चाहते हैं। इससे पहले कि हम ऐसा करें, हम कैनरी को रोक देंगे, इसलिए हम प्रतिशत को 0 पर बदलते हैं। फिर Apache APISIX को फिर से रिक्वेस्ट भेजें।

kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-service-canary-percentage=0" --overwrite
for ((i=0; i<100; i++)); do
  curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s
done

आप देखेंगे कि अब सभी रिक्वेस्ट error-page-v1 पर जा रही हैं।

रिलीज़

लंबे समय के बाद, हम मानते हैं कि संस्करण 2 पर्याप्त स्थिर है, और हम चाहते हैं कि सभी रिक्वेस्ट संस्करण 2 तक पहुंचें। फिर हम संस्करण 1 error page एप्लिकेशन को ऑफ़लाइन कर सकते हैं। इसलिए हम प्रतिशत को 100% पर बदलते हैं।

kubectl annotate service -n canary-release-demo error-page-v2 "api7.cloud/published-service-canary-percentage=100" --overwrite
for ((i=0; i<100; i++)); do
  curl http://127.0.0.1:10080/api/error_page -H 'Host: error-page' -s
done

अब सभी रिक्वेस्ट error-page-v2 पर प्रॉक्सी हो रही हैं। और error-page-v1 को सुरक्षित रूप से ऑफ़लाइन किया जा सकता है।

सारांश

कैनरी रिलीज़ रिलीज़ के लिए एक प्रभावी हथियार है। हालांकि, कैनरी रिलीज़ रणनीति को ट्वीक करना हिस्टेरिक हो सकता है। यह लेख दिखाता है कि कैसे कैनरी रिलीज़ को डिक्लेरेटिव तरीके से संचालित किया जाए और कैनरी रिलीज़ को कुछ हद तक स्वचालित किया जाए। कुछ लोग GitOps घटकों की मदद से पूरी तरह से स्वचालित कैनरी रिलीज़ की तलाश कर सकते हैं। उदाहरण के लिए, Argo Rollouts का उपयोग करके, कोई स्वचालित रूप से सेवाओं को प्रमोट या रोल बैक कर सकता है। Argo Rollouts सेवा मेट्रिक्स को क्वेरी करता है और इनग्रेस कंट्रोलर्स के साथ एकीकृत करता है ताकि उनके CRDs को बदल सके। अंततः, API गेटवे कैनरी संस्करण पर सही अनुपात में रिक्वेस्ट फॉरवर्ड करेगा।

संदर्भ

error page और कैनरी रिलीज़ कंट्रोलर के लिए स्रोत कोड: https://github.com/tokers/canary-release-automation-demo।