क्लस्टर के बीच वर्कलोड को "बर्स्ट" करने के लिए, 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) API चालू करें:

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. "primary" 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 के नामों में बदलाव करना

इस निर्देश से, burst में बनाई गई kubeconfig एंट्री में बदलाव होगा

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 Multicluster

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

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

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

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

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

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

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

Worker

वर्कर ऐप्लिकेशन को NodeJS में लिखा गया है. यह आने वाले POST HTTP अनुरोधों को सुनेगा, उन पर हैशिंग ऑपरेशन करेगा, और अगर 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 Services हैं. नीले रंग से आउटलाइन किए गए बॉक्स, Kubernetes Deployments हैं. पीले बॉक्स से पता चलता है कि हमने Istio इंस्टॉल कर लिया है.

561db37c510944bd.png

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

फ़ाइनल ऐप्लिकेशन में, primary नाम के istiowatcher. क्लस्टर में एक और डिप्लॉयमेंट चल रहा होगा. इससे हमें ट्रैफ़िक को 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 Multicluster पर ट्रैफ़िक राउटिंग करेंगे

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 Cache डिप्लॉय करना
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

जब सभी पॉड "Running" स्थिति में हों, तब 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 Traffic Management की मदद से, हमारे ऐप्लिकेशन को डिप्लॉय करना

Istio Traffic Management की कॉन्फ़िगरेशन फ़ाइलें बनाना

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 Cache डिप्लॉय करना
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 Remote, प्राइमरी क्लस्टर के साथ कम्यूनिकेट करने के लिए करता है.

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 Remote इंस्टॉल करना

हमारे 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 लेबल है.

इससे हमारे ट्रैफ़िक को दोनों क्लस्टर के बीच आधा-आधा बांट दिया जाता है.

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

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 Ingress पॉइंट पर जाएं. देखें कि करीब 50% हैश के आगे "burst-" प्रीफ़िक्स लगा है.

78fb6e235e9f4a07.png

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

16. Prometheus मेट्रिक का इस्तेमाल करना

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

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

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

601e1155a825e0c2.png

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

Prometheus मेट्रिक के बारे में जानकारी

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

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

b4a7a3cd67db05b3.png

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

c04a482e55bdfd41.png

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

d5af3ba22a7a6ebb.png

इसके बाद, "Expose" चुनें

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

एंडपॉइंट के चालू होने का इंतज़ार करें. इसके बाद, "External endpoints" के बगल में मौजूद आईपी पते पर क्लिक करें 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 पर आने वाले सभी ट्रैफ़िक को 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

Apply istio-manifests/worker-virtualservice.yaml

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

istiowatcher डेमॉन लिखें

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

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

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

हम अपने कंटेनर से istioctl को कॉल करेंगे, ताकि क्लस्टर में Istio कंट्रोल प्लैन को मैनेज किया जा सके.

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 फ़ाइल लिखना

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

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 को बनाना और पुश करना

मौजूदा डायरेक्ट्री को Google Cloud Build (GCB) पर भेजने के लिए, यहां दिया गया तरीका अपनाएं. इससे 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 में बदलकर 5s. कर सकते हैं

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

सफ़ाई

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

आपके पास Kubernetes क्लस्टर, फ़ायरवॉल का नियम, और GCR में मौजूद इमेज मिटाने का विकल्प होता है

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

आगे की कार्रवाई