מעבר מ-Compute Engine ל-Kubernetes Engine באמצעות Migrate for Anthos

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

אין תמיד אפשרות לשכתב או לתכנן מחדש אפליקציות קיימות כדי שיעבדו ב-Kubernetes, או שאפשר לעשות זאת באופן ידני. העברה ל-Anthos יכולה לעזור לכם לחדש את האפליקציות הקיימות שלכם ולהריץ אותן ב-Kubernetes. בשיעור ה-Codelab הזה, תתבצע העברה של אפליקציית אינטרנט קיימת שמתארחת ב-Compute Engine אל Kubernetes Engine באמצעות Migrate for Anthos.

מה תלמדו

• איך לפרוס Migrate for Anthos באשכול Kubernetes
• איך יוצרים קונטיינר בקבוצה עם שמירת מצב ממכונה קיימת של Compute Engine
• איך לפרוס את הקונטיינר ב-Kubernetes ולהגדיר אותו באמצעות מאזן עומסים

מה צריך להכין

• יצירת פרויקט ב-Google Cloud שמוגדר בו חיוב. אם אין לכם חשבון, תצטרכו ליצור חשבון.

הערה: הפתרונות שנפרסו ב-Codelab הזה יגרמו לפעילויות שניתנות לחיוב. התמחור של Google Compute Engine מופיע כאן. משתמשים חדשים ב-Google Cloud Platform זכאים לתקופת ניסיון בחינם עם קרדיט בסך 300 $.

2. בתהליך ההגדרה

ה-Codelab הזה יכול לפעול באופן מלא ב-Google Cloud Platform ללא התקנה או הגדרות מקומיות.

הפעלת ממשקי API

לפני שמתחילים, חשוב להפעיל את ממשקי ה-API הנדרשים בפרויקט שלכם ב-Google Cloud:

הפעלת Compute Engine API הפעלת Kubernetes Engine API

יצירת שרת אינטרנט של מכונות Compute

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

הפעלת Cloud Shell

ב-Cloud Shell, מריצים את הפקודה הבאה:

gcloud compute instances create webserver --zone=us-central1-a && \
gcloud compute firewall-rules create default-allow-http --allow=tcp:80 

החלק הראשון של הפקודה הזו ייצור מכונה של Google Cloud באזור us-central1-a, ואילו במחצית השנייה ייווצר כלל חומת אש בשם 'default-allow-http'. שתאפשר תנועת http לרשת שלנו.

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

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

אחרי שהמכונה מתחילה לפעול, אפשר להיכנס באמצעות SSH למכונה מ-Cloud Shell כדי להתקין את הפקודה nginx ולהפעיל את שרת האינטרנט:

gcloud compute ssh --zone us-central1-a webserver

אחרי ההתחברות למכונת המחשוב שלנו, מתקינים את nginx:

sudo apt install nginx

התנתקות מסשן ssh באמצעות הפקודה logout

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

שרת האינטרנט הזה ישמש כאפליקציית האינטרנט מהדור הקודם שיועבר ל-Kubernetes באמצעות Migrate for Anthos.

3. אשכול Kubernetes עם Migrate for Anthos

בשלב הבא ניצור אשכול GKE, שאליו נעביר בסופו של דבר את שרת האינטרנט של מנוע המחשוב. במסוף Cloud, מריצים את הפקודה הבאה:

gcloud container clusters create my-gke-cluster \
  --zone us-central1-a \
  --cluster-version 1.13 \
  --machine-type n1-standard-4 \
  --image-type "UBUNTU" \
  --num-nodes 1 \
  --enable-stackdriver-kubernetes

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

לאחר מכן, עליכם לנווט ל-GCP Marketplace כדי לפרוס Migrate for Anthos:

Market Place: העברה ל-Anthos

בדף Marketplace של Migrate for Anthos, לוחצים על Set [הגדרה], ואם מופיעה בקשה, בוחרים את הפרויקט מהרשימה. בדף ההמשך יוצג טופס עם כמה ערכי ברירת מחדל. מוודאים שהאשכול שנבחר הוא זה שיצרנו הרגע ולוחצים על Deploy (פריסה):

עכשיו אמורים לפרוס העברות ל-Anthos באשכול kubernetes. בסיום הפריסה, יוצג הסטטוס 'OK' (אישור) ב דף האפליקציות של Kubernetes Engine:

4. ממופע מחשוב לקבוצה עם שמירת מצב

יש לנו אשכול Kubernetes שמריץ את Migrate for Anthos, כך שעכשיו אנחנו יכולים להתחיל את תהליך ההעברה. כדי לפרוס את מכונת המחשוב באשכול של Kubenetes, נוציא משימוש את מכונת Compute Engine כדי שנוכל לצלם קובצי snapshot של הדיסקים. לפני שממשיכים, חשוב לשים לב למזהה המכונה, שנצטרך בהמשך:

gcloud compute instances describe webserver --zone us-central1-a | grep ^id

נשבית את מכונת המחשוב:

gcloud compute instances stop webserver --zone us-central1-a

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

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

python3 /google/migrate/anthos/gce-to-gke/clone_vm_disks.py \
  -p <project-id>   -i <instance-id> \
  -z us-central1-a \
  -T us-central1-a \
  -A webserver-statefulset \
  -o containerized-webserver.yaml

באמצעות הדגלים האלה, clone_vm_disks.py:

• איך לוודא שמופע ה-GCE מושבת
• יצירת קובץ snapshot מהדיסק של כל אחד מהדיסקים
• יצירת דיסק חדש מכל קובץ snapshot
• למחוק את תמונות המצב שנוצרו
• יצירת קובץ YAML בספריית העבודה הנוכחית לפריסת קבוצה עם שמירת מצב שתארח את שרת האינטרנט שלכם

קובץ ה-yaml שנוצר יקצה מצב מוגדר באשכול ה-kubernetes, יחד עם ההצהרות על נפח האחסון הקבוע שנדרשות כדי לטעון את הדיסקים שהועתקו למאגר של שרת האינטרנט שלנו. אפשר להחיל את השינויים האלה באמצעות kubectl:

kubectl apply -f containerized-webserver.yaml

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

עומסי עבודה (workload) של Kubernetes

הסטטוס 'Pods בהמתנה' הוא תופעה רגילה. למשך כמה דקות אחרי הרצת kubectl apply. ממשיכים כשהסטטוס יהיה 'OK' [אישור].

5. חשיפת האשכול למאזן עומסים

בשלב הזה, אשכול Kubenetes אמור להריץ את שרת האינטרנט שלנו כקבוצת שמירת מצב, אבל נצטרך גם לחשוף את המאגר שלו למאזן עומסים כדי לגשת לשרת האינטרנט שלנו דרך כתובת IP חיצונית. ב-Cloud Shell, יוצרים קובץ חדש בשם loadbalancer.yaml עם התוכן הבא:

loadbalancer.yaml

apiVersion: v1
kind: Service
metadata:
  name: webserver-loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: webserver-statefulset
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

ועכשיו מחילים אותה עם kubectl:

kubectl apply -f loadbalancer.yaml

אנחנו יכולים להשתמש ב-kubectl כדי לאחזר את כתובת ה-IP החיצונית של שירות הקונטיינר של שרת האינטרנט:

kubectl get services

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

עשינו זאת! שרת האינטרנט של GCE שלנו מתארח עכשיו ב-Kubernetes! איזה יופי!

6. מעקב אחרי Stackdriver

מדדים

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

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

טיפ: אפשר לגשת במהירות לפריט מתפריט המוצרים והשירותים על ידי הקשה על '/'. להקיש על המקש הזה ולהקליד את האפשרות בתפריט.

בסיום הטעינה, מעבירים את העכבר מעל Resources בחלונית השמאלית ובוחרים באפשרות 'Kubernetes Engine NEW' מהתפריט.

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

בתצוגה Workloads, מרחיבים את my-gke-cluster והתעמקות לברירת המחדל > webserver-statefulset > webserver-statefulset-0 > שרת אינטרנט-statefulset. לוחצים על מאגר התגים בסטטוס של שרת האינטרנט. כאן אפשר למצוא כמה מדדים חדשים לגמרי שתועדו על ידי Stackdriver, כולל ניצול הזיכרון וניצול המעבד (CPU).

התרשימים שמוצגים במרכז הבקרה הזה הם אלה שנוכל להשתמש בהם כדי ליצור מרכז בקרה מותאם אישית.

הערה: יכול להיות שיעבור קצת זמן עד שהנתונים ייאספו ב-Stackdriver.

מרכזי בקרה בהתאמה אישית

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

בחלונית שמשמאל, מעבירים את העכבר מעל 'לוחות בקרה' ולוחצים על 'יצירת מרכז בקרה'.

עכשיו, כשיש לנו מרכז בקרה ריק, אנחנו יכולים להוסיף מדדים שאנחנו רוצים לעקוב אחריהם. אנחנו נותנים למרכז הבקרה ללא שם שם שימושי, כמו 'My Web Server Containers' (מאגרי שרת האינטרנט שלי) ולוחצים על 'Add Chart'. בפינה הימנית העליונה:

זוכרים את המדדים הקיימים? עכשיו נוסיף תרשים לניצול המעבד (CPU) בקונטיינר. בשדה Chart Title, מזינים 'CPU Utilization'. בתיבה 'Find resource type and metric' (חיפוש סוג המשאב והמדד), מקלידים request_utilization ובוחרים באפשרות CPU request utilization מהרשימה המסוננת. הבחירה הזו תאכלס גם את השדה 'סוג המשאב' וגם את השדה 'מדד'.

בשלב הבא נרצה לסנן לפי project_id שלנו (אם יש לנו מספר פרויקטים) ו-Container_name. בתיבת הסינון מקלידים project_id, בוחרים אותו מהרשימה המסוננת ולאחר מכן בוחרים את הפרויקט בשדה 'ערך'. אנחנו צריכים גם לסנן לפיContainer_name. בתיבה 'מסנן', מקלידים container_name, בוחרים אותו מהרשימה המסוננת ובשדה 'ערך' בוחרים באפשרות webserver-statefulset. לוחצים על 'שמירה'.

יש לנו עכשיו לוח בקרה עם התרשים הראשון שלנו.

7. בדיקת זמני פעילות ומדיניות התראות

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

בחלונית הימנית, לוחצים על Uptime Checks ואז על Uptime Checks Overview (סקירה כללית של זמני פעילות):

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

בטופס ההמשך, מזינים 'Endpoint Uptime'. בתור הכותרת וכתובת ה-IP החיצונית של מאזן העומסים בתור שם המארח.

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

לוחצים על Create Alert Policy.

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

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

לוחצים על Add Notification Channe. לסיום, בחלק התחתון של הטופס, יש לתת למדיניות את השם 'זמן פעולה תקינה של אפליקציית אינטרנט' ולוחצים על 'שמירה'.

כדי לראות איך התראה תיראה, פותחים שוב את Cloud Shell במסוף Cloud. הפקודה הבאה תפסיק את שירות nginx שפועל ב-pod של שרת האינטרנט שלנו:

kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx -s stop"

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

בואו נבטל את זה. נחזור ל-Cloud Shell ונפעיל מחדש את nginx:

kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx"

לאחר כמה דקות תקבלו אימייל נוסף מ-Stackdriver, והפעם עם חדשות טובות יותר מבעבר:

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

עכשיו, לאחר המעבר מ-GCE ל-GKE עם Migrate for Anthos, בואו ננקה את הפרויקט שלנו מכל המשאבים שיצרנו.

מחיקת הפרויקט

אם אתם מעדיפים, תוכלו למחוק את הפרויקט כולו. במסוף GCP, נכנסים לדף Cloud Resource Manager:

Cloud Resource Manager

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

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

Stackdriver

מרכז הבקרה

בדף מרכז השליטה, לוחצים על סמל ההגדרות בחלק העליון של הדף ובוחרים מחיקת מרכז השליטה.

מדיניות התראות

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

בדיקת זמני פעילות

בדף Uptime Checks, בוחרים באפשרות Delete בתפריט הפעולות שמשמאל לכל בדיקה שיצרתם.

GCE ו-Kubernetes

מכונה של Google Compute Engine

gcloud compute instances delete webserver --zone=us-central1-a

אשכול Kubernetes (כולל Migrate for Anthos, Stateful set ושירות מאזן עומסים)

gcloud container clusters delete my-gke-cluster --zone=us-central1-a

דיסקים

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

gcloud compute disks list --filter=webserver

משתמשים בשם הדיסק במקום בדיסק שלי, ומוחקים אותו באמצעות:

gcloud compute disks delete vls-690d-webserver --zone=us-central1-a

הכול נקי!

9. מעולה!

כל הכבוד! העברתם את שרת האינטרנט ממכונת GCE לאשכול Kubernetes באמצעות Migrate for Anthos.

אילו נושאים דיברנו?

• העברנו שרת אינטרנט מ-GCE לאשכול Kubernetes באמצעות Migrate for Anthos
• פתחנו לעולם את שרת האינטרנט הקבוע שלנו בעל שמירת מצב באמצעות חשיפתו באמצעות שירות מאזן עומסים של Kubernetes.
• הפעלנו את Stackdriver ויצרנו מרכז בקרה בהתאמה אישית
• הגדרנו בדיקת זמני פעילות יחד עם מדיניות התראות כדי להודיע לנו כששרת האינטרנט שלנו מושבת