מעבר מ-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, לוחצים על configure (הגדרה) ואם מופיעה בקשה, בוחרים את הפרויקט מהרשימה. בדף הבא יוצג טופס עם כמה ערכי ברירת מחדל. מוודאים שהאשכול שנבחר הוא זה שיצרנו הרגע ולוחצים על 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 שלנו, יחד עם בקשות ל-persistent volume שנדרשות כדי לטעון את הדיסקים שהועתקו למאגר של שרת האינטרנט שלנו. אנחנו יכולים להחיל את השינויים האלה באמצעות kubectl:

kubectl apply -f containerized-webserver.yaml

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

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

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

בתצוגת עומסי העבודה, מרחיבים את 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 (ניצול המעבד). בתיבה '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 החיצונית של מאזן העומסים בתור שם המארח.

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

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

נקרא לה'מדיניות זמינות של נקודות קצה'. בקטע Configuration (הגדרה), מגדירים את האפשרות Condition triggers if (התנאי מופעל אם) ל-Any time series violates (כל סדרת זמן חורגת) ולוחצים על save (שמירה).

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

לוחצים על הוספת ערוץ התראות. לבסוף, בחלק התחתון של הטופס, נותנים למדיניות את השם Web App Uptime (זמן פעולה של אפליקציית אינטרנט) ולוחצים על Save (שמירה).

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

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

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