क्लस्टर के बीच वर्कलोड को "बर्स्ट" करने के लिए, Istio के मल्टीक्लस्टर का इस्तेमाल करना

1. आपका स्वागत है

Google के Istio Multi Cloud Burst कोडलैब में शामिल होने के लिए धन्यवाद.इस कोडलैब में, Kubernetes, Node, और Go के बारे में शुरुआती लेवल का अनुभव होना ज़रूरी है.

आपको इन चीज़ों की ज़रूरत होगी

  • Google Cloud Platform खाता (मौजूदा खाते का इस्तेमाल करें या हम आपको मुफ़्त खाते देंगे)
  • आपके पास लैपटॉप हो, जिसमें "kubectl", "gcloud" वगैरह इंस्टॉल हो या फिर Google Cloud Shell का इस्तेमाल किया जा सकता है.

आपको क्या सीखने को मिलेगा

  • GKE पर Kubernetes क्लस्टर बनाने का तरीका
  • Helm की मदद से, Kubernetes क्लस्टर पर Istio इंस्टॉल करने का तरीका
  • Helm की मदद से, Istio Multicluster इंस्टॉल करने का तरीका
  • किसी वेब ऐप्लिकेशन को सोर्स से Kubernetes पर डिप्लॉय करना
  • Istio में ट्रैफ़िक रूटिंग के नियम लिखना और लागू करना
  • Prometheus मेट्रिक
  • Kubernetes क्लस्टर में कंटेनर इमेज बनाना और उन्हें पुश करना

2. सेट अप करना

इस कोडलैब को इनमें से किसी एक पर फ़ॉलो किया जा सकता है:

  • Google Cloud Shell (इसका सुझाव दिया जाता है): यह ब्राउज़र में काम करने वाला शेल है. इसमें टूल पहले से इंस्टॉल होते हैं
  • अपने लैपटॉप पर (नीचे दिए गए निर्देशों का पालन करें)

Google Cloud Platform का इस्तेमाल शुरू करना

  1. अगर आपके पास GCP खाता नहीं है, तो ट्रेनर से अपना मुफ़्त उपयोगकर्ता खाता कार्ड लें.
  2. Google Cloud Console पर जाएं और "कोई प्रोजेक्ट चुनें" पर क्लिक करें: 5c2d9bf74c78f7e4.png
  3. प्रोजेक्ट के "आईडी" को कहीं नोट कर लें. इसके बाद, उसे चुनने के लिए प्रोजेक्ट पर क्लिक करें: ecc5e8e97bfa6559.png

Cloud Shell, आपके ब्राउज़र में कमांड-लाइन शेल उपलब्ध कराता है. इसमें वे टूल पहले से इंस्टॉल होते हैं जिनकी आपको ज़रूरत होती है. साथ ही, यह आपके Google Cloud Platform खाते की पुष्टि अपने-आप करता है. (अगर आपको Cloud Shell पर यह एक्सरसाइज़ नहीं करनी है, तो अगले सेक्शन पर जाएं.)

Cloud Console पर जाएं और सबसे ऊपर दाएं टूलबार में, "Cloud Shell चालू करें" पर क्लिक करें:

68a17b036ce24ccb.png

Cloud Shell में टूल जोड़ना

  1. इंस्टॉल करें kubectx****: bash स्क्रिप्ट को यहां से डाउनलोड करके, $PATH में किसी जगह पर सेव करें.
  2. इंस्टॉल करें helm****: इन निर्देशों का पालन करें.

इसके अलावा, ~/.bin में दोनों को इंस्टॉल करने और उसे अपने $PATH में जोड़ने के लिए, ये कमांड चलाएं:

mkdir -p ~/.bin && \
cd ~/.bin && \
curl -LO https://raw.githubusercontent.com/ahmetb/kubectx/master/kubectx && \
chmod +x kubectx && \
curl -LO https://raw.githubusercontent.com/ahmetb/kubectx/master/kubens && \
chmod +x kubens && \
curl -LO  https://storage.googleapis.com/kubernetes-helm/helm-v2.12.0-linux-amd64.tar.gz && \
tar xzf helm-v2.12.0-linux-amd64.tar.gz && \
rm helm-v2.12.0-linux-amd64.tar.gz && \
mv linux-amd64/helm ./helm && \
rm -r linux-amd64 && \
export PATH=${HOME}/.bin:${PATH}

Cloud Shell का इस्तेमाल आसान बनाने के लिए, यहां कुछ सलाह दी गई हैं:

1. शेल को नई विंडो में अलग करें:

2. फ़ाइल एडिटर का इस्तेमाल करना: ब्राउज़र में फ़ाइल एडिटर लॉन्च करने के लिए, सबसे ऊपर दाईं ओर मौजूद पेंसिल आइकॉन पर क्लिक करें. यह सुविधा आपके लिए काम की होगी, क्योंकि हम कोड स्निपेट को फ़ाइलों में कॉपी करेंगे.

3. नए टैब खोलें: अगर आपको एक से ज़्यादा टर्मिनल प्रॉम्प्ट चाहिए.

4. टेक्स्ट को बड़ा करना: Cloud Shell पर डिफ़ॉल्ट फ़ॉन्ट साइज़, पढ़ने के लिए बहुत छोटा हो सकता है.

Linux/Windows पर Ctrl-+ और macOS पर ⌘-+.

अगर आपको Cloud Shell के बजाय अपने वर्कस्टेशन एनवायरमेंट का इस्तेमाल करना ज़्यादा पसंद है, तो नीचे दिए गए टूल सेट अप करें:

  1. इंस्टॉल करें gcloud: (Cloud Shell पर पहले से इंस्टॉल है.) अपने प्लैटफ़ॉर्म पर gcloud इंस्टॉल करने के लिए, निर्देशों का पालन करें. हम इसका इस्तेमाल Kubernetes क्लस्टर बनाने के लिए करेंगे.
  2. इंस्टॉल करें kubectl:(Cloud Shell पर पहले से इंस्टॉल है.) इंस्टॉल करने के लिए, यह कमांड चलाएं:
gcloud components install kubectl

gcloud की पुष्टि करने के लिए, यह कमांड चलाएं. इसके बाद, आपसे अपने Google खाते से लॉग इन करने के लिए कहा जाएगा. इसके बाद, पहले से बनाए गए प्रोजेक्ट (ऊपर देखा गया) को डिफ़ॉल्ट प्रोजेक्ट के तौर पर चुनें. (कंप्यूट ज़ोन को कॉन्फ़िगर करने की प्रक्रिया को छोड़ा जा सकता है):

gcloud init
  1. इंस्टॉल करें curl: ज़्यादातर Linux/macOS सिस्टम पर पहले से इंस्टॉल होता है. आपके पास शायद पहले से ही यह सुविधा हो. इसके अलावा, इसे इंस्टॉल करने का तरीका जानने के लिए, इंटरनेट पर खोजें.
  2. इंस्टॉल करें kubectx****: यहां से bash स्क्रिप्ट डाउनलोड करके, उन्हें $PATH में किसी जगह पर सेव करें
  3. इंस्टॉल करें helm****: इन निर्देशों का पालन करें.

3. GCP प्रोजेक्ट सेट अप करना

अपने प्रोजेक्ट पर GKE (Google Kubernetes Engine), GCR (Google Container Registry), और GCB (Google Cloud Build) एपीआई चालू करें:

gcloud services enable \
  cloudapis.googleapis.com \
  container.googleapis.com \
  containerregistry.googleapis.com \
  cloudbuild.googleapis.com

एनवायरमेंट वैरिएबल सेट अप करना

सेटअप के दौरान, हम अपने Google Cloud प्रोजेक्ट के साथ ज़्यादा काम करेंगे. इसलिए, तुरंत रेफ़रंस के लिए एक एनवायरमेंट वैरिएबल सेट करें

export GCLOUD_PROJECT=$(gcloud config get-value project)

इस वर्कशॉप के दौरान, हम कुछ कोड और कॉन्फ़िगरेशन फ़ाइलें बनाएंगे. इसलिए, एक प्रोजेक्ट डायरेक्ट्री बनाएं और उसमें जाएं

mkdir -p src/istio-burst && \
cd src/istio-burst && \
export proj=$(pwd)

4. "प्राइमरी" Kubernetes क्लस्टर बनाना

Google Kubernetes Engine (GKE) की मदद से, मैनेज किया जा सकने वाला Kubernetes क्लस्टर आसानी से बनाया जा सकता है.

यह कमांड, Kubernetes क्लस्टर बना देगा:

  • "primary" नाम दिया गया हो,
  • us-west1-a ज़ोन में,
  • Kubernetes का सबसे नया वर्शन उपलब्ध हो,
  • चार शुरुआती नोड के साथ
export cluster=primary

export zone=us-west1-a

gcloud container clusters create $cluster --zone $zone --username "admin" \
--cluster-version latest --machine-type "n1-standard-2" \
--image-type "COS" --disk-size "100" \
--scopes "https://www.googleapis.com/auth/compute",\
"https://www.googleapis.com/auth/devstorage.read_only",\
"https://www.googleapis.com/auth/logging.write",\
"https://www.googleapis.com/auth/monitoring",\
"https://www.googleapis.com/auth/servicecontrol",\
"https://www.googleapis.com/auth/service.management.readonly",\
"https://www.googleapis.com/auth/trace.append" \
--num-nodes "4" --network "default" \
--enable-cloud-logging --enable-cloud-monitoring --enable-ip-alias

(इसमें करीब पांच मिनट लग सकते हैं. Cloud Console में जाकर, क्लस्टर बनने की प्रोसेस देखी जा सकती है.)

Kubernetes क्लस्टर बन जाने के बाद, gcloud क्लस्टर पर ले जाने वाले क्रेडेंशियल की मदद से kubectl को कॉन्फ़िगर करता है.

gcloud container clusters get-credentials $cluster --zone=$zone

अब आपको अपने नए क्लस्टर के साथ kubectl का इस्तेमाल करने में कोई समस्या नहीं होगी.

अपने क्लस्टर के Kubernetes नोड की सूची देखने के लिए, यह कमांड चलाएं. इससे, आपको "तैयार है" स्टेटस दिखेगा:

kubectl get nodes

Kubeconfig के नामों में बदलाव करना, ताकि उन्हें आसानी से इस्तेमाल किया जा सके

हम एक से दूसरे कॉन्टेक्स्ट के बीच बार-बार स्विच करेंगे. इसलिए, हमारे क्लस्टर के लिए कोई छोटा उपनाम होना ज़रूरी है.

इस कमांड से, आपने जो kubeconfig एंट्री अभी-अभी बनाई है उसका नाम बदलकर primary हो जाएगा

kubectx ${cluster}=gke_${GCLOUD_PROJECT}_${zone}_${cluster}

अनुमतियां सेट करना:

Istio को डिप्लॉय करने के लिए, आपके पास क्लस्टर एडमिन की भूमिका होनी चाहिए. यह कमांड, आपके Google Cloud खाते से जुड़े ईमेल पते को क्लस्टर एडमिन के तौर पर सेट करेगा

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole=cluster-admin \
    --user=$(gcloud config get-value core/account)

5. "बर्स्ट" क्लस्टर बनाना

यह कमांड, Kubernetes क्लस्टर बना देगा:

  • "burst" नाम का
  • us-west1-a ज़ोन में,
  • Kubernetes का सबसे नया वर्शन उपलब्ध हो,
  • एक शुरुआती नोड के साथ
  • ज़्यादा से ज़्यादा पांच नोड के लिए ऑटोस्केलिंग की सुविधा चालू हो
export cluster=burst

export zone=us-west1-a

gcloud container clusters create $cluster --zone $zone --username "admin" \
--cluster-version latest --machine-type "n1-standard-2" \
--image-type "COS" --disk-size "100" \
--scopes "https://www.googleapis.com/auth/compute",\
"https://www.googleapis.com/auth/devstorage.read_only",\
"https://www.googleapis.com/auth/logging.write",\
"https://www.googleapis.com/auth/monitoring",\
"https://www.googleapis.com/auth/servicecontrol",\
"https://www.googleapis.com/auth/service.management.readonly",\
"https://www.googleapis.com/auth/trace.append" \
--num-nodes "1" --enable-autoscaling --min-nodes=1 --max-nodes=5 \
--network "default" \
--enable-cloud-logging --enable-cloud-monitoring --enable-ip-alias

(इसमें करीब पांच मिनट लग सकते हैं. Cloud Console में जाकर, क्लस्टर बनने की प्रोसेस देखी जा सकती है.)

Kubernetes क्लस्टर बन जाने के बाद, gcloud क्लस्टर पर ले जाने वाले क्रेडेंशियल की मदद से kubectl को कॉन्फ़िगर करता है.

gcloud container clusters get-credentials $cluster --zone=$zone

अब आपको अपने नए क्लस्टर के साथ kubectl का इस्तेमाल करने में कोई समस्या नहीं होगी.

अपने क्लस्टर के Kubernetes नोड की सूची देखने के लिए, यह कमांड चलाएं. इससे, आपको "तैयार है" स्टेटस दिखेगा:

kubectl get nodes

Kubeconfig के नामों में बदलाव करना, ताकि उन्हें आसानी से इस्तेमाल किया जा सके

यह कमांड, आपके हाल ही में बनाए गए kubeconfig एंट्री को burst में बदल देगा

kubectx ${cluster}=gke_${GCLOUD_PROJECT}_${zone}_${cluster}

अनुमतियां सेट करना:

Istio Remote को डिप्लॉय करने के लिए, आपके पास क्लस्टर एडमिन की भूमिका होनी चाहिए. यह कमांड, आपके Google Cloud खाते से जुड़े ईमेल पते को क्लस्टर एडमिन के तौर पर सेट करेगा

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole=cluster-admin \
    --user=$(gcloud config get-value core/account)

6. फ़ायरवॉल के नियम लागू करना

हमारे दोनों क्लस्टर एक-दूसरे से कम्यूनिकेट कर सकें, इसके लिए हमें फ़ायरवॉल नियम बनाना होगा.

Google Cloud Platform में फ़ायरवॉल नियम बनाने के लिए, नीचे दिए गए निर्देशों का पालन करें. इससे हमारे क्लस्टर, एक-दूसरे से कम्यूनिकेट कर पाएंगे

function join_by { local IFS="$1"; shift; echo "$*"; }

ALL_CLUSTER_CIDRS=$(gcloud container clusters list \
--filter="(name=burst OR name=primary) AND zone=$zone" \
--format='value(clusterIpv4Cidr)' | sort | uniq)

ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))

ALL_CLUSTER_NETTAGS=$(gcloud compute instances list \
--filter="(metadata.cluster-name=burst OR metadata.cluster-name=primary) AND metadata.cluster-location=us-west1-a" \
--format='value(tags.items.[0])' | sort | uniq)

ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))

gcloud compute firewall-rules create istio-multicluster-test-pods \
  --allow=tcp,udp,icmp,esp,ah,sctp \
  --direction=INGRESS \
  --priority=900 \
  --source-ranges="${ALL_CLUSTER_CIDRS}" \
  --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet

हमारे दोनों क्लस्टर सेट अप हो चुके हैं और उन पर ऐप्लिकेशन और Istio को डिप्लॉय करने के लिए तैयार हैं!

7. Istio के बारे में जानकारी

Istio क्या है?

Istio, सेवा मेश कंट्रोल प्लेन है. इसका मकसद "सेवाओं को कनेक्ट करना, सुरक्षित करना, कंट्रोल करना, और निगरानी करना" है. यह कई तरीकों से ऐसा करता है. हालांकि, मुख्य रूप से यह आपके डिप्लॉय किए गए हर Kubernetes पॉड में, किसी प्रॉक्सी कंटेनर ( Envoy) को साइडकार के तौर पर जोड़ता है. प्रॉक्सी कंटेनर, सामान्य नीति और टेलीमेट्री हब ( Mixer) के साथ मिलकर, माइक्रोसर्विस के बीच के सभी नेटवर्क कम्यूनिकेशन को कंट्रोल करता है.

a25613cd581825da.png

ये नीतियां, Kubernetes के डिप्लॉयमेंट और सेवाओं से अलग से लागू की जा सकती हैं. इसका मतलब है कि नेटवर्क ऑपरेटर, नेटवर्क गतिविधि को मॉनिटर कर सकता है, उस पर पाबंदी लगा सकता है, उसे रीडायरेक्ट कर सकता है या उससे जुड़े ऐप्लिकेशन को फिर से डिप्लॉय किए बिना नेटवर्क नीतियों को फिर से लिख सकता है.

ट्रैफ़िक मैनेजमेंट की कुछ सुविधाएं, Istio के साथ काम करती हैं. जैसे:

  • सर्किट ब्रेकर
  • प्रतिशत के आधार पर ट्रैफ़िक का बंटवारा
  • यूआरएल को फिर से लिखना
  • TLS टर्मिनेशन
  • कैंपेन की परफ़ॉर्मेंस की जांच
  • लोड बैलेंसिंग

इस वर्कशॉप में, हम प्रतिशत के आधार पर ट्रैफ़िक के बंटवारे पर फ़ोकस करेंगे.

Istio की वे शर्तें जिनके साथ हम काम करेंगे

VirtualService

VirtualService, ट्रैफ़िक को रूट करने के नियमों का एक सेट तय करता है. ये नियम, होस्ट के पते का इस्तेमाल करने पर लागू होते हैं.

गेटकवे

गेटवे, एक लोड बैलेंसर है जो मेश के एज पर काम करता है. यह इनकमिंग या आउटगोइंग एचटीटीपी/टीसीपी कनेक्शन को स्वीकार करता है. गेटवे, पोर्ट, एसएनआई कॉन्फ़िगरेशन वगैरह तय कर सकते हैं.

DestinationRule

DestinationRule, ऐसी नीतियों के बारे में बताता है जो रूटिंग होने के बाद, किसी सेवा के लिए ट्रैफ़िक पर लागू होती हैं. इनमें लोड बैलेंसिंग, साइडकार से कनेक्शन पूल का साइज़, और आउटलायर का पता लगाने की सेटिंग के लिए कॉन्फ़िगरेशन की जानकारी होती है.

Istio मल्टीक्लस्टर

आपने देखा होगा कि जब हमने दो क्लस्टर बनाए थे, तब हमारे primary क्लस्टर में ऑटोस्केल करने की सुविधा के बिना चार नोड थे और हमारे burst क्लस्टर में पांच नोड तक ऑटोस्केल करने की सुविधा के साथ एक नोड था.

इस कॉन्फ़िगरेशन की दो वजहें हैं.

सबसे पहले, हम "ऑन-प्रीमिस" से क्लाउड पर माइग्रेट करने की स्थिति को सिम्युलेट करना चाहते हैं. ऑन-प्रीमिस एनवायरमेंट में, आपके पास अपने-आप स्केल होने वाले क्लस्टर का ऐक्सेस नहीं होता, क्योंकि आपके पास तय इन्फ़्रास्ट्रक्चर होता है.

दूसरा, Istio को चलाने के लिए, चार नोड का सेटअप (जैसा कि ऊपर बताया गया है) ज़रूरी है. इससे यह सवाल उठता है: अगर Istio को कम से कम चार नोड की ज़रूरत है, तो हमारा burst क्लस्टर, एक नोड के साथ Istio को कैसे चला सकता है? इसका जवाब यह है कि Istio मल्टीक्लस्टर, Istio सेवाओं का बहुत छोटा सेट इंस्टॉल करता है. साथ ही, नीति के नियमों को वापस पाने और टेलीमेट्री की जानकारी पब्लिश करने के लिए, प्राइमरी क्लस्टर में Istio इंस्टॉलेशन के साथ संपर्क करता है.

8. ऐप्लिकेशन आर्किटेक्चर के बारे में खास जानकारी

कॉम्पोनेंट की खास जानकारी

हम NodeJS और Redis का इस्तेमाल करके, तीन टीयर वाला ऐप्लिकेशन डिप्लॉय करेंगे.

Worker

वर्कर्स ऐप्लिकेशन, NodeJS में लिखा गया है. यह आने वाले POST एचटीटीपी अनुरोधों को सुनेगा और उन पर हैश करने की कार्रवाई करेगा. अगर PREFIX नाम का कोई एनवायरमेंट वैरिएबल तय किया गया है, तो यह हैश को उस वैल्यू के साथ जोड़ देगा. हैश का हिसाब लगाने के बाद, ऐप्लिकेशन, तय किए गए Redis सर्वर पर चैनल "calculation" पर नतीजा भेजता है.

हम बाद में PREFIX एनवायरमेंट वैरिएबल का इस्तेमाल करके, मल्टीक्लस्टर की सुविधा के बारे में बताएंगे.

रेफ़रंस के लिए: ये ऐसे पैकेज हैं जिनका इस्तेमाल ऐप्लिकेशन करता है.

  • body-parser: हमें अपने एचटीटीपी अनुरोधों को पार्स करने की अनुमति देता है
  • cors: क्रॉस-ऑरिजिन रिसॉर्स शेयरिंग का इस्तेमाल करने की अनुमति देता है
  • dotenv: एनवायरमेंट वैरिएबल को आसानी से पार्स करना
  • express: आसान वेब साइट होस्टिंग
  • ioredis: Redis डेटाबेस के साथ कम्यूनिकेट करने के लिए क्लाइंट लाइब्रेरी
  • morgan: स्ट्रक्चर्ड लॉग की सुविधा देता है

Frontend

हमारा फ़्रंटएंड भी एक NodeJS ऐप्लिकेशन है, जो express का इस्तेमाल करके वेब पेज को होस्ट करता है. यह उपयोगकर्ता की डाली गई फ़्रीक्वेंसी लेता है और उसी दर पर हमारे worker ऐप्लिकेशन को अनुरोध भेजता है. यह ऐप्लिकेशन, "calculation" नाम के Redis चैनल पर मैसेज की सदस्यता भी लेता है और नतीजों को वेब पेज पर दिखाता है.

ऐप्लिकेशन इन डिपेंडेंसी का इस्तेमाल करता है.

  • body-parser: इससे हमें अपने एचटीटीपी अनुरोधों को पार्स करने में मदद मिलती है
  • dotenv: एनवायरमेंट वैरिएबल को आसानी से पार्स करना
  • express: आसान वेब साइट होस्टिंग
  • ioredis: Redis डेटाबेस के साथ कम्यूनिकेट करने के लिए क्लाइंट लाइब्रेरी
  • morgan: स्ट्रक्चर्ड लॉग उपलब्ध कराता है
  • request: एचटीटीपी अनुरोध करने की अनुमति देता है
  • socket.io: वेब पेज से सर्वर के बीच, दोनों तरफ़ से कम्यूनिकेशन की सुविधा देता है

यह वेबपेज, स्टाइल के लिए Bootstrap का इस्तेमाल करता है. इसे चलाने पर, यह कुछ ऐसा दिखता है

e5e3b9cbede4cac4.png

आर्किटेक्चर डायग्राम

7ae4bc22a58f80a6.png

डिप्लॉयमेंट डायग्राम

हम अपने बनाए गए दो क्लस्टर में अपना फ़ाइनल ऐप्लिकेशन डिप्लॉय करेंगे. primary क्लस्टर में सभी कॉम्पोनेंट (frontend, worker, और Redis) डिप्लॉय किए जाएंगे. हालांकि, burst क्लस्टर में सिर्फ़ worker ऐप्लिकेशन डिप्लॉय किया जाएगा.

यहां दो क्लस्टर के बारे में बताने वाला डायग्राम दिया गया है. लाल रंग में बॉक्स किए गए बॉक्स, Kubernetes सेवाएं हैं और नीले रंग में बॉक्स किए गए बॉक्स, Kubernetes डिप्लॉयमेंट हैं. पीले बॉक्स से पता चलता है कि Istio इंस्टॉल किया गया है.

561db37c510944bd.png

ध्यान दें कि burst क्लस्टर में अब भी Redis की सेवा डिप्लॉय की गई है, जबकि क्लस्टर में Redis के लिए कोई डिप्लॉयमेंट नहीं है. हमें क्लस्टर में यह सेवा होनी चाहिए, ताकि Kubernetes डीएनएस अनुरोध को हल कर सके. हालांकि, जब अनुरोध किया जाएगा, तो Istio Proxy, अनुरोध को primary क्लस्टर में Redis डिप्लॉयमेंट पर फिर से रूट कर देगा.

फ़ाइनल ऐप्लिकेशन में, istiowatcher. नाम के primary क्लस्टर में एक और डिप्लॉयमेंट चलेगा. इससे, ट्रैफ़िक तय थ्रेशोल्ड से ज़्यादा होने पर, burst पर अपने-आप ट्रैफ़िक को डाइनैमिक रीराउटर करने में मदद मिलेगी.

8f6183bdfc3f813c.png

9. ऐप्लिकेशन डिप्लॉयमेंट फ़ाइलें बनाना

हमें अपने ऐप्लिकेशन को डिप्लॉय करने के लिए, Kubernetes मेनिफ़ेस्ट का एक सेट बनाना होगा

प्रोजेक्ट की रूट डायरेक्ट्री में जाएं और kubernetes नाम का नया फ़ोल्डर बनाएं

mkdir ${proj}/kubernetes && cd ${proj}/kubernetes

frontend.yaml लिखना

इससे हमारी फ़्रंटएंड इमेज को ऐक्सेस करने के लिए, Kubernetes डिप्लॉयमेंट और सेवा, दोनों बन जाएंगी.

frontend.yaml में यह जानकारी डालें.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: frontend-deployment
  labels:
    app: frontend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: frontend
        image: gcr.io/istio-burst-workshop/frontend
        ports:
        - containerPort: 8080
        readinessProbe:
            initialDelaySeconds: 10
            httpGet:
              path: "/_healthz"
              port: 8080
              httpHeaders:
              - name: "Cookie"
                value: "istio_session-id=x-readiness-probe"
        livenessProbe:
          initialDelaySeconds: 10
          httpGet:
            path: "/"
            port: 8080
            httpHeaders:
            - name: "Cookie"
              value: "istio_session-id=x-liveness-probe"
        env:
        - name: PORT
          value: "8080"
        - name: PROCESSOR_URL
          value: "http://worker-service"
        - name: REDIS_URL
          value: "redis-cache-service:6379"
---
apiVersion: v1
kind: Service
metadata:
  name: frontend-service
spec:
  type: ClusterIP
  selector:
    app: frontend
  ports:
  - name: http
    port: 80
    targetPort: 8080

Deployment में ध्यान देने वाली मुख्य बातें

  • हमने 8080 को वह पोर्ट बताया है जिस पर ऐप्लिकेशन चलेगा
  • हमने वर्कर्स के लिए "http://worker-service" पता सेट किया है. साथ ही, इस सेवा को रिज़ॉल्व करने के लिए, Kubernetes में पहले से मौजूद डीएनएस सुविधा का इस्तेमाल किया जाएगा
  • हमने अपने REDIS_URL के लिए "redis-cache-service:6379" पते को सेट किया है. साथ ही, हम Kubernetes में पहले से मौजूद डीएनएस सुविधा का इस्तेमाल करके, आईपी पतों को रिज़ॉल्व करेंगे.
  • हमने कंटेनर में liveness और readiness प्रोब भी सेट किए हैं, ताकि कंटेनर के चालू होने पर Kubernetes को इसकी जानकारी दी जा सके.

worker-service.yaml लिखना

हम Kubernetes सेवा की परिभाषा को डिप्लॉयमेंट की परिभाषा से अलग फ़ाइल में लिख रहे हैं, क्योंकि हम इस सेवा का इस्तेमाल कई क्लस्टर में फिर से करेंगे. हालांकि, हर क्लस्टर के लिए एक अलग डिप्लॉयमेंट लिखा जाएगा.

worker-service.yaml में यह जानकारी डालें

apiVersion: v1
kind: Service
metadata:
 name: worker-service
spec:
 type: ClusterIP
 selector:
   app: worker
 ports:
 - name: http
   port: 80
   targetPort: 8081

worker-primary.yaml लिखना

यह worker का डिप्लॉयमेंट होगा, जिसे हम प्राइमरी क्लस्टर में पुश करेंगे.

worker-primary.yaml में यह जानकारी डालें.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: worker-deployment
 labels:
   app: worker
spec:
 replicas: 1
 selector:
   matchLabels:
     app: worker
 template:
   metadata:
     labels:
       app: worker
       cluster-type: primary-cluster
   spec:
     containers:
     - name: worker
       image: gcr.io/istio-burst-workshop/worker
       imagePullPolicy: Always
       ports:
       - containerPort: 8081
       readinessProbe:
           initialDelaySeconds: 10
           httpGet:
             path: "/_healthz"
             port: 8081
             httpHeaders:
             - name: "Cookie"
               value: "istio_session-id=x-readiness-probe"
       livenessProbe:
         initialDelaySeconds: 10
         httpGet:
           path: "/"
           port: 8081
           httpHeaders:
           - name: "Cookie"
             value: "istio_session-id=x-liveness-probe"
       env:
       - name: PORT
         value: "8081"
       - name: REDIS_URL
         value: "redis-cache-service:6379"

इसमें ध्यान दें कि हम liveness और readiness प्रोब देने के लिए उसी पैटर्न का इस्तेमाल कर रहे हैं. साथ ही, अपने ऐप्लिकेशन के इस्तेमाल के लिए PORT और REDIS_URL एनवायरमेंट वैरिएबल तय कर रहे हैं.

इस डिप्लॉयमेंट में ध्यान देने वाली एक और बात यह है कि इसमें PREFIX एनवायरमेंट वैरिएबल मौजूद नहीं है. इसका मतलब है कि कैलकुलेशन के नतीजे, रॉ हैश होंगे.

इस डिप्लॉयमेंट का आखिरी मुख्य पॉइंट cluster-type: primary-cluster लेबल है. हम इसका इस्तेमाल बाद में करेंगे, जब हम Istio के मल्टीक्लस्टर पर ट्रैफ़िक रूटिंग करेंगे

redis.yaml लिखना

हमारे वर्कर से फ़्रंटएंड तक का कम्यूनिकेशन, Redis चैनल के ज़रिए होता है. इसलिए, हमें अपने क्लस्टर में Redis ऐप्लिकेशन को डिप्लॉय करना होगा.

redis.yaml में यह जानकारी डालें

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
 name: redis-cache
spec:
 template:
   metadata:
     labels:
       app: redis-cache
   spec:
     containers:
     - name: redis
       image: redis:alpine
       ports:
       - containerPort: 6379
       readinessProbe:
         periodSeconds: 5
         tcpSocket:
           port: 6379
       livenessProbe:
         periodSeconds: 5
         tcpSocket:
           port: 6379
       volumeMounts:
       - mountPath: /data
         name: redis-data
       resources:
         limits:
           memory: 256Mi
           cpu: 125m
         requests:
           cpu: 70m
           memory: 200Mi
     volumes:
     - name: redis-data
       emptyDir: {}

यह Redis ऐप्लिकेशन का सेमी स्टैंडर्ड डिप्लॉयमेंट है. यह redis:alpine इमेज के आधार पर एक कंटेनर बनाता है, सही पोर्ट दिखाता है, और संसाधनों की सही सीमाएं सेट करता है.

redis-service.yaml लिखना

हमें अपने Redis ऐप्लिकेशन के साथ कम्यूनिकेट करने के लिए, Kubernetes सेवा की ज़रूरत है

redis-service.yaml में यह जानकारी डालें

apiVersion: v1
kind: Service
metadata:
 name: redis-cache-service
spec:
 type: ClusterIP
 selector:
   app: redis-cache
 ports:
 - port: 6379
   targetPort: 6379

यह redis-cache-service नाम की सेवा उपलब्ध कराती है, ताकि हमारे Redis डिप्लॉयमेंट को ऐक्सेस किया जा सके.

10. ऐप्लिकेशन को डिप्लॉय करना

GCR में हमारी इमेज पॉश हो गई हैं और हमारे Kubernetes मेनिफ़ेस्ट लिखे जा चुके हैं. इसलिए, अब हमारे ऐप्लिकेशन को डिप्लॉय करने और यह देखने का अच्छा समय है कि यह कैसे काम करता है!

ऐप्लिकेशन को डिप्लॉय करने के लिए, ये कमांड चलाएं

  1. पक्का करें कि हम सही क्लस्टर में हैं
kubectx primary
  1. Redis कैश मेमोरी डिप्लॉय करना
kubectl apply -f redis.yaml
  1. Redis सेवा को डिप्लॉय करना
kubectl apply -f redis-service.yaml
  1. फ़्रंटएंड डिप्लॉय करना
kubectl apply -f frontend.yaml
  1. वर्कर्स डिप्लॉय करना
kubectl apply -f worker-primary.yaml
  1. वर्कर सेवा डिप्लॉय करना
kubectl apply -f worker-service.yaml

हमने अपना ऐप्लिकेशन GKE पर डिप्लॉय कर दिया है. बधाई हो!

जांच करना

पॉड के ऑनलाइन आने का इंतज़ार करें

kubectl get pods -w

जब सभी पॉड "चालू" हो जाएं, तो Ctrl + C दबाएं

NAME                                   READY     STATUS    RESTARTS   AGE
frontend-deployment-695d95fbf7-76sd8   1/1       Running   0          2m
redis-cache-7475999bf5-nxj8x           1/1       Running   0          2m
worker-deployment-5b9cf9956d-g975p     1/1       Running   0          2m

आपको पता चलेगा कि हमने LoadBalancer के ज़रिए अपना फ़्रंटएंड एक्सपोज़ नहीं किया है. ऐसा इसलिए है, क्योंकि बाद में हम Istio के ज़रिए ऐप्लिकेशन को ऐक्सेस करेंगे. यह जांचने के लिए कि सब कुछ ठीक से काम कर रहा है या नहीं, हम kubectl port-forward. का इस्तेमाल करेंगे. अपनी लोकल (या Cloud Shell) मशीन के पोर्ट 8080 को frontend डिप्लॉयमेंट चलाने वाले पोर्ट 8080 पर फ़ॉरवर्ड करने के लिए, यह कमांड चलाएं.

kubectl port-forward \
$(kubectl get pods -l app=frontend -o jsonpath='{.items[0].metadata.name}') \
8080:8080

अगर आपने स्थानीय तौर पर इंस्टॉल किया है: कोई वेब ब्राउज़र खोलें और http://localhost:8080 पर जाएं

अगर Cloud Shell में चलाया जा रहा है, तो: "वेब की झलक" बटन पर क्लिक करें और "पोर्ट 8080 पर झलक देखें" चुनें

bdb5dc75f415be11.png

आपको फ़्रंटएंड दिखेगा! अगर "फ़्रीक्वेंसी" बॉक्स में कोई नंबर डाला जाता है, तो आपको हैश दिखने लगेंगे

1caafaffab26897a.png

बधाई हो, यह सुविधा चालू हो गई है!

पोर्ट को फ़ॉरवर्ड करना बंद करने के लिए, Ctrl+C दबाएं.

11. डिप्लॉय किए गए ऐप्लिकेशन को क्लीनअप करना

हम अपने क्लस्टर में Istio लागू करने जा रहे हैं. इसके बाद, अपने ऐप्लिकेशन को फिर से डिप्लॉय करेंगे. इसलिए, पहले अपने मौजूदा ऐप्लिकेशन को हटा दें.

आपने अभी-अभी जो डिप्लॉयमेंट और सेवाएं बनाई हैं उन्हें मिटाने के लिए, नीचे दिए गए कमांड चलाएं

  1. redis-cache-service मिटाएं
kubectl delete -f redis-service.yaml
  1. redis मिटाएं
kubectl delete -f redis.yaml
  1. frontend मिटाएं
kubectl delete -f frontend.yaml
  1. worker मिटाएं
kubectl delete -f worker-primary.yaml
  1. worker-service मिटाएं
kubectl delete -f worker-service.yaml

12. प्राइमरी क्लस्टर पर Istio इंस्टॉल करना

Istio का इस्तेमाल करना

Istio की रिलीज़, GitHub पर होस्ट की जाती हैं. नीचे दिए गए निर्देशों से, istio का 1.0.0 वर्शन डाउनलोड हो जाएगा और उसे अनपैक कर दिया जाएगा.

  1. अपने प्रोजेक्ट के रूट पर जाना
cd ${proj}
  1. संग्रह डाउनलोड करना
curl -LO https://github.com/istio/istio/releases/download/1.0.0/istio-1.0.0-linux.tar.gz
  1. संग्रहित डेटा को निकालना और हटाना
tar xzf istio-1.0.0-linux.tar.gz && rm istio-1.0.0-linux.tar.gz

Istio टेंप्लेट बनाना

नीचे दिया गया Helm कमांड चलाने से, आपके क्लस्टर में Istio इंस्टॉल करने के लिए टेंप्लेट बन जाएगा.

helm template istio-1.0.0/install/kubernetes/helm/istio \
--name istio --namespace istio-system \
--set prometheus.enabled=true \
--set servicegraph.enabled=true  > istio-primary.yaml

इससे आपकी मौजूदा डायरेक्ट्री में istio-primary.yaml नाम की एक फ़ाइल बन जाएगी. इसमें Istio को डिप्लॉय और चलाने के लिए ज़रूरी सभी डेफ़िनिशन और स्पेसिफ़िकेशन शामिल होंगे.

दो --set पैरामीटर पर ध्यान दें. ये Istio सिस्टम में Prometheus और ServiceGraph की सहायता जोड़ते हैं. हम बाद में लैब में Prometheus सेवा का इस्तेमाल करेंगे.

Istio को डिप्लॉय करना

istio को डिप्लॉय करने के लिए, हमें पहले istio-system नाम का नेमस्पेस बनाना होगा. इस नेमस्पेस में, Istio डिप्लॉयमेंट और सेवाएं चल सकती हैं.

kubectl create namespace istio-system

आखिर में, Helm की मदद से बनाई गई istio-primary.yaml फ़ाइल लागू करें

kubectl apply -f istio-primary.yaml

लेबल का डिफ़ॉल्ट नेमस्पेस

Istio, आपके हर डिप्लॉयमेंट में साइडकार प्रॉक्सी सेवा को इंजेक्ट करके काम करता है. यह ऑप्ट-इन के आधार पर किया जाता है. इसलिए, हमें अपने default नेमस्पेस को istio-injection=enabled के साथ लेबल करना होगा, ताकि Istio हमारे लिए साइडकार को अपने-आप इंजेक्ट कर सके.

kubectl label namespace default istio-injection=enabled

बधाई हो! हमारे पास Istio के साथ क्लस्टर चालू है, ताकि हम अपना ऐप्लिकेशन डिप्लॉय कर सकें!

13. Istio ट्रैफ़िक मैनेजमेंट के साथ हमारा ऐप्लिकेशन डिप्लॉय करना

Istio ट्रैफ़िक मैनेजमेंट कॉन्फ़िगरेशन फ़ाइलें बनाना

Istio, Kubernetes की तरह ही काम करता है, क्योंकि यह कॉन्फ़िगरेशन के लिए yaml फ़ाइलों का इस्तेमाल करता है. इसलिए, हमें फ़ाइलों का एक सेट बनाना होगा, ताकि Istio को यह बताया जा सके कि हमारे ट्रैफ़िक को कैसे एक्सपोज़ और रूट किया जाए.

istio-manifests नाम की डायरेक्ट्री बनाएं और उसमें बदलें

mkdir ${proj}/istio-manifests && cd ${proj}/istio-manifests

frontend-gateway.yaml लिखना

यह फ़ाइल, हमारे Kubernetes क्लस्टर को GKE LoadBalancer की तरह ही एक्सपोज़ करेगी. साथ ही, आने वाले सभी ट्रैफ़िक को हमारी फ़्रंटएंड सेवा पर भेजेगी.

frontend-gateway.yaml नाम की फ़ाइल बनाएं और इसमें यह डालें.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
 name: frontend-gateway
spec:
 selector:
   istio: ingressgateway # use Istio default gateway implementation
 servers:
 - port:
     number: 80
     name: http
     protocol: HTTP
   hosts:
   - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: frontend-ingress-virtual-service
spec:
 hosts:
 - "*"
 gateways:
 - frontend-gateway
 http:
 - route:
   - destination:
       host: frontend-service
       port:
         number: 80

redis-virtualservice.yaml लिखना

redis-virtualservice.yaml नाम की फ़ाइल बनाएं और इसमें यह डालें

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: redis-virtual-service
spec:
 hosts:
 - redis-cache-service
 gateways:
 - mesh
 tcp:
 - route:
   - destination:
       host: redis-cache-service.default.svc.cluster.local

worker-virtualservice.yaml लिखना

worker-virtualservice.yaml नाम की फ़ाइल बनाएं और इसमें यह डालें

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: worker-virtual-service
spec:
 hosts:
 - worker-service
 gateways:
 - mesh
 http:
 - route:
   - destination:
       host: worker-service.default.svc.cluster.local   
       port:
         number: 80

Istio ट्रैफ़िक मैनेजमेंट की नीतियां डिप्लॉय करना

Istio की नीतियों को डिप्लॉय करने का तरीका, Kubernetes के अन्य संसाधनों को डिप्लॉय करने के तरीके जैसा ही है. इसके लिए, kubectl apply

  1. हमारा गेटवे लागू करना
kubectl apply -f frontend-gateway.yaml
  1. Redis VirtualService लागू करना
kubectl apply -f redis-virtualservice.yaml
  1. हमारी Worker VirtualService लागू करना
kubectl apply -f worker-virtualservice.yaml

ऐप्लिकेशन को डिप्लॉय करना

  1. हमारी kubernetes डायरेक्ट्री पर वापस जाना
cd ${proj}/kubernetes
  1. Redis कैश मेमोरी डिप्लॉय करना
kubectl apply -f redis.yaml
  1. Redis सेवा को डिप्लॉय करना
kubectl apply -f redis-service.yaml
  1. फ़्रंटएंड डिप्लॉय करना
kubectl apply -f frontend.yaml
  1. वर्कर्स डिप्लॉय करना
kubectl apply -f worker-primary.yaml
  1. वर्कर सेवा डिप्लॉय करना
kubectl apply -f worker-service.yaml

पुष्टि करें

इस समय, हमने अपने ऐप्लिकेशन को Istio और ट्रैफ़िक मैनेजमेंट नीतियों वाले क्लस्टर पर फिर से डिप्लॉय किया है.

चलिए, सभी वर्कलोड के ऑनलाइन होने का इंतज़ार करते हैं

सभी नोड ऑनलाइन होने के बाद, frontend-ingressgateway.yaml में कॉन्फ़िगर किया गया IngressGateway पाएं

$ kubectl -n istio-system get svc istio-ingressgateway
NAME                   TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                                                                                     AGE
istio-ingressgateway   LoadBalancer   10.36.3.112   35.199.158.10   80:31380/TCP,

<EXTERNAL-IP> पते पर ब्राउज़ करें या उसे कर्ल करें. इसके बाद, आपको फ़्रंटएंड दिखेगा!

$ curl 35.199.158.10
<!doctype html>
<html>

<head>
    <title>String Hashr</title>
    <!-- Bootstrap -->
...

14. "बर्स्ट" क्लस्टर पर Istio इंस्टॉल करना

हमने अपने primary क्लस्टर को सेट अप करने और उस पर डिप्लॉय करने में काफ़ी समय बिताया है. हालांकि, हमारे पास एक और क्लस्टर है जिस पर डिप्लॉय करना है!

इस सेक्शन में, हमें अपने दोनों क्लस्टर में कॉन्फ़िगरेशन वैरिएबल हासिल करने होंगे. इसलिए, हर कमांड के लिए यह ध्यान रखें कि हमें किस क्लस्टर पर ले जाया जा रहा है.

Istio रिमोट मेनिफ़ेस्ट बनाना

primary क्लस्टर में Istio को डिप्लॉय करने की तरह ही, हम burst क्लस्टर में Istio रिमोट को डिप्लॉय करने के लिए, टेंप्लेट बनाने के लिए Helm का इस्तेमाल करेंगे. हालांकि, ऐसा करने से पहले, हमें अपने primary क्लस्टर के बारे में कुछ जानकारी चाहिए

प्राइमरी क्लस्टर की जानकारी इकट्ठा करना

primary क्लस्टर में बदलना

kubectx primary

यहां दिए गए निर्देश, प्राइमरी क्लस्टर में मौजूद अलग-अलग पॉड के आईपी पते वापस लाते हैं. Istio रिमोट, प्राइमरी क्लस्टर के साथ फिर से संपर्क करने के लिए इनका इस्तेमाल करता है.

export PILOT_POD_IP=$(kubectl -n istio-system get pod -l istio=pilot -o jsonpath='{.items[0].status.podIP}')

export POLICY_POD_IP=$(kubectl -n istio-system get pod -l istio-mixer-type=policy -o jsonpath='{.items[0].status.podIP}')

export STATSD_POD_IP=$(kubectl -n istio-system get pod -l istio=statsd-prom-bridge -o jsonpath='{.items[0].status.podIP}')

export TELEMETRY_POD_IP=$(kubectl -n istio-system get pod -l istio-mixer-type=telemetry -o jsonpath='{.items[0].status.podIP}')

export ZIPKIN_POD_IP=$(kubectl -n istio-system get pod -l app=jaeger -o jsonpath='{range .items[*]}{.status.podIP}{end}')

रिमोट टेंप्लेट बनाना

अब हम helm का इस्तेमाल करके, istio-remote-burst.yaml नाम की एक फ़ाइल बनाएंगे. इसके बाद, हम इसे burst क्लस्टर में डिप्लॉय कर सकते हैं.

प्रोजेक्ट रूट में बदलना

cd $proj

helm template istio-1.0.0/install/kubernetes/helm/istio-remote --namespace istio-system \
--name istio-remote \
--set global.remotePilotAddress=${PILOT_POD_IP} \
--set global.remotePolicyAddress=${POLICY_POD_IP} \
--set global.remoteTelemetryAddress=${TELEMETRY_POD_IP} \
--set global.proxy.envoyStatsd.enabled=true \
--set global.proxy.envoyStatsd.host=${STATSD_POD_IP} \
--set global.remoteZipkinAddress=${ZIPKIN_POD_IP} > istio-remote-burst.yaml

बर्स्ट क्लस्टर पर Istio रिमोट इंस्टॉल करना

अपने burst क्लस्टर पर Istio इंस्टॉल करने के लिए, हमें वही चरण अपनाने होंगे जो primary क्लस्टर पर इंस्टॉल करते समय अपनाए गए थे. हालांकि, इसके लिए हमें istio-remote-burst.yaml फ़ाइल का इस्तेमाल करना होगा.

kubecontext को burst में बदलना

kubectx burst

istio-system नेमस्पेस बनाना

kubectl create ns istio-system

istio-burst.yaml लागू करना

kubectl apply -f istio-remote-burst.yaml

लेबल का डिफ़ॉल्ट नेमस्पेस

हमें फिर से default नेमस्पेस को लेबल करना होगा, ताकि प्रॉक्सी अपने-आप इंजेक्ट हो सके.

kubectl label namespace default istio-injection=enabled

बधाई हो! इस समय, हमने burst क्लस्टर पर Istio Remote सेट अप कर लिया है. हालांकि, इस समय क्लस्टर एक-दूसरे से संपर्क नहीं कर पा रहे हैं. हमें burst क्लस्टर के लिए एक kubeconfig फ़ाइल जनरेट करनी होगी, ताकि हम उन्हें एक साथ लिंक करने के लिए primary क्लस्टर में डिप्लॉय कर सकें.

"बर्स्ट" क्लस्टर के लिए kubeconfig फ़ाइल बनाना

बर्स्ट क्लस्टर में बदलना

kubectx burst

एनवायरमेंट सेट अप करना

क्लस्टर के लिए kubeconfig फ़ाइल बनाने के लिए, हमें क्लस्टर के बारे में कुछ जानकारी इकट्ठा करनी होगी.

  1. क्लस्टर का नाम पाना
CLUSTER_NAME=$(kubectl config view --minify=true -o "jsonpath={.clusters[].name}")
  1. क्लस्टर सर्वर का नाम पाना
SERVER=$(kubectl config view --minify=true -o "jsonpath={.clusters[].cluster.server}")
  1. istio-multi सेवा खाते के सर्टिफ़िकेट देने वाली संस्था के लिए, सीक्रेट का नाम पाना
SECRET_NAME=$(kubectl get sa istio-multi -n istio-system -o jsonpath='{.secrets[].name}')
  1. पिछले सीक्रेट में सेव किया गया, सर्टिफ़िकेट देने वाली संस्था या निकाय का डेटा पाना
CA_DATA=$(kubectl get secret ${SECRET_NAME} -n istio-system -o "jsonpath={.data['ca\.crt']}")
  1. पिछले सीक्रेट में सेव किया गया टोकन पाना
TOKEN=$(kubectl get secret ${SECRET_NAME} -n istio-system -o "jsonpath={.data['token']}" | base64 --decode)

kubeconfig फ़ाइल बनाना

सभी एनवायरमेंट वैरिएबल सेट होने के बाद, हमें अपनी kubeconfig फ़ाइल बनानी होगी

cat <<EOF > burst-kubeconfig
apiVersion: v1
clusters:
   - cluster:
       certificate-authority-data: ${CA_DATA}
       server: ${SERVER}
     name: ${CLUSTER_NAME}
contexts:
   - context:
       cluster: ${CLUSTER_NAME}
       user: ${CLUSTER_NAME}
     name: ${CLUSTER_NAME}
current-context: ${CLUSTER_NAME}
kind: Config
preferences: {}
users:
   - name: ${CLUSTER_NAME}
     user:
       token: ${TOKEN}
EOF

इससे आपकी मौजूदा डायरेक्ट्री में burst-kubeconfig नाम की एक नई फ़ाइल बन जाएगी. इसका इस्तेमाल primary क्लस्टर, burst क्लस्टर की पुष्टि करने और उसे मैनेज करने के लिए कर सकता है.

प्राइमरी क्लस्टर पर वापस जाना

kubectx primary

सीक्रेट बनाकर और उसे लेबल करके, "बर्स्ट" के लिए kubeconfig लागू करना

kubectl create secret generic burst-kubeconfig --from-file burst-kubeconfig -n istio-system

सीक्रेट को लेबल करें, ताकि Istio को पता चले कि इसका इस्तेमाल मल्टीक्लस्टर की पुष्टि करने के लिए किया जाना है

kubectl label secret burst-kubeconfig istio/multiCluster=true -n istio-system

बधाई हो! हमारे दोनों क्लस्टर की पुष्टि हो चुकी है और वे Istio Multicluster के ज़रिए एक-दूसरे से संपर्क कर रहे हैं. चलिए, अपने ऐप्लिकेशन को क्रॉस-क्लस्टर डिप्लॉय करते हैं

15. क्रॉस-क्लस्टर ऐप्लिकेशन को डिप्लॉय करना

डिप्लॉयमेंट बनाना

kubernetes डायरेक्ट्री पर स्विच करना

cd ${proj}/kubernetes

"बर्स्ट" क्लस्टर के लिए वर्कर्स डिप्लॉयमेंट बनाएं: worker-burst.yaml

worker-burst.yaml नाम की फ़ाइल बनाएं और इसमें यह डालें:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: worker-deployment
  labels:
    app: worker
spec:
  replicas: 1
  selector:
    matchLabels:
      app: worker
  template:
    metadata:
      labels:
        app: worker
        cluster-type: burst-cluster
    spec:
      containers:
      - name: worker
        image: gcr.io/istio-burst-workshop/worker
        imagePullPolicy: Always
        ports:
        - containerPort: 8081
        readinessProbe:
            initialDelaySeconds: 10
            httpGet:
              path: "/_healthz"
              port: 8081
              httpHeaders:
              - name: "Cookie"
                value: "istio_session-id=x-readiness-probe"
        livenessProbe:
          initialDelaySeconds: 10
          httpGet:
            path: "/"
            port: 8081
            httpHeaders:
            - name: "Cookie"
              value: "istio_session-id=x-liveness-probe"
        env:
        - name: PORT
          value: "8081"
        - name: REDIS_URL
          value: "redis-cache-service:6379"
        - name: PREFIX
          value: "bursty-"

ध्यान दें कि यह worker-primary.yaml से काफ़ी मिलता-जुलता है, जिसे हमने पहले बनाया था. इनमें दो मुख्य अंतर हैं.

पहला मुख्य अंतर यह है कि हमने PREFIX एनवायरमेंट वैरिएबल को "bursty-" वैल्यू के साथ जोड़ा है

env:
- name: PORT
  value: "8081"
- name: REDIS_URL
  value: "redis-cache-service:6379"
- name: PREFIX
  value: "bursty-"

इसका मतलब है कि burst क्लस्टर में मौजूद हमारा वर्कर्स, भेजे जाने वाले सभी हैश के आगे "bursty-" लगाएगा. इसका इस्तेमाल करके, यह पता लगाया जा सकता है कि हमारा ऐप्लिकेशन सचमुच क्रॉस-क्लस्टर है या नहीं.

दूसरा मुख्य अंतर यह है कि हमने इस डिप्लॉयमेंट पर cluster-type लेबल को primary-cluster से बदलकर burst-cluster कर दिया है

labels:
  app: worker
  cluster-type: burst-cluster

हम अपनी VirtualService को अपडेट करते समय, इस लेबल का इस्तेमाल करेंगे.

Istio सेवाओं में बदलाव करना

फ़िलहाल, हमारी Istio सेवाएं, दोनों डिप्लॉयमेंट का फ़ायदा नहीं ले रही हैं. हमारा 100% ट्रैफ़िक, "प्राइमरी" क्लस्टर पर भेजा जा रहा है. चलिए, इसे बदलते हैं.

हमारी istio-manifests डायरेक्ट्री पर स्विच करना

cd ${proj}/istio-manifests

DestinationRules को शामिल करने के लिए, worker-virtualservice.yaml में बदलाव करना

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: worker-virtual-service
spec:
  hosts:
  - worker-service
  gateways:
  - mesh
  http:
  - route:
    - destination:
        host: worker-service.default.svc.cluster.local    
        subset: primary
        port:
          number: 80        
      weight: 50
    - destination:
        host: worker-service.default.svc.cluster.local     
        subset: burst  
        port:
          number: 80        
      weight: 50
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: worker-destination-rule
spec:
  host: worker-service
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: primary
    labels:
      cluster-type: primary-cluster
  - name: burst
    labels:
     cluster-type: burst-cluster

आप देख सकते हैं कि हमने अपनी VirtualService में दूसरा डेस्टिनेशन जोड़ा है. यह अब भी उसी होस्ट (worker-service.default.svc.cluster.local)) का रेफ़रंस देता है, लेकिन 50% ट्रैफ़िक को primary सबसेट पर और बाकी 50% ट्रैफ़िक को burst सबसेट पर भेजा जा रहा है.

हमने primary सबसेट को उन डिप्लॉयमेंट के तौर पर तय किया है जिन पर cluster-type: primary-cluster लेबल है. साथ ही, burst सबसेट को उन डिप्लॉयमेंट के तौर पर तय किया है जिन पर cluster-type: burst-cluster लेबल है.

इससे, हमारे ट्रैफ़िक को दो क्लस्टर के बीच 50/50 के हिसाब से बांटा जाता है.

क्लस्टर में डिप्लॉय करना

बर्स्ट क्लस्टर में redis-service.yaml को डिप्लॉय करना

burst kubeconfig में बदलें

kubectx burst

हमारे प्रोजेक्ट के रूट में बदलें

cd ${proj}

इसके बाद, डिप्लॉय करें

बर्स्ट क्लस्टर में redis-service.yaml को डिप्लॉय करना

kubectl apply -f kubernetes/redis-service.yaml

बर्स्ट क्लस्टर में worker-burst.yaml को डिप्लॉय करना

kubectl apply -f kubernetes/worker-burst.yaml

बर्स्ट क्लस्टर में worker-service.yaml को डिप्लॉय करना

kubectl apply -f kubernetes/worker-service.yaml

Istio VirtualServices लागू करना

primary kubeconfig में बदलें

kubectx primary

इसके बाद, डिप्लॉय करें

kubectl apply -f istio-manifests/worker-virtualservice.yaml

पुष्टि करना कि यह काम करता है

यह पुष्टि करने के लिए कि यह काम कर रहा है, अपने Istio इंग्रेस पॉइंट पर ब्राउज़ करें और देखें कि करीब 50% हैश में "burst-" प्रीफ़िक्स कैसे है.

78fb6e235e9f4a07.png

इसका मतलब है कि हम अलग-अलग क्लस्टर के साथ बातचीत कर रहे हैं! अलग-अलग सेवाओं के लिए अहमियत बदलकर, worker-virtualservice.yaml फ़ाइल लागू करें. क्लस्टर के बीच ट्रैफ़िक को संतुलित करने का यह एक बेहतरीन तरीका है. हालांकि, अगर यह अपने-आप हो जाए, तो क्या होगा?

16. Prometheus मेट्रिक का फ़ायदा लेना

Prometheus के बारे में जानकारी

Prometheus, सिस्टम की निगरानी करने और चेतावनी देने वाला एक ओपन-सोर्स टूलकिट है. इसे मूल रूप से SoundCloud ने बनाया था. यह टाइम सीरीज़ डेटा के साथ कई डाइमेंशन वाला डेटा मॉडल बनाए रखता है. इस डेटा की पहचान, मेट्रिक के नाम और की/वैल्यू पेयर से की जाती है.

रेफ़रंस के लिए, यहां Prometheus के आर्किटेक्चर का डायग्राम दिया गया है:

601e1155a825e0c2.png

Prometheus के साथ डिप्लॉय किए जाने पर, Istio अपने-आप Prometheus सर्वर को अलग-अलग मेट्रिक की रिपोर्ट भेजता है. हम इन मेट्रिक का इस्तेमाल करके, अपने क्लस्टर को फ़्लाइट पर मैनेज कर सकते हैं.

Prometheus की मेट्रिक एक्सप्लोर करना

शुरू करने के लिए, हमें Prometheus डिप्लॉयमेंट को एक्सपोज़ करना होगा.

GKE में, 'वर्कलोड' टैब पर जाएं. इसके बाद, "prometheus" वर्कलोड पर ड्रिल-डाउन करें.

b4a7a3cd67db05b3.png

डिप्लॉयमेंट की जानकारी देखने के बाद, कार्रवाइयां -> एक्सपोज़ करें पर जाएं.

c04a482e55bdfd41.png

पोर्ट 9090 पर फ़ॉरवर्ड करने का विकल्प चुनें और "लोड बैलेंसर" टाइप करें

d5af3ba22a7a6ebb.png

इसके बाद, "एक्सपोज़ करें" को चुनें

इससे सार्वजनिक तौर पर ऐक्सेस किए जा सकने वाले आईपी पते पर एक सेवा बन जाएगी. इसका इस्तेमाल, अपनी Prometheus मेट्रिक को एक्सप्लोर करने के लिए किया जा सकता है

एंडपॉइंट के चालू होने का इंतज़ार करें. इसके बाद, "बाहरी एंडपॉइंट" के बगल में मौजूद आईपी पते पर क्लिक करें b1e40ad90851da29.png

अब आपको Prometheus का यूज़र इंटरफ़ेस दिखेगा.

ed273552270337ec.png

Prometheus में ज़रूरत के मुताबिक मेट्रिक उपलब्ध होती हैं, ताकि इसे वर्कशॉप के तौर पर इस्तेमाल किया जा सके. फ़िलहाल, हम istio_requests_total मेट्रिक के बारे में बताएंगे.

उस क्वेरी को लागू करने पर, बहुत सारा डेटा मिलता है. यह Istio सेवा मेश से गुज़रने वाले सभी अनुरोधों की मेट्रिक है. हम अपने एक्सप्रेशन को बदलकर, अपनी दिलचस्पी के हिसाब से फ़िल्टर करेंगे:

ऐसे अनुरोध जिनमें डेस्टिनेशन सेवा worker-service.default.svc.cluster.local है और जिनका सोर्स frontend-deployment, पिछले 15 सेकंड तक सीमित है

यह क्वेरी कुछ इस तरह दिखती है:

istio_requests_total{reporter="destination",
destination_service="worker-service.default.svc.cluster.local",
source_workload="frontend-deployment"}[15s]

इससे हमें काम करने के लिए, डेटा का एक ऐसा सेट मिलता है जिसे मैनेज करना काफ़ी आसान होता है

19d551fd5eac3785.png

हालांकि, यह अब भी थोड़ा घना है. हमें सभी अनुरोधों के बारे में नहीं, बल्कि हर सेकंड मिलने वाले अनुरोधों के बारे में जानकारी चाहिए.

इसके लिए, हम बिल्ट-इन rate फ़ंक्शन का इस्तेमाल कर सकते हैं

rate(istio_requests_total{reporter="destination",
destination_service="worker-service.default.svc.cluster.local",
source_workload="frontend-deployment"}[15s])

dbb9dc063a18da9b.png

इससे हमें ज़्यादा जानकारी मिल रही है, लेकिन हमें उन मेट्रिक को लॉजिकल ग्रुप में थोड़ा और कम करना होगा.

इसके लिए, हम sum और by कीवर्ड का इस्तेमाल करके, अपने नतीजों को ग्रुप कर सकते हैं और उनका योग निकाल सकते हैं

sum(rate(istio_requests_total{reporter="destination",
destination_service="worker-service.default.svc.cluster.local",
source_workload="frontend-deployment"}[15s])) by (source_workload,
source_app, destination_service)

898519966930ec56.png

बढ़िया! हमें Prometheus से अपनी ज़रूरत के हिसाब से मेट्रिक मिल सकती हैं.

Prometheus की हमारी आखिरी क्वेरी

अब हमें Prometheus से यह आखिरी क्वेरी पूछनी है

sum(rate(istio_requests_total{reporter="destination",
destination_service="worker-service.default.svc.cluster.local",
source_workload="frontend-deployment"}[15s])) by (source_workload,
source_app, destination_service)

अब हम मेट्रिक पाने के लिए, उनके एचटीटीपी एपीआई का इस्तेमाल कर सकते हैं.

हम अपनी क्वेरी के साथ उनके एपीआई को क्वेरी कर सकते हैं. इसके लिए, एचटीटीपी GET अनुरोध इस तरह करें. <prometheus-ip-here> को बदलें

curl http://<prometheus-ip-here>/api/v1/query?query=sum\(rate\(istio_requests_total%7Breporter%3D%22destination%22%2C%0Adestination_service%3D%22worker-service.default.svc.cluster.local%22%2C%0Asource_workload%3D%22frontend-deployment%22%7D%5B15s%5D\)\)%20by%20\(source_workload%2C%0Asource_app%2C%20destination_service\)

जवाब का एक उदाहरण यहां दिया गया है:

{
    "status": "success",
    "data": {
        "resultType": "vector",
        "result": [
            {
                "metric": {
                    "destination_service": "worker-service.default.svc.cluster.local",
                    "source_app": "frontend",
                    "source_workload": "frontend-deployment"
                },
                "value": [
                    1544404907.503,
                    "18.892886390062788"
                ]
            }
        ]
    }
}

अब, हम JSON से अपनी मेट्रिक वैल्यू निकाल सकते हैं

क्लीनअप

हमें वह सेवा मिटानी होगी जिसका इस्तेमाल हमने Prometheus को एक्सपोज़ करने के लिए किया था. Google Cloud Console में, हमने अभी जो सेवा बनाई है उसके सबसे ऊपर जाएं और "मिटाएं" पर क्लिक करें

d58cb51b4c922751.png

अगले चरण:

क्लस्टर में ट्रैफ़िक किस तरह और किस दर से आ रहा है, यह पता लगाने के बाद हमारा अगला कदम एक छोटी बाइनरी लिखना है. यह बाइनरी, समय-समय पर prometheus से क्वेरी करती है. अगर worker पर हर सेकंड मिलने वाले अनुरोधों की संख्या किसी थ्रेशोल्ड से ज़्यादा हो जाती है, तो सभी ट्रैफ़िक को burst क्लस्टर पर भेजने के लिए, हमारी वर्कर्स वर्चुअल सेवा पर अलग-अलग डेस्टिनेशन वेट लागू करें. जब हर सेकंड में मिलने वाले अनुरोधों की संख्या, थ्रेशोल्ड से कम हो जाए, तो सारा ट्रैफ़िक वापस primary पर भेजें.

17. क्रॉस क्लस्टर बर्स्ट बनाना

सेट अप

प्राइमरी क्लस्टर में, worker-service के लिए सारा ट्रैफ़िक सेट करना

हम worker-service क्लस्टर पर भेजे जाने वाले सभी ट्रैफ़िक को अपने ऐप्लिकेशन की "डिफ़ॉल्ट" स्थिति मानेंगेprimary

$proj/istio-manifests/worker-virtualservice.yaml को इस तरह से बदलें

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: worker-virtual-service
spec:
  hosts:
  - worker-service
  gateways:
  - mesh
  http:
  - route:
    - destination:
        host: worker-service.default.svc.cluster.local    
        subset: primary
        port:
          number: 80        
      weight: 100
    - destination:
        host: worker-service.default.svc.cluster.local     
        subset: burst  
        port:
          number: 80        
      weight: 0
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: worker-destination-rule
spec:
  host: worker-service
  trafficPolicy:
    loadBalancer:
      simple: RANDOM
  subsets:
  - name: primary
    labels:
      cluster-type: primary-cluster
  - name: burst
    labels:
     cluster-type: burst-cluster

पक्का करें कि आप primary क्लस्टर से कनेक्ट हों

kubectx primary

istio-manifests/worker-virtualservice.yaml लागू करना

kubectl apply -f istio-manifests/worker-virtualservice.yaml

istiowatcher डेमन लिखना

हम इस सेवा को Go में लिखेंगे, ताकि यह तेज़ी से काम करे और इसे आसानी से कहीं भी इस्तेमाल किया जा सके. ऐप्लिकेशन का पूरा फ़्लो, शुरू होने और हर सेकंड, प्रोमेथियस से क्वेरी करने के लिए होगा,

src में istiowatcher नाम की नई डायरेक्ट्री बनाएं

mkdir -p ${proj}/src/istiowatcher && cd ${proj}/src/istiowatcher

हम क्लस्टर में मौजूद Istio कंट्रोल प्लेन में बदलाव करने के लिए, अपने कंटेनर से istioctl को कॉल करेंगे.

istiowatcher.go लिखना

उस डायरेक्ट्री में istiowatcher.go नाम की फ़ाइल बनाएं और उसमें यह डालें

package main

import (
        "github.com/tidwall/gjson"
        "io/ioutil"
        "log"
        "net/http"
        "os/exec"
        "time"
)

func main() {
        //These are in requests per second
        var targetLow float64 = 10
        var targetHigh float64 = 15
        // This is for the ticker in milliseconds
        ticker := time.NewTicker(1000 * time.Millisecond)

        isBurst := false

        // Our prometheus query
        reqQuery := `/api/v1/query?query=sum(rate(istio_requests_total{reporter="destination",destination_service="worker-service.default.svc.cluster.local",source_workload="frontend-deployment"}[15s]))by(source_workload,source_app,destination_service)`

        for t := range ticker.C {
                log.Printf("Checking Prometheus at %v", t)

                // Check prometheus
                // Note that b/c we are querying over the past 5 minutes, we are getting a very SLOW ramp of our reqs/second
                // If we wanted this to be a little "snappier" we can scale it down to say 30s
                resp, err := http.Get("http://prometheus.istio-system.svc.cluster.local:9090" + reqQuery)
                if err != nil {
                        log.Printf("Error: %v", err)
                        continue
                }
                defer resp.Body.Close()
                body, _ := ioutil.ReadAll(resp.Body)

                val := gjson.Get(string(body), "data.result.0.value.1")
                log.Printf("Value: %v", val)

                currentReqPerSecond := val.Float()
                log.Printf("Reqs per second %f", currentReqPerSecond)

                if currentReqPerSecond > targetHigh && !isBurst {
                        applyIstio("burst.yaml")
                        log.Println("Entering burst mode")
                        isBurst = true
                } else if currentReqPerSecond < targetLow && isBurst {
                        applyIstio("natural.yaml")
                        log.Println("Returning to natural state.")
                        isBurst = false
                }
        }
}

func applyIstio(filename string) {
        cmd := exec.Command("istioctl", "replace", "-f", filename)
        if err := cmd.Run(); err != nil {
                log.Printf("Error hit applying istio manifests: %v", err)
        }
}

Dockerfile लिखना

Dockerfile नाम की एक नई फ़ाइल बनाएं और इसमें यह डालें.

FROM golang:1.11.2-stretch as base

FROM base as builder

WORKDIR /workdir
RUN curl -LO https://github.com/istio/istio/releases/download/1.0.0/istio-1.0.0-linux.tar.gz
RUN tar xzf istio-1.0.0-linux.tar.gz
RUN cp istio-1.0.0/bin/istioctl ./istioctl

FROM base 

WORKDIR /go/src/istiowatcher
COPY . .
COPY --from=builder /workdir/istioctl /usr/local/bin/istioctl

RUN go get -d -v ./...
RUN go install -v ./...

CMD ["istiowatcher"]

यह मल्टी-स्टेज Dockerfile, पहले चरण में Istio की 1.0.0 रिलीज़ को डाउनलोड और निकालता है. दूसरा चरण, हमारी डायरेक्ट्री से सब कुछ इमेज में कॉपी करता है. इसके बाद, बिल्ड स्टेज से istioctl को /usr/local/bin में कॉपी करता है, ताकि हमारे ऐप्लिकेशन से इसे कॉल किया जा सके. साथ ही, यह डिपेंडेंसी पाता है, कोड को कंपाइल करता है, और CMD को "istiowatcher" पर सेट करता है

burst.yaml लिखना

यह वह फ़ाइल है जो frontend से worker पर एक सेकंड में किए गए अनुरोधों की संख्या 15 से ज़्यादा होने पर लागू होगी.istiowatcher

burst.yaml नाम की एक नई फ़ाइल बनाएं और इसमें यह डालें.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: worker-virtual-service
spec:
 hosts:
 - worker-service
 gateways:
 - mesh
 http:
 - route:
   - destination:
       host: worker-service.default.svc.cluster.local   
       subset: primary
       port:
         number: 80       
     weight: 0
   - destination:
       host: worker-service.default.svc.cluster.local    
       subset: burst 
       port:
         number: 80       
     weight:  100

natural.yaml लिखना

हम इसे "सामान्य" स्थिति मानेंगे. जब frontend से worker तक के अनुरोध/सेकंड की संख्या 10 से कम हो जाएगी, तब हम इस स्थिति पर वापस आ जाएंगे. इस स्थिति में, 100% ट्रैफ़िक को primary क्लस्टर पर भेजा जा रहा है.

natural.yaml नाम की एक नई फ़ाइल बनाएं और उसमें यह टेक्स्ट डालें

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
 name: worker-virtual-service
spec:
 hosts:
 - worker-service
 gateways:
 - mesh
 http:
 - route:
   - destination:
       host: worker-service.default.svc.cluster.local   
       subset: primary
       port:
         number: 80       
     weight: 100
   - destination:
       host: worker-service.default.svc.cluster.local    
       subset: burst 
       port:
         number: 80       
     weight: 0

istiowatcher को बनाना और उसे Push करना

मौजूदा डायरेक्ट्री को Google Cloud Build (GCB) में भेजने के लिए, यह कमांड चलाएं. इससे GCR में इमेज बन जाएगी और उसे टैग कर दिया जाएगा.

gcloud builds submit -t gcr.io/${GCLOUD_PROJECT}/istiowatcher

istiowatcher को डिप्लॉय करना

हमारी kubernetes डायरेक्ट्री पर स्विच करना

cd ${proj}/kubernetes/

डिप्लॉयमेंट फ़ाइल लिखना: istiowatcher.yaml

istiowatcher.yaml नाम की फ़ाइल बनाएं और इसमें यह डालें (<your-project-id> की जगह अपना प्रोजेक्ट आईडी डालें).

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: istiowatcher-deployment
  labels:
    app: istiowatcher
spec:
  replicas: 1
  selector:
    matchLabels:
      app: istiowatcher
  template:
    metadata:
      labels:
        app: istiowatcher
    spec:
      serviceAccountName: istio-pilot-service-account
      automountServiceAccountToken: true
      containers:
      - name: istiowatcher
        image: gcr.io/<your-project-id>/istiowatcher
        imagePullPolicy: Always

डिप्लॉय करना

पक्का करें कि हम प्राइमरी क्लस्टर में चल रहे हैं

kubectx primary

istio-system नेमस्पेस में istiowatcher.yaml डिप्लॉय करना

kubectl apply -n istio-system -f istiowatcher.yaml

yaml में serviceAccountName और automountServiceAccountToken निर्देशों का ध्यान रखना ज़रूरी है. इससे हमें क्लस्टर में istioctl चलाने के लिए ज़रूरी क्रेडेंशियल मिलते हैं.

हमें इसे istio-system नेमस्पेस में भी डिप्लॉय करना होगा, ताकि यह पक्का किया जा सके कि हमारे पास istio-pilot-service-account के क्रेडेंशियल हैं. (यह default नेमस्पेस में मौजूद नहीं है).

देखें कि ट्रैफ़िक अपने-आप कैसे स्विच हो जाता है!

अब खास पल का आनंद लें! आइए, हम अपने फ़्रंटएंड पर जाएं और हर सेकंड के अनुरोधों की संख्या को 20 तक बढ़ाएं

ध्यान दें कि इसमें कुछ सेकंड लगते हैं, लेकिन हम इसे बढ़ा देते हैं और हमारे सभी हैश में "bursty-" प्रीफ़िक्स होता है!

ऐसा इसलिए है, क्योंकि हम 15s रेंज में prometheus का सैंपलिंग कर रहे हैं. इस वजह से, हमारे जवाब में थोड़ी देरी हो रही है. अगर हमें ज़्यादा सटीक बैंड चाहिए, तो हम अपनी क्वेरी को prometheus में बदलकर 5s.

18. आगे क्या करना है?

क्लीनअप

अगर इस वर्कशॉप के लिए दिए गए अस्थायी खाते का इस्तेमाल किया जा रहा है, तो आपको खाते से डेटा मिटाने की ज़रूरत नहीं है.

GCR में अपने Kubernetes क्लस्टर, फ़ायरवॉल नियम, और इमेज मिटाई जा सकती हैं

gcloud container clusters delete primary --zone=us-west1-a

gcloud container clusters delete burst --zone=us-west1-a

gcloud compute firewall-rules delete istio-multicluster-test-pods 

gcloud container images delete gcr.io/$GCLOUD_PROJECT/istiowatcher

आने वाले समय में