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

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

अहम जानकारी: यह एक ऐल्फ़ा वर्कशॉप है. इसका मकसद, सिर्फ़ प्रशिक्षक की निगरानी में Classroom की ट्रेनिंग देना है.

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

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

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

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

एजेंडा

• मॉड्यूल 0 - प्लैटफ़ॉर्म का सेटअप और इसके बारे में जानकारी
• परिचय और आर्किटेक्चर
• सर्विस मेश और Istio/ASM के बारे में बुनियादी जानकारी
• लैब: इंफ़्रास्ट्रक्चर सेटअप: उपयोगकर्ता का वर्कफ़्लो
• ब्रेक
• QnA
• पहला मॉड्यूल - एएसएम की मदद से ऐप्लिकेशन इंस्टॉल करना, उन्हें सुरक्षित करना, और उन पर नज़र रखना
• रिपो मॉडल: बुनियादी ढांचे और Kubernetes रिपो के बारे में जानकारी
• लैब: सैंपल ऐप्लिकेशन डिप्लॉय करना
• डिस्ट्रिब्यूट की गई सेवाएं और जांचने की क्षमता
• लंच
• लैब: Stackdriver की मदद से निगरानी करना
• QNA
• मॉड्यूल 2 - DevOps - कैनेरी रोलआउट, नीति/RBAC
• मल्टी क्लस्टर सर्विस डिस्कवरी और सुरक्षा/नीति
• लैब: म्यूचल टीएलएस
• कैनरी डिप्लॉयमेंट
• लैब: कैनेरी डिप्लॉयमेंट
• सुरक्षित मल्टी क्लस्टर ग्लोबल लोड बैलेंसिंग
• ब्रेक
• लैब: अनुमति से जुड़ी नीति
• 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 स्क्रिप्ट को कॉल करती है. setup-terraform-admin-project.sh स्क्रिप्ट, एक उपयोगकर्ता के लिए वर्कशॉप एनवायरमेंट बनाती है.

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

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

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

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

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

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

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

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

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

• [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
• jq
• envsubst
• kustomize

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

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

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

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. bootstrap_workshop.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 
 

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

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

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

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

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

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

7. Cloud Shell खोलें और नीचे दिए गए सभी काम Cloud Shell में करें. नीचे दिए गए लिंक पर क्लिक करें.

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. bootstrap_workshop.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. terraform प्रोजेक्ट आईडी पाने के लिए, एडमिन के GCS बकेट से workshop.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 विंडो में जाकर, सभी चरण पूरे करें.

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

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

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

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

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

FAST TRACK SCRIPT

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

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

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

कोई तरीका चुनने और उसमें दिए गए चरणों को पूरा करने के बाद, दूसरे तरीके में दिए गए चरणों को पूरा न करें.

स्क्रिप्ट को तेज़ी से सेटअप करना

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

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

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

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

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

CLOUD SHELL

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

4. अगली स्क्रीन पर, [Google की सेवा की शर्तों](https://cloud.google.com/terms) से सहमत होने के लिए चेकबॉक्स को चुनें. इसके बाद, `Start Cloud Shell` पर क्लिक करें.

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

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" या "–setup-for-admin" फ़्लैग का इस्तेमाल करके, अपने लिए वर्कशॉप सेट अप की है, तो 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 इंस्टॉलेशन की पुष्टि करना

FAST TRACK SCRIPT

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

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

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

source ${HOME}/.bashrc

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

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

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

वर्कशॉप सेट अप करने वाले एडमिन को, उपयोगकर्ता को उपयोगकर्ता नाम और पासवर्ड की जानकारी देनी होगी. उपयोगकर्ता के सभी प्रोजेक्ट के नाम के आगे उपयोगकर्ता नाम जोड़ दिया जाएगा. उदाहरण के लिए, उपयोगकर्ता [e-mail] के लिए, Terraform एडमिन प्रोजेक्ट का आईडी 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
• jq
• envsubst
• kustomize
• pv

Terraform एडमिन प्रोजेक्ट को ऐक्सेस करना

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

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

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

1. नीचे दिए गए लिंक पर क्लिक करके Cloud Shell खोलें. अगर यह Lab Setup and Prep सेक्शन से पहले से ही खुला हुआ है, तो इसे खोलने की ज़रूरत नहीं है.

CLOUD SHELL

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. यह कमांड चलाकर, Terraform एडमिन प्रोजेक्ट आईडी पाएं:

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

7. वर्कशॉप से जुड़े सभी संसाधन, terraform admin project के 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. Terraform एडमिन प्रोजेक्ट के लिए 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 लिंक पर क्लिक करें. इसके बाद, सबसे नए बिल्ड पर क्लिक करके, Terraform के शुरुआती डिप्लॉयमेंट की जानकारी देखें. टेराफ़ॉर्म स्क्रिप्ट के तहत, ये संसाधन बनाए जाते हैं. ऊपर दिए गए आर्किटेक्चर डायग्राम को भी देखा जा सकता है.

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

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

10. terraform admin project में बिल्ड पूरा होने के बाद, ऑप्स प्रोजेक्ट पर दूसरा बिल्ड शुरू हो जाएगा. ops project के लिए Cloud Build पेज खोलने के लिए, दिखाए गए लिंक पर क्लिक करें. साथ ही, पुष्टि करें कि k8s-repo 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 वैरिएबल जोड़ें, ताकि 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 क्लस्टर में सिर्फ़ Citadel, sidecar-injector, और coredns चलते हैं. ये ops-1 क्लस्टर में चल रहे Istio कंट्रोलप्लेन को शेयर करते हैं.

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

17. पक्का करें कि दोनों dev2 क्लस्टर पर Istio इंस्टॉल किया गया हो. dev2 क्लस्टर में सिर्फ़ Citadel, sidecar-injector, और coredns चलते हैं. ये दोनों, ops-2 क्लस्टर में चल रहे Istio कंट्रोलप्लेन को शेयर करते हैं.

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

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

6. Infrastructure Repo के बारे में जानकारी

इन्फ़्रास्ट्रक्चर क्लाउड बिल्ड

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

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

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

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

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

इस वर्कशॉप में, चार तरह की टीमों के बारे में बताया गया है:

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

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

प्रोवाइडर, स्टेट, और आउटपुट - बैकएंड और शेयर की गई स्टेट

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

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

जिन संसाधनों की वैल्यू एक-दूसरे पर निर्भर करती हैं उनमें output.tf फ़ाइल होती है. ज़रूरी आउटपुट वैल्यू, उस संसाधन के लिए बैकएंड में तय की गई tfstate फ़ाइल में सेव की जाती हैं. उदाहरण के लिए, किसी प्रोजेक्ट में GKE क्लस्टर बनाने के लिए, आपको प्रोजेक्ट आईडी पता होना चाहिए. प्रोजेक्ट आईडी को output.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 क्लस्टर बनाने के लिए, आपको प्रोजेक्ट आईडी और वीपीसी की जानकारी की ज़रूरत होती है. shared_state फ़ाइलें, templates/shared_state.tf_tmpl पर मौजूद टेंप्लेट से जनरेट की जाती हैं. इसके लिए, scripts/setup_terraform_admin_project पर मौजूद स्क्रिप्ट का इस्तेमाल किया जाता है. सभी संसाधनों की shared_state फ़ाइलें, gcp/[environment]/shared_states फ़ोल्डर में रखी जाती हैं. ज़रूरी shared_state फ़ाइलों को, उनसे जुड़े संसाधन फ़ोल्डर में सिमलिंक किया जाता है. सभी shared_state फ़ाइलों को एक फ़ोल्डर में रखने और उन्हें सही संसाधन फ़ोल्डर में सिंबॉलिक लिंक करने से, सभी स्टेट फ़ाइलों को एक ही जगह पर मैनेज करना आसान हो जाता है.

वैरिएबल

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

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

K8s रिपो के बारे में जानकारी

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

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

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

इस वर्कशॉप में, दो तरह के GKE क्लस्टर हैं.

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

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

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

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

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

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. सैंपल ऐप्लिकेशन डिप्लॉय करना

मकसद: ऐप्लिकेशन क्लस्टर पर Hipster shop ऐप्लिकेशन डिप्लॉय करना है

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

FAST TRACK SCRIPT

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

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

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

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

ops प्रोजेक्ट के सोर्स रेपो की कॉपी बनाएं

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

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

mkdir $WORKDIR/k8s-repo
 

2. git repo शुरू करें, रिमोट जोड़ें, और रिमोट 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. सभी क्लस्टर के लिए, Hipster Shop के नेमस्पेस और सेवाओं को सोर्स रेपो में कॉपी करें.

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. ऐप्लिकेशन क्लस्टर के लिए, Hipster Shop Deployments, RBAC, और 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. एक डेवलपमेंट क्लस्टर को छोड़कर, बाकी सभी क्लस्टर से cartservice डिप्लॉयमेंट, rbac, और podsecuritypolicy को हटाएं. Hipstershop को मल्टी-क्लस्टर डिप्लॉयमेंट के लिए नहीं बनाया गया था. इसलिए, अलग-अलग नतीजे मिलने से बचने के लिए, हम सिर्फ़ एक cartservice का इस्तेमाल कर रहे हैं.

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 में cartservice डिप्लॉयमेंट, 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. RBAC मेनिफ़ेस्ट में 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. IngressGateway और 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. Config Connector संसाधनों को हर प्रोजेक्ट के किसी एक क्लस्टर में कॉपी करें.

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. Config Connector मेनिफ़ेस्ट में 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) कॉपी करें. Hipster shop ऐप्लिकेशन को ग्लोबल Google Cloud Load Balancer (GCLB) का इस्तेमाल करके दिखाया जाता है. GCLB को क्लाइंट ट्रैफ़िक (frontend के लिए) मिलता है और वह इसे सेवा के सबसे नज़दीकी इंस्टेंस को भेजता है. दोनों ऑप्स क्लस्टर पर loadgenerator रखने से, यह पक्का किया जा सकेगा कि ट्रैफ़िक को ऑप्स क्लस्टर में चल रहे दोनों Istio Ingress गेटवे पर भेजा जा रहा है. लोड बैलेंसिंग के बारे में यहां ज़्यादा जानकारी दी गई है.

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 मेनिफ़ेस्ट में ऑप्स प्रोजेक्ट आईडी बदलें.

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

Hipster Shop ऐप्लिकेशन को ऐक्सेस करना

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

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

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

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

GKE Autoneg controller

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

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

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

21. Hipster shop को ऐक्सेस करने के लिए, यहां दी गई कमांड के लिंक आउटपुट पर क्लिक करें.

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

22. आपके पास यह देखने का विकल्प होता है कि सर्टिफ़िकेट मान्य है या नहीं. इसके लिए, Chrome टैब के यूआरएल बार में मौजूद लॉक सिंबल पर क्लिक करें.

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

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

23. उस ऑप्स प्रोजेक्ट के लिए GCLB > मॉनिटरिंग लिंक पाएं जिसमें Hipster shop 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. नीचे दिए गए तरीके से, बैकएंड ड्रॉपडाउन मेन्यू में जाकर All backends को istio-ingressgateway में बदलें.

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

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

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

8. Stackdriver की मदद से जांच करने की क्षमता

मकसद: Istio टेलीमेट्री को Stackdriver से कनेक्ट करना और उसकी पुष्टि करना.

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

FAST TRACK SCRIPT

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

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

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

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

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

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

1. istio to stackdriver कॉन्फ़िगरेशन फ़ाइल इंस्टॉल करें.

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 → Stackdriver इंटिग्रेशन की पुष्टि करें. Stackdriver Handler CRD पाएं.

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

आउटपुट में, stackdriver नाम का हैंडलर दिखना चाहिए:

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

5. पुष्टि करें कि Istio मेट्रिक, Stackdriver में एक्सपोर्ट हो रही हैं. इस कमांड से मिले लिंक पर क्लिक करें:

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

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

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

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

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

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

Istio का Envoy प्रॉक्सी हमें कई मेट्रिक देता है. हालांकि, शुरुआत करने के लिए ये मेट्रिक काफ़ी हैं. (पूरी सूची यहां दी गई है). ध्यान दें कि हर मेट्रिक के लिए लेबल का एक सेट होता है. इसका इस्तेमाल फ़िल्टर करने और एग्रीगेट करने के लिए किया जा सकता है. जैसे: destination_service, source_workload_namespace, response_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"
 
 

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

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वां पर्सेंटाइल इंतज़ार का समय): [ एपीआई का संदर्भ] अब हम कोड में अपने डैशबोर्ड में एक नया ग्राफ़ विजेट जोड़ सकते हैं. इस बदलाव की समीक्षा अन्य डेवलपर कर सकते हैं. साथ ही, इसे वर्शन कंट्रोल में शामिल किया जा सकता है. यहां एक ऐसा विजेट दिया गया है जिसे जोड़कर, 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, मेश में मौजूद सभी नेटवर्क ट्रैफ़िक के लिए स्ट्रक्चर्ड लॉग का एक सेट उपलब्ध कराता है. साथ ही, उन्हें Stackdriver Logging पर अपलोड करता है, ताकि एक ही टूल में अलग-अलग क्लस्टर का विश्लेषण किया जा सके. लॉग में सेवा-स्तर का मेटाडेटा शामिल होता है. जैसे, क्लस्टर, कंटेनर, ऐप्लिकेशन, 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 कंटेनर चुनें. इसके बाद, "पायलट" खोजें —

यहां हम देख सकते हैं कि Istio कंट्रोल प्लेन, हर सैंपल के तौर पर मिले ऐप्लिकेशन सेवा के लिए साइडकार प्रॉक्सी को प्रॉक्सी कॉन्फ़िगरेशन पुश कर रहा है. "CDS," "LDS," और "RDS" अलग-अलग Envoy API के बारे में बताते हैं ( ज़्यादा जानकारी).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FAST TRACK SCRIPT

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

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

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

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

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

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

1. ऑपरेशन क्लस्टर में 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'
 

    `Output (do not copy)`

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

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

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

2. हम पूरे क्लस्टर में mTLS चालू करने के लिए, istioControlPlane CR पर kustomize पैच लागू करेंगे. सभी क्लस्टर के लिए, पैच को काम की डायरेक्ट्री में कॉपी करें और 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}"

 

एमटीएलएस की पुष्टि करना

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 ऑपरेटर कंट्रोलर की ओर से बनाए गए DestinationRule के बारे में जानकारी दें.

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

FAST TRACK SCRIPT

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

${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. repo_setup.sh स्क्रिप्ट चलाएं, ताकि बेसलाइन मेनिफ़ेस्ट को k8s-repo में कॉपी किया जा सके.

$CANARY_DIR/repo-setup.sh 
 

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

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

हम अपनी Cloud Shell विंडो को दो पैन में बांटने के लिए, 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 में frontend-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. Dev2 रोलआउट पूरा होने के बाद, आपको स्क्रिप्ट के आखिर में यह मैसेज दिखेगा:

    Output (do not copy) 
   

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

9. साथ ही, Dev2 पॉड से आने वाला सभी फ़्रंटएंड ट्रैफ़िक, frontend-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 पर "लॉक" है. ऐसा इसलिए है, क्योंकि baseline 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 में frontend-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 पाइपलाइन के तौर पर अपने-आप ट्रिगर किया जा सकता है. इसके लिए, कंटेनर रजिस्ट्री में पुश की गई नई टैग की गई इमेज जैसे ट्रिगर का इस्तेमाल किया जा सकता है. आपको हर चरण के बीच में कैनरी विश्लेषण भी जोड़ना होगा. इससे, ज़्यादा ट्रैफ़िक भेजने से पहले, v2 की लेटेन्सी और गड़बड़ी की दर का विश्लेषण किया जा सकेगा. इसके लिए, पहले से तय किए गए सुरक्षा थ्रेशोल्ड का इस्तेमाल किया जाएगा.

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

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

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

FAST TRACK SCRIPT

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

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

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

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

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

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

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

1. currency-deny-all.yaml के कॉन्टेंट की जांच करें. यह नीति, currencyservice के ऐक्सेस को सीमित करने के लिए, डिप्लॉयमेंट लेबल सिलेक्टर का इस्तेमाल करती है. ध्यान दें कि यहां 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. पहले से खुले टैब में या इस लिंक पर क्लिक करके, Cloud Build के Ops प्रोजेक्ट की स्थिति देखें:

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

5. बिल्ड पूरा होने के बाद, इस लिंक पर जाकर ब्राउज़र में hipstershop के फ़्रंटएंड को ऐक्सेस करने की कोशिश करें:

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

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

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. मुद्रा सेवा की साइडकार प्रॉक्सी से, आरबीएसी (अनुमति) लॉग पाएं. आपको "लागू किया गया: अनुमति नहीं है" मैसेज दिखेगा. इससे पता चलता है कि currencyservice को सभी इनबाउंड अनुरोधों को ब्लॉक करने के लिए सेट किया गया है.

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. अब, फ़्रंटएंड को अनुमति दें, लेकिन अन्य बैकएंड सेवाओं को नहीं, ताकि वे currencyservice को ऐक्सेस कर सकें. 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 AuthorizationPolicies में Kubernetes सेवा खातों का इस्तेमाल करते समय, आपको सबसे पहले क्लस्टर-वाइड म्यूचल टीएलएस चालू करना होगा. जैसा कि हमने मॉड्यूल 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. बिल्ड पूरा होने के बाद, Hipstershop का फ़्रंटएंड फिर से खोलें. इस बार, आपको होम पेज पर कोई गड़बड़ी नहीं दिखेगी. ऐसा इसलिए है, क्योंकि फ़्रंटएंड को मौजूदा सेवा को ऐक्सेस करने की अनुमति साफ़ तौर पर दी गई है.
13. अब, कार्ट में आइटम जोड़कर और "ऑर्डर करें" पर क्लिक करके, चेकआउट करने की कोशिश करें. इस बार, आपको मुद्रा सेवा से कीमत-कन्वर्ज़न की गड़बड़ी दिखेगी. ऐसा इसलिए है, क्योंकि हमने सिर्फ़ फ़्रंटएंड को अनुमति दी है. इसलिए, checkoutservice अब भी currencyservice को ऐक्सेस नहीं कर सकता.

14. आखिर में, चेकआउट सेवा को मुद्रा की जानकारी ऐक्सेस करने की अनुमति दें. इसके लिए,हम currencyservice की AuthorizationPolicy में एक और नियम जोड़ेंगे. ध्यान दें कि हम सिर्फ़ उन दो सेवाओं को मुद्रा का ऐक्सेस दे रहे हैं जिन्हें इसकी ज़रूरत है - फ़्रंटएंड और चेकआउट. अन्य बैकएंड अब भी ब्लॉक रहेंगे.
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 बनाई जा सकती है. उदाहरण के लिए, एक ही नेमस्पेस में मौजूद सभी वर्कलोड को एक-दूसरे को ऐक्सेस करने की अनुमति देने के लिए, allow-all नीति का इस्तेमाल किया जा सकता है.

12. इन्फ़्रास्ट्रक्चर स्केलिंग

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

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

FAST TRACK SCRIPT

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

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

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

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

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

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

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

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

1. नए ऑपरेशंस और ऐप्लिकेशन क्लस्टर के लिए, होस्ट प्रोजेक्ट में r3 क्षेत्र में शेयर किए गए वीपीसी में सबनेट.
2. r3 क्षेत्र में मौजूद रीजनल ऑप्स क्लस्टर, जहां ASM/Istio कंट्रोल प्लेन मौजूद है.
3. रीजन r3 के दो ज़ोन में दो ज़ोनल ऐप्लिकेशन क्लस्टर.
4. k8s-repo को अपडेट करें:
5. ASM/Istio कंट्रोल प्लैन के संसाधनों को r3 क्षेत्र में मौजूद ऑप्स क्लस्टर पर डिप्लॉय करें.
6. ASM/Istio के शेयर किए गए कंट्रोल प्लेन के संसाधनों को क्षेत्र r3 में मौजूद ऐप्लिकेशन क्लस्टर में डिप्लॉय करें.
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. add-proj repo डायरेक्ट्री में मौजूद 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 (ऑप्स प्रोजेक्ट में) में Cloud Build ट्रिगर होता है. नए Kubernetes संसाधन, पिछले चरण में जोड़े गए तीन नए क्लस्टर के लिए हैं. k8s-repo Cloud Build की मदद से बनाए गए नए क्लस्टर में, ASM/Istio कंट्रोल प्लेन और शेयर किए गए कंट्रोल प्लेन के संसाधन जोड़े जाते हैं.

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 क्लस्टर में सिर्फ़ Citadel, sidecar-injector, और coredns चलते हैं. ये 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 (लोड जनरेशन यूटिलिटी) का इस्तेमाल करें. इसके लिए, सर्किट को ज़बरदस्ती ट्रिप करें

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

Fast Track Script Lab जल्द ही आ रहा है!!

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

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

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

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

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

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

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

Istio DestinationRules का इस्तेमाल करके, सर्किट ब्रेकर नीतियां तय की जा सकती हैं. इस सेक्शन में, हम शिपिंग सेवा के लिए सर्किट ब्रेकर लागू करने के लिए, यह नीति लागू करेंगे:

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

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

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

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

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

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

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

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 लोड जनरेटर पॉड को कॉपी करें. यह क्लाइंट पॉड है. इसका इस्तेमाल हम shippingservice के लिए सर्किट ब्रेकर को "ट्रिप" करने के लिए करेंगे.

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 में वापस जाकर, fortio पॉड का इस्तेमाल करके shippingservice को gRPC ट्रैफ़िक भेजें. इसके लिए, एक साथ एक कनेक्शन और कुल 1,000 अनुरोधों का इस्तेमाल करें. इससे सर्किट ब्रेकर ट्रिप नहीं होगा, क्योंकि हमने अब तक 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 करें. हालांकि, अनुरोधों की कुल संख्या को स्थिर रखें. हमें दो-तिहाई अनुरोधों में "ओवरफ़्लो" गड़बड़ी दिखनी चाहिए, क्योंकि सर्किट ब्रेकर ट्रिप हो गया है: हमने जो नीति तय की है उसके मुताबिक, एक सेकंड के अंतराल में सिर्फ़ एक साथ एक कनेक्शन की अनुमति है.

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
 

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

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

मकसद: सुझाव देने वाली सेवा की परफ़ॉर्मेंस की जांच करना. इसके लिए, प्रोडक्शन में पुश करने से पहले, इसमें देरी करना.

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

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

Fast Track Script Lab जल्द ही आ रहा है!!

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

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

फ़ॉल्ट इंजेक्शन के लिए Istio का इस्तेमाल करना फ़ायदेमंद होता है. इसकी वजह यह है कि इसमें प्रोडक्शन रिलीज़ इमेज का इस्तेमाल किया जा सकता है. साथ ही, सोर्स कोड में बदलाव करने के बजाय, नेटवर्क लेयर पर फ़ॉल्ट जोड़ा जा सकता है. प्रोडक्शन में, नेटवर्क लेयर के साथ-साथ Kubernetes/कंप्यूट लेयर पर भी सिस्टम की मज़बूती की जांच करने के लिए, केऑस टेस्टिंग टूल का इस्तेमाल किया जा सकता है.

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

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 में, कुछ प्रतिशत अनुरोधों में गड़बड़ी डालने का विकल्प होता है. यहां हम सभी recommendationservice अनुरोधों में टाइमआउट की सुविधा चालू करेंगे.

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

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 पॉड में एक्ज़ीक्यूट करें और recommendationservice को कुछ ट्रैफ़िक भेजें.

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. दोनों ऑप्स क्लस्टर से फ़ॉल्ट इंजेक्शन सेवा को हटाकर, क्लीन अप करें.

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. Istio कंट्रोल प्लेन की निगरानी करना

ASM, कंट्रोल प्लैन के चार ज़रूरी कॉम्पोनेंट इंस्टॉल करता है: Pilot, Mixer, Galley, और Citadel. हर कॉम्पोनेंट, निगरानी से जुड़ी अपनी मेट्रिक को 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. Cloud Shell विंडो में सबसे ऊपर दाएं कोने में मौजूद, "वेब की झलक" आइकॉन पर क्लिक करें
23. पोर्ट 3000 पर झलक देखें पर क्लिक करें (ध्यान दें: अगर पोर्ट 3000 नहीं है, तो पोर्ट बदलें पर क्लिक करें और पोर्ट 3000 चुनें)
24. इससे आपके ब्राउज़र में एक टैब खुलेगा. इसमें " BASE_URL/?orgId=1&authuser=0&environment_id=default" जैसा यूआरएल होगा
25. उपलब्ध डैशबोर्ड देखना
26. यूआरएल को " BASE_URL/dashboard" में बदलें
27. उपलब्ध डैशबोर्ड देखने के लिए, "istio" फ़ोल्डर पर क्लिक करें
28. किसी कॉम्पोनेंट की परफ़ॉर्मेंस देखने के लिए, इनमें से किसी भी डैशबोर्ड पर क्लिक करें. हम यहां दिए गए सेक्शन में, हर कॉम्पोनेंट के लिए अहम मेट्रिक देखेंगे.

Monitoring Pilot

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

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

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

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

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

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

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

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

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

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

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

Envoy की जानकारी

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

मिक्सर को मॉनिटर करना

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

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

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

24. Mixer मेट्रिक देखने के लिए, अपने ब्राउज़र में " BASE_URL/dashboard/db/istio-mixer-dashboard" पर जाएं.

निगरानी की जाने वाली अहम मेट्रिक

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

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

Mixer की खास जानकारी

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

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

गैलरी की निगरानी करना

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

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

निगरानी की जाने वाली अहम मेट्रिक

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

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

कनेक्ट किए गए क्लाइंट

इससे पता चलता है कि Galley से कितने क्लाइंट कनेक्ट हैं. आम तौर पर, यह संख्या 3 होती है (पायलट, istio-telemetry, istio-policy). साथ ही, इन कॉम्पोनेंट के बढ़ने के साथ-साथ यह संख्या भी बढ़ती है.

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

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

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

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

इसके बाद, आपको एक लॉग दिखेगा. इसमें Push Status मैसेज खोजें. उदाहरण के लिए:

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. साफ़-सफ़ाई सेवा

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

एडमिन, bootstrap_workshop.sh स्क्रिप्ट से बनाए गए संसाधनों को मिटाने के लिए, cleanup_workshop.sh स्क्रिप्ट चलाता है. क्लीनअप स्क्रिप्ट चलाने के लिए, आपको यह जानकारी देनी होगी.

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

13. Cloud Shell खोलें और नीचे दिए गए सभी काम Cloud Shell में करें. नीचे दिए गए लिंक पर क्लिक करें.

CLOUD SHELL

14. पुष्टि करें कि आपने gcloud में, एडमिन के तौर पर इस्तेमाल किए जाने वाले खाते से लॉग इन किया हो.

gcloud config list
 

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

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}