סדנה ל-Anthos Service Mesh: מדריך Lab

1. סדנת אלפא

הערה חשובה: זהו סדנה באלפא, והיא מיועדת במיוחד להדרכת כיתה ב-Classroom.

קישור ל-Codelab של הסדנה bit.ly/asm-workshop

2. סקירה כללית

תרשים הארכיטקטורה

בסדנה הזאת יש חוויה סוחפת ומעשית שמסבירה איך להגדיר שירותים שמופצים ברחבי העולם ב-GCP בייצור. הטכנולוגיות העיקריות שבהן נעשה שימוש הן Google Kubernetes Engine (GKE) למחשוב ו-Istio Service mesh ליצירת קישוריות מאובטחת, ניראות (observability) ועיצוב תעבורת נתונים מתקדם. כל השיטות והכלים שנעשה בהם שימוש בסדנה זו הם שבהם תשתמשו בהפקה.

הנושאים לדיון

• מודול 0 – מבוא והגדרת פלטפורמה
• מבוא וארכיטקטורה
• מבוא ל-Service Mesh ול-Istio/ASM
• שיעור Lab: הגדרת תשתית: תהליך עבודה של משתמש
• הפסקה
• QnA
• מודול 1 – התקנה, אבטחה ומעקב של אפליקציות באמצעות ASM
• מודל מאגר: הסבר על מאגרי תשתית ו-Kubernetes
• שיעור Lab: פריסת אפליקציה לדוגמה
• שירותים מבוזרים וניראות (observability)
• ארוחת צהריים
• שיעור Lab: ניראות (observability) באמצעות Stackdriver
• QNA
• מודול 2 – DevOps – השקות של גרסה ראשונית (canary), מדיניות/RBAC
• אבטחה/מדיניות של שירות מרובה אשכולות
• שיעור Lab: TLS הדדי
• פריסות של גרסה ראשונית (canary)
• שיעור Lab: פריסות של גרסה ראשונית (canary)
• איזון עומסים גלובלי מאובטח של אשכולות מרובים
• הפסקה
• שיעור Lab: מדיניות הרשאות
• QNA
• מודול 3 – Infra Ops – שדרוגי הפלטפורמה
• אבני בניין של שירות מבוזר
• שיעור Lab: התאמת תשתית
• השלבים הבאים

מגלשות

ניתן למצוא את השקפים של הסדנה בקישור הבא:

מצגת לסדנת ASM

דרישות מוקדמות

כדי להמשיך בסדנה הזאת, אתם צריכים לוודא שהתנאים הבאים מתקיימים:

1. צומת של ארגון GCP
2. מזהה חשבון לחיוב (המשתמש שלכם חייב להיות אדמין לענייני חיוב בחשבון הזה לחיוב)
3. תפקיד IAM של אדמין ארגוני ברמת הארגון של המשתמש

3. הגדרת תשתית – תהליך עבודה של אדמין

השלבים בקטע הזה יבוצעו על ידי אדמין שיוצר את הסדנה.

אם אתם משתמשים שמשלימים את הסדנה, דלגו לקטע הבא בשם Infrastructure Setup - User Workflow

הסבר על התסריט לסדנת אתחול

סקריפט בשם bootstrap_workshop.sh משמש להגדרת הסביבה הראשונית לסדנה. אתם יכולים להשתמש בסקריפט הזה כדי להגדיר סביבה אחת לעצמכם או סביבות מרובות למשתמשים מרובים, למקרה שאתם מעבירים את הסדנה כהדרכה למספר משתמשים.

התסריט של סדנת האתחול באתחול דורש הקלט הבאים כקלט:

• שם הארגון (לדוגמה yourcompany.com) – הארגון שבו יוצרים סביבות לסדנה.
• מזהה חיוב (לדוגמה: 12345-12345-12345) – מזהה החיוב הזה משמש לחיוב כל המשאבים שהיו בשימוש במהלך הסדנה.
• מספר הסדנה (לדוגמה 01) – מספר דו-ספרתי. האפשרות הזו מתאימה אם אתם עורכים כמה סדנאות ביום אחד ואתם רוצים לעקוב אחריהן בנפרד. מספרי הסדנאות משמשים גם להסיק את מזהי הפרויקטים. מספרי סדנאות נפרדים יקלו על קבלת מזהי פרויקטים ייחודיים בכל פעם. בנוסף למספר הסדנה, התאריך הנוכחי (בפורמט של YYMMDD) משמש גם למזהי הפרויקטים. השילוב של תאריך ומספר הסדנה מספק מזהי פרויקטים ייחודיים.
• מספר משתמש התחלתי (לדוגמה 1) – המספר הזה מייצג את המשתמש הראשון בסדנה. לדוגמה: אם אתם רוצים ליצור סדנה ל-10 משתמשים, המספר של משתמש הקצה יכול להיות 1, ומספר משתמשי הקצה יהיה 10.
• מספר משתמש קצה (לדוגמה 10) – המספר הזה מייצג את המשתמש האחרון בסדנה. לדוגמה: אם אתם רוצים ליצור סדנה ל-10 משתמשים, המספר של משתמש הקצה יכול להיות 1, ומספר משתמשי הקצה יהיה 10. אם אתם מגדירים סביבה אחת (לדוגמה, בעצמכם), מספר המשתמש ההתחלתי ומספר משתמש הקצה זהים. הפעולה הזו תיצור סביבה אחת.

בנוסף למספר התאריך והסדנה, במזהי הפרויקטים משולבים גם מספרים של משתמשי קצה ומספרי התחלה. מזהי משתמשים (למשתמשים שמבצעים את הסדנה) נגזרים ממספר ההתחלה ומספר משתמש הקצה. מוסבר על מזהי משתמשים בקטע בשם User schema and permissions performing the workshop.

• קטגוריית GCS של אדמין (לדוגמה my-gcs-bucket-name) – קטגוריית GCS משמשת לאחסון מידע שקשור לסדנה. המידע הזה משמש את הסקריפט cleanup_workshop.sh כדי למחוק באלגנטיות את כל המשאבים שנוצרו במהלך התסריט של סדנת האתחול. אדמינים שיוצרים סדנאות צריכים הרשאות קריאה/כתיבה בקטגוריה הזו.

הסקריפט בסדנת האתחול משתמש בערכים שצוינו למעלה ומשמש כסקריפט wrapper שקורא לסקריפט 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:

• בעלים – הרשאה של בעלי הפרויקט לכל הפרויקטים בארגון.
• אדמין תיקיות – יכולת ליצור ולמחוק תיקיות בארגון. כל משתמש מקבל תיקייה אחת שמכילה את כל המשאבים שלו בתוך הפרויקט.
• אדמין ארגוני
• יצירת פרויקטים – הרשאה ליצור פרויקטים בארגון.
• Project Deleter – מחיקה של פרויקטים בארגון.
• אדמין IAM של פרויקט – יכולת ליצור כללי IAM בכל הפרויקטים בארגון.

בנוסף לתפקידים האלה, ADMIN_USER חייב להיות גם אדמין לענייני חיוב במזהה החיוב שמשמש לסדנה.

סכימת משתמשים והרשאות לביצוע הסדנה

אם בכוונתך ליצור את הסדנה למשתמשים (חוץ ממך) בארגון, עליך לפעול לפי סכמה ספציפית של משתמשים למתן שמות ל-MY_USERs. במהלך הסקריפט bootrap_workshop.sh, אתם מציינים מספר התחלה ומספר משתמש קצה. המספרים האלה משמשים ליצירת שמות המשתמשים הבאים:

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

לדוגמה, אם תריצו את הסקריפט של סדנת האתחול עם מספר המשתמש הראשון (1) ומספר משתמש הקצה (3) בארגון שלכם, בשם yourcompany.com ייווצרו סביבות הסדנה למשתמשים הבאים:

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

שמות המשתמשים האלה מוקצים תפקידי 'בעלים' של הפרויקט בפרויקטים הספציפיים שלהם שנוצרו במהלך הסקריפט setup_terraform_admin_project.sh. יש לפעול בהתאם לסכימה הזו למתן שמות של משתמשים כשמשתמשים בסקריפט bootstrap. כך מוסיפים מספר משתמשים בו-זמנית ב-G Suite.

הכלים הנדרשים לסדנה

הסדנה הזאת אמורה להיות במסגרת אתחול מ-Cloud Shell. לסדנה הזו נדרשים הכלים הבאים.

• gcloud (גרסה 270 או יותר)
• kubectl
• sed (עובד עם sed ב-Cloud Shell/Linux ולא ב-Mac OS)
• git (חשוב לוודא שאתם עדכניים)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize

כל הכלים מלבד kustomize כבר מותקנים כברירת מחדל ב-Cloud Shell. אם kustomize לא מותקן, צריך להתקין אותו באמצעות סקריפט ה-Bash שסופק בקישור שלמעלה, ולוודא שהבינארי הבינארי נמצא ב-PATH ולאשר על ידי הרצת הפקודה kustomize ב-Cloud Shell.

הגדרת סדנה לעצמך (הגדרת משתמש יחיד)

1. פותחים את Cloud Shell ומבצעים את כל הפעולות הבאות ב-Cloud Shell. אפשר ללחוץ על הקישור שלמטה.

Cloud Shell

2. ודאו שנכנסתם ל-gcloud עם משתמש האדמין המיועד.

gcloud config list
 

3. יוצרים WORKDIR ומשכפלים את מאגר הסדנה.

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

4. מגדירים את שם הארגון, מזהה החיוב, מספר הסדנה וקטגוריית GCS של אדמין שישמשו בסדנה. בודקים את ההרשאות הנדרשות להגדרת הסדנה בקטעים שלמעלה.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

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

export WORKSHOP_NUMBER=<two digit number for example 01>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

5. מריצים את הסקריפט bootrap_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 
 

לתשומת ליבכם: לא צריך להגדיר את מספר ההתחלה ואת מספר משתמש הקצה, כי אתם מגדירים את המספר בעצמכם.

לאחר השלמת הסקריפט shoestrap_workshop.sh, תיווצר תיקייה GCP לכל משתמש בארגון. בתוך התיקייה נוצר פרויקט אדמין Terraform. פרויקט האדמין ב-terraform משמש ליצירת שאר משאבי ה-GCP שנדרשים לסדנה הזו. צריך להפעיל את ממשקי ה-API הנדרשים בפרויקט האדמין של terraform. משתמשים ב-Cloud Build כדי להחיל תוכניות של Terraform. אתם צריכים לתת לחשבון השירות של Cloud Build תפקידי IAM מתאימים כדי שהוא יוכל ליצור משאבים ב-GCP. לבסוף, מגדירים קצה עורפי מרוחק בקטגוריה של Google Cloud Storage (GCS) כדי לאחסן מצבים של Terraform עם כל משאבי ה-GCP.

כדי לצפות במשימות של Cloud Build בפרויקט האדמין ב-terraform, צריך את מזהה פרויקט האדמין ב-terraform. הוא מאוחסן בקובץ vars/vars.sh תחת ספריית ה-asm. הספרייה הזו תישמר רק אם אתם מגדירים את הסדנה לעצמכם כאדמינים.

6. מקור קובץ המשתנים כדי להגדיר משתני סביבה

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

הגדרת סדנה למשתמשים מרובים (הגדרת מספר משתמשים)

7. פותחים את Cloud Shell ומבצעים את כל הפעולות הבאות ב-Cloud Shell. אפשר ללחוץ על הקישור שלמטה.

Cloud Shell

8. ודאו שנכנסתם ל-gcloud עם משתמש האדמין המיועד.

gcloud config list
 

9. יוצרים WORKDIR ומשכפלים את מאגר הסדנה.

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

10. מגדירים את שם הארגון, מזהה החיוב, מספר הסדנה, המספר של משתמש ההתחלה ומספר משתמש הקצה וקטגוריית GCS של אדמין לשימוש בסדנה. בודקים את ההרשאות הנדרשות להגדרת הסדנה בקטעים שלמעלה.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

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

export WORKSHOP_NUMBER=<two digit number for example 01>

export START_USER_NUMBER=<number for example 1>

export END_USER_NUMBER=<number greater or equal to START_USER_NUM>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

11. מריצים את הסקריפט bootrap_workshop.sh. השלמת הסקריפט עשויה להימשך כמה דקות.

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

12. כדי לאחזר את מזהי פרויקטי ה-terraform, משיגים את הקובץ workshop.txt מקטגוריית GCS של האדמין.

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

4. הגדרה והכנה לשיעור ה-Lab

משתמשים שמבצעים את הסדנה מתחילים כאן. צריך לבצע את כל השלבים מחלון INCOGNITO ב-Chrome או ב-Firefox.

בחירת הנתיב לשיעור ה-Lab

אפשר לבצע את שיעורי ה-Lab בסדנה הזו באחת משתי הדרכים הבאות:

• "סקריפטים אינטראקטיביים של מסלול מהיר קל" דרך
• האפשרות "העתקה והדבקה ידנית של כל הוראה" דרך

שיטת הסקריפטים במסלול מהיר מאפשרת להריץ סקריפט אינטראקטיבי יחיד לכל שיעור Lab, שינחה אתכם בשיעור ה-Lab באמצעות הרצה אוטומטית של הפקודות לשיעור ה-Lab הזה. הפקודות ירוצו בקבוצות עם הסברים תמציתיים על כל שלב ועל המטרות שלהן. אחרי כל קבוצת קבצים, תתבקשו לעבור לקבוצת הפקודות הבאה. כך תוכלו להריץ את שיעורי ה-Lab בקצב שלכם. הסקריפטים של המסלול המהיר הם אידמפוטנטיים, כלומר אפשר להריץ אותם כמה פעמים וכך תתקבל תוצאה זהה.

הסקריפטים של המסלול המהיר יופיעו בחלק העליון של כל שיעור Lab בתיבה ירוקה כפי שמוצג בהמשך.

תסריט הטראק המהיר

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

שיטת ההעתקה וההדבקה היא הדרך המסורתית להעתקה והדבקה של בלוקים של פקודות נפרדות עם הסברים על הפקודות. השיטה הזו מיועדת להפעלה פעם אחת בלבד. לא בטוח שהרצה חוזרת של פקודות בשיטה הזו תניב את אותן התוצאות.

יש לבחור אחת משתי השיטות כדי לבצע את שיעורי ה-Lab.

אחרי שבחרתם שיטה וביצוע את השלבים בשיטה הזו, אל תבצעו את השלבים בשיטה השנייה.

הגדרת סקריפט למסלול מהיר

אחרי שתסיימו את הסקריפט של המסלול המהיר, תסיימו את שיעור ה-Lab. אין לבצע את השלבים המפורטים בהוראות להעתקה והדבקה של שיעור ה-Lab.

אחזור של פרטי משתמש

הסדנה מתבצעת באמצעות חשבון משתמש זמני (או חשבון שיעור Lab) שנוצר על ידי מנהל הסדנה. החשבון של שיעור ה-Lab הוא הבעלים של כל הפרויקטים בסדנה. מנהל הסדנה מספק את פרטי הכניסה לחשבון של שיעור ה-Lab (שם משתמש וסיסמה) למשתמש שמבצע את הסדנה. התחילית של כל הפרויקטים של המשתמש היא שם המשתמש של החשבון לשיעור ה-Lab. לדוגמה: החשבון [e-mail] ב-Lab, מזהה פרויקט האדמין ב-terraform יהיה user001-200131-01-tf-abcde וכן הלאה בשאר הפרויקטים. כל משתמש צריך להתחבר לחשבון לשיעור ה-Lab שסופק על ידי מנהל הסדנה, ולבצע את הסדנה באמצעות החשבון לשיעור ה-Lab.

בודקים את כתובת האימייל של החברה (אותה כתובת אימייל שבה השתמשתם כדי להירשם לסדנה). הייתם אמורים לקבל אימייל מהאדמין של הסדנה עם פרטי הכניסה לחשבון שלכם בשיעור ה-Lab (כלומר, שם המשתמש והסיסמה). הודעת האימייל נראית כך.

1. לוחצים על הקישור שלמטה כדי לפתוח את Cloud Shell.

Cloud Shell

2. צריך להתחבר באמצעות פרטי הכניסה לחשבון לשיעור ה-Lab (ולא להתחבר באמצעות החשבון הארגוני או האישי). החשבון לשיעור ה-Lab נראה כמו userXYZ@<workshop_domain>.com.
3. מכיוון שמדובר בחשבון חדש, עליך לאשר את התנאים וההגבלות של Google. לוחצים על 'אישור'.

4. במסך הבא, מסמנים את התיבה כדי להביע הסכמה לתנאים ולהגבלות של Google ולוחצים על Start Cloud Shell.

השלב הזה מקצה VM קטן של Linux Debian כדי שתוכלו להשתמש בו כדי לגשת למשאבי GCP. לכל חשבון תהיה מכונה וירטואלית של Cloud Shell. מתחברים עם פרטי החשבון לשיעור ה-Lab ומתחברים באמצעות פרטי הכניסה לחשבון. בנוסף ל-Cloud Shell, הוספנו גם עורך קוד שמאפשר לערוך בקלות קובצי תצורה (terraform, YAML וכו'). כברירת מחדל, המסך של Cloud Shell מחולק לסביבת המעטפת של Cloud Shell (בחלק התחתון) ול-Cloud Code Editor (בחלק העליון). סמלי העיפרון וסמל הנחיית המעטפת בפינה השמאלית העליונה מאפשרים לעבור בין שניהם (מעטפת ועורך קוד). אפשר גם לגרור את סרגל המפריד האמצעי (למעלה או למטה) ולשנות את הגודל של כל חלון באופן ידני. 5. יוצרים WORKDIR לסדנה הזו. ה-WORKDIR היא תיקייה שממנה מבצעים את כל שיעורי ה-Lab בסדנה הזו. מריצים את הפקודות הבאות ב-Cloud Shell כדי ליצור את ה-WORKDIR.

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

6. אפשר לייצא את המשתמש בחשבון בשיעור ה-Lab כמשתנה כדי שישמש בסדנה הזו. זה אותו חשבון שאיתו התחברת ל-Cloud Shell.

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

הערה: אם אתם אדמינים ואתם מגדירים את הסדנה לעצמכם באמצעות המאפיין ' -sufa' או ' -setup-for-admin' לאחר מכן מגדירים את MY_USER לאימייל של חשבון ה-GCP שבו השתמשתם כדי ליצור את הפרויקטים של הסדנה.

7. מחזירים את המשתנים WORKDIR ו-MY_USER כדי לוודא ששניהם מוגדרים כראוי על ידי הרצת הפקודות הבאות.

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

8. משכפלים את מאגר הסדנה.

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

5. הגדרת תשתית – תהליך עבודה של המשתמש

המטרה: אימות ההתקנה של התשתית ו-Istio

• התקנת הכלים לסדנה
• שכפול מאגר של סדנאות
• אימות התקנה אחת (Infrastructure)
• אימות התקנה אחת (k8s-repo)
• אימות ההתקנה של Istio

תסריט הטראק המהיר

אם תבחרו בשיטה הזו, תריצו את הסקריפט הבא כדי לסיים את שיעור ה-Lab הזה.

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

בסיום הסקריפט, מכינים את ה-Bashrc במקור כדי לעדכן את המשתנים בסשן של Cloud Shell.

source ${HOME}/.bashrc

הוראות להעתקה והדבקה של שיטת ה-Labs

חשוב: אם כבר השלמתם את סקריפט המסלול המהיר לשיעור ה-Lab הזה, אל תבצעו את שיטת ההעתקה וההדבקה שבהמשך**.**.

אחזור של פרטי משתמש

האדמין שמגדיר את הסדנה צריך לספק למשתמש את שם המשתמש והסיסמה. התחילית של כל הפרויקטים של המשתמש תהיה user001-200131-01-tf-abcde, לדוגמה של המשתמש [e-mail], מזהה פרויקט האדמין ב-terraform יהיה user001-200131-01-tf-abcde וכן הלאה בשאר הפרויקטים. לכל משתמש יש גישה רק לסביבת הסדנה שלו.

הכלים הנדרשים לסדנה

הסדנה הזאת אמורה להיות במסגרת אתחול מ-Cloud Shell. לסדנה הזו נדרשים הכלים הבאים.

כל הכלים מלבד kustomize ו-pv כבר מותקנים כברירת מחדל ב-Cloud Shell. בהמשך תמצאו הוראות להתקנה של שתי האפשרויות האלה.

• gcloud (גרסה 270 או יותר)
• kubectl
• sed (עובד עם sed ב-Cloud Shell/Linux ולא ב-Mac OS)
• git (חשוב לוודא שאתם עדכניים)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize
• pv

גישה לפרויקט האדמין ב-terraform

לאחר השלמת הסקריפט shoestrap_workshop.sh, תיווצר תיקייה GCP לכל משתמש בארגון. בתוך התיקייה נוצר פרויקט אדמין Terraform. פרויקט האדמין ב-terraform משמש ליצירת שאר משאבי ה-GCP שנדרשים לסדנה הזו. הסקריפט setup-terraform-admin-project.sh מפעיל את ממשקי ה-API הנדרשים בפרויקט האדמין ב-terraform. Cloud Build משמש להחלת תוכניות Terraform. באמצעות הסקריפט, אתם נותנים לחשבון השירות של Cloud Build תפקידי IAM מתאימים כדי שיוכל ליצור משאבים ב-GCP. לבסוף, קצה עורפי מרוחק מוגדר בקטגוריה של Google Cloud Storage (GCS) לאחסון מצבים של Terraform עם כל משאבי ה-GCP.

כדי לצפות במשימות של Cloud Build בפרויקט האדמין ב-terraform, צריך את מזהה פרויקט האדמין ב-terraform. הוא יאוחסן בקטגוריית האדמין של GCS שצוינה בסקריפט ה-Bootstrap. אם מריצים את הסקריפט bootrap עבור משתמשים מרובים, כל מזהי הפרויקטים של מנהלי מערכת ב-terraform נמצאים בקטגוריה של GCS.

הסדנה הזאת אמורה להתבצע ב-Cloud Shell ובמסוף Cloud. צריך לבצע את השלבים הבאים בחלון INCOGNITO כי ההתחברות תתבצע באמצעות שם משתמש וסיסמה נפרדים.

1. לוחצים על הקישור שלמטה כדי לפתוח את Cloud Shell (אם היא עדיין לא פתוחה בקטע 'הגדרה והכנה' של Lab).

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, ולאמת שה-build הושלם.

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

אם נכנסים למסוף Cloud בפעם הראשונה, צריך לאשר את התנאים וההגבלות של Google.

9. בדף של Cloud Build, לוחצים על הקישור History בתפריט הניווט השמאלי ולוחצים על גרסת ה-build האחרונה כדי לראות את הפרטים של היישום הראשוני של Terraform. המשאבים הבאים נוצרים כחלק מהסקריפט של Terraform. אפשר להיעזר גם בתרשים הארכיטקטורה שלמעלה.

• 4 פרויקטים של GCP בארגון. החשבון לחיוב שצוין משויך לכל פרויקט.
• פרויקט אחד הוא ה-network host project של ה-VPC המשותף. לא נוצרים משאבים אחרים בפרויקט הזה.
• פרויקט אחד הוא ה-ops project שמשמש לאשכולות GKE ברמת Istio.
• שני פרויקטים מייצגים שני צוותי פיתוח שונים שעובדים על השירותים שלהם.
• שני אשכולות GKE נוצרים בכל אחד משלושת הפרויקטים הבאים: ops, dev1 ו-dev2.
• נוצר מאגר CSR בשם k8s-repo, שמכיל שש תיקיות לקובצי מניפסטים של Kubernetes. תיקייה אחת לכל אשכול GKE. המאגר הזה משמש לפריסת מניפסטים של Kubernetes באשכולות בצורה של GitOps.
• טריגר של Cloud Build נוצר כך שבכל פעם שיש התחייבות להסתעפות הראשית של k8s-repo, הוא פורס את המניפסטים של Kubernetes לאשכולות GKE מהתיקיות המתאימות שלהם.

הסקריפט מסוג terraform נמשך 40-50 דקות.

10. אחרי שה-build יסתיים ב-terraform admin project, יתחיל build נוסף בפרויקט התפעול. צריך ללחוץ על הקישור שמוצג כדי לפתוח את הדף של Cloud Build של ops project ולוודא שהמאגר של k8s-repo Cloud Build הסתיים.

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

הערה: צריך להשלים את גרסת ה-build הזו כדי לאמת את ההתקנה של 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 יופעל בכל הפעלה מחדש של 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 מותקן בשני האשכולות, בודקים שכל ה-Pods פועלים ושהמשימות הסתיימו.

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 שפועל באשכול ops-1.

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

17. יש לוודא ש-Istio מותקן בשני האשכולות dev2. רק Citadel, הזרקת מכונית וחיבורי ליבה פועלים באשכולות dev2. הם חולקים מטוס בקרה של Istio שפועל באשכול ops-2.

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

    `Output (do not copy)`

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

אימות גילוי השירות למישורי בקרה משותפים

18. אפשר גם לוודא שהסודות פרוסים.

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

    `Output (do not copy)`

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

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

בסדנה הזאת תשתמשו בVPC משותף אחד שבו נוצרים כל אשכולות GKE. כדי לגלות שירותים באשכולות, משתמשים בקובצי kubeconfig (לכל אחד מאשכולות האפליקציות) שנוצרו כסודות באשכולות הפעולות. תוכנית הפיילוט משתמשת בסודות האלה כדי לגלות שירותים על ידי שליחת שאילתות לשרת ה-API של Kube, אשכולות האפליקציות (שאומתו באמצעות הסודות שלמעלה). אתם רואים ששני אשכולות התפעול יכולים לבצע אימות לכל אשכולות האפליקציות באמצעות סודות שנוצרו באמצעות kubeconfig. אשכולות תפעול יכולים לאתר שירותים באופן אוטומטי באמצעות קובצי kubeconfig כשיטה סודית. לשם כך, לתוכנית הפיילוט באשכולות הפעולות צריכה להיות גישה לשרת של Kube API של כל האשכולות האחרים. אם תוכנית הפיילוט לא מצליחה להגיע לשרתי Kube API, צריך להוסיף שירותים מרוחקים באופן ידני כ-ServiceEntries. אפשר לחשוב על ServiceEntries כרשומות DNS במרשם השירותים. ServiceEntries מגדירות שירות באמצעות שם DNS שמוגדר במלואו ( FQDN) וכתובת IP שדרכה אפשר להגיע אל השירות. מידע נוסף זמין במסמכים של Istio Multicluster.

6. הסבר על מאגר תשתיות

תשתית Cloud Build

משאבי ה-GCP לסדנה נוצרים באמצעות Cloud Build ומאגר CSR של infrastructure. הפעלת סקריפט אתחול (שנמצא ב-scripts/bootstrap_workshop.sh) מהטרמינל המקומי שלך. הסקריפט ב-bootstrap יוצר תיקיית GCP, פרויקט אדמין ב-terraform והרשאות IAM מתאימות לחשבון השירות של Cloud Build. פרויקט האדמין ב-Terraform משמש לאחסון מצבי טרפורם, יומנים וסקריפטים שונים. הוא מכיל את infrastructure ואת k8s_repo מאגרי ה-CSR. בקטע הבא מוסבר בהרחבה על המאגרים האלה. בפרויקט האדמין של terraform לא מובנה משאבים אחרים של סדנאות. חשבון השירות של Cloud Build בפרויקט האדמין של terraform משמש לבניית משאבים לסדנה.

קובץ cloudbuild.yaml שנמצא בתיקייה infrastructure ישמש לפיתוח משאבי GCP לסדנה. נוצרת תמונת build מותאמת אישית בהתאמה אישית שכוללת את כל הכלים הדרושים ליצירת משאבי GCP. הכלים האלה כוללים את gcloud SDK, terraform ושירותים נוספים כמו python, git, jq וכו'. קובץ האימג' בהתאמה אישית של ה-builder מריץ את terraform plan ואת apply לכל משאב. קובצי ה-terraform של כל משאב ממוקמים בתיקיות נפרדות (פרטים בקטע הבא). המשאבים נוצרים אחד בכל פעם, ולפי הסדר שבו הם היו נוצרים בדרך כלל (לדוגמה, פרויקט GCP נבנה לפני שהמשאבים נוצרים בפרויקט). פרטים נוספים זמינים בקובץ cloudbuild.yaml.

Cloud Build מופעל בכל פעם שיש התחייבות למאגר infrastructure. כל שינוי שמתבצע בתשתית נשמר כתשתית כקוד (IaC) ומחויב למאגר. מצב הסדנה תמיד מאוחסן במאגר הזה.

מבנה התיקיות – צוותים, סביבות ומשאבים

מאגר התשתית מגדיר את משאבי התשתית של GCP לסדנה. הוא מובנה בתיקיות ובתיקיות משנה. תיקיות הבסיס במאגר מייצגות את team שבבעלותו משאבים ספציפיים של GCP. השכבה הבאה של התיקיות מייצגת את הערך environment הספציפי של הצוות (לדוגמה, dev, level, prod). השכבה הבאה של התיקיות בתוך הסביבה מייצגת את resource הספציפי (לדוגמה host_project, gke_clusters וכו'). הסקריפטים וקובצי ה-terraform הנדרשים קיימים בתיקיות המשאבים.

ארבעת סוגי הצוותים הבאים מיוצגים בסדנה:

1. infrastructure – מייצג את צוות תשתית הענן. הם אחראים ליצירת המשאבים של GCP לכל שאר הצוותים. הם משתמשים בפרויקט האדמין של Terraform למשאבים שלהם. מאגר התשתית עצמו נמצא בפרויקט האדמין של Terraform, וגם בקובצי המצב של Terraform (כפי שמוסבר בהמשך). המשאבים האלה נוצרים על ידי סקריפט bash במהלך תהליך האתחול (פרטים נוספים זמינים במודול 0 – תהליך עבודה של אדמין).
2. network – מייצג את צוות הרשתות. הם אחראים על משאבי ה-VPC והרשתות. הוא הבעלים של משאבי GCP הבאים.
3. host project – מייצג את הפרויקט המארח של ה-VPC המשותף.
4. shared VPC – מייצג את ה-VPC המשותף, את רשתות המשנה, טווחי IP משניים, מסלולים וכללי חומת אש.
5. ops – מייצג את צוות התפעול/devops. הוא הבעלים של המשאבים הבאים.
6. ops project – מייצג פרויקט לכל משאבי התפעול.
7. gke clusters – אשכול GKE של פעולות לכל אזור. מישור הבקרה של Istio מותקן בכל אחד מאשכולות GKE של הפעולות.
8. k8s-repo – מאגר CSR שמכיל מניפסטים של GKE לכל אשכולות GKE.
9. apps – מייצג את צוותי האפליקציות. בסדנה הזאת אנחנו מדמות שני צוותים – app1 ו-app2. הוא הבעלים של המשאבים הבאים.
10. app projects – כל צוות אפליקציה מקבל פרויקטים משלו. כך הם יוכלו לשלוט בחיוב וב-IAM בפרויקט הספציפי שלהם.
11. gke clusters – אלה אשכולות של אפליקציות שבהם פועלים הקונטיינרים או ה-Pods של האפליקציות.
12. gce instances - באופן אופציונלי, אם יש להם אפליקציות שרצות על מכונות של GCE. בסדנה הזו יש ל-app1 כמה מופעי GCE שבהם חלק מהאפליקציה פועל.

בסדנה הזו, אותה אפליקציה (Hipster store app) מייצגת גם את 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 בפרויקט, צריך לדעת את מזהה הפרויקט. הפלט של מזהה הפרויקט מתבצע באמצעות פלט.tf לקובץ ה-tfstate שניתן להשתמש בו דרך מקור נתונים terraform_remote_state במשאב אשכול GKE.

קובץ shared_state הוא מקור נתונים של terraform_remote_state שמצביע אל קובץ tfstate של משאב. יש קובץ shared_state_[resource_name].tf (או קבצים) בתיקיות המשאבים שמחייבות פלט ממשאבים אחרים. לדוגמה, בתיקיית המשאבים ops_gke יש קובצי shared_state מהמשאבים של ops_project ומ-shared_vpc, כי צריך את מזהה הפרויקט ופרטי ה-VPC כדי ליצור אשכולות GKE בפרויקט התפעול. קובצי shared_state נוצרים מתבנית (שנמצאת ב-templates/shared_state.tf_tmpl) באמצעות סקריפט (שנמצא ב-scripts/setup_terraform_admin_project). של כל המשאבים קובצי shared_state ממוקמים בתיקייה gcp/[environment]/shared_states. קובצי shared_state הנדרשים מקושרים בתיקיות המשאבים המתאימות. כדי לנהל בקלות את כל קובצי המצב במקום אחד, מציבים את כל קובצי shared_state בתיקייה אחת ומקשרים אותם לתיקיות המשאבים המתאימות.

משתנים

כל ערכי המשאבים מאוחסנים כמשתני סביבה. המשתנים האלה מאוחסנים (כהצהרות ייצוא) בקובץ בשם vars.sh שנמצא בקטגוריה של GCS בפרויקט האדמין מסוג terraform. הנתונים האלה כוללים מזהה ארגון, חשבון לחיוב, מזהי פרויקטים, פרטים של אשכול GKE וכו'. אפשר להוריד את vars.sh מכל טרמינל ולאתר אותו כדי לקבל את הערכים להגדרה.

המשתנים של Terraform מאוחסנים בקובץ vars.sh בתור TF_VAR_[variable name]. המשתנים האלה משמשים ליצירת קובץ variables.tfvars בתיקיית המשאבים המתאימה. הקובץ variables.tfvars מכיל את כל המשתנים עם הערכים שלהם. הקובץ variables.tfvars נוצר מקובץ תבנית שנמצא באותה תיקייה באמצעות סקריפט (שנמצא ב-scripts/setup_terraform_admin_project).

הסבר על מאגר K8s

k8s_repo הוא מאגר CSR (בנפרד ממאגר התשתית) שנמצא בפרויקט האדמין של Terraform. הוא משמש לאחסון וליישום של מניפסטים של GKE בכל אשכולות GKE. k8s_repo נוצר על ידי התשתית של Cloud Build (פרטים נוספים זמינים בקטע הקודם). במהלך התשתית הראשונית של Cloud Build, נוצרים שישה אשכולות GKE. בתיקייה k8s_repo נוצרות שש תיקיות. כל תיקייה (שם שתואם לשם של אשכול GKE) תואמת לאשכול GKE שמכיל את קובצי המניפסט של המשאבים הרלוונטיים. בדומה לתשתית של בנייה, Cloud Build משמש להחלת המניפסטים של Kubernetes על כל אשכולות GKE שמשתמשים ב-k8s_repo. Cloud Build יופעל בכל פעם שיש התחייבות למאגר k8s_repo. בדומה לתשתית, כל המניפסטים של Kubernetes מאוחסנים כקוד במאגר k8s_repo והמצב של כל אשכול GKE מאוחסן תמיד בתיקייה המתאימה.

במסגרת ה-build הראשוני של התשתית, k8s_repo נוצר ו-Istio מותקן בכל האשכולות.

פרויקטים, אשכולות GKE ומרחבי שמות

המשאבים בסדנה הזו מחולקים לפרויקטים שונים של GCP. הפרויקטים צריכים להתאים למבנה הארגוני (או הצוותי) של החברה שלכם. צוותים (בארגון) שאחראים על פרויקטים, מוצרים או משאבים שונים משתמשים בפרויקטים שונים של GCP. פרויקטים נפרדים מאפשרים ליצור קבוצות נפרדות של הרשאות ב-IAM ולנהל את החיוב ברמת הפרויקט. בנוסף, המכסות מנוהלות גם ברמת הפרויקט.

בסדנה הזאת מיוצגים חמישה צוותים, ולכל אחד מהם יש פרויקט משלו.

1. צוות התשתית שיוצר את משאבי GCP משתמש בTerraform admin project. הם מנהלים את התשתית כקוד במאגר CSR (שנקרא infrastructure) ומאחסנים את כל המידע על מצב Terraform שקשור למשאבים המובנים ב-GCP בקטגוריות GCS. הם שולטים בגישה למאגר ה-CSR ולקטגוריות GCS של מצב Terraform.
2. צוות הרשת שבונה את ה-VPC המשותף משתמש ב-host project. הפרויקט הזה מכיל את ה-VPC, רשתות המשנה, הנתיבים וכללי חומת האש. כשיש להם VPC משותף, הם יכולים לנהל בצורה מרוכזת את הרשתות של משאבי GCP. כל הפרויקטים השתמשו ב-VPC המשותף היחיד הזה לרשתות.
3. צוות התפעול/הפלטפורמה שיוצר אשכולות GKE ורמות בקרה של ASM/Istio משתמשים ב-ops project. הם מנהלים את מחזור החיים של אשכולות GKE ו-Service mesh. הם אחראים להקשיחת האשכולות, וניהול החוסן וההתאמה של פלטפורמת Kubernetes. בסדנה הזאת תשתמשו בשיטת gitops לפריסת משאבים ב-Kubernetes. קיים מאגר CSR (שנקרא k8s_repo) בפרויקט התפעול.
4. לבסוף, צוותי dev1 ו-dev2 (מייצגים שני צוותי פיתוח) שבונים אפליקציות משתמשים ב-dev1 וב-dev2 projects משלהם. אלה האפליקציות והשירותים שאתם מספקים ללקוחות שלכם. האירועים האלה מבוססים על הפלטפורמה שצוות התפעול מנהל. המשאבים (פריסות, שירותים וכו') מועברים בדחיפה אל k8s_repo ונפרסים באשכולות המתאימים. חשוב לציין שהסדנה לא מתמקדת בשיטות מומלצות ובכלים של CI/CD. תשתמשו ב-Cloud Build כדי לבצע פריסה אוטומטית של משאבי Kubernetes באשכולות GKE. בתרחישים של ייצור בעולם האמיתי, צריך להשתמש בפתרון CI/CD מתאים כדי לפרוס אפליקציות באשכולות GKE.

בסדנה הזו יש שני סוגים של אשכולות GKE.

1. אשכולות תפעול – משמשים את צוות התפעול להרצת כלי devops. בסדנה הזאת הם מפעילים את מישור הבקרה ASM/Istio לניהול רשת השירות (Service mesh).
2. אשכולות אפליקציות (אפליקציות) – משמשים את צוותי הפיתוח להרצת אפליקציות. בסדנה הזו נעשה שימוש באפליקציית החנות של ההיפסטר.

הפרדה בין כלי תפעול או ניהול לבין האשכולות שמפעילים את האפליקציה מאפשרת לנהל את מחזור החיים של כל משאב בנפרד. שני סוגי האשכולות קיימים גם בפרויקטים שונים הקשורים לצוות/למוצר שמשתמש בהם, ולכן גם קל יותר לנהל את הרשאות IAM.

יש סה"כ 6 אשכולות GKE. בפרויקט התפעול נוצרים שני אשכולות פעולות אזוריים. מישור הבקרה ASM/Istio מותקן בשני אשכולות התפעול. כל אשכול פעולות נמצא באזור אחר. בנוסף, יש ארבעה אשכולות של אפליקציות של תחום מוגדר. הם נוצרים בפרויקטים משלהם. בסדנה הזו אנחנו מדמות שני צוותי פיתוח שלכל אחד מהם יש פרויקטים משלו. כל פרויקט מכיל שני אשכולות אפליקציות. אשכולות אפליקציות הם אשכולות של תחום מוגדר בתחומים שונים. ארבעת אשכולות האפליקציות ממוקמים בשני אזורים ובארבעה אזורים. כך אפשר לקבל יתירות אזורית ואזורית.

האפליקציה שבה נעשה שימוש בסדנה הזאת, אפליקציית Histert Shop, פרוסה בכל ארבעת אשכולות האפליקציות. כל מיקרו-שירות (microservice) נמצא במרחב שמות משלו בכל אשכול של אפליקציות. פריסות של אפליקציות חנות היפסטר (Pods) לא פרוסות באשכולות התפעול. עם זאת, מרחבי השמות ומשאבי השירות של כל המיקרו-שירותים נוצרים גם באשכולות הפעולות. מישור הבקרה ASM/Istio משתמש במרשם השירות של Kubernetes לצורך גילוי שירותים. בהיעדר שירותים (באשכולות התפעול), יהיה עליך ליצור באופן ידני ServiceEntries לכל שירות שפועל באשכול האפליקציות.

בסדנה הזו פרסתם אפליקציית מיקרו-שירותים (microservices) ב-10 רמות. האפליקציה היא אפליקציית מסחר אלקטרוני מבוססת-אינטרנט בשם ' Hipster Shop" שבו המשתמשים יכולים לעיין בפריטים, להוסיף אותם לעגלת הקניות ולקנות אותם.

מניפסטים של Kubernetes ו-k8s_repo

צריך להשתמש ב-k8s_repo כדי להוסיף משאבי Kubernetes לכל אשכולות GKE. כדי לעשות זאת, מעתיקים מניפסטים של Kubernetes ומתחייבים ל-k8s_repo. כל ההתחייבויות ל-k8s_repo יפעילו משימה של Cloud Build שפורסת את המניפסטים של Kubernetes לאשכול המתאים. המניפסט של כל אשכול נמצא בתיקייה נפרדת ששמה זהה לשם האשכול.

שמות האשכולות הם:

1. gke-asm-1-r1-prod – אשכול התפעול האזורי באזור 1
2. gke-asm-2-r2-prod – אשכול הפעולות האזורי באזור 2
3. gke-1-apps-r1a-prod – אשכול האפליקציות באזור 1 zone a
4. gke-2-apps-r1b-prod – אשכול האפליקציות באזור 1 תחום b
5. gke-3-apps-r2a-prod – אשכול האפליקציות באזור 2 תחום a
6. gke-4-apps-r2b-prod – אשכול האפליקציות באזור 2 תחום b

ב-k8s_repo יש תיקיות שתואמות לאשכולות האלה. כל מניפסט שמוצב בתיקיות האלה מוחל על אשכול GKE התואם. מניפסטים של כל אשכול נמצאים בתיקיות משנה (בתוך התיקייה הראשית של האשכול) כדי להקל על הניהול. בסדנה הזאת תשתמשו ב-Kustomize כדי לעקוב אחרי המשאבים שנפרסו. לפרטים נוספים, ניתן לעיין במסמכים הרשמיים של Kustomize.

7. פריסת האפליקציה לדוגמה

המטרה: לפרוס אפליקציית חנות ההיפסטר באשכולות אפליקציות

• שכפול של k8s-repo
• העתקת מניפסטים של חנות היפסטרים לכל אשכולות האפליקציות
• יצירת שירותים לאפליקציית חנות ההיפסטר באשכולות התפעול
• הגדרה של loadgenerators באשכולות התפעול כדי לבדוק את הקישוריות הגלובלית
• יש לאמת את הקישוריות המאובטחת לאפליקציית החנות של להיפסטר

תסריט הטראק המהיר

אם תבחרו בשיטה הזו, תריצו את הסקריפט הבא כדי לסיים את שיעור ה-Lab הזה.

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

הוראות להעתקה והדבקה של שיטת ה-Labs

אם כבר השלמתם את הסקריפט של המסלול המהיר לשיעור ה-Lab הזה, אל תבצעו את שיטת ההעתקה וההדבקה שבהמשך**.**

שכפול מאגר המקור של פרויקט התפעול

כחלק מתהליך ה-build הראשוני של התשתית של Terraform, המסמך k8s-repo כבר נוצר בפרויקט התפעול.

1. יצירת ספרייה ריקה למאגר git:

mkdir $WORKDIR/k8s-repo
 

2. הפעלת מאגר git, הוספת שלט רחוק ושליפת מאסטר מהמאגר המרוחק:

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

3. קביעת ההגדרות האישיות של Git מקומי.

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

העתקת מניפסטים, שמירה ודחיפה

4. מעתיקים את מרחבי השמות והשירותים של Histers 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 Deployments, RBAC ו-PodSecurityPolicy למאגר המקור של אשכולות האפליקציות.

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

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

7. יש להסיר את פריסת שירות העגלה, rbac ו-podsecuritypolicy מכל אשכול הפיתוח (dev) אחד. חברת Backstershop לא נבנתה לפריסה מרובת אשכולות, ולכן כדי למנוע חוסר עקביות בתוצאות, אנחנו משתמשים בשירות עגלה אחד בלבד.

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. צריך להוסיף את פריסת Carservice, 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. מעתיקים את המשאבים של Config Connector לאחד מהאשכולות בכל פרויקט.

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

13. מחליפים את PROJECT_ID במניפסטים של Config Connector.

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

14. העתקת מניפסטים של loadgenerator (Deployment, PodSecurityPolicy ו-RBAC) לאשכולות הפעולות. אפליקציית החנות של ביניהן נחשפת באמצעות מאזן עומסים גלובלי של 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. צריך לוודא שה-Pods במרחב השמות של עגלות הקניות נמצאים במצב 'פועל' באשכול dev הראשון בלבד.

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

Output (do not copy)

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

גישה לאפליקציית Hipster Shop

איזון עומסים גלובלי

עכשיו יש לך אפליקציית Himpster Shop פרוסה בכל ארבעת אשכולות האפליקציות. האשכולות האלה נמצאים בשני אזורים ובארבעה תחומים. לקוחות יכולים לגשת לאפליקציית החנות של להיפסטר באמצעות גישה לשירות frontend. השירות frontend פועל בכל ארבעת אשכולות האפליקציות. מאזן עומסים של Google Cloud ( GCLB) משמש לקבלת תעבורת נתונים של לקוחות לכל ארבעת המכונות של שירות frontend.

שערי Istio Ingress פועלים רק באשכולות הפעולות ומשמשים כמאזן עומסים אזורי לשני אשכולות האפליקציות האזוריים באזור. ב-GCLB נעשה שימוש בשני שערי תעבורת הנתונים הנכנסת (ingress) של Istio (פועלים בשני אשכולות הפעולות) כקצוות עורפיים לשירות הקצה הגלובלי. שערי Istio Ingress מקבלים את תעבורת הנתונים של הלקוח מה-GCLB ולאחר מכן שולחים את תנועת הלקוח הלאה ל-Pods של הקצה הקדמי שפועלים באשכולות של האפליקציות.

לחלופין, אפשר לשים שערים של Istio Ingress ישירות באשכולות של האפליקציות, ו-GCLB יכול להשתמש בהם בתור קצוות עורפיים.

בקר Autoneg של GKE

שער Istio Ingress Kubernetes Service רושם את עצמו כקצה עורפי ל-GCLB באמצעות קבוצות של נקודות קצה של רשת (NEG). אובייקטים מסוג NEG מאפשרים לבצע איזון עומסים שמקורם בקונטיינר באמצעות GCLB. את ה-NEG יוצרים באמצעות הערה מיוחדת בשירות Kubernetes, כדי שהם יוכלו לרשום את עצמם לבקרת ה-NEG. בקר Autoneg הוא בקר מיוחד ב-GKE שהופך את היצירה של מפתחות NEG באופן אוטומטי וגם מקצה אותם כקצוות עורפיים ל-GCLB באמצעות הערות שירות. מישורי הבקרה של Istio, כולל שערי תעבורת הנתונים הנכנסת (ingress) של Istio, נפרסו במהלך התשתית הראשונית של Terraform Cloud Build. הגדרות ה-GCLB וה-autoneg מתבצעות כחלק מהתשתית הראשונית של Terraform Cloud Build.

אבטחת תעבורת נתונים נכנסת (ingress) באמצעות Cloud Endpoints ואישורים מנוהלים

אישורי GCP מנוהלים משמשים לאבטחת תנועת הלקוח לשירות GCLB frontend. ב-GCLB נעשה שימוש באישורים מנוהלים לשירות frontend הגלובלי, והאישור מסתיים ב-GCLB. בסדנה הזאת תשתמשו ב-Cloud Endpoints בתור הדומיין של האישור המנוהל. לחלופין, אפשר להשתמש בדומיין ובשם ה-DNS של frontend כדי ליצור אישורים מנוהלים ב-GCP.

21. כדי לגשת לחנות ההיפסטר, יש ללחוץ על פלט הקישור של הפקודה הבאה.

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

22. כדי לבדוק שהאישור תקף, לוחצים על סמל המנעול בסרגל כתובות ה-URL בכרטיסייה של Chrome.

אימות איזון עומסים גלובלי

במסגרת פריסת האפליקציה, מחוללי עומסים נפרסו בשני אשכולות התפעול שיוצרים תעבורת נתונים לבדיקה לקישור של GCLB ליהנות מ-Cloud Endpoints ב-Cloud Endpoints. יש לוודא ש-GCLB מקבל תנועה ושולח אותו לשני שערי Istio Ingress.

23. להורדת GCLB > קישור למעקב אחרי פרויקט התפעול שבו נוצר GCLB של חנות ההיפסטר.

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

24. משנים את כל הקצוות העורפיים ל-istio-ingressgateway מהתפריט הנפתח של הקצה העורפי כפי שמוצג בהמשך.

25. חשוב לשים לב לתנועה שמגיעה אל istio-ingressgateways.

לכל istio-ingressgateway נוצרים 3 מפתחות NEG. מכיוון שאשכולות התפעול הם אשכולות אזוריים, ולכן נוצר NEG אחד לכל תחום באזור. עם זאת, ה-Pods של istio-ingressgateway פועלים בתחום יחיד לכל אזור. התנועה מוצגת מעבר ל-Pods של istio-ingressgateway.

מחוללי עומסים פועלים בשני אשכולות הפעולות. הם מדמות תנועת לקוחות משני האזורים שבהם הם נמצאים. העומס שנוצר באזור 1 של אשכול התפעול נשלח אל istio-ingressgateway באזור 2. באופן דומה, העומס שנוצר באזור 2 של אשכול התפעול נשלח אל istio-ingressgateway באזור 2.

8. ניראות (observability) באמצעות Stackdriver

המטרה: לחבר את נתוני הטלמטריה של Istio ל-Stackdriver ולאמת.

• התקנת istio-telemetry משאבים
• יצירה/עדכון של מרכזי בקרה של Istio Services
• צפייה ביומני מאגרים
• הצגת מעקב מבוזר ב-Stackdriver

תסריט הטראק המהיר

אם תבחרו בשיטה הזו, תריצו את הסקריפט הבא כדי לסיים את שיעור ה-Lab הזה.

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

הוראות להעתקה והדבקה של שיטת ה-Labs

אם כבר השלמתם את הסקריפט של המסלול המהיר לשיעור ה-Lab הזה, אל תבצעו את שיטת ההעתקה וההדבקה שבהמשך**.**

אחת התכונות העיקריות של Istio היא ניראות (observability) מובנית ("o11y"). פירוש הדבר הוא שגם בקונטיינרים ללא אינסטלציה, המפעילים עדיין יכולים לעקוב אחר התנועה שמגיעה אל הקונטיינרים האלה ויוצאת מהם, ולספק שירותים ללקוחות. התצפית הזו מתבטאת בכמה שיטות שונות: מדדים, יומנים ועקבות.

בנוסף, נשתמש במערכת המובנית ליצירת עומסים ב-Hifster Shop. ניראות (observability) לא פועלת טוב במערכת סטטית ללא תנועה, ולכן יצירת העומסים עוזרת לנו לראות איך הוא עובד. הטעינה הזו כבר פועלת, עכשיו נוכל רק לראות אותה.

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.

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

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

בפלט אמור להופיע handler בשםStackdriver:

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

5. מוודאים שייצוא מדדי Istio ל-Stackdriver פועל. לוחצים על פלט הקישור מהפקודה הזו:

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

תוצג בקשה ליצור סביבת Workspace חדשה, שנקראת על שם פרויקט Ops. צריך רק ללחוץ על 'אישור'. אם מוצגת בקשה לגבי ממשק המשתמש החדש, פשוט סוגרים את תיבת הדו-שיח.

ב-Metrics Explorer, בקטע 'חיפוש סוג ומדד של משאב' מקלידים 'istio'. כדי לראות שיש אפשרויות כמו 'ספירת בקשות של שרת' בקונטיינר Kubernetes סוג המשאב. הפעולה הזו מראה שהמדדים עוברים מהרשת אל Stackdriver.

(כדי לראות את השורות שלמטה, צריך לסמן את התווית 'קיבוץ לפי' destination_service_name.)

המחשה חזותית של מדדים באמצעות מרכזי בקרה:

עכשיו, כשהמדדים שלנו נמצאים במערכת Stackdriver APM, אנחנו רוצים שתהיה לנו דרך להציג אותם באופן חזותי. בקטע זה נתקין מרכז בקרה מוכן מראש שבו יוצגו שלושה מתוך ארבעת אותות זהב" מתוך המדדים: תנועה (בקשות לשנייה), זמן אחזור (במקרה הזה, האחוזון ה-99 וה-50) ושגיאות (בדוגמה הזו אנחנו לא כוללים רוויה).

שרת ה-Proxy ל-Envoy של Istio מספק לנו כמה מדדים, אבל כדאי להתחיל איתם. (רשימה מקיפה מופיעה כאן). חשוב לזכור שלכל מדד יש קבוצה של תוויות שאפשר להשתמש בהן לסינון, לצבירת נתונים, כמו: destination_service, source_workload_namespace, Response_code, istio_tcp_received_bytes_total וכו').

6. עכשיו נוסיף את מרכז הבקרה של המדדים המוגדרים מראש. אנחנו נשתמש ישירות ב-Dashboard API. הפעולה הזו לא מתבצעת בדרך כלל על ידי יצירה ידנית של קריאות 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"
 
 

נוכל לערוך את מרכז הבקרה במקומו בעזרת חוויית המשתמש, אבל במקרה שלנו נוסיף במהירות תרשים חדש באמצעות ה-API. לשם כך, עליך למשוך למטה את הגרסה האחרונה של מרכז הבקרה, להחיל את שינויי העריכה ולאחר מכן לדחוף אותה חזרה כלפי מעלה באמצעות שיטת HTTP PATCH.

8. כדי לקבל לוח בקרה קיים אפשר לשלוח שאילתות על ה-API למעקב. עכשיו אתם יכולים לקבל את מרכז הבקרה הקיים שנוסף:

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

9. הוספת תרשים חדש: (זמן אחזור 50 של %ile): [ הפניה ל-API] עכשיו אנחנו יכולים להוסיף ווידג'ט תרשים חדש למרכז הבקרה שלנו בקוד. אפליקציות להשוואה יכולות לבדוק את השינוי הזה ולבצע צ'ק-אין לניהול הגרסאות. הנה ווידג'ט להוספה שמציג זמן אחזור של 50% (זמן אחזור חציוני).

כדאי לנסות לערוך את מרכז הבקרה שקיבלת ולהוסיף בית חדש:

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

10. מעדכנים את מרכז הבקרה הקיים של השירותים:

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

11. כדי לצפות במרכז הבקרה המעודכן, צריך לעבור לקישור הבא לפלט:

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

12. לבצע כמה פעולות פשוטות של ניתוח יומנים.

Istio מספק קבוצה של יומנים מובנים לכל תעבורת הנתונים ברשת בתוך הרשת, ומעלה אותם ל-Stackdriver 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, בוחרים באפשרות Resource (משאב) > Kubernetes Container וחיפוש ב-'pilot' –

כאן ניתן לראות את הגדרות ה-Proxy של Istio Control Plane ל-Proxy ל-Sidecar לכל שירות אפליקציה לדוגמה. "CDS", "LDS," ו-"RDS" לייצג ממשקי API שונים של Envoy ( מידע נוסף).

מעבר ליומנים של Istio, תוכלו גם למצוא יומני קונטיינרים ותשתית ויומנים של שירותי GCP אחרים – והכול באותו הממשק. לפניכם כמה שאילתות על יומנים לדוגמה ל-GKE. מציג היומנים מאפשר גם ליצור מדדים מיומנים (למשל: "ספירת כל שגיאה שתואמת למחרוזת מסוימת"), ולשימוש בהם במרכז הבקרה או כחלק מהתראה. אפשר גם להעביר את היומנים לכלי ניתוח אחרים כמו BigQuery.

כמה פילטרים לדוגמה לחנות היפסטרים:

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

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

13. כדאי לקרוא את רשימת המעקבים המופצים.

עכשיו, כשאתם עובדים עם מערכת מבוזרת, אתם זקוקים לכלי חדש לניפוי באגים: מעקב מבוזר. הכלי הזה מאפשר לכם לגלות נתונים סטטיסטיים על האינטראקציה בין השירותים שלכם (למשל, אירועים איטיים יוצאי דופן בתמונה למטה), וגם להתעמק בעקבות גולמיים שונים כדי לחקור את הפרטים האמיתיים של הבעיה.

בתצוגת ציר הזמן אפשר לראות את כל הבקשות לאורך זמן, בגרף לפי זמן האחזור או משך הזמן שחולף בין הבקשה הראשונית, דרך מקבץ ההיפסטר, כדי להגיב בסופו של דבר למשתמש הקצה. ככל שהנקודות גבוהות יותר, כך חוויית המשתמש איטית יותר (ופחות מרוצה!).

אפשר ללחוץ על נקודה כדי לראות את תצוגת ה-Waterfall המפורטת של הבקשה הספציפית הזו. היכולת למצוא את הפרטים הגולמיים של בקשה מסוימת (ולא רק נתונים סטטיסטיים מצטברים) היא חיונית להבנת ההשפעה ההדדית בין שירותים, במיוחד כשרוצים לאתר אינטראקציות נדירות אבל רעות בין שירותים.

תצוגת ה-Waterfall צריכה להיות מוכרת לכל מי שהשתמש בכלי לניפוי באגים, אבל במקרה הזה לא מוצג הזמן שבו הוקדש זמן לתהליכים שונים באפליקציה אחת, מוצג זמן המעבר ברשת שלנו בין שירותים, הרצה בקונטיינרים נפרדים.

כאן תוכלו למצוא את נתוני המעקב:

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

צילום מסך לדוגמה של הכלי:

9. אימות TLS הדדי

המטרה: קישוריות מאובטחת בין מיקרו-שירותים (AuthN).

• הפעלה של mTLS לרוחב ברשת
• אימות mTLS על ידי בדיקת היומנים

תסריט הטראק המהיר

אם תבחרו בשיטה הזו, תריצו את הסקריפט הבא כדי לסיים את שיעור ה-Lab הזה.

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

הוראות להעתקה והדבקה של שיטת ה-Labs

אם כבר השלמתם את הסקריפט של המסלול המהיר לשיעור ה-Lab הזה, אל תבצעו את שיטת ההעתקה וההדבקה שבהמשך**.**

אחרי שהאפליקציות שלנו מותקנות והגדרת הניראות (observability), אנחנו יכולים להתחיל לאבטח את החיבורים בין השירותים ולוודא שהם ימשיכו לפעול.

למשל, במרכז הבקרה ב-Kiali אפשר לראות שהשירותים שלנו לא משתמשים ב-MTLS (בלי סמל נעילה). אבל התנועה זורמת והמערכת פועלת כמו שצריך. מרכז הבקרה שלנו למדדי הזהב של StackDriver מאפשר לנו להיות רגועים שהכול עובד כמו שצריך, באופן כללי.

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 בכל האשכולות על ידי עדכון ה-CR של IstioControlPlane ועדכון המאגר של k8s. הגדרה גלובלית > mTLS > enabled: true ב-IstioControlPlane CR יובילו לשני השינויים הבאים במישור הבקרה של Istio:

• MeshPolicy מוגדרת להפעיל רשת mTLS לרוחב עבור כל השירותים שפועלים בכל האשכולות.
• DestinationRule נוצר כדי לאפשר תעבורת ISTIO_MUTUAL בין שירותים שפועלים בכל האשכולות.

2. נחיל תיקון קוסומיזציה על התגובה המוכנה מראש istioControlPlane כדי להפעיל בכל אשכול mTLS. מעתיקים את התיקון ל-dir רלוונטי לכל האשכולות ומוסיפים תיקון קוסמטי.

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.

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

תסריט הטראק המהיר

אם תבחרו בשיטה הזו, תריצו את הסקריפט הבא כדי לסיים את שיעור ה-Lab הזה.

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

הוראות להעתקה והדבקה של שיטת ה-Labs

אם כבר השלמתם את הסקריפט של המסלול המהיר לשיעור ה-Lab הזה, אל תבצעו את שיטת ההעתקה וההדבקה שבהמשך**.**

פריסה של גרסה ראשונית היא השקה הדרגתית של שירות חדש. בפריסה של גרסה חדשה, שולחים כמות הולכת וגדלה של תנועה לגרסה החדשה, ועדיין שולחים את האחוזים הנותרים לגרסה הנוכחית. דפוס נפוץ הוא ביצוע ניתוח קנוני בכל שלב של פיצול התנועה, ולהשוות את "האותות המוזהבים". של הגרסה החדשה (זמן אחזור, שיעור שגיאות, רוויה) לעומת ערך הבסיס. זה עוזר למנוע הפסקות זמניות בשירות ולהבטיח את היציבות של גרסה 2 החדשה בכל שלב של פיצול התנועה.

בחלק הזה נסביר איך להשתמש במדיניות בנושא תעבורת הנתונים של Cloud Build ו-Istio כדי ליצור פריסה בסיסית של גרסה ראשונית (canary) לגרסה חדשה של שירות הקצה הקדמי.

קודם כל נפעיל את צינור עיבוד הנתונים של Canary באזור DEV1 (us-west1) ונשיק את גרסה 2 של הקצה הקדמי בשני האשכולות באזור הזה. לאחר מכן, נפעיל את צינור עיבוד הנתונים של Canary באזור DEV2 (us-central) ונפרס את v2 בשני האשכולות באותו אזור. הפעלה של צינור עיבוד הנתונים באזורים לפי סדר מסוים, לעומת במקביל בכל האזורים, עוזרת למנוע הפסקות זמניות בשירות גלובליות שנגרמות בגלל הגדרות לא נכונות או כתוצאה מבאגים באפליקציית גרסה 2 עצמה.

הערה: אנחנו נפעיל באופן ידני את צינור עיבוד הנתונים של Canary בשני האזורים, אבל בסביבת הייצור תצטרכו להשתמש בטריגר אוטומטי, למשל, על סמך תג תמונה חדש של Docker שהועבר למרשם.

1. מגדירים משתני env ב-Cloud Shell כדי להריץ את שאר הפקודות בקלות רבה יותר.

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

2. מריצים את הסקריפט repo_setup.sh כדי להעתיק את המניפסטים הבסיסיים למאגר k8s-repo.

$CANARY_DIR/repo-setup.sh 
 

המניפסטים הבאים מועתקים:

• פריסת Front-v2
• תיקון frontend-v1 (כדי לכלול את התווית 'v1' ותמונה עם נקודת הקצה '/version')
• respy, רצף קטן שידפיס הפצת תגובת HTTP, ויעזור לנו להמחיש את הפריסה של גרסה ראשונית (canary) בזמן אמת.
• Frontend Istio DestinationRule – מפצלת את שירות Kubernetes הקדמי לשתי קבוצות משנה, v1 ו-v2, לפי ה"גרסה" תווית פריסה
• Frontend Istio VirtualService – מנתב 100% מהתנועה ל-Frontend v1. הפעולה הזו מבטלת את התנהגות ברירת המחדל של שירות 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 יסתיים, ואז לקבל Pods במרחב השמות של הקצה הקדמי בשני אשכולות DEV1. אתם אמורים לראות את הנתונים הבאים:

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

Output (do not copy)

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

הערה: כדי לצאת מפקודות השעון, צריך להקיש על Ctrl-C

אנחנו נשתמש ב-tmux כדי לפצל את החלון של Cloudshell ל-2 חלוניות:

• החלונית התחתונה תריץ את פקודת השעון כדי לצפות בהתפלגות של תגובת ה-HTTP לשירות הקצה הקדמי.
• החלונית העליונה תפעיל את הסקריפט של צינור עיבוד הנתונים הקנוני עצמו.

6. מריצים את הפקודה כדי לפצל את החלון של ה-Cloud Shell, ולהריץ את פקודת השעון בחלונית התחתונה.

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

פלט (ללא העתקה)

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

אפשר לראות שכל התנועה מגיעה לפריסת גרסה 1 של הקצה הקדמי, שמוגדרת ב-VirtualService החדש.

7. להפעיל את צינור עיבוד הנתונים הקנוני באזור Dev1. אנחנו מספקים סקריפט שמעדכן את אחוזי התנועה של Front-v2 ב-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. לאחר השלמת ההשקה של גרסה 2.0 של Frontend-v2, אמורה להופיע הודעת הצלחה בסוף הסקריפט:

    Output (do not copy) 
   

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

9. וכל התנועה בחזית מ-Pod של Dev2 צריכה לעבור ל-Front-v2:

    Output (do not copy) 
   

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

10. סוגרים את החלונית המפוצלת.

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

11. בקישור שנוצר, עוברים אל Cloud Source Repos.

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

אתם אמורים לראות התחייבות נפרדת לכל אחוז תנועה. ההתחייבות האחרונה ביותר מופיעה בראש הרשימה:

עכשיו חוזרים על אותו תהליך גם באזור הפיתוח 2. חשוב לשים לב שאזור Dev2 עדיין 'נעול'. בגרסה 1. הסיבה לכך היא שבסקריפט הבסיס של repo_setup, דחינו VirtualService כדי לשלוח באופן מפורש את כל התנועה אל v1. כך יכולנו ליצור גרסה אזורית בטוחה של גרסה Dev1, ולוודא שהיא פועלת בהצלחה לפני ההשקה של הגרסה החדשה ברחבי העולם.

12. מריצים את הפקודה כדי לפצל את החלון של ה-Cloud Shell, ולהריץ את פקודת השעון בחלונית התחתונה.

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

פלט (ללא העתקה)

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

אפשר לראות שכל התנועה מגיעה לפריסת גרסה 1 של הקצה הקדמי, שמוגדרת ב-VirtualService החדש.

13. להפעיל את צינור עיבוד הנתונים הקנוני באזור Dev2. אנחנו מספקים סקריפט שמעדכן את אחוזי התנועה של Front-v2 ב-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 שזזות בהדרגה מ-Frontend v1 לגרסה 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, באמצעות טריגר כמו תמונה מתויגת חדשה שנדחפת למרשם קונטיינרים. כדאי גם להוסיף ניתוח של גרסה קנונית בין כל שלב, כדי לנתח את זמן האחזור של גרסה 2 ושיעור השגיאות לפי סף בטיחות מוגדר מראש, לפני ששולחים עוד תנועה.

11. מדיניות ההרשאות

המטרה: להגדיר RBAC בין מיקרו-שירותים (AuthZ).

• כדי להגדיר גישת DENY למיקרו-שירות (microservice) של AuthorizationPolicy
• יצירת AuthorizationPolicy כדי לאפשר גישה ספציפית למיקרו-שירות (microservice)

תסריט הטראק המהיר

אם תבחרו בשיטה הזו, תריצו את הסקריפט הבא כדי לסיים את שיעור ה-Lab הזה.

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

הוראות להעתקה והדבקה של שיטת ה-Labs

אם כבר השלמתם את הסקריפט של המסלול המהיר לשיעור ה-Lab הזה, אל תבצעו את שיטת ההעתקה וההדבקה שבהמשך**.**

בניגוד לאפליקציה מונוליתית שעשויה לפעול במקום אחד, אפליקציות מיקרו-שירותים שמופצות באופן גלובלי מבצעות קריאות מעבר לגבולות הרשת. המשמעות היא שתקבלו יותר נקודות כניסה לאפליקציות שלכם והזדמנויות רבות יותר להתקפות זדוניות. בגלל שלקבוצות Pod של Kubernetes יש כתובות IP זמניות, כללי חומת אש מסורתיים שמבוססים על IP כבר לא מתאימים לאבטחת גישה בין עומסי עבודה. בארכיטקטורת מיקרו-שירותים (microservices), נדרשת גישה חדשה לאבטחה. Istio מתבסס על אבני בניין של אבטחה ב-Kubernetes, כמו חשבונות שירות, ומספק קבוצה גמישה של כללי מדיניות אבטחה לאפליקציות שלכם.

כללי המדיניות של Istio חלים גם על אימות וגם על הרשאות. אימות מאמת את הזהות (האם השרת הזה כתוב שהוא?), והרשאה מאמתת את ההרשאות (האם הלקוח הזה מורשה לעשות זאת?). הסברנו על אימות Istio בקטע TLS הדדי במודול 1 (MeshPolicy). בחלק הזה נסביר איך להשתמש במדיניות ההרשאות של Istio כדי לשלוט בגישה לאחד מעומסי העבודה של האפליקציות שלנו, currencyservice.

קודם כול, נפרוס AuthorizationPolicy בכל ארבעת אשכולות הפיתוח, נסגור את כל הגישה לשירות המטבעות ונפעיל שגיאה בקצה הקדמי. אחר כך נאפשר רק לשירות הקדמי לגשת לשירות המטבע.

1. יש לבדוק את התוכן של currency-deny-all.yaml. המדיניות הזו משתמשת בבוררים של תוויות פריסה כדי להגביל את הגישה לשירות המטבע. שימו לב איך אין השדה spec – המשמעות היא שהמדיניות הזו תדחה כל גישה לשירות שנבחר.

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

פלט (ללא העתקה)

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

2. מעתיקים את מדיניות המטבע למאגר k8s-il, לאשכולות הפעולות בשני האזורים.

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. אחרי שה-build מסתיים בהצלחה, אפשר לנסות להגיע לחזית ההיפסטרופ בדפדפן דרך הקישור הבא:

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

אמורה להופיע שגיאת הרשאה מ-currencyservice:

6. עכשיו נבדוק איך שירות המטבע אוכף את AuthorizationPolicy הזה. קודם כול, מפעילים יומנים ברמת המעקב בשרת ה-proxy של 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 (ההרשאה) משרת proxy של שירות המטבעות. אמורה להופיע הודעת השגיאה 'האכיפה נדחתה'. שמציינת ששירות המטבע מוגדר לחסום את כל הבקשות הנכנסות.

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

פלט (ללא העתקה)

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

8. עכשיו נאפשר לקצה הקדמי – אבל לא לשירותים האחרים לקצה העורפי – לגשת לשירות המטבע. צריך לפתוח את currency-allow-frontend.yaml ולבדוק את התוכן שלו. שימו לב שהוספנו את הכלל הבא:

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

פלט (ללא העתקה)

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

כאן אנחנו מוסיפים רשימת היתרים של source.principal (לקוח) ספציפי כדי לאפשר גישה לשירות המטבע. source.principal מוגדר על ידי Kubernetes Service Account. במקרה הזה, חשבון השירות שאנחנו מוסיפים לרשימת ההיתרים הוא חשבון השירות של הקצה הקדמי במרחב השמות של הקצה הקדמי.

הערה: כשמשתמשים בחשבונות שירות של Kubernetes ב-Istio AuthorizationPolicy, קודם צריך להפעיל 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. אחרי שה-build מסתיים, פותחים שוב את החזית של Histershop. הפעם לא אמורות להופיע שגיאות בדף הבית, הסיבה לכך היא שלממשק הקצה יש הרשאה מפורשת לגשת לשירות הנוכחי.
13. עכשיו עליך לנסות לבצע תהליך תשלום על ידי הוספת פריטים לעגלת הקניות ולחיצה על 'ביצוע הזמנה'. הפעם אמורה להופיע שגיאה בהמרת מחיר משירות המטבעות – הסיבה לכך היא שהוספת לרשימת ההיתרים רק את החזית, ולכן לשירות התשלום עדיין אין גישה לשירות המטבע.

14. לסיום, נאפשר לשירות התשלום לגשת למטבע על ידי הוספת כלל ל-AuthorizationPolicy של שירות המטבעות. לתשומת ליבכם: אנחנו פותחים את האפשרות הזו רק לשני השירותים שצריכים גישה למטבעות האלה – ממשק קצה ותשלום. הקצוות העורפיים האחרים עדיין ייחסמו.
15. צריך לפתוח את currency-allow-frontend-checkout.yaml ולבדוק את התוכן שלו. שימו לב שרשימת הכללים פועלת באופן לוגי OR - currency יקבל רק בקשות מעומסי עבודה עם אחד משני חשבונות השירות האלה.

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.

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. לאחר סיום ה-build, נסו לבצע תשלום – הוא אמור לפעול בהצלחה.

בחלק הזה מוסבר איך להשתמש במדיניות ההרשאה של Istio כדי לאכוף בקרת גישה מפורטת ברמת השירות לכל שירות. בסביבת ייצור, אפשר ליצור AuthorizationPolicy אחד לכל שירות, וכן (למשל) להשתמש במדיניות הרשאה-הכול כדי לאפשר לכל עומסי העבודה באותו מרחב שמות לגשת זה לזה.

12. התאמת התשתית של התשתית

המטרה: התאמת גודל התשתית על ידי הוספת אזור, פרויקט ואשכולות חדשים.

• שכפול המאגר infrastructure
• מעדכנים את קובצי ה-terraform כדי ליצור משאבים חדשים.
• שתי רשתות משנה באזור החדש (אחת לפרויקט התפעול ואחת לפרויקט החדש)
• אשכול פעולות חדש באזור חדש (ברשת המשנה החדשה)
• מטוס בקרה חדש של Istio לאזור החדש
• שני אשכולות של אפליקציות בפרויקט החדש באזור החדש
• התחייבות למאגר infrastructure
• אימות התקנה

תסריט הטראק המהיר

אם תבחרו בשיטה הזו, תריצו את הסקריפט הבא כדי לסיים את שיעור ה-Lab הזה.

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

הוראות להעתקה והדבקה של שיטת ה-Labs

אם כבר השלמתם את הסקריפט של המסלול המהיר לשיעור ה-Lab הזה, אל תבצעו את שיטת ההעתקה וההדבקה שבהמשך**.**

יש כמה דרכים להתאים את הפלטפורמה. ניתן להוסיף עוד מחשוב על ידי הוספת צמתים לאשכולות קיימים. אפשר להוסיף עוד אשכולות באזור מסוים. אפשר גם להוסיף אזורים לפלטפורמה. ההחלטה איזה היבט של הפלטפורמה להרחיב תלוי בדרישות. לדוגמה, אם יש לכם אשכולות בכל שלושת התחומים באזור מסוים, אולי תספיקו להוסיף עוד צמתים (או מאגרי צמתים) לאשכול קיים. עם זאת, אם יש לכם אשכולות בשני אזורים באזור אחד, אז הוספת אשכול חדש באזור השלישי מאפשרת התאמה לעומס (scaling) ודומיין שגיאה נוסף (כלומר תחום חדש). עוד סיבה להוספת אשכול חדש באזור יכולה להיות הצורך ליצור אשכול דיירים יחיד – מסיבות של רגולציה או תאימות (לדוגמה, PCI או אשכול מסדי נתונים שמכיל פרטים אישיים מזהים). ככל שהעסק והשירותים שלכם מתרחבים, הוספת אזורים חדשים הופכת לבלתי נמנעת כדי לספק שירותים קרובים יותר ללקוחות.

הפלטפורמה הנוכחית מורכבת משני אזורים ואשכולות בשני תחומים לכל אזור. אפשר לחשוב על התאמת הפלטפורמה בשתי דרכים:

• אנכית – בתוך כל אזור, באמצעות הוספת מחשוב. ניתן לעשות זאת על ידי הוספת עוד צמתים (או מאגרי צמתים) לאשכולות קיימים או על ידי הוספה של אשכולות חדשים בתוך האזור. הפעולה הזו מתבצעת דרך המאגר infrastructure. הנתיב הפשוט ביותר הוא הוספת צמתים לאשכולות קיימים. אין צורך בהגדרות נוספות. הוספת אשכולות חדשים עשויה לחייב רשתות משנה נוספות (וטווחים משניים), הוספת כללי חומת אש מתאימים, הוספת האשכולות החדשים למישור הבקרה האזורי ASM/Istio של Service mesh ופריסת משאבי אפליקציות לאשכולות החדשים.
• לרוחב – על ידי הוספת אזורים נוספים. בפלטפורמה הנוכחית אתם מקבלים תבנית אזורית. הוא מורכב מאשכול פעולות אזורי שבו נמצא פקד ASM/Istio ומשני אשכולות אפליקציות אזוריים (או יותר) שבהם פרוסים משאבי אפליקציות.

בסדנה הזאת תשתמשו בפלטפורמה "אופקי" כי הוא כולל גם את שלבי התרחיש לדוגמה האנכי. כדי לבצע את ההתאמות בקנה מידה אופקי של הפלטפורמה על ידי הוספת אזור חדש (r3) לפלטפורמה, צריך להוסיף את המשאבים הבאים:

1. רשתות משנה ב-VPC המשותף בפרויקט המארח באזור r3 עבור הפעולות ואשכולות האפליקציות החדשים.
2. אשכול פעולות אזורי באזור r3 שבו נמצא מטוס הבקרה ASM/Istio.
3. שני אשכולות של אפליקציות של תחום מוגדר בשני אזורים באזור r3.
4. עדכון למאגר k8s:
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, אפשר ללחוץ על הפלט של הקישור הבא ולעבור ל-build האחרון שנמצא למעלה.

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

השלמת השלב הזה נמשכת 25-30 דקות. זה זמן טוב להפסקת קפה.

בשלב האחרון של infrastructure Cloud Build נוצרים משאבי Kubernetes חדשים ב-k8s-repo. הפעולה הזו תפעיל את Cloud Build ב-k8s-repo (בפרויקט התפעול). המשאבים החדשים ב-Kubernetes מיועדים לשלושת האשכולות החדשים שנוספו בשלב הקודם. משאבים ברמת הבקרה של ASM/Istio ומשאבים ברמת הבקרה משותפים מתווספים לאשכולות החדשים באמצעות Cloud Build k8s-repo.

8. בסיום יצירת התשתית ב-Cloud Build, תוכלו ללחוץ על קישור הפלט הבא כדי לעבור לגרסה האחרונה של Cloud Build ל-k8s-repo.

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 מותקן באשכול הפעולות החדש, צריך לבדוק שכל ה-Pods פועלים ושהמשימות הסתיימו.

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

Fast Track Script Lab – זמין בקרוב!

הוראות להעתקה והדבקה של שיטת ה-Labs

עכשיו, אחרי שלמדנו כמה אסטרטגיות בסיסיות למעקב ולפתרון בעיות בשירותים שתומכים ב-Istio, בואו נראה איך Istio עוזר לכם לשפר את העמידות של השירותים שלכם ולהפחית את כמות פתרון הבעיות שתצטרכו לבצע מלכתחילה.

ארכיטקטורת מיקרו-שירותים (microservices) גורמת לסיכון לכשלים מדורגים, שבהם כשל בשירות אחד יכול לעבור ליחסי התלות שלו, וליחסי התלות של יחסי התלות האלה, וכך ליצור 'אפקט אדים'. הפסקה זמנית בשירות שעלולה להשפיע על משתמשי הקצה. Istio מספקת מדיניות בנושא 'מפסק זרם' כדי לעזור לכם לבודד שירותים, להגן על שירותים במורד הזרם (בצד הלקוח) מפני המתנה לשירותים שנכשלו ולהגן על שירותים ב-upstream (בצד השרת) מפני שיטפון פתאומי של תנועה במורד הזרם כשהם חוזרים לאינטרנט. באופן כללי, אם תשתמשו במפסקי זרם, כל השירותים שלכם לא ייכשלו ביעדי ה-SLO בגלל בעיה של שירות לקצה העורפי.

לדפוס של מפסק הזרם יש שם של מתג חשמלי שיכול "לגלוש" כאשר יותר מדי חשמל עובר דרכם, תוך הגנה על המכשירים מפני עומס יתר. בהגדרה של Istio, המשמעות היא ש-Envoy הוא מפסק הזרם שמאפשר לעקוב אחר מספר הבקשות שבהמתנה לשירות. במצב סגור כברירת מחדל, הבקשות עוברות דרך Envoy ללא הפסקות.

עם זאת, כשמספר הבקשות הממתינות חורג מהסף המוגדר, מפסק הזרם (נפתח) ומוצג הודעת שגיאה באופן מיידי. זה מאפשר לשרת להיכשל במהירות עבור הלקוח, ומונעת מהקוד של אפליקציית השרת לקבל את הבקשה של הלקוח בזמן עומס יתר.

לאחר מכן, אחרי הזמן הקצוב לתפוגה שהגדרתם, Envoy עובר למצב פתוח למחצה שבו השרת יכול לקבל שוב בקשות באופן זמני. אם הוא יכול להגיב לבקשות, מפסק הזרם ייסגר שוב והבקשות לשרת יתחילו לזרום שוב.

התרשים הזה מסכם את דפוס מפסק הזרם של Istio. המלבנים הכחולים מייצגים את Envoy, העיגול המלא בכחול מייצג את הלקוח, והעיגולים הלבנים מייצגים את מאגר השרת:

אפשר להגדיר כללי מדיניות של מפסק זרם באמצעות Istio DestinationRules. בקטע הזה נחיל את המדיניות הבאה כדי לאכוף מפסק הזרם בשירות המשלוחים:

Output (do not copy)

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

יש שני שדות של כלל יעד (DestinationRule) שצריך לציין כאן. ההגדרה connectionPool מגדירה את מספר החיבורים שהשירות יאפשר. השדה 'outlierDetection' הוא המקום שבו אנחנו מגדירים את האופן שבו Envoy יקבע את הסף שבו ייפתח מפסק הזרם. כאן, בכל שנייה (מרווח זמן), Envoy יספור את מספר השגיאות שהתקבלו ממאגר התגים בצד השרת. אם הוא יחרוג מהסף של consecutiveErrors, מפסק הזרם של Envoy ייפתח, ו-100% מרצפי המוצרים יהיו מוגנים למשך 10 שניות מפני בקשות לקוח חדשות. ברגע שמפסק הזרם של Envoy פתוח (כלומר פעיל), הלקוחות יקבלו שגיאות 503 (שירות לא זמין). נראה את זה בפעולה.

1. הגדרה של משתני סביבה למאגר k8s ול-asm dir כדי לפשט את הפקודות.

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

2. עדכון המאגר של k8s

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

3. מעדכנים את DestinationRule של שירות המשלוחים בשני אשכולות התפעול.

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

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

4. העתקת Pod של מחולל עומסים של 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. ממתינים להשלמת התהליך ב-Cloud Build.
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
 

בקטע הזה מוסבר איך להגדיר מדיניות בנושא מפסק יחיד לשירות. השיטה המומלצת היא להגדיר מפסק זרם לכל שירות ב-upstream (קצה עורפי) שעלול להיתקע. החלת מדיניות של מפסק הזרם ב-Istio עוזרת לבודד את מיקרו-שירותים (microservices) בארכיטקטורה שלכם, ולצמצם את הסיכון לכשלים מדורגים בעומס גבוה.

14. החדרת תקלה

המטרה: לבדוק את העמידות של שירות ההמלצות על ידי הצגת עיכובים (לפני שהוא עובר לסביבת הייצור).

• יצירת VirtualService לשירות recommendation כדי להציג עיכוב של 5 שניות
• בדיקת העיכוב באמצעות מחולל העומסים fortio
• צריך להסיר את ההשהיה בVirtualService ולאמת

הוראות ל-Fast Track Script Lab

Fast Track Script Lab – זמין בקרוב!

הוראות להעתקה והדבקה של שיטת ה-Labs

הוספת כללי מדיניות של מפסקי זרם לשירותים היא אחת הדרכים לבנות עמידות בפני שירותים בסביבת הייצור. עם זאת, שבירת זרם יכולה להיות בעייתית. מדובר בתקלות – שעלולות להיות שגיאות שגלויות למשתמשים. כדי להתכונן למקרי השגיאה האלה ולחזות טוב יותר איך השירותים שלכם ב-downstream עשויים להגיב כאשר קצוות עורפיים מחזירים שגיאות, אפשר לבצע בדיקת כאוס בסביבת Staging. בדיקת כאוס היא שיטה שבמסגרתה מופסקים השירותים באופן מכוון, כדי לנתח נקודות חלשות במערכת ולשפר את הסבלנות לתקלות. תוכלו גם להשתמש בבדיקת כאוס כדי לזהות דרכים לצמצום שגיאות המוצגות למשתמשים כאשר קצוות עורפיים נכשלים – למשל, על ידי הצגת תוצאה שנשמרה במטמון בממשק קצה.

השימוש ב-Istio להחדרת תקלות יכול לעזור כי אפשר להשתמש בתמונות של גרסאות הייצור ולהוסיף את הטעות בשכבת הרשת, במקום לשנות את קוד המקור. בסביבת הייצור, אפשר להשתמש בכלי לבדיקת כאוס מלא כדי לבדוק עמידות בשכבת Kubernetes/compute, בנוסף לשכבת הרשת.

אפשר להשתמש ב-Istio לביצוע בדיקות כאוס על ידי החלת VirtualService עם ה-"fault" השדה הזה. Istio תומך בשני סוגים של תקלות: שגיאות השהיה (החדרת זמן קצוב לתפוגה) ושגיאות ביטול (החדרת שגיאות HTTP). בדוגמה הזו נוסיף פגם מסוג עיכוב של 5 שניות אל שירות ההמלצות. אבל הפעם, במקום להשתמש במפסק זרם כדי 'להתכשל' כנגד השירות התלוי הזה, נאלץ את שירותי ה-downstream לעמוד בקצב של כל הזמן הקצוב לתפוגה.

11. עוברים אל הספרייה 'החדרת תקלות'.

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

12. כדי לבדוק את התוכן, צריך לפתוח את k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml. שימו לב שב-Istio יש אפשרות להזריק את השגיאה לאחוז מהבקשות. כאן נוסיף זמן קצוב לתפוגה בכל הבקשות של שירות ההמלצות.

פלט (ללא העתקה)

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

13. מעתיקים את VirtualService לתוך k8s_repo. אנחנו נוסיף את התקלה בכל העולם, בשני האזורים.

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

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

14. שינויים בדחיפה

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

15. ממתינים להשלמת התהליך ב-Cloud Build.
16. נכנסים לשקע בפורטו שנפרס בקטע של מפסק הזרם, ושולחים חלק מהתנועה לשירות ההמלצות.

FORTIO_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. ביצוע ניוד של שירות Grafana שמותקן באמצעות Istio

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

21. פותחים את Grafana בדפדפן
22. לוחצים על 'תצוגה מקדימה של האתר' בפינה הימנית העליונה של החלון של Cloud Shell.
23. לוחצים על 'תצוגה מקדימה' ביציאה 3000 (הערה: אם היציאה היא לא 3000, יש ללחוץ על 'שינוי היציאה' ולבחור ביציאה 3000)
24. הפעולה הזו תפתח כרטיסייה בדפדפן עם כתובת URL שדומה ל-" BASE_URL/?orgId=1&authuser=0&environment_id=default"
25. הצגת מרכזי הבקרה הזמינים
26. לשנות את כתובת ה-URL ל-" BASE_URL/dashboard"
27. לוחצים על 'istio' תיקייה להצגה של מרכזי בקרה זמינים
28. אפשר ללחוץ על כל אחד ממרכזי הבקרה האלה כדי להציג את הביצועים של הרכיב. בקטעים הבאים נבחן את המדדים החשובים לכל רכיב.

טייס מעקב

הפיילוט הוא הרכיב במישור הבקרה שמפיץ את ההגדרות הרישות והמדיניות למישור הנתונים (שרתי ה-proxy של Envoy). תוכנית הפיילוט נוטה להתאים את כמות עומסי העבודה והפריסות, אבל לא בהכרח ביחס לנפח תעבורת הנתונים של עומסי העבודה האלה. טייס לא בריא עלול:

• צורכים יותר משאבים מהנדרש (מעבד (CPU) או RAM)
• התוצאה תהיה עיכובים בהעברת פרטי ההגדרות המעודכנים ל-Envoys

הערה: אם תוכנית הפיילוט מושבתת או אם יש עיכובים, עומסי העבודה עדיין מגישים תנועה.

23. ניווט אל " BASE_URL/dashboard/db/istio-pilot-dashboard" בדפדפן כדי לראות את מדדי הפיילוט.

מדדים חשובים במעקב

שימוש במשאבים

מספרי השימוש הקבילים בדף הזה מפורטים בדף Istio Performance and Scalability (ביצועים ומדרגיות). אם רואים שימוש ממושך יותר במשאבים בהשוואה לערך הזה, יש לפנות לתמיכה של GCP.

מידע על דחיפת תוכנית הפיילוט

הקטע הזה עוקב אחרי דחיפת התצורה של תוכניות פיילוט לשרת ה-proxy שלכם ב-Envoy.

• בכרטיס דחיפת פיילוט מוצג סוג ההגדרות שנדחפו בכל זמן נתון.
• במעקב אחר מודעות מוצג מספר השירותים הווירטואליים, השירותים ונקודות הקצה המחוברות במערכת.
• באשכולות ללא נקודות קצה ידועות מוצגות נקודות קצה שהוגדרו אבל לא פועלות בהן מכונות (המצב הזה יכול להעיד על שירותים חיצוניים, כמו *.googleapis.com).
• בקטע שגיאות בתוכנית הפיילוט מוצג מספר השגיאות שאירעו לאורך זמן.
• מחלוקות מייצגות את מספר ההתנגשויות בין הגדרות לא חד-משמעיות לגבי המאזינים.

אם יש שגיאות או התנגשויות, אחד או יותר מהשירותים שלכם כוללים תצורה שגויה או לא עקבית. לקבלת מידע, ראו פתרון בעיות במישור הנתונים.

מידע על Envoy

המקטע הזה מכיל מידע על שרתי proxy של Envoy שיוצרים קשר עם מישור הבקרה. במקרה של כשלים חוזרים בחיבור XDS, יש לפנות לתמיכה של GCP.

מיקסר מוניטור

מיקסר הוא הרכיב שמנתב את נתוני הטלמטריה משרתי Envoy לקצוות העורפיים של טלמטריה (בדרך כלל Prometheus, Stackdriver וכו'). בתפקיד הזה, הוא לא במישור הנתונים. היא פרוסה כשתי משימות Kubernetes (שנקראות Superer) שנפרסו עם שני שמות שירות שונים (istio-telemetry ו-istio-policy).

אפשר להשתמש במיקסר גם כדי לשלב מערכות שקשורות למדיניות. בתפקיד הזה, מיקסר כן משפיע על מישור הנתונים, כי בדיקות המדיניות של המיקסר נכשלות וחוסמות את הגישה לשירותים שלכם.

מיקסר בדרך כלל בקנה מידה גדול עם נפח התנועה.

24. ניווט אל " BASE_URL/dashboard/db/istio-mixer-dashboard" בדפדפן כדי להציג מדדי מיקסר.

מדדים חשובים במעקב

שימוש במשאבים

מספרי השימוש הקבילים בדף הזה מפורטים בדף Istio Performance and Scalability (ביצועים ומדרגיות). אם רואים שימוש ממושך יותר במשאבים בהשוואה לערך הזה, יש לפנות לתמיכה של GCP.

סקירה כללית של Mixer

• משך התגובה הוא מדד חשוב. דיווחים לטלמטריה של מיקסר לא נמצאים בנתיב הנתונים, אבל אם זמני האחזור גבוהים, זה בהחלט מאט את הביצועים של שרת proxy משני. האחוזון ה-90 אמור להופיע באלפיות השנייה, והאחוזון ה-99 אמור להיות פחות מ-100 אלפיות השנייה.

• משך השליחה של מתאם מציין שמערבל זמן האחזור חווה מתאמים לקריאות (כך הוא שולח מידע למערכות טלמטריה ורישום ביומן). זמן אחזור גבוה כאן ישפיע באופן מוחלט על הביצועים ברשת. שוב, זמן האחזור של p90 צריך להיות פחות מ-10 אלפיות השנייה.

מעקב אחר גליל

Galley הוא הרכיב של Istio לאימות הגדרות, להטמעת נתונים, לעיבוד ולהפצה. היא מעבירה את התצורה משרת API של Kubernetes אל הפיילוט. כמו תוכנית הפיילוט, היא נוטה להתאים להיקף הפרסום בהתאם למספר השירותים ונקודות הקצה במערכת.

25. ניווט אל " BASE_URL/dashboard/db/istio-galley-dashboard" בדפדפן כדי להציג מדדים של Galley.

מדדים חשובים במעקב

אימות משאבים

המדד החשוב ביותר שצריך לעקוב אחריו מציין את מספר המשאבים מהסוגים השונים, כמו כללי יעד, שערים ורשומות של שירותים שעוברים את האימות או נכשלים בו.

לקוחות מקושרים

מציין כמה לקוחות מחוברים ל-Galley; בדרך כלל יהיה זה 3 (פיילוט, istio-טלמטריה, istio-policy), והגודל שלו ישתנה בהתאם לקנה המידה של הרכיבים האלה.

16. פתרון בעיות ב-Istio

פתרון בעיות במישור הנתונים

אם לוח הבקרה של הפיילוט מצביע על בעיות בתצורה, עליכם לבדוק את יומני הפיילוט או להשתמש ב-istioctl כדי לאתר בעיות בהגדרה.

כדי לבדוק יומני פיילוט, מריצים את יומני kubectl -n istio-system istio-pilot-69db46c598-45m44, ומחליפים את istio-pilot-... במזהה pod של מכונת הפיילוט שרוצים לפתור בעיות בקשר אליה.

ביומן שיתקבל, מחפשים הודעת Push Status. לדוגמה:

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

סטטוס הדחיפה יציין בעיות שהתרחשו במהלך הניסיון לדחוף את התצורה לשרתי Envoy. במקרה הזה, יש כמה "אשכול כפול". הודעות, שמציינות יעדים כפולים ב-upstream.

לקבלת עזרה באבחון בעיות, אפשר לפנות לתמיכה של Google Cloud בכל בעיה.

איתור שגיאות הגדרה

כדי להשתמש ב-istioctl לניתוח ההגדרה, מריצים את istioctl experimental analyze -k --context $OPS_GKE_1. הפעולה הזו תבצע ניתוח של ההגדרות במערכת, ותציין בעיות כלשהן, בנוסף לשינויים המוצעים. במסמכי התיעוד אפשר למצוא רשימה מלאה של שגיאות הגדרה שהפקודה הזו יכולה לזהות.

17. הסרת המשאבים

בסיום הסדנה, האדמין מבצע את השלבים הבאים.

אדמין מריץ את הסקריפט cleanup_workshop.sh כדי למחוק משאבים שנוצרו על ידי הסקריפט bootrap_workshop.sh. כדי להפעיל את סקריפט הניקוי, נדרשים הפרטים הבאים.

• שם הארגון – לדוגמה yourcompany.com
• מזהה סדנה – בפורמט YYMMDD-NN לדוגמה 200131-01
• קטגוריית Admin GCS - מוגדרת בסקריפט אתחול.

13. פותחים את Cloud Shell ומבצעים את כל הפעולות הבאות ב-Cloud Shell. אפשר ללחוץ על הקישור שלמטה.

Cloud Shell

14. ודאו שנכנסתם ל-gcloud עם משתמש האדמין המיועד.

gcloud config list
 

15. מנווטים לתיקייה ב-asm.

cd ${WORKDIR}/asm
 

16. מגדירים את שם הארגון ואת מזהה הסדנה שרוצים למחוק.

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

17. מריצים את הסקריפט לניקוי הנתונים באופן הבא.

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