שיטות מומלצות לתכנון
במאמר הזה מפורטים טיפים להעברת אפליקציות אל Google Kubernetes Engine (GKE) או אל GKE Enterprise, על סמך העברות של אפליקציות אמיתיות שבוצעו באמצעות Migrate to Containers.
Migration Center discovery client CLI או mcdc CLI הוא כלי שמשמש לקביעת ההתאמה של עומס העבודה של מכונה וירטואלית להעברה לקונטיינר.
עומסי עבודה מומלצים
הכלי Migrate to Containers מומלץ לסוגים מסוימים של עומסי עבודה ב-Linux וב-Windows, שמפורטים בהמשך.
התאמה טובה
Linux
אפליקציות Linux שמתאימות להעברה באמצעות Migrate to Containers כוללות את הארכיטקטורות הבאות של אפליקציות:
- שרתי אינטרנט/אפליקציות
- תוכנת ביניים של לוגיקה עסקית (לדוגמה, Tomcat)
- מערכים מרובי מכונות וירטואליות ומרובי שכבות (לדוגמה, LAMP)
- מסדי נתונים קטנים או בינוניים (לדוגמה, MySQL ו-PostgreSQL)
בנוסף, האפליקציות שהכי מתאימות להעברה באמצעות Migrate to Containers הן בעלות המאפיינים התפעוליים הבאים:
- עומסי עבודה עם מחזור פעילות נמוך ופרצי פעילות
- סביבות מעבדה לפיתוח, לבדיקה ולאימון
- שירותים עם עומס נמוך שפועלים תמיד
באופן כללי, רוב עומסי העבודה של Linux תואמים להעברה, למעט עומסי העבודה שמפורטים בהמשך בקטע לא מתאים.
Windows
אפליקציות ל-Windows שמתאימות להעברה באמצעות Migrate to Containers כוללות עומסי עבודה שעומדים בכל המאפיינים הבאים:
- IIS 7 ואילך, ASP.NET עם .NET Framework 3.5 ואילך
- רמות של אינטרנט ולוגיקה
- WS2008 R2 ואילך
תמיכה במערכת הפעלה
הכלי Migrate to Containers תואם למערכות ההפעלה של מכונות וירטואליות הבאות.
לא מתאים
Linux
ב-Linux, אפליקציות ושרתים שלא מתאימים להעברה באמצעות Migrate to Containers כוללים:
- ביצועים גבוהים ומסדי נתונים גדולים בזיכרון
- מכונות וירטואליות עם דרייברים מיוחדים של ליבה (לדוגמה, NFS במצב ליבה)
- תלות בחומרה ספציפית
- תוכנה עם רישיונות שקשורים לרישום של מזהה חומרה מסוים
Windows
ב-Windows, עומסי עבודה שלא מותקן בהם IIS 7 ואילך לא מתאימים להעברה. סוגים אחרים של אפליקציות שלא מתאימות להעברה:
- אפליקציות עם יחסי תלות במעבדי GPU או TPU
- אפליקציות ברמת רשת נמוכה
- אפליקציות למחשב, RDP ו-VDI
- אפליקציות עם BYOL
כללי גישה לרשת ול-DNS
לפני שמעבירים ל-GKE, חשוב להבין את משאבי הרשת והשירותים שבהם נעשה שימוש בעומסי העבודה שהועברו, ולוודא שאפשר לגשת אליהם ולטפל בהם מהענן הווירטואלי הפרטי.
תכנון השמות של שירותי Kubernetes
אם עומסי העבודה שלכם מסתמכים על DNS כדי לגשת לשירותים, אתם צריכים לתכנן את סכימת מרחב השמות של Kubernetes, את מדיניות הרשת ואת שמות השירותים.
מפרט הפריסה שנוצר בתהליך ההעברה מכיל אובייקט Service מוצע ללא ראש מסוג ClusterIP. ClusterIP פירושו שאין איזון עומסים, וכתובת IP פנימית אחת של האשכול שאפשר להגיע אליה רק מתוך האשכול. הבקר של נקודות הקצה ב-Kubernetes משנה את הגדרת ה-DNS כדי להחזיר רשומות (כתובות) שמפנות אל ה-Pods, שמסומנים בתווית "app": "app-name" בקובץ deployment_spec.yaml.
יצירה והחלה של שירותים לחיבורים לפודים ולקונטיינרים
אחרי העברת עומס עבודה, שמות המארחים כבר לא רלוונטיים. כדי לאפשר חיבורים לעומסי העבודה, צריך ליצור ולהחיל שירותים.
זיהוי והגדרה של שמות וכתובות IP שהועברו
GKE מנהל את הקובץ /etc/hosts. ב-Migrate to Containers, התאמת קובץ המארחים מהמכונה הווירטואלית של המקור ל-GKE עדיין לא מתבצעת באופן אוטומטי. צריך לזהות את השמות וכתובות ה-IP בקובץ hosts במכונה הווירטואלית שהועברה ולהגדיר אותם כ-hostAliases.
הצבת שירותים שתלויים במיקום באותו מרחב שמות
שירותים שתלויים זה בזה צריכים להיות ממוקמים באותו מרחב שמות של Kubernetes ולהשתמש בשמות DNS קצרים (לדוגמה, app ו-db) כדי לתקשר. ההגדרה הזו עוזרת גם לשכפל סביבות של כמה אפליקציות, כמו סביבת ייצור, סביבת Staging וסביבת בדיקה.
שליטה במשטח הגישה באמצעות רשת GKE
ל-GKE יש אמצעי בקרה מתוחכמים לרישות. אפשר לגשת ל-Pods מרשתות שונות, כמו האינטרנט הציבורי, רשת VPC או רשת פנימית של אשכול. האפשרות הזו מאפשרת לשלוט עוד יותר בגישה לעומס עבודה ולהגביל אותה, בלי להוסיף מורכבות בניהול של רשתות VLAN, מסננים או כללי ניתוב.
לדוגמה, לאפליקציה טיפוסית עם שלוש שכבות יש שכבת חזית, שכבת אפליקציה ושכבת מסד נתונים. כשמבצעים מיגרציה אל Google Cloud, שירות הקצה הקדמי מוגדר עם LoadBalancer ברשת ה-VPC. אי אפשר לגשת ישירות לרמות האחרות מחוץ לאשכול GKE. מדיניות של גישה לרשת מוודאת ששירות האפליקציה נגיש רק ל-Pods של הקצה הקדמי מתוך רשת האשכול הפנימית. מדיניות אחרת מבטיחה שרק פודים של אפליקציות יוכלו לגשת לפודים של מסדי נתונים.
NFS
הגדרת חיבורי NFS כנפחי אחסון מתמיד
כשיוצרים את תוכנית המיגרציה, המערכת מזהה באופן אוטומטי את ה-NFS client mounts במכונה הווירטואלית של המקור ומוסיפה אותם לתוכנית שנוצרה.
התושבות מתווספות לתוכנית, אבל הן מושבתות כברירת מחדל.
כלומר, ההגדרות של PersistentVolume ו-PersistentVolumeClaim לא נכללות בקובץ deployment_spec.yaml כשיוצרים ארטיפקטים של העברה.
אם רוצים ש-Migrate to Containers ייצור הגדרות של PersistentVolume ו-PersistentVolumeClaim,
צריך קודם לערוך את תוכנית ההעברה כדי להפעיל את NFS client mount.
מידע נוסף מופיע במאמר בנושא התאמה אישית של נקודות חיבור NFS.
שרתי NFS במצב ליבה
אי אפשר להעביר מכונות וירטואליות עם שרתי NFS שפועלים במצב ליבה ל-GKE באמצעות Migrate to Containers. צריך להעביר את המכונות הווירטואליות האלה למכונות וירטואליות ב-Compute Engine. לחלופין, אפשר להשתמש ב-Filestore לפתרון NFS מבוסס-ענן.
העברת נתונים משיתופי NFS של מקור
אם מכונת ה-VM שלכם משתמשת בנקודת חיבור לשיתוף NFS, אי אפשר להעביר את הנתונים האלה באופן אוטומטי. אפשר להטמיע את השיתוף במאגר של עומס העבודה שהועבר באמצעות נפח אחסון מתמשך של NFS, או – אם שיתוף ה-NFS של המקור הוא מרוחק – להעתיק את הנתונים לשיתוף קבצים אחר שמספק גישה לאשכול עם זמן אחזור נמוך יותר.
אפשרויות להעתקת נתונים מפורטות במאמרים הבאים:
העתקת נתונים באמצעות
gcloud storage rsync(משיתוף קבצים של מקור לקטגוריה, ואז מהקטגוריה לשיתוף הקבצים בענן).פתרונות של צד שלישי, כמו NetApp SnapMirror ל-NetApp Cloud Volumes.
כלי OSS כמו Rsync.
מוודאים שיש גישה למסדי הנתונים
אם האפליקציה שלכם מסתמכת על מסד נתונים, בין אם הוא פועל באופן מקומי במכונה הווירטואלית או במכונה חיצונית, אתם צריכים לוודא שעדיין יש גישה למסד הנתונים מה-Pod החדש שהועבר. צריך לוודא שמדיניות חומת האש בין רשתות מאפשרת גישה מהאשכול למסד הנתונים.
כדי להעביר את מסד הנתונים אל Google Cloud, מומלץ להשתמש בDatabase Migration Service
אפשרות אחרת היא להריץ את מסד הנתונים בתוך האשכול. מידע נוסף זמין במאמר תכנון פריסות של מסדי נתונים ב-GKE.
מוודאים שהמטא-נתונים שהוזרקו זמינים
אם האפליקציות שלכם מסתמכות על מטא-נתונים שמוזרקים (לדוגמה, משתני סביבה), אתם צריכים לוודא שהמטא-נתונים האלה זמינים ב-GKE. אם אותה שיטה להוספת מטא-נתונים לא זמינה, ב-GKE יש ConfigMaps ו-Secrets.
הגדרת השירותים הנדרשים להפעלה ברמת הרצה 3
עומסי עבודה של Migrate to Containers מגיעים רק לרמת הרצה 3. מכונות וירטואליות שהועברו ל-GKE באמצעות Migrate to Containers יופעלו בקונטיינר ב-Linux runlevel 3. שירותים מסוימים (לדוגמה X11 או XDM, לגישה מרחוק לממשק משתמש גרפי באמצעות VNC) מוגדרים כברירת מחדל להפעלה רק ברמת הרצה 5. צריך להגדיר את כל השירותים הנדרשים כך שיופעלו ברמת ההפעלה 3.
השבתה של שירותים לא נחוצים
הכלי Migrate to Containers משבית אוטומטית שירותים שספציפיים לחומרה או לסביבה, וגם קבוצה מוגדרת מראש של שירותים נוספים שפועלים במכונות וירטואליות. לא צריך את השירותים האלה אחרי שמעבירים את עומסי העבודה למאגרי מידע.
לדוגמה, Migrate to Containers משבית אוטומטית את iptables, ip6tables ו-firewalld. כדי לראות רשימה מלאה של השירותים שמושבתים על ידי Migrate to Containers, אפשר להוריד את הקובץ blocklist.yaml.
התאמה אישית של שירותים מושבתים
כברירת מחדל, Migrate to Containers משבית את השירותים המיותרים שמפורטים למעלה. אפשר גם להגדיר רשימה מותאמת אישית של שירותים להשבתה במאגר שהועבר על ידי התאמה אישית של תוכנית ההעברה כדי להגדיר רשימת חסימה. ברשימת חסימה, מציינים שירות אחד או יותר שרוצים להשבית במאגר שהועבר.
תחזוקה ועדכון של מכונות וירטואליות שהועברו
באמצעות הארטיפקטים שנוצרים במהלך ההעברה, אפשר להחיל עדכוני תוכנה של מערכת ההפעלה במצב משתמש ושל אפליקציות, תיקוני אבטחה, עריכה של הגדרות מוטמעות, הוספה או החלפה של קבצים ועדכון של תוכנת זמן הריצה של Migrate to Containers.
מידע נוסף זמין במאמר בנושא עדכוני תמונות אחרי העברת נתונים.