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

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

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

מה תלמדו

• איך פורסים את Migrate for Anthos באשכול Kubernetes
• איך יוצרים קונטיינר ב-StatefulSet ממכונה קיימת של 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, שאליו נעביר בסופו של דבר את שרת האינטרנט של Compute Engine. ב-Cloud Console, מריצים את הפקודה הבאה:

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: Migrate for Anthos

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

‫Migrate for Anthos אמור להיות פרוס עכשיו באשכול Kubernetes. כשהפריסה תסתיים, הסטטוס 'OK' יופיע ב דף האפליקציות של Kubernetes Engine:

4. ממופע חישוב ל-StatefulSet

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

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 שנוצר יקצה stateful set באשכול Kubernetes שלנו, יחד עם בקשות לכרכים מתמשכים שנדרשות כדי לטעון את הדיסקים שהועתקו למאגר של שרת האינטרנט שלנו. אנחנו יכולים להחיל את השינויים האלה באמצעות kubectl:

kubectl apply -f containerized-webserver.yaml

בודקים את הסטטוס של webserver-statefulset בדף Workloads (עומסי עבודה):

עומסי עבודה ב-Kubernetes

אחרי שמריצים את הפקודה kubectl apply, סטטוס ההמתנה של ה-Pod-ים הוא תקין למשך כמה דקות. אחרי שהסטטוס יהיה '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 החיצונית של שירות webserver-container:

kubectl get services

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

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

6. Stackdriver monitoring

מדדים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לוחצים על יצירת מדיניות התראות.

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

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

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

כדי לראות איך ייראה התראה, פותחים שוב את 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

מרכז הבקרה

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

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

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

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

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

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

Disks

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

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