کارگاه مش سرویس Anthos: راهنمای آزمایشگاه

1. کارگاه آلفا

نکته مهم: این یک کارگاه آموزشی آلفا است و اکیداً در نظر گرفته شده است که یک کلاس آموزشی تحت رهبری مربی باشد.

پیوند به codelab کارگاه bit.ly/asm-workshop

2. بررسی اجمالی

نمودار معماری

این کارگاه یک تجربه همهجانبه عملی است که نحوه راه اندازی سرویس های توزیع شده جهانی در GCP را در تولید مرور می کند. فناوری‌های اصلی مورد استفاده Google Kubernetes Engine (GKE) برای محاسبات و مش سرویس Istio برای ایجاد اتصال امن، قابلیت مشاهده و شکل‌دهی پیشرفته ترافیک است. تمام روش ها و ابزارهای مورد استفاده در این کارگاه همان چیزی است که شما در تولید استفاده می کنید.

دستور کار

• ماژول 0 - مقدمه و راه اندازی پلت فرم
• مقدمه و معماری
• معرفی سرویس مش و ایستیو/ASM
• آزمایشگاه: راه اندازی زیرساخت: گردش کار کاربر
• شکستن
• QnA
• ماژول 1 - نصب، ایمن و نظارت بر برنامه ها با ASM
• مدل Repo: زیرساخت و مخازن Kubernetes توضیح داده شده است
• آزمایشگاه: استقرار نمونه برنامه
• خدمات توزیع شده و قابلیت مشاهده
• ناهار
• آزمایشگاه: قابلیت مشاهده با Stackdriver
• QNA
• ماژول 2 - DevOps - عرضه Canary، Policy/RBAC
• کشف خدمات چند خوشه ای و امنیت/خط مشی
• آزمایشگاه: متقابل TLS
• استقرار قناری
• آزمایشگاه: استقرار قناری
• تعادل بار جهانی چند خوشه ای ایمن
• شکستن
• آزمایشگاه: سیاست مجوز
• QNA
• ماژول 3 - Infra Ops - ارتقاء پلتفرم
• بلوک های ساختمانی خدمات توزیع شده
• آزمایشگاه: مقیاس گذاری زیرساخت
• مراحل بعدی

اسلایدها

اسلایدهای این کارگاه در لینک زیر قابل مشاهده است:

اسلایدهای کارگاه ASM

پیش نیازها

قبل از ادامه این کارگاه موارد زیر ضروری است:

1. یک گره سازمانی GCP
2. شناسه حساب صورت‌حساب (کاربر شما باید مدیر صورت‌حساب در این حساب صورت‌حساب باشد)
3. نقش IAM مدیر سازمان در سطح سازمان برای کاربر شما

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 Admin (به عنوان مثال 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 مورد نیاز است:

• مالک - مجوز مالک پروژه برای تمام پروژه های سازمان.
• Folder Admin - امکان ایجاد و حذف پوشه ها در سازمان. هر کاربر یک پوشه با تمام منابع خود در داخل پروژه دریافت می کند.
• مدیر سازمان
• Project Creator - امکان ایجاد پروژه در سازمان.
• Project Deleter - امکان حذف پروژه ها در سازمان.
• Project IAM Admin - امکان ایجاد قوانین IAM در تمام پروژه های سازمان.

علاوه بر این موارد، ADMIN_USER باید مدیر صورت‌حساب شناسه صورت‌حساب مورد استفاده در کارگاه نیز باشد.

شمای کاربر و مجوزهای اجرای کارگاه

اگر قصد دارید این کارگاه را برای کاربران (غیر از خودتان) در سازمان خود ایجاد کنید، باید از یک طرح نامگذاری کاربر خاص برای MY_USERs پیروی کنید. در طول اسکریپت bootstrap_workshop.sh، شما یک شماره شروع و یک کاربر نهایی ارائه می دهید. از این اعداد برای ایجاد نام کاربری زیر استفاده می شود:

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

به عنوان مثال، اگر اسکریپت کارگاه بوت استرپ را با شماره کاربر شروع 1 و شماره کاربر نهایی 3 اجرا کنید، در سازمان شما به نام yourcompany.com، محیط کارگاه برای کاربران زیر ایجاد می شود:

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

به این نام‌های کاربری، نقش‌های مالک پروژه برای پروژه‌های خاص آنها که در اسکریپت setup_terraform_admin_project.sh ایجاد شده‌اند، اختصاص داده می‌شوند. هنگام استفاده از اسکریپت بوت استرپ باید به این طرح نامگذاری کاربر پایبند باشید. به نحوه افزودن چند کاربر همزمان در GSuite مراجعه کنید.

ابزار مورد نیاز کارگاه

این کارگاه برای بوت استرپ شدن از Cloud Shell در نظر گرفته شده است. ابزارهای زیر برای این کارگاه مورد نیاز است.

• gcloud (ver >= 270)
• کوبکتل
• sed (با sed در Cloud Shell/Linux کار می کند و نه Mac OS)
• git (مطمئن شوید که به روز هستید)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• سفارشی کردن

همه ابزارها به جز kustomize قبلاً به طور پیش فرض در Cloud Shell نصب شده اند. اگر kustomize نصب نشده است، آن را با استفاده از اسکریپت bash ارائه شده در لینک بالا نصب کنید و مطمئن شوید که باینری kustomize در PATH شما قرار دارد و با اجرای دستور kustomize در Cloud Shell تأیید کنید.

برای خودتان کارگاه راه اندازی کنید (تنظیم تک کاربره)

1. Cloud Shell را باز کنید، تمام اقدامات زیر را در Cloud Shell انجام دهید. روی لینک زیر کلیک کنید.

پوسته ابری

2. بررسی کنید که با کاربر Admin مورد نظر وارد 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 ایجاد می شود. پروژه terraform admin برای ایجاد باقیمانده منابع GCP مورد نیاز برای این کارگاه استفاده می شود. شما API های مورد نیاز را در پروژه مدیریت terraform فعال می کنید. شما از Cloud Build برای اعمال پلان های Terraform استفاده می کنید. شما به حساب سرویس Cloud Build نقش های IAM مناسبی می دهید تا بتواند منابعی را در GCP ایجاد کند. در نهایت یک باطن راه دور را در یک سطل Google Cloud Storage (GCS) پیکربندی می‌کنید تا حالت‌های Terraform را برای همه منابع GCP ذخیره کند.

برای مشاهده وظایف Cloud Build در پروژه terraform admin، به شناسه پروژه terraform admin نیاز دارید. این در فایل vars/vars.sh در زیر پوشه asm شما ذخیره می شود. این دایرکتوری فقط در صورتی وجود دارد که کارگاه را برای خود به عنوان مدیر راه اندازی کنید.

6. منبع فایل متغیرها برای تنظیم متغیرهای محیطی

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

راه اندازی کارگاه برای چند کاربر (راه اندازی چند کاربر)

7. Cloud Shell را باز کنید، تمام اقدامات زیر را در Cloud Shell انجام دهید. روی لینک زیر کلیک کنید.

پوسته ابری

8. بررسی کنید که با کاربر Admin مورد نظر وارد 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. فایل workshop.txt را از سطل GCS مدیریت دریافت کنید تا شناسه های پروژه terraform را بازیابی کنید.

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

4. راه اندازی و آماده سازی آزمایشگاه

کاربرانی که کارگاه را انجام می دهند از اینجا شروع می کنند. تمام مراحل را از یک پنجره INCOGNITO در Chrome یا Firefox انجام دهید.

مسیر آزمایشگاهی خود را انتخاب کنید

آزمایشگاه های این کارگاه را می توان به یکی از دو روش زیر انجام داد:

• راه " اسکریپت های تعاملی مسیر سریع آسان ".
• روش " کپی و چسباندن دستی هر دستورالعمل ".

روش اسکریپت‌های مسیر سریع به شما امکان می‌دهد یک اسکریپت تعاملی واحد را برای هر آزمایشگاه اجرا کنید که با اجرای خودکار دستورات آن آزمایشگاه شما را در آزمایشگاه راهنمایی می‌کند. دستورات به صورت دسته‌ای با توضیحات مختصر در مورد هر مرحله و آنچه انجام می‌دهند اجرا می‌شوند. پس از هر دسته، از شما خواسته می شود تا به دسته بعدی دستورات بروید. به این ترتیب می توانید آزمایشگاه ها را با سرعت خود اجرا کنید. اسکریپت های آهنگ سریع بی قدرت هستند، به این معنی که می توانید این اسکریپت ها را چندین بار اجرا کنید و نتیجه یکسانی داشته باشید.

اسکریپت های آهنگ سریع در بالای هر آزمایشگاه در یک کادر سبز رنگ مانند شکل زیر ظاهر می شوند.

فیلمنامه آهنگ سریع

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

روش کپی و چسباندن روش سنتی کپی و چسباندن بلوک‌های فرمان فردی با توضیحاتی درباره دستورات است. این روش فقط برای یک بار اجرا در نظر گرفته شده است. هیچ تضمینی وجود ندارد که اجرای مجدد دستورات در این روش نتایج یکسانی به شما بدهد.

هنگام انجام آزمایشگاه، لطفاً یکی از دو روش را انتخاب کنید.

بعد از اینکه روشی را انتخاب کردید و مراحل آن متد را انجام دادید، مراحل را در روش دیگر انجام ندهید.

راه اندازی اسکریپت آهنگ سریع

پس از تکمیل اسکریپت آهنگ سریع، کار با آن آزمایشگاه تمام شده است. مراحل موجود در دستورالعمل های آزمایشگاه کپی و جایگذاری را انجام ندهید.

دریافت اطلاعات کاربر

این کارگاه با استفاده از یک حساب کاربری موقت (یا یک حساب کاربری آزمایشگاهی) ایجاد شده توسط مدیر کارگاه انجام می شود. حساب آزمایشگاه مالک تمام پروژه های کارگاه است. مدیر کارگاه اعتبار اکانت آزمایشگاه (نام کاربری و رمز عبور) را در اختیار کاربر انجام دهنده کارگاه قرار می دهد. همه پروژه های کاربر با نام کاربری اکانت آزمایشگاه پیشوند می شوند، به عنوان مثال برای حساب آزمایشگاه [e-mail] ، شناسه پروژه مدیریت terraform user001-200131-01-tf-abcde و غیره برای بقیه پروژه ها خواهد بود. هر کاربر باید با حساب آزمایشگاهی ارائه شده توسط مدیر کارگاه وارد شده و با استفاده از حساب آزمایشگاه کارگاه را انجام دهد.

ایمیل شرکت خود را بررسی کنید (همان ایمیلی که برای ثبت نام در کارگاه استفاده کردید). شما باید از مدیر کارگاه ایمیلی با اعتبار حساب آزمایشگاهی خود (یعنی نام کاربری و رمز عبور) دریافت کرده باشید. ایمیل به این شکل است.

1. با کلیک بر روی لینک زیر، Cloud Shell را باز کنید.

پوسته ابری

2. با اعتبار حساب آزمایشگاهی وارد شوید (با حساب شرکتی یا شخصی خود وارد نشوید). حساب آزمایشگاهی شبیه userXYZ@<workshop_domain>.com است.
3. از آنجایی که این یک حساب جدید است، از شما خواسته می‌شود شرایط خدمات Google را بپذیرید. روی Accept کلیک کنید.

4. در صفحه بعدی، کادر تأیید را برای موافقت با شرایط خدمات Google انتخاب کنید و روی Start Cloud Shell کلیک کنید.

این مرحله یک لینوکس دبیان VM کوچک را برای شما فراهم می کند تا از آن برای دسترسی به منابع GCP استفاده کنید. هر حساب یک Cloud Shell VM دریافت می کند. ورود با شرایط حساب آزمایشگاهی و ورود شما با استفاده از اعتبار حساب آزمایشگاهی. علاوه بر 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 را تأیید کنید

فیلمنامه آهنگ سریع

اگر این روش را انتخاب کردید، اسکریپت زیر را برای تکمیل این آزمایشگاه اجرا کنید.

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

پس از تکمیل اسکریپت، bashrc خود را برای به روز رسانی متغیرها در جلسه Cloud Shell خود منبع کنید.

source ${HOME}/.bashrc

دستورالعمل های آزمایشگاه روش کپی و چسباندن

مهم: اگر قبلاً اسکریپت مسیر سریع را برای این آزمایشگاه تکمیل کرده‌اید، روش کپی و جای‌گذاری زیر را انجام ندهید**.**

دریافت اطلاعات کاربر

مدیر راه‌اندازی کارگاه باید اطلاعات نام کاربری و رمز عبور را در اختیار کاربر قرار دهد. همه پروژه های کاربر با نام کاربری به عنوان مثال برای کاربر [e-mail] پیشوند خواهند شد، شناسه پروژه مدیریت terraform user001-200131-01-tf-abcde و غیره برای بقیه پروژه ها خواهد بود. هر کاربر فقط به محیط کارگاه خود دسترسی دارد.

ابزار مورد نیاز کارگاه

این کارگاه برای بوت استرپ شدن از Cloud Shell در نظر گرفته شده است. ابزارهای زیر برای این کارگاه مورد نیاز است.

همه ابزارها به جز kustomize و pv به طور پیش فرض در Cloud Shell نصب شده اند. در زیر دستورالعمل نصب هر دو را خواهید دید.

• gcloud (ver >= 270)
• کوبکتل
• sed (با sed در Cloud Shell/Linux کار می کند و نه Mac OS)
• git (مطمئن شوید که به روز هستید)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• سفارشی کردن
• pv

به پروژه مدیریت terraform دسترسی پیدا کنید

پس از تکمیل اسکریپت bootstrap_workshop.sh، یک پوشه GCP برای هر کاربر در سازمان ایجاد می شود. در داخل پوشه، یک پروژه مدیریت terraform ایجاد می شود. پروژه terraform admin برای ایجاد باقیمانده منابع GCP مورد نیاز برای این کارگاه استفاده می شود. اسکریپت setup-terraform-admin-project.sh API های مورد نیاز را در پروژه مدیریت terraform فعال می کند. Cloud Build برای اعمال پلان های Terraform استفاده می شود. از طریق اسکریپت، به حساب سرویس Cloud Build نقش های IAM مناسب می دهید تا بتواند منابعی را در GCP ایجاد کند. در نهایت، یک Backend راه دور در یک سطل Google Cloud Storage (GCS) پیکربندی شده است تا حالت های Terraform را برای همه منابع GCP ذخیره کند.

برای مشاهده وظایف Cloud Build در پروژه terraform admin، به شناسه پروژه terraform admin نیاز دارید. این در سطل GCS مدیریت که در اسکریپت بوت استرپ مشخص شده است ذخیره می شود. اگر اسکریپت بوت استرپ را برای چندین کاربر اجرا می کنید، همه شناسه های پروژه مدیریت terraform در سطل GCS قرار دارند.

این کارگاه برای اجرا در Cloud Shell و Cloud Console در نظر گرفته شده است. مراحل زیر را در یک پنجره INCOGNITO انجام دهید زیرا با یک نام کاربری و رمز عبور جداگانه وارد سیستم خواهید شد.

1. Cloud Shell را باز کنید (اگر قبلاً از قسمت Lab Setup and Prep باز نشده باشد) با کلیک روی پیوند زیر.

پوسته ابری

2. kustomize (اگر قبلاً نصب نشده است) را در پوشه $HOME/bin نصب کنید و پوشه $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. درخواست bash خود را به روز کنید.

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. ID پروژه مدیریت Terraform خود را با اجرای دستور زیر دریافت کنید:

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

7. تمام منابع مرتبط با کارگاه به عنوان متغیر در یک فایل vars.sh ذخیره شده در یک سطل GCS در پروژه terraform admin ذخیره می شوند. فایل vars.sh را برای پروژه مدیریت terraform خود دریافت کنید.

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. روی پیوند نمایش داده شده کلیک کنید تا صفحه Cloud Build برای پروژه مدیریت Terraform باز شود و تأیید شود که ساخت با موفقیت انجام شده است.

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 اولیه روی آخرین ساخت کلیک کنید. منابع زیر به عنوان بخشی از اسکریپت Terraform ایجاد شده است. همچنین می توانید به نمودار معماری بالا مراجعه کنید.

• 4 پروژه GCP در سازمان. حساب صورتحساب ارائه شده با هر پروژه مرتبط است.
• یک پروژه network host project برای VPC مشترک است. هیچ منبع دیگری در این پروژه ایجاد نشده است.
• یکی از پروژه‌ها ops project است که برای خوشه‌های هواپیمای کنترل Istio GKE استفاده می‌شود.
• دو پروژه نشان دهنده دو تیم توسعه متفاوت است که بر روی خدمات مربوطه خود کار می کنند.
• دو خوشه GKE در هر یک از سه پروژه ops ، dev1 و dev2 ایجاد شده است.
• یک مخزن CSR به نام k8s-repo ایجاد می شود که حاوی شش پوشه برای فایل های مانیفست Kubernetes است. یک پوشه در هر خوشه GKE. این مخزن برای استقرار مانیفست های Kubernetes در خوشه ها به شکل GitOps استفاده می شود.
• یک تریگر Cloud Build ایجاد می‌شود تا هر زمان که یک commit به شاخه اصلی k8s-repo وجود دارد، مانیفست‌های Kubernetes را در خوشه‌های GKE از پوشه‌های مربوطه خود مستقر می‌کند.

فیلمنامه ترافورم 40 تا 50 دقیقه طول می کشد.

10. پس از تکمیل ساخت در terraform admin project ، ساخت دیگری در پروژه ops شروع می شود. روی پیوند نمایش داده شده کلیک کنید تا صفحه Cloud Build برای ops project باز شود و تأیید شود که ساخت کلود k8s-repo با موفقیت به پایان رسیده است.

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
 

این اسکریپت یک فایل kubeconfig جدید در پوشه gke به نام kubemesh ایجاد می کند.

12. متغیر KUBECONFIG را تغییر دهید تا به فایل kubeconfig جدید اشاره کند.

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

13. vars.sh و KUBECONFIG var را به bashrc. در Cloud Shell اضافه کنید تا هر بار که 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. مطمئن شوید که Istio روی هر دو کلاستر dev1 نصب شده است. فقط Citadel، sidecar-injector و coredns در کلاسترهای dev1 اجرا می شوند. آنها یک هواپیمای کنترلی Istio دارند که در خوشه ops-1 در حال اجراست.

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

17. مطمئن شوید که Istio روی هر دو خوشه dev2 نصب شده است. فقط Citadel، sidecar-injector و coredns در خوشه‌های dev2 اجرا می‌شوند. آنها یک هواپیمای کنترلی ایستیو دارند که در خوشه ops-2 در حال اجراست.

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

    `Output (do not copy)`

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

کشف سرویس برای هواپیماهای کنترل مشترک را تأیید کنید

18. در صورت تمایل، بررسی کنید که اسرار مستقر هستند.

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

    `Output (do not copy)`

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

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

در این کارگاه، شما از یک VPC مشترک استفاده می‌کنید که در آن همه خوشه‌های GKE ایجاد می‌شوند. برای کشف سرویس‌ها در میان خوشه‌ها، از فایل‌های kubeconfig (برای هر یک از خوشه‌های برنامه) استفاده می‌کنید که به‌عنوان راز در خوشه‌های عملیاتی ایجاد شده‌اند. Pilot از این اسرار برای کشف سرویس ها با پرس و جو از سرور Kube API خوشه های برنامه (تأیید شده از طریق اسرار بالا) استفاده می کند. مشاهده می کنید که هر دو دسته عملیاتی می توانند با استفاده از رازهای ایجاد شده توسط kubeconfig به همه خوشه های برنامه احراز هویت کنند. خوشه‌های Ops می‌توانند به‌طور خودکار خدمات را با استفاده از فایل‌های kubeconfig به عنوان یک روش مخفی کشف کنند. این مستلزم آن است که Pilot در خوشه‌های عملیاتی به سرور Kube API همه خوشه‌های دیگر دسترسی داشته باشد. اگر Pilot نمی تواند به سرورهای Kube API دسترسی پیدا کند، می توانید خدمات راه دور را به صورت دستی به عنوان ServiceEntries اضافه کنید. می توانید ServiceEntries را به عنوان ورودی های DNS در رجیستری سرویس خود در نظر بگیرید. ServiceEntries یک سرویس را با استفاده از یک نام DNS کاملا واجد شرایط ( FQDN ) و یک آدرس IP که در آن می توان به آن دسترسی داشت، تعریف می کند. برای اطلاعات بیشتر به اسناد Istio Multicluster مراجعه کنید.

6. Infrastructure Repo توضیح داد

ساخت ابر زیرساخت

منابع GCP برای کارگاه با استفاده از Cloud Build و infrastructure مخزن CSR ساخته شده است. شما فقط یک اسکریپت بوت استرپ (واقع در scripts/bootstrap_workshop.sh ) را از ترمینال محلی خود اجرا کردید. اسکریپت بوت استرپ یک پوشه GCP، یک پروژه مدیریت terraform و مجوزهای IAM مناسب برای حساب سرویس Cloud Build ایجاد می کند. پروژه مدیریت Terraform برای ذخیره حالت های ترافورم، لاگ ها و اسکریپت های متفرقه استفاده می شود. این شامل infrastructure و مخازن CSR k8s_repo است. این مخازن در بخش بعدی به تفصیل توضیح داده شده است. هیچ منبع کارگاه دیگری در پروژه مدیریت terraform ساخته نشده است. حساب سرویس Cloud Build در پروژه terraform admin برای ساخت منابع برای کارگاه استفاده می شود.

یک فایل cloudbuild.yaml واقع در پوشه infrastructure برای ساخت منابع GCP برای کارگاه استفاده می شود. این یک تصویر سازنده سفارشی با تمام ابزارهای مورد نیاز برای ایجاد منابع GCP ایجاد می کند. این ابزارها شامل gcloud SDK، terraform و ابزارهای دیگر مانند python، git، jq و غیره است. تصویر سازنده سفارشی terraform plan را اجرا می کند و برای هر منبع apply . فایل های terraform هر منبع در پوشه های جداگانه قرار دارند (جزئیات در بخش بعدی). منابع در یک زمان و به ترتیبی که معمولاً چگونه ساخته می شوند ساخته می شوند (به عنوان مثال، یک پروژه GCP قبل از ایجاد منابع در پروژه ساخته می شود). لطفاً فایل cloudbuild.yaml را برای جزئیات بیشتر بررسی کنید.

هر زمان که تعهدی به مخزن infrastructure وجود داشته باشد، Cloud Build فعال می شود. هر تغییری که در زیرساخت ایجاد شود به عنوان زیرساخت به عنوان کد (IaC) ذخیره می شود و به مخزن متعهد می شود. وضعیت کارگاه شما همیشه در این مخزن ذخیره می شود.

ساختار پوشه - تیم ها، محیط ها و منابع

مخزن زیرساخت منابع زیرساخت GCP را برای کارگاه تنظیم می کند. این به پوشه ها و زیر پوشه ها ساختار یافته است. پوشه های پایه در مخزن نشان دهنده team است که دارای منابع GCP خاص است. لایه بعدی پوشه ها نشان دهنده environment خاص تیم است (به عنوان مثال dev، stage، prod). لایه بعدی پوشه ها در محیط، resource خاصی را نشان می دهد (به عنوان مثال host_project، gke_cluster و غیره). اسکریپت های مورد نیاز و فایل های terraform در پوشه های منبع وجود دارند.

چهار نوع تیم زیر در این کارگاه حضور دارند:

1. زیرساخت - نشان دهنده تیم زیرساخت ابری است. آنها مسئول ایجاد منابع GCP برای همه تیم های دیگر هستند. آنها از پروژه مدیریت Terraform برای منابع خود استفاده می کنند. خود مخزن زیرساخت در پروژه مدیریت Terraform و همچنین فایل های Terraform State (در زیر توضیح داده شده است) وجود دارد. این منابع توسط یک اسکریپت bash در طول فرآیند بوت استرپ ایجاد می شوند (برای جزئیات به ماژول 0 - گردش کار مدیر مراجعه کنید).
2. شبکه - نشان دهنده تیم شبکه است. آنها مسئول VPC و منابع شبکه هستند. آنها مالک منابع GCP زیر هستند.
3. host project - نشان دهنده پروژه میزبان مشترک VPC است.
4. shared VPC - نشان دهنده VPC مشترک، زیرشبکه ها، محدوده IP ثانویه، مسیرها و قوانین فایروال است.
5. ops - نشان دهنده تیم عملیات/devops است. آنها صاحب منابع زیر هستند.
6. ops project - نشان دهنده یک پروژه برای همه منابع عملیاتی است.
7. gke clusters - یک خوشه ops GKE در هر منطقه. صفحه کنترل Istio در هر یک از خوشه های ops GKE نصب شده است.
8. k8s-repo - مخزن CSR که حاوی مانیفست های GKE برای همه خوشه های GKE است.
9. برنامه ها - نشان دهنده تیم های برنامه است. این کارگاه دو تیم app1 و app2 را شبیه سازی می کند. آنها صاحب منابع زیر هستند.
10. app projects - هر تیم برنامه مجموعه ای از پروژه های خود را دریافت می کند. این به آنها اجازه می دهد که صورتحساب و IAM را برای پروژه خاص خود کنترل کنند.
11. gke clusters - اینها خوشه‌های برنامه‌ای هستند که کانتینرها/Pods برنامه اجرا می‌شوند.
12. gce instances - به صورت اختیاری، اگر برنامه‌هایی داشته باشند که روی نمونه‌های GCE اجرا شوند. در این کارگاه، app1 دارای چند نمونه GCE است که در آن بخشی از برنامه اجرا می شود.

در این کارگاه، همان اپلیکیشن (برنامه فروشگاه هیپستر) هم اپلیکیشن 1 و هم اپلیکیشن 2 را نشان می دهد.

ارائه دهنده، ایالت ها و خروجی ها - پس زمینه ها و حالت های مشترک

ارائه دهندگان google و google-beta در gcp/[environment]/gcp/provider.tf قرار دارند. فایل provider.tf در هر پوشه منبع پیوند شده است. این به شما امکان می دهد به جای مدیریت جداگانه ارائه دهندگان برای هر منبع، ارائه دهنده را در یک مکان تغییر دهید.

هر منبع حاوی یک فایل backend.tf است که مکان فایل tfstate منبع را مشخص می کند. این فایل backend.tf از یک الگو (واقع در templates/backend.tf_tmpl ) با استفاده از یک اسکریپت (واقع در scripts/setup_terraform_admin_project ) تولید می‌شود و سپس در پوشه منبع مربوطه قرار می‌گیرد. سطل‌های Google Cloud Storage (GCS) برای backendها استفاده می‌شوند. نام پوشه سطل GCS با نام منبع مطابقت دارد. همه منابع پشتیبان در پروژه مدیریت terraform قرار دارند.

منابع با مقادیر وابسته به هم حاوی یک فایل output.tf هستند. مقادیر خروجی مورد نیاز در فایل tfstate تعریف شده در backend برای آن منبع خاص ذخیره می شود. به عنوان مثال، برای ایجاد یک کلاستر GKE در یک پروژه، باید شناسه پروژه را بدانید. شناسه پروژه از طریق output.tf به فایل tfstate خروجی می شود که می تواند از طریق منبع داده terraform_remote_state در منبع خوشه GKE استفاده شود.

فایل shared_state یک منبع داده terraform_remote_state است که به فایل tfstate یک منبع اشاره می کند. یک فایل shared_state_[resource_name].tf (یا فایل‌ها) در پوشه‌های منبع وجود دارد که به خروجی‌های منابع دیگر نیاز دارند. به عنوان مثال، در پوشه منبع ops_gke ، فایل‌های shared_state از منابع ops_project و shared_vpc وجود دارد، زیرا برای ایجاد خوشه‌های GKE در پروژه ops به شناسه پروژه و جزئیات VPC نیاز دارید. فایل‌های shared_state از یک الگو (واقع در templates/shared_state.tf_tmpl ) با استفاده از یک اسکریپت (واقع در scripts/setup_terraform_admin_project ) تولید می‌شوند. همه فایل‌های shared_state منابع در پوشه gcp/[environment]/shared_states قرار می‌گیرند. فایل‌های shared_state مورد نیاز در پوشه‌های منبع مربوطه پیوند می‌شوند. قرار دادن همه فایل‌های shared_state در یک پوشه و پیوند علامت‌گذاری آن‌ها در پوشه‌های منبع مناسب، مدیریت همه فایل‌های حالت را در یک مکان آسان می‌کند.

متغیرها

تمام مقادیر منابع به عنوان متغیرهای محیطی ذخیره می شوند. این متغیرها (به عنوان عبارات صادرات) در فایلی به نام vars.sh که در یک سطل GCS در پروژه مدیریت terraform قرار دارد، ذخیره می شوند. این شامل شناسه سازمان، حساب صورت‌حساب، شناسه‌های پروژه، جزئیات خوشه GKE و غیره است. می‌توانید vars.sh از هر پایانه‌ای دانلود و منبع کنید تا مقادیر تنظیمات خود را دریافت کنید.

متغیرهای Terraform در vars.sh به عنوان TF_VAR_[variable name] ذخیره می‌شوند. از این متغیرها برای تولید فایل variables.tfvars در پوشه منبع مربوطه استفاده می شود. فایل variables.tfvars شامل تمام متغیرها به همراه مقادیر آنهاست. فایل variables.tfvars از یک فایل الگو در همان پوشه با استفاده از یک اسکریپت (واقع در scripts/setup_terraform_admin_project ) تولید می شود.

K8s Repo توضیح داد

k8s_repo یک مخزن CSR (جدا از مخزن زیرساخت) است که در پروژه مدیریت Terraform قرار دارد. برای ذخیره و اعمال مانیفست های GKE برای همه خوشه های GKE استفاده می شود. k8s_repo توسط زیرساخت Cloud Build ایجاد شده است (برای جزئیات به بخش قبلی مراجعه کنید). در طول فرآیند ساخت ابری زیرساخت اولیه، در مجموع شش کلاستر GKE ایجاد می شود. در k8s_repo ، شش پوشه ایجاد می شود. هر پوشه (نام مطابق با نام خوشه GKE) مربوط به یک خوشه GKE است که حاوی فایل های مانیفست منابع مربوطه است. شبیه به ساخت زیرساخت، از Cloud Build برای اعمال مانیفست های Kubernetes در تمام خوشه های GKE با استفاده از k8s_repo استفاده می شود. هر زمان که تعهدی به مخزن k8s_repo وجود داشته باشد، Cloud Build راه اندازی می شود. مشابه زیرساخت، همه مانیفست های Kubernetes به عنوان کد در مخزن k8s_repo ذخیره می شوند و وضعیت هر خوشه GKE همیشه در پوشه مربوطه ذخیره می شود.

به عنوان بخشی از ساخت زیرساخت اولیه، k8s_repo ایجاد می شود و Istio بر روی همه کلاسترها نصب می شود.

پروژه ها، خوشه های GKE و فضاهای نام

منابع این کارگاه به پروژه های مختلف GCP تقسیم می شود. پروژه ها باید با ساختار سازمانی (یا تیمی) شرکت شما مطابقت داشته باشند. تیم‌هایی (در سازمان شما) که مسئول پروژه‌ها/محصولات/منابع مختلف هستند از پروژه‌های مختلف GCP استفاده می‌کنند. داشتن پروژه های جداگانه به شما امکان می دهد مجموعه های جداگانه ای از مجوزهای IAM ایجاد کنید و صورتحساب را در سطح پروژه مدیریت کنید. علاوه بر این، سهمیه ها نیز در سطح پروژه مدیریت می شوند.

پنج تیم در این کارگاه حضور دارند که هر کدام پروژه خود را دارند.

1. تیم زیرساختی که منابع GCP را می سازد از Terraform admin project استفاده می کند. آنها زیرساخت را به عنوان کد در یک مخزن CSR (به نام infrastructure ) مدیریت می کنند و تمام اطلاعات وضعیت Terraform مربوط به منابع ساخته شده در GCP را در سطل های GCS ذخیره می کنند. آنها دسترسی به مخزن CSR و سطل GCS State Terraform را کنترل می کنند.
2. تیم شبکه ای که VPC مشترک را می سازد از host project استفاده می کند. این پروژه شامل VPC، زیرشبکه ها، مسیرها و قوانین فایروال است. داشتن یک VPC مشترک به آنها اجازه می دهد تا به صورت متمرکز شبکه را برای منابع GCP مدیریت کنند. همه پروژه ها از این VPC مشترک برای شبکه استفاده کردند.
3. تیم ops/platform که خوشه‌های GKE و هواپیماهای کنترلی ASM/Istio را می‌سازد از ops project استفاده می‌کنند. آنها چرخه عمر خوشه های GKE و مش خدمات را مدیریت می کنند. آنها مسئول سخت کردن خوشه ها، مدیریت انعطاف پذیری و مقیاس پلت فرم Kubernetes هستند. در این کارگاه شما از روش gitops برای استقرار منابع به Kubernetes استفاده می کنید. یک مخزن CSR (به نام k8s_repo ) در پروژه ops وجود دارد.
4. در نهایت، تیم‌های dev1 و dev2 (نماینده دو تیم توسعه هستند) که برنامه‌های کاربردی را می‌سازند از پروژه‌های dev1 و dev2 projects خود استفاده می‌کنند. اینها برنامه ها و خدماتی هستند که شما به مشتریان خود ارائه می دهید. اینها بر روی پلتفرمی ساخته شده اند که تیم عملیات مدیریت می کند. منابع (استقرار، خدمات و غیره) به k8s_repo منتقل می شوند و در خوشه های مناسب مستقر می شوند. توجه به این نکته ضروری است که این کارگاه بر روی بهترین شیوه ها و ابزارهای CI/CD تمرکز ندارد. شما از Cloud Build برای خودکار کردن استقرار منابع Kubernetes در خوشه های GKE به طور مستقیم استفاده می کنید. در سناریوهای تولید دنیای واقعی، شما از یک راه حل مناسب CI/CD برای استقرار برنامه ها در خوشه های GKE استفاده می کنید.

در این کارگاه دو نوع خوشه GKE وجود دارد.

1. خوشه های OPS - توسط تیم OPS برای اجرای ابزارهای DevOps استفاده می شود. در این کارگاه ، آنها هواپیمای کنترل ASM/Istio را برای مدیریت مش خدمات اجرا می کنند.
2. خوشه های برنامه (برنامه ها) - توسط تیم های توسعه برای اجرای برنامه ها استفاده می شود. در این کارگاه از برنامه فروشگاه Hipster استفاده می شود.

جدا کردن ابزار OPS/Admin از خوشه های اجرا شده برنامه به شما امکان می دهد چرخه زندگی هر منبع را به طور مستقل مدیریت کنید. دو نوع خوشه نیز در پروژه های مختلف مربوط به تیم/محصول وجود دارد که از آنها استفاده می کند و باعث می شود مجوزهای IAM نیز مدیریت شوند.

در مجموع شش خوشه GKE وجود دارد. دو خوشه OPS منطقه ای در پروژه OPS ایجاد شده است. هواپیمای کنترل ASM/ISTIO در هر دو خوشه OPS نصب شده است. هر خوشه OPS در منطقه دیگری است. علاوه بر این ، چهار خوشه کاربردی منطقه ای وجود دارد. اینها در پروژه های خاص خود ایجاد شده اند. این کارگاه دو تیم توسعه را هر یک پروژه های خاص خود را شبیه سازی می کند. هر پروژه شامل دو خوشه برنامه است. خوشه های برنامه خوشه های منطقه ای در مناطق مختلف هستند. چهار خوشه برنامه در دو منطقه و چهار منطقه قرار دارد. به این ترتیب شما افزونگی منطقه ای و منطقه ای دریافت می کنید.

برنامه مورد استفاده در این کارگاه ، برنامه Hipster Shop ، در هر چهار خوشه برنامه مستقر شده است. هر میکروسرویس در هر خوشه برنامه در فضای نام خود زندگی می کند. استقرار برنامه Hipster Shop (POD) در خوشه های OPS مستقر نمی شوند. با این حال ، فضای نام و منابع خدمات برای کلیه خدمات میکروسرویس نیز در خوشه های OPS ایجاد می شود. هواپیمای کنترل ASM/ISTIO از ثبت خدمات Kubernetes برای کشف خدمات استفاده می کند. در صورت عدم وجود خدمات (در خوشه های OPS) ، شما باید برای هر خدمتی که در خوشه برنامه اجرا می شود ، به صورت دستی سرویس دهی ایجاد کنید.

شما یک برنامه میکروسرویس 10 لایه را در این کارگاه مستقر می کنید. این برنامه یک برنامه تجارت الکترونیکی مبتنی بر وب به نام " Hipster Shop " است که در آن کاربران می توانند موارد را مرور کنند ، آنها را به سبد خرید اضافه کنند و آنها را خریداری کنند.

kubernetes تجلی و k8s_repo

شما از k8s_repo برای اضافه کردن منابع Kubernetes به همه خوشه های GKE استفاده می کنید. شما این کار را با کپی کردن مانیفست های Kubernetes و تعهد به k8s_repo انجام می دهید. تمام تعهدات مربوط به k8s_repo باعث ایجاد یک کار ساخت ابر می شود که Kubernetes را به خوشه های مربوطه می برد. مانیفست هر خوشه در یک پوشه جداگانه به نام همان نام خوشه قرار دارد.

شش نام خوشه ای عبارتند از:

1. GKE-ASM-1-R1-Prod- خوشه OPS منطقه ای در منطقه 1
2. GKE-ASM-2-R2-PROD- خوشه منطقه ای OPS در منطقه 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 در خوشه های برنامه ها

• کلون k8s-repo
• کپی کردن فروشگاه های hipster برای همه خوشه های برنامه ها
• برای برنامه Hipster Shop در خوشه های OPS خدمات ایجاد کنید
• تنظیم loadgenerators تنظیم کننده در خوشه های OPS برای آزمایش اتصال جهانی
• اتصال امن به برنامه Hipster Shop را تأیید کنید

فیلمنامه سریع آهنگ

اگر این روش را انتخاب کردید ، اسکریپت زیر را برای تکمیل این آزمایشگاه اجرا کنید.

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

دستورالعمل های آزمایشگاه روش کپی و چسباندن

اگر قبلاً اسکریپت Track Fast را برای این آزمایشگاه به پایان رسانده اید ، روش کپی و چسباندن را در زیر انجام ندهید. **

کلون repo منبع پروژه OPS

به عنوان بخشی از ساخت زیرساخت اولیه Terraform ، k8s-repo در حال حاضر در پروژه OPS ایجاد شده است.

1. یک دایرکتوری خالی برای repo git ایجاد کنید:

mkdir $WORKDIR/k8s-repo
 

2. init 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 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 را در repo منبع کپی کنید.

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 ، 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 را از همه به جز یک خوشه dev حذف کنید. HipsterShop برای استقرار چند خوشه ای ساخته نشده است ، بنابراین برای جلوگیری از نتایج متناقض ، ما فقط از یک سرویس دهنده استفاده می کنیم.

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. استقرار CartService ، RBAC و PodsecurityPolicy را به Kustomization.yAML اضافه کنید.

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. حذف podsecuritypolicies ، استقرار و دایرکتوری های RBAC از خوشه های OPS kustomization.yaml

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

10. project_id را در مانیفست های RBAC جایگزین کنید.

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 را کپی کنید و مجازی های مجازی را برای خوشه های OPS به منبع منبع بازپرداخت کنید.

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

12. منابع اتصال پیکربندی را در یکی از خوشه های هر پروژه کپی کنید.

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

13. Project_ID را در مانیفست های کانتی پیکربندی جایگزین کنید.

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

14. کپی loadgenerator (استقرار ، PodSecurityPolicy و RBAC) را به خوشه های OPS کپی کنید. برنامه Hipster Shop با استفاده از یک متعادل کننده بار جهانی Google Cloud (GCLB) در معرض دید قرار می گیرد. GCLB ترافیک مشتری را دریافت می کند (به مقصد frontend ) و آن را به نزدیکترین نمونه خدمات ارسال می کند. قرار دادن loadgenerator در هر دو خوشه OPS باعث می شود ترافیک به هر دو دروازه Ingress Istio که در خوشه های OPS اجرا می شوند ، ارسال شود. تعادل بار در بخش زیر به تفصیل توضیح داده شده است.

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. شناسه پروژه OPS را در loadgenerator برای هر دو خوشه OPS جایگزین کنید.

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

16. منابع loadgenerator را به Kustomization.yAML برای هر دو خوشه OPS اضافه کنید.

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 Project Cloud Build در یک برگه قبلاً باز شده یا با کلیک بر روی لینک زیر:

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

استقرار برنامه را تأیید کنید

19. تأیید غلاف ها در کلیه فضای نام برنامه ها به جز سبد خرید در حالت در حال اجرا در همه خوشه های Dev است.

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. تأیید غلافها در فضای نام سبد خرید فقط در حالت اول در Cluster Dev Cluster قرار دارند.

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 در هر چهار خوشه برنامه اجرا می شود. یک متعادل کننده بار Google Cloud Load ( GCLB ) برای بدست آوردن ترافیک مشتری به هر چهار مورد از سرویس frontend استفاده می شود.

Istio Ingress Gateways فقط در خوشه های OPS اجرا می شود و به عنوان یک متعادل کننده بار منطقه ای به دو خوشه برنامه منطقه ای در منطقه عمل می کند. GCLB از دو دروازه Ingress Istio (در حال اجرا در دو خوشه OPS) به عنوان پشتیبان به سرویس Global Frontend استفاده می کند. Istio Ingress Gateways ترافیک مشتری را از GCLB دریافت می کند و سپس ترافیک مشتری را به سمت غلافهای جلوی که در خوشه های برنامه اجرا می شود ، ارسال می کند.

از طرف دیگر ، می توانید Istio Ingress Gateways را مستقیماً روی خوشه های برنامه قرار دهید و GCLB می تواند از آن ها به عنوان پشتیبان استفاده کند.

GKE Autoneg Controller

خدمات Istio Ingress Gateway Kubernetes خود را به عنوان پس زمینه GCLB با استفاده از گروه های نقطه پایانی شبکه (NEGS) ثبت می کند. NEG ها با استفاده از GCLB ها ، تعادل بار بومی کانتینر را امکان پذیر می کنند. NEG ها از طریق حاشیه نویسی ویژه در یک سرویس Kubernetes ایجاد می شوند ، بنابراین می تواند خود را در کنترل کننده NEG ثبت کند. Autoneg Controller یک کنترل کننده ویژه GKE است که ایجاد NEG ها و همچنین اختصاص دادن آنها به عنوان باکتری به GCLB با استفاده از حاشیه نویسی های سرویس است. هواپیماهای کنترل ISTIO از جمله دروازه های Ingress Istio در طول زیرساخت اولیه Terraform Cloud Build مستقر می شوند. پیکربندی GCLB و Autoneg به عنوان بخشی از ساخت اولیه زیرساخت زیرساخت Terraform انجام می شود.

ورود ایمن با استفاده از نقاط پایانی ابر و گواهینامه های مدیریت شده

از گواهینامه های مدیریت شده GCP برای تأمین ترافیک مشتری به سرویس GCLB frontend استفاده می شود. GCLB از گواهینامه های مدیریت شده برای سرویس جهانی frontend استفاده می کند و گواهینامه در GCLB خاتمه می یابد. در این کارگاه ، شما از نقاط پایانی Cloud به عنوان دامنه گواهی مدیریت شده استفاده می کنید. از طرف دیگر ، می توانید از frontend و نام DNS خود برای ایجاد مجوزهای مدیریت شده GCP استفاده کنید.

21. برای دسترسی به فروشگاه Hipster ، بر روی لینک خروجی دستور زیر کلیک کنید.

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

22. می توانید با کلیک بر روی نماد قفل در نوار URL برگه Chrome خود ، این گواهی را بررسی کنید.

تعادل بار جهانی را تأیید کنید

به عنوان بخشی از استقرار برنامه ، ژنراتورهای بار در هر دو خوشه OPS مستقر شدند که باعث ایجاد ترافیک آزمایش به لینک نقطه های پایان ابر Cloud GCLB Hipster Shop می شوند. تأیید کنید که GCLB در حال دریافت ترافیک و ارسال به هر دو دروازه Ingress Istio است.

23. پیوند GCLB> نظارت را برای پروژه OPS که در آن 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. تغییر از همه باکتری ها به Istio-ingressgateway از منوی کشویی پس زمینه همانطور که در شکل زیر نشان داده شده است.

25. توجه داشته باشید که ترافیک به هر دو istio-ingressgateways مراجعه کنید.

در هر istio-ingressgateway سه NEG وجود دارد. از آنجا که خوشه های OPS خوشه های منطقه ای هستند ، یک NEG برای هر منطقه در منطقه ایجاد می شود. غلافهای istio-ingressgateway ، با این حال ، در یک منطقه واحد در هر منطقه اجرا می شود. ترافیک در حال رفتن به غلافهای istio-ingressgateway نشان داده شده است.

ژنراتورهای بار در هر دو خوشه OPS در حال شبیه سازی ترافیک مشتری از دو منطقه ای هستند که در آن قرار دارند. بار تولید شده در منطقه خوشه OPS 1 به istio-ingressgateway در منطقه 2 ارسال می شود. در منطقه 2 به istio-ingressgateway ارسال می شود.

8- مشاهده با stackdriver

هدف: تله متری iStio را به stackdriver و اعتبارسنجی وصل کنید.

• منابع istio-telemetry را نصب کنید
• داشبورد خدمات ISTIO را ایجاد/به روز کنید
• مشاهده سیاهههای مربوط به کانتینر
• مشاهده ردیابی توزیع شده در StackDriver

فیلمنامه سریع آهنگ

اگر این روش را انتخاب کردید ، اسکریپت زیر را برای تکمیل این آزمایشگاه اجرا کنید.

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

دستورالعمل های آزمایشگاه روش کپی و چسباندن

اگر قبلاً اسکریپت Track Fast را برای این آزمایشگاه به پایان رسانده اید ، روش کپی و چسباندن را در زیر انجام ندهید. **

یکی از مهمترین ویژگی های ISTIO ، مشاهده داخلی ("O11y") است. این بدان معناست که حتی با وجود ظروف سیاه و بدون جعبه سیاه ، اپراتورها هنوز هم می توانند ترافیک وارد شده و خارج از این ظروف را مشاهده کنند و خدمات را به مشتریان ارائه دهند. این مشاهدات شکل چند روش مختلف را به خود می گیرد: معیارها ، سیاهههای مربوط و آثار.

ما همچنین از سیستم تولید بار داخلی در فروشگاه Hipster استفاده خواهیم کرد. مشاهده در یک سیستم استاتیک و بدون ترافیک خیلی خوب کار نمی کند ، بنابراین تولید بار به ما کمک می کند تا ببینیم که چگونه کار می کند. این بار در حال اجرا است ، اکنون ما فقط قادر به دیدن آن خواهیم بود.

1. istio را به پرونده پیکربندی 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 Project Cloud Build در یک برگه قبلاً باز شده یا با کلیک بر روی لینک زیر:

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

4. تأیید کنید که ادغام stackdriver iStio → CRD Handler StackDriver را دریافت کنید.

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"
 

از شما خواسته می شود یک فضای کاری جدید با نام پروژه OPS ایجاد کنید ، فقط OK را انتخاب کنید. اگر شما را در مورد UI جدید سوق می دهد ، فقط گفتگو را رد کنید.

در Metrics Explorer ، تحت عنوان "Find Resource Type و Metric" Type " istio " برای دیدن گزینه هایی مانند "تعداد درخواست سرور" در نوع منابع "Kubernetes Container" وجود دارد. این به ما نشان می دهد که معیارها از مش به StackDriver در جریان هستند.

(اگر می خواهید خطوط زیر را ببینید ، باید با برچسب destination_service_name گروه بندی کنید.)

تجسم معیارها با داشبورد:

اکنون که معیارهای ما در سیستم APM Stackdriver قرار دارند ، ما راهی برای تجسم آنها می خواهیم. در این بخش ، ما یک داشبورد از پیش ساخته شده را نصب خواهیم کرد که سه مورد از چهار " سیگنال طلایی " معیارها را به ما نشان می دهد: ترافیک (درخواست در ثانیه) ، تأخیر (در این حالت ، صدک 99 و 50) و خطاها (ما در این مثال به استثنای اشباع مجدد).

نماینده فرستاده استیو چندین معیار به ما می دهد ، اما این مجموعه خوبی برای شروع است. (لیست جامع اینجاست ). توجه داشته باشید که هر متریک مجموعه ای از برچسب ها را دارد که می تواند برای فیلتر ، جمع آوری استفاده شود ، مانند: Destination_Service ، Source_WorkLoad_Namespace ، Response_code ، ISTIO_TCP_RECEIVED_BYTES_TOTAL و غیره).

6. حال بیایید داشبورد از پیش تعیین شده خود را اضافه کنیم. ما قصد داریم مستقیماً از API داشبورد استفاده کنیم. این کاری است که شما معمولاً با تولید تماس های API انجام نمی دهید ، این بخشی از یک سیستم اتوماسیون خواهد بود ، یا اینکه داشبورد را به صورت دستی در UI وب می سازید. این باعث می شود ما به سرعت شروع کنیم:

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

7. برای مشاهده "داشبورد خدمات تازه اضافه شده" به لینک خروجی زیر بروید.

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

ما می توانیم داشبورد را با استفاده از UX ویرایش کنیم ، اما در مورد ما قصد داریم به سرعت با استفاده از API یک نمودار جدید اضافه کنیم. برای انجام این کار ، باید آخرین نسخه داشبورد را پایین بیاورید ، ویرایش های خود را اعمال کنید ، سپس با استفاده از روش HTTP Patch ، آن را به عقب فشار دهید.

8. با پرس و جو از API مانیتورینگ می توانید یک داشبورد موجود دریافت کنید. داشبورد موجود را که تازه اضافه شده است دریافت کنید:

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

9. یک نمودار جدید اضافه کنید: (50 ٪ ILE LATENCY): [ مرجع API ] اکنون می توانیم یک ویجت نمودار جدید را به صورت کد به داشبورد خود اضافه کنیم. این تغییر را می توان توسط همسالان بررسی کرده و در کنترل نسخه بررسی کرد. در اینجا یک ویجت برای افزودن وجود دارد که نشان می دهد 50 ٪ تأخیر ایل (تأخیر متوسط).

سعی کنید داشبورد را که تازه دریافت کرده اید ویرایش کنید و یک تنگی جدید اضافه کنید:

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

10. داشبورد خدمات موجود را به روز کنید:

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

11. داشبورد به روز شده را با پیمایش به لینک خروجی زیر مشاهده کنید:

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

12. تجزیه و تحلیل سیاهههای مربوطه را انجام دهید.

ISTIO مجموعه ای از سیاهههای مربوط به ساختاری را برای همه ترافیک شبکه در شبکه فراهم می کند و آنها را برای ورود به سیستم StackDriver بارگذاری می کند تا تجزیه و تحلیل متقابل خوشه ای در یک ابزار قدرتمند باشد. سیاههها با ابرداده سطح خدمات مانند خوشه ، کانتینر ، برنامه ، Connection_ID و غیره حاشیه نویسی می شوند.

یک ورود به سیستم به عنوان مثال (در این حالت ، AccessLog Proxy 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"
 

شما می توانید با انتخاب Resource> Kubernetes Container ، و جستجوی "خلبان" ، سیاهههای هواپیمای کنترل Istio را مشاهده کنید -

در اینجا ، ما می توانیم هواپیمای کنترل Istio را با فشار پیکربندی پروکسی به پروکسی های Sidecar برای هر سرویس برنامه نمونه مشاهده کنیم. "CDS" ، "LDS" و "RDS" نمایانگر API های مختلف فرستاده ( اطلاعات بیشتر ) هستند.

فراتر از سیاهههای مربوط به ISTIO ، می توانید سیاهههای مربوط به کانتینر و همچنین زیرساخت ها یا سایر خدمات GCP را در یک رابط یکسان پیدا کنید. در اینجا برخی از نمایشگاه های نمونه برای GKE آورده شده است. Viewer Logs همچنین به شما امکان می دهد معیارهایی را از سیاهههای مربوط ایجاد کنید (به عنوان مثال: "هر خطایی را که با برخی از رشته ها مطابقت دارد" بشمارید) که می تواند در داشبورد یا به عنوان بخشی از هشدار استفاده شود. سیاههها همچنین می توانند به سایر ابزارهای تجزیه و تحلیل مانند BigQuery پخش شوند.

برخی از فیلترهای نمونه برای فروشگاه hipster:

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. احراز هویت TLS متقابل

هدف: اتصال ایمن بین میکروسرویس (AUTHN).

• MESH Wide MTL را فعال کنید
• MTL ها را با بازرسی از سیاههها تأیید کنید

فیلمنامه سریع آهنگ

اگر این روش را انتخاب کردید ، اسکریپت زیر را برای تکمیل این آزمایشگاه اجرا کنید.

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

دستورالعمل های آزمایشگاه روش کپی و چسباندن

اگر قبلاً اسکریپت Track Fast را برای این آزمایشگاه به پایان رسانده اید ، روش کپی و چسباندن را در زیر انجام ندهید. **

اکنون که برنامه های ما نصب شده و مشاهده شده است ، می توانیم ارتباطات بین خدمات را شروع کنیم و مطمئن شویم که این کار را ادامه می دهد.

به عنوان مثال ، ما می توانیم در داشبورد Kiali ببینیم که خدمات ما از MTLS استفاده نمی کنند (بدون نماد "قفل"). اما ترافیک جریان دارد و سیستم خوب کار می کند. داشبورد معیارهای طلایی Stackdriver ما به ما آرامش خاطر می بخشد که به طور کلی همه چیز کار می کند.

1. Meshpolicy را در خوشه های OPS بررسی کنید. توجه داشته باشید 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 (CR) استفاده می کند. ما با به روزرسانی Istiocontrolplane CR و به روزرسانی K8S-REPO ، MTL ها را در تمام خوشه ها پیکربندی خواهیم کرد. تنظیم جهانی> MTLS> فعال: درست در Istiocontrolplane CR منجر به دو تغییر زیر در هواپیمای کنترل ISTIO می شود:

• Meshpolicy قرار است برای کلیه خدمات که در همه خوشه ها اجرا می شود ، MTLS MESH WRIPE را روشن کند.
• یک مقصد مقصد ایجاد شده است تا امکان ترافیک ISTIO_MUTUAL بین خدمات اجرا شده در همه خوشه ها فراهم شود.

2. ما یک وصله kustomize را در Istiocontrolplane CR اعمال خواهیم کرد تا خوشه MTLS گسترده شود. پچ را برای همه خوشه ها در DIR مربوطه کپی کرده و یک پچ 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 Project Cloud Build در یک برگه قبلاً باز شده یا با کلیک بر روی لینک زیر:

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

 

MTL ها را تأیید کنید

5. یک بار دیگر در خوشه های OPS 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. DestinationRule ایجاد شده توسط کنترلر اپراتور ISTIO را شرح دهید.

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

خروجی (کپی نکنید):

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

همچنین می توانیم حرکت HTTP به HTTPS را در سیاههها مشاهده کنیم.

ما می توانیم با کلیک بر روی یک ورودی ورود به سیستم ، این قسمت خاص را از سیاهههای مربوط به UI در معرض دید و سپس با کلیک بر روی مقدار فیلدی که می خواهید نمایش دهید ، در مورد ما ، روی "HTTP" در کنار "پروتکل کلیک کنید:

این منجر به روشی خوب برای تجسم تغییر می شود:

10. استقرار قناری

هدف: نسخه جدیدی از سرویس Frontend را باز کنید.

• سرویس Rollout frontend-v2 (نسخه تولید بعدی) در یک منطقه
• از DestinationRules و VirtualServices استفاده کنید تا به آرامی ترافیک را به سمت frontend-v2 هدایت کنید
• با بازرسی از مجموعه تعهدات به k8s-repo خط لوله استقرار Gitops را تأیید کنید

فیلمنامه سریع آهنگ

اگر این روش را انتخاب کردید ، اسکریپت زیر را برای تکمیل این آزمایشگاه اجرا کنید.

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

دستورالعمل های آزمایشگاه روش کپی و چسباندن

اگر قبلاً اسکریپت Track Fast را برای این آزمایشگاه به پایان رسانده اید ، روش کپی و چسباندن را در زیر انجام ندهید. **

استقرار قناری یک برنامه پیشرفته از یک سرویس جدید است. در استقرار قناری ، شما مقدار فزاینده ای از ترافیک را به نسخه جدید ارسال می کنید ، در حالی که هنوز درصد باقی مانده را به نسخه فعلی ارسال می کنید. یک الگوی مشترک انجام تجزیه و تحلیل قناری در هر مرحله از تقسیم ترافیک و مقایسه "سیگنال های طلایی" نسخه جدید (تأخیر ، میزان خطا ، اشباع) در برابر یک پایه است. این امر به جلوگیری از قطع شدن و اطمینان از ثبات سرویس جدید "V2" در هر مرحله از تقسیم ترافیک کمک می کند.

در این بخش ، شما یاد می گیرید که چگونه از سیاستهای ترافیکی Cloud Build و Istio استفاده کنید تا یک استقرار اساسی قناری برای نسخه جدید سرویس Frontend ایجاد کنید.

اول ، ما خط لوله قناری را در منطقه Dev1 (ایالات متحده-غربی 1) اجرا خواهیم کرد و جلوی V2 را در هر دو خوشه در آن منطقه قرار خواهیم داد. دوم ، ما خط لوله قناری را در منطقه DEV2 (ایالات متحده-مرکزی) اجرا خواهیم کرد و V2 را بر روی هر دو خوشه در آن منطقه مستقر خواهیم کرد. اجرای خط لوله در مناطق به ترتیب ، در مقابل موازی در همه مناطق ، به جلوگیری از قطع جهانی ناشی از پیکربندی بد یا با اشکالات موجود در برنامه V2 کمک می کند.

توجه : ما به صورت دستی خط لوله قناری را در هر دو منطقه قرار خواهیم داد ، اما در تولید ، شما از یک ماشه خودکار استفاده می کنید ، به عنوان مثال بر اساس یک برچسب تصویر Docker جدید که به یک رجیستری منتقل می شود.

1. از Cloud Shell ، برخی از متغیرهای ENV را برای ساده کردن بقیه دستورات تعریف کنید.

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 Patch (شامل برچسب "V1" و تصویری با نقطه پایانی "/نسخه")
• Respy ، یک غلاف کوچک که توزیع پاسخ HTTP را چاپ می کند ، و به ما در تجسم استقرار قناری در زمان واقعی کمک می کند.
• Frontend Istio DestinationRule - بر اساس برچسب استقرار "نسخه" ، سرویس Kubernetes Frontend Kubernetes را به دو زیر مجموعه ، V1 و V2 تقسیم می کند
• Frontend Istio VirtualService - 100 ٪ از ترافیک به Frontend V1. این امر بر رفتار پیش فرض Robin Robin سرویس Kubernetes غلبه می کند ، که بلافاصله 50 ٪ از کل ترافیک منطقه ای DEV1 را به Frontend V2 ارسال می کند.

3. تغییر در K8S_REPO:

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

4. مشاهده وضعیت OPS Project Cloud Build در یک برگه قبلاً باز شده یا با کلیک بر روی لینک زیر:

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

5. برای پروژه OPS1 به Cloud Build در کنسول بروید. صبر کنید تا خط لوله ساخت ابر کامل شود ، سپس در هر دو خوشه DEV1 غلاف را در فضای نام جلوی قرار دهید. شما باید موارد زیر را ببینید:

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

Output (do not copy)

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

توجه: CTRL-C برای خروج از دستورات ساعت

ما از TMUX برای تقسیم پنجره CloudShell خود در 2 صفحه استفاده خواهیم کرد:

• صفحه پایین دستور WATCH را برای مشاهده توزیع پاسخ HTTP برای سرویس Frontend اجرا می کند.
• صفحه بالا اسکریپت خط لوله واقعی قناری را اجرا می کند.

6. دستور را برای تقسیم پنجره Cloud Shell اجرا کنید و دستور Watch را در قسمت پایین اجرا کنید.

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 می رود ، که در مجازی جدید تعریف شده است.

7. خط لوله قناری را در منطقه DEV1 اجرا کنید. ما یک اسکریپت را ارائه می دهیم که درصد ترافیک 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 برای Frontend-V2 ، باید در انتهای اسکریپت یک پیام موفقیت مشاهده کنید:

    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. در لینک تولید شده به repos منبع ابر حرکت کنید.

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

شما باید یک تعهد جداگانه برای هر درصد ترافیک مشاهده کنید ، با جدیدترین تعهد در صدر لیست:

اکنون ، شما همان فرآیند را برای منطقه Dev2 تکرار خواهید کرد. توجه داشته باشید که منطقه Dev2 هنوز در V1 "قفل" است. این امر به این دلیل است که در اسکریپت repo_setup پایه ، ما یک سرویس مجازی را تحت فشار قرار دادیم تا صریح همه ترافیک را به V1 بفرستیم. به این ترتیب ، ما توانستیم با خیال راحت یک قناری منطقه ای را در DEV1 انجام دهیم و مطمئن شویم که قبل از انتشار نسخه جدید در سطح جهان با موفقیت اجرا شد.

12. دستور را برای تقسیم پنجره Cloud Shell اجرا کنید و دستور Watch را در قسمت پایین اجرا کنید.

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 می رود ، که در مجازی جدید تعریف شده است.

13. خط لوله قناری را در منطقه DEV2 اجرا کنید. ما یک اسکریپت را ارائه می دهیم که درصد ترافیک 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. از غلاف Respy در DEV2 ، تماشای ترافیک از غلاف 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 برای استقرار قناری منطقه ای معرفی شده است. در تولید ، به جای یک اسکریپت دستی ، ممکن است به طور خودکار این اسکریپت قناری را به عنوان یک خط لوله ساخت ابر انجام دهید ، با استفاده از یک ماشه مانند یک تصویر برچسب جدید که به رجیستری کانتینر منتقل می شود. همچنین می خواهید قبل از ارسال ترافیک بیشتر ، تجزیه و تحلیل قناری را در هر مرحله ، تجزیه و تحلیل تأخیر و خطای V2 در برابر آستانه ایمنی از پیش تعریف شده اضافه کنید.

11. سیاست های مجوز

هدف: RBAC را بین میکروسرویس (AUTHZ) تنظیم کنید.

• برای انکار دسترسی به میکروسرویس ، AuthorizationPolicy ایجاد کنید
• AuthorizationPolicy ایجاد کنید تا امکان دسترسی خاص به میکروسرویس را فراهم کند

فیلمنامه سریع آهنگ

اگر این روش را انتخاب کردید ، اسکریپت زیر را برای تکمیل این آزمایشگاه اجرا کنید.

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

دستورالعمل های آزمایشگاه روش کپی و چسباندن

اگر قبلاً اسکریپت Track Fast را برای این آزمایشگاه به پایان رسانده اید ، روش کپی و چسباندن را در زیر انجام ندهید. **

بر خلاف یک برنامه یکپارچه که ممکن است در یک مکان در حال اجرا باشد ، برنامه های MicroService در سطح جهانی توزیع شده در مرزهای شبکه تماس برقرار می کنند. این به معنای ورود بیشتر به برنامه های شما و فرصت های بیشتر برای حملات مخرب است. و از آنجا که غلافهای Kubernetes دارای IP های گذرا هستند ، قوانین سنتی فایروال مبتنی بر IP دیگر برای تأمین دسترسی بین بارهای کاری کافی نیستند. در یک معماری میکروسرویس ، رویکرد جدیدی برای امنیت لازم است. Istio با تکیه بر بلوک های ساختمان امنیتی Kubernetes مانند حساب های خدمات ، مجموعه ای انعطاف پذیر از سیاست های امنیتی را برای برنامه های شما فراهم می کند.

سیاست های Istio هم تأیید اعتبار و هم مجوز را پوشش می دهد. احراز هویت هویت را تأیید می کند (آیا این سرور کسی است که آنها می گویند؟) ، و مجوز مجوزها را تأیید می کند (آیا این مشتری مجاز به انجام این کار است؟). ما احراز هویت Istio را در بخش TLS متقابل در ماژول 1 (Meshpolicy) پوشش دادیم. در این بخش ، ما یاد خواهیم گرفت که چگونه از سیاست های مجوز ISTIO برای کنترل دسترسی به یکی از بارهای کار برنامه ، CurrencyService استفاده کنیم.

اول ، ما یک مجوز را در هر 4 خوشه dev ، بسته می کنیم ، همه دسترسی به CurrencyService را می بندیم و خطایی را در جلوی آن ایجاد می کنیم. سپس ، ما فقط به سرویس جبهه اجازه خواهیم داد تا به CurrencyService دسترسی پیدا کند.

1. محتوای currency-deny-all.yaml . یامل را بازرسی کنید. این خط مشی از انتخاب کنندگان برچسب استقرار برای محدود کردن دسترسی به ارز استفاده می کند. توجه کنید که چگونه هیچ یک از قسمت های spec وجود ندارد - این بدان معنی است که این خط مشی دسترسی به سرویس انتخاب شده را انکار می کند .

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

خروجی (کپی نکنید)

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

2. برای خوشه های OPS در هر دو منطقه ، خط مشی ارز را در K8S-REPO کپی کنید.

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

3. فشار را فشار دهید.

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

4. وضعیت OPS Project Cloud Build را در یک برگه قبلاً باز شده یا با کلیک روی پیوند زیر بررسی کنید:

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. بیایید بررسی کنیم که چگونه خدمات ارز این مجوز را اجرا می کند. ابتدا ، ورود به سیستم سطح ردیابی را در پروکسی فرستاده برای یکی از غلافهای ارزی فعال کنید ، زیرا تماس های مجوز مسدود شده به طور پیش فرض وارد نمی شوند.

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. سیاهههای مربوط به RBAC (مجوز) را از پروکسی SIDECAR سرویس ارز دریافت کنید. شما باید یک پیام "رد شده اجرا شده" را مشاهده کنید ، نشان می دهد که ارشاد سرویس برای جلوگیری از تمام درخواست های ورودی تنظیم شده است.

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"]

در اینجا ، ما برای دسترسی به خدمات ارزی در حال پخش لیست منبع خاص هستیم. این منبع. principal توسط حساب سرویس kubernetes تعریف شده است. در این حالت ، حساب خدماتی که ما Whitelisting داریم حساب خدمات جبهه در فضای نام Frontend است.

توجه: هنگام استفاده از حساب های خدمات Kubernetes در مجوزهای Istio ، ابتدا باید TL های متقابل خوشه ای را فعال کنید ، همانطور که در ماژول 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 Project Cloud Build در یک برگه قبلاً باز شده یا با کلیک بر روی لینک زیر:

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

12. بعد از اتمام ساخت با موفقیت ، مجدداً جلوی HipsterShop را باز کنید. این بار نباید در صفحه اصلی خطایی مشاهده کنید - این به این دلیل است که جلوی آن صریحاً مجاز به دسترسی به سرویس فعلی است.
13. اکنون ، با اضافه کردن موارد به سبد خرید خود و کلیک بر روی "سفارش مکان" ، سعی کنید یک پرداخت را انجام دهید. این بار ، شما باید خطای تبدیل قیمت را از خدمات ارزی مشاهده کنید - این به این دلیل است که ما فقط جلوی آن را لیست کرده ایم ، بنابراین خدمات پرداخت هنوز قادر به دسترسی به CurrencyService نیست.

14. سرانجام ، اجازه می دهیم با افزودن یک قانون دیگر به مجوز CurrencyService ما ، به خدمات پرداخت به ارز دسترسی پیدا کنیم . توجه داشته باشید که ما فقط دسترسی به ارز به دو سرویس دسترسی به آن را باز می کنیم - جلو و پرداخت. پس زمینه های دیگر هنوز مسدود خواهند شد.
15. باز کردن currency-allow-frontend-checkout.yaml توجه داشته باشید که لیست قوانین به عنوان یک منطقی یا ارز فقط درخواست های بار کاری را با هر یک از این دو حساب سرویس می پذیرد.

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 Project Cloud Build در یک برگه قبلاً باز شده یا با کلیک بر روی لینک زیر:

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

19. بعد از اتمام ساخت با موفقیت ، سعی کنید یک پرداخت را انجام دهید - باید با موفقیت کار کند.

در این بخش نحوه استفاده از سیاست های مجوز ISTIO برای اجرای کنترل دسترسی دانه ای در سطح هر سرویس انجام شد. در تولید ، شما ممکن است یک مجوز در هر سرویس ایجاد کنید ، و (به عنوان مثال) از یک خط مشی مجاز استفاده کنید تا به همه بارهای کاری در یک فضای نام یکسان دسترسی پیدا کنید.

12. مقیاس زیرساخت

هدف: زیرساخت های مقیاس با افزودن منطقه ، پروژه و خوشه های جدید.

• کلون repo infrastructure
• برای ایجاد منابع جدید ، پرونده های Terraform را به روز کنید
• 2 زیر شبکه در منطقه جدید (یکی برای پروژه OPS و دیگری برای پروژه جدید)
• خوشه جدید Ops در منطقه جدید (در زیر شبکه جدید)
• هواپیمای جدید کنترل Istio برای منطقه جدید
• 2 برنامه در پروژه جدید در منطقه جدید
• متعهد به repo infrastructure
• نصب را تأیید کنید

فیلمنامه سریع آهنگ

اگر این روش را انتخاب کردید ، اسکریپت زیر را برای تکمیل این آزمایشگاه اجرا کنید.

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

دستورالعمل های آزمایشگاه روش کپی و چسباندن

اگر قبلاً اسکریپت Track Fast را برای این آزمایشگاه به پایان رسانده اید ، روش کپی و چسباندن را در زیر انجام ندهید. **

چندین روش برای مقیاس بندی یک سکو وجود دارد. می توانید با اضافه کردن گره ها به خوشه های موجود ، محاسبه بیشتری را اضافه کنید. می توانید خوشه های بیشتری را در یک منطقه اضافه کنید. یا می توانید مناطق بیشتری را به سیستم عامل اضافه کنید. تصمیم گیری در مورد اینکه چه جنبه ای از پلتفرم برای مقیاس بستگی دارد به الزامات بستگی دارد. به عنوان مثال ، اگر در هر سه منطقه در یک منطقه خوشه دارید ، شاید اضافه کردن گره های بیشتر (یا استخرهای گره) به خوشه موجود ممکن است کافی باشد. با این حال ، اگر در دو یا سه منطقه در یک منطقه واحد خوشه دارید ، اضافه کردن یک خوشه جدید در منطقه سوم به شما مقیاس و دامنه گسل اضافی (یعنی یک منطقه جدید) می دهد. Another reason for adding a new cluster in a region might be the need to create a single tenant cluster - for regulatory or compliance reasons (for example PCI, or a database cluster that houses PII information). As your business and services expand, adding new regions become inevitable to provide services closer to the clients.

The current platform consists of two regions and clusters in two zones per region. You can think of scaling the platform in two ways:

• Vertically - within each region by adding more compute. This is done either by adding more nodes (or node pools) to existing clusters or by adding new clusters within the region. This is done via the infrastructure repo. The simplest path is adding nodes to existing clusters. No additional configuration is required. Adding new clusters may require additional subnets (and secondary ranges), adding appropriate firewall rules, adding the new clusters to the regional ASM/Istio service mesh control plane and deploying application resources to the new clusters.
• Horizontally - by adding more regions. The current platform gives you a regional template. It consists on a regional ops cluster where the ASM/Istio control please resides and two (or more) zonal application clusters where application resources are deployed.

In this workshop, you scale the platform "horizontally" as it encompasses the vertical use case steps as well. In order to horizontally, scale the platform by adding a new region (r3) to the platform, the following resources need to be added:

1. Subnets in the host project shared VPC in region r3 for the new ops and application clusters.
2. A regional ops cluster in region r3 where the ASM/Istio control plane resides.
3. Two zonal application clusters in two zones on region r3.
4. Update to the k8s-repo:
5. Deploy ASM/Istio control plane resources to the ops cluster in region r3.
6. Deploy ASM/Istio shared control plane resources to the app clusters in region r3.
7. While you don't need to create a new project, the steps in the workshop demonstrate adding a new project dev3 to cover the use case of adding a new team to the platform.

Infrastructure repo is used to add new resources stated above.

1. In Cloud Shell, navigate to WORKDIR and clone the infrastructure repo.

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. Clone the workshop source repo add-proj branch into the add-proj-repo directory.

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

 

3. Copy files from the add-proj branch in the source workshop repo. The add-proj branch contains the changes for this section.

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

4. Replace the infrastructure directory in the add-proj repo directory with a symlink to the infra-repo directory to allow the scripts on the branch to run.

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

5. Run the add-project.sh script to copy the shared states and vars to the new project directory structure.

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

6. Commit and push changes to create new project

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

7. The commit triggers the infrastructure repo to deploy the infrastructure with the new resources. View the Cloud Build progress by clicking on the output of the following link and navigating to the latest build at the top.

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

This step takes 25 - 30 minutes to complete. Good time for a coffee break.

The last step of the infrastructure Cloud Build creates new Kubernetes resources in the k8s-repo . This triggers the Cloud Build in the k8s-repo (in the ops project). The new Kubernetes resources are for the three new clusters added in the previous step. ASM/Istio control plane and shared control plane resources are added to the new clusters with the k8s-repo Cloud Build.

8. After the infrastructure Cloud Build successfully finishes, navigate to the k8s-repo latest Cloud Build run by clicking on the following output link.

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

9. Run the following script to add the new clusters to the vars and kubeconfig file.

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

10. Change the KUBECONFIG variable to point to the new kubeconfig file.

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

11. List your cluster contexts. You should see eight clusters.

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

Verify Istio Installation

12. Ensure Istio is installed on the new ops cluster by checking all pods are running and jobs have completed.

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. Ensure Istio is installed on both dev3 clusters. Only Citadel, sidecar-injector and coredns run in the dev3 clusters. They share an Istio controlplane running in the ops-3 cluster.

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

Verify service discovery for shared control planes

14. Verify the secrets are deployed in all ops clusters for all six application clusters.

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. Circuit Breaking

Objective: Implement a Circuit Breaker for the shipping Service.

• Create a DestinationRule for the shipping Service to implement a circuit breaker
• Use fortio (a load gen utility) to validate circuit breaker for the shipping Service by force tripping the circuit

Fast Track Script Lab Instructions

Fast Track Script Lab is coming soon!!

Copy-and-Paste Method Lab Instructions

Now that we've learned some basic monitoring and troubleshooting strategies for Istio-enabled services, let's look at how Istio helps you improve the resilience of your services, reducing the amount of troubleshooting you'll have to do in the first place.

A microservices architecture introduces the risk of cascading failures , where the failure of one service can propagate to its dependencies, and the dependencies of those dependencies, causing a "ripple effect" outage that can potentially affect end-users. Istio provides a Circuit Breaker traffic policy to help you isolate services, protecting downstream (client-side) services from waiting on failing services, and protecting upstream (server-side) services from a sudden flood of downstream traffic when they do come back online. Overall, using Circuit Breakers can help you avoid all your services failing their SLOs because of one backend service that is hanging.

The Circuit Breaker pattern is named for an electrical switch that can "trip" when too much electricity flows through, protecting devices from overload. In an Istio setup , this means that Envoy is the circuit breaker, keeping track of the number of pending requests for a service. In this default closed state, requests flow through Envoy uninterrupted.

But when the number of pending requests exceeds your defined threshold, the circuit breaker trips (opens), and Envoy immediately returns an error. This allows the server to fail fast for the client, and prevents the server application code from receiving the client's request when overloaded.

Then, after your defined timeout, Envoy moves to a half open state, where the server can start receiving requests again in a probationary way, and if it can successfully respond to requests, the circuit breaker closes again, and requests to the server begin to flow again.

This diagram summarizes the Istio circuit breaker pattern. The blue rectangles represent Envoy, the blue-filled circle represents the client, and the white-filled circles represent the server container:

You can define Circuit Breaker policies using Istio DestinationRules. In this section, we'll apply the following policy to enforce a circuit breaker for the shipping service:

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

There are two DestinationRule fields to note here. connectionPool defines the number of connections this service will allow. The outlierDetection field is where we configure how Envoy will determine the threshold at which to open the circuit breaker. Here, every second (interval), Envoy will count the number of errors it received from the server container. If it exceeds the consecutiveErrors threshold, the Envoy circuit breaker will open, and 100% of productcatalog pods will be shielded from new client requests for 10 seconds. Once the Envoy circuit breaker is open (ie. active), clients will receive 503 (Service Unavailable) errors. Let's see this in action.

1. Set environment variables for the k8s-repo and asm dir to simplify commands.

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

2. Update the k8s-repo

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

3. Update the shipping service DestinationRule on both Ops clusters.

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. Copy a Fortio load generator pod into the GKE_1 cluster in the Dev1 region. This is the client pod we'll use to "trip" the circuit breaker for 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. Wait for Cloud Build to complete.
7. Back in Cloud Shell, use the fortio pod to send gRPC traffic to shippingservice with 1 concurrent connection, 1000 requests total - this will not trip the circuit breaker, because we have not exceeded the connectionPool settings yet.

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 
 

Output (do not copy)

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

8. Now run fortio again, increasing the number of concurrent connections to 2, but keeping the total number of requests constant. We should see up to two-thirds of the requests return an "overflow" error, because the circuit breaker has been tripped: in the policy we defined, only 1 concurrent connection is allowed in a 1-second interval.

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 
 

Output (do not copy)

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 keeps track of the number of connections it dropped when the circuit breaker is active, with the upstream_rq_pending_overflow metric. Let's find this in the fortio pod:

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

Output (do not copy)

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. Clean up by removing the circuit breaker policy from both regions.

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
 

This section demonstrated how to set up a single circuit breaker policy for a service. A best practice is to set up a circuit breaker for any upstream (backend) service that has the potential to hang. By applying Istio circuit breaker policies, you help isolate your microservices, build fault tolerance into your architecture, and reduce the risk of cascading failures under high load.

14. Fault Injection

Objective: Test the resilience of the recommendation Service by introducing delays (before it is pushed to production).

• Create a VirtualService for the recommendation Service to introduce a 5s delay
• Test the delay using fortio load generator
• Remove the delay in the VirtualService and validate

Fast Track Script Lab Instructions

Fast Track Script Lab is coming soon!!

Copy-and-Paste Method Lab Instructions

Adding circuit breaker policies to your services is one way to build resilience against services in production. But circuit breaking results in faults — potentially user-facing errors — which is not ideal. To get ahead of these error cases, and better predict how your downstream services might respond when backends do return errors, you can adopt chaos testing in a staging environment. Chaos testing is the practice of deliberately breaking your services, in order to analyze weak points in the system and improve fault tolerance. You can also use chaos testing to identify ways to mitigate user-facing errors when backends fail - for instance, by displaying a cached result in a frontend.

Using Istio for fault injection is helpful because you can use your production release images, and add the fault at the network layer, instead of modifying source code. In production, you might use a full-fledged chaos testing tool to test resilience at the Kubernetes/compute layer in addition to the network layer.

You can use Istio for chaos testing by applying a VirtualService with the "fault" field. Istio supports two kinds of faults: delay faults (inject a timeout) and abort faults (inject HTTP errors). In this example, we'll inject a 5-second delay fault into the recommendations service . But this time instead of using a circuit breaker to "fail fast" against this hanging service, we will force downstream services to endure the full timeout.

11. Navigate into the fault injection directory.

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

12. Open k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml to inspect its contents. Notice that Istio has an option to inject the fault into a percentage of the requests - here, we'll introduce a timeout into all recommendationservice requests.

Output (do not copy)

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. Copy the VirtualService into k8s_repo. We'll inject the fault globally, across both regions.

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. Push changes

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

15. Wait for Cloud Build to complete.
16. Exec into the fortio pod deployed in the circuit breaker section, and send some traffic to 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:

Output (do not copy)

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. Another way to see the fault we injected in action is open the frontend in a web browser, and click on any product. A product page should take 5 extra seconds to load, since it fetches the recommendations that are displayed at the bottom of the page.
18. Clean up by removing the fault injection service from both Ops clusters.

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. Push changes:

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

15. Monitoring the Istio Control Plane

ASM installs four important control plane components: Pilot, Mixer, Galley and Citadel. Each sends its relevant monitoring metrics to Prometheus, and ASM ships with Grafana dashboards that let operators visualize this monitoring data and assess the health and performance of the control plane.

Viewing the Dashboards

20. Port-forward your Grafana service installed with Istio

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

21. Open Grafana in your browser
22. Click on the "Web Preview" icon on the top right corner of your Cloud Shell Window
23. Click Preview on port 3000 (Note: if the port is not 3000, click on change port and select port 3000)
24. This will open a tab in your browser with a URL similar to " BASE_URL/?orgId=1&authuser=0&environment_id=default "
25. View available dashboards
26. Modify the URL to " BASE_URL/dashboard "
27. Click on "istio" folder to view available dashboards
28. Click on any of those dashboards to view the performance of that component. We'll look at the important metrics for each component in the following sections.

Monitoring Pilot

Pilot is the control plane component that distributes networking and policy configuration to the data plane (the Envoy proxies). Pilot tends to scale with the number of workloads and deployments, although not necessarily with the amount of traffic to those workloads. An unhealthy Pilot can:

• consume more resources than necessary (CPU and/or RAM)
• result in delays in pushing updated configuration information to Envoys

Note: if Pilot is down, or if there are delays, your workloads still serve traffic.

23. Navigate to " BASE_URL/dashboard/db/istio-pilot-dashboard " in your browser to view Pilot metrics.

Important monitored metrics

استفاده از منابع

Use the Istio Performance and Scalability page as your guide for acceptable usage numbers. Contact GCP support if you see significantly more sustained resource usage than this.

Pilot Push Information

This section monitors Pilots pushes of configuration to your Envoy proxies.

• Pilot Pushes shows the type of configuration pushed at any given time.
• ADS Monitoring shows the number of Virtual Services, Services and Connected Endpoints in the system.
• Clusters with no known endpoints shows endpoints that have been configured but do not have any instances running (which may indicate external services, such as *.googleapis.com).
• Pilot Errors show the number of errors encountered over time.
• Conflicts show the number of conflicts which are ambiguous configuration on listeners.

If you have Errors or Conflicts, you have bad or inconsistent configuration for one or more of your services. See Troubleshooting the data plane for information.

Envoy Information

This section contains information about the Envoy proxies contacting the control plane. Contact GCP support if you see repeated XDS Connection Failures.

Monitoring Mixer

Mixer is the component that funnels telemetry from the Envoy proxies to telemetry backends (typically Prometheus, Stackdriver, etc). In this capacity, it is not in the data plane. It is deployed as two Kubernetes Jobs (called Mixer) deployed with two different service names (istio-telemetry and istio-policy).

Mixer can also be used to integrate with policy systems. In this capacity, Mixer does affect the data plane, as policy checks to Mixer that fail block access to your services.

Mixer tends to scale with volume of traffic.

24. Navigate to " BASE_URL/dashboard/db/istio-mixer-dashboard " in your browser to view Mixer metrics.

Important monitored metrics

استفاده از منابع

Use the Istio Performance and Scalability page as your guide for acceptable usage numbers. Contact GCP support if you see significantly more sustained resource usage than this.

Mixer Overview

• Response Duration is an important metric. While reports to Mixer telemetry are not in the datapath, if these latencies are high it will definitely slow down sidecar proxy performance. You should expect the 90th percentile to be in the single-digit milliseconds, and the 99th percentile to be under 100ms.

• Adapter Dispatch Duration indicates the latency Mixer is experiencing in calling adapters (through which it sends information to telemetry and logging systems). High latencies here will absolutely affect performance on the mesh. Again, p90 latencies should be under 10ms.

Monitoring Galley

Galley is Istio's configuration validation, ingestion, processing and distribution component. It conveys configuration from the Kubernetes API server to Pilot. Like Pilot, it tends to scale with the number of services and endpoints in the system.

25. Navigate to " BASE_URL/dashboard/db/istio-galley-dashboard " in your browser to view Galley metrics.

Important monitored metrics

Resource Validation

The most important metric to follow which indicates the number of resources of various types like Destination rules, Gateways and Service entries that are passing or failing validation.

Connected clients

Indicates how many clients are connected to Galley; typically this will be 3 (pilot, istio-telemetry, istio-policy) and will scale as those components scale.

16. Troubleshooting Istio

Troubleshooting the data plane

If your Pilot dashboard indicates that you have configuration issues, you should examine PIlot logs or use istioctl to find configuration problems.

To examine Pilot logs, run kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery, replacing istio-pilot-... with the pod identifier for the Pilot instance you want to troubleshoot.

In the resulting log, search for a Push Status message. به عنوان مثال:

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="
}

The Push Status will indicate any issues that occurred when trying to push the configuration to Envoy proxies – in this case, we see several "Duplicate cluster" messages, which indicate duplicate upstream destinations.

For assistance in diagnosing problems, contact Google Cloud support with issues.

Finding configuration errors

In order to use istioctl to analyze your configuration, run istioctl experimental analyze -k --context $OPS_GKE_1 . This will perform an analysis of configuration in your system, indicate any problems along with any suggested changes. See documentation for a full list of configuration errors that this command can detect.

17. Cleanup

The following steps are performed by an administrator after the workshop is completed.

An administrator runs the cleanup_workshop.sh script to delete resources created by the bootstrap_workshop.sh script. You need the following pieces of information for the cleanup script to run.

• Organization name - for example yourcompany.com
• Workshop ID - in the form YYMMDD-NN for example 200131-01
• Admin GCS bucket - defined in the bootstrap script.

13. Open Cloud Shell, perform all actions below in Cloud Shell. Click on the link below.

CLOUD SHELL

14. Verify you are logged into gcloud with the intended Admin user.

gcloud config list
 

15. Navigate you the asm folder.

cd ${WORKDIR}/asm
 

16. Define your Organization name and workshop ID to be deleted.

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

17. Run the cleanup script as follows.

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