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

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

ملاحظة مهمة: هذه ورشة عمل على الإصدار ألفا والهدف منها أن تكون تدريبًا على مستوى الصف الدراسي تحت إشراف المرشَّح.

رابط إلى الدرس التطبيقي حول الترميز في ورشة العمل bit.ly/asm-workshop

2. نظرة عامة

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

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

جدول الأعمال

• الوحدة 0 - المقدمة وإعداد النظام الأساسي
• المقدمة والهندسة
• مقدمة عن شبكة الخدمة المتداخلة وIStio/ASM
• المعمل: إعداد البنية الأساسية: سير عمل المستخدم
• استراحة
• QnA
• الوحدة 1 - تثبيت التطبيقات وتأمينها ومراقبتها باستخدام ASM
• نموذج Repo: شرح البنية الأساسية ومستودعات Kubernetes
• المختبر: نشر نموذج تطبيق
• الخدمات الموزعة وإمكانية المراقبة
• الغداء
• المختبر: الملاحظة باستخدام Stackdriver
• QNA
• الوحدة 2 - DevOps - عمليات طرح إصدار Canary، والسياسة/RBAC
• اكتشاف الخدمة متعددة المجموعات والأمان/السياسة
• المعمل: بروتوكول أمان طبقة النقل (TLS) المتبادل
• عمليات نشر Canary
• المختبر: عمليات نشر إصدار Canary
• موازنة الحمل الشامل الآمن للمجموعات المتعدّدة المجموعات
• استراحة
• المختبر: سياسة التفويض
• QNA
• الوحدة 3 - العمليات Infra Ops - ترقيات النظام الأساسي
• الوحدات الأساسية للخدمة الموزعة
• المختبر: توسيع نطاق البنية الأساسية
• الخطوات التالية

شرائح

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

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

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

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

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

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

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

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

شرح نص ورشة العمل حول التمهيد

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

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

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

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

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

مخطط المستخدم والأذونات أثناء تنفيذ ورشة العمل

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

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

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

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

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

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

تم إعداد ورشة العمل هذه لبدء العمل من منصة Cloud Shell. الأدوات التالية مطلوبة لورشة العمل هذه.

• gcloud (الإصدار >= 270)
• kubectl
• sed (يعمل مع sed على Cloud Shell/Linux وليس على Mac OS)
• git (احرص على التحديث)
• sudo apt update
• sudo apt install git
• jq
• envsubst

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

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

1. افتح 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 Platform لكل مستخدم داخل المؤسسة. داخل المجلد، يتم إنشاء مشروع مشرف Terraform. يتم استخدام مشروع مشرف التضاريس لإنشاء باقي موارد GCP المطلوبة لورشة العمل هذه. يمكنك تفعيل واجهات برمجة التطبيقات المطلوبة في مشروع المشرف في terraform. يمكنك استخدام Cloud Build لتطبيق خطط Terraform. يجب منح حساب خدمة Cloud Build أدوار "إدارة الهوية وإمكانية الوصول" المناسبة له ليتمكّن من إنشاء موارد على Google Cloud Platform. أخيرًا، يمكنك إعداد خلفية بعيدة في حزمة Google Cloud Storage (GCS) لتخزين حالات التضاريس لجميع موارد 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. انقر على الرابط أدناه.

الصدفة السحابية

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. يمكنك الحصول على ملف Dashboard.txt من حزمة Admin 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]، ورقم تعريف مشروع المشرف الذي يستخدم تيرافورم سيكون user001-200131-01-tf-abcde وهكذا في باقي المشاريع. يجب على كل مستخدم تسجيل الدخول باستخدام حساب التمرين المعملي الذي قدمه مشرف ورشة العمل وإجراء ورشة العمل باستخدام حساب التمرين المعملي.

تحقَّق من عنوان البريد الإلكتروني للشركة (عنوان البريد الإلكتروني نفسه الذي استخدمته للتسجيل في ورشة العمل). من المفترض أن تكون قد تلقيت رسالة إلكترونية من مشرف ورشة العمل تتضمّن بيانات اعتماد حسابك في المختبر (أي اسم المستخدم وكلمة المرور). تبدو رسالة البريد الإلكتروني هكذا.

1. افتح Cloud Shell بالنقر على الرابط أدناه.

الصدفة السحابية

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

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

توفِّر لك هذه الخطوة جهاز افتراضي (VM) صغير لنظام التشغيل Linux Debian لاستخدامه في الوصول إلى موارد GCP. يحصل كل حساب على جهاز افتراضي في Cloud Shell. تسجيل الدخول باستخدام معلومات حساب المعمل وتسجيل دخولك باستخدام بيانات اعتماد الحساب المعملي. بالإضافة إلى Cloud Shell، يتم أيضًا توفير "محرِّر الرموز" لتسهيل تعديل ملفات الإعداد (بتنسيق terraform وYAML وما إلى ذلك). يتم تلقائيًا تقسيم شاشة Cloud Shell إلى بيئة Cloud Shell (في أسفل الصفحة) وCloud Code Editor (محرِّر الرموز البرمجية) (في أعلى الصفحة). يتيح لك رمز القلم الرصاص ورمز موجّه الطلبات في أعلى يسار الشاشة التبديل بين الاثنين (أداة تعديل الرموز البرمجية والواجهات). يمكنك أيضًا سحب الشريط الفاصل الأوسط (لأعلى أو لأسفل) وتغيير حجم كل نافذة يدويًا. 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

بعد اكتمال النص البرمجي، مصدر البيانات الأساسية لتعديل المتغيّرات في جلسة 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 OS)
• git (احرص على التحديث)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• pv

الوصول إلى مشروع المشرف في terraform

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

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

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

1. افتح 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. ويُستخدَم مستودع Chrome هذا لنشر بيانات Kubernetes في المجموعات العنقودية بطريقة GitOps.
• يتم إنشاء مشغّل Cloud Build كي ينشر بيانات Kubernetes في مجموعات GKE من المجلدات الخاصة بها عندما يكون هناك التزام بالفرع الرئيسي لـ k8s-repo.

يستغرق نص terraform 40-50 دقيقة.

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

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

ملاحظة: يجب إكمال هذا الإصدار قبل التحقُّق من تثبيت Istio.

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

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

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

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

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

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

13. أضِف vars.sh وKUBECONFIG var إلى .bashrc في Cloud Shell حتى يتم الحصول عليه في كل مرة تتم فيها إعادة تشغيل Cloud Shell.

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

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

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

    `Output (do not copy)`

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

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

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

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

    `Output (do not copy)`

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

    `Output (do not copy)`

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

16. تأكَّد من تثبيت Istio على مجموعتَي dev1. لا يتم تشغيل سوى Citadel ومُحقن سداسي ونواة في مجموعات dev1. ويشترك في وحدة تحكم Istio تعمل في مجموعة العمليات 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 ومُحقن سداسي ونواة في مجموعات dev2. ويشترك في وحدة تحكم Istio تعمل في مجموعة العمليات 2.

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

    `Output (do not copy)`

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

التأكّد من اكتشاف الخدمة لمستويات التحكّم المشتركة

18. يمكنك اختياريًا التأكّد من نشر المفاتيح السرّية.

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

    `Output (do not copy)`

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

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

في ورشة العمل هذه، ستستخدم شبكة VPC مشتركة يتم فيها إنشاء كل مجموعات GKE. لاستكشاف الخدمات على مستوى المجموعات، يمكنك استخدام ملفات kubeconfig (لكل مجموعة من مجموعات التطبيقات) التي تم إنشاؤها كأدوات سرية في مجموعات العمليات. يستخدم البرنامج التجريبي هذه الأسرار لاكتشاف "الخدمات" من خلال إرسال طلب بحث إلى خادم واجهة برمجة تطبيقات Kube لمجموعات التطبيقات (تمت المصادقة عليه من خلال المفاتيح السرّية أعلاه). ويتبيّن لك أنّ كلتا مجموعتَي العمليات يمكنهما المصادقة على جميع مجموعات التطبيقات باستخدام المفاتيح السرّية التي أنشأها kubeconfig. يمكن لمجموعات العمليات اكتشاف الخدمات تلقائيًا باستخدام ملفات kubeconfig كطريقة سرية. ويتطلب ذلك أن يكون للإصدار التجريبي في مجموعات العمليات إذن بالوصول إلى خادم واجهة برمجة تطبيقات Kube لجميع المجموعات الأخرى. إذا لم يتمكّن الإصدار التجريبي من الوصول إلى خوادم واجهة برمجة تطبيقات Kube، يمكنك إضافة الخدمات عن بُعد يدويًا باعتبارها ServiceEntries. ويمكنك اعتبار ServiceEntries بمثابة إدخالات لنظام أسماء النطاقات في سجلّ الخدمة. تُحدِّد ServiceEntries خدمة باستخدام اسم نظام أسماء نطاقات مؤهل بالكامل ( FQDN) وعنوان IP يمكن الوصول من خلاله إلى هذه الخدمة. راجِع مستندات Istio Multicluster للحصول على مزيد من المعلومات.

6- توضيح مستودع Repo للبنية الأساسية

إنشاء السحابة الإلكترونية للبنية الأساسية

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

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

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

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

يقوم مستودع البنية التحتية بإعداد موارد البنية الأساسية GCP لورشة العمل. إنها منظمة في مجلدات ومجلدات فرعية. تمثل المجلدات الأساسية ضمن المستودع team التي تمتلك موارد Google Cloud Platform محدَّدة. تمثل الطبقة التالية من المجلدات environment المحدَّد للفريق (على سبيل المثال، مطوّر البرامج أو المرحلة أو الإنتاج). تمثّل الطبقة التالية من المجلدات داخل البيئة resource المحدَّد (على سبيل المثال Host_project وgke_clusters وغيرها). توجد النصوص البرمجية وملفات النسخة الأولية في مجلدات الموارد.

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

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

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

الموفّر والحالات والمخرجات - الخلفيات والحالات المشتركة

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

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

تحتوي الموارد ذات القيم المترابطة على ملف output.tf. يتم تخزين قيم الإخراج المطلوبة في ملف tfstate المحدد في الخلفية لهذا المورد المحدد. على سبيل المثال، من أجل إنشاء مجموعة GKE في مشروع، عليك معرفة معرّف المشروع. يتم إخراج رقم تعريف المشروع من خلال audio.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 ومصدره من أي وحدة طرفية للحصول على القيم اللازمة لعملية الإعداد.

يتم تخزين متغيّرات التضاريس في 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 ومساحات الاسم

تنقسم الموارد في ورشة العمل هذه إلى مشاريع مختلفة لبرنامج GCP. يجب أن تتطابق المشروعات مع الهيكل التنظيمي (أو الفريق) لشركتك. تستخدم الفِرق (في مؤسستك) المسؤولة عن المشاريع أو المنتجات أو الموارد المختلفة مشاريع مختلفة على 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 وشبكة GKE المتداخلة. وتقع على عاتقهم مسؤولية تقوية المجموعات العنقودية وإدارة مدى مرونة وحجم منصة Kubernetes. في ورشة العمل هذه، يمكنك استخدام طريقة gitops لنشر الموارد في Kubernetes. يتوفّر مستودع CSR (يُعرف باسم k8s_repo) في مشروع العمليات.
4. أخيرًا، يستخدم فريقا dev1 وdev2 (فريقَين للتطوير) ينشئان تطبيقات التطبيقات dev1 وdev2 projects الخاصَّين بهم. وهذه هي التطبيقات والخدمات التي تقدّمها لعملائك. تعتمد هذه العمليات على النظام الأساسي الذي يديره فريق العمليات. يتم إرسال الموارد (عمليات النشر والخدمات وما إلى ذلك) إلى k8s_repo ويتم نشرها في المجموعات المناسبة. من المهم الإشارة إلى أنّ ورشة العمل هذه لا تركّز على أفضل الممارسات والأدوات المتعلقة بالتسويق عبر الإنترنت/CD. يمكنك استخدام Cloud Build لنشر موارد Kubernetes بشكل مبرمَج في مجموعات GKE مباشرةً. في سيناريوهات الإنتاج على أرض الواقع، يمكنك استخدام حل CI/CD مناسب لنشر التطبيقات في مجموعات GKE.

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

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

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

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

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

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

بيانات 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 المنطقة a
6. gke-4-apps-r2b-prod - مجموعة التطبيقات في المنطقة 2 b

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

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

الهدف: نشر تطبيق Hister Shop في مجموعات التطبيقات

• نسخة طبق الأصل عن "k8s-repo"
• نسخ بيانات المتجر الافتراضية إلى جميع مجموعات التطبيقات
• أنشِئ "خدمات" لتطبيق متجر عصري في مجموعات العمليات
• إعداد loadgenerators في مجموعات العمليات لاختبار الاتصال العام
• التحقق من الاتصال الآمن بتطبيق Hister Shop

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

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

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

إرشادات التمرين المعملي لطريقة النسخ واللصق

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

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

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

1. إنشاء دليل فارغ لمستودع git:

mkdir $WORKDIR/k8s-repo
 

2. Init git repo, add عن بُعد وسحب الدليل الرئيسي من المستودع البعيد:

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. انسخ مساحات الاسم والخدمات Hister 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. انسخ عمليات نشر تطبيق Hister 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. أزِل نشر خدمة سلّة التسوّق وrbac وpodsecuritypolicy من مجموعة المطوّرين باستثناء مجموعة واحدة. لم يتم تصميم Hillstershop للنشر متعدد المجموعات، لذا لتجنب اتساق النتائج، فإننا نستخدم خدمة سلة واحدة فقط.

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. أضِف نشر خدمة سلّة التسوّق و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 من مجموعات العمليات 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. انسخ موارد موصِّل الإعداد إلى إحدى المجموعات في كل مشروع.

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

13. يمكنك استبدال PROJECT_ID في بيانات موصل الضبط.

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

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

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

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

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

16. أضِف موارد 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. يمكنك عرض حالة مشروع العمليات Cloud Build في علامة تبويب مفتوحة سابقًا أو من خلال النقر على الرابط التالي:

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

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

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

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

Output (do not copy)

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

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

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

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

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

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

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

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

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

Output (do not copy)

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

الوصول إلى تطبيق Hister Shop

موازنة التحميل العام

لديك الآن تطبيق Hister Shop في جميع مجموعات التطبيقات الأربع. وتقع هذه المجموعات العنقودية في منطقتين وأربع مناطق. يمكن للعملاء الوصول إلى تطبيق Hister Shop من خلال الوصول إلى خدمة frontend. تعمل خدمة frontend على كل مجموعات التطبيقات الأربع. يتم استخدام جهاز موازنة الحمل في Google Cloud ( GCLB) لجذب زيارات العملاء إلى جميع المثيلات الأربعة لخدمة frontend.

لا تعمل مداخل Istio Ingress إلا في مجموعات العمليات، وتعمل كموازن تحميل إقليمي لمجموعتَي تطبيقات المنطقة في المنطقة. يستخدم GCLB مدخلي الدخول في Istio (اللذين يتم تشغيلهما في مجموعتَي العمليات) باعتبارهما واجهات خلفية لخدمة الواجهة الأمامية العالمية. تتلقى مداخل Istio Ingress حركة بيانات العميل من GCLB ثم ترسل زيارات العميل فصاعدًا إلى واجهات الواجهة الأمامية التي يتم تشغيلها في مجموعات التطبيقات.

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

وحدة التحكّم في GKE Autoneg

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

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

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

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

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

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

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

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

23. الحصول على GCLB > رابط المراقبة لمشروع العمليات الذي تم فيه إنشاء واجهة GCLB لمتجر Hister.

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.

يتم إنشاء ثلاث مجموعات NEG لكل istio-ingressgateway. وبما أنّ مجموعات العمليات هي مجموعات عنقودية إقليمية، يتم إنشاء مجموعة نقاط نهاية (NEG) واحدة لكل منطقة في المنطقة. في المقابل، تعمل مجموعات الإعلانات المتسلسلة istio-ingressgateway في منطقة واحدة لكل منطقة. يتم عرض عدد الزيارات عند الانتقال إلى istio-ingressgateway مجموعة.

تعمل أدوات إنشاء التحميل في كلتا مجموعتَي العمليات من محاكاة حركة بيانات العملاء من المنطقتين اللتين تقع فيهما. يتم إرسال التحميل الذي تم إنشاؤه في منطقة مجموعة العمليات 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"). وهذا يعني أنّه حتى في حال استخدام الحاويات ذات المربّعات السوداء وغير المخصّصة، لا يزال بإمكان المشغّلين ملاحظة عدد الزيارات الواردة من هذه الحاويات وإليها، ما يوفّر الخدمات للعملاء. تتخذ هذه الملاحظة شكل عدة طرق مختلفة: المقاييس والسجلات والتتبعات.

سنستخدم أيضًا نظام إنشاء التحميل المدمج في Hillster 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. يمكنك عرض حالة مشروع العمليات 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" لمعرفة أن هناك خيارات مثل "عدد طلبات الخادم" على "حاوية كوبرنتيس" نوع المورد. ويوضّح لنا ذلك أنّ المقاييس تتدفق من الشبكة المتداخلة إلى Stackdriver.

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

عرض المقاييس باستخدام لوحات البيانات:

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

يقدّم لنا الخادم الوكيل لـ Istio العديد من المقاييس، إلا أنّها مناسبة للبدء. (تتوفّر قائمة شاملة هنا). تجدر الإشارة إلى أنّ كل مقياس يحتوي على مجموعة من التصنيفات التي يمكن استخدامها للفلترة والتجميع، مثل: Destination_service وsource_workload_namespace وResponse_code وistio_tcp_reviewd_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".

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

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

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

حاول تعديل لوحة التحكم التي حصلت عليها للتو، وإضافة مقطع جديد:

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

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

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

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

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

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

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

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

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

يمكنك عرض السجلّات هنا:

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

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

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

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

بعض نماذج الفلاتر للمتجر العصري:

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

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

13. تحقق من آثار الأنشطة الموزعة.

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

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

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

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

يمكنك العثور هنا على "تتبُّع الأشخاص":

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

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

9. المصادقة المتبادلة لبروتوكول أمان طبقة النقل (TLS)

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

• تفعيل mTLS على نطاق الشبكة المتداخلة
• التحقُّق من بروتوكول mTLS من خلال فحص السجلات

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

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

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

إرشادات التمرين المعملي لطريقة النسخ واللصق

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

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

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

1. تحقَّق من سياسة MeshPolicy في مجموعات العمليات. ملاحظة: إنّ بروتوكول mTLS PERMISSIVE يسمح بحركة البيانات المشفَّرة وغير المزوّدة ببروتوكول mTLS.

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

    `Output (do not copy)`

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

تتم تهيئة Istio على جميع المجموعات باستخدام عامل التشغيل Istio الذي يستخدم مورد IstioControlPlane المخصص (CR). سنُعدّ mTLS في كل المجموعات من خلال تحديث IstioControlPlane CR وتحديث k8s-repo. الإعداد العام > mTLS > مفعَّل: يؤدي تفعيل: true في الرد التلقائي على IstioControlPlane إلى إجراء التغييرَين التاليَين على مستوى التحكّم Istio:

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

2. سنطبّق تصحيح kustomize على istioControlPlane CR لتفعيل مجموعة mTLS على مستوى مجموعة 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. يمكنك عرض حالة مشروع العمليات 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" بجوار "بروتوكول:

ينتج عن ذلك طريقة لطيفة لتصور التغيير.:

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 لإصدار جديد من خدمة الواجهة الأمامية.

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

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

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

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

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

$CANARY_DIR/repo-setup.sh 
 

يتم نسخ البيانات التالية:

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

3. الالتزام بالتغييرات على k8s_repo:

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

4. يمكنك عرض حالة مشروع العمليات 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 لتقسيم نافذة Cloudshell إلى جزأين:

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

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. تنفيذ مسار Canary في منطقة Dev1. ونوفّر نصًا برمجيًا يعدِّل النسب المئوية لعدد زيارات الواجهة الأمامية الإصدار 2 في VirtualService (مع تعديل الترجيحات إلى 20% و50% و80% ثم 100%). وبين آخر التعديلات، ينتظر النص البرمجي اكتمال سير عمل Cloud Build. تشغيل النص البرمجي لإصدار Canary لمنطقة 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 للواجهة الأمامية للإصدار 2، من المفترض أن تظهر لك رسالة نجاح في نهاية النص البرمجي:

    Output (do not copy) 
   

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

9. ويجب أن تكون كل حركة البيانات في الواجهة الأمامية من لوحة Dev2 المتسلسلة انتقالاً إلى الواجهة الأمامية v2:

    Output (do not copy) 
   

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

10. إغلاق جزء التقسيم.

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

11. انتقِل إلى مستودع مصدر السحابة الإلكترونية في الرابط الذي تم إنشاؤه.

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

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

الآن، ستكرر نفس العملية لمنطقة Dev2. يُرجى العِلم أنّ منطقة Dev2 لا تزال "مقفلة". في الإصدار 1 ويرجع ذلك إلى أنّه في النص البرمجي repo_setup الأساسي، دفعنا VirtualService لإرسال جميع الزيارات إلى الإصدار 1 بشكل صريح. بهذه الطريقة، تمكّنا من إنشاء إصدار Canary على المستوى الإقليمي بأمان على 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. تنفيذ مسار Canary في منطقة Dev2. ونوفّر نصًا برمجيًا يعدِّل النسب المئوية لعدد زيارات الواجهة الأمامية الإصدار 2 في VirtualService (مع تعديل الترجيحات إلى 20% و50% و80% ثم 100%). وبين آخر التعديلات، ينتظر النص البرمجي اكتمال سير عمل Cloud Build. تشغيل النص البرمجي لإصدار Canary لمنطقة 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 المتحرّكة تدريجيًا من الواجهة الأمامية إلى الإصدار 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 الإقليمي. في مرحلة الإنتاج، بدلاً من استخدام نص برمجي يدوي، يمكنك تلقائيًا تشغيل هذا النص البرمجي Canary كمسار في Cloud Build، وذلك باستخدام عامل تشغيل مثل إرسال صورة جديدة ذات علامة يتم إرسالها إلى سجلّ الحاوية. بالإضافة إلى ذلك، ننصحك بإضافة تحليل إصدار Canary بين كل خطوة، وتحليل وقت الاستجابة للإصدار 2 ومعدّل الخطأ مقابل حد الأمان المحدَّد مسبقًا، قبل إرسال عدد أكبر من الزيارات.

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

الهدف: إعداد RBAC بين الخدمات المصغَّرة (AuthZ).

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

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

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

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

إرشادات التمرين المعملي لطريقة النسخ واللصق

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

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

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

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

1. يجب فحص محتوى "currency-deny-all.yaml". تستخدم هذه السياسة أدوات اختيار تصنيفات النشر لحظر الوصول إلى خدمة currency. يُرجى العلم بعدم توفّر حقل 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 في علامة تبويب مفتوحة سابقًا أو من خلال النقر على الرابط التالي:

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

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

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

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

6. لنحقّق في كيفية فرض خدمة العملة لـ PermissionPolicy هذه. أولاً، عليك تفعيل السجلات على مستوى التتبُّع في الخادم الوكيل 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 (التفويض) من الخادم الوكيل الجانبي لخدمة العملات. من المفترض أن تظهر لك الرسالة "تم فرض الرفض" تشير إلى أنّه تم ضبط خدمة currency على حظر جميع الطلبات الواردة.

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 (عميل) معيّن إلى القائمة البيضاء للوصول إلى خدمة العملة. يتم تحديد المصدر.principal من خلال حساب خدمة Kubernetes. في هذه الحالة، يكون حساب الخدمة الذي نضيفه إلى القائمة البيضاء هو حساب خدمة الواجهة الأمامية في مساحة الاسم في الواجهة الأمامية.

ملاحظة: عند استخدام حسابات خدمة Kubernetes في Istio PermissionPolicies، يجب أولاً تفعيل بروتوكول أمان طبقة النقل (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. يمكنك عرض حالة مشروع العمليات Cloud Build في علامة تبويب مفتوحة سابقًا أو من خلال النقر على الرابط التالي:

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

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

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

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

الإخراج (عدم النسخ)

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

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

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

17. نشر التغييرات

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

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

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

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

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

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

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

• استنساخ مستودع infrastructure
• تعديل ملفات الأشكال التضاريسية لإنشاء موارد جديدة
• شبكتان فرعيتان في المنطقة الجديدة (إحداهما لمشروع العمليات والأخرى للمشروع الجديد)
• مجموعة عمليات جديدة في منطقة جديدة (في الشبكة الفرعية الجديدة)
• مستوى تحكُّم جديد في Istio في المنطقة الجديدة
• مجموعتان من التطبيقات في المشروع الجديد في المنطقة الجديدة
• الالتزام بمستودع infrastructure
• التحقق من التثبيت

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

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

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

إرشادات التمرين المعملي لطريقة النسخ واللصق

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

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

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

• عموديًا: داخل كل منطقة عن طريق إضافة المزيد من عمليات الحوسبة. ويتم ذلك إما عن طريق إضافة المزيد من العُقد (أو مجموعات العُقد) إلى المجموعات العنقودية الحالية أو إضافة مجموعات عنقودية جديدة داخل المنطقة. يتم ذلك من خلال مستودع 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 في k8s-repo (في مشروع العمليات). إنّ موارد Kubernetes الجديدة مخصّصة للمجموعات الثلاث الجديدة التي تمّت إضافتها في الخطوة السابقة. تتم إضافة مستوى التحكّم ASM/Istio وموارد مستوى التحكّم المشترك إلى المجموعات الجديدة باستخدام إصدار السحابة الإلكترونية k8s-repo.

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

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

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

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

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

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

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

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

    `Output (do not copy)`

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

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

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

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

    `Output (do not copy)`

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

13. تأكَّد من تثبيت Istio على مجموعتَي dev3. لا يتم تشغيل سوى Citadel ومُحقن سداسي ونواة في مجموعات dev3. تشترك المجموعة في مستوى تحكُّم Istio الذي يتم تشغيله في مجموعة 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 سياسة مرور البيانات لقاطع الدائرة الكهربائية لمساعدتك في عزل الخدمات، وحماية خدمات التشغيل (من جهة العميل) من انتظار الخدمات المتعطِّلة، وحماية الخدمات الرئيسية (من جهة الخادم) من التدفق المفاجئ لحركة مرور البيانات التي تحوَّل إلى نقطة الاتصال عند معاودة الاتصال بالإنترنت. بوجه عام، يمكن أن يساعدك استخدام قواطع الدائرة الكهربائية في تجنب إخفاق جميع خدماتك في إخفاق أهداف SLO بسبب وجود إحدى الخدمات الخلفية المعلّقة.

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

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

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

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

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

Output (do not copy)

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

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

1. يمكنك ضبط متغيّرات البيئة لكل من k8s-repo وasm dir لتبسيط الأوامر.

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

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. يُرجى الانتظار إلى أن تكتمل عملية إنشاء السحابة الإلكترونية.
7. في Cloud Shell، استخدِم لوحة fortio pod لإرسال زيارات gRPC إلى خدمة الشحن باستخدام اتصال متزامن واحد، وإجمالي 1,000 طلب. لن يؤدي هذا إلى إيقاف قاطع الدائرة الكهربائية لأنّنا لم نتجاوز إعدادات connectionPool حتى الآن.

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

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

الإخراج (عدم النسخ)

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

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

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

الإخراج (عدم النسخ)

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

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

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

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

الإخراج (عدم النسخ)

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
• يُرجى إزالة التأخير في VirtualService والتحقّق من صحة ذلك.

تعليمات التمرين المعملي للنص البرمجي للتتبع السريع

قريبًا: برنامج Fast Track Script Lab!

إرشادات التمرين المعملي لطريقة النسخ واللصق

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

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

يمكنك استخدام Istio لاختبار الفوضى من خلال تطبيق VirtualService مع "الخطأ". . يتوافق 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 يملك خيارًا لإدراج الخطأ في نسبة مئوية من الطلبات. وهنا، سنضع مهلة لجميع طلبات خدمة التوصية.

الإخراج (عدم النسخ)

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. يُرجى الانتظار إلى أن تكتمل عملية إنشاء السحابة الإلكترونية.
16. اتصِل إلى لوحة fortio pod المنشورة في قسم قاطع الدائرة الكهربائية، وأرسِل بعض حركة المرور إلى promotionservice.

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. يمكنك إخلاء مساحة كافية من خلال إزالة خدمة حقن الأخطاء من مجموعتَي العمليات.

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 بتثبيت أربعة مكونات مهمة لطائرة التحكم: الطيار والخلاط والرسم البياني والقلعة. ويرسل كل منها مقاييس المراقبة ذات الصلة إلى Prometheus، كما يتم شحن ASM إلى لوحات بيانات Grafana التي تتيح للمشغلين عرض بيانات المراقبة هذه وتقييم سلامة مستوى التحكم وأدائه.

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

20. إعادة توجيه خدمة Gravana المثبَّتة باستخدام 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. انقر على أي من لوحات البيانات هذه لعرض أداء هذا المكون. سنلقي نظرة على المقاييس المهمة لكل مكوّن في الأقسام التالية.

برنامج تجريبي للمراقبة

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

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

ملاحظة: إذا توقف الإصدار التجريبي أو إذا حدثت تأخيرات، ستظل أعباء العمل تخدم حركة الزيارات.

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

مقاييس مهمة تتم مراقبتها

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

استخدِم صفحة الأداء وقابلية التوسّع في Istio كدليل لأرقام الاستخدام المقبول. يمكنك التواصل مع فريق دعم Google Cloud Platform إذا لاحظت استخدام موارد أكثر استدامة بكثير من هذا.

المعلومات الفورية للتطبيق

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

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

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

معلومات Envoy

يحتوي هذا القسم على معلومات عن خوادم Envoy الوكيلة التي تتصل بمستوى التحكم. يُرجى التواصل مع فريق دعم Google Cloud Platform في حال ظهور حالات تعذُّر اتصال XDS متكرّرة.

أداة مزج المراقبة

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

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

يميل المزج إلى توسيع نطاقه مع حجم الزيارات.

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

مقاييس مهمة تتم مراقبتها

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

استخدِم صفحة الأداء وقابلية التوسّع في Istio كدليل لأرقام الاستخدام المقبول. يمكنك التواصل مع فريق دعم Google Cloud Platform إذا لاحظت استخدام موارد أكثر استدامة بكثير من هذا.

نظرة عامة حول الخلاطات

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

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

صالة المراقبة

إنّ واجهة برمجة التطبيقات Galaxy هي مكوِّن عمليات التحقّق من الإعدادات ونقلها والمعالجة والتوزيع في Istio. وهو ينقل الإعدادات من خادم واجهة برمجة تطبيقات Kubernetes إلى الإصدار التجريبي. وكما هو الحال مع البرنامج التجريبي، تميل إلى التوسع وفقًا لعدد الخدمات ونقاط النهاية في النظام.

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

مقاييس مهمة تتم مراقبتها

التحقّق من صحة الموارد

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

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

يشير إلى عدد العملاء المتصلين بغالي؛ وعادة ما يكون 3 (تجربة، وقياس عن بُعد، وسياسة istio)، وستتغير حسب نطاق هذه المكوّنات.

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

استكشاف أخطاء مستوى البيانات وإصلاحها

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

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

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

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

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

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

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

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

17. تنظيف

يقوم المشرف بتنفيذ الخطوات التالية بعد اكتمال ورشة العمل.

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

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

13. افتح 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}