ورشة عمل شبكات خدمة Anthos: دليل الميزات الاختبارية

1. ورشة عمل حول الإصدار الأولي

ملاحظة مهمة: هذه ورشة عمل في مرحلة الإصدار الأوّلي، وهي مخصّصة حصريًا للتدريب في الصف بإشراف معلّم.

رابط إلى ورشة عمل Codelab bit.ly/asm-workshop

2. نظرة عامة

مخطط الهندسة المعمارية

ورشة العمل هذه هي تجربة عملية غامرة تشرح كيفية إعداد الخدمات الموزّعة على مستوى العالم على "منصة Google Cloud" في مرحلة الإنتاج. تتضمّن التقنيات الرئيسية المستخدَمة Google Kubernetes Engine (GKE) للحوسبة وشبكة خدمات Istio لإنشاء اتصال آمن وإمكانية تتبّع البيانات وتشكيل الزيارات المتقدّمة. جميع الممارسات والأدوات المستخدَمة في ورشة العمل هذه هي نفسها التي ستستخدمها في مرحلة الإنتاج.

جدول الأعمال

• الوحدة 0 - مقدمة وإعداد المنصة
• المقدمة والبنية
• مقدمة عن شبكة الخدمات وIstio/ASM
• الدرس التطبيقي: إعداد البنية الأساسية: سير عمل المستخدم
• استراحة
• QnA
• الوحدة 1: تثبيت التطبيقات وتأمينها ومراقبتها باستخدام "إدارة تطبيقات Android"
• نموذج المستودع: شرح مستودعات البنية الأساسية وKubernetes
• المختبر: نشر تطبيق نموذجي
• الخدمات الموزّعة وإمكانية المراقبة
• الغداء
• ورشة عمل: إمكانية المراقبة باستخدام Stackdriver
• QNA
• الوحدة 2 - DevOps - عمليات طرح Canary، والسياسة/التحكّم المستند إلى الدور
• اكتشاف الخدمات المتعددة المجموعات والأمان/السياسة
• مختبر: بروتوكول أمان طبقة النقل الثنائي
• عمليات نشر Canary
• التدريب العملي: عمليات نشر Canary
• موازنة الحمل العالمية الآمنة على مستوى عدة مجموعات
• استراحة
• معمل: سياسة التفويض
• QNA
• الوحدة 3 - عمليات البنية الأساسية - ترقيات المنصة
• الوحدات الأساسية لخدمة Distributed Service
• الدرس التطبيقي: توسيع نطاق البنية الأساسية
• الخطوات التالية

العروض التقديمية من Google

يمكنك العثور على شرائح عرض ورشة العمل هذه على الرابط التالي:

شرائح ورشة عمل "إدارة متجر Play للمؤسسات"

المتطلبات الأساسية

يجب توفّر ما يلي قبل المتابعة في ورشة العمل هذه:

1. عقدة مؤسسة Google Cloud Platform
2. معرّف حساب فوترة (يجب أن يكون المستخدم مشرف فوترة في حساب الفوترة هذا)
3. دور "مشرف المؤسسة" في نظام إدارة الهوية وإمكانية الوصول (IAM) على مستوى المؤسسة للمستخدم

3- إعداد البنية الأساسية - سير عمل المشرف

ينفّذ المشرف الخطوات الواردة في هذا القسم عند إنشاء ورشة العمل.

إذا كنت مستخدمًا يشارك في ورشة العمل، انتقِل إلى القسم التالي بعنوان Infrastructure Setup - User Workflow

شرح نص ورشة عمل Bootstrap

يتم استخدام نص برمجي باسم bootstrap_workshop.sh لإعداد البيئة الأولية لورشة العمل. يمكنك استخدام هذا النص البرمجي لإعداد بيئة واحدة لك أو بيئات متعددة لمستخدمين متعددين في حال تقديم ورشة العمل هذه كتدريب لعدة مستخدمين.

يتطلّب نص ورشة العمل التمهيدية ما يلي كمدخلات:

• اسم المؤسسة (على سبيل المثال yourcompany.com): هذه هي المؤسسة التي تنشئ فيها بيئات لورشة العمل.
• معرّف الفوترة (مثل 12345-12345-12345): يُستخدَم معرّف الفوترة هذا لفوترة جميع الموارد المستخدَمة أثناء ورشة العمل.
• رقم ورشة العمل (على سبيل المثال 01) - رقم مكوّن من رقمَين يُستخدَم هذا الحقل في حال إجراء ورش عمل متعددة في يوم واحد وأردت تتبُّع كل منها بشكل منفصل. تُستخدم أرقام ورش العمل أيضًا لاشتقاق أرقام تعريف المشاريع. يؤدي توفّر أرقام ورش عمل منفصلة إلى تسهيل ضمان الحصول على أرقام تعريف فريدة للمشاريع في كل مرة. بالإضافة إلى رقم ورشة العمل، يتم أيضًا استخدام التاريخ الحالي (بالتنسيق YYMMDD) لأرقام تعريف المشاريع. يوفّر الجمع بين التاريخ ورقم ورشة العمل أرقام تعريف فريدة للمشاريع.
• رقم المستخدم الأول (على سبيل المثال 1): يشير هذا الرقم إلى المستخدم الأول في ورشة العمل. على سبيل المثال، إذا أردت إنشاء ورشة عمل لـ 10 مستخدمين، قد يكون لديك رقم مستخدم بداية يبلغ 1 ورقم مستخدم نهاية يبلغ 10.
• رقم المستخدم النهائي (على سبيل المثال 10) - يشير هذا الرقم إلى آخر مستخدم في ورشة العمل. على سبيل المثال، إذا أردت إنشاء ورشة عمل لـ 10 مستخدمين، قد يكون لديك رقم مستخدم بداية يبلغ 1 ورقم مستخدم نهاية يبلغ 10. إذا كنت بصدد إعداد بيئة واحدة (لنفسك مثلاً)، اجعل رقمَي المستخدمَين الأوّل والأخير متطابقَين. سيؤدي ذلك إلى إنشاء بيئة واحدة.

بالإضافة إلى التاريخ ورقم ورشة العمل، يتم أيضًا تضمين أرقام المستخدمين الأوائل والأواخر في أرقام تعريف المشاريع. يتم استخراج أرقام تعريف المستخدمين (الذين يشاركون في ورشة العمل) من رقم المستخدم الأول والأخير. يتم توضيح معرّفات المستخدمين في القسم الذي يحمل الاسم User schema and permissions performing the workshop.

• حزمة GCS الخاصة بالمشرف (مثلاً my-gcs-bucket-name): تُستخدم حزمة GCS لتخزين المعلومات ذات الصلة بورشة العمل. ويستخدم النص البرمجي cleanup_workshop.sh هذه المعلومات لحذف جميع الموارد التي تم إنشاؤها أثناء النص البرمجي لورشة عمل الإعداد الأوّلي. يجب أن يكون لدى المشرفين الذين ينشئون ورش عمل أذونات القراءة/الكتابة في هذه الحزمة.

يستخدم نص ورشة العمل التمهيدية القيم المقدَّمة أعلاه ويعمل كنص برمجي لتغليف النصوص البرمجية يستدعي النص البرمجي setup-terraform-admin-project.sh. ينشئ النص البرمجي setup-terraform-admin-project.sh بيئة ورشة العمل لمستخدم واحد.

أذونات المشرف مطلوبة لإعداد ورشة العمل

هناك نوعان من المستخدمين في ورشة العمل هذه. ADMIN_USER، وهو الشخص الذي ينشئ الموارد ويحذفها في ورشة العمل هذه. أما الشخص الثاني فهو MY_USER، وهو الذي ينفّذ الخطوات في ورشة العمل. يمكن لتطبيق "MY_USER" الوصول إلى موارده الخاصة فقط. يمكن للمشرف ADMIN_USER الوصول إلى جميع إعدادات المستخدمين. إذا كنت بصدد إنشاء هذا الإعداد لنفسك، سيكون ADMIN_USER وMY_USER متطابقَين. إذا كنت مدرّبًا تنشئ ورشة العمل هذه لعدة طلاب، سيكون ADMIN_USER وMY_USER مختلفَين.

يجب توفّر أذونات المؤسسة التالية لاستخدام ADMIN_USER:

• المالك: إذن "مالك المشروع" لجميع المشاريع في المؤسسة
• مشرف المجلد: إذن بإنشاء المجلدات وحذفها في المؤسسة يحصل كل مستخدم على مجلد واحد يحتوي على جميع الموارد داخل المشروع.
• مشرف المؤسسة
• منشئ المشروع: إذن بإنشاء مشاريع في المؤسسة
• حذف المشاريع: إمكانية حذف المشاريع في المؤسسة
• مشرف إدارة الهوية وإمكانية الوصول في المشروع: إمكانية إنشاء قواعد إدارة الهوية وإمكانية الوصول في جميع المشاريع في المؤسسة

بالإضافة إلى ذلك، يجب أن يكون ADMIN_USER أيضًا مشرف الفوترة لمعرّف الفوترة المستخدَم في ورشة العمل.

مخطط المستخدم والأذونات اللازمة لإجراء ورشة العمل

إذا كنت تخطّط لإنشاء ورشة العمل هذه للمستخدمين (غيرك) في مؤسستك، عليك اتّباع نظام تسمية مستخدمين محدّد لـ MY_USERs. أثناء تنفيذ النص البرمجي bootstrap_workshop.sh، عليك تقديم رقمَي مستخدمَين، أحدهما لبداية النطاق والآخر لنهايته. يتم استخدام هذه الأرقام لإنشاء أسماء المستخدمين التالية:

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

على سبيل المثال، إذا شغّلت نص ورشة العمل البرمجي الخاص بالتهيئة مع رقم المستخدم الأوّل 1 ورقم المستخدم الأخير 3، في مؤسستك التي تحمل الاسم yourcompany.com، سيتم إنشاء بيئات ورشة العمل للمستخدمين التاليين:

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

يتم منح أدوار "مالك المشروع" لهذه الأسماء لمشاريعهم المحدّدة التي تم إنشاؤها أثناء تنفيذ البرنامج النصي setup_terraform_admin_project.sh. يجب الالتزام بمخطط تسمية المستخدم هذا عند استخدام نص برمجي للتشغيل الأوّلي. يُرجى الرجوع إلى كيفية إضافة عدة مستخدمين في آنٍ واحد في G Suite.

الأدوات المطلوبة لورشة العمل

تهدف ورشة العمل هذه إلى الاستفادة من Cloud Shell. يجب توفير الأدوات التالية لورشة العمل هذه.

• gcloud (الإصدار >= 270)
• kubectl
• ‫sed (يعمل مع sed على Cloud Shell/Linux وليس على نظام التشغيل Mac)
• git (تأكَّد من أنّك تستخدم أحدث إصدار)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize

يتم تثبيت جميع الأدوات تلقائيًا في Cloud Shell باستثناء kustomize. إذا لم يتم تثبيت kustomize، ثبِّته باستخدام نص Bash البرمجي المتوفّر في الرابط أعلاه وتأكَّد من أنّ ملف kustomize الثنائي موجود في PATH، ثم أكِّد ذلك من خلال تنفيذ الأمر kustomize في Cloud Shell.

إعداد ورشة عمل لنفسك (إعداد مستخدم واحد)

1. افتح Cloud Shell، ونفِّذ جميع الإجراءات أدناه في Cloud Shell. انقر على الرابط أدناه.

CLOUD SHELL

2. تأكَّد من تسجيل الدخول إلى gcloud باستخدام حساب المشرف المطلوب.

gcloud config list
 

3. أنشئ WORKDIR واستنسِخ مستودع ورشة العمل.

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

4. حدِّد اسم مؤسستك ومعرّف الفوترة ورقم ورشة العمل وحزمة GCS للمشرف لاستخدامها في ورشة العمل. راجِع الأذونات المطلوبة لإعداد ورشة العمل في الأقسام أعلاه.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

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

export WORKSHOP_NUMBER=<two digit number for example 01>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

5. شغِّل النص البرمجي bootstrap_workshop.sh. قد يستغرق تنفيذ هذا النص البرمجي بضع دقائق.

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

يُرجى العِلم أنّه ليس عليك تحديد رقم المستخدم الأول والأخير لأنّك ستجري عملية الإعداد بنفسك.

بعد اكتمال النص البرمجي bootstrap_workshop.sh، يتم إنشاء مجلد على "منصة Google Cloud" لكل مستخدم داخل المؤسسة. يتم إنشاء مشروع مشرف Terraform داخل المجلد. يُستخدَم مشروع مشرف Terraform لإنشاء بقية موارد Google Cloud Platform المطلوبة في ورشة العمل هذه. فعِّل واجهات برمجة التطبيقات المطلوبة في مشروع مشرف Terraform. يمكنك استخدام Cloud Build لتطبيق خطط Terraform. عليك منح حساب خدمة Cloud Build أدوار IAM المناسبة ليتمكّن من إنشاء موارد على Google Cloud. أخيرًا، يمكنك إعداد خادم خلفي بعيد في حزمة Google Cloud Storage (GCS) لتخزين حالات Terraform لجميع موارد Google Cloud Platform.

للاطّلاع على مهام Cloud Build في مشروع مشرف Terraform، يجب أن يكون لديك رقم تعريف مشروع مشرف Terraform. يتم تخزين ذلك في الملف 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. انقر على الرابط أدناه.

CLOUD SHELL

8. تأكَّد من تسجيل الدخول إلى gcloud باستخدام حساب المشرف المطلوب.

gcloud config list
 

9. أنشئ WORKDIR واستنسِخ مستودع ورشة العمل.

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

10. حدِّد اسم مؤسستك ومعرّف الفوترة ورقم ورشة العمل ورقم المستخدمين الأوّلي والنهائي ومجموعة GCS إدارية لاستخدامها في ورشة العمل. راجِع الأذونات المطلوبة لإعداد ورشة العمل في الأقسام أعلاه.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

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

export WORKSHOP_NUMBER=<two digit number for example 01>

export START_USER_NUMBER=<number for example 1>

export END_USER_NUMBER=<number greater or equal to START_USER_NUM>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

11. شغِّل النص البرمجي bootstrap_workshop.sh. قد يستغرق تنفيذ هذا النص البرمجي بضع دقائق.

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

12. احصل على ملف 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 بالنقر على الرابط أدناه.

CLOUD SHELL

2. سجِّل الدخول باستخدام بيانات اعتماد حساب المختبر (لا تسجِّل الدخول باستخدام حساب شركتك أو حسابك الشخصي). يظهر حساب المختبر على النحو التالي: userXYZ@<workshop_domain>.com.
3. بما أنّ هذا حساب جديد، سيُطلب منك قبول بنود خدمة Google. انقر على "قبول".

4. في الشاشة التالية، ضَع علامة في مربّع الاختيار للموافقة على بنود خدمة Google، ثم انقر على Start Cloud Shell.

توفّر لك هذه الخطوة جهازًا افتراضيًا صغيرًا يعمل بنظام التشغيل Linux Debian يمكنك استخدامه للوصول إلى موارد Google Cloud Platform. يحصل كل حساب على آلة افتراضية في Cloud Shell. يوفّر تسجيل الدخول باستخدام حساب المختبر إمكانية تسجيل الدخول باستخدام بيانات اعتماد حساب المختبر. بالإضافة إلى Cloud Shell، يتم توفير "محرّر رموز" أيضًا لتسهيل تعديل ملفات الإعداد (مثل Terraform وYAML وما إلى ذلك). يتم تلقائيًا تقسيم شاشة Cloud Shell إلى بيئة shell في Cloud Shell (في أسفل الشاشة) ومحرِّر Cloud Code (في أعلى الشاشة). يتيح لك رمزا القلم ومطالبة الصدفة في أعلى يسار الصفحة التبديل بينهما (الصدفة وأداة تعديل الرموز). يمكنك أيضًا سحب شريط الفاصل الأوسط (للأعلى أو للأسفل) وتغيير حجم كل نافذة يدويًا. 5- أنشئ WORKDIR لورشة العمل هذه. WORKDIR هو مجلد تنفّذ منه جميع التمارين العملية في ورشة العمل هذه. نفِّذ الأوامر التالية في Cloud Shell لإنشاء WORKDIR.

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

6. صدِّر مستخدم حساب المختبر كمتغيّر لاستخدامه في ورشة العمل هذه. هذا هو الحساب نفسه الذي سجّلت الدخول إلى Cloud Shell باستخدامه.

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

ملاحظة: إذا كنت مشرفًا وأعددت ورشة العمل لنفسك باستخدام العلامتَين "-sufa" أو "–setup-for-admin"، اضبط MY_USER على عنوان البريد الإلكتروني لحساب Google Cloud Platform الذي استخدمته لإنشاء مشاريع ورشة العمل.

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. يجب توفير الأدوات التالية لورشة العمل هذه.

يتم تثبيت جميع الأدوات تلقائيًا في Cloud Shell باستثناء kustomize وpv. يمكنك الاطّلاع أدناه على تعليمات تثبيت كليهما.

• gcloud (الإصدار >= 270)
• kubectl
• ‫sed (يعمل مع sed على Cloud Shell/Linux وليس على نظام التشغيل Mac)
• git (تأكَّد من أنّك تستخدم أحدث إصدار)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize
• pv

الوصول إلى مشروع مشرف Terraform

بعد اكتمال النص البرمجي bootstrap_workshop.sh، يتم إنشاء مجلد على "منصة Google Cloud" لكل مستخدم داخل المؤسسة. يتم إنشاء مشروع مشرف Terraform داخل المجلد. يُستخدَم مشروع مشرف Terraform لإنشاء بقية موارد Google Cloud Platform المطلوبة في ورشة العمل هذه. يُفعِّل النص البرمجي setup-terraform-admin-project.sh واجهات برمجة التطبيقات المطلوبة في مشروع مشرف Terraform. يتم استخدام Cloud Build لتطبيق خطط Terraform. من خلال النص البرمجي، يمكنك منح حساب خدمة Cloud Build أدوار IAM المناسبة ليتمكّن من إنشاء موارد على Google Cloud Platform. أخيرًا، يتم إعداد خادم خلفي عن بُعد في حزمة Google Cloud Storage (GCS) لتخزين حالات Terraform لجميع موارد Google Cloud Platform.

للاطّلاع على مهام Cloud Build في مشروع مشرف Terraform، يجب أن يكون لديك رقم تعريف مشروع مشرف Terraform. يتم تخزين هذا الملف في حزمة GCS الخاصة بالمشرف والتي تم تحديدها في نص bootstrap البرمجي. إذا شغّلت نص bootstrap البرمجي لعدة مستخدمين، ستكون جميع أرقام تعريف مشاريع مشرف Terraform في حزمة GCS.

من المفترض أن يتم تنفيذ ورشة العمل هذه في Cloud Shell وCloud Console. اتّبِع الخطوات التالية في نافذة INCOGNITO لأنّك ستسجّل الدخول باستخدام اسم مستخدم وكلمة مرور منفصلَين.

1. افتح Cloud Shell (إذا لم يكن مفتوحًا من قسم "إعداد المعمل والتحضير") من خلال النقر على الرابط أدناه.

CLOUD SHELL

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. احصل على رقم تعريف مشروع مشرف Terraform من خلال تنفيذ الأمر التالي:

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

7. يتم تخزين جميع الموارد المرتبطة بورشة العمل كمتغيرات في ملف vars.sh مخزَّن في حزمة GCS في مشروع مشرف Terraform. احصل على ملف 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 مشاريع Google Cloud Platform في المؤسسة يكون حساب الفوترة المقدَّم مرتبطًا بكل مشروع.
• أحد المشاريع هو network host project لسحابة VPC المشتركة. لا يتم إنشاء أي موارد أخرى في هذا المشروع.
• أحد المشاريع هو ops project المستخدَم لمجموعات GKE في لوحة التحكّم في Istio.
• يمثّل المشروعان فريقَي تطوير مختلفَين يعملان على خدماتهما.
• يتم إنشاء مجموعتَي GKE في كل من المشاريع الثلاثة ops وdev1 وdev2.
• يتم إنشاء مستودع CSR باسم k8s-repo يحتوي على ستة مجلدات لملفات بيانات Kubernetes. مجلد واحد لكل مجموعة GKE يُستخدم هذا المستودع لنشر بيانات Kubernetes إلى المجموعات بطريقة GitOps.
• يتم إنشاء مشغّل Cloud Build لكي يتم نشر بيانات Kubernetes إلى مجموعات GKE من مجلداتها المعنية كلما تم إجراء عملية تثبيت في الفرع الرئيسي من k8s-repo.

يستغرق نص Terraform البرمجي من 40 إلى 50 دقيقة.

10. بعد اكتمال الإصدار في terraform admin project، سيبدأ إصدار آخر في مشروع العمليات. انقر على الرابط المعروض لفتح صفحة Cloud Build الخاصة بـ ops project وتأكَّد من اكتمال عملية إنشاء k8s-repo في Cloud Build بنجاح.

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

ملاحظة: يجب إكمال عملية الإنشاء هذه قبل أن تتمكّن من التحقّق من عملية تثبيت Istio.

التحقق من التثبيت

11. أنشئ ملفات kubeconfig لجميع المجموعات. نفِّذ النص البرمجي التالي.

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

ينشئ هذا النص البرمجي ملف kubeconfig جديدًا في المجلد gke باسم kubemesh.

12. غيِّر المتغيّر KUBECONFIG للإشارة إلى ملف kubeconfig الجديد.

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

13. أضِف vars.sh ومتغير KUBECONFIG إلى ملف .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 على كلا المجموعتَين من خلال التحقّق من أنّ جميع وحدات Pod قيد التشغيل وأنّ المهام قد اكتملت.

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. تتشارك هذه المجموعات في Istio controlplane الذي يعمل في المجموعة 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 كطريقة سرية. يتطلّب ذلك أن يكون لدى الإصدار التجريبي في مجموعات عمليات الوصول إلى خادم Kube API لجميع المجموعات الأخرى. إذا لم يتمكّن Pilot من الوصول إلى خوادم Kube API، عليك إضافة الخدمات البعيدة يدويًا كـ ServiceEntries. يمكنك اعتبار ServiceEntries كإدخالات نظام أسماء النطاقات في سجلّ الخدمات. تحدّد ServiceEntries خدمة باستخدام اسم نظام أسماء نطاقات مؤهَّل بالكامل ( FQDN) وعنوان IP يمكن الوصول إليه من خلاله. راجِع مستندات Istio Multicluster للحصول على مزيد من المعلومات.

6. شرح مستودع البنية التحتية

إنشاء البنية الأساسية السحابية

يتم إنشاء موارد Google Cloud Platform الخاصة بورشة العمل باستخدام Cloud Build وinfrastructure مستودع CSR. لقد نفّذت للتو نصًا برمجيًا للتشغيل الأوّلي (موجود في scripts/bootstrap_workshop.sh) من الجهاز الطرفي المحلي. ينشئ نص البرمجة التمهيدي مجلدًا على Google Cloud Platform ومشروعًا إداريًا لـ Terraform وأذونات مناسبة في "إدارة الهوية وإمكانية الوصول" لحساب خدمة Cloud Build. يُستخدم مشروع مشرف Terraform لتخزين حالات Terraform وسجلّاتها والنصوص البرمجية المتنوعة. يحتوي على مستودعات infrastructure وk8s_repo CSR. يتم شرح هذه المستودعات بالتفصيل في القسم التالي. لا يتم إنشاء أي موارد أخرى خاصة بورشة العمل في مشروع مشرف Terraform. يتم استخدام حساب خدمة Cloud Build في مشروع مشرف Terraform لإنشاء موارد لورشة العمل.

يتم استخدام ملف cloudbuild.yaml الموجود في المجلد infrastructure لإنشاء موارد GCP لورشة العمل. تنشئ هذه الأداة صورة أداة إنشاء مخصّصة تتضمّن جميع الأدوات المطلوبة لإنشاء موارد على Google Cloud Platform. تتضمّن هذه الأدوات gcloud SDK وTerraform وأدوات مساعدة أخرى، مثل Python وGit وjq وما إلى ذلك. وتنفّذ صورة أداة الإنشاء المخصّصة terraform plan وapply لكل مورد. تتوفّر ملفات Terraform لكل مرجع في مجلدات منفصلة (التفاصيل في القسم التالي). يتم إنشاء الموارد واحدة تلو الأخرى وبالترتيب الذي يتم إنشاؤها به عادةً (على سبيل المثال، يتم إنشاء مشروع على Google Cloud Platform قبل إنشاء الموارد في المشروع). يُرجى مراجعة ملف cloudbuild.yaml للحصول على مزيد من التفاصيل.

يتم تشغيل Cloud Build في أي وقت يتم فيه إجراء عملية إيداع في مستودع infrastructure. يتم تخزين أي تغيير يتم إجراؤه على البنية الأساسية على شكل بنية أساسية كرمز (IaC) ويتم إرساله إلى المستودع. يتم دائمًا تخزين حالة ورشة العمل في هذا المستودع.

بنية المجلدات - الفِرق والبيئات والموارد

يُعدّ مستودع البنية التحتية موارد البنية التحتية في Google Cloud Platform لورشة العمل. وهي منظَّمة في مجلدات ومجلدات فرعية. تمثّل المجلدات الأساسية داخل المستودع team التي تملك موارد GCP معيّنة. تمثّل الطبقة التالية من المجلدات environment المحدّدة للفريق (مثل dev وstage وprod). تمثّل الطبقة التالية من المجلدات داخل البيئة resource المحدّد (مثل host_project وgke_clusters وما إلى ذلك). تتوفّر النصوص البرمجية وملفات Terraform المطلوبة في مجلدات الموارد.

يتم تمثيل الأنواع الأربعة التالية من الفِرق في ورشة العمل هذه:

1. البنية التحتية: تمثّل فريق البنية التحتية للسحابة الإلكترونية. وهي مسؤولة عن إنشاء موارد GCP لجميع الفِرق الأخرى. يستخدمون مشروع مشرف Terraform لمواردهم. يقع مستودع البنية الأساسية نفسه في مشروع مشرف Terraform، بالإضافة إلى ملفات حالة Terraform (الموضّحة أدناه). يتم إنشاء هذه الموارد بواسطة نص برمجي bash أثناء عملية التشغيل الأوّلي (راجِع الوحدة 0 - سير عمل المشرف للحصول على التفاصيل).
2. network: تمثّل فريق الشبكات. وهي مسؤولة عن شبكة VPC وموارد الشبكات. لديهم موارد GCP التالية.
3. ‫host project: يمثّل مشروع مضيف شبكة VPC المشتركة.
4. shared VPC: تمثّل هذه السحابة VPC المشتركة والشبكات الفرعية ونطاقات عناوين IP الثانوية والمسارات وقواعد جدار الحماية.
5. ops: يمثّل فريق العمليات/DevOps. وهي تملك المراجع التالية.
6. ops project: يمثّل مشروعًا لجميع موارد العمليات.
7. ‫gke clusters: مجموعة GKE للعمليات في كل منطقة يتم تثبيت مسار التحكّم في Istio في كل مجموعات GKE الخاصة بالعمليات.
8. استبدِل k8s-repo بمستودع CSR يحتوي على بيانات GKE لجميع مجموعات GKE.
9. التطبيقات: تمثّل فِرق التطبيقات. تحاكي ورشة العمل هذه فريقَين، هما app1 وapp2. وهي تملك المراجع التالية.
10. app projects: يحصل كل فريق تطبيق على مجموعة المشاريع الخاصة به. يتيح لهم ذلك التحكّم في الفوترة وإدارة الهوية وإمكانية الوصول (IAM) لمشروعهم المحدّد.
11. gke clusters: هي مجموعات تطبيقات يتم فيها تشغيل حاويات التطبيقات/وحدات Pod.
12. gce instances: اختياري، إذا كان لديهم تطبيقات تعمل على مثيلات GCE. في ورشة العمل هذه، يحتوي app1 على مثيلَين من "محرك حساب Google" يتم فيهما تشغيل جزء من التطبيق.

في ورشة العمل هذه، يمثّل التطبيق نفسه (تطبيق Hipster shop) كلاً من app1 وapp2.

مقدّم الخدمة والحالات والنتائج - الخلفيات والحالات المشترَكة

يقع مقدّما الخدمة google وgoogle-beta في gcp/[environment]/gcp/provider.tf. يتم symlinked الملف provider.tf بشكل رمزي في كل مجلد موارد. يتيح لك ذلك تغيير مقدّم الخدمة في مكان واحد بدلاً من إدارة مقدّمي الخدمات بشكل فردي لكل مرجع.

يحتوي كل مورد على ملف backend.tf يحدّد الموقع الجغرافي لملف tfstate الخاص بالمورد. يتم إنشاء ملف backend.tf هذا من نموذج (موجود في templates/backend.tf_tmpl) باستخدام نص برمجي (موجود في scripts/setup_terraform_admin_project)، ثم يتم وضعه في مجلد الموارد المعني. تُستخدَم حِزم Google Cloud Storage ‏ (GCS) للخوادم الخلفية. يتطابق اسم مجلد مجموعة GCS مع اسم المورد. تتوفّر جميع الخلفيات الخاصة بالموارد في مشروع المشرف على Terraform.

تحتوي الموارد التي تتضمّن قيمًا مترابطة على ملف output.tf. يتم تخزين قيم الناتج المطلوبة في ملف tfstate المحدّد في الخلفية لهذا المورد المعيّن. على سبيل المثال، لإنشاء مجموعة 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، لأنّك تحتاج إلى رقم تعريف المشروع وتفاصيل السحابة الإلكترونية الخاصة الافتراضية (VPC) لإنشاء مجموعات GKE في مشروع العمليات. يتم إنشاء ملفات shared_state من نموذج (موجود في templates/shared_state.tf_tmpl) باستخدام نص برمجي (موجود في scripts/setup_terraform_admin_project). يتم وضع جميع ملفات shared_state الخاصة بالمراجع في المجلد gcp/[environment]/shared_states. يتم إنشاء روابط رمزية لملفات shared_state المطلوبة في مجلدات الموارد المعنية. يؤدي وضع جميع ملفات shared_state في مجلد واحد وربطها بشكل رمزي بمجلدات الموارد المناسبة إلى تسهيل إدارة جميع ملفات الحالة في مكان واحد.

المتغيّرات

يتم تخزين جميع قيم الموارد كمتغيرات بيئية. يتم تخزين هذه المتغيّرات (كعبارات تصدير) في ملف باسم vars.sh يقع في حزمة GCS في مشروع مشرف Terraform. يحتوي هذا الملف على رقم تعريف المؤسسة وحساب الفوترة وأرقام تعريف المشاريع وتفاصيل مجموعة GKE وما إلى ذلك. ويمكنك تنزيل vars.sh واستخدامه من أيّ وحدة طرفية للحصول على قيم الإعداد.

يتم تخزين متغيرات Terraform في vars.sh كـ TF_VAR_[variable name]. يتم استخدام هذه المتغيرات لإنشاء ملف variables.tfvars في مجلد الموارد المعنيّ. يحتوي ملف variables.tfvars على جميع المتغيرات مع قيمها. يتم إنشاء الملف variables.tfvars من ملف نموذج في المجلد نفسه باستخدام نص برمجي (موجود في scripts/setup_terraform_admin_project).

شرح مستودع K8s

‫k8s_repo هو مستودع CSR (منفصل عن مستودع البنية الأساسية) يقع في مشروع مشرف Terraform. يُستخدَم لتخزين بيانات GKE وتطبيقها على جميع مجموعات GKE. يتم إنشاء k8s_repo بواسطة البنية الأساسية لبرنامج Cloud Build (راجِع القسم السابق للحصول على التفاصيل). أثناء عملية إنشاء البنية الأساسية الأولية في Cloud Build، يتم إنشاء ما مجموعه ست مجموعات GKE. في k8s_repo، يتم إنشاء ستة مجلدات. يتوافق كل مجلد (اسم مطابق لاسم مجموعة GKE) مع مجموعة GKE تحتوي على ملفات بيان الموارد الخاصة بها. على غرار إنشاء البنية الأساسية، يتم استخدام Cloud Build لتطبيق بيانات Kubernetes على جميع مجموعات GKE باستخدام k8s_repo. يتم تشغيل Cloud Build في أي وقت يتم فيه إجراء عملية إيداع في مستودع k8s_repo. على غرار البنية الأساسية، يتم تخزين جميع بيانات Kubernetes كرموز في مستودع k8s_repo، ويتم دائمًا تخزين حالة كل مجموعة GKE في المجلد الخاص بها.

كجزء من عملية إنشاء البنية الأساسية الأولية، يتم إنشاء k8s_repo وتثبيت Istio على جميع المجموعات.

المشاريع ومجموعات GKE ومساحات الأسماء

يتم تقسيم الموارد في ورشة العمل هذه إلى مشاريع مختلفة على Google Cloud Platform. يجب أن تتطابق المشاريع مع البنية التنظيمية (أو بنية الفريق) لشركتك. تستخدم الفرق (في مؤسستك) المسؤولة عن المشاريع أو المنتجات أو الموارد المختلفة مشاريع مختلفة على Google Cloud Platform. يتيح لك استخدام مشاريع منفصلة إنشاء مجموعات منفصلة من أذونات "إدارة الهوية وإمكانية الوصول" وإدارة الفوترة على مستوى المشروع. بالإضافة إلى ذلك، تتم إدارة الحصص أيضًا على مستوى المشروع.

تمثّل هذه الورشة التدريبية خمسة فِرق، لكل منها مشروعها الخاص.

1. يستخدم فريق البنية الأساسية الذي ينشئ موارد Google Cloud Platform Terraform admin project. يديرون البنية الأساسية كتعليمات برمجية في مستودع CSR (يُسمى infrastructure) ويخزّنون جميع معلومات حالة Terraform المتعلقة بالموارد التي تم إنشاؤها في Google Cloud Platform في حِزم GCS. وهي تتحكّم في الوصول إلى مستودع CSR وحِزم GCS الخاصة بحالة Terraform.
2. يستخدم فريق الشبكة الذي ينشئ شبكة VPC مشتركة host project. يحتوي هذا المشروع على شبكة VPC والشبكات الفرعية والمسارات وقواعد جدار الحماية. يتيح لهم استخدام شبكة VPC مشترَكة إدارة الشبكات بشكل مركزي لموارد GCP. استخدمت جميع المشاريع سحابة VPC مشتركة واحدة للربط الشبكي.
3. يستخدم فريق العمليات/المنصة الذي ينشئ مجموعات GKE ومستويات التحكّم في ASM/Istio ops project. وهي تدير دورة حياة مجموعات GKE وشبكة الخدمات. وهم مسؤولون عن تعزيز أمان المجموعات وإدارة مرونة منصة Kubernetes وقابليتها للتوسّع. في ورشة العمل هذه، ستستخدم طريقة gitops لنشر الموارد على Kubernetes. يتوفّر مستودع CSR (يُسمى k8s_repo) في مشروع العمليات.
4. أخيرًا، فريقا التطوير 1 و2 (يمثّلان فريقَي تطوير) اللذان ينشئان التطبيقات يستخدمان dev1 وdev2 projects الخاصين بهما. هذه هي التطبيقات والخدمات التي تقدّمها لعملائك. ويتم إنشاء هذه الأدوات على النظام الأساسي الذي يديره فريق العمليات. يتم إرسال الموارد (عمليات النشر والخدمات وما إلى ذلك) إلى k8s_repo ونشرها في المجموعات المناسبة. يُرجى العِلم أنّ ورشة العمل هذه لا تركّز على أفضل الممارسات والأدوات المتعلّقة بالتكامل المستمر/التسليم المستمر. يمكنك استخدام Cloud Build لأتمتة عملية نشر موارد Kubernetes إلى مجموعات GKE مباشرةً. في سيناريوهات الإنتاج الواقعية، يمكنك استخدام حلّ مناسب للتكامل المستمر/التسليم المستمر (CI/CD) لنشر التطبيقات في مجموعات GKE.

هناك نوعان من مجموعات GKE في ورشة العمل هذه.

1. مجموعات العمليات: تستخدمها فِرق العمليات لتشغيل أدوات تطوير العمليات. في ورشة العمل هذه، يتم تشغيل خطة التحكّم في ASM/Istio لإدارة شبكة الخدمات.
2. مجموعات التطبيقات: تستخدمها فِرق التطوير لتشغيل التطبيقات. في ورشة العمل هذه، يتم استخدام تطبيق Hipster Shop.

يسمح لك فصل أدوات العمليات/المشرف عن المجموعات التي تشغّل التطبيق بإدارة دورة حياة كل مورد بشكل مستقل. يتوفّر نوعا المجموعات أيضًا في مشاريع مختلفة ذات صلة بالفريق أو المنتج الذي يستخدمها، ما يسهّل أيضًا إدارة أذونات إدارة الهوية وإمكانية الوصول.

هناك ما مجموعه ست مجموعات GKE. يتم إنشاء مجموعتَين إقليميتَين في مشروع العمليات. يتم تثبيت خطة تحكّم ASM/Istio على كلتا مجموعتَي الخوادم المخصّصة للعمليات. يقع كلّ مجموعة عنقودية للعمليات في منطقة مختلفة. بالإضافة إلى ذلك، هناك أربع مجموعات من التطبيقات على مستوى المنطقة. ويتم إنشاؤها في مشاريعهم الخاصة. تحاكي ورشة العمل هذه فريقَي تطوير لكل منهما مشاريعه الخاصة. يحتوي كل مشروع على مجموعتَين من التطبيقات. مجموعات التطبيقات هي مجموعات مناطقية في مناطق مختلفة. تقع مجموعات التطبيقات الأربع في منطقتَين وأربع مناطق. بهذه الطريقة، يمكنك الحصول على التكرار على مستوى المنطقة والمنطقة الجغرافية.

تم نشر التطبيق المستخدَم في ورشة العمل هذه، وهو تطبيق Hipster Shop، على جميع مجموعات التطبيقات الأربع. يعمل كلّ خدمة مصغّرة في مساحة الاسم الخاصة به في كل مجموعة من مجموعات التطبيقات. لا يتم نشر عمليات نشر تطبيق Hipster Shop (الحاويات) على مجموعات عمليات التشغيل. ومع ذلك، يتم أيضًا إنشاء مساحات الأسماء وموارد الخدمة لجميع الخدمات المصغّرة في مجموعات عمليات التشغيل. يستخدم مستوى التحكّم في ASM/Istio سجلّات خدمات Kubernetes لاكتشاف الخدمات. في حال عدم توفّر الخدمات (في مجموعات العمليات)، عليك إنشاء ServiceEntries يدويًا لكل خدمة تعمل في مجموعة التطبيقات.

في ورشة العمل هذه، ستنفّذ تطبيقًا للخدمات المصغّرة يتضمّن 10 مستويات. التطبيق هو تطبيق للتجارة الإلكترونية على الويب يُسمّى " Hipster Shop"، ويمكن للمستخدمين من خلاله تصفُّح السلع وإضافتها إلى سلة التسوّق وشرائها.

ملفات بيانات Kubernetes وk8s_repo

يمكنك استخدام k8s_repo لإضافة موارد Kubernetes إلى جميع مجموعات GKE. يمكنك إجراء ذلك من خلال نسخ بيانات Kubernetes ولصقها في k8s_repo. تؤدي جميع عمليات الإيداع في k8s_repo إلى تشغيل مهمة Cloud Build تنشر بيانات Kubernetes إلى المجموعة المعنية. يتم تخزين بيان كل مجموعة في مجلد منفصل يحمل الاسم نفسه.

أسماء المجموعات الست هي:

1. gke-asm-1-r1-prod: مجموعة العمليات الإقليمية في المنطقة 1
2. gke-asm-2-r2-prod: مجموعة العمليات الإقليمية في المنطقة 2
3. ‫gke-1-apps-r1a-prod: مجموعة التطبيقات في المنطقة 1، النطاق أ
4. ‫gke-2-apps-r1b-prod: مجموعة التطبيقات في المنطقة 1، النطاق الفرعي b
5. ‫gke-3-apps-r2a-prod: مجموعة التطبيقات في المنطقة 2، القسم أ
6. ‫gke-4-apps-r2b-prod: مجموعة التطبيقات في المنطقة 2، النطاق الفرعي b

يحتوي k8s_repo على مجلدات تتوافق مع هذه المجموعات. يتم تطبيق أي بيان موضوع في هذه المجلدات على مجموعة GKE المقابلة. يتم وضع بيانات كل مجموعة في مجلدات فرعية (داخل المجلد الرئيسي للمجموعة) لتسهيل الإدارة. في ورشة العمل هذه، ستستخدم Kustomize لتتبُّع الموارد التي يتم نشرها. يُرجى الرجوع إلى مستندات Kustomize الرسمية للحصول على مزيد من التفاصيل.

7. نشر نموذج التطبيق

الهدف: نشر تطبيق Hipster shop على مجموعات التطبيقات

• نسخة طبق الأصل عن "k8s-repo"
• نسخ بيانات Hipster shop إلى جميع مجموعات التطبيقات
• إنشاء خدمات لتطبيق Hipster shop في مجموعات عمليات
• إعداد loadgenerators في مجموعات عمليات الاختبار لاختبار الاتصال العالمي
• التحقّق من إمكانية الاتصال بشكل آمن بتطبيق Hipster shop

نص الأغنية السريعة

إذا اخترت هذه الطريقة، شغِّل البرنامج النصي التالي لإكمال هذا الدرس التطبيقي.

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

تعليمات التمرين المعملي حول طريقة النسخ واللصق

إذا سبق لك إكمال نص المسار السريع لهذا المختبر، لا تنفِّذ طريقة النسخ واللصق أدناه**.**

استنساخ مستودع المصدر لمشروع العمليات

كجزء من عملية إنشاء البنية الأساسية الأولية في Terraform، يتم إنشاء k8s-repo في مشروع العمليات.

1. أنشئ دليلاً فارغًا لمستودع git:

mkdir $WORKDIR/k8s-repo
 

2. ابدأ مستودع git وأضِف مستودعًا بعيدًا واسحب النسخة الرئيسية من المستودع البعيد:

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

3. ضبط إعدادات git المحلية

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

نسخ ملفات البيان وتنفيذ عملية الإيداع والدفع

4. انسخ مساحات الأسماء والخدمات في Hipster Shop إلى مستودع المصدر لجميع المجموعات.

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

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

5. انسخ ملف kustomization.yaml الخاص بمجلد التطبيق إلى جميع المجموعات.

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

6. انسخ عمليات نشر Hipster Shop وRBAC وPodSecurityPolicy إلى مستودع المصدر لمجموعات التطبيقات.

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

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

7. أزِل عملية نشر cartservice وrbac وpodsecuritypolicy من جميع مجموعات التطوير باستثناء مجموعة واحدة. لم يتم تصميم Hipstershop ليتم نشره في عدة مجموعات، لذا لتجنُّب النتائج غير المتسقة، نستخدم خدمة عربة تسوّق واحدة فقط.

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 clusters 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 وVirtualService إلى مستودع المصدر لمجموعات العمليات.

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

12. انسخ موارد Config Connector إلى أحد المجموعات في كل مشروع.

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

13. استبدِل PROJECT_ID في بيانات Config Connector.

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

14. انسخ بيانات loadgenerator (عملية النشر وPodSecurityPolicy وRBAC) إلى مجموعات عمليات التشغيل. يتم عرض تطبيق متجر Hipster باستخدام موازن تحميل عالمية من Google Cloud (GCLB). تتلقّى موازنة التحميل العالمية من Google زيارات العملاء (المتّجهة إلى frontend) وترسلها إلى أقرب مثيل من الخدمة. سيضمن وضع loadgenerator على مجموعتَي عمليات التشغيل إرسال عدد الزيارات إلى بوابتَي Istio Ingress اللتين تعملان في مجموعتَي عمليات التشغيل. يتم شرح موازنة التحميل بالتفصيل في القسم التالي.

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

15. استبدِل رقم تعريف مشروع العمليات في بيانات loadgenerator لكلتا مجموعتَي العمليات.

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

16. أضِف موارد loadgenerator إلى ملف kustomization.yaml لكلتا مجموعتَي العمل.

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

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

17. الالتزام بـ k8s-repo

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

18. يمكنك الاطّلاع على حالة مشروع Ops Cloud Build في علامة تبويب تم فتحها سابقًا أو من خلال النقر على الرابط التالي:

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

التحقّق من نشر التطبيق

19. تأكَّد من أنّ وحدات Pod في جميع مساحات أسماء التطبيقات باستثناء سلة التسوّق في حالة "قيد التشغيل" في جميع مجموعات التطوير.

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. تأكَّد من أنّ وحدات Pod في مساحة اسم سلة التسوّق في حالة "قيد التشغيل" في مجموعة التطوير الأولى فقط.

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 في جميع مجموعات التطبيقات الأربع. تتوفّر هذه المجموعات في منطقتَين وأربع مناطق. يمكن للعملاء الوصول إلى تطبيق متجر Hipster من خلال الوصول إلى خدمة frontend. تعمل خدمة frontend على جميع مجموعات التطبيقات الأربع. يتم استخدام موازن حمل Google Cloud ( GCLB) لتوجيه عدد الزيارات من العملاء إلى جميع مثيلات خدمة frontend الأربعة.

لا يتم تشغيل بوابات Istio Ingress إلا في مجموعات العمليات، وتعمل كأداة إقليمية لموازنة الحمل في مجموعتَي التطبيقات على مستوى المنطقة ضمن المنطقة. تستخدم موازنة التحميل العالمية من Google بوابتَي Istio الواردتَين (اللتان تعملان في مجموعتَي العمليات) كـ خوادم خلفية لخدمة الواجهة الأمامية العالمية. تتلقّى بوابات Istio Ingress زيارات العملاء من موازن التحميل العام من Google (GCLB)، ثم تُرسِل زيارات العملاء إلى وحدات Pod للواجهة الأمامية التي تعمل في مجموعات التطبيقات.

بدلاً من ذلك، يمكنك وضع بوابات Istio Ingress على مجموعات التطبيقات مباشرةً، ويمكن أن تستخدم موازنة التحميل العامة من Google هذه البوابات كخوادم خلفية.

GKE Autoneg controller

تسجّل خدمة Kubernetes لبوابة Istio Ingress نفسها كخادم خلفي في موازنة التحميل العامة من Google باستخدام مجموعات نقاط نهاية الشبكة (NEGs). تتيح مجموعات نقاط النهاية ميزة موازنة الحمل في الحاويات باستخدام موازنات الحمل العالمية (GCLB). يتم إنشاء مجموعات نقاط النهاية على الشبكة من خلال تعليق توضيحي خاص على إحدى خدمات Kubernetes، ما يتيح لها تسجيل نفسها في وحدة التحكّم في مجموعات نقاط النهاية على الشبكة. وحدة التحكّم Autoneg هي وحدة تحكّم خاصة في GKE تعمل على أتمتة عملية إنشاء مجموعات NEG بالإضافة إلى تعيينها كخلفيات إلى موازنة تحميل GCLB باستخدام تعليقات توضيحية للخدمة. يتم نشر لوحات التحكّم في Istio، بما في ذلك بوابات الدخول في Istio، أثناء عملية إنشاء البنية الأساسية الأولية في Terraform Cloud. يتم إعداد موازنة التحميل العامة من Google وautoneg كجزء من البنية الأساسية الأولية لـ Terraform Cloud Build.

تأمين Ingress باستخدام نقاط النهاية في السحابة الإلكترونية والشهادات المُدارة

يتم استخدام شهادات GCP المُدارة لتأمين زيارات العملاء إلى خدمة frontend GCLB. تستخدم موازنة التحميل العالمية (GCLB) شهادات مُدارة لخدمة frontend العالمية، ويتم إنهاء الشهادة في موازنة التحميل العالمية. في ورشة العمل هذه، ستستخدم Cloud Endpoints كنطاق للشهادة المُدارة. بدلاً من ذلك، يمكنك استخدام نطاقك واسم نظام أسماء النطاقات الخاص بـ frontend لإنشاء شهادات مُدارة من GCP.

21. للوصول إلى متجر Hipster، انقر على رابط الناتج من الأمر التالي.

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

22. يمكنك التأكّد من أنّ الشهادة صالحة من خلال النقر على رمز القفل في شريط عناوين علامة تبويب Chrome.

التحقّق من موازنة الحمل على مستوى العالم

كجزء من عملية نشر التطبيق، تم نشر مولّدات التحميل في كلتا مجموعتَي العمليات اللتين تنشئان زيارات اختبارية إلى رابط GCLB Hipster shop نقاط النهاية في السحابة الإلكترونية. تأكَّد من أنّ GCLB يتلقّى عددًا كبيرًا من الزيارات ويرسلها إلى بوابتَي Istio Ingress.

23. احصل على الرابط GCLB > المراقبة لمشروع العمليات الذي تم فيه إنشاء موازن تحميل Google السحابي (GCLB) الخاص بمتجر Hipster.

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 واحدة لكل منطقة في الإقليم. ومع ذلك، يتم تشغيل istio-ingressgateway Pods في منطقة واحدة لكل منطقة. يتم عرض عدد الزيارات المتّجهة إلى istio-ingressgateway Pods.

يتم تشغيل مولّدات التحميل في مجموعتَي العمليات اللتين تحاكيان زيارات العملاء من المنطقتَين اللتين تقعان فيهما. يتم إرسال الحمل الذي تم إنشاؤه في المنطقة 1 من مجموعة عمليات التشغيل إلى istio-ingressgateway في المنطقة 2. وبالمثل، يتم إرسال الحمل الذي تم إنشاؤه في منطقة المجموعة 2 إلى istio-ingressgateway في المنطقة 2.

8. إمكانية تتبُّع البيانات باستخدام Stackdriver

الهدف: ربط بيانات قياس استخدام Istio بخدمة Stackdriver والتحقّق من صحتها.

• تثبيت مراجع istio-telemetry
• إنشاء/تعديل لوحات بيانات خدمات Istio
• عرض سجلّات الحاويات
• عرض التتبُّع الموزّع في Stackdriver

نص الأغنية السريعة

إذا اخترت هذه الطريقة، شغِّل البرنامج النصي التالي لإكمال هذا الدرس التطبيقي.

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

تعليمات التمرين المعملي حول طريقة النسخ واللصق

إذا سبق لك إكمال نص المسار السريع لهذا المختبر، لا تنفِّذ طريقة النسخ واللصق أدناه**.**

إحدى الميزات الرئيسية في Istio هي إمكانية المراقبة المضمّنة (المعروفة باسم "o11y"). وهذا يعني أنّه حتى مع الحاويات غير المزوّدة بأدوات القياس، سيظل بإمكان المشغّلين مراقبة عدد الزيارات الواردة إلى هذه الحاويات والصادرة منها، وتقديم الخدمات للعملاء. تتخذ هذه الملاحظة شكل بضع طرق مختلفة: المقاييس والسجلات وعمليات التتبُّع.

سنستخدم أيضًا نظام إنشاء التحميل المضمّن في Hipster Shop. لا تعمل إمكانية المراقبة بشكل جيد في نظام ثابت لا يتضمّن زيارات، لذا يساعدنا إنشاء الحمل على معرفة طريقة عملها. هذا التحميل قيد التنفيذ حاليًا، وسنتمكّن الآن من رؤيته.

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 Cloud Build في علامة تبويب تم فتحها سابقًا أو من خلال النقر على الرابط التالي:

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

4. التحقّق من عملية الدمج بين Istio وStackdriver احصل على تعريف الموارد المخصّصة (CRD) الخاص بمعالج 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"
 

سيُطلب منك إنشاء مساحة عمل جديدة تحمل اسم مشروع العمليات، ما عليك سوى اختيار "حسنًا". إذا ظهرت لك رسالة حول واجهة المستخدم الجديدة، ما عليك سوى إغلاق مربّع الحوار.

في "مستكشف المقاييس"، ضمن "البحث عن نوع المورد والمقياس"، اكتب "istio" للاطّلاع على خيارات مثل "عدد طلبات الخادم" في نوع المورد "حاوية Kubernetes". يوضّح لنا ذلك أنّ المقاييس تنتقل من الشبكة إلى Stackdriver.

(عليك تجميع البيانات حسب تصنيف destination_service_name إذا أردت الاطّلاع على الأسطر أدناه).

تصوّر المقاييس باستخدام لوحات البيانات:

بعد أن أصبحت مقاييسنا في نظام Stackdriver APM، نريد طريقة لعرضها بشكل مرئي. في هذا القسم، سنثبّت لوحة بيانات مُعدّة مسبقًا تعرض لنا ثلاثة من أربعة مقاييس الإشارات الذهبية: عدد الزيارات (الطلبات في الثانية)، ووقت الاستجابة (في هذه الحالة، الشريحة المئوية الـ 99 والشريحة المئوية الـ 50)، والأخطاء (نستثني الاستخدام في هذا المثال).

يوفّر وكيل Envoy من Istio العديد من المقاييس، ولكن هذه المقاييس هي مجموعة جيدة للبدء. (يمكنك الاطّلاع على القائمة الشاملة هنا). يُرجى العِلم أنّ كل مقياس يتضمّن مجموعة من التصنيفات التي يمكن استخدامها للفلترة والتجميع، مثل: destination_service وsource_workload_namespace وresponse_code وistio_tcp_received_bytes_total وما إلى ذلك).

6. لنضِف الآن لوحة بيانات المقاييس الجاهزة. سنستخدم Dashboard API مباشرةً. هذا الإجراء لا يتم عادةً من خلال إنشاء طلبات إلى واجهة برمجة التطبيقات يدويًا، بل يكون جزءًا من نظام التشغيل الآلي، أو يمكنك إنشاء لوحة البيانات يدويًا في واجهة مستخدم الويب. سيساعدنا ذلك في البدء بسرعة:

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

7. انتقِل إلى رابط الإخراج أدناه لعرض "لوحة بيانات الخدمات" المُضافة حديثًا.

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

يمكننا تعديل لوحة البيانات في مكانها باستخدام تجربة المستخدم، ولكن في حالتنا، سنضيف بسرعة رسمًا بيانيًا جديدًا باستخدام واجهة برمجة التطبيقات. لإجراء ذلك، عليك سحب أحدث إصدار من لوحة البيانات، وتطبيق التعديلات، ثم إعادة تحميله باستخدام طريقة HTTP PATCH.

8. يمكنك الحصول على لوحة بيانات حالية من خلال طلب البحث في واجهة برمجة التطبيقات الخاصة بالمراقبة. الحصول على لوحة البيانات الحالية التي تمت إضافتها للتو:

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

9. إضافة رسم بياني جديد: (وقت الاستجابة عند النسبة المئوية الخمسين): [ مرجع واجهة برمجة التطبيقات] يمكننا الآن إضافة أداة رسم بياني جديدة إلى لوحة التحكّم في الرمز البرمجي. يمكن أن يراجع الزملاء هذا التغيير ويتم التحقّق منه في نظام التحكم في الإصدارات. في ما يلي تطبيق مصغّر لإضافة عرض لوقت الاستجابة عند النسبة المئوية 50 (متوسط وقت الاستجابة).

جرِّب تعديل لوحة البيانات التي حصلت عليها للتو، وأضِف مقطعًا جديدًا:

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

10. تعديل لوحة بيانات الخدمات الحالية:

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

11. يمكنك الاطّلاع على لوحة البيانات المعدَّلة من خلال الانتقال إلى رابط الإخراج التالي:

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

12. إجراء بعض التحليل البسيط للسجلات

توفّر Istio مجموعة من السجلات المنظَّمة لجميع حركة بيانات الشبكة داخل الشبكة المتداخلة، وتحمّلها إلى Stackdriver Logging للسماح بإجراء التحليل على مستوى المجموعات في أداة واحدة فعّالة. يتم إرفاق السجلات ببيانات وصفية على مستوى الخدمة، مثل المجموعة والحاوية والتطبيق وconnection_id وما إلى ذلك.

قد يبدو إدخال في السجلّ النموذجي (في هذه الحالة، accesslog لخادم وكيل Envoy) على النحو التالي (تم اقتطاعه):

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

يمكنك الاطّلاع على سجلّاتك هنا:

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

يمكنك عرض سجلّات لوحة التحكّم في Istio من خلال اختيار "المورد" > "حاوية Kubernetes"، والبحث عن "pilot" —

يمكننا هنا أن نرى Istio Control Plane يرسل إعدادات الخادم الوكيل إلى الخوادم الوكيلة المساعدة لكل خدمة من خدمات التطبيق النموذجي. تمثّل "CDS" و"LDS" و "RDS" واجهات برمجة تطبيقات مختلفة في Envoy ( مزيد من المعلومات).

بالإضافة إلى سجلّات Istio، يمكنك أيضًا العثور على سجلّات الحاويات وسجلّات البنية الأساسية أو خدمات Google Cloud Platform الأخرى في الواجهة نفسها. في ما يلي بعض نماذج طلبات البحث في السجلات الخاصة بـ GKE. تتيح لك واجهة عرض السجلّات أيضًا إنشاء مقاييس من السجلات (مثل "احتساب كل خطأ يطابق سلسلة معيّنة") يمكن استخدامها في لوحة بيانات أو كجزء من تنبيه. يمكن أيضًا نقل السجلّات إلى أدوات تحليل أخرى، مثل BigQuery.

في ما يلي بعض الأمثلة على فلاتر متجر الهيبستر:

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

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

13. اطّلِع على "عمليات التتبُّع الموزّعة".

الآن بعد أن أصبحت تعمل مع نظام موزّع، تحتاج عملية تصحيح الأخطاء إلى أداة جديدة، وهي التتبُّع الموزّع. تتيح لك هذه الأداة اكتشاف إحصاءات حول كيفية تفاعل خدماتك (مثل العثور على أحداث بطيئة بعيدة عن النطاق في الصورة أدناه)، بالإضافة إلى التوغّل في عمليات تتبُّع العيّنات الأولية للتحقّق من تفاصيل ما يحدث فعلاً.

تعرض "طريقة العرض على المخطط الزمني" جميع الطلبات بمرور الوقت، ويتم تمثيلها بيانيًا حسب وقت الاستجابة أو الوقت المستغرَق بين الطلب الأوّلي، من خلال حزمة Hipster، إلى أن يتم الردّ أخيرًا على المستخدم النهائي. كلما ارتفعت النقاط، كانت تجربة المستخدم أبطأ (وأقل إرضاءً).

يمكنك النقر على نقطة للعثور على "عرض Waterfall" المفصّل لهذا الطلب المحدّد. تُعدّ القدرة على العثور على التفاصيل الأولية لطلب معيّن (وليس الإحصاءات المجمّعة فقط) أمرًا ضروريًا لفهم التفاعل بين الخدمات، لا سيما عند البحث عن تفاعلات نادرة ولكنها سيئة بين الخدمات.

يجب أن يكون "عرض التسلسل الهرمي" مألوفًا لأي شخص استخدم برنامج تصحيح الأخطاء، ولكن في هذه الحالة، بدلاً من عرض الوقت المستغرَق في العمليات المختلفة لتطبيق واحد، يعرض هذا الوقت المستغرَق في اجتياز شبكتنا المتداخلة، بين الخدمات، التي تعمل في حاويات منفصلة.

يمكنك العثور على عمليات التتبُّع هنا:

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

في ما يلي مثال على لقطة شاشة للأداة:

9- مصادقة TLS المتبادلة

الهدف: توفير اتصال آمن بين الخدمات المصغّرة (المصادقة).

• تفعيل ميزة mTLS على مستوى الشبكة
• التحقّق من أمان النقل المتبادل (mTLS) من خلال فحص السجلّات

نص الأغنية السريعة

إذا اخترت هذه الطريقة، شغِّل البرنامج النصي التالي لإكمال هذا الدرس التطبيقي.

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

تعليمات التمرين المعملي حول طريقة النسخ واللصق

إذا سبق لك إكمال نص المسار السريع لهذا المختبر، لا تنفِّذ طريقة النسخ واللصق أدناه**.**

بعد تثبيت تطبيقاتنا وإعداد ميزة "قابلية المراقبة"، يمكننا البدء في تأمين الاتصالات بين الخدمات والتأكّد من استمرار عملها.

على سبيل المثال، يمكننا أن نرى في لوحة بيانات Kiali أنّ خدماتنا لا تستخدم MTLS (لا يظهر رمز "القفل"). ولكن حركة المرور تسير بشكل طبيعي والنظام يعمل بشكل جيد. تمنحنا لوحة بيانات "المقاييس الذهبية" في StackDriver بعض الراحة لأنّها تشير إلى أنّ كل شيء يعمل بشكل عام.

1. تحقَّق من MeshPolicy في مجموعات عمليات. ملاحظة: 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). سنضبط بروتوكول mTLS في جميع المجموعات العنقودية من خلال تعديل IstioControlPlane CR وتعديل k8s-repo. يؤدي ضبط global > mTLS > enabled: true في IstioControlPlane CR إلى إجراء التغييرَين التاليَين على لوحة التحكّم في Istio:

• تم ضبط MeshPolicy لتفعيل شبكة mTLS على مستوى جميع الخدمات التي تعمل في جميع المجموعات.
• يتم إنشاء DestinationRule للسماح بحركة بيانات ISTIO_MUTUAL بين الخدمات التي تعمل في جميع المجموعات.

2. سنطبّق تصحيح kustomize على istioControlPlane CR لتفعيل mTLS على مستوى المجموعة. انسخ التصحيح إلى الدليل ذي الصلة لجميع المجموعات وأضِف تصحيح kustomize.

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

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

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

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

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

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

3. إجراء عملية الإيداع في k8s-repo

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

4. يمكنك الاطّلاع على حالة مشروع Ops Cloud Build في علامة تبويب تم فتحها سابقًا أو من خلال النقر على الرابط التالي:

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

 

التحقّق من صحة mTLS

5. تحقَّق من MeshPolicy مرة أخرى في مجموعات العمليات. يُرجى العِلم أنّ ميزة mTLS لم تعُد PERMISSIVE، ولن تسمح إلا بزيارات mTLS.

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

الناتج (لا تنسخ):

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

6. توضّح هذه السمة وصف 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 في السجلات.

يمكننا عرض هذا الحقل المحدّد من السجلات في واجهة المستخدم من خلال النقر على إدخال في السجلّ ثم النقر على قيمة الحقل الذي تريد عرضه، وفي حالتنا هذه، انقر على "http" بجانب "protocol:"

ويؤدي ذلك إلى طريقة رائعة لتصوّر عملية التبديل:

10. عمليات نشر Canary

الهدف: طرح إصدار جديد من خدمة الواجهة الأمامية.

• طرح الإصدار frontend-v2 (إصدار الإنتاج التالي) للخدمة في منطقة واحدة
• استخدِم DestinationRules وVirtualServices لتوجيه الزيارات ببطء إلى frontend-v2
• تحقَّق من مسار نشر GitOps من خلال فحص سلسلة من عمليات الإيداع في k8s-repo

نص الأغنية السريعة

إذا اخترت هذه الطريقة، شغِّل البرنامج النصي التالي لإكمال هذا الدرس التطبيقي.

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

تعليمات التمرين المعملي حول طريقة النسخ واللصق

إذا سبق لك إكمال نص المسار السريع لهذا المختبر، لا تنفِّذ طريقة النسخ واللصق أدناه**.**

عملية نشر Canary هي طرح تدريجي لخدمة جديدة. في عملية نشر الإصدار التجريبي، يتم إرسال كمية متزايدة من الزيارات إلى الإصدار الجديد، مع الاستمرار في إرسال النسبة المتبقية إلى الإصدار الحالي. يتم عادةً إجراء تحليل Canary في كل مرحلة من مراحل تقسيم عدد الزيارات، ومقارنة "الإشارات الذهبية" للإصدار الجديد (وقت الاستجابة ومعدّل الخطأ والتشبّع) بالأساس. يساعد ذلك في منع الانقطاعات وضمان استقرار الخدمة الجديدة "الإصدار 2" في كل مرحلة من مراحل تقسيم عدد الزيارات.

في هذا القسم، ستتعرّف على كيفية استخدام Cloud Build وسياسات نقل البيانات في Istio لإنشاء عملية نشر تجريبية أساسية لإصدار جديد من خدمة الواجهة الأمامية.

أولاً، سننفّذ مسار Canary في المنطقة DEV1 (us-west1)، وسنطرح الإصدار 2 من الواجهة الأمامية على كلا المجموعتين في تلك المنطقة. ثانيًا، سنشغّل مسار Canary في المنطقة DEV2 (us-central) ونوزّع الإصدار 2 على كلا المجموعتين في تلك المنطقة. يساعد تشغيل سلسلة المعالجة على المناطق بالتسلسل، بدلاً من تشغيلها بالتوازي في جميع المناطق، في تجنُّب الانقطاعات العالمية الناتجة عن الإعدادات غير الصحيحة أو الأخطاء في تطبيق الإصدار 2 نفسه.

ملاحظة: سنفعّل مسار Canary يدويًا في كلتا المنطقتين، ولكن في مرحلة الإنتاج، يمكنك استخدام مشغّل آلي، على سبيل المثال استنادًا إلى علامة صورة Docker جديدة يتم إرسالها إلى سجلّ.

1. من Cloud Shell، حدِّد بعض متغيرات البيئة لتسهيل تنفيذ بقية الأوامر.

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

2. شغِّل النص البرمجي repo_setup.sh لنسخ بيانات البيان الأساسية إلى k8s-repo.

$CANARY_DIR/repo-setup.sh 
 

يتم نسخ البيانات الوصفية التالية:

• نشر frontend-v2
• تصحيح frontend-v1 (لتضمين التصنيف "v1" وصورة تتضمّن نقطة نهاية "/version")
• respy: هي مجموعة صغيرة ستعرض توزيع استجابات HTTP، وستساعدنا في عرض عملية النشر التجريبي في الوقت الفعلي.
• DestinationRule في Istio للواجهة الأمامية: يقسّم خدمة Kubernetes للواجهة الأمامية إلى مجموعتين فرعيتين، الإصدار 1 والإصدار 2، استنادًا إلى تصنيف النشر "الإصدار"
• VirtualService في Istio للواجهة الأمامية: توجّه% 100 من عدد الزيارات إلى الإصدار 1 من الواجهة الأمامية. يؤدي ذلك إلى تجاهل السلوك التلقائي لخدمة Kubernetes الذي يعتمد على التوزيع بالتساوي، والذي سيؤدي على الفور إلى إرسال% 50 من جميع الزيارات الإقليمية إلى Dev1 إلى الإصدار الثاني من الواجهة الأمامية.

3. إرسال التغييرات إلى k8s_repo:

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

4. يمكنك الاطّلاع على حالة مشروع Ops Cloud Build في علامة تبويب تم فتحها سابقًا أو من خلال النقر على الرابط التالي:

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

5. انتقِل إلى Cloud Build في وحدة التحكّم الخاصة بمشروع 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 لتقسيم نافذة Cloud Shell إلى لوحتَين:

• ستعرض اللوحة السفلية أمر المراقبة لملاحظة توزيع استجابة HTTP لخدمة الواجهة الأمامية.
• سيتم تشغيل النص البرمجي الفعلي لعملية النشر التجريبي في الجزء العلوي.

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%            |
|          |                   |
+----------+-------------------+

يمكننا أن نرى أنّ كل الزيارات تتوجّه إلى عملية نشر الإصدار 1 من الواجهة الأمامية، كما هو محدّد في VirtualService الجديد.

7. نفِّذ مسار الإصدار التجريبي في منطقة Dev1. نوفّر نصًا برمجيًا يعدّل نسب عدد الزيارات إلى frontend-v2 في VirtualService (من خلال تعديل الأوزان إلى %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. انتقِل إلى Cloud Source Repos من خلال الرابط الذي تم إنشاؤه.

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

من المفترض أن يظهر لك تغيير منفصل لكل نسبة مئوية من عدد الزيارات، مع ظهور أحدث تغيير في أعلى القائمة:

الآن، عليك تكرار العملية نفسها لمنطقة Dev2. يُرجى العِلم أنّ منطقة Dev2 لا تزال "محظورة" على الإصدار 1. ويرجع ذلك إلى أنّه في نص repo_setup الأساسي، أرسلنا VirtualService لإرسال جميع الزيارات إلى الإصدار 1 بشكل صريح. بهذه الطريقة، تمكّنا من إجراء اختبار إطلاق محدود على مستوى منطقة معيّنة على الإصدار 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%            |
|          |                   |
+----------+-------------------+

يمكننا أن نرى أنّ كل الزيارات تتوجّه إلى عملية نشر الإصدار 1 من الواجهة الأمامية، كما هو محدّد في VirtualService الجديد.

13. نفِّذ مسار الإصدار التجريبي على منطقة Dev2. نوفّر نصًا برمجيًا يعدّل نسب عدد الزيارات إلى frontend-v2 في VirtualService (من خلال تعديل الأوزان إلى %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 وهي تنتقل تدريجيًا من الإصدار 1 إلى الإصدار 2 من الواجهة الأمامية. بعد اكتمال النص البرمجي، من المفترض أن يظهر لك ما يلي:

الناتج (لا تنسخ)

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 لعمليات نشر Canary الإقليمية. في مرحلة الإنتاج، بدلاً من استخدام نص برمجي يدوي، يمكنك تشغيل هذا النص البرمجي التجريبي تلقائيًا كمسار Cloud Build، وذلك باستخدام مشغّل مثل صورة جديدة موسومة يتم إرسالها إلى سجلّ حاويات. عليك أيضًا إضافة تحليل Canary بين كل خطوة، وتحليل وقت الاستجابة ومعدّل الخطأ في الإصدار 2 مقارنةً بحدّ أمان محدّد مسبقًا، قبل إرسال المزيد من الزيارات.

11. سياسات التفويض

الهدف: إعداد نظام التحكّم المستند إلى الأدوار (RBAC) بين الخدمات المصغّرة (AuthZ).

• إنشاء AuthorizationPolicy لرفض الوصول إلى خدمة مصغّرة
• إنشاء AuthorizationPolicy للسماح بالوصول إلى خدمة مصغّرة بشكل محدّد

نص الأغنية السريعة

إذا اخترت هذه الطريقة، شغِّل البرنامج النصي التالي لإكمال هذا الدرس التطبيقي.

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

تعليمات التمرين المعملي حول طريقة النسخ واللصق

إذا سبق لك إكمال نص المسار السريع لهذا المختبر، لا تنفِّذ طريقة النسخ واللصق أدناه**.**

على عكس التطبيقات ذات النمط الموحَّد التي قد يتم تشغيلها في مكان واحد، تجري تطبيقات الخدمات المصغّرة الموزَّعة على مستوى العالم عمليات استدعاء عبر حدود الشبكة. وهذا يعني توفّر المزيد من نقاط الدخول إلى تطبيقاتك، والمزيد من فرص شنّ هجمات ضارة. وبما أنّ وحدات Kubernetes لديها عناوين IP مؤقتة، لم تعُد قواعد جدار الحماية التقليدية المستندة إلى عناوين IP كافية لتأمين الوصول بين أحمال العمل. في بنية الخدمات الدقيقة، يجب اتّباع نهج جديد للأمان. استنادًا إلى وحدات إنشاء أمان Kubernetes، مثل حسابات الخدمة، يوفّر Istio مجموعة مرنة من سياسات الأمان لتطبيقاتك.

تغطي سياسات Istio كلاً من المصادقة والترخيص. تتحقّق المصادقة من الهوية (هل هذا الخادم هو من يدّعي أنّه هو؟)، بينما يتحقّق الترخيص من الأذونات (هل يُسمح لهذا العميل بتنفيذ هذا الإجراء؟). تحدّثنا عن مصادقة Istio في قسم "بروتوكول أمان طبقة النقل المتبادل" في الوحدة 1 (MeshPolicy). في هذا القسم، سنتعرّف على كيفية استخدام سياسات التفويض في Istio للتحكّم في الوصول إلى أحد أحمال عمل التطبيق، وهو currencyservice.

أولاً، سننشر AuthorizationPolicy على جميع مجموعات 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. انسخ سياسة العملة إلى k8s-repo، وذلك لمجموعات العمليات في كلتا المنطقتين.

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

3. إرسال التغييرات

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

4. تحقَّق من حالة مشروع Cloud Build في Ops في علامة تبويب تم فتحها سابقًا أو من خلال النقر على الرابط التالي:

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

5. بعد انتهاء عملية الإنشاء بنجاح، حاوِل الوصول إلى الواجهة الأمامية لموقع hipstershop في متصفّح على الرابط التالي:

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

من المفترض أن يظهر لك خطأ في التفويض من currencyservice:

6. لنستكشف كيف تفرض خدمة العملة سياسة AuthorizationPolicy هذه. أولاً، فعِّل سجلّات مستوى التتبُّع على خادم وكيل Envoy لأحد وحدات العملة، لأنّه لا يتم تسجيل طلبات التفويض المحظورة تلقائيًا.

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

7. احصل على سجلات التحكّم المستند إلى الأدوار (RBAC) (التفويض) من الخادم الوكيل المساعد لخدمة العملة. من المفترض أن تظهر لك الرسالة "تم الرفض الإجباري"، ما يشير إلى أنّ خدمة currencyservice مضبوطة على حظر جميع الطلبات الواردة.

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

الناتج (لا تنسخ)

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

8. الآن، لنسمح للواجهة الأمامية بالوصول إلى currencyservice، ولكن ليس لخدمات الخلفية الأخرى. افتح currency-allow-frontend.yaml وافحص محتواه. يُرجى العِلم أنّنا أضفنا القاعدة التالية:

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

الناتج (لا تنسخ)

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

في هذا المثال، نضيف source.principal (العميل) محدّدًا إلى القائمة البيضاء للوصول إلى خدمة العملة. يتم تحديد source.principal هذا من خلال حساب خدمة Kubernetes. في هذه الحالة، يكون حساب الخدمة الذي ندرجه في القائمة البيضاء هو حساب خدمة الواجهة الأمامية في مساحة اسم الواجهة الأمامية.

ملاحظة: عند استخدام حسابات خدمة Kubernetes في Istio AuthorizationPolicies، عليك أولاً تفعيل بروتوكول TLS الثنائي على مستوى المجموعة، كما فعلنا في الوحدة 1. يتم ذلك لضمان تضمين بيانات اعتماد حساب الخدمة في الطلبات.

9. نسخ سياسة العملة المعدَّلة

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

10. إرسال التغييرات

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

11. يمكنك الاطّلاع على حالة مشروع Ops Cloud Build في علامة تبويب تم فتحها سابقًا أو من خلال النقر على الرابط التالي:

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

12. بعد انتهاء عملية الإنشاء بنجاح، افتح واجهة Hipstershop الأمامية مرة أخرى. في هذه المرة، لن تظهر لك أي أخطاء في الصفحة الرئيسية، لأنّه يُسمح للواجهة الأمامية صراحةً بالوصول إلى الخدمة الحالية.
13. الآن، جرِّب إتمام عملية الدفع عن طريق إضافة سلع إلى سلة التسوّق والنقر على "تقديم الطلب". في هذه المرة، من المفترض أن يظهر لك خطأ في تحويل الأسعار من خدمة العملات، وذلك لأنّنا أدرجنا الواجهة الأمامية فقط في القائمة البيضاء، وبالتالي لا يزال بإمكان خدمة الدفع الوصول إلى خدمة العملات.

14. أخيرًا، لنمنح خدمة الدفع إذن الوصول إلى العملة من خلال إضافة قاعدة أخرى إلى AuthorizationPolicy الخاصة بخدمة currencyservice. يُرجى العِلم أنّنا سنمنح إذن الوصول إلى العملة لخدمتَين فقط تحتاجان إلى ذلك، وهما الواجهة الأمامية وعملية الدفع. وسيظلّ الوصول إلى الأنظمة الخلفية الأخرى محظورًا.
15. افتح currency-allow-frontend-checkout.yaml وافحص محتواه. يُرجى العِلم أنّ قائمة القواعد تعمل كعامل منطقي OR، ولن تقبل العملة سوى الطلبات من أحمال العمل التي تتضمّن أحد حسابَي الخدمة هذين.

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

الناتج (لا تنسخ)

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

16. انسخ سياسة التفويض النهائية إلى k8s-repo.

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

17. إرسال التغييرات

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

18. يمكنك الاطّلاع على حالة مشروع Ops Cloud Build في علامة تبويب تم فتحها سابقًا أو من خلال النقر على الرابط التالي:

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

19. بعد انتهاء عملية الإنشاء بنجاح، حاوِل تنفيذ عملية دفع، ومن المفترض أن تتم بنجاح.

تضمّن هذا القسم خطوات حول كيفية استخدام "سياسات التفويض" في Istio لفرض عناصر تحكّم دقيقة في الوصول على مستوى كل خدمة. في مرحلة الإنتاج، يمكنك إنشاء سياسة AuthorizationPolicy واحدة لكل خدمة، واستخدام سياسة السماح بالوصول إلى الكل (على سبيل المثال) للسماح لجميع أحمال العمل في مساحة الاسم نفسها بالوصول إلى بعضها البعض.

12. توسيع نطاق البنية التحتية

الهدف: توسيع نطاق البنية الأساسية من خلال إضافة منطقة ومشروع ومجموعات جديدة.

• استنساخ مستودع infrastructure
• تعديل ملفات Terraform لإنشاء موارد جديدة
• شبكتان فرعيتان في المنطقة الجديدة (واحدة لمشروع العمليات وواحدة للمشروع الجديد)
• مجموعة عمليات جديدة في منطقة جديدة (في الشبكة الفرعية الجديدة)
• طائرة تحكّم Istio جديدة للمنطقة الجديدة
• مجموعتان من التطبيقات في المشروع الجديد في المنطقة الجديدة
• تنفيذ التغييرات في مستودع infrastructure
• التحقق من التثبيت

نص الأغنية السريعة

إذا اخترت هذه الطريقة، شغِّل البرنامج النصي التالي لإكمال هذا الدرس التطبيقي.

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

تعليمات التمرين المعملي حول طريقة النسخ واللصق

إذا سبق لك إكمال نص المسار السريع لهذا المختبر، لا تنفِّذ طريقة النسخ واللصق أدناه**.**

هناك عدد من الطرق لتوسيع نطاق منصة. يمكنك إضافة المزيد من موارد الحوسبة عن طريق إضافة عُقد إلى المجموعات الحالية. يمكنك إضافة المزيد من المجموعات في منطقة معيّنة. أو يمكنك إضافة المزيد من المناطق إلى المنصة. يعتمد قرار تحديد الجانب الذي يجب توسيعه في المنصة على المتطلبات. على سبيل المثال، إذا كانت لديك مجموعات في جميع المناطق الثلاث في منطقة ما، قد يكون من الكافي إضافة المزيد من العُقد (أو مجموعات العُقد) إلى المجموعة الحالية. ومع ذلك، إذا كان لديك مجموعات في منطقتَين من ثلاث مناطق في منطقة واحدة، فإنّ إضافة مجموعة جديدة في المنطقة الثالثة يمنحك إمكانية التوسيع ونطاق خطأ إضافي (أي منطقة جديدة). قد يكون السبب الآخر لإضافة مجموعة جديدة في منطقة هو الحاجة إلى إنشاء مجموعة مستأجر واحد لأسباب تنظيمية أو متعلّقة بالامتثال (مثل معيار أمان بيانات صناعة بطاقات الدفع (PCI) أو مجموعة قواعد بيانات تتضمّن معلومات تكشف الهوية الشخصية). مع توسّع نشاطك التجاري وخدماتك، يصبح من الضروري إضافة مناطق جديدة لتقديم الخدمات بالقرب من العملاء.

تتألف المنصة الحالية من منطقتَين ومجموعات في نطاقَين لكل منطقة. يمكنك التفكير في توسيع نطاق المنصة بطريقتَين:

• عموديًا: ضمن كل منطقة من خلال إضافة المزيد من موارد الحوسبة ويتم ذلك إما عن طريق إضافة المزيد من العُقد (أو مجموعات العُقد) إلى المجموعات الحالية أو عن طريق إضافة مجموعات جديدة داخل المنطقة. يتم ذلك من خلال مستودع infrastructure. أبسط طريقة هي إضافة عُقد إلى المجموعات الحالية. ولن يُطلب منك ضبط أي إعدادات إضافية. قد تتطلّب إضافة مجموعات جديدة شبكات فرعية إضافية (ونطاقات ثانوية)، وإضافة قواعد جدار الحماية المناسبة، وإضافة المجموعات الجديدة إلى مستوى التحكّم في شبكة الخدمات الإقليمية ASM/Istio، ونشر موارد التطبيق إلى المجموعات الجديدة.
• أفقيًا: من خلال إضافة المزيد من المناطق توفّر لك المنصة الحالية نموذجًا إقليميًا. يتألف من مجموعة عمليات إقليمية حيث يتم تخزين ASM/Istio، ومجموعتَين (أو أكثر) من تطبيقات المناطق حيث يتم نشر موارد التطبيق.

في ورشة العمل هذه، يمكنك توسيع نطاق المنصة "أفقيًا" لأنّها تشمل خطوات حالة الاستخدام العمودية أيضًا. من أجل توسيع نطاق المنصة أفقيًا عن طريق إضافة منطقة جديدة (r3) إلى المنصة، يجب إضافة الموارد التالية:

1. الشبكات الفرعية في مشروع المضيف VPC المشترك في المنطقة r3 للمجموعات الجديدة من العمليات والتطبيقات
2. مجموعة عمليات إقليمية في المنطقة r3 حيث تتوفّر خطة تحكّم ASM/Istio.
3. مجموعتان من التطبيقات في منطقتَين على المنطقة r3
4. تعديل k8s-repo:
5. نشر موارد خطة تحكّم ASM/Istio إلى مجموعة العمليات في المنطقة r3
6. انشر موارد خطة التحكّم المشترَكة في ASM/Istio إلى مجموعات التطبيقات في المنطقة r3.
7. على الرغم من أنّك لست بحاجة إلى إنشاء مشروع جديد، توضّح الخطوات الواردة في ورشة العمل كيفية إضافة مشروع جديد dev3 لتغطية حالة الاستخدام الخاصة بإضافة فريق جديد إلى المنصة.

يتم استخدام مستودع البنية الأساسية لإضافة الموارد الجديدة المذكورة أعلاه.

1. في Cloud Shell، انتقِل إلى WORKDIR واستنسِخ مستودع infrastructure.

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

2. استنسِخ فرع add-proj مستودع مصدر ورشة العمل إلى الدليل add-proj-repo.

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

 

3. انسخ الملفات من الفرع add-proj في مستودع ورشة العمل المصدر. يحتوي الفرع add-proj على التغييرات الخاصة بهذا القسم.

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

4. استبدِل الدليل infrastructure في دليل مستودع add-proj برابط رمزي إلى الدليل infra-repo للسماح بتشغيل النصوص البرمجية على الفرع.

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

5. نفِّذ النص البرمجي add-project.sh لنسخ الحالات والمتغيرات المشتركة إلى بنية دليل المشروع الجديد.

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

6. تنفيذ التغييرات ودفعها لإنشاء مشروع جديد

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

7. يؤدي الالتزام إلى تشغيل مستودع infrastructure لتفعيل البنية الأساسية باستخدام الموارد الجديدة. يمكنك الاطّلاع على مستوى تقدّم Cloud Build من خلال النقر على ناتج الرابط التالي والانتقال إلى أحدث إصدار في الأعلى.

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

تستغرق هذه الخطوة من 25 إلى 30 دقيقة. حان وقت الاستراحة وتناول القهوة.

تتمثّل الخطوة الأخيرة في إنشاء infrastructure Cloud Build لموارد Kubernetes جديدة في k8s-repo. سيؤدي ذلك إلى تشغيل Cloud Build في k8s-repo (في مشروع العمليات). إنّ موارد Kubernetes الجديدة مخصّصة للمجموعات الثلاث الجديدة التي تمت إضافتها في الخطوة السابقة. تتم إضافة موارد خطة التحكّم في ASM/Istio وموارد خطة التحكّم المشتركة إلى المجموعات الجديدة باستخدام k8s-repo Cloud Build.

8. بعد انتهاء عملية إنشاء البنية الأساسية في Cloud Build بنجاح، انتقِل إلى k8s-repo أحدث عملية تشغيل في Cloud Build من خلال النقر على رابط الإخراج التالي.

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

9. نفِّذ البرنامج النصي التالي لإضافة المجموعات الجديدة إلى ملفات المتغيرات وkubeconfig.

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

10. غيِّر المتغيّر KUBECONFIG للإشارة إلى ملف kubeconfig الجديد.

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

11. أدرِج سياقات مجموعتك. من المفترض أن تظهر لك ثماني مجموعات.

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

    `Output (do not copy)`

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

التحقّق من تثبيت Istio

12. تأكَّد من تثبيت Istio على مجموعة العمليات الجديدة من خلال التحقّق من أنّ جميع وحدات Pod قيد التشغيل وأنّ المهام قد اكتملت.

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. تأكَّد من تثبيت Istio على كلا المجموعتَين dev3. لا يتم تشغيل سوى Citadel وsidecar-injector وcoredns في مجموعات dev3. تتشارك هذه المجموعات في Istio controlplane الذي يعمل في مجموعة ops-3.

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

    `Output (do not copy)`

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

التحقّق من إمكانية رصد الخدمات في لوحات التحكّم المشترَكة

14. تأكَّد من نشر الأسرار في جميع مجموعات عمليات النشر لجميع مجموعات التطبيقات الست.

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

    `Output (do not copy)`

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

13. إيقاف الدائرة

الهدف: تنفيذ قاطع الدائرة لخدمة الشحن

• إنشاء DestinationRule لخدمة shipping من أجل تنفيذ قاطع الدائرة الكهربائية
• استخدِم fortio (أداة إنشاء تحميل) للتحقّق من صحة قاطع الدائرة الكهربائية لخدمة shipping من خلال تعطيل الدائرة الكهربائية

تعليمات "مختبر النصوص السريعة"

سيتم إطلاق Fast Track Script Lab قريبًا!!

تعليمات التمرين المعملي حول طريقة النسخ واللصق

بعد أن تعرّفنا على بعض الاستراتيجيات الأساسية لرصد وتحديد المشاكل وحلّها في الخدمات المتوافقة مع Istio، لنلقِ نظرة على كيفية مساعدة Istio في تحسين مرونة خدماتك، ما يقلّل من مقدار تحديد المشاكل وحلّها الذي عليك تنفيذه في المقام الأول.

تتسبّب بنية الخدمات المصغّرة في خطر الأعطال المتتالية، حيث يمكن أن ينتقل عطل إحدى الخدمات إلى التبعيات الخاصة بها، وإلى تبعيات تلك التبعيات، ما يؤدي إلى انقطاع "تأثير مضاعف" يمكن أن يؤثر في المستخدمين النهائيين. يوفر Istio سياسة حركة مرور "قاطع الدائرة" لمساعدتك في عزل الخدمات، وحماية الخدمات النهائية (من جهة العميل) من انتظار الخدمات التي يتعذّر الوصول إليها، وحماية الخدمات الأولية (من جهة الخادم) من تدفق مفاجئ لحركة المرور النهائية عند إعادة الاتصال بالإنترنت. بشكل عام، يمكن أن يساعدك استخدام قواطع الدوائر في تجنُّب تعذُّر استيفاء جميع خدماتك لاتفاقيات مستوى الخدمة بسبب تعليق إحدى الخدمات الخلفية.

تمت تسمية نمط "قاطع الدائرة" على اسم مفتاح كهربائي يمكن أن "يتعطّل" عند مرور الكثير من الكهرباء، ما يحمي الأجهزة من التحميل الزائد. في إعداد Istio، يعني ذلك أنّ Envoy هو قاطع الدائرة، ويتتبّع عدد الطلبات المعلّقة لإحدى الخدمات. في هذه الحالة المغلقة التلقائية، تمر الطلبات عبر Envoy بدون انقطاع.

ولكن عندما يتجاوز عدد الطلبات المعلّقة الحدّ الذي حدّدته، يتم إيقاف قاطع الدائرة الكهربائية (فتحه)، ويعرض Envoy على الفور رسالة خطأ. يسمح ذلك للخادم بإعلام العميل سريعًا بحدوث خطأ، ويمنع الرمز البرمجي لتطبيق الخادم من تلقّي طلب العميل عند التحميل الزائد.

بعد انتهاء المهلة المحدّدة، ينتقل Envoy إلى حالة نصف مفتوحة، حيث يمكن للخادم البدء في تلقّي الطلبات مرة أخرى بطريقة تجريبية، وإذا تمكّن من الردّ على الطلبات بنجاح، يتم إغلاق قاطع الدائرة الكهربائية مرة أخرى، وتبدأ الطلبات في الوصول إلى الخادم مرة أخرى.

يلخّص هذا الرسم البياني نمط قاطع الدائرة في Istio. تمثّل المستطيلات الزرقاء Envoy، وتمثّل الدائرة الزرقاء المعبّأة العميل، وتمثّل الدوائر البيضاء المعبّأة حاوية الخادم:

يمكنك تحديد سياسات Circuit Breaker باستخدام Istio DestinationRules. في هذا القسم، سنطبّق السياسة التالية لفرض قاطع الدائرة الكهربائية على خدمة الشحن:

Output (do not copy)

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

هناك حقلان في DestinationRule يجب ملاحظتهما هنا. يحدّد connectionPool عدد الاتصالات التي ستسمح بها هذه الخدمة. الحقل outlierDetection هو المكان الذي نضبط فيه كيفية تحديد Envoy للحدّ الذي سيتم عنده فتح قاطع الدائرة الكهربائية. في هذه الحالة، سيحصي Envoy كل ثانية (فترة زمنية) عدد الأخطاء التي تلقّاها من حاوية الخادم. إذا تجاوزت الحدّ consecutiveErrors، سيتم فتح قاطع الدائرة الكهربائية Envoy، وستتم حماية% 100 من وحدات productcatalog من طلبات العملاء الجديدة لمدة 10 ثوانٍ. بعد فتح قاطع الدائرة Envoy (أي تفعيله)، ستتلقّى البرامج 503 (الخدمة غير متوفرة) أخطاء. لنطّلِع على مثال عملي على ذلك.

1. اضبط متغيّرات البيئة لدليلَي k8s-repo وasm لتسهيل الأوامر.

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

2. تعديل k8s-repo

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

3. عدِّل DestinationRule لخدمة الشحن على مجموعتَي Ops.

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. Fortio هذه هي مجموعة العميل التي سنستخدمها "لإيقاف" قاطع الدائرة الكهربائية لخدمة shippingservice.

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

5. إجراء التغييرات

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

6. انتظِر إلى أن تكتمل عملية Cloud Build.
7. في Cloud Shell، استخدِم وحدة fortio لإرسال عدد 1000 طلب إجماليًا إلى shippingservice مع اتصال واحد متزامن، ولن يؤدي ذلك إلى تشغيل قاطع الدائرة الكهربائية لأنّنا لم نتجاوز إعدادات connectionPool بعد.

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

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

الناتج (لا تنسخ)

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

8. أعِد تشغيل fortio مرة أخرى، مع زيادة عدد الاتصالات المتزامنة إلى 2، ولكن مع الحفاظ على العدد الإجمالي للطلبات ثابتًا. من المفترض أن يعرض ثلثا الطلبات على الأقل الخطأ "overflow"، لأنّ قاطع الدائرة الكهربائية قد تم تنشيطه: في السياسة التي حدّدناها، لا يُسمح إلا باتصال واحد متزامن في فاصل زمني مدته ثانية واحدة.

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

الناتج (لا تنسخ)

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

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

9. يتتبّع Envoy عدد الاتصالات التي تمّت إزالتها عندما يكون قاطع الدائرة الكهربائية نشطًا، وذلك باستخدام مقياس upstream_rq_pending_overflow. لنبحث عن ذلك في وحدة fortio:

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

الناتج (لا تنسخ)

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

10. نظِّم الموارد عن طريق إزالة سياسة قاطع الدائرة من كلتا المنطقتين.

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

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

يوضّح هذا القسم كيفية إعداد سياسة واحدة لقطع الدائرة الكهربائية لإحدى الخدمات. من أفضل الممارسات إعداد قاطع الدائرة الكهربائية لأي خدمة مصدر (خلفية) يمكن أن تتوقف عن العمل. من خلال تطبيق سياسات قاطع الدائرة الكهربائية في Istio، يمكنك المساعدة في عزل خدماتك المصغّرة وإنشاء تحمّل للأخطاء في تصميمك وتقليل خطر حدوث أعطال متتالية في ظل الحمل العالي.

14. إدخال الأخطاء

الهدف: اختبار مرونة خدمة الاقتراحات من خلال إدخال تأخيرات (قبل طرحها في مرحلة الإنتاج).

• إنشاء VirtualService لخدمة recommendation من أجل تقديم تأخير لمدة 5 ثوانٍ
• اختبار التأخير باستخدام fortio load generator
• إزالة التأخير في VirtualService والتحقّق من صحة البيانات

تعليمات "مختبر النصوص السريعة"

سيتم إطلاق Fast Track Script Lab قريبًا!!

تعليمات التمرين المعملي حول طريقة النسخ واللصق

تُعدّ إضافة سياسات قاطع الدائرة الكهربائية إلى خدماتك إحدى طرق تعزيز المرونة في مواجهة الخدمات أثناء الإنتاج. لكنّ إيقاف الدائرة يؤدي إلى حدوث أخطاء، وربما أخطاء تظهر للمستخدمين، وهذا ليس مثاليًا. لتجنُّب حالات الخطأ هذه، وتوقُّع طريقة استجابة الخدمات النهائية بشكل أفضل عندما تعرض الخلفيات أخطاء، يمكنك استخدام اختبار الفوضى في بيئة مرحلية. اختبار الفوضى هو ممارسة تهدف إلى تعطيل خدماتك عمدًا من أجل تحليل نقاط الضعف في النظام وتحسين قدرته على تحمّل الأخطاء. يمكنك أيضًا استخدام اختبار الفوضى لتحديد طرق الحدّ من الأخطاء التي يواجهها المستخدمون عند تعذُّر عمل الأنظمة الخلفية، وذلك مثلاً من خلال عرض نتيجة مخزَّنة مؤقتًا في الواجهة الأمامية.

يُعدّ استخدام Istio لإدخال الأخطاء مفيدًا لأنّه يمكنك استخدام صور إصدارات الإنتاج وإضافة الخطأ في طبقة الشبكة بدلاً من تعديل رمز المصدر. في مرحلة الإنتاج، يمكنك استخدام أداة اختبار الفوضى كاملة الميزات لاختبار المرونة على مستوى Kubernetes/الحوسبة بالإضافة إلى مستوى الشبكة.

يمكنك استخدام Istio لاختبار الفوضى من خلال تطبيق VirtualService مع الحقل "fault". يتيح Istio نوعَين من الأخطاء: أخطاء التأخير (إدخال مهلة) وأخطاء الإيقاف (إدخال أخطاء HTTP). في هذا المثال، سنُدخل خطأ تأخير لمدة 5 ثوانٍ في خدمة الاقتراحات. ولكن هذه المرة، بدلاً من استخدام قاطع الدائرة الكهربائية "لإيقاف التشغيل سريعًا" في مواجهة هذه الخدمة المعطّلة، سنفرض على الخدمات التابعة تحمّل المهلة الزمنية الكاملة.

11. انتقِل إلى دليل إدخال الأعطال.

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

12. افتح k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml لفحص محتواه. لاحظ أنّ Istio يوفّر خيارًا لإدخال الخطأ في نسبة مئوية من الطلبات، وسنضيف هنا مهلة إلى جميع طلبات recommendationservice.

الناتج (لا تنسخ)

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

13. انسخ VirtualService إلى k8s_repo. سنُدخل الخطأ على مستوى العالم في كلتا المنطقتَين.

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

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

14. إرسال التغييرات

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

15. انتظِر إلى أن تكتمل عملية Cloud Build.
16. نفِّذ الأمر داخل وحدة fortio التي تم نشرها في قسم قاطع الدائرة، وأرسِل بعض الزيارات إلى recommendationservice.

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

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

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

الناتج (لا تنسخ)

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

17. هناك طريقة أخرى لرؤية الخطأ الذي أدرجناه أثناء العمل، وهي فتح الواجهة الأمامية في متصفّح ويب والنقر على أي منتج. يجب أن تستغرق صفحة المنتج 5 ثوانٍ إضافية للتحميل، لأنّها تستردّ الاقتراحات المعروضة في أسفل الصفحة.
18. يمكنك إجراء عملية تنظيف عن طريق إزالة خدمة إدخال الأعطال من كلا مجموعتَي Ops.

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

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

19. إرسال التغييرات:

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

15. مراقبة "خطة تحكّم" Istio

تثبِّت ASM أربعة مكوّنات مهمة في لوحة التحكّم: Pilot وMixer وGalley وCitadel. يرسل كل منها مقاييس الرصد ذات الصلة إلى Prometheus، وتتضمّن ASM لوحات بيانات Grafana التي تتيح للمشغّلين عرض بيانات الرصد هذه وتقييم حالة مستوى التحكّم وأدائه.

عرض لوحات البيانات

20. توجيه المنفذ لخدمة Grafana المثبَّتة باستخدام Istio

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

21. فتح Grafana في المتصفّح
22. انقر على رمز "معاينة الويب" في أعلى يسار نافذة Cloud Shell
23. انقر على "معاينة" على المنفذ 3000 (ملاحظة: إذا لم يكن المنفذ 3000، انقر على "تغيير المنفذ" وحدِّد المنفذ 3000).
24. سيؤدي ذلك إلى فتح علامة تبويب في المتصفّح تحتوي على عنوان URL مشابه لـ " BASE_URL/?orgId=1&authuser=0&environment_id=default"
25. عرض لوحات البيانات المتاحة
26. عدِّل عنوان URL إلى " BASE_URL/dashboard"
27. انقر على مجلد "istio" لعرض لوحات البيانات المتاحة
28. انقر على أيّ من لوحات البيانات هذه لعرض أداء هذا المكوّن. سنتناول في الأقسام التالية المقاييس المهمة لكل مكوّن.

التشغيل التجريبي للرصد

‫Pilot هو أحد مكونات لوحة التحكّم التي توزع إعدادات الشبكات والسياسات على مستوى البيانات (خوادم Envoy الوكيلة). يميل الإصدار التجريبي إلى التوسّع مع عدد أحمال العمل وعمليات النشر، ولكن ليس بالضرورة مع مقدار عدد الزيارات إلى أحمال العمل هذه. يمكن أن يؤدي التشغيل التجريبي غير الصحي إلى ما يلي:

• استهلاك موارد أكثر من اللازم (وحدة المعالجة المركزية و/أو ذاكرة الوصول العشوائي)
• سيؤدي إلى تأخير في إرسال معلومات الإعداد المعدَّلة إلى وكلاء Envoy

ملاحظة: إذا كان Pilot متوقفًا أو كانت هناك تأخيرات، ستستمر أحمال العمل في عرض الزيارات.

23. انتقِل إلى " BASE_URL/dashboard/db/istio-pilot-dashboard" في المتصفّح لعرض مقاييس Pilot.

المقاييس المهمة التي يجب تتبُّعها

استخدام الموارد

استخدِم صفحة "الأداء وقابلية التوسّع" في Istio كدليل لأرقام الاستخدام المقبولة. يُرجى التواصل مع فريق دعم GCP إذا لاحظت زيادة كبيرة في استخدام الموارد بشكل مستمر.

معلومات حول الإصدار التجريبي من الإشعارات الفورية

يتتبّع هذا القسم عمليات إرسال إعدادات Pilot إلى خوادم Envoy الوكيلة.

• تعرض عمليات الدفع التجريبية نوع الإعداد الذي يتم دفعه في أي وقت.
• تعرض مراقبة ADS عدد الخدمات الافتراضية والخدمات ونقاط النهاية المرتبطة في النظام.
• تعرض المجموعات التي ليس لها نقاط نهاية معروفة نقاط النهاية التي تم إعدادها ولكن ليس لديها أي مثيلات قيد التشغيل (ما قد يشير إلى خدمات خارجية، مثل ‎ *.googleapis.com).
• تعرض أخطاء الإصدار التجريبي عدد الأخطاء التي حدثت بمرور الوقت.
• تعرض التعارضات عدد التعارضات التي تمثّل إعدادًا غامضًا في أدوات معالجة الأحداث.

إذا ظهرت لك أخطاء أو تعارضات، يعني ذلك أنّ هناك إعدادات غير صحيحة أو غير متسقة في واحدة أو أكثر من خدماتك. لمزيد من المعلومات، اطّلِع على مقالة تحديد المشاكل وحلّها في مستوى البيانات.

معلومات Envoy

يحتوي هذا القسم على معلومات حول خوادم Envoy الوكيلة التي تتواصل مع لوحة التحكّم. يُرجى التواصل مع فريق دعم GCP إذا ظهرت لك أخطاء متكررة في ربط XDS.

Monitoring Mixer

‫Mixer هو المكوّن الذي يوجّه بيانات القياس عن بُعد من خوادم وكيل Envoy إلى الخلفيات (عادةً Prometheus وStackdriver وما إلى ذلك). في هذه الحالة، لا تكون في مستوى البيانات. يتم نشرها كوظيفتَين من وظائف Kubernetes (تُعرف باسم Mixer) يتم نشرهما باسمَي خدمتَين مختلفَين (istio-telemetry وistio-policy).

يمكن أيضًا استخدام Mixer للدمج مع أنظمة السياسات. في هذه الحالة، يؤثّر Mixer في مستوى البيانات، لأنّ عمليات التحقّق من السياسات التي تفشل في Mixer تحظر الوصول إلى خدماتك.

يميل Mixer إلى التوسّع مع حجم الزيارات.

24. انتقِل إلى " BASE_URL/dashboard/db/istio-mixer-dashboard" في المتصفّح لعرض مقاييس Mixer.

المقاييس المهمة التي يتم تتبُّعها

استخدام الموارد

استخدِم صفحة "الأداء وقابلية التوسّع" في Istio كدليل لأرقام الاستخدام المقبولة. يُرجى التواصل مع فريق دعم GCP إذا لاحظت زيادة كبيرة في استخدام الموارد بشكل مستمر.

نظرة عامة حول Mixer

• مدة الاستجابة هي مقياس مهم. على الرغم من أنّ التقارير إلى بيانات قياس استخدام Mixer ليست في مسار البيانات، إذا كانت حالات التأخير هذه كبيرة، سيؤدي ذلك بالتأكيد إلى إبطاء أداء وكيل Sidecar. يجب أن تتوقّع أن يكون المئوي التسعون في نطاق الأرقام الفردية من الملّي ثانية، وأن يكون المئوي التاسع والتسعون أقل من 100 ملّي ثانية.

• يشير مدة إرسال المحوّل إلى وقت الاستجابة الذي يواجهه Mixer عند استدعاء المحوّلات (التي يرسل من خلالها المعلومات إلى أنظمة القياس عن بُعد وتسجيل البيانات). سيؤثر ارتفاع معدلات الاستجابة هنا بشكل كبير على الأداء على الشبكة المتداخلة. مرة أخرى، يجب أن تكون مدة الاستجابة عند النسبة المئوية التسعين أقل من 10 ملي ثانية.

Monitoring Galley

Galley هي مكوّن التحقّق من صحة الإعدادات والاستيعاب والمعالجة والتوزيع في Istio. تنقل هذه السمة الإعدادات من خادم Kubernetes API إلى Pilot. مثل Pilot، يميل إلى التوسّع مع عدد الخدمات ونقاط النهاية في النظام.

25. انتقِل إلى " BASE_URL/dashboard/db/istio-galley-dashboard" في المتصفّح لعرض مقاييس Galley.

المقاييس المهمة التي يتم تتبُّعها

التحقّق من صحة المرجع

المقياس الأكثر أهمية الذي يجب تتبُّعه والذي يشير إلى عدد الموارد من أنواع مختلفة، مثل قواعد الوجهة والبوابات وإدخالات الخدمة التي تجتاز عملية التحقّق من الصحة أو لا تجتازها.

العملاء المرتبطون

يشير إلى عدد العملاء المتصلين بـ Galley، وعادةً ما يكون هذا العدد 3 (البرنامج التجريبي، وistio-telemetry، وistio-policy)، وسيتم توسيعه مع توسيع نطاق هذه المكوّنات.

16. تحديد المشاكل وحلّها في Istio

تحديد المشاكل في مستوى البيانات وحلّها

إذا كانت لوحة بيانات الإصدار التجريبي تشير إلى أنّ لديك مشاكل في الإعداد، عليك فحص سجلات الإصدار التجريبي أو استخدام istioctl للعثور على مشاكل الإعداد.

لفحص سجلات Pilot، شغِّل kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery، واستبدِل istio-pilot-... بمعرّف لوحة لنسخة Pilot التي تريد تحديد المشاكل فيها وحلّها.

في السجلّ الناتج، ابحث عن رسالة حالة الإرسال. على سبيل المثال:

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

ستشير حالة الإرسال إلى أي مشاكل حدثت عند محاولة إرسال الإعداد إلى خوادم وكيل Envoy. في هذه الحالة، نرى عدة رسائل "مجموعة مكرّرة"، تشير إلى وجهات مكرّرة في المصدر.

للحصول على مساعدة في تشخيص المشاكل، يُرجى التواصل مع فريق دعم Google Cloud بشأن المشاكل.

العثور على أخطاء في الإعدادات

لاستخدام istioctl في تحليل إعداداتك، شغِّل الأمر istioctl experimental analyze -k --context $OPS_GKE_1. سيؤدي ذلك إلى إجراء تحليل للإعدادات في نظامك، وتحديد أي مشاكل مع أي تغييرات مقترَحة. يمكنك الاطّلاع على المستندات للحصول على قائمة كاملة بأخطاء الإعداد التي يمكن لهذا الأمر رصدها.

17. تنظيف

ينفّذ المشرف الخطوات التالية بعد انتهاء ورشة العمل.

ينفّذ المشرف النص البرمجي cleanup_workshop.sh لحذف الموارد التي تم إنشاؤها بواسطة النص البرمجي bootstrap_workshop.sh. يجب توفير المعلومات التالية لتنفيذ نص التنظيف.

• اسم المؤسسة، مثل yourcompany.com
• معرّف ورشة العمل - بالتنسيق YYMMDD-NN، مثلاً 200131-01
• حزمة GCS الخاصة بالمشرف: يتم تحديدها في النص البرمجي للتشغيل الأوّلي.

13. افتح Cloud Shell، ونفِّذ جميع الإجراءات أدناه في Cloud Shell. انقر على الرابط أدناه.

CLOUD SHELL

14. تأكَّد من تسجيل الدخول إلى gcloud باستخدام حساب المشرف المطلوب.

gcloud config list
 

15. انتقِل إلى مجلد asm.

cd ${WORKDIR}/asm
 

16. حدِّد اسم مؤسستك ومعرّف ورشة العمل المطلوب حذفهما.

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

17. نفِّذ نص التنظيف البرمجي على النحو التالي.

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