Anthos सर्विस मेश वर्कशॉप: लैब गाइड

1. अल्फ़ा वर्कशॉप

ज़रूरी जानकारी: यह एक ऐल्फ़ा वर्कशॉप है और इसका मकसद, क्लासरूम में पढ़ाने के लिए गुरुओं की ट्रेनिंग लेना है.

वर्कशॉप कोडलैब का लिंक bit.ly/asm-workshop

2. खास जानकारी

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

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

एजेंडा

• मॉड्यूल 0 - परिचय और प्लैटफ़ॉर्म सेटअप
• जानकारी और आर्किटेक्चर
• सर्विस मेश और Istio/ASM के बारे में जानकारी
• लैब: इंफ़्रास्ट्रक्चर सेटअप: उपयोगकर्ता का वर्कफ़्लो
• ब्रेक
• QnA
• मॉड्यूल 1 - ASM की मदद से ऐप्लिकेशन इंस्टॉल करें, सुरक्षित रखें, और उन्हें मॉनिटर करें
• रेपो मॉडल: इंफ़्रास्ट्रक्चर और Kubernetes repos के बारे में जानकारी
• लैब: सैंपल ऐप्लिकेशन डिप्लॉय करना
• डिस्ट्रिब्यूटेड सेवाएं और निगरानी करने की सुविधा
• लंच
• लैब: स्टैकड्राइवर की मदद से निगरानी करने की क्षमता
• QNA
• मॉड्यूल 2 - DevOps - कैनरी को रोल आउट करना, नीति/आरबीएसी
• मल्टी क्लस्टर सेवा की खोज और सुरक्षा/नीति
• लैब: म्युचुअल TLS
• कैनरी डिप्लॉयमेंट
• लैब: कैनरी डिप्लॉयमेंट
• सुरक्षित मल्टी क्लस्टर ग्लोबल लोड बैलेंसिंग
• ब्रेक
• लैब: अनुमति देने से जुड़ी नीति
• QNA
• मॉड्यूल 3 - इंफ़्रास्ट्रक्चर ऑपरेशन - प्लैटफ़ॉर्म अपग्रेड
• डिस्ट्रिब्यूटेड सर्विस के लिए बिल्डिंग ब्लॉक
• लैब: इंफ़्रास्ट्रक्चर स्केलिंग
• अगले चरण

स्लाइड

इस वर्कशॉप की स्लाइड यहां दिए गए लिंक पर पाएं:

एएसएम वर्कशॉप स्लाइड

ज़रूरी शर्तें

इस वर्कशॉप में आगे बढ़ने से पहले, आपको ये शर्तें पूरी करनी होंगी:

1. GCP संगठन नोड
2. बिलिंग खाता आईडी (इस बिलिंग खाते के लिए, आपका उपयोगकर्ता बिलिंग एडमिन होना चाहिए)
3. आपके उपयोगकर्ता के लिए, संगठन के लेवल पर संगठन के एडमिन की आईएएम की भूमिका

3. इन्फ़्रास्ट्रक्चर सेटअप - एडमिन वर्कफ़्लो

वर्कशॉप बनाने वाला एडमिन, इस सेक्शन में बताए गए चरणों को पूरा करता है.

अगर आप वर्कशॉप करते हैं, तो Infrastructure Setup - User Workflow लेबल वाले अगले सेक्शन पर जाएं

बूटस्ट्रैप वर्कशॉप स्क्रिप्ट के बारे में जानकारी

bootstrap_workshop.sh नाम की स्क्रिप्ट का इस्तेमाल, वर्कशॉप के लिए शुरुआती एनवायरमेंट को सेट अप करने के लिए किया जाता है. अगर आपने यह वर्कशॉप कई उपयोगकर्ताओं को ट्रेनिंग के तौर पर दी है, तो इस स्क्रिप्ट का इस्तेमाल अपने लिए एक एनवायरमेंट या कई उपयोगकर्ताओं के लिए कई एनवायरमेंट सेट अप करने के लिए किया जा सकता है.

बूटस्ट्रैप वर्कशॉप स्क्रिप्ट को इनपुट के तौर पर इनकी ज़रूरत होती है:

• संगठन का नाम (उदाहरण के लिए, yourcompany.com)- यह वह संगठन है जिसमें वर्कशॉप के लिए एनवायरमेंट बनाए जाते हैं.
• बिलिंग आईडी (उदाहरण के लिए, 12345-12345-12345) - वर्कशॉप के दौरान इस्तेमाल किए गए सभी संसाधनों का बिल भेजने के लिए, इस बिलिंग आईडी का इस्तेमाल किया जाता है.
• वर्कशॉप का नंबर (उदाहरण के लिए, 01) - दो अंकों वाला नंबर. इसका इस्तेमाल तब किया जाता है, जब आप एक दिन में कई वर्कशॉप कर रहे होते हैं और उनकी अलग-अलग जानकारी रखना चाहते हैं. वर्कशॉप नंबर का इस्तेमाल, प्रोजेक्ट आईडी हासिल करने के लिए भी किया जाता है. वर्कशॉप के लिए अलग-अलग नंबर होने से, यह पक्का करने में मदद मिलती है कि आपको हर बार यूनीक प्रोजेक्ट आईडी मिलें. वर्कशॉप नंबर के अलावा, प्रोजेक्ट आईडी के लिए मौजूदा तारीख (YYMMDD के फ़ॉर्मैट में) का भी इस्तेमाल किया जाता है. तारीख और वर्कशॉप की संख्या के कॉम्बिनेशन से, यूनीक प्रोजेक्ट आईडी मिलते हैं.
• उपयोगकर्ता का नंबर (उदाहरण के लिए, 1) - यह नंबर, वर्कशॉप में शामिल पहले उपयोगकर्ता के बारे में बताता है. उदाहरण के लिए, अगर आपको 10 उपयोगकर्ताओं के लिए वर्कशॉप बनानी है, तो शुरुआती उपयोगकर्ता की संख्या 1 और असली उपयोगकर्ताओं की संख्या 10 हो सकती है.
• असली उपयोगकर्ता का नंबर (उदाहरण के लिए, 10) - यह नंबर वर्कशॉप में शामिल आखिरी उपयोगकर्ता के बारे में बताता है. उदाहरण के लिए, अगर आपको 10 उपयोगकर्ताओं के लिए वर्कशॉप बनानी है, तो शुरुआती उपयोगकर्ता की संख्या 1 और असली उपयोगकर्ताओं की संख्या 10 हो सकती है. उदाहरण के लिए, अगर आपको सिर्फ़ एक एनवायरमेंट सेट अप करना है, तो शुरुआती और असली उपयोगकर्ता का नंबर एक जैसा रखें. इससे एक एनवायरमेंट बन जाएगा.

प्रोजेक्ट आईडी में, तारीख और वर्कशॉप के नंबर के अलावा, शुरू और असली उपयोगकर्ताओं के नंबर भी शामिल होते हैं. वर्कशॉप में परफ़ॉर्म करने वाले उपयोगकर्ताओं के लिए यूज़र आईडी, शुरुआती और असली उपयोगकर्ता की संख्या से लिए जाते हैं. यूज़र आईडी की जानकारी User schema and permissions performing the workshop सेक्शन में दी गई है.

• एडमिन GCS बकेट (उदाहरण के लिए, my-gcs-bucket-name) - वर्कशॉप से जुड़ी जानकारी स्टोर करने के लिए GCS बकेट का इस्तेमाल किया जाता है. इस जानकारी का इस्तेमाल cleanup_workshop.sh स्क्रिप्ट से किया जाता है, ताकि बूटस्ट्रैप वर्कशॉप स्क्रिप्ट के दौरान बनाए गए सभी संसाधनों को अच्छी तरह मिटाया जा सके. वर्कशॉप बनाने वाले एडमिन के पास, इस बकेट के लिए पढ़ने/लिखने की अनुमतियां होनी चाहिए.

बूटस्ट्रैप वर्कशॉप स्क्रिप्ट ऊपर दी गई वैल्यू का इस्तेमाल करती है और एक रैपर स्क्रिप्ट की तरह काम करती है, जो setup-terraform-admin-project.sh स्क्रिप्ट को कॉल करती है. सेटअप-terraform-admin-project.sh स्क्रिप्ट किसी एक उपयोगकर्ता के लिए वर्कशॉप एनवायरमेंट बनाती है.

वर्कशॉप की बूटस्ट्रैप करने के लिए एडमिन की अनुमतियां ज़रूरी हैं

इस वर्कशॉप में दो तरह के उपयोगकर्ता शामिल होते हैं. एक ADMIN_USER, जो इस वर्कशॉप के लिए संसाधन बनाता और मिटाता है. दूसरी MY_USER है, जो वर्कशॉप के चरणों को पूरा करती है. MY_USER के पास सिर्फ़ अपने संसाधनों का ऐक्सेस होता है. ADMIN_USER के पास सभी उपयोगकर्ताओं के सेटअप का ऐक्सेस होता है. अगर आपको यह सेटअप अपने लिए बनाना है, तो ADMIN_USER और MY_USER एक ही हैं. अगर आप एक शिक्षक हैं और एक से ज़्यादा छात्र-छात्राओं के लिए इस वर्कशॉप को बना रहे हैं, तो आपका ADMIN_USER और MY_USER अलग-अलग होगा.

ADMIN_USER के लिए, संगठन के लेवल की इन अनुमतियों की ज़रूरत होती है:

• मालिक - संगठन के सभी प्रोजेक्ट के लिए प्रोजेक्ट के मालिक की अनुमति.
• फ़ोल्डर एडमिन - संगठन में फ़ोल्डर बनाने और मिटाने की सुविधा. हर उपयोगकर्ता को एक फ़ोल्डर मिलता है, जिसमें प्रोजेक्ट में मौजूद उनके सभी संसाधन होते हैं.
• संगठन का एडमिन
• प्रोजेक्ट क्रिएटर - संगठन में प्रोजेक्ट बनाने की सुविधा.
• प्रोजेक्ट डिलीटर - संगठन में प्रोजेक्ट मिटाने की सुविधा.
• प्रोजेक्ट आईएएम एडमिन - संगठन के सभी प्रोजेक्ट में IAM नियम बनाने की सुविधा.

इनके अलावा, ADMIN_USER को वर्कशॉप के लिए इस्तेमाल किए जाने वाले बिलिंग आईडी के लिए, बिलिंग एडमिन भी होना चाहिए.

वर्कशॉप के लिए उपयोगकर्ता का स्कीमा और अनुमतियां

अगर आपको अपने संगठन के उपयोगकर्ताओं के लिए यह वर्कशॉप बनानी है, तो आपको MY_USERs के लिए, उपयोगकर्ताओं का नाम रखने की खास स्कीम को फ़ॉलो करना होगा. बूटस्ट्रैप_वर्कशॉप.श स्क्रिप्ट के दौरान, आप एक स्टार्ट और असली उपयोगकर्ता नंबर देते हैं. इन नंबरों का इस्तेमाल, ये उपयोगकर्ता नाम बनाने के लिए किया जाता है:

• user<3 digit user number>@<organization_name>

उदाहरण के लिए, अगर आपने स्टार्ट यूज़र नंबर एक और असली उपयोगकर्ता की संख्या 3 के साथ बूटस्ट्रैप वर्कशॉप स्क्रिप्ट चलाया है, तो आपके संगठन में yourcompany.com नाम का इस्तेमाल किया जाता है, तो इन उपयोगकर्ताओं के लिए वर्कशॉप एनवायरमेंट बन जाते हैं:

• [e-mail]
• [e-mail]
• [e-mail]

इन उपयोगकर्ता नामों को setup_terraform_admin_project.sh स्क्रिप्ट के दौरान बनाए गए खास प्रोजेक्ट के लिए, प्रोजेक्ट के मालिक की भूमिकाएं असाइन की जाती हैं. बूटस्ट्रैप स्क्रिप्ट का इस्तेमाल करते समय, आपको उपयोगकर्ता के इस नाम के स्कीमा का पालन करना होगा. G Suite में एक साथ कई उपयोगकर्ताओं को जोड़ने का तरीका जानें.

वर्कशॉप के लिए ज़रूरी टूल

इस वर्कशॉप का मकसद, Cloud Shell से बूटस्ट्रैप करना है. इस वर्कशॉप के लिए इन टूल की ज़रूरत है.

• gcloud (ver >= 270)
• kubectl
• sed (यह Cloud Shell/Linux पर sed के साथ काम करता है, Mac OS पर नहीं)
• git (पक्का करें कि आप अप-टू-डेट हों)
• sudo apt update
• sudo apt install git
• जेक्यू
• envsubst
• kustomize

kustomize को छोड़कर सभी टूल, Cloud Shell में डिफ़ॉल्ट रूप से पहले से इंस्टॉल होते हैं. अगर kustomize इंस्टॉल नहीं किया गया है, तो ऊपर दिए गए लिंक में दी गई बैश स्क्रिप्ट का इस्तेमाल करके, इसे इंस्टॉल करें. साथ ही, पक्का करें कि आपके PATH में kustomize बाइनरी है और Cloud Shell में kustomize कमांड चलाकर इसकी पुष्टि करें.

अपने लिए वर्कशॉप सेट अप करना (एक उपयोगकर्ता के लिए सेटअप)

1. Cloud Shell खोलें और क्लाउड शेल में नीचे दी गई सभी कार्रवाइयां करें. नीचे दिए गए लिंक पर क्लिक करें.

क्लाउड शेल

2. पुष्टि करें कि आपने gcloud में सही एडमिन उपयोगकर्ता से लॉग इन किया है.

gcloud config list
 

3. WORKDIR बनाएं और वर्कशॉप रेपो का क्लोन बनाएं.

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

4. वर्कशॉप में इस्तेमाल करने के लिए, अपने संगठन का नाम, बिलिंग आईडी, वर्कशॉप नंबर, और एडमिन GCS बकेट तय करें. ऊपर दिए गए सेक्शन में, वर्कशॉप सेट अप करने के लिए ज़रूरी अनुमतियां देखें.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<ADMIN_BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

5. बूटस्ट्रैप_वर्कशॉप.sh स्क्रिप्ट चलाएं. इस स्क्रिप्ट को पूरा होने में कुछ मिनट लग सकते हैं.

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --set-up-for-admin 
 

ध्यान दें कि आपको शुरुआती और असली उपयोगकर्ता का नंबर तय करने की ज़रूरत नहीं है, क्योंकि इसे अपने लिए सेट अप किया जा रहा है.

बूटस्ट्रैप_वर्कशॉप.श स्क्रिप्ट के पूरा होने के बाद, संगठन के हर उपयोगकर्ता के लिए एक GCP फ़ोल्डर बनाया जाता है. फ़ोल्डर में, एक terraform admin प्रोजेक्ट बनाया जाता है. इस वर्कशॉप के लिए ज़रूरी GCP संसाधन बनाने के लिए, टेराफ़ॉर्म एडमिन प्रोजेक्ट का इस्तेमाल किया जाता है. टेराफ़ॉर्म एडमिन प्रोजेक्ट में, ज़रूरी एपीआई चालू किए गए हैं. टेराफ़ॉर्म प्लान लागू करने के लिए, Cloud Build का इस्तेमाल किया जाता है. Cloud Build के सेवा खाते को सही IAM भूमिकाएं असाइन की जाती हैं, ताकि वह GCP पर संसाधन बना सके. आखिर में, सभी GCP संसाधनों के लिए टेराफ़ॉर्म स्टेट को स्टोर करने के लिए, Google Cloud Storage (GCS) बकेट में रिमोट बैकएंड कॉन्फ़िगर किया जाता है.

terraform admin प्रोजेक्ट में Cloud Build के टास्क देखने के लिए, आपके पास टेराफ़ॉर्म एडमिन प्रोजेक्ट आईडी होना चाहिए. इसे आपकी एएसएम डायरेक्ट्री में, vars/vars.sh फ़ाइल में सेव किया जाता है. यह डायरेक्ट्री सिर्फ़ तब सेव की जाती है, जब एडमिन के तौर पर अपने लिए वर्कशॉप सेट अप की जा रही हों.

6. एनवायरमेंट वैरिएबल सेट करने के लिए, वैरिएबल फ़ाइल को सोर्स करें

echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
source $WORKDIR/asm/vars/vars.sh 
 

एक से ज़्यादा उपयोगकर्ताओं के लिए वर्कशॉप सेट अप करना (एक से ज़्यादा उपयोगकर्ताओं के लिए सेटअप)

7. Cloud Shell खोलें और क्लाउड शेल में नीचे दी गई सभी कार्रवाइयां करें. नीचे दिए गए लिंक पर क्लिक करें.

क्लाउड शेल

8. पुष्टि करें कि आपने gcloud में सही एडमिन उपयोगकर्ता से लॉग इन किया है.

gcloud config list
 

9. WORKDIR बनाएं और वर्कशॉप रेपो का क्लोन बनाएं.

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

10. वर्कशॉप में इस्तेमाल करने के लिए, अपने संगठन का नाम, बिलिंग आईडी, वर्कशॉप नंबर, शुरू और असली उपयोगकर्ता का नंबर, और एक एडमिन GCS बकेट तय करें. ऊपर दिए गए सेक्शन में, वर्कशॉप सेट अप करने के लिए ज़रूरी अनुमतियां देखें.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export START_USER_NUMBER=<number for example 1>

export END_USER_NUMBER=<number greater or equal to START_USER_NUM>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

11. बूटस्ट्रैप_वर्कशॉप.sh स्क्रिप्ट चलाएं. इस स्क्रिप्ट को पूरा होने में कुछ मिनट लग सकते हैं.

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --start-user-num ${START_USER_NUMBER} --end-user-num ${END_USER_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET}
 

12. टेराफ़ॉर्म प्रोजेक्ट आईडी वापस पाने के लिए, एडमिन GCS बकेट से वर्कशॉप.txt फ़ाइल लें.

export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .
 

4. लैब का सेटअप और तैयारी

वर्कशॉप में हिस्सा लेने वाले लोग यहां से शुरू करते हैं. Chrome या Firefox में INCOGNITO विंडो से सभी चरण पूरे करें.

अपना लैब पाथ चुनें

इस वर्कशॉप में शामिल लैब का इस्तेमाल, इन दो में से किसी एक तरीके से किया जा सकता है:

• "आसान फ़ास्ट ट्रैक इंटरैक्टिव स्क्रिप्ट" रास्ता
• "हर निर्देश को मैन्युअल तरीके से कॉपी करके चिपकाएं" रास्ता

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

फ़ास्ट ट्रैक स्क्रिप्ट हर लैब के ऊपर हरे रंग के बॉक्स में दिखेंगी.

फ़ास्ट ट्रैक स्क्रिप्ट

${WORKDIR}/asm/fasttrack_scripts/<name_of_script>.sh

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

लैब का इस्तेमाल करते समय, कृपया दोनों में से कोई एक तरीका चुनें.

कोई तरीका चुनने और उस तरीके के चरणों को पूरा करने के बाद, दूसरे तरीके का इस्तेमाल न करें.

फ़ास्ट ट्रैक स्क्रिप्ट सेटअप

फ़ास्ट ट्रैक स्क्रिप्ट पूरी करने के बाद, आपको उस लैब का काम पूरा करना होगा. 'कॉपी करके चिपकाएं' लैब के निर्देशों में बताए गए तरीके न अपनाएं.

उपयोगकर्ता की जानकारी पाएं

यह वर्कशॉप, उस अस्थायी उपयोगकर्ता खाते (या लैब खाते) का इस्तेमाल करके की जाती है जिसे वर्कशॉप के एडमिन ने बनाया है. वर्कशॉप के सभी प्रोजेक्ट का मालिकाना हक, लैब खाते के पास होता है. वर्कशॉप का एडमिन, वर्कशॉप करने वाले उपयोगकर्ता को लैब खाते के क्रेडेंशियल (उपयोगकर्ता नाम और पासवर्ड) उपलब्ध कराता है. उपयोगकर्ता के सभी प्रोजेक्ट के आगे लैब खाते के उपयोगकर्ता नाम का इस्तेमाल किया जाता है. उदाहरण के लिए, लैब खाते [e-mail] के लिए, टेराफ़ॉर्म एडमिन प्रोजेक्ट आईडी user001-200131-01-tf-abcde होगा. बाकी प्रोजेक्ट के लिए भी ऐसा ही होगा. हर उपयोगकर्ता को वर्कशॉप के एडमिन के उपलब्ध कराए गए लैब खाते से लॉग इन करना होगा. इसके बाद, लैब खाते का इस्तेमाल करके वर्कशॉप करनी होगी.

अपना कॉर्पोरेट ईमेल पता देखें. यह वही ईमेल पता है जिसका इस्तेमाल आपने वर्कशॉप में रजिस्टर करने के लिए किया था. आपको वर्कशॉप के एडमिन से एक ईमेल मिला होगा. इसमें लैब खाते के क्रेडेंशियल (जैसे, उपयोगकर्ता नाम और पासवर्ड) के साथ दिया गया था. ईमेल ऐसा दिखता है.

1. नीचे दिए गए लिंक पर क्लिक करके Cloud Shell खोलें.

क्लाउड शेल

2. लैब खाते के क्रेडेंशियल से लॉग इन करें. अपने कॉर्पोरेट या निजी खाते से लॉग इन न करें. Lab खाता userXYZ@<workshop_domain>.com जैसा दिखता है.
3. यह एक नया खाता है, इसलिए आपको Google की सेवा की शर्तें स्वीकार करने के लिए कहा जाएगा. 'स्वीकार करें' पर क्लिक करें.

4. अगली स्क्रीन में, Google की सेवा की शर्तों से सहमत होने के लिए चेकबॉक्स को चुनें और Start Cloud Shell पर क्लिक करें.

इस चरण में एक छोटा Linux Debian VM उपलब्ध कराया जाता है, ताकि आप GCP के संसाधनों को ऐक्सेस कर सकें. हर खाते को एक Cloud Shell वीएम मिलती है. Lab खाते के प्रावधानों के साथ लॉग इन करें और लैब खाते के क्रेडेंशियल का इस्तेमाल करके, आपको लॉग इन करें. Cloud Shell के साथ-साथ, कोड एडिटर की सुविधा भी उपलब्ध है. इससे, कॉन्फ़िगरेशन फ़ाइलों (टेराफ़ॉर्म, YAML वगैरह) में आसानी से बदलाव किए जा सकते हैं. डिफ़ॉल्ट रूप से, Cloud Shell की स्क्रीन, Cloud Shell शेल एनवायरमेंट (सबसे नीचे) और क्लाउड कोड एडिटर (सबसे ऊपर) में बंट जाती है. पेंसिल और शेल प्रॉम्प्ट आइकॉन, जो सबसे ऊपर दाएं कोने में आपको दोनों (शेल और कोड एडिटर) के बीच टॉगल करने की सुविधा देता है. बीच वाले सेपरेटर बार को ऊपर या नीचे खींचकर छोड़ा जा सकता है और हर विंडो का साइज़ मैन्युअल तरीके से भी बदला जा सकता है. 5. इस वर्कशॉप के लिए WorkDIR बनाएं. WorkDIR एक ऐसा फ़ोल्डर है जिससे आप इस वर्कशॉप के लिए सभी लैब का काम करते हैं. WorkDIR बनाने के लिए क्लाउड शेल में निम्न आदेश चलाएं.

mkdir -p ${HOME}/asm-workshop
cd ${HOME}/asm-workshop
export WORKDIR=`pwd` 
 

6. लैब खाते के उपयोगकर्ता को वैरिएबल के तौर पर एक्सपोर्ट करें, ताकि इस वर्कशॉप के लिए इसका इस्तेमाल किया जा सके. यह वही खाता है जिससे आपने Cloud Shell में लॉग इन किया है.

export MY_USER=<LAB ACCOUNT EMAIL PROVIDED BY THE WORKSHOP ADMIN>
# For example export MY_USER=[e-mail] 
 

ध्यान दें: अगर आप एडमिन हैं और आपने "-suFA" का इस्तेमाल करके अपने लिए वर्कशॉप सेट अप की है या "–एडमिन के लिए सेटअप" फ़्लैग करने के बाद, MY_USER को उस GCP खाते के ईमेल पर सेट कर दिया जाता है जिसका इस्तेमाल आपने वर्कशॉप प्रोजेक्ट बनाने के लिए किया था.

7. WorkDIR और MY_USER वैरिएबल को इको करें, ताकि यह पक्का किया जा सके कि ये दोनों वैरिएबल नीचे दिए गए निर्देशों का पालन करके सही तरीके से सेट हैं.

echo "WORKDIR set to ${WORKDIR}" && echo "MY_USER set to ${MY_USER}"
 

8. वर्कशॉप रेपो का क्लोन बनाएं.

git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git ${WORKDIR}/asm
 

5. इंफ़्रास्ट्रक्चर सेटअप - उपयोगकर्ता वर्कफ़्लो

मकसद: इंफ़्रास्ट्रक्चर और Istio इंस्टॉलेशन की पुष्टि करना

• वर्कशॉप में इस्तेमाल होने वाले टूल इंस्टॉल करें
• क्लोन वर्कशॉप रेपो
• Infrastructure के इंस्टॉल की पुष्टि करें
• k8s-repo के इंस्टॉल की पुष्टि करें
• Istio इंस्टॉल करने की पुष्टि करें

फ़ास्ट ट्रैक स्क्रिप्ट

अगर यह तरीका चुना जाता है, तो इस लैब को पूरा करने के लिए, यहां दी गई स्क्रिप्ट चलाएं.

${WORKDIR}/asm/fasttrack_scripts/infrastructure-setup-user-workflow.sh

स्क्रिप्ट पूरी होने के बाद, अपने Cloud Shell सेशन में वैरिएबल अपडेट करने के लिए, अपने bashrc को सेट करें.

source ${HOME}/.bashrc

कॉपी-और-पेस्ट करने की विधि चुनने वाले लैब से जुड़े निर्देश

ज़रूरी जानकारी: अगर आपने इस लैब के लिए फ़ास्ट ट्रैक स्क्रिप्ट पहले ही पूरी कर ली है, तो कॉपी करने और चिपकाने के लिए यहां दिया गया तरीका न अपनाएं**.**

उपयोगकर्ता की जानकारी पाएं

वर्कशॉप सेट अप करने वाले एडमिन को, उपयोगकर्ता को उपयोगकर्ता नाम और पासवर्ड की जानकारी देनी होगी. उपयोगकर्ता के सभी प्रोजेक्ट के आगे उपयोगकर्ता नाम लगाएं. उदाहरण के लिए, उपयोगकर्ता [e-mail] के लिए, टेराफ़ॉर्म एडमिन प्रोजेक्ट आईडी user001-200131-01-tf-abcde होगा. बाकी प्रोजेक्ट के लिए भी ऐसा ही जारी रहेगा. हर उपयोगकर्ता के पास सिर्फ़ अपनी वर्कशॉप एनवायरमेंट का ऐक्सेस होता है.

वर्कशॉप के लिए ज़रूरी टूल

इस वर्कशॉप का मकसद, Cloud Shell से बूटस्ट्रैप करना है. इस वर्कशॉप के लिए इन टूल की ज़रूरत है.

kustomize और pv को छोड़कर, सभी टूल Cloud Shell में डिफ़ॉल्ट रूप से पहले से इंस्टॉल होते हैं. आपको नीचे दोनों को इंस्टॉल करने के निर्देश मिलेंगे.

• gcloud (ver >= 270)
• kubectl
• sed (यह Cloud Shell/Linux पर sed के साथ काम करता है, Mac OS पर नहीं)
• git (पक्का करें कि आप अप-टू-डेट हों)
• sudo apt update
• sudo apt install git
• जेक्यू
• envsubst
• kustomize
• pv

टेराफ़ॉर्म एडमिन प्रोजेक्ट को ऐक्सेस करें

बूटस्ट्रैप_वर्कशॉप.श स्क्रिप्ट के पूरा होने के बाद, संगठन के हर उपयोगकर्ता के लिए एक GCP फ़ोल्डर बनाया जाता है. फ़ोल्डर में, एक terraform admin प्रोजेक्ट बनाया जाता है. इस वर्कशॉप के लिए ज़रूरी GCP संसाधन बनाने के लिए, टेराफ़ॉर्म एडमिन प्रोजेक्ट का इस्तेमाल किया जाता है. सेटअप-terraform-admin-project.sh स्क्रिप्ट, टेराफ़ॉर्म एडमिन प्रोजेक्ट में ज़रूरी एपीआई को चालू करती है. Cloud Build का इस्तेमाल, टेरेस पर उपलब्ध प्लान लागू करने के लिए किया जाता है. स्क्रिप्ट की मदद से, Cloud Build के सेवा खाते को आईएएम की सही भूमिकाएं दी जाती हैं, ताकि वह GCP पर संसाधन बना सके. आखिर में, रिमोट बैकएंड को Google Cloud Storage (GCS) बकेट में कॉन्फ़िगर किया जाता है, ताकि सभी GCP संसाधनों के लिए टेराफ़ॉर्म स्टेट को स्टोर किया जा सके.

terraform admin प्रोजेक्ट में Cloud Build के टास्क देखने के लिए, आपके पास टेराफ़ॉर्म एडमिन प्रोजेक्ट आईडी होना चाहिए. इसे एडमिन GCS बकेट में सेव किया जाता है, जिसके बारे में बूटस्ट्रैप स्क्रिप्ट में बताया गया था. अगर एक से ज़्यादा उपयोगकर्ताओं के लिए बूटस्ट्रैप स्क्रिप्ट चलाया जाता है, तो सभी टेराफ़ॉर्म एडमिन प्रोजेक्ट आईडी GCS बकेट में होते हैं.

यह वर्कशॉप, Cloud Shell और Cloud Console में उपलब्ध होगी. INCOGNITO विंडो में इन चरणों को पूरा करें, क्योंकि लॉग इन करने के लिए आपको एक अलग उपयोगकर्ता नाम और पासवर्ड का इस्तेमाल करना होगा.

1. क्लाउड शेल खोलें (अगर यह पहले से 'लैब सेटअप और प्रेप' सेक्शन से नहीं खुला है), तो नीचे दिए गए लिंक पर क्लिक करें.

क्लाउड शेल

2. अगर $HOME/bin फ़ोल्डर में kustomize (अगर पहले से इंस्टॉल नहीं किया गया है) इंस्टॉल करें और $HOME/bin फ़ोल्डर को $PATH में जोड़ें.

mkdir -p $HOME/bin
cd $HOME/bin
curl -s "https://raw.githubusercontent.com/\
kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
cd $HOME
export PATH=$PATH:${HOME}/bin
echo "export PATH=$PATH:$HOME/bin" >> $HOME/.bashrc
 

3. pv इंस्टॉल करके उसे $HOME/bin/pv पर ले जाएं.

sudo apt-get update && sudo apt-get -y install pv
sudo mv /usr/bin/pv ${HOME}/bin/pv
 

4. बैश प्रॉम्प्ट अपडेट करें.

cp $WORKDIR/asm/scripts/krompt.bash $HOME/.krompt.bash
echo "export PATH=\$PATH:\$HOME/bin" >> $HOME/.asm-workshop.bash
echo "source $HOME/.krompt.bash" >> $HOME/.asm-workshop.bash

alias asm-init='source $HOME/.asm-workshop.bash' >> $HOME/.bashrc
echo "source $HOME/.asm-workshop.bash" >> $HOME/.bashrc
source $HOME/.bashrc
 

5. पुष्टि करें कि आपने gcloud में सही उपयोगकर्ता खाते से लॉग इन किया है.

echo "Check logged in user output from the next command is $MY_USER"
gcloud config list account --format=json | jq -r .core.account
 

6. इस निर्देश की मदद से, अपना टेराफ़ॉर्म एडमिन प्रोजेक्ट आईडी पाएं:

export TF_ADMIN=$(gcloud projects list | grep tf- | awk '{ print $1 }')
echo $TF_ADMIN
 

7. वर्कशॉप से जुड़े सभी संसाधन, टेराफ़ॉर्म एडमिन प्रोजेक्ट में GCS (जीसीएस) बकेट में स्टोर की गई vars.sh फ़ाइल में वैरिएबल के तौर पर सेव किए जाते हैं. अपने टेराफ़ॉर्म एडमिन प्रोजेक्ट के लिए vars.sh फ़ाइल पाएं.

mkdir $WORKDIR/asm/vars
gsutil cp gs://$TF_ADMIN/vars/vars.sh $WORKDIR/asm/vars/vars.sh
echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
 

8. Teraform एडमिन प्रोजेक्ट का Cloud Build पेज खोलने के लिए, दिखाए गए लिंक पर क्लिक करें और पुष्टि करें कि बिल्ड पूरा हो गया है.

source $WORKDIR/asm/vars/vars.sh
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

अगर आपने Cloud Console को पहली बार ऐक्सेस किया है, तो आपको Google की सेवा की शर्तें स्वीकार करनी होंगी.

9. अब जब आपको Cloud Build पेज दिख रहा हो, तो बाईं ओर मौजूद नेविगेशन में History लिंक पर क्लिक करें. इसके बाद, सबसे नए बिल्ड पर क्लिक करें, ताकि लागू होने वाले शुरुआती टेराफ़ॉर्म की जानकारी देखी जा सके. नीचे दिए गए संसाधन टेराफ़ॉर्म स्क्रिप्ट के हिस्से के रूप में बनाए गए हैं. ऊपर दिया गया आर्किटेक्चर डायग्राम भी देखा जा सकता है.

• संगठन में चार GCP प्रोजेक्ट दिया गया बिलिंग खाता, हर प्रोजेक्ट से जुड़ा हुआ है.
• शेयर किए गए VPC का network host project, एक प्रोजेक्ट है. इस प्रोजेक्ट में कोई अन्य संसाधन नहीं बनाया गया है.
• एक प्रोजेक्ट ops project है. इसका इस्तेमाल Istio कंट्रोल प्लेन GKE (जीकेई) क्लस्टर के लिए किया जाता है.
• दो प्रोजेक्ट, दो अलग-अलग डेवलपमेंट टीम का प्रतिनिधित्व करते हैं, जो अपनी-अपनी सेवाओं पर काम कर रही हैं.
• ops, dev1, और dev2 प्रोजेक्ट में से हर एक में दो GKE (जीकेई) क्लस्टर बनाए गए हैं.
• k8s-repo नाम का एक CSR रेपो बनाया गया है. इसमें Kubernetes मेनिफ़ेस्ट फ़ाइलों के लिए छह फ़ोल्डर हैं. हर GKE (जीकेई) क्लस्टर के लिए एक फ़ोल्डर. इस रेपो का इस्तेमाल, GitOps फ़ैशन के क्लस्टर में Kubernetes मेनिफ़ेस्ट को डिप्लॉय करने के लिए किया जाता है.
• Cloud Build ट्रिगर बनाया जाता है, ताकि जब भी k8s-repo के मास्टर ब्रांच के लिए काम किया जाए, तो वह अपने फ़ोल्डर से GKE (जीकेई) क्लस्टर में Kubernetes मेनिफ़ेस्ट फ़ाइल डिप्लॉय करे.

टेराफ़ॉर्म स्क्रिप्ट में 40 से 50 मिनट लगते हैं.

10. terraform admin project में बिल्ड पूरा होने के बाद, ऑपरेशन प्रोजेक्ट पर एक और बिल्ड शुरू हो जाएगा. ops project का Cloud Build पेज खोलने के लिए, दिखाए गए लिंक पर क्लिक करें. इसके बाद, पुष्टि करें कि k8s-रेपो Cloud Build पूरा हो गया है.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

ध्यान दें: Istio इंस्टॉलेशन की पुष्टि करने से पहले, इस बिल्ड को पूरा करना ज़रूरी है.

इंस्टॉल हो जाने की पुष्टि करें

11. सभी क्लस्टर के लिए, kubeconfig फ़ाइलें बनाएं. नीचे दी गई स्क्रिप्ट चलाएं.

$WORKDIR/asm/scripts/setup-gke-vars-kubeconfig.sh
 

यह स्क्रिप्ट gke फ़ोल्डर में kubemesh नाम की एक नई kubeconfig फ़ाइल बनाती है.

12. नई kubeconfig फ़ाइल पर ले जाने के लिए KUBECONFIG वैरिएबल को बदलें.

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

13. Cloud Shell में मौजूद .bashrc में vars.sh और KUBECONFIG var को जोड़ें. इससे Cloud Shell के रीस्टार्ट होने पर हर बार यह कोड जनरेट होगा.

echo "source ${WORKDIR}/asm/vars/vars.sh" >> $HOME/.bashrc
echo "export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh" >> $HOME/.bashrc
 

14. अपने क्लस्टर के कॉन्टेक्स्ट की सूची बनाएं. आपको छह क्लस्टर दिखेंगे.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_tf05-01-ops_us-central1_gke-asm-2-r2-prod
gke_tf05-01-ops_us-west1_gke-asm-1-r1-prod
gke_tf05-02-dev1_us-west1-a_gke-1-apps-r1a-prod
gke_tf05-02-dev1_us-west1-b_gke-2-apps-r1b-prod
gke_tf05-03-dev2_us-central1-a_gke-3-apps-r2a-prod
gke_tf05-03-dev2_us-central1-b_gke-4-apps-r2b-prod

Istio इंस्टॉलेशन की पुष्टि करें

15. यह पक्का करें कि दोनों क्लस्टर में Istio इंस्टॉल किया गया हो. इसके लिए, यह देखें कि सभी पॉड चल रहे हैं या नहीं और टास्क पूरे हो गए हैं.

kubectl --context ${OPS_GKE_1} get pods -n istio-system
kubectl --context ${OPS_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-z9f98                  1/1     Running   0          6m21s
istio-citadel-568747d88-qdw64             1/1     Running   0          6m26s
istio-egressgateway-8f454cf58-ckw7n       1/1     Running   0          6m25s
istio-galley-6b9495645d-m996v             2/2     Running   0          6m25s
istio-ingressgateway-5df799fdbd-8nqhj     1/1     Running   0          2m57s
istio-pilot-67fd786f65-nwmcb              2/2     Running   0          6m24s
istio-policy-74cf89cb66-4wrpl             2/2     Running   1          6m25s
istio-sidecar-injector-759bf6b4bc-mw4vf   1/1     Running   0          6m25s
istio-telemetry-77b6dfb4ff-zqxzz          2/2     Running   1          6m24s
istio-tracing-cd67ddf8-n4d7k              1/1     Running   0          6m25s
istiocoredns-5f7546c6f4-g7b5c             2/2     Running   0          6m39s
kiali-7964898d8c-5twln                    1/1     Running   0          6m23s
prometheus-586d4445c7-xhn8d               1/1     Running   0          6m25s

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-2s8k4                  1/1     Running   0          59m
istio-citadel-568747d88-87kdj             1/1     Running   0          59m
istio-egressgateway-8f454cf58-zj9fs       1/1     Running   0          60m
istio-galley-6b9495645d-qfdr6             2/2     Running   0          59m
istio-ingressgateway-5df799fdbd-2c9rc     1/1     Running   0          60m
istio-pilot-67fd786f65-nzhx4              2/2     Running   0          59m
istio-policy-74cf89cb66-4bc7f             2/2     Running   3          59m
istio-sidecar-injector-759bf6b4bc-grk24   1/1     Running   0          59m
istio-telemetry-77b6dfb4ff-6zr94          2/2     Running   4          60m
istio-tracing-cd67ddf8-grs9g              1/1     Running   0          60m
istiocoredns-5f7546c6f4-gxd66             2/2     Running   0          60m
kiali-7964898d8c-nhn52                    1/1     Running   0          59m
prometheus-586d4445c7-xr44v               1/1     Running   0          59m

16. पक्का करें कि dev1 के दोनों क्लस्टर पर Istio इंस्टॉल किया गया हो. dev1 क्लस्टर में सिर्फ़ सिटाडेल, साइडकार-इंजेक्टर, और कोरडन ही रन करता है. इसका लक्ष्य, ops-1 क्लस्टर में एक Itio कंट्रोलप्लेन शामिल है.

kubectl --context ${DEV1_GKE_1} get pods -n istio-system
kubectl --context ${DEV1_GKE_2} get pods -n istio-system
 

17. पक्का करें कि dev2 के दोनों क्लस्टर पर Istio इंस्टॉल किया गया हो. dev2 क्लस्टर में सिर्फ़ सिटाडेल, साइडकार-इंजेक्टर, और कोरडन ही रन करता है. इसका एक Itio कंट्रोलप्लेन, ops-2 क्लस्टर में चलता है.

kubectl --context ${DEV2_GKE_1} get pods -n istio-system
kubectl --context ${DEV2_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

शेयर किए गए कंट्रोल प्लेन के लिए, सेवा खोज की पुष्टि करें

18. आप चाहें, तो पुष्टि करें कि सीक्रेट डिप्लॉय किए गए हैं.

kubectl --context ${OPS_GKE_1} get secrets -l istio/multiCluster=true -n istio-system
kubectl --context ${OPS_GKE_2} get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

For OPS_GKE_1:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      8m7s
gke-2-apps-r1b-prod   Opaque   1      8m7s
gke-3-apps-r2a-prod   Opaque   1      44s
gke-4-apps-r2b-prod   Opaque   1      43s

For OPS_GKE_2:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      40s
gke-2-apps-r1b-prod   Opaque   1      40s
gke-3-apps-r2a-prod   Opaque   1      8m4s
gke-4-apps-r2b-prod   Opaque   1      8m4s

इस वर्कशॉप में, शेयर किए गए एक ही VPC का इस्तेमाल किया जाता है, जिसमें सभी GKE (जीकेई) क्लस्टर बनाए जाते हैं. सभी क्लस्टर में सेवाएं खोजने के लिए, आपको ऑपरेशन क्लस्टर में सीक्रेट के तौर पर बनाई गई kubeconfig फ़ाइलों (हर ऐप्लिकेशन क्लस्टर के लिए) का इस्तेमाल करना होगा. पायलट इन सीक्रेट का इस्तेमाल, ऐप्लिकेशन क्लस्टर के Kube API सर्वर से क्वेरी करके सेवाएं खोजने के लिए करता है. इसके लिए, ऊपर बताए गए सीक्रेट तरीके से पुष्टि की जाती है. आपको दिख रहा होगा कि दोनों ऑपरेशन क्लस्टर, kubeconfig के बनाए गए सीक्रेट्स का इस्तेमाल करके सभी ऐप्लिकेशन क्लस्टर में पुष्टि कर सकते हैं. ऑपरेशन क्लस्टर अपने-आप सेवाएं खोज सकते हैं. इसके लिए, वे kubeconfig फ़ाइलों को सीक्रेट तरीके के तौर पर इस्तेमाल करते हैं. इसके लिए ज़रूरी है कि ऑपरेशन क्लस्टर में मौजूद पायलट के पास, अन्य सभी क्लस्टर के Kube API सर्वर का ऐक्सेस हो. अगर पायलट Kube API सर्वर तक नहीं पहुंच सकता, तो आपको रिमोट सेवाओं को मैन्युअल रूप से ServiceEntries के तौर पर जोड़ना होगा. ServiceEntries को आपकी सर्विस रजिस्ट्री में डीएनएस एंट्री के तौर पर माना जा सकता है. ServiceEntries, सेवा को तय करने के लिए, पूरी तरह क्वालिफ़ाइड डीएनएस नाम ( FQDN) और आईपी पते का इस्तेमाल करती हैं, जहां उस तक पहुंचा जा सकता है. ज़्यादा जानकारी के लिए Istio Multicluster दस्तावेज़ देखें.

6. इन्फ़्रास्ट्रक्चर रेपो के बारे में जानकारी

क्लाउड बिल्ड

वर्कशॉप के लिए GCP के संसाधन, Cloud Build और infrastructure सीएसआर डेटा स्टोर करने की दर का इस्तेमाल करके बनाए गए हैं. आपने अभी-अभी अपने लोकल टर्मिनल से बूटस्ट्रैप स्क्रिप्ट (scripts/bootstrap_workshop.sh पर मौजूद) चलाई है. बूटस्ट्रैप स्क्रिप्ट एक GCP फ़ोल्डर, टेराफ़ॉर्म एडमिन प्रोजेक्ट, और Cloud Build सेवा खाते के लिए सही IAM अनुमतियां बनाती है. टेराफ़ॉर्म एडमिन प्रोजेक्ट का इस्तेमाल, टेराफ़ॉर्म स्टेट, लॉग, और कई तरह की स्क्रिप्ट को स्टोर करने के लिए किया जाता है. इसमें infrastructure और k8s_repo सीएसआर डेटा संग्रह स्थान शामिल हैं. अगले सेक्शन में, इन भंडारों के बारे में विस्तार से बताया गया है. टेराफ़ॉर्म एडमिन प्रोजेक्ट में कोई अन्य वर्कशॉप संसाधन नहीं बनाया गया है. terraform एडमिन प्रोजेक्ट में मौजूद Cloud Build के सेवा खाते का इस्तेमाल, वर्कशॉप के लिए संसाधन बनाने में किया जाता है.

वर्कशॉप के लिए GCP के संसाधन बनाने के लिए, infrastructure फ़ोल्डर में मौजूद cloudbuild.yaml फ़ाइल का इस्तेमाल किया जाता है. यह GCP संसाधन बनाने के लिए ज़रूरी सभी टूल के साथ एक कस्टम बिल्डर इमेज बनाता है. इन टूल में gcloud SDK, terraform, और Python, git, jq जैसी अन्य सुविधाएं शामिल हैं. कस्टम बिल्डर की इमेज हर रिसॉर्स के लिए terraform plan और apply का इस्तेमाल करती है. हर संसाधन की टेराफ़ॉर्म फ़ाइलें अलग-अलग फ़ोल्डर में मौजूद होती हैं. इसकी जानकारी अगले सेक्शन में दी गई है. संसाधन एक-एक करके बनाए जाते हैं और उन्हें आम तौर पर किस क्रम में बनाया जाता है. उदाहरण के लिए, प्रोजेक्ट में संसाधन बनाए जाने से पहले GCP प्रोजेक्ट बनाया जाता है. ज़्यादा जानकारी के लिए, कृपया cloudbuild.yaml फ़ाइल देखें.

जब भी infrastructure के रेपो की नीति का पालन किया जाएगा, तब Cloud Build को ट्रिगर करना होगा. इन्फ़्रास्ट्रक्चर में किया जाने वाला कोई भी बदलाव, इन्फ़्रास्ट्रक्चर के तौर पर कोड (IaC) में सेव किया जाता है और यह डेटा स्टोर करने के लिए प्रतिबद्ध होता है. आपकी वर्कशॉप की स्थिति हमेशा इस रेपो में सेव रहती है.

फ़ोल्डर का स्ट्रक्चर - टीम, एनवायरमेंट, और संसाधन

इन्फ़्रास्ट्रक्चर रेपो, वर्कशॉप के लिए GCP इन्फ़्रास्ट्रक्चर के संसाधन सेट अप करता है. इसे फ़ोल्डर और सब-फ़ोल्डर में बांटा गया है. रेपो में मौजूद बेस फ़ोल्डर, उन team को दिखाते हैं जिनके पास खास GCP संसाधनों का मालिकाना हक है. फ़ोल्डर की अगली लेयर, टीम के लिए खास environment को दिखाती है. उदाहरण के लिए, डेवलपर, स्टेज, और प्रोडक्शन. एनवायरमेंट में फ़ोल्डर की अगली लेयर, खास resource को दिखाती है. उदाहरण के लिए,host_project, gke_clusters वगैरह. ज़रूरी स्क्रिप्ट और टेराफ़ॉर्म फ़ाइलें, रिसॉर्स फ़ोल्डर में मौजूद होती हैं.

इस वर्कशॉप में ये चार तरह की टीमें शामिल हैं:

1. इन्फ़्रास्ट्रक्चर - क्लाउड इन्फ़्रास्ट्रक्चर टीम के बारे में बताता है. दूसरी सभी टीमों के लिए, GCP के संसाधन बनाने की ज़िम्मेदारी उनकी है. वे अपने संसाधनों के लिए,terraform एडमिन प्रोजेक्ट का इस्तेमाल करते हैं. इन्फ़्रास्ट्रक्चर का रेपो, Teraform एडमिन प्रोजेक्ट में होता है. साथ ही, यह Teleraform की स्टेट फ़ाइलों (इसके बारे में नीचे बताया गया है) में भी शामिल है. ये संसाधन, बूटस्ट्रैप प्रोसेस के दौरान बैश स्क्रिप्ट से बनाए जाते हैं. ज़्यादा जानकारी के लिए, मॉड्यूल 0 - एडमिन वर्कफ़्लो देखें.
2. network - नेटवर्किंग टीम का प्रतिनिधित्व करता है. वे VPC और नेटवर्किंग संसाधनों के लिए ज़िम्मेदार हैं. उनके पास नीचे दिए गए GCP संसाधनों का मालिकाना हक है.
3. host project - शेयर किए गए VPC होस्ट प्रोजेक्ट की जानकारी देता है.
4. shared VPC - शेयर किए गए VPC, सबनेट, सेकंडरी आईपी रेंज, रूट, और फ़ायरवॉल के नियमों को दिखाता है.
5. ops - ऑपरेशन/devops टीम के बारे में बताता है. उनके पास इन संसाधनों का मालिकाना हक है.
6. ops project - सभी ऑपरेशन संसाधनों के लिए प्रोजेक्ट दिखाता है.
7. gke clusters - हर क्षेत्र के लिए Ops GKE (जीकेई) क्लस्टर. Istio कंट्रोल प्लेन को Ops GKE (जीकेई) के हर क्लस्टर में इंस्टॉल किया गया है.
8. k8s-repo - सीएसआर रेपो, जिसमें सभी GKE (जीकेई) क्लस्टर के लिए, GKE (जीकेई) मेनिफ़ेस्ट शामिल होता है.
9. apps - ऐप्लिकेशन टीम की जानकारी देती है. इस वर्कशॉप में, app1 और app2 नाम की दो टीमों को सिम्युलेट किया जाता है. उनके पास इन संसाधनों का मालिकाना हक है.
10. app projects - हर ऐप्लिकेशन टीम को अपने प्रोजेक्ट का सेट मिलता है. इससे उन्हें अपने प्रोजेक्ट के लिए बिलिंग और IAM को कंट्रोल करने में मदद मिलती है.
11. gke clusters - ये ऐप्लिकेशन क्लस्टर हैं, जहां ऐप्लिकेशन कंटेनर/पॉड चलते हैं.
12. gce instances - अगर उनके पास ऐसे ऐप्लिकेशन हैं जो GCE (जीसीई) इंस्टेंस पर चलते हैं, तो इसका इस्तेमाल किया जा सकता है. इस वर्कशॉप में, app1 पर GCE (जीसीई) के कुछ ऐसे इंस्टेंस मौजूद हैं जहां ऐप्लिकेशन का कुछ हिस्सा काम करता है.

इस वर्कशॉप में, app1 और app2, दोनों के लिए एक ही ऐप्लिकेशन (Hipster Shop ऐप्लिकेशन) को दिखाया गया है.

सेवा देने वाली कंपनी, स्थितियां, और आउटपुट - बैकएंड और शेयर किए गए राज्य

google और google-beta सेवा देने वाली कंपनी gcp/[environment]/gcp/provider.tf पर मौजूद है. provider.tf फ़ाइल को हर रिसॉर्स फ़ोल्डर में सिमलिंक किया जाता है. इससे आपको हर संसाधन के लिए अलग-अलग कंपनियों को मैनेज करने के बजाय, एक ही जगह पर सेवा देने वाली कंपनी को बदलने की सुविधा मिलती है.

हर संसाधन में एक backend.tf फ़ाइल होती है, जो संसाधन की tfstate फ़ाइल की जगह की जानकारी देती है. इस backend.tf फ़ाइल को scripts/setup_terraform_admin_project पर मौजूद स्क्रिप्ट का इस्तेमाल करके, templates/backend.tf_tmpl पर मौजूद टेंप्लेट से बनाया जाता है. इसके बाद, इसे संबंधित संसाधन फ़ोल्डर में रखा जाता है. Google Cloud Storage (GCS) बकेट का इस्तेमाल, बैकएंड के लिए किया जाता है. GCS बकेट फ़ोल्डर का नाम, संसाधन के नाम से मेल खाता है. सभी रिसॉर्स बैकएंड, टेराफ़ॉर्म एडमिन प्रोजेक्ट में मौजूद होते हैं.

इंटरडिपेंडेंट वैल्यू वाले रिसॉर्स में एक output.tf फ़ाइल होती है. किसी खास संसाधन के लिए ज़रूरी आउटपुट वैल्यू, बैकएंड में तय की गई tfstate फ़ाइल में सेव होती हैं. उदाहरण के लिए, किसी प्रोजेक्ट में GKE (जीकेई) क्लस्टर बनाने के लिए, आपके पास प्रोजेक्ट आईडी की जानकारी होनी चाहिए. प्रोजेक्ट आईडी, आउटपुट.tf के ज़रिए उस tfstate फ़ाइल में मिलता है जिसे GKE (जीकेई) क्लस्टर के संसाधन में, terraform_remote_state डेटा सोर्स के ज़रिए इस्तेमाल किया जा सकता है.

Shared_state फ़ाइल एक terraform_remote_state डेटा सोर्स है, जो संसाधन की tfstate फ़ाइल पर ले जाता है. संसाधन फ़ोल्डर में एक shared_state_[resource_name].tf फ़ाइल (या फ़ाइलें) मौजूद होती है, जिसके लिए अन्य संसाधनों के आउटपुट की ज़रूरत होती है. उदाहरण के लिए, ops_gke संसाधन फ़ोल्डर में ops_project और shared_vpc संसाधनों की shared_state फ़ाइलें मौजूद हैं. इसकी वजह यह है कि Ops प्रोजेक्ट में GKE (जीकेई) क्लस्टर बनाने के लिए, आपको प्रोजेक्ट आईडी और VPC की जानकारी की ज़रूरत होगी. Shared_state फ़ाइलें, स्क्रिप्ट (scripts/setup_terraform_admin_project पर मौजूद) का इस्तेमाल करके, टेंप्लेट (templates/shared_state.tf_tmpl पर मौजूद) से जनरेट की जाती हैं. सभी संसाधनों की Shared_state फ़ाइलों को gcp/[environment]/shared_states फ़ोल्डर में रखा जाता है. ज़रूरी shared_state फ़ाइलों को उनसे जुड़े रिसॉर्स फ़ोल्डर में सिमलिंक किया जाता है. सभी Shared_state फ़ाइलों को एक फ़ोल्डर में रखने और उन्हें सही संसाधन फ़ोल्डर में सिम लिंक करने से, सभी स्टेट फ़ाइलों को एक ही जगह पर मैनेज करना आसान हो जाता है.

वैरिएबल

सभी संसाधन वैल्यू, एनवायरमेंट वैरिएबल के तौर पर स्टोर की जाती हैं. ये वैरिएबल, vars.sh नाम की फ़ाइल में स्टोर किए जाते हैं, जो कि टेराफ़ॉर्म एडमिन प्रोजेक्ट में GCS बकेट में होते हैं. इसमें संगठन का आईडी, बिलिंग खाता, प्रोजेक्ट आईडी, GKE (जीकेई) क्लस्टर की जानकारी वगैरह शामिल होती है. अपने सेटअप की वैल्यू पाने के लिए, vars.sh को किसी भी टर्मिनल से डाउनलोड और सोर्स किया जा सकता है.

टेराफ़ॉर्म वैरिएबल, vars.sh में TF_VAR_[variable name] के तौर पर सेव किए जाते हैं. इन वैरिएबल का इस्तेमाल, संबंधित संसाधन फ़ोल्डर में variables.tfvars फ़ाइल जनरेट करने के लिए किया जाता है. variables.tfvars फ़ाइल में सभी वैरिएबल की वैल्यू मौजूद होती हैं. variables.tfvars फ़ाइल को उसी फ़ोल्डर में मौजूद टेंप्लेट फ़ाइल से, scripts/setup_terraform_admin_project पर मौजूद स्क्रिप्ट का इस्तेमाल करके जनरेट किया जाता है.

K8s Repo के बारे में जानकारी

k8s_repo, एक सीएसआर रेपो है. यह Turaform एडमिन प्रोजेक्ट में मौजूद, इंफ़्रास्ट्रक्चर रेपो से अलग होता है. It का इस्तेमाल, सभी GKE (जीकेई) क्लस्टर पर, GKE (जीकेई) मेनिफ़ेस्ट को सेव और लागू करने के लिए किया जाता है. k8s_repo को Cloud Build इंफ़्रास्ट्रक्चर के ज़रिए बनाया गया है. ज़्यादा जानकारी के लिए, पिछला सेक्शन देखें. Cloud Build की शुरुआती इन्फ़्रास्ट्रक्चर के लिए, कुल छह GKE (जीकेई) क्लस्टर बनाए जाते हैं. k8s_repo में, छह फ़ोल्डर बनाए जाते हैं. हर फ़ोल्डर (GKE क्लस्टर के नाम से मिलता-जुलता नाम) एक GKE क्लस्टर से जुड़ा होता है, जिसमें उससे जुड़ी संसाधन मेनिफ़ेस्ट फ़ाइलें होती हैं. बिल्डिंग इन्फ़्रास्ट्रक्चर की तरह ही Cloud Build का इस्तेमाल, k8s_repo का इस्तेमाल करके सभी GKE (जीकेई) क्लस्टर पर Kubernetes मेनिफ़ेस्ट लागू करने के लिए किया जाता है. जब भी k8s_repo रेपो की नीति का पालन किया जाता है, तब Cloud Build ट्रिगर होता है. इन्फ़्रास्ट्रक्चर की तरह ही, Kubernetes के सभी मेनिफ़ेस्ट, k8s_repo डेटा स्टोर करने की जगह में कोड के तौर पर सेव किए जाते हैं. साथ ही, हर GKE (जीकेई) क्लस्टर की स्थिति को हमेशा इससे जुड़े फ़ोल्डर में सेव किया जाता है.

शुरुआती इन्फ़्रास्ट्रक्चर के बिल्ड के तौर पर, k8s_repo बनाया गया और सभी क्लस्टर पर Istio इंस्टॉल किया गया.

प्रोजेक्ट, GKE (जीकेई) क्लस्टर, और नेमस्पेस

इस वर्कशॉप में मौजूद संसाधनों को अलग-अलग GCP प्रोजेक्ट में बांटा गया है. प्रोजेक्ट, आपकी कंपनी के संगठन या टीम के स्ट्रक्चर से मेल खाने चाहिए. अलग-अलग प्रोजेक्ट/प्रॉडक्ट/संसाधनों के लिए ज़िम्मेदार टीमें (आपके संगठन में) अलग-अलग GCP प्रोजेक्ट का इस्तेमाल करती हैं. अलग-अलग प्रोजेक्ट होने से, IAM अनुमतियों के अलग-अलग सेट बनाए जा सकते हैं. साथ ही, प्रोजेक्ट लेवल पर बिलिंग को मैनेज किया जा सकता है. इसके अलावा, कोटा को प्रोजेक्ट लेवल पर भी मैनेज किया जाता है.

इस वर्कशॉप में पांच टीमों का प्रतिनिधित्व किया गया है. हर टीम का अपना प्रोजेक्ट है.

1. GCP के संसाधन बनाने वाली इन्फ़्रास्ट्रक्चर टीम, Terraform admin project का इस्तेमाल करती है. वे इन्फ़्रास्ट्रक्चर को सीएसआर रेपो (infrastructure) में कोड के तौर पर मैनेज करते हैं. साथ ही, GCP में बनाए गए संसाधनों से जुड़ी, टेरेस की पूरी जानकारी को GCS (जीसीएस) बकेट में स्टोर करते हैं. वे सीएसआर रेपो और टेराफ़ॉर्म स्टेट GCS बकेट के ऐक्सेस को कंट्रोल करते हैं.
2. शेयर किया गया VPC बनाने वाली नेटवर्क टीम, host project का इस्तेमाल करती है. इस प्रोजेक्ट में VPC, सबनेट, रूट, और फ़ायरवॉल के नियम शामिल हैं. शेयर किया गया VPC होने से, यह कंपनी GCP संसाधनों के लिए एक ही जगह से नेटवर्किंग को मैनेज कर सकती है. सभी प्रोजेक्ट में, नेटवर्किंग के लिए इस एक शेयर किए गए VPC का इस्तेमाल किया गया था.
3. GKE (जीकेई) क्लस्टर और एएसएम/Istio कंट्रोल हवाई जहाज़ बनाने वाली ops/platform टीम, ops project का इस्तेमाल करती है. ये GKE (जीकेई) क्लस्टर और सर्विस मेश की लाइफ़ साइकल को मैनेज करते हैं. क्लस्टरों को मज़बूत करने, Kubernetes प्लैटफ़ॉर्म के इस्तेमाल में होने वाले बदलाव और उसके असर को मैनेज करने की ज़िम्मेदारी उनकी है. इस वर्कशॉप में, आपने Kubernetes पर संसाधनों को डिप्लॉय करने के लिए, गिटॉप्स वाले तरीके का इस्तेमाल किया है. ऑपरेशन प्रोजेक्ट में सीएसआर रेपो (जिसे k8s_repo कहा जाता है) मौजूद है.
4. आखिर में, ऐप्लिकेशन बनाने वाली dev1 और dev2 टीमें (इनमें दो डेवलपमेंट टीमें शामिल हैं), अपने dev1 और dev2 projects का इस्तेमाल करती हैं. ये ऐसे ऐप्लिकेशन और सेवाएं हैं जिन्हें आप अपने ग्राहकों को उपलब्ध कराते हैं. इन्हें उस प्लैटफ़ॉर्म पर बनाया जाता है जिसे ऑपरेशन टीम मैनेज करती है. संसाधन (डिप्लॉयमेंट, सेवाएं वगैरह) k8s_repo में पुश किए जाते हैं और सही क्लस्टर में डिप्लॉय किए जाते हैं. ध्यान दें कि यह वर्कशॉप, सीआई/सीडी के सबसे सही तरीकों और टूल पर फ़ोकस नहीं करती. आपने Cloud Build का इस्तेमाल करके, Kubernetes संसाधनों को सीधे GKE क्लस्टर में अपने-आप डिप्लॉय किया है. असल में प्रोडक्शन से जुड़ी स्थितियों में, GKE (जीकेई) क्लस्टर में ऐप्लिकेशन डिप्लॉय करने के लिए, सही CI/CD समाधान का इस्तेमाल करना होगा.

इस वर्कशॉप में दो तरह के GKE (जीकेई) क्लस्टर इस्तेमाल किए जाते हैं.

1. Ops क्लस्टर - इसका इस्तेमाल DevOps टूल चलाने के लिए, Ops टीम करती है. इस वर्कशॉप में, वे सर्विस मेश को मैनेज करने के लिए ASM/Istio कंट्रोल प्लेन चलाते हैं.
2. ऐप्लिकेशन (ऐप्लिकेशन) क्लस्टर - इसका इस्तेमाल डेवलपमेंट टीमें ऐप्लिकेशन चलाने के लिए करती हैं. इस वर्कशॉप में, हिपस्टर शॉप ऐप्लिकेशन का इस्तेमाल किया गया है.

ऐप्लिकेशन को चलाने वाले क्लस्टर से ऑपरेशन/एडमिन टूल को अलग करके, आप हर संसाधन के लाइफ़ साइकल को अलग से मैनेज कर सकते हैं. टीम/प्रॉडक्ट से जुड़े अलग-अलग प्रोजेक्ट में दो तरह के क्लस्टर भी मौजूद होते हैं. ये क्लस्टर इनका इस्तेमाल करते हैं, जिससे IAM अनुमतियों को मैनेज करना भी आसान हो जाता है.

GKE (जीकेई) के कुल छह क्लस्टर होते हैं. ऑपरेशन प्रोजेक्ट में दो रीजनल ऑपरेशन क्लस्टर बनाए जाते हैं. ASM/Istio कंट्रोल प्लेन, दोनों ऑपरेशन क्लस्टर पर इंस्टॉल किया गया है. हर ऑपरेशन क्लस्टर एक अलग क्षेत्र में है. इसके अलावा, चार ज़ोनल ऐप्लिकेशन क्लस्टर भी उपलब्ध हैं. इन्हें उनके अपने प्रोजेक्ट में बनाया जाता है. इस वर्कशॉप में, दो डेवलपमेंट टीमों के बीच अपने-अपने प्रोजेक्ट लिए जाते हैं. हर प्रोजेक्ट में दो ऐप्लिकेशन क्लस्टर होते हैं. ऐप्लिकेशन क्लस्टर, अलग-अलग ज़ोन में मौजूद ज़ोनल क्लस्टर होते हैं. चार ऐप्लिकेशन क्लस्टर, दो क्षेत्रों और चार ज़ोन में मौजूद हैं. इससे आपको रीजनल और ज़ोनल रिडंडंसी की सुविधा मिलती है.

इस वर्कशॉप में इस्तेमाल किया गया हिपस्टर शॉप ऐप्लिकेशन, सभी चार ऐप्लिकेशन क्लस्टर के लिए डिप्लॉय किया गया है. हर माइक्रोसर्विस, हर ऐप्लिकेशन क्लस्टर में अपने नेमस्पेस में मौजूद होती है. हिपस्टर शॉप ऐप्लिकेशन के डिप्लॉयमेंट (पॉड) को ऑपरेशन क्लस्टर में डिप्लॉय नहीं किया गया है. हालांकि, सभी माइक्रोसेवाओं के लिए नेमस्पेस और सेवा से जुड़े संसाधन, ऑपरेशन क्लस्टर में भी बनाए जाते हैं. ASM/Istio कंट्रोल प्लेन, सेवा खोजने के लिए Kubernetes सेवा रजिस्ट्री का इस्तेमाल करता है. सेवाएं (ऑपरेशन क्लस्टर में) मौजूद न होने पर, आपको ऐप्लिकेशन क्लस्टर में चल रही हर सेवा के लिए, ServiceEntries को मैन्युअल तरीके से बनाना होगा.

इस वर्कशॉप में 10-टीयर माइक्रोसर्विस ऐप्लिकेशन डिप्लॉय किया जाता है. यह ऐप्लिकेशन " हिपस्टर की दुकान" जहां लोग आइटम ब्राउज़ कर सकते हैं, उन्हें कार्ट में जोड़ सकते हैं, और उन्हें खरीद सकते हैं.

Kubernetes मेनिफ़ेस्ट और k8s_repo

आपने सभी GKE (जीकेई) क्लस्टर में, Kubernetes संसाधनों को जोड़ने के लिए, k8s_repo का इस्तेमाल किया है. ऐसा करने के लिए, आपको Kubernetes मेनिफ़ेस्ट को कॉपी करना होगा और k8s_repo को स्वीकार करना होगा. ये सभी काम, k8s_repo के लिए Cloud Build जॉब को ट्रिगर करने का वादा करते हैं, जो संबंधित क्लस्टर में Kubernetes मेनिफ़ेस्ट को डिप्लॉय करता है. हर क्लस्टर का मेनिफ़ेस्ट, एक अलग फ़ोल्डर में मौजूद होता है, जिसका नाम क्लस्टर का नाम ही होता है.

क्लस्टर के ये छह नाम हैं:

1. gke-asm-1-r1-prod - क्षेत्र 1 में क्षेत्रीय ऑपरेशन क्लस्टर
2. gke-asm-2-r2-prod - क्षेत्र 2 में क्षेत्रीय ऑपरेशन क्लस्टर
3. gke-1-apps-r1a-prod - क्षेत्र 1 ज़ोन a में ऐप्लिकेशन क्लस्टर
4. gke-2-apps-r1b-prod - क्षेत्र 1 ज़ोन b में ऐप्लिकेशन क्लस्टर
5. gke-3-apps-r2a-prod - क्षेत्र 2 ज़ोन a में ऐप्लिकेशन क्लस्टर
6. gke-4-apps-r2b-prod - क्षेत्र 2 ज़ोन b में ऐप्लिकेशन क्लस्टर

k8s_repo में इन क्लस्टर से जुड़े फ़ोल्डर हैं. इन फ़ोल्डर में मौजूद कोई भी मेनिफ़ेस्ट, इससे जुड़े GKE (जीकेई) क्लस्टर पर लागू हो जाता है. हर क्लस्टर के मेनिफ़ेस्ट को सब-फ़ोल्डर (क्लस्टर के मुख्य फ़ोल्डर में) में रखा जाता है, ताकि उसे आसानी से मैनेज किया जा सके. इस वर्कशॉप में, डिप्लॉय किए गए संसाधनों को ट्रैक करने के लिए, Kustomize का इस्तेमाल किया जाता है. ज़्यादा जानकारी के लिए, कृपया Kustomize के आधिकारिक दस्तावेज़ देखें.

7. सैंपल ऐप्लिकेशन को डिप्लॉय करें

मकसद: अलग-अलग ऐप्लिकेशन के क्लस्टर पर, हिपस्टर शॉप ऐप्लिकेशन डिप्लॉय करना

• k8s-repo का क्लोन
• हिपस्टर शॉपिंग मेनिफ़ेस्ट को सभी ऐप्लिकेशन क्लस्टर में कॉपी करें
• ऑपरेशन क्लस्टर में, हिपस्टर शॉप ऐप्लिकेशन के लिए सेवाएं बनाएं
• दुनिया भर में कनेक्टिविटी की जांच करने के लिए, ऑपरेशन क्लस्टर में loadgenerators को सेटअप करें
• हिपस्टर शॉपिंग ऐप्लिकेशन के साथ सुरक्षित कनेक्टिविटी की पुष्टि करें

फ़ास्ट ट्रैक स्क्रिप्ट

अगर यह तरीका चुना जाता है, तो इस लैब को पूरा करने के लिए, यहां दी गई स्क्रिप्ट चलाएं.

${WORKDIR}/asm/fasttrack_scripts/deploy-sample-app.sh

कॉपी-और-पेस्ट करने की विधि चुनने वाले लैब से जुड़े निर्देश

अगर आपने इस लैब के लिए फ़ास्ट ट्रैक स्क्रिप्ट पहले ही पूरी कर ली है, तो कॉपी करने और चिपकाने के लिए यहां दिया गया तरीका न अपनाएं**.**

ऑपरेशन प्रोजेक्ट के सोर्स रेपो का क्लोन बनाएं

शुरुआती टेराफ़ॉर्म इन्फ़्रास्ट्रक्चर के बिल्ड के तौर पर, k8s-repo को ऑपरेशन प्रोजेक्ट में पहले ही बना लिया गया है.

1. git repo के लिए एक खाली डायरेक्ट्री बनाएं:

mkdir $WORKDIR/k8s-repo
 

2. git repo में, रिमोट जोड़ें और रिमोट रेपो से मास्टर को पुल करें:

cd $WORKDIR/k8s-repo
git init && git remote add origin \
https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo
 

3. लोकल git लोकल कॉन्फ़िगरेशन सेट करें.

git config --local user.email $MY_USER
git config --local user.name "K8s repo user"
git config --local \
credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

मेनिफ़ेस्ट कॉपी करें, कमिट करें, और पुश करें

4. हिपस्टर शॉप के नेमस्पेस और सेवाओं को सभी क्लस्टर के लिए, सोर्स रेपो में कॉपी करें.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.
 

5. ऐप्लिकेशन फ़ोल्डर kustomization.yaml को सभी क्लस्टर में कॉपी करें.

cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/
 

6. हिपस्टर शॉप के डिप्लॉयमेंट, आरबीएसी, और PodSecurityPolicy को कॉपी करके, ऐप्लिकेशन क्लस्टर के सोर्स रेपो में बदलें.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

7. सिर्फ़ एक डेवलपर क्लस्टर को छोड़कर, सभी कार्टसेवा डिप्लॉयमेंट, rbac, और podsecuritypolicy को हटाएं. हिपस्टरशॉप को मल्टी-क्लस्टर डिप्लॉयमेंट के लिए नहीं बनाया गया था. इसलिए, अलग-अलग नतीजों से बचने के लिए, हम सिर्फ़ एक कार्टसेवा का इस्तेमाल कर रहे हैं.

rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml
 

8. सिर्फ़ पहले डेवलपर क्लस्टर में, kustomization.yaml में कार्टसेवा डिप्लॉयमेंट, rbac, और podsecuritypolicy जोड़ें.

cd ${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app
cd deployments && kustomize edit add resource app-cart-service.yaml
cd ../podsecuritypolicies && kustomize edit add resource cart-psp.yaml
cd ../rbac && kustomize edit add resource cart-rbac.yaml
cd ${WORKDIR}/asm
 

9. ops क्लस्टर kustomization.yaml से podsecuritypolicies, डिप्लॉयमेंट, और rbac डायरेक्ट्री हटाएं

sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/kustomization.yaml
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/kustomization.yaml

10. आरबीएसी मेनिफ़ेस्ट में PROJECT_ID की जगह बदलें.

sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/*
  

11. Inग्रेसगेटवे और VirtualService मेनिफ़ेस्ट को, ऑपरेशन क्लस्टर के सोर्स रेपो में कॉपी करें.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-ingress/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-ingress/
 

12. हर प्रोजेक्ट के किसी एक क्लस्टर में कॉन्फ़िगरेशन कनेक्टर संसाधन कॉपी करें.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/
 

13. कॉन्फ़िगरेशन कनेक्टर मेनिफ़ेस्ट में PROJECT_ID बदलें.

sed -i 's/${PROJECT_ID}/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev1_project_name'/g' \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev2_project_name'/g' \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/*
 

14. loadgenerator मेनिफ़ेस्ट (डिप्लॉयमेंट, PodSecurityPolicy, और RBAC) को ऑपरेशन क्लस्टर में कॉपी करें. हिपस्टर शॉपिंग ऐप्लिकेशन को ग्लोबल Google क्लाउड लोड बैलेंसर (जीसीएलबी) की मदद से दिखाया गया है. GCLB को क्लाइंट ट्रैफ़िक मिलता है (यह ट्रैफ़िक frontend पर सेट होता है) और इसे सेवा के सबसे नज़दीकी इंस्टेंस पर भेजता है. दोनों ऑपरेशन क्लस्टर पर loadgenerator रखने से, यह पक्का हो जाएगा कि ऑपरेशन क्लस्टर में चल रहे, दोनों Istio Inग्रेस गेटवे पर ट्रैफ़िक भेजा जाएगा. लोड बैलेंसिंग के बारे में नीचे दिए गए सेक्शन में बताया गया है.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/. 
 

15. दोनों ऑपरेशन क्लस्टर के लिए, loadgenerator मेनिफ़ेस्ट में Ops प्रोजेक्ट आईडी बदलें.

sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g'  \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
 

16. दोनों ऑपरेशन क्लस्टर के लिए, kustomization.yaml में loadgenerator संसाधन जोड़ें.

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml
 

17. k8s-repo को अपनाएं.

cd $WORKDIR/k8s-repo
git add . && git commit -am "create app namespaces and install hipster shop"
git push --set-upstream origin master 
 

18. पहले से खोले गए टैब में या नीचे दिए गए लिंक पर क्लिक करके, Ops प्रोजेक्ट Cloud Build की स्थिति देखें:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
  

ऐप्लिकेशन डिप्लॉयमेंट की पुष्टि करें

19. पुष्टि करें कि सभी डेवलपर क्लस्टर में, कार्ट को छोड़कर बाकी सभी ऐप्लिकेशन नेमस्पेस में पॉड रनिंग की स्थिति में हैं.

for ns in ad checkout currency email frontend payment product-catalog recommendation shipping; do
  kubectl --context $DEV1_GKE_1 get pods -n $ns;
  kubectl --context $DEV1_GKE_2 get pods -n $ns;
  kubectl --context $DEV2_GKE_1 get pods -n $ns;
  kubectl --context $DEV2_GKE_2 get pods -n $ns;
done;
 

Output (do not copy)

NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-pvc6s   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-xlkl9   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-zdjkg   2/2     Running   0          115s
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-l748q   2/2     Running   0          82s

NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-gk92n   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-rvzk9   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-mt925   2/2     Running   0          117s
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-klqn7   2/2     Running   0          84s

NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-kkq7d   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-lwskf   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-zz7xs   2/2     Running   0          118s
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-2vtw5   2/2     Running   0          85s

NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-df8ml   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-bdcvg   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-jqf28   2/2     Running   0          117s
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-95x2m   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-q5g9p   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-n6lp8   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-gf9xl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-v7cbr   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-2ltrk   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-dqd55   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-jghcl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-kkspz   2/2     Running   0          87s

NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-qqd9n   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-xczg5   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-wfgfr   2/2     Running   0          2m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-r6t8v   2/2     Running   0          88s

20. पुष्टि करें कि कार्ट नेमस्पेस में मौजूद पॉड, सिर्फ़ पहले डेवलपर क्लस्टर में 'चालू है' की स्थिति में हैं.

kubectl --context $DEV1_GKE_1 get pods -n cart;
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
cartservice-659c9749b4-vqnrd   2/2     Running   0          17m

हिपस्टर शॉप ऐप्लिकेशन ऐक्सेस करें

ग्लोबल लोड बैलेंसिंग

अब आपके पास हिपस्टर शॉप ऐप्लिकेशन है, जिसे चारों ऐप्लिकेशन क्लस्टर में डिप्लॉय कर दिया गया है. ये क्लस्टर दो क्षेत्रों और चार ज़ोन में हैं. क्लाइंट, हिपस्टर खरीदारी ऐप्लिकेशन को frontend की सेवा ऐक्सेस करके ऐक्सेस कर सकते हैं. frontend सेवा, ऐप्लिकेशन के चारों क्लस्टर पर काम करती है. Google Cloud लोड बैलेंसर ( GCLB) का इस्तेमाल, frontend सेवा के चारों इंस्टेंस पर क्लाइंट ट्रैफ़िक पाने के लिए किया जाता है.

Istio Inग्रेस गेटवे, सिर्फ़ ऑपरेशन क्लस्टर में चलते हैं. साथ ही, ये एक इलाके में मौजूद दो ज़ोनल ऐप्लिकेशन क्लस्टर के लिए, रीजनल लोड बैलेंसर के तौर पर काम करते हैं. GCLB, ग्लोबल फ़्रंटएंड सेवा के बैकएंड के तौर पर दो Istio इन्ग्रेस गेटवे (दो ऑपरेशन क्लस्टर में चल रहा है) का इस्तेमाल करता है. इस्टियो इन्ग्रेस गेटवे को GCLB से क्लाइंट ट्रैफ़िक मिलता है और इसके बाद यह क्लाइंट ट्रैफ़िक को ऐप्लिकेशन क्लस्टर में चल रहे फ़्रंटएंड पॉड पर भेजता है.

इसके अलावा, Istio Inग्रेस गेटवे को सीधे ऐप्लिकेशन क्लस्टर में रखा जा सकता है. साथ ही, GCLB इनका इस्तेमाल बैकएंड के तौर पर कर सकता है.

GKE (जीकेई) Autoneg कंट्रोलर

Istio Inग्रेस गेटवे Kubernetes Service, नेटवर्क एंडपॉइंट ग्रुप (एनईजी) का इस्तेमाल करके, जीसीएलबी में बैकएंड के तौर पर खुद को रजिस्टर करता है. एनईजी, जीसीएलबी का इस्तेमाल करके कंटेनर-नेटिव लोड बैलेंसिंग की अनुमति देता है. एनईजी, Kubernetes सेवा पर एक खास एनोटेशन के ज़रिए बनाया जाता है, ताकि यह खुद को NEG कंट्रोलर पर रजिस्टर कर सके. Autoneg कंट्रोलर, एक खास GKE (जीकेई) कंट्रोलर है. यह अपने-आप एनईजी बनाता है. साथ ही, यह सेवा एनोटेशन का इस्तेमाल करके, जीसीएलबी को बैकएंड के तौर पर असाइन करता है. इस्तियो कंट्रोल प्लेन, Teraform Cloud Build के शुरुआती इन्फ़्रास्ट्रक्चर के दौरान डिप्लॉय किए जाते हैं. इनमें Istio के इन्ग्रेस गेटवे भी शामिल हैं. GCLB और Autoneg कॉन्फ़िगरेशन को, शुरुआती टेराफ़ॉर्म इन्फ़्रास्ट्रक्चर Cloud Build के हिस्से के तौर पर किया जाता है.

Cloud एंडपॉइंट और मैनेज किए जा रहे सर्टिफ़िकेट का इस्तेमाल करके, इन्ग्रेस डेटा ट्रैफ़िक को सुरक्षित करें

GCP से मैनेज किए जाने वाले सर्टिफ़िकेट का इस्तेमाल, क्लाइंट ट्रैफ़िक को frontend GCLB सेवा पर सुरक्षित रखने के लिए किया जाता है. GCLB, ग्लोबल frontend सेवा के लिए मैनेज किए जा रहे सर्टिफ़िकेट इस्तेमाल करता है और GCLB पर सर्टिफ़िकेट खत्म हो जाता है. इस वर्कशॉप में, मैनेज किए जा रहे सर्टिफ़िकेट के लिए, डोमेन के तौर पर Cloud एंडपॉइंट का इस्तेमाल किया जाता है. इसके अलावा, GCP से मैनेज किए जाने वाले सर्टिफ़िकेट बनाने के लिए, frontend के लिए अपने डोमेन और डीएनएस नेम का इस्तेमाल किया जा सकता है.

21. हिपस्टर शॉप को ऐक्सेस करने के लिए, नीचे दिए गए निर्देश के लिंक आउटपुट पर क्लिक करें.

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

22. आप अपने Chrome टैब के URL बार में लॉक प्रतीक पर क्लिक करके यह जांच सकते हैं कि प्रमाणपत्र मान्य है या नहीं.

ग्लोबल लोड बैलेंसिंग की पुष्टि करें

ऐप्लिकेशन डिप्लॉयमेंट के तौर पर, दोनों ऑपरेशन क्लस्टर में लोड जनरेट करने वाले टूल डिप्लॉय किए गए. ये दोनों क्लस्टर, GCLB हिपस्टर शॉप क्लाउड एंडपॉइंट लिंक पर टेस्ट ट्रैफ़िक जनरेट करते हैं. पुष्टि करें कि GCLB को ट्रैफ़िक मिल रहा है और यह Istio Inग्रेस के दोनों गेटवे पर भेज रहा है.

23. GCLB > उस ऑपरेशन प्रोजेक्ट के लिए मॉनिटरिंग लिंक जहां हिपस्टर शॉप GCLB बनाया गया है.

echo "https://console.cloud.google.com/net-services/loadbalancing/details/http/istio-ingressgateway?project=$TF_VAR_ops_project_name&cloudshell=false&tab=monitoring&duration=PT1H" 
 

24. जैसा कि नीचे दिखाया गया है, बैकएंड मेन्यू में सभी बैकएंड को बैकएंड ड्रॉपडाउन मेन्यू से istio-inग्रेसगेटवे में बदलें.

25. istio-ingressgateways, दोनों पर जाने वाले ट्रैफ़िक पर ध्यान दें.

हर istio-ingressgateway में तीन NEG बनाए जाते हैं. ऑपरेशन क्लस्टर, रीजनल क्लस्टर हैं. इसलिए, क्षेत्र के हर ज़ोन के लिए एक NEG बनाया जाता है. हालांकि, istio-ingressgateway पॉड, हर क्षेत्र के लिए एक ही ज़ोन में चलते हैं. ट्रैफ़िक को istio-ingressgateway पॉड में दिखाया जा रहा है.

दोनों ऑपरेशन क्लस्टर में, लोड जनरेट करने वाले टूल उन दोनों इलाकों से क्लाइंट ट्रैफ़िक को सिम्युलेट कर रहे हैं जहां वे हैं. ऑपरेशन क्लस्टर के पहले इलाके में जनरेट किया गया लोड, क्षेत्र 2 में मौजूद istio-ingressgateway को भेजा जा रहा है. इसी तरह, ऑपरेशन क्लस्टर के क्षेत्र 2 में जनरेट किया गया लोड, क्षेत्र 2 में मौजूद istio-ingressgateway को भेजा जा रहा है.

8. स्टैकड्राइवर की मदद से निगरानी करने की सुविधा

मकसद: Istio टेलीमेट्री को स्टैकड्राइवर से कनेक्ट करें और पुष्टि करें.

• istio-telemetry संसाधन इंस्टॉल करें
• Istio Services के डैशबोर्ड बनाएं या अपडेट करें
• कंटेनर के लॉग देखें
• स्टैकड्राइवर में डिस्ट्रिब्यूटेड ट्रेसिंग देखें

फ़ास्ट ट्रैक स्क्रिप्ट

अगर यह तरीका चुना जाता है, तो इस लैब को पूरा करने के लिए, यहां दी गई स्क्रिप्ट चलाएं.

${WORKDIR}/asm/fasttrack_scripts/observability-with-stackdriver.sh

कॉपी-और-पेस्ट करने की विधि चुनने वाले लैब से जुड़े निर्देश

अगर आपने इस लैब के लिए फ़ास्ट ट्रैक स्क्रिप्ट पहले ही पूरी कर ली है, तो कॉपी करने और चिपकाने के लिए यहां दिया गया तरीका न अपनाएं**.**

इस्तिओ की एक मुख्य सुविधा, बिल्ट-इन ऑब्ज़र्वेबिलिटी ("o11y") है. इसका मतलब है कि ब्लैक-बॉक्स और बिना रुकावट वाले कंटेनर का इस्तेमाल करने पर भी ऑपरेटर, इन कंटेनर के अंदर और बाहर जाने वाले ट्रैफ़िक की निगरानी कर सकते हैं और ग्राहकों को सेवाएं दे सकते हैं. यह जानकारी अलग-अलग तरीकों के तौर पर दिखती है: मेट्रिक, लॉग, और ट्रेस.

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

1. istio को स्टैकड्राइवर कॉन्फ़िगरेशन फ़ाइल में इंस्टॉल करें.

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml
 

2. k8s-repo पर जाएं.

cd $WORKDIR/k8s-repo
git add . && git commit -am "Install istio to stackdriver configuration"
git push 
 

3. पहले से खोले गए टैब में या नीचे दिए गए लिंक पर क्लिक करके, Ops प्रोजेक्ट Cloud Build की स्थिति देखें:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

4. Istio → स्टैकड्राइवर इंटिग्रेशन की पुष्टि करें, स्टैकड्राइवर हैंडलर CRD पाएं.

kubectl --context $OPS_GKE_1 get handler -n istio-system
 

आउटपुट में स्टैकड्राइवर नाम का हैंडलर दिखना चाहिए:

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s      # <== NEW!

5. पुष्टि करें कि Stackdriver पर Istio मेट्रिक एक्सपोर्ट करने की सुविधा काम कर रही है. इस निर्देश से मिले लिंक के आउटपुट पर क्लिक करें:

echo "https://console.cloud.google.com/monitoring/metrics-explorer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

आपको एक नया फ़ाइल फ़ोल्डर बनाने के लिए कहा जाएगा, जिसका नाम Ops प्रोजेक्ट के नाम पर रखा जाएगा. बस 'ठीक है' चुनें. अगर यह आपको नए यूज़र इंटरफ़ेस (यूआई) के बारे में प्रॉम्प्ट करता है, तो डायलॉग को खारिज कर दें.

मेट्रिक एक्सप्लोरर में, "संसाधन टाइप और मेट्रिक ढूंढें" में जाकर "istio" लिखें यह देखने के लिए कि आपके पास "सर्वर अनुरोध की संख्या" जैसे विकल्प हैं या नहीं के बारे में ज़्यादा जानकारी मौजूद है. संसाधन प्रकार. इससे हमें पता चलता है कि मेट्रिक, मेश से स्टैकड्राइवर में फ़्लो कर रही हैं.

(अगर आपको नीचे दी गई लाइनें देखनी हैं, तो आपको 'इसके हिसाब से ग्रुप बनाएं' destination_service_name लेबल लगाना होगा.)

डैशबोर्ड की मदद से मेट्रिक को विज़ुअलाइज़ करना:

अब हमारी मेट्रिक स्टैकड्राइवर एपीएम सिस्टम में हैं, इसलिए हम उन्हें विज़ुअलाइज़ करने का तरीका चाहते हैं. इस सेक्शन में, हम पहले से बना एक डैशबोर्ड इंस्टॉल करेंगे. इसमें हमें, गोल्डन सिग्नल" मेट्रिक में से: ट्रैफ़िक (अनुरोध प्रति सेकंड), इंतज़ार का समय (इस मामले में, 99वां और 50वां पर्सेंटाइल), और गड़बड़ियां (इस उदाहरण में, हम सैचुरेशन को शामिल नहीं कर रहे हैं).

Istio की Envoy प्रॉक्सी से हमें कई मेट्रिक मिलती हैं, लेकिन शुरुआत के लिए, ये बेहतर विकल्प हैं. (पूरी सूची यहां दी गई है). ध्यान दें कि हर मेट्रिक में लेबल का एक सेट होता है, जिसका इस्तेमाल फ़िल्टर करने और उसे एग्रीगेट करने के लिए किया जा सकता है. जैसे: destination_service, source_workload_namespace, प्रतिक्रिया_code, istio_tcp_received_bytes_total वगैरह).

6. अब आइए, पहले से तैयार मेट्रिक डैशबोर्ड जोड़ें. हम सीधे Dashboard API का इस्तेमाल करेंगे. यह कुछ ऐसा है जिसे आम तौर पर हैंड-जनरेट एपीआई कॉल के ज़रिए नहीं किया जाता. यह किसी ऑटोमेशन सिस्टम का हिस्सा होगा या आपको वेब यूज़र इंटरफ़ेस (यूआई) में मैन्युअल तरीके से डैशबोर्ड बनाना होगा. इससे हम जल्द ही काम शुरू कर देंगे:

sed -i 's/OPS_PROJECT/'${TF_VAR_ops_project_name}'/g' \
$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
OAUTH_TOKEN=$(gcloud auth application-default print-access-token)
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards \
 -d @$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
 

7. नया जोड़ा गया "सेवाओं का डैशबोर्ड" देखने के लिए, नीचे दिए गए आउटपुट लिंक पर जाएं.

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 
 

हम UX का इस्तेमाल करके डैशबोर्ड में बदलाव कर सकते थे. हालांकि, हमारे मामले में हम एपीआई का इस्तेमाल करके तुरंत एक नया ग्राफ़ जोड़ने वाले हैं. ऐसा करने के लिए, आपको डैशबोर्ड का सबसे नया वर्शन उतारना होगा, अपने बदलाव लागू करने होंगे, और फिर HTTP PATCH तरीके का इस्तेमाल करके वापस ऊपर की ओर धकेलना होगा.

8. मॉनिटरिंग एपीआई से क्वेरी करके, किसी मौजूदा डैशबोर्ड को ऐक्सेस किया जा सकता है. वह मौजूदा डैशबोर्ड पाएं जिसे अभी-अभी जोड़ा गया है:

curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash > /tmp/services-dashboard.json
 

9. नया ग्राफ़ जोड़ें: (50वां %ile प्रतीक्षा अवधि): [ API संदर्भ] अब हम अपने डैशबोर्ड में कोड में एक नया ग्राफ़ विजेट जोड़ सकते हैं. मिलते-जुलते ऐप्लिकेशन, इस बदलाव की समीक्षा कर सकते हैं और वर्शन कंट्रोल में जाकर इसकी जांच कर सकते हैं. यहां जोड़ने के लिए एक विजेट दिया गया है, जो 50%प्रतीक्षा समय (मीडियन इंतज़ार का समय) दिखाता है.

अभी-अभी मिले डैशबोर्ड में बदलाव करने की कोशिश करें और एक नया छंद जोड़ें:

NEW_CHART=${WORKDIR}/asm/k8s_manifests/prod/app-telemetry/new-chart.json
jq --argjson newChart "$(<$NEW_CHART)" '.gridLayout.widgets += [$newChart]' /tmp/services-dashboard.json > /tmp/patched-services-dashboard.json
 

10. मौजूदा सेवाओं का डैशबोर्ड अपडेट करें:

curl -X PATCH -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash \
 -d @/tmp/patched-services-dashboard.json
 

11. अपडेट किया गया डैशबोर्ड देखने के लिए, इस आउटपुट लिंक पर जाएं:

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 

12. कुछ आसान लॉग विश्लेषण करें.

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

उदाहरण के तौर पर दी गई लॉग एंट्री (इस मामले में, Envoy प्रॉक्सी का ऐक्सेसलॉग) इस तरह से दिख सकता है (काट-छांट की गई):

*** DO NOT PASTE *** 
 logName: "projects/PROJECTNAME-11932-01-ops/logs/server-tcp-accesslog-stackdriver.instance.istio-system" 
labels: {
  connection_id: "fbb46826-96fd-476c-ac98-68a9bd6e585d-1517191"   
  destination_app: "redis-cart"   
  destination_ip: "10.16.1.7"   
  destination_name: "redis-cart-6448dcbdcc-cj52v"   
  destination_namespace: "cart"   
  destination_owner: "kubernetes://apis/apps/v1/namespaces/cart/deployments/redis-cart"   
  destination_workload: "redis-cart"   
  source_ip: "10.16.2.8"   
  total_received_bytes: "539"   
  total_sent_bytes: "569" 
...  
 }

अपने लॉग यहां देखें:

echo "https://console.cloud.google.com/logs/viewer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

आप संसाधन > को चुनकर Istio के कंट्रोल प्लेन लॉग देख सकते हैं Kubernetes कंटेनर और "pilot" पर खोज रहे हैं —

यहां पर हम देख सकते हैं कि क्या Istio Control Plane का है कि किस ऐप्लिकेशन सेवा के सैंपल के लिए, साइडकार प्रॉक्सी में प्रॉक्सी कॉन्फ़िगरेशन को पुश किया जा रहा है. "सीडीएस," "एलडीएस" और "आरडीएस" अलग-अलग Envoy एपीआई दिखाते हैं ( ज़्यादा जानकारी).

Istio के लॉग के अलावा, कंटेनर लॉग के साथ-साथ इन्फ़्रास्ट्रक्चर या GCP की अन्य सेवाओं के लॉग भी एक ही इंटरफ़ेस में देखे जा सकते हैं. यहां GKE (जीकेई) के लिए सैंपल लॉग क्वेरी दी गई हैं. लॉग व्यूअर की मदद से, लॉग से बाहर भी मेट्रिक बनाई जा सकती हैं (उदाहरण के लिए: "किसी स्ट्रिंग से मेल खाने वाली हर गड़बड़ी की गिनती करें"), जिसका इस्तेमाल डैशबोर्ड पर या अलर्ट के हिस्से के रूप में किया जा सकता है. लॉग को BigQuery जैसे अन्य विश्लेषण टूल पर भी स्ट्रीम किया जा सकता है.

हिपस्टर शॉप के लिए कुछ सैंपल फ़िल्टर:

resource.type="k8s_container" labels.destination_app="productcatalogservice"

resource.type="k8s_container" resource.labels.namespace_name="cart"

13. डिस्ट्रिब्यूट किए गए ट्रेस देखें.

डिस्ट्रिब्यूटेड सिस्टम का इस्तेमाल करने की वजह से, अब डीबग करने के लिए एक नए टूल की ज़रूरत है: डिस्ट्रिब्यूटेड ट्रेसिंग. यह टूल आपको इस बारे में आंकड़े खोजने की सुविधा देता है कि आपकी सेवाएं कैसे इंटरैक्ट कर रही हैं (जैसे कि नीचे दी गई तस्वीर में धीमी घटनाओं के बारे में पता लगाना), साथ ही असल में चल रही गतिविधियों की जानकारी की जांच करने के लिए रॉ सैंपल ट्रेस का इस्तेमाल करती है.

टाइमलाइन व्यू में, समय के साथ मिलने वाले सभी अनुरोध दिखते हैं. इन्हें हिपस्टर स्टैक की मदद से, इंतज़ार के समय या शुरुआती अनुरोध के बीच बिताए गए समय के हिसाब से ग्राफ़ में दिखाया जाता है. ऐसा इसलिए किया जाता है, ताकि असली उपयोगकर्ता को जवाब दिया जा सके. बिंदु जितने ज़्यादा होंगे, उपयोगकर्ता का अनुभव उतना ही धीमा (और कम अच्छा!) होगा.

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

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

यहां आपको अपने ट्रेस मिल सकते हैं:

echo "https://console.cloud.google.com/traces/overview?cloudshell=false&project=$TF_VAR_ops_project_name"
 

टूल के उदाहरण का स्क्रीनशॉट:

9. म्यूचुअल TLS ऑथेंटिकेशन

मकसद: माइक्रोसर्विस (AuthN) के बीच सुरक्षित कनेक्टिविटी.

• मेश वाइड mTLS चालू करें
• लॉग की जांच करके mTLS की पुष्टि करें

फ़ास्ट ट्रैक स्क्रिप्ट

अगर यह तरीका चुना जाता है, तो इस लैब को पूरा करने के लिए, यहां दी गई स्क्रिप्ट चलाएं.

${WORKDIR}/asm/fasttrack_scripts/mutual-tls.sh

कॉपी-और-पेस्ट करने की विधि चुनने वाले लैब से जुड़े निर्देश

अगर आपने इस लैब के लिए फ़ास्ट ट्रैक स्क्रिप्ट पहले ही पूरी कर ली है, तो कॉपी करने और चिपकाने के लिए यहां दिया गया तरीका न अपनाएं**.**

अब जब हमारे ऐप्लिकेशन इंस्टॉल हो गए हैं और निगरानी करने की सुविधा सेट अप हो गई है, तो हम सेवाओं के बीच कनेक्शन सुरक्षित करना शुरू कर सकते हैं और पक्का कर सकते हैं कि वे काम करते रहें.

उदाहरण के लिए, Kiali डैशबोर्ड पर देखा जा सकता है कि हमारी सेवाएं MTLS का इस्तेमाल नहीं कर रही हैं. ("लॉक" आइकॉन नहीं). हालांकि, ट्रैफ़िक फ़्लो हो रहा है और सिस्टम ठीक से काम कर रहा है. हमारा StackDriver गोल्डन मेट्रिक डैशबोर्ड है और हमें निश्चिंत महसूस हो रहा है कि चीज़ें काम कर रही हैं.

1. ऑपरेशन क्लस्टर में MeshPolicy देखें. ध्यान दें कि mTLS, एन्क्रिप्ट (सुरक्षित) किए गए और बिना mTLS, दोनों तरह के ट्रैफ़िक के लिए PERMISSIVE है.

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq '.items[].spec'
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq '.items[].spec'
 

    `Output (do not copy)`

{
  "peers": [
    {
      "mtls": {
        "mode": "PERMISSIVE"
      }
    }
  ]
}

Istio को सभी क्लस्टर पर, Istio ऑपरेटर का इस्तेमाल करके कॉन्फ़िगर किया जाता है. यह ऑपरेटर, IstioControlPlane कस्टम रिसॉर्स (सीआर) का इस्तेमाल करता है. हम IstioControlPlane CR को अपडेट करके और k8s-repo को अपडेट करके, सभी क्लस्टर में mTLS को कॉन्फ़िगर करेंगे. वैश्विक सेटिंग > एमटीएलएस > सक्षम किया गया: यह IstioControlPlane CR के परिणामों में Istio कंट्रोल प्लेन में निम्न दो बदलावों को लागू करता है:

• सभी क्लस्टर में चल रही सभी सेवाओं के लिए, MeshPolicy सुविधा को mTLS मेश-वाइड मोड चालू करने के लिए सेट किया गया है.
• सभी क्लस्टर में चल रही सेवाओं के बीच ISTIO_MUTUAL ट्रैफ़िक को अनुमति देने के लिए एक गंतव्य नियम बनाया गया है.

2. हम mTLS क्लस्टर को चालू करने के लिए, istioControlPlane सीआर में kustomize पैच लागू करेंगे. पैच को सभी क्लस्टर के लिए, सही डायरेक्ट्री में कॉपी करें और कस्टम पैच जोड़ें.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml
 

3. k8s-repo पर जाएं.

cd $WORKDIR/k8s-repo
git add . && git commit -am "turn mTLS on"
git push
 

4. पहले से खोले गए टैब में या नीचे दिए गए लिंक पर क्लिक करके, Ops प्रोजेक्ट Cloud Build की स्थिति देखें:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

 

mTLS की पुष्टि करें

5. ऑपरेशन क्लस्टर में, MeshPolicy को एक बार फिर से देखें. ध्यान दें कि mTLS अब PERMISSIVE नहीं है और यह सिर्फ़ mTLS ट्रैफ़िक के लिए इस्तेमाल करेगा.

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq .items[].spec
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq .items[].spec
 

आउटपुट (कॉपी न करें):

{
  "peers": [
    {
      "mtls": {}
    }
  ]
}

6. Istio ऑपरेटर कंट्रोलर के डेस्टिनेशन नियम के बारे में बताएं.

kubectl --context $OPS_GKE_1 get DestinationRule default -n istio-system -o json | jq '.spec'
kubectl --context $OPS_GKE_2 get DestinationRule default -n istio-system -o json | jq '.spec'

आउटपुट (कॉपी न करें):

{
    host: '*.local',
    trafficPolicy: {
      tls: {
        mode: ISTIO_MUTUAL
      }
   }
}

हम लॉग में, एचटीटीपी से एचटीटीपीएस पर जाने की जानकारी भी देख सकते हैं.

हम एक लॉग प्रविष्टि पर क्लिक करके और फिर उस फ़ील्ड के मान पर क्लिक करके यूज़र इंटरफ़ेस (यूआई) में लॉग से इस विशेष फ़ील्ड को प्रदर्शित कर सकते हैं, जिसे आप दिखाना चाहते हैं, हमारे मामले में, "http" पर क्लिक करें तो "प्रोटोकॉल:

यह बदलाव को विज़ुअलाइज़ करने का एक अच्छा तरीका है.:

10. कैनरी डिप्लॉयमेंट

मकसद: फ़्रंटएंड सेवा का नया वर्शन लॉन्च करना.

• frontend-v2 (प्रोडक्शन वर्शन का अगला वर्शन) सेवा को एक क्षेत्र में रोल आउट करें
• frontend-v2 की ओर ट्रैफ़िक को धीरे-धीरे ले जाने के लिए, DestinationRules और VirtualServices का इस्तेमाल करें
• k8s-repo के लिए कमिट की सीरीज़ की जांच करके GitOps डिप्लॉयमेंट पाइपलाइन की पुष्टि करें

फ़ास्ट ट्रैक स्क्रिप्ट

अगर यह तरीका चुना जाता है, तो इस लैब को पूरा करने के लिए, यहां दी गई स्क्रिप्ट चलाएं.

${WORKDIR}/asm/fasttrack_scripts/canary-deployments.sh

कॉपी-और-पेस्ट करने की विधि चुनने वाले लैब से जुड़े निर्देश

अगर आपने इस लैब के लिए फ़ास्ट ट्रैक स्क्रिप्ट पहले ही पूरी कर ली है, तो कॉपी करने और चिपकाने के लिए यहां दिया गया तरीका न अपनाएं**.**

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

इस सेक्शन में, फ़्रंटएंड सेवा के नए वर्शन के लिए बेसिक कैनरी डिप्लॉयमेंट बनाने के लिए, Cloud Build और Istio की ट्रैफ़िक नीतियों को इस्तेमाल करने का तरीका बताया गया है.

सबसे पहले, हम DEV1 क्षेत्र (us-west1) में कैनरी पाइपलाइन चलाएंगे और उस क्षेत्र में दोनों क्लस्टर पर फ़्रंटएंड v2 रोल आउट करेंगे. दूसरा, हम DEV2 क्षेत्र (us-central) में कैनरी पाइपलाइन चलाएंगे और उस इलाके में दोनों क्लस्टर पर v2 को डिप्लॉय करेंगे. सभी इलाकों के लिए समान क्रम में पाइपलाइन चलाने से, गलत कॉन्फ़िगरेशन या v2 ऐप्लिकेशन में मौजूद गड़बड़ियों की वजह से दुनिया भर में होने वाली रुकावटों से बचा जा सकता है.

ध्यान दें: हम कैनरी पाइपलाइन को दोनों इलाकों में मैन्युअल तरीके से ट्रिगर करेंगे. हालांकि, प्रोडक्शन में आपको ऑटोमेटेड ट्रिगर का इस्तेमाल करना होगा. उदाहरण के लिए, यह रजिस्ट्री में पुश किए गए नए Docker इमेज टैग पर आधारित होगा.

1. Cloud Shell से, बाकी कमांड को आसानी से चलाने के लिए कुछ एनवी वैरिएबल तय करें.

CANARY_DIR="$WORKDIR/asm/k8s_manifests/prod/app-canary/"
K8S_REPO="$WORKDIR/k8s-repo"
 

2. बेसलाइन मेनिफ़ेस्ट को k8s-repo में कॉपी करने के लिए, repo_setup.sh स्क्रिप्ट चलाएं.

$CANARY_DIR/repo-setup.sh 
 

ये मेनिफ़ेस्ट कॉपी किए गए हैं:

• frontend-v2 डिप्लॉयमेंट
• frontend-v1 पैच ("v1" लेबल और "/version" एंडपॉइंट वाली इमेज शामिल करने के लिए)
• respy, एक छोटा पॉड जो एचटीटीपी रिस्पॉन्स डिस्ट्रिब्यूशन को प्रिंट करेगा और रीयल टाइम में कैनरी डिप्लॉयमेंट को विज़ुअलाइज़ करने में हमारी मदद करेगा.
• फ़्रंटएंड Istio DestinationRule - फ़्रंटएंड Kubernetes सेवा को "वर्शन" के आधार पर दो सबसेट v1 और v2 में बांटती है डिप्लॉयमेंट लेबल
• Fronend Istio VirtualService - ट्रैफ़िक का 100% फ़्रंटएंड v1 पर भेज देता है. इससे Kubernetes Service के डिफ़ॉल्ट राउंड-रॉबिन के व्यवहार को बदला जा सकता है. इसलिए, Dev1 के सभी रीजनल ट्रैफ़िक का 50% फ़्रंटएंड v2 पर तुरंत भेज दिया जाएगा.

3. k8s_repo में बदलाव करें:

cd $K8S_REPO 
git add . && git commit -am "frontend canary setup"
git push
 

4. पहले से खोले गए टैब में या नीचे दिए गए लिंक पर क्लिक करके, Ops प्रोजेक्ट Cloud Build की स्थिति देखें:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}" 
 

5. OPS1 प्रोजेक्ट के लिए, कंसोल में Cloud Build पर जाएं. Cloud Build पाइपलाइन के पूरा होने का इंतज़ार करें. इसके बाद, दोनों DEV1 क्लस्टर में, फ़्रंटएंड नेमस्पेस में पॉड पाएं. आपको यह जानकारी दिखेगी:

watch -n 1 kubectl --context $DEV1_GKE_1 get pods -n frontend 
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
frontend-578b5c5db6-h9567      2/2     Running   0          59m
frontend-v2-54b74fc75b-fbxhc   2/2     Running   0          2m26s
respy-5f4664b5f6-ff22r         2/2     Running   0          2m26s

ध्यान दें: स्मार्टवॉच के निर्देशों से बाहर निकलने के लिए, Ctrl-C दबाएं

हम अपनी क्लाउडशेल विंडो को दो पैनल में बांटने के लिए, tmux का इस्तेमाल करेंगे:

• सबसे नीचे मौजूद पैनल में, फ़्रंटएंड सेवा के लिए एचटीटीपी रिस्पॉन्स डिस्ट्रिब्यूशन के बारे में निगरानी करने का निर्देश दिया जाएगा.
• सबसे ऊपर वाले पैनल पर, कैनरी पाइपलाइन स्क्रिप्ट चल रही होगी.

6. क्लाउड शेल विंडो को स्प्लिट करने के लिए कमांड चलाएं और सबसे नीचे मौजूद पैनल में स्मार्टवॉच के निर्देश को एक्ज़ीक्यूट करें.

RESPY_POD=$(kubectl --context $DEV1_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV1_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

आउटपुट (कॉपी न करें)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

हमने देखा है कि पूरा ट्रैफ़िक, फ़्रंटएंड v1 डिप्लॉयमेंट पर जा रहा है. इसके बारे में नई VirtualService में बताया गया है.

7. Dev1 क्षेत्र पर कैनरी पाइपलाइन चलाएं. हम एक ऐसी स्क्रिप्ट उपलब्ध कराते हैं जो VirtualService में फ़्रंटएंड-v2 ट्रैफ़िक प्रतिशत को अपडेट करती है (वेट को 20%, 50%, 80%, और उसके बाद 100%) अपडेट किया जाता है. अपडेट के दौरान, स्क्रिप्ट Cloud Build के काम करने की पाइपलाइन के पूरा होने का इंतज़ार करती है. Dev1 क्षेत्र के लिए कैनरी डिप्लॉयमेंट स्क्रिप्ट चलाएं. ध्यान दें - इस स्क्रिप्ट को पूरा होने में करीब 10 मिनट लगते हैं.

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_1_CLUSTER OPS_CONTEXT=$OPS_GKE_1 \
${CANARY_DIR}/auto-canary.sh
 

रीयल टाइम में ट्रैफ़िक का बंटवारा, सबसे नीचे वाली विंडो में देखा जा सकता है, जहां respy कमांड चलाया जा रहा है. उदाहरण के लिए, 20% के निशान पर :

आउटपुट (कॉपी न करें)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 79.4%             |
|          |                   |
| v2       | 20.6%             |
|          |                   |
+----------+-------------------+

8. जब फ़्रंटएंड-v2 के लिए Dev2 का रोल आउट पूरा हो जाता है, तब आपको स्क्रिप्ट के आखिर में सफल होने का मैसेज दिखेगा:

    Output (do not copy) 
   

✅ 100% successfully deployed
🌈 frontend-v2 Canary Complete for gke-asm-1-r1-prod

9. साथ ही, Dev2 पॉड से आने वाले सभी फ़्रंटएंड ट्रैफ़िक को फ़्रंटएंड-v2 पर जाना चाहिए:

    Output (do not copy) 
   

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

10. स्प्लिट पैनल को बंद करें.

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'
 

11. जनरेट किए गए लिंक पर, Cloud Source Repos पर जाएं.

echo https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo

आपको हर ट्रैफ़िक प्रतिशत के लिए अलग-अलग प्रतिबद्धता दिखाई देगी, जिसमें सबसे हाल की प्रतिबद्धता सूची में सबसे ऊपर होगी:

अब, Dev2 क्षेत्र के लिए भी यही प्रोसेस दोहराएं. ध्यान दें कि Dev2 क्षेत्र अब भी "लॉक" है v1. ऐसा इसलिए है, क्योंकि बेसलाइन repo_setup स्क्रिप्ट में, हमने एक VirtualService को सभी ट्रैफ़िक को साफ़ तौर पर v1 पर भेजने के लिए पुश किया है. इस तरह, हम Dev1 पर सुरक्षित तरीके से एक रीजनल कैनरी बना पाए. साथ ही, हम यह पक्का कर पाए कि दुनिया भर में नए वर्शन को रोल आउट करने से पहले, हम सही तरीके से काम कर पाए.

12. क्लाउड शेल विंडो को स्प्लिट करने के लिए कमांड चलाएं और सबसे नीचे मौजूद पैनल में स्मार्टवॉच के निर्देश को एक्ज़ीक्यूट करें.

RESPY_POD=$(kubectl --context $DEV2_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV2_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

आउटपुट (कॉपी न करें)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

हमने देखा है कि पूरा ट्रैफ़िक, फ़्रंटएंड v1 डिप्लॉयमेंट पर जा रहा है. इसके बारे में नई VirtualService में बताया गया है.

13. Dev2 क्षेत्र पर कैनरी पाइपलाइन चलाएं. हम एक ऐसी स्क्रिप्ट उपलब्ध कराते हैं जो VirtualService में फ़्रंटएंड-v2 ट्रैफ़िक प्रतिशत को अपडेट करती है (वेट को 20%, 50%, 80%, और उसके बाद 100%) अपडेट किया जाता है. अपडेट के दौरान, स्क्रिप्ट Cloud Build के काम करने की पाइपलाइन के पूरा होने का इंतज़ार करती है. Dev1 क्षेत्र के लिए कैनरी डिप्लॉयमेंट स्क्रिप्ट चलाएं. ध्यान दें - इस स्क्रिप्ट को पूरा होने में करीब 10 मिनट लगते हैं.

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_2_CLUSTER OPS_CONTEXT=$OPS_GKE_2 \
${CANARY_DIR}/auto-canary.sh
 

आउटपुट (कॉपी न करें)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

14. Dev2 में Respy पॉड से, Dev2 पॉड के ट्रैफ़िक को फ़्रंटएंड v1 से v2 में धीरे-धीरे जाते हुए देखें. स्क्रिप्ट पूरी हो जाने पर, आपको यह दिखेगा:

आउटपुट (कॉपी न करें)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

15. स्प्लिट पैनल को बंद करें.

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'

इस सेक्शन में, क्षेत्रीय कैनरी डिप्लॉयमेंट के लिए Istio इस्तेमाल करने का तरीका बताया गया है. प्रोडक्शन में, मैन्युअल स्क्रिप्ट के बजाय, इस कैनरी स्क्रिप्ट को Cloud Build पाइपलाइन के तौर पर अपने-आप ट्रिगर किया जा सकता है. ऐसा ट्रिगर का इस्तेमाल करके किया जा सकता है. जैसे, कंटेनर रजिस्ट्री में टैग की गई नई इमेज को पुश करना. आपको हर चरण के बीच में कैनरी विश्लेषण भी जोड़ना चाहिए. ज़्यादा ट्रैफ़िक भेजने से पहले, पहले से तय सुरक्षा थ्रेशोल्ड के हिसाब से वर्शन 2 की इंतज़ार के समय और गड़बड़ी की दर का विश्लेषण किया जा सकता है.

11. अनुमति देने से जुड़ी नीतियां

मकसद: माइक्रोसर्विस (AuthZ) के बीच आरबीएसी सेट अप करना.

• माइक्रोसेवा का ऐक्सेस अस्वीकार करने के लिए, AuthorizationPolicy बनाएं
• माइक्रोसेवा का खास ऐक्सेस देने के लिए, AuthorizationPolicy बनाएं

फ़ास्ट ट्रैक स्क्रिप्ट

अगर यह तरीका चुना जाता है, तो इस लैब को पूरा करने के लिए, यहां दी गई स्क्रिप्ट चलाएं.

${WORKDIR}/asm/fasttrack_scripts/authorization-policy.sh

कॉपी-और-पेस्ट करने की विधि चुनने वाले लैब से जुड़े निर्देश

अगर आपने इस लैब के लिए फ़ास्ट ट्रैक स्क्रिप्ट पहले ही पूरी कर ली है, तो कॉपी करने और चिपकाने के लिए यहां दिया गया तरीका न अपनाएं**.**

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

Istio की नीतियों में, पुष्टि करने और अनुमति देने, दोनों पर पाबंदी है. पुष्टि करने की सुविधा, पहचान की पुष्टि करती है (क्या यह सर्वर वे कहते हैं जो वे कहते हैं?) और अनुमति से अनुमतियों की पुष्टि की जाती है (क्या इस क्लाइंट को ऐसा करने की अनुमति है?). हमने मॉड्यूल 1 (MeshPolicy) में दिए गए म्युचुअल TLS सेक्शन में Istio की पुष्टि करने की प्रक्रिया के बारे में बताया है. इस सेक्शन में, हम अपने किसी एक ऐप्लिकेशन वर्कलोड, currencyservice के ऐक्सेस को कंट्रोल करने के लिए Istio की अनुमति देने से जुड़ी नीतियों का इस्तेमाल करने का तरीका जानेंगे.

सबसे पहले, हम चारों डेवलपर क्लस्टर में AuthorizationPolicy डिप्लॉय करेंगे. साथ ही, मुद्रा सेवा का सभी ऐक्सेस बंद करेंगे और फ़्रंटएंड में गड़बड़ी ट्रिगर करेंगे. इसके बाद, हम सिर्फ़ फ़्रंटएंड सेवा को मुद्रा सेवा ऐक्सेस करने की अनुमति देंगे.

1. currency-deny-all.yaml के कॉन्टेंट की जांच करें. इस नीति में, मुद्रा सेवा के ऐक्सेस को सीमित करने के लिए डिप्लॉयमेंट लेबल सिलेक्टर का इस्तेमाल किया जाता है. ध्यान दें कि कोई spec फ़ील्ड कैसे नहीं होता - इसका मतलब है कि यह नीति चुनी गई सेवा का पूरा ऐक्सेस नहीं देगी.

cat $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml
 

आउटपुट (कॉपी न करें)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice

2. दोनों क्षेत्रों में ऑपरेशन क्लस्टर के लिए, मुद्रा नीति को k8s-repo में कॉपी करें.

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml

3. पुश बदलाव.

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: deny all"
git push 

4. पहले से खोले गए टैब में या नीचे दिए गए लिंक पर क्लिक करके, Ops प्रोजेक्ट Cloud Build की स्थिति देखें:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name 
 

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

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

आपको मुद्रा सेवा से अनुमति देने से जुड़ी गड़बड़ी दिखेगी:

6. चलिए देखते हैं कि मुद्रा सेवा इस AuthorizationPolicy को कैसे लागू कर रही है. सबसे पहले, किसी एक करंसी पॉड के लिए, Envoy प्रॉक्सी पर ट्रेस-लेवल के लॉग चालू करें. ऐसा इसलिए, क्योंकि ब्लॉक किए गए ऑथराइज़ेशन कॉल, डिफ़ॉल्ट रूप से लॉग नहीं होते हैं.

CURRENCY_POD=$(kubectl --context $DEV1_GKE_2 get pod -n currency | grep currency| awk '{ print $1 }')
kubectl --context $DEV1_GKE_2 exec -it $CURRENCY_POD -n \
currency -c istio-proxy -- curl -X POST \
"http://localhost:15000/logging?level=trace"
 

7. मुद्रा सेवा की साइडकार प्रॉक्सी से आरबीएसी (अनुमति) लॉग पाएं. आपको "लागू करने की अनुमति नहीं दी गई" मैसेज दिखेगा से पता चलता है कि मुद्रा सेवा, बाहर से आने वाले सभी अनुरोधों को ब्लॉक करने के लिए सेट है.

kubectl --context $DEV1_GKE_2 logs -n currency $CURRENCY_POD \
-c istio-proxy | grep -m 3 rbac
 

आउटपुट (कॉपी न करें)

[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:67] checking request: remoteAddress: 10.16.5.15:37310, localAddress: 10.16.3.8:7000, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/frontend/sa/frontend, subjectPeerCertificate: , headers: ':method', 'POST'
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:118] enforced denied
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1354] [C115][S17310331589050212978] Sending local reply with details rbac_access_denied

8. आइए, अब फ़्रंटएंड को अनुमति दें – लेकिन दूसरी बैकएंड सेवाओं को मुद्रा सेवा ऐक्सेस करने की अनुमति नहीं देते. currency-allow-frontend.yaml खोलें और इसके कॉन्टेंट की जांच करें. ध्यान दें कि हमने यह नियम जोड़ा है:

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml

आउटपुट (कॉपी न करें)

rules:
 - from:
   - source:
       principals: ["cluster.local/ns/frontend/sa/frontend"]

यहां हम मुद्रा सेवा को ऐक्सेस करने के लिए, किसी खास source.principal (क्लाइंट) को अनुमति दे रहे हैं. यह source.principal, Kubernetes सेवा खाता से तय करता है. इस मामले में, हम जिस सेवा खाते को व्हाइटलिस्ट कर रहे हैं वह फ़्रंटएंड नेमस्पेस में फ़्रंटएंड सेवा खाता है.

ध्यान दें: Istio AuthorizationPolicy में Kubernetes सेवा खातों का इस्तेमाल करते समय, सबसे पहले आपको क्लस्टर-वाइड म्युचुअल TLS चालू करना होगा, जैसा कि हमने मॉड्यूल 1 में किया था. इससे यह पक्का होता है कि सेवा खाते के क्रेडेंशियल, अनुरोधों में माउंट किए गए हैं.

9. अपडेट की गई मुद्रा नीति को कॉपी करें

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

10. पुश बदलाव.

cd $WORKDIR/k8s-repo
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend"
git push
 

11. पहले से खोले गए टैब में या नीचे दिए गए लिंक पर क्लिक करके, Ops प्रोजेक्ट Cloud Build की स्थिति देखें:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name

12. बिल्ड पूरा होने के बाद, हिपस्टरशॉप फ़्रंटएंड फिर से खोलें. इस बार होम पेज पर आपको कोई गड़बड़ी नहीं दिखेगी - ऐसा इसलिए है, क्योंकि फ़्रंटएंड को साफ़ तौर पर मौजूदा सेवा को ऐक्सेस करने की अनुमति है.
13. अब अपने कार्ट में आइटम जोड़कर और "ऑर्डर करें" पर क्लिक करके, चेकआउट करने की कोशिश करें. इस बार, आपको मुद्रा सेवा से कीमत और कन्वर्ज़न से जुड़ी गड़बड़ी दिख सकती है - ऐसा इसलिए है, क्योंकि हमने सिर्फ़ फ़्रंटएंड को अनुमति दी है. इसलिए, चेकआउट सेवा अब भी मुद्रा सेवा को ऐक्सेस नहीं कर पा रही है.

14. आखिर में, चलिए, चेकआउट सेवा को मुद्रा का ऐक्सेस देते हैं. इसके लिए, हमारी मुद्रा सेवा की अनुमति देने की नीति में एक और नियम जोड़ें. ध्यान दें कि हम सिर्फ़ उन दो सेवाओं के लिए मुद्रा का ऐक्सेस दे रहे हैं जिनके लिए इसे ऐक्सेस करना ज़रूरी है - फ़्रंटएंड और चेकआउट. अन्य बैकएंड अब भी ब्लॉक रहेंगे.
15. currency-allow-frontend-checkout.yaml खोलें और इसके कॉन्टेंट की जांच करें. ध्यान दें कि नियमों की सूची, लॉजिकल OR - मुद्रा के तौर पर काम करती है. मुद्रा सिर्फ़ इन दोनों सेवा खातों में से किसी एक के साथ वर्कलोड से किए गए अनुरोधों को ही स्वीकार करेगी.

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml
 

आउटपुट (कॉपी न करें)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/checkout/sa/checkout"]

16. अनुमति देने से जुड़ी फ़ाइनल नीति को k8s-repo पर कॉपी करें.

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

17. पुश बदलाव

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend and checkout"
git push
 

18. पहले से खोले गए टैब में या नीचे दिए गए लिंक पर क्लिक करके, Ops प्रोजेक्ट Cloud Build की स्थिति देखें:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name
 

19. बिल्ड पूरा होने के बाद, चेकआउट करने की कोशिश करें. यह सही तरीके से काम करेगा.

इस सेक्शन में, हर सेवा के लेवल पर विस्तृत ऐक्सेस कंट्रोल लागू करने के लिए Istio की अनुमति से जुड़ी नीतियों को इस्तेमाल करने का तरीका बताया गया है. प्रोडक्शन में, आप हर सेवा के लिए एक AuthorizationPolicy बना सकते हैं और (उदाहरण के लिए) एक सभी की अनुमति दें नीति का इस्तेमाल कर सकते हैं, ताकि एक ही नेमस्पेस में मौजूद सभी वर्कलोड एक-दूसरे को ऐक्सेस कर सकें.

12. अधोसंरचना स्केलिंग

मकसद: नया क्षेत्र, प्रोजेक्ट, और क्लस्टर जोड़कर इन्फ़्रास्ट्रक्चर को बढ़ाना.

• infrastructure रेपो का क्लोन बनाएं
• नए संसाधन बनाने के लिए टेराफ़ॉर्म फ़ाइलों को अपडेट करें
• नए क्षेत्र में दो सबनेट (एक ऑपरेशन प्रोजेक्ट के लिए और दूसरा नए प्रोजेक्ट के लिए)
• नए क्षेत्र में नए ऑपरेशन क्लस्टर (नए सबनेट में)
• नए इलाके के लिए नया Istio कंट्रोल प्लेन
• नए क्षेत्र में नए प्रोजेक्ट में दो ऐप्लिकेशन क्लस्टर बनाए गए हैं
• infrastructure रेपो रखें
• इंस्टॉल हो जाने की पुष्टि करें

फ़ास्ट ट्रैक स्क्रिप्ट

अगर यह तरीका चुना जाता है, तो इस लैब को पूरा करने के लिए, यहां दी गई स्क्रिप्ट चलाएं.

${WORKDIR}/asm/fasttrack_scripts/infrastructure-scaling.sh

कॉपी-और-पेस्ट करने की विधि चुनने वाले लैब से जुड़े निर्देश

अगर आपने इस लैब के लिए फ़ास्ट ट्रैक स्क्रिप्ट पहले ही पूरी कर ली है, तो कॉपी करने और चिपकाने के लिए यहां दिया गया तरीका न अपनाएं**.**

किसी प्लैटफ़ॉर्म को बढ़ाने के कई तरीके हैं. मौजूदा क्लस्टर में नोड जोड़कर, ज़्यादा कंप्यूट जोड़ी जा सकती हैं. किसी क्षेत्र में और क्लस्टर जोड़े जा सकते हैं. इसके अलावा, प्लैटफ़ॉर्म पर और इलाके भी जोड़े जा सकते हैं. प्लैटफ़ॉर्म के किस पहलू का आकलन करना है, यह ज़रूरी शर्तों के आधार पर तय होता है. उदाहरण के लिए, अगर किसी क्षेत्र के सभी तीन ज़ोन में क्लस्टर हैं, तो मौजूदा क्लस्टर में ज़्यादा नोड (या नोड पूल) जोड़ना काफ़ी हो सकता है. हालांकि, अगर आपके पास एक ही क्षेत्र में तीन में से दो में से दो ज़ोन में क्लस्टर हैं, तो तीसरे ज़ोन में एक नया क्लस्टर जोड़ने से आपको स्केलिंग और एक अतिरिक्त गड़बड़ी डोमेन (यानी एक नया ज़ोन) मिलता है. किसी क्षेत्र में नया क्लस्टर जोड़ने की एक वजह यह भी हो सकती है कि नियमों के पालन या अनुपालन से जुड़ी वजहों से एक ही टेनेंट क्लस्टर बनाना पड़े. उदाहरण के लिए, पीसीआई या ऐसा डेटाबेस क्लस्टर जिसमें व्यक्तिगत पहचान से जुड़ी जानकारी मौजूद हो. आपके कारोबार और सेवाओं का दायरा बढ़ने के साथ-साथ, नए इलाके जोड़ना भी बेहद ज़रूरी हो गया है. इसके आधार पर, आपको ग्राहकों के ज़्यादा करीब सेवाएं देने में मदद मिलेगी.

मौजूदा प्लैटफ़ॉर्म में दो क्षेत्र और हर क्षेत्र के दो ज़ोन में क्लस्टर हैं. इस प्लैटफ़ॉर्म को दो तरीकों से बढ़ाया जा सकता है:

• वर्टिकल - हर क्षेत्र में, ज़्यादा कंप्यूट जोड़ें. ऐसा या तो मौजूदा क्लस्टर में और नोड (या नोड पूल) जोड़कर किया जाता है या क्षेत्र में नए क्लस्टर को जोड़कर किया जाता है. ऐसा, infrastructure रेपो की मदद से किया जाता है. मौजूदा क्लस्टर में नोड जोड़ना सबसे आसान पाथ है. किसी अन्य कॉन्फ़िगरेशन की ज़रूरत नहीं है. नए क्लस्टर को जोड़ने के लिए, अतिरिक्त सबनेट (और सेकंडरी रेंज) की ज़रूरत हो सकती है. साथ ही, फ़ायरवॉल के सही नियम जोड़ने, क्षेत्रीय ASM/Istio सर्विस मेश कंट्रोल प्लेन में नए क्लस्टर जोड़ने, और नए क्लस्टर में ऐप्लिकेशन के संसाधनों को डिप्लॉय करने की ज़रूरत हो सकती है.
• हॉरिज़ॉन्टल - ज़्यादा क्षेत्र जोड़कर. मौजूदा प्लैटफ़ॉर्म पर आपको रीजनल टेंप्लेट मिलता है. इसमें एक क्षेत्रीय ऑपरेशन क्लस्टर होता है, जहां ASM/Istio कंट्रोल मौजूद होते हैं. साथ ही, दो या उससे ज़्यादा ज़ोनल ऐप्लिकेशन क्लस्टर होते हैं, जहां ऐप्लिकेशन के संसाधनों को डिप्लॉय किया जाता है.

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

1. होस्ट प्रोजेक्ट के सबनेट ने नए ऑपरेशन और ऐप्लिकेशन क्लस्टर के लिए, क्षेत्र r3 में VPC को शेयर किया है.
2. क्षेत्र r3 में एक रीजनल ऑपरेशन क्लस्टर है. इस क्लस्टर में ASM/Istio कंट्रोल प्लेन मौजूद है.
3. क्षेत्र r3 पर दो ज़ोन में दो ज़ोनल ऐप्लिकेशन क्लस्टर.
4. k8s-repo पर अपडेट करना:
5. क्षेत्र r3 में, Ops क्लस्टर में ASM/Istio के कंट्रोल प्लेन संसाधनों को डिप्लॉय करें.
6. क्षेत्र r3 के ऐप्लिकेशन क्लस्टर में, ASM/Istio के शेयर किए गए कंट्रोल प्लेन संसाधनों को डिप्लॉय करें.
7. आपको कोई नया प्रोजेक्ट बनाने की ज़रूरत नहीं है. हालांकि, वर्कशॉप में एक नया प्रोजेक्ट dev3 जोड़ने का तरीका बताया गया है, ताकि प्लैटफ़ॉर्म पर नई टीम जोड़ने के इस्तेमाल के उदाहरण को कवर किया जा सके.

इन्फ़्रास्ट्रक्चर रेपो का इस्तेमाल, ऊपर बताए गए नए संसाधनों को जोड़ने के लिए किया जाता है.

1. Cloud Shell में, WorkDIR पर जाएं और infrastructure रेपो का क्लोन बनाएं.

mkdir -p $WORKDIR/infra-repo
cd $WORKDIR/infra-repo
git init && git remote add origin https://source.developers.google.com/p/${TF_ADMIN}/r/infrastructure
git config --local user.email ${MY_USER}
git config --local user.name "infra repo user"
git config --local credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

2. वर्कशॉप सोर्स रेपो add-proj ब्रांच को add-proj-repo डायरेक्ट्री में क्लोन करें.

cd $WORKDIR
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git add-proj-repo -b add-proj

 

3. सोर्स वर्कशॉप रेपो में, add-proj ब्रांच से फ़ाइलें कॉपी करें. add-proj ब्रांच में, इस सेक्शन के बदलाव शामिल होते हैं.

cp -r $WORKDIR/add-proj-repo/infrastructure/* $WORKDIR/infra-repo/
 

4. जोड़ें-proj रेपो डायरेक्ट्री में, infrastructure डायरेक्ट्री को infra-repo डायरेक्ट्री के सिमलिंक से बदलें, ताकि ब्रांच पर मौजूद स्क्रिप्ट काम कर सकें.

rm -rf $WORKDIR/add-proj-repo/infrastructure
ln -s $WORKDIR/infra-repo $WORKDIR/add-proj-repo/infrastructure
 

5. शेयर की गई स्थितियों और वैरिएबल को नए प्रोजेक्ट डायरेक्ट्री स्ट्रक्चर में कॉपी करने के लिए, add-project.sh स्क्रिप्ट चलाएं.

$WORKDIR/add-proj-repo/scripts/add-project.sh app3 $WORKDIR/asm $WORKDIR/infra-repo

6. नया प्रोजेक्ट बनाने के लिए, बदलावों को लागू करें और उन्हें लागू करें

cd $WORKDIR/infra-repo
git add .
git status
git commit -m "add new project" && git push origin master
 

7. यह पुष्टि, नए रिसॉर्स के साथ इन्फ़्रास्ट्रक्चर को डिप्लॉय करने के लिए, infrastructure रेपो को ट्रिगर करती है. Cloud Build में हुई प्रोग्रेस देखने के लिए, नीचे दिए गए लिंक के आउटपुट पर क्लिक करें और सबसे ऊपर सबसे नए बिल्ड पर जाएं.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

इस चरण को पूरा होने में 25 से 30 मिनट लगते हैं. कॉफ़ी ब्रेक के लिए अच्छा समय है.

infrastructure Cloud Build के आखिरी चरण में, k8s-repo में नए Kubernetes संसाधन बनाए जाते हैं. यह k8s-repo (Ops प्रोजेक्ट में) में, Cloud Build को ट्रिगर करता है. नए Kubernetes संसाधन पिछले चरण में जोड़े गए तीन नए क्लस्टर के लिए हैं. ASM/Istio कंट्रोल प्लेन और शेयर किए गए कंट्रोल प्लेन संसाधन, k8s-repo Cloud Build के नए क्लस्टर में जोड़ दिए गए हैं.

8. Cloud Build के इंफ़्रास्ट्रक्चर के काम करने के बाद, k8s-repo के सबसे नए Cloud Build पर जाएं. इसके लिए, नीचे दिए गए आउटपुट लिंक पर क्लिक करें.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

9. नए क्लस्टर को vars और kubeconfig फ़ाइल में जोड़ने के लिए, नीचे दी गई स्क्रिप्ट चलाएं.

$WORKDIR/add-proj-repo/scripts/setup-gke-vars-kubeconfig-add-proj.sh $WORKDIR/asm
 

10. नई kubeconfig फ़ाइल पर ले जाने के लिए KUBECONFIG वैरिएबल को बदलें.

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

11. अपने क्लस्टर के कॉन्टेक्स्ट की सूची बनाएं. आपको आठ क्लस्टर दिखेंगे.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_user001-200204-05-dev1-49tqc4_us-west1-a_gke-1-apps-r1a-prod
gke_user001-200204-05-dev1-49tqc4_us-west1-b_gke-2-apps-r1b-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-a_gke-3-apps-r2a-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-b_gke-4-apps-r2b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-b_gke-5-apps-r3b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-c_gke-6-apps-r3c-prod
gke_user001-200204-05-ops-49tqc4_us-central1_gke-asm-2-r2-prod
gke_user001-200204-05-ops-49tqc4_us-east1_gke-asm-3-r3-prod
gke_user001-200204-05-ops-49tqc4_us-west1_gke-asm-1-r1-prod

Istio इंस्टॉलेशन की पुष्टि करें

12. यह देखें कि सभी पॉड चल रहे हैं और जॉब पूरे हो गए हैं. इससे यह पक्का किया जा सकेगा कि नए ऑपरेशन क्लस्टर में Istio इंस्टॉल किया गया है.

kubectl --context $OPS_GKE_3 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-72g6w                  1/1     Running   0          5h12m
istio-citadel-7d8595845-hmmvj             1/1     Running   0          5h12m
istio-egressgateway-779b87c464-rw8bg      1/1     Running   0          5h12m
istio-galley-844ddfc788-zzpkl             2/2     Running   0          5h12m
istio-ingressgateway-59ccd6574b-xfj98     1/1     Running   0          5h12m
istio-pilot-7c8989f5cf-5plsg              2/2     Running   0          5h12m
istio-policy-6674bc7678-2shrk             2/2     Running   3          5h12m
istio-sidecar-injector-7795bb5888-kbl5p   1/1     Running   0          5h12m
istio-telemetry-5fd7cbbb47-c4q7b          2/2     Running   2          5h12m
istio-tracing-cd67ddf8-2qwkd              1/1     Running   0          5h12m
istiocoredns-5f7546c6f4-qhj9k             2/2     Running   0          5h12m
kiali-7964898d8c-l74ww                    1/1     Running   0          5h12m
prometheus-586d4445c7-x9ln6               1/1     Running   0          5h12m

13. पक्का करें कि dev3 के दोनों क्लस्टर पर Istio इंस्टॉल किया गया हो. dev3 क्लस्टर में सिर्फ़ सिटाडेल, साइडकार-इंजेक्टर, और कोरडन ही रन करता है. इस तरह का एयरप्लेन ops-3 क्लस्टर में चल रहा एक Istio कंट्रोलप्लेन शेयर करता है.

kubectl --context $DEV3_GKE_1 get pods -n istio-system
kubectl --context $DEV3_GKE_2 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

शेयर किए गए कंट्रोल प्लेन के लिए, सेवा खोज की पुष्टि करें

14. पुष्टि करें कि सभी छह ऐप्लिकेशन क्लस्टर के लिए, सभी ऑपरेशन क्लस्टर में सीक्रेट डिप्लॉय किए गए हैं.

kubectl --context $OPS_GKE_1 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_2 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_3 get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      14h
gke-2-apps-r1b-prod   Opaque   1      14h
gke-3-apps-r2a-prod   Opaque   1      14h
gke-4-apps-r2b-prod   Opaque   1      14h
gke-5-apps-r3b-prod   Opaque   1      5h12m
gke-6-apps-r3c-prod   Opaque   1      5h12m

13. सर्किट ब्रेकिंग

मकसद: शिपिंग सेवा के लिए सर्किट ब्रेकर लागू करना.

• सर्किट ब्रेकर लागू करने के लिए, shipping सेवा के लिए DestinationRule बनाएं
• सर्किट ट्रिप करके, shipping सेवा के लिए सर्किट ब्रेकर की पुष्टि करने के लिए, fortio (लोड जेन यूटिलिटी) का इस्तेमाल करें

फ़ास्ट ट्रैक स्क्रिप्ट लैब के निर्देश

फ़ास्ट ट्रैक स्क्रिप्ट लैब जल्द आ रहा है!!

कॉपी-और-पेस्ट करने की विधि चुनने वाले लैब से जुड़े निर्देश

अब जबकि हमने Istio की सुविधा वाली सेवाओं के लिए निगरानी करने और समस्या हल करने के कुछ बुनियादी तरीकों के बारे में जान लिया है, तो आइए देखते हैं कि जानें कि कैसे Istio की मदद से आप अपनी सेवाओं को को बेहतर बनाने में मदद करते हैं. इससे आपको समस्या हल करने में काफ़ी मदद मिलती है.

माइक्रोसर्विस आर्किटेक्चर में कैस्केडिंग फ़ेल होने का जोखिम होता है. इसमें किसी एक सेवा के काम न करने पर, उसकी डिपेंडेंसी और उन डिपेंडेंसी की डिपेंडेंसी हो सकती है. इस वजह से "रिपल इफ़ेक्ट" होता है ऐसा कुछ समय के लिए किया गया है जिसका असर असली उपयोगकर्ताओं पर हो सकता है. Istio, सर्किट ब्रेकर ट्रैफ़िक से जुड़ी नीति उपलब्ध कराता है. इससे आपको सेवाओं को अलग-अलग करने, डाउनस्ट्रीम (क्लाइंट-साइड) सेवाओं के लिए, इंतज़ार न कर पाने वाली सेवाओं से सुरक्षा देने, और अपस्ट्रीम (सर्वर-साइड) सेवाओं को ऑनलाइन आने पर, डाउनस्ट्रीम ट्रैफ़िक से बचाने में मदद मिलती है. कुल मिलाकर, सर्किट ब्रेकर का इस्तेमाल करने से आपको ऐसी सभी सेवाओं से बचने में मदद मिल सकती है जो अपने एसएलओ को सिंक नहीं कर पाते, क्योंकि एक बैकएंड सेवा रुकी हुई है.

सर्किट ब्रेकर पैटर्न का नाम, एक इलेक्ट्रिकल स्विच के नाम पर रखा गया है जो "ट्रिप" कर सकता है जब बिजली बहुत ज़्यादा बहती है, तब डिवाइस को ओवरलोड से बचाया जाता है. Istio के सेटअप में, इसका मतलब है कि Envoy एक सर्किट ब्रेकर है, जो किसी सेवा के लिए लंबित अनुरोधों की संख्या का ट्रैक रखता है. इस डिफ़ॉल्ट क्लोज़्ड स्थिति में, Envoy के ज़रिए बिना किसी रुकावट के अनुरोध भेजे जा सकते हैं.

लेकिन जब लंबित अनुरोधों की संख्या आपके तय किए गए थ्रेशोल्ड से ज़्यादा हो जाती है, तो सर्किट ब्रेकर ट्रिप (खुलता है) और Envoy तुरंत एक गड़बड़ी लौटाता है. इससे क्लाइंट के लिए, सर्वर तेज़ी से फ़ेल हो जाता है. साथ ही, ओवरलोड होने पर, सर्वर ऐप्लिकेशन कोड को क्लाइंट का अनुरोध पाने से रोकता है.

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

इस डायग्राम में इस्टियो सर्किट ब्रेकर पैटर्न की खास जानकारी दी गई है. नीले रंग के रेक्टैंगल, Envoy को दिखाते हैं, नीले रंग के सर्कल से क्लाइंट की जानकारी मिलती है, और सफ़ेद रंग के सर्कल, सर्वर कंटेनर को दिखाते हैं:

IstiodestinationRules का इस्तेमाल करके, सर्किट ब्रेकर से जुड़ी नीतियां तय की जा सकती हैं. इस सेक्शन में, शिपिंग सेवा के लिए सर्किट ब्रेकर लागू करने के लिए, हम यहां दी गई नीति लागू करेंगे:

Output (do not copy)

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "shippingservice-shipping-destrule"
  namespace: "shipping"
spec:
  host: "shippingservice.shipping.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 10s
      maxEjectionPercent: 100

यहां ध्यान देने के लिए दो गंतव्य नियम फ़ील्ड हैं. connectionPool, इस सेवा के तहत काम करने वाले कनेक्शन की संख्या बताता है. बाहरी डिटेक्शन फ़ील्ड वह जगह है जहां हम यह कॉन्फ़िगर करते हैं कि Envoy किस तरह से सर्किट ब्रेकर को खोलने का थ्रेशोल्ड तय करेगा. यहां हर सेकंड (इंटरवल) में, Envoy सर्वर कंटेनर से मिली गड़बड़ियों की संख्या गिनेगा. अगर यह सीमा consecutiveErrors से ज़्यादा हो जाती है, तो Envoy सर्किट ब्रेकर खुल जाएगा. साथ ही, नए क्लाइंट के अनुरोधों से 100% productcatalog पॉड, 10 सेकंड के लिए सुरक्षित हो जाएंगे. Envoy सर्किट ब्रेकर चालू होने (जैसे, चालू) होने पर, क्लाइंट को 503 (सेवा उपलब्ध नहीं है) से जुड़ी गड़बड़ियां मिलेंगी. आइए, इसे काम करते हुए देखते हैं.

1. निर्देशों को आसान बनाने के लिए, k8s-repo और asm di के लिए एनवायरमेंट वैरिएबल सेट करें.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm" 
 

2. k8s-रेपो को अपडेट करना

cd $WORKDIR/k8s-repo
git pull
cd $WORKDIR

3. दोनों ऑपरेशन क्लस्टर पर, शिपिंग सेवा के डेस्टिनेशन नियम को अपडेट करें.

cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml

cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
 

4. Dev1 क्षेत्र के GKE_1 क्लस्टर में, Fortio लोड जनरेटर पॉड को कॉपी करें. इस क्लाइंट पॉड का इस्तेमाल हम "यात्रा" के लिए करेंगे शिपिंग सेवा के लिए सर्किट ब्रेकर.

cp $ASM/k8s_manifests/prod/app/deployments/app-fortio.yaml ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments/
cd ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments; kustomize edit add resource app-fortio.yaml
 

5. बदलाव लागू करें.

cd $K8S_REPO 
git add . && git commit -am "Circuit Breaker: shippingservice"
git push
cd $ASM
 

6. Cloud Build के पूरा होने का इंतज़ार करें.
7. Cloud Shell में वापस जाकर, एक ही समय पर एक कनेक्शन और कुल 1, 000 अनुरोध वाली शिपिंग सेवा को gRPC ट्रैफ़िक भेजने के लिए fortio पॉड का इस्तेमाल करें. इससे सर्किट ब्रेकर से यात्रा नहीं होगी, क्योंकि अभी तक हमने connectionPool की सेटिंग पार नहीं की हैं.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 1 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

आउटपुट (कॉपी न करें)

Health SERVING : 1000
All done 1000 calls (plus 0 warmup) 4.968 ms avg, 201.2 qps

8. अब fortio को फिर से चलाएं और एक साथ मिलने वाले कनेक्शन की संख्या को बढ़ाकर 2 कर दें, लेकिन अनुरोधों की कुल संख्या को स्थिर रखें. हमें अधिकतम दो-तिहाई अनुरोधों को "ओवरफ़्लो" लौटाते हुए देखना चाहिए गड़बड़ी हुई, क्योंकि सर्किट ब्रेकर को ट्रिप कर दिया गया है: हमने जो नीति तय की है उसके मुताबिक, 1-सेकंड के इंटरवल में एक ही समय पर सिर्फ़ एक कनेक्शन की अनुमति है.

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 2 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

आउटपुट (कॉपी न करें)

18:46:16 W grpcrunner.go:107> Error making grpc call: rpc error: code = Unavailable desc = upstream connect error or disconnect/reset before headers. reset reason: overflow
...

Health ERROR : 625
Health SERVING : 375
All done 1000 calls (plus 0 warmup) 12.118 ms avg, 96.1 qps

9. Envoy, सर्किट ब्रेकर के चालू होने पर छोड़े गए कनेक्शन की संख्या का ट्रैक रखता है. इसके लिए, यह upstream_rq_pending_overflow मेट्रिक की मदद लेता है. चलिए, इसे fortio पॉड में खोजते हैं:

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep shipping | grep pending
 

आउटपुट (कॉपी न करें)

cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.default.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.high.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_active: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_failure_eject: 9
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_overflow: 565
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_total: 1433

10. साफ़-सफ़ाई के लिए, दोनों इलाकों से सर्किट ब्रेकर नीति को हटाएं.

kubectl --context ${OPS_GKE_1} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
 

kubectl --context ${OPS_GKE_2} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
cd $K8S_REPO; git add .; git commit -m "Circuit Breaker: cleanup"; git push origin master
 

इस सेक्शन में, किसी सेवा के लिए एक सर्किट ब्रेकर नीति सेट अप करने का तरीका बताया गया है. सबसे सही तरीका यह है कि किसी भी अपस्ट्रीम (बैकएंड) सेवा के लिए सर्किट ब्रेकर सेट अप किया जाए, जो हैंग हो सकता है. इस्टियो सर्किट ब्रेकर नीतियों को लागू करके, आप अपनी माइक्रोसेवाओं को अलग करने में मदद करते हैं, आपके सिस्टम में गड़बड़ी को सहन करते हैं, और बहुत ज़्यादा लोड होने पर कैस्केडिंग के फ़ेल होने का जोखिम कम करते हैं.

14. फ़ॉल्ट इंजेक्शन

मकसद: यह पता लगाने के लिए कि सुझाव देने वाली सेवा में किसी तरह का बदलाव हुआ है या नहीं, यह देखने के लिए उसे प्रोडक्शन में लगने वाले समय में देरी करें.

• 5 सेकंड की देरी शुरू करने के लिए, recommendation सेवा के लिए VirtualService बनाएं
• fortio लोड जनरेटर का इस्तेमाल करके, देरी की जांच करें
• VirtualService में हुई देरी को हटाएं और पुष्टि करें

फ़ास्ट ट्रैक स्क्रिप्ट लैब के निर्देश

फ़ास्ट ट्रैक स्क्रिप्ट लैब जल्द आ रहा है!!

कॉपी-और-पेस्ट करने की विधि चुनने वाले लैब से जुड़े निर्देश

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

गड़बड़ी डालने के लिए Istio का इस्तेमाल करना, आपके लिए मददगार होता है. इसकी वजह यह है कि सोर्स कोड में बदलाव करने के बजाय, प्रोडक्शन रिलीज़ की इमेज का इस्तेमाल किया जा सकता है. साथ ही, नेटवर्क लेयर में गड़बड़ी जोड़ी जा सकती है. प्रोडक्शन में, हो सकता है कि आप नेटवर्क लेयर के साथ ही, Kubernetes/Compute लेयर पर मौजूद लचीलेपन की जांच करने के लिए, पूरी तरह से उपलब्ध अव्यवस्थित टेस्टिंग टूल का इस्तेमाल करें.

गड़बड़ी की जांच करने के लिए Istio का इस्तेमाल करें. इसके लिए, "गड़बड़ी" के साथ VirtualService का इस्तेमाल करें फ़ील्ड में डालें. इस्टियो में दो तरह की गड़बड़ियां हो सकती हैं: देरी से जुड़ी गड़बड़ियां (टाइम आउट इंजेक्ट करना) और गर्भपात से जुड़ी गड़बड़ियां (एचटीटीपी गड़बड़ियां इंजेक्ट करना). इस उदाहरण में, हम सुझाव सेवा में पांच सेकंड की देरी की गड़बड़ी शामिल करेंगे. लेकिन, इस बार "तेज़ी से फ़ेल" करने के लिए, सर्किट ब्रेकर का इस्तेमाल करना हैंगिंग सेवा के ख़िलाफ़, हम डाउनस्ट्रीम सेवाओं को पूरी समयावधि का सामना करने के लिए मजबूर करेंगे.

11. फ़ॉल्ट इंजेक्शन वाली डायरेक्ट्री में जाएं.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm/" 
cd $ASM
 

12. कॉन्टेंट की जांच करने के लिए k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml खोलें. ध्यान दें कि Istio में गड़बड़ी को कुछ प्रतिशत में डालने का विकल्प है. यहां हम सभी सुझाव सेवाओं के अनुरोधों में टाइम आउट की जानकारी देंगे.

आउटपुट (कॉपी न करें)

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation-delay-fault
spec:
  hosts:
  - recommendationservice.recommendation.svc.cluster.local
  http:
  - route:
    - destination:
        host: recommendationservice.recommendation.svc.cluster.local
    fault:
      delay:
        percentage:
          value: 100
        fixedDelay: 5s

13. VirtualService को k8s_repo में कॉपी करें. हम इस गड़बड़ी को दोनों क्षेत्रों में, दुनिया भर में इंजेक्ट करेंगे.

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml
 

14. पुश बदलाव

cd $K8S_REPO 
git add . && git commit -am "Fault Injection: recommendationservice"
git push
cd $ASM
 

15. Cloud Build के पूरा होने का इंतज़ार करें.
16. सर्किट ब्रेकर सेक्शन में डिप्लॉय किए गए fortio पॉड में चलाएं और कुछ ट्रैफ़िक को सुझाव सेवा पर भेजें.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 100 -n 100 -qps 0 recommendationservice.recommendation.svc.cluster.local:8080
 

    Once the fortio command is complete, you should see responses averaging 5s:

आउटपुट (कॉपी न करें)

Ended after 5.181367359s : 100 calls. qps=19.3
Aggregated Function Time : count 100 avg 5.0996506 +/- 0.03831 min 5.040237641 max 5.177559818 sum 509.965055

17. हमने जो गलती पाई है उसे देखने का एक और तरीका है, किसी वेब ब्राउज़र में फ़्रंटएंड खोलें और किसी भी प्रॉडक्ट पर क्लिक करें. किसी प्रॉडक्ट के पेज को लोड होने में पांच सेकंड ज़्यादा लगते हैं. ऐसा इसलिए, क्योंकि इससे पेज के सबसे नीचे दिखाए गए सुझावों को फ़ेच किया जाता है.
18. दोनों Ops क्लस्टर से, ख़राब इंजेक्शन सेवा को हटाकर जगह खाली करें.

kubectl --context ${OPS_GKE_1} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml

kubectl --context ${OPS_GKE_2} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml
 

19. पुश परिवर्तन:

cd $K8S_REPO 
git add . && git commit -am "Fault Injection cleanup / restore"
git push
cd $ASM
 

15. इस्टियो कंट्रोल प्लेन की निगरानी

ASM, कंट्रोल प्लेन के चार अहम कॉम्पोनेंट इंस्टॉल करता है: पायलट, मिक्सर, गैली, और सिटाडेल. हर प्लैटफ़ॉर्म, Prometheus को निगरानी से जुड़ी ज़रूरी मेट्रिक भेजता है. साथ ही, ASM, Grafana डैशबोर्ड के साथ शिप करता है. इनकी मदद से ऑपरेटर, निगरानी से जुड़े इस डेटा को विज़ुअलाइज़ करते हैं. साथ ही, कंट्रोल प्लेन की परफ़ॉर्मेंस और परफ़ॉर्मेंस का आकलन करते हैं.

डैशबोर्ड देखना

20. Istio की मदद से इंस्टॉल की गई Grafana सेवा को पोर्ट-फ़ॉरवर्ड करें

kubectl --context ${OPS_GKE_1} -n istio-system port-forward svc/grafana 3000:3000 >> /dev/null
 

21. Grafana को अपने ब्राउज़र में खोलें
22. "वेब पूर्वावलोकन" पर क्लिक करें आपकी क्लाउड शेल विंडो के सबसे ऊपर दाएं कोने में मौजूद आइकॉन
23. पोर्ट 3000 पर 'झलक देखें' पर क्लिक करें (ध्यान दें: अगर पोर्ट 3000 नहीं है, तो 'पोर्ट करें' पर क्लिक करें और पोर्ट 3000 को चुनें)
24. इससे आपके ब्राउज़र में " BASE_URL/?orgId=1&authuser=0&environment_id=default"
25. उपलब्ध डैशबोर्ड देखें
26. URL को " BASE_URL/dashboard"
27. "istio" पर क्लिक करें उपलब्ध डैशबोर्ड देखने के लिए फ़ोल्डर
28. कॉम्पोनेंट की परफ़ॉर्मेंस देखने के लिए, उनमें से किसी भी डैशबोर्ड पर क्लिक करें. हम नीचे दिए गए सेक्शन में, हर कॉम्पोनेंट से जुड़ी ज़रूरी मेट्रिक पर नज़र डालेंगे.

मॉनिटरिंग पायलट

पायलट, कंट्रोल प्लेन कॉम्पोनेंट है. यह डेटा प्लेन (Evoy प्रॉक्सी) को नेटवर्किंग और नीति कॉन्फ़िगरेशन करने का काम करता है. पायलट प्रोजेक्ट में, वर्कलोड और डिप्लॉयमेंट की संख्या के साथ बड़े पैमाने पर बदलाव किए जाते हैं. हालांकि, यह ज़रूरी नहीं है कि इन कामों में ज़्यादा ट्रैफ़िक शामिल हो. एक खराब पायलट:

• ज़्यादा संसाधनों का इस्तेमाल करते हैं (सीपीयू और/या रैम)
• इससे Envoys को अपडेट की गई कॉन्फ़िगरेशन की जानकारी भेजने में देरी होती है

ध्यान दें: अगर पायलट प्रोग्राम बंद है या देर होती है, तो आपके वर्कलोड को अब भी ट्रैफ़िक मिलेगा.

23. " BASE_URL/dashboard/db/istio-pilot-dashboard" अपने ब्राउज़र में पायलट मेट्रिक देखें.

मॉनिटर की जाने वाली ज़रूरी मेट्रिक

संसाधन का इस्तेमाल

सही इस्तेमाल के आंकड़ों के लिए, istio के परफ़ॉर्मेंस और स्टोरेज बढ़ाने की सुविधा वाले पेज को अपनी गाइड के तौर पर इस्तेमाल करें. अगर आपको लगता है कि लंबे समय तक संसाधनों का इस्तेमाल ज़्यादा हो रहा है, तो GCP की सहायता टीम से संपर्क करें.

पायलट पुश की जानकारी

यह सेक्शन आपके Envoy प्रॉक्सी के कॉन्फ़िगरेशन के पायलट पुश को मॉनिटर करता है.

• पायलट पुश की मदद से, किसी दिए गए समय में पुश किए गए कॉन्फ़िगरेशन के टाइप की जानकारी मिलती है.
• ADS मॉनिटरिंग, सिस्टम में वर्चुअल सेवाओं, सेवाओं, और कनेक्ट किए गए एंडपॉइंट की संख्या दिखाती है.
• जिन एंडपॉइंट के बारे में जानकारी मौजूद नहीं है वे ऐसे एंडपॉइंट दिखाते हैं जिन्हें कॉन्फ़िगर किया जा चुका है, लेकिन उन पर कोई इंस्टेंस नहीं चल रहा है. ये ऐसे एंडपॉइंट हो सकते हैं जो *.googleapis.com जैसी बाहरी सेवाओं के बारे में बताते हैं.
• पायलट गड़बड़ियां समय के साथ मिलने वाली गड़बड़ियों की संख्या दिखाती हैं.
• विवाद ऐसे विवादों की संख्या दिखाते हैं जो सुनने वालों के बारे में साफ़ तौर पर नहीं बताते हैं.

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

न्यूज़लेटर की जानकारी

इस सेक्शन में envoy प्रॉक्सी, जो कंट्रोल प्लेन से संपर्क कर रहे हैं, के बारे में जानकारी है. अगर आपको XDS कनेक्शन बार-बार दिखता है, तो GCP की सहायता टीम से संपर्क करें.

मिक्सर की निगरानी करना

मिक्सर वह कॉम्पोनेंट है जो Envoy प्रॉक्सी से टेलीमेट्री बैकएंड (आम तौर पर, प्रोमेथस, स्टैकड्राइवर वगैरह) पर टेलीमेट्री को फ़नल करता है. इस क्षमता में, यह डेटा प्लेन में नहीं है. इसे दो Kubernetes जॉब (जिसे मिक्सर कहा जाता है) के तौर पर डिप्लॉय किया गया है. इसे दो अलग-अलग सेवाओं के नाम (istio-टेलीमेट्री और istio-policy) के साथ डिप्लॉय किया गया है.

मिक्सर का इस्तेमाल नीति सिस्टम के साथ इंटिग्रेट करने के लिए भी किया जा सकता है. इस क्षमता के आधार पर, मिक्सर डेटा प्लेन को प्रभावित करता है, क्योंकि मिक्सर के लिए नीति की जांच की जाती है जो आपकी सेवाओं के ऐक्सेस को ब्लॉक नहीं कर पाती है.

मिक्सर ट्रैफ़िक की मात्रा के साथ बढ़ जाता है.

24. " BASE_URL/dashboard/db/istio-mixer-dashboard" पर जाएं.

मॉनिटर की गई ज़रूरी मेट्रिक

संसाधन का इस्तेमाल

सही इस्तेमाल के आंकड़ों के लिए, istio के परफ़ॉर्मेंस और स्टोरेज बढ़ाने की सुविधा वाले पेज को अपनी गाइड के तौर पर इस्तेमाल करें. अगर आपको लगता है कि लंबे समय तक संसाधनों का इस्तेमाल ज़्यादा हो रहा है, तो GCP की सहायता टीम से संपर्क करें.

मिक्सर की खास जानकारी

• जवाब देने की अवधि एक अहम मेट्रिक है. हालांकि, मिक्सर की टेलीमेट्री की रिपोर्ट, डेटापाथ में नहीं होती हैं. अगर इंतज़ार का समय ज़्यादा होता है, तो इससे साइडकार प्रॉक्सी की परफ़ॉर्मेंस ज़रूर धीमी हो जाएगी. 90वां पर्सेंटाइल, एक अंक मिलीसेकंड में और 99वां पर्सेंटाइल 100 मि॰से॰ से कम होना चाहिए.

• अडैप्टर डिस्पैच अवधि से पता चलता है कि मिक्सर को कॉल अडैप्टर में इंतज़ार के समय का अनुभव हो रहा है (जिसके ज़रिए यह टेलीमेट्री और लॉगिंग सिस्टम को जानकारी भेजता है). यहां ज़्यादा इंतज़ार के समय का असर, मेश नेटवर्क की परफ़ॉर्मेंस पर होगा. फिर से, p90 इंतज़ार के समय का अंतर 10 मि॰से॰ से कम होना चाहिए.

गैलरी को मॉनिटर करना

गैलरी, Istio के कॉन्फ़िगरेशन की पुष्टि करने, डेटा डालने, प्रोसेस करने, और डिस्ट्रिब्यूशन से जुड़े कॉम्पोनेंट के तौर पर काम करती है. यह Kubernetes API सर्वर से पायलट में कॉन्फ़िगरेशन के बारे में बताता है. पायलट कार्यक्रम की तरह, यह सिस्टम में सेवाओं की संख्या और एंडपॉइंट के हिसाब से भी स्केल करता है.

25. " BASE_URL/dashboard/db/istio-galley-dashboard" गैलरी की मेट्रिक देखने के लिए अपने ब्राउज़र में जाएं.

मॉनिटर की गई ज़रूरी मेट्रिक

संसाधन की पुष्टि करना

फ़ॉलो की जाने वाली सबसे ज़रूरी मेट्रिक, कई तरह के रिसॉर्स की संख्या बताती है. जैसे, डेस्टिनेशन के नियम, गेटवे, और सेवा की एंट्री, जिनकी पुष्टि नहीं हो पा रही है या पुष्टि नहीं हो पा रही है.

जुड़े हुए क्लाइंट

यह बताता है कि Galley से कितने क्लाइंट कनेक्ट हैं; आम तौर पर, यह तीन (पायलट, istio-टेलीमेट्री, और istio-policy) होगा. साथ ही, इन कॉम्पोनेंट को स्केल करने पर स्केल किया जाएगा.

16. Istio से जुड़ी समस्याओं का हल

डेटा प्लेन से जुड़ी समस्याओं को हल करना

अगर आपके पायलट डैशबोर्ड से पता चलता है कि आपको कॉन्फ़िगरेशन से जुड़ी समस्याएं हैं, तो आपको PIlot लॉग की जांच करनी चाहिए या कॉन्फ़िगरेशन की समस्याओं का पता लगाने के लिए istioctl का इस्तेमाल करना चाहिए.

पायलट लॉग की जांच करने के लिए, kubectl -n istio-system लॉग istio-pilot-69db46c598-45m44 डिस्कवरी चलाएं. इसके लिए, istio-pilot-... को उस पायलट इंस्टेंस के पॉड आइडेंटिफ़ायर से बदलें जिसकी आपको समस्या का हल करना है.

मिलने वाले लॉग में, पुश स्टेटस मैसेज खोजें. उदाहरण के लिए:

2019-11-07T01:16:20.451967Z        info        ads        Push Status: {
    "ProxyStatus": {
        "pilot_conflict_outbound_listener_tcp_over_current_tcp": {
            "0.0.0.0:443": {
                "proxy": "cartservice-7555f749f-k44dg.hipster",
                "message": "Listener=0.0.0.0:443 AcceptedTCP=accounts.google.com,*.googleapis.com RejectedTCP=edition.cnn.com TCPServices=2"
            }
        },
        "pilot_duplicate_envoy_clusters": {
            "outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            }
        },
        "pilot_eds_no_instances": {
            "outbound_.80_._.frontend-external.hipster.svc.cluster.local": {},
            "outbound|443||*.googleapis.com": {},
            "outbound|443||accounts.google.com": {},
            "outbound|443||metadata.google.internal": {},
            "outbound|80||*.googleapis.com": {},
            "outbound|80||accounts.google.com": {},
            "outbound|80||frontend-external.hipster.svc.cluster.local": {},
            "outbound|80||metadata.google.internal": {}
        },
        "pilot_no_ip": {
            "loadgenerator-778c8489d6-bc65d.hipster": {
                "proxy": "loadgenerator-778c8489d6-bc65d.hipster"
            }
        }
    },
    "Version": "o1HFhx32U4s="
}

पुश स्टेटस की मदद से, उन समस्याओं की जानकारी दी जाएगी जो कॉन्फ़िगरेशन को Envoy प्रॉक्सी में पुश करने के दौरान हुई हैं – इस मामले में, हमें कई "डुप्लीकेट क्लस्टर" दिखेंगे मैसेज, जो डुप्लीकेट अपस्ट्रीम डेस्टिनेशन दिखाते हैं.

समस्याओं का पता लगाने में मदद के लिए, Google Cloud की सहायता टीम से संपर्क करें.

कॉन्फ़िगरेशन से जुड़ी गड़बड़ियां ढूंढना

अपने कॉन्फ़िगरेशन का विश्लेषण करने के लिए, istioctl का इस्तेमाल करने के लिए, istioctl experimental analyze -k --context $OPS_GKE_1 चलाएं. यह आपके सिस्टम के कॉन्फ़िगरेशन का विश्लेषण करेगा. साथ ही, सुझाए गए बदलावों के साथ सभी समस्याओं की जानकारी देगा. इस निर्देश से पता लगाई जा सकने वाली कॉन्फ़िगरेशन गड़बड़ियों की पूरी सूची के लिए, दस्तावेज़ देखें.

17. साफ़-सफ़ाई सेवा

वर्कशॉप पूरी होने के बाद, एडमिन ये काम करता है.

बूटस्ट्रैप_वर्कशॉप.sh स्क्रिप्ट के ज़रिए बनाए गए संसाधनों को मिटाने के लिए एडमिन, क्लीनअप_workshop.sh स्क्रिप्ट चलाता है. क्लीनअप स्क्रिप्ट चलाने के लिए, आपको नीचे दी गई जानकारी की ज़रूरत होगी.

• संगठन का नाम - उदाहरण के लिए yourcompany.com
• वर्कशॉप आईडी - YYMMDD-NN फ़ॉर्म में, उदाहरण के लिए 200131-01
• एडमिन GCS बकेट - बूटस्ट्रैप स्क्रिप्ट में तय किया गया है.

13. Cloud Shell खोलें और क्लाउड शेल में नीचे दी गई सभी कार्रवाइयां करें. नीचे दिए गए लिंक पर क्लिक करें.

क्लाउड शेल

14. पुष्टि करें कि आपने gcloud में सही एडमिन उपयोगकर्ता से लॉग इन किया है.

gcloud config list
 

15. एएसएम फ़ोल्डर पर जाएं.

cd ${WORKDIR}/asm
 

16. उस संगठन का नाम और वर्कशॉप आईडी तय करें जिसे मिटाना है.

export ORGANIZATION_NAME=<ORGANIZATION NAME>
export ASM_WORKSHOP_ID=<WORKSHOP ID>
export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

17. क्लीनअप स्क्रिप्ट को नीचे बताए गए तरीके से चलाएं.

./scripts/cleanup_workshop.sh --workshop-id ${ASM_WORKSHOP_ID} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --org-name ${ORGANIZATION_NAME}