העברה מ-AWS אל Google Cloud: העברה מ-Amazon EKS אל GKE

Last reviewed 2026-02-20 UTC

‫Google Cloud מספקת כלים, מוצרים, הנחיות ושירותים מקצועיים להעברה מ-Amazon Elastic Kubernetes Service‏ (Amazon EKS) אל Google Kubernetes Engine‏ (GKE). במסמך הזה מוסבר איך לתכנן, להטמיע ולאמת תוכנית להעברה מ-Amazon EKS ל-GKE. במסמך הזה יש גם הנחיות שיעזרו לכם להעריך את האפשרות לבצע העברה ולבדוק איך היא עשויה להיראות. בנוסף להרצה ב-Amazon Elastic Compute Cloud‏ (Amazon EC2), ל-Amazon EKS יש כמה אפשרויות פריסה אחרות, כמו Amazon EKS ב-AWS Outposts ו-Amazon EKS Anywhere. המאמר הזה מתמקד ב-Amazon EKS ב-EC2.

המסמך הזה הוא חלק מסדרה של מסמכים בנושא מעבר מ-AWS אלGoogle Cloud , והוא כולל את המסמכים הבאים:

‫GKE הוא שירות Kubernetes שמנוהל על ידי Google, שבעזרתו אפשר לפרוס אפליקציות בקונטיינרים ולהפעיל אותן בהיקף גדול באמצעות התשתית של Google. השירות מספק תכונות שעוזרות לכם לנהל את סביבת Kubernetes, כמו:

  • שני מצבי פעולה: רגיל וטייס אוטומטי. במהדורת Standard, אתם מנהלים את התשתית הבסיסית ואת ההגדרה של כל צומת באשכול GKE. ב-Autopilot,‏ GKE מנהל את התשתית הבסיסית, כמו הגדרת הצמתים, שינוי הגודל האוטומטי, השדרוגים האוטומטיים, אבטחת הבסיס והגדרת הרשת. מידע נוסף על מצבי הפעולה של GKE זמין במאמר בחירת מצב פעולה של GKE.
  • הסכם רמת שירות (SLA) ייחודי בתעשייה ל-Pods כשמשתמשים ב-Autopilot בכמה אזורים.
  • יצירה ומחיקה אוטומטיות של מאגרי צמתים באמצעות Node Auto Provisioning.
  • רשתות מרובות אשכולות בניהול Google, שיעזרו לכם לתכנן ולהטמיע ארכיטקטורות מבוזרות עם זמינות גבוהה לעומסי העבודה.

למידע נוסף על GKE, אפשר לקרוא את הסקירה הכללית על GKE.

כדי לבצע את ההעברה אל Google Cloud, מומלץ לפעול לפי מסגרת ההעברה שמתוארת במאמר העברה אל Google Cloud: תחילת העבודה.

התרשים הבא מדגים את תהליך ההעברה.

נתיב העברה עם ארבעה שלבים.

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

  1. הערכה וגילוי של עומסי העבודה והנתונים.
  2. מתכננים ובונים בסיס ב- Google Cloud.
  3. העברת עומסי העבודה והנתונים אל Google Cloud.
  4. אופטימיזציה של Google Cloud הסביבה

מידע נוסף על השלבים של המסגרת הזו זמין במאמר מעבר אל Google Cloud: תחילת העבודה.

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

הערכת סביבת המקור

בשלב ההערכה, קובעים את הדרישות והתלות להעברת סביבת המקור אל Google Cloud.

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

שלב ההערכה כולל את המשימות הבאות:

  1. יוצרים מלאי מקיף של עומסי העבודה.
  2. מקטלגים את עומסי העבודה לפי המאפיינים והתלות שלהם.
  3. הדרכה ולימוד של הצוותים בנושא Google Cloud.
  4. יצירת ניסויים והוכחות היתכנות ב- Google Cloud.
  5. חישוב עלות הבעלות הכוללת (TCO) של סביבת היעד.
  6. בוחרים את אסטרטגיית ההעברה של עומסי העבודה.
  7. בוחרים את כלי ההעברה.
  8. הגדרת תוכנית ההעברה ולוח הזמנים.
  9. מאמתים את תוכנית ההעברה.

מידע נוסף על שלב ההערכה והמשימות האלה זמין במאמר מעבר אל Google Cloud: הערכה וגילוי של עומסי העבודה. הקטעים הבאים מבוססים על מידע שמופיע במסמך הזה.

יצירת מלאי שטחי הפרסום

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

  1. המלאי של האשכולות.
  2. מלאי עומסי העבודה (workloads) שנפרסו באשכולות האלה.

אחרי שיוצרים את מלאי שטחי הפרסום האלה:

  1. הערכה של תהליכי הפריסה והתפעול בסביבת המקור.
  2. הערכה של שירותים תומכים ותלויות חיצוניות.

בניית המלאי של האשכולות

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

  • מספר הצמתים והסוג שלהם. אם אתם יודעים כמה צמתים יש בסביבה הנוכחית שלכם ואילו מאפיינים יש לכל צומת, תוכלו לקבוע את גודל האשכולות כשאתם עוברים ל-GKE. יכול להיות שהצמתים בסביבה החדשה יפעלו על ארכיטקטורת חומרה או דור שונים מאלה שבהם אתם משתמשים בסביבה שלכם. הביצועים של כל ארכיטקטורה ודור שונים, ולכן יכול להיות שמספר הצמתים שדרושים בסביבה החדשה יהיה שונה מהמספר בסביבה הקודמת. להעריך כל סוג של חומרה שבה אתם משתמשים בצמתים, כמו מכשירי אחסון בעלי ביצועים גבוהים, מעבדי GPU ומעבדי TPU. בודקים את תמונת מערכת ההפעלה שבה משתמשים בצמתים.
  • קלאסטר פנימי או חיצוני. בודקים לאילו גורמים, פנימיים או חיצוניים לסביבה, כל אשכול חשוף. כדי לתמוך בתרחישי השימוש שלכם, ההערכה הזו כוללת את עומסי העבודה שפועלים באשכול ואת הממשקים שמתקשרים עם האשכולות שלכם.
  • ריבוי דיירים. אם אתם מנהלים אשכולות רב-דיירים בסביבה שלכם, כדאי לבדוק אם הם פועלים בסביבת Google Cloudהחדשה. זה הזמן לבדוק איך אפשר לשפר את אשכולות ה-multi-tenant, כי אסטרטגיית ה-multi-tenancy משפיעה על האופן שבו בונים את הבסיס ב- Google Cloud.
  • גרסת Kubernetes. כדאי לאסוף מידע על גרסת Kubernetes של האשכולות כדי לבדוק אם יש אי התאמה בין הגרסאות האלה לבין הגרסאות שזמינות ב-GKE. אם אתם מפעילים גרסה ישנה של Kubernetes או גרסה שפורסמה לאחרונה, יכול להיות שאתם משתמשים בתכונות שלא זמינות ב-GKE. יכול להיות שהתכונות הוצאו משימוש, או שגרסת Kubernetes שכוללת אותן עדיין לא זמינה ב-GKE.
  • מחזור השדרוג של Kubernetes. כדי לשמור על סביבה אמינה, חשוב להבין איך מתבצעים שדרוגים של Kubernetes ואיך מחזור השדרוגים קשור לשדרוגים של GKE.
  • מאגרי צמתים. אם אתם משתמשים בקיבוץ צמתים מכל סוג שהוא, כדאי לשקול איך הקיבוצים האלה ממופים למושג של מאגרי צמתים ב-GKE, כי יכול להיות שהקריטריונים לקיבוץ לא מתאימים ל-GKE.
  • Node initialization (הפעלת הצומת). כדאי להעריך איך אתם מאתחלים כל צומת לפני שאתם מסמנים אותו כזמין להרצת עומסי העבודה, כדי שתוכלו להעביר את תהליכי האתחול האלה אל GKE.
  • הגדרת הרשת. צריך לבדוק את הגדרת הרשת של האשכולות, את הקצאת כתובות ה-IP שלהם, איך הגדרתם את תוספי הרשת שלהם, איך הגדרתם את שרתי ה-DNS ואת ספקי שירותי ה-DNS שלהם, אם הגדרתם צורה כלשהי של NAT או SNAT לאשכולות האלה, והאם הם חלק מסביבה מרובת אשכולות.
  • תאימות: הערכה של דרישות התאימות והרגולציה שהאשכולות צריכים לעמוד בהן, ובדיקה אם אתם עומדים בדרישות האלה.
  • מכסות ומגבלות בודקים איך הגדרתם את המכסות והמגבלות עבור האשכולות. לדוגמה, כמה פודים יכולים לפעול בכל צומת? כמה צמתים יכולים להיות באשכול?
  • תוויות ותגים. בודקים את המטא-נתונים שהחלתם על אשכולות, על מאגרי צמתים ועל צמתים, ואת אופן השימוש בהם. לדוגמה, יכול להיות שאתם יוצרים דוחות עם שיוך עלויות מפורטות שמבוסס על תוויות.

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

יצירת מלאי של מרחבי השמות ב-Kubernetes ואובייקטים של הגדרות אבטחה

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

  • מרחבי שמות. אם אתם משתמשים במרחבי שמות של Kubernetes באשכולות כדי להפריד בין משאבים באופן לוגי, כדאי להעריך אילו משאבים נמצאים בכל מרחב שמות ולהבין למה יצרתם את ההפרדה הזו. לדוגמה, יכול להיות שאתם משתמשים במרחבי שמות כחלק מאסטרטגיית ריבוי הדיירים שלכם. יכול להיות שיש לכם עומסי עבודה שפרוסים במרחבי שמות ששמורים לרכיבי מערכת של Kubernetes, ויכול להיות שלא תהיה לכם שליטה רבה ב-GKE.
  • בקרת גישה מבוססת-תפקידים (RBAC). אם אתם משתמשים בהרשאת RBAC באשכולות, תיאור של כל ClusterRoles ו-ClusterRoleBindings שהגדרתם באשכולות.
  • כללי מדיניות הרשת. לרשום את כל כללי המדיניות של הרשת שהגדרתם באשכולות, ולהבין איך כללי המדיניות של הרשת פועלים ב-GKE.
  • הקשרים של אבטחת Pod. קבלת מידע על הקשרים של אבטחת ה-Pod שהגדרתם באשכולות והסבר על אופן הפעולה שלהם ב-GKE.
  • חשבונות שירות. אם יש תהליך באשכול שמתקשר עם שרת ה-API של Kubernetes, צריך לתעד מידע על חשבונות השירות שבהם התהליך משתמש.

יצירת מלאי של עומסי העבודה (workload) של Kubernetes

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

  • מארזי אוזניות ובקרים. כדי לקבוע את גודל האשכולות בסביבה החדשה, צריך להעריך כמה מופעים של כל עומס עבודה פרוסים, ואם אתם משתמשים במכסות משאבים ובמגבלות על צריכת משאבי מחשוב. אוספים מידע על עומסי העבודה שפועלים בצמתים של מישור הבקרה בכל אשכול ועל הבקרים שכל עומס עבודה משתמש בהם. לדוגמה, בכמה פריסות אתם משתמשים? בכמה DaemonSets השתמשת?
  • משימות וCronJobs. יכול להיות שהאשכולות ועומסי העבודה שלכם יצטרכו להריץ Jobs או CronJobs כחלק מההליכים של ההפעלה או התפעול שלהם. כדאי להעריך כמה מקרים של משימות ומשימות Cron פרסתם, ואת האחריות והקריטריונים להשלמה של כל מופע.
  • Kubernetes Autoscalers. כדי להעביר את מדיניות ההתאמה האוטומטית לעומס בסביבה החדשה, כדאי לקרוא על Horizontal Pod Autoscaler ועל Vertical Pod Autoscaler ב-GKE.
  • עומסי עבודה ללא מצב (stateless) ועומסי עבודה עם מצב (stateful). עומסי עבודה ללא מצב לא שומרים נתונים או מצב באשכול או באחסון קבוע. אפליקציות עם מצב (Stateful) שומרות נתונים לשימוש מאוחר יותר. לגבי כל עומס עבודה, צריך להעריך אילו רכיבים הם stateless ואילו הם stateful, כי בדרך כלל קשה יותר להעביר עומסי עבודה stateful מאשר להעביר עומסי עבודה stateless.
  • תכונות של Kubernetes. ממלאי המשאבים של האשכול, אפשר לדעת איזו גרסת Kubernetes מופעלת בכל אשכול. כדאי לעיין בנתוני הגרסה של כל גרסת Kubernetes כדי לדעת אילו תכונות נכללות בה ואילו תכונות הוצאו משימוש. לאחר מכן, מעריכים את עומסי העבודה בהשוואה לתכונות של Kubernetes שדרושות לכם. המטרה של המשימה הזו היא לדעת אם אתם משתמשים בתכונות שהוצאו משימוש או בתכונות שעדיין לא זמינות ב-GKE. אם אתם מוצאים תכונות שלא זמינות, כדאי להפסיק להשתמש בתכונות שהוצאו משימוש ולעבור לתכונות החדשות כשהן יהיו זמינות ב-GKE.
  • אחסון. עבור עומסי עבודה עם שמירת מצב, בודקים אם הם משתמשים ב-PersistenceVolumeClaims. מפרטים את דרישות האחסון, כמו גודל ומצב גישה, ומסבירים איך בקשות PersistenceVolumeClaims ממופות ל-PersistenceVolumes. כדי להתכונן לצמיחה עתידית, צריך לבדוק אם יש צורך להרחיב את PersistenceVolumeClaim.
  • הגדרה והחדרת סודות. כדי להימנע מבנייה מחדש של ארטיפקטים שניתנים לפריסה בכל פעם שמתבצע שינוי בהגדרות של הסביבה, אפשר להחדיר הגדרות וסודות ל-Pods באמצעות ConfigMaps ו-Secrets. לכל עומס עבודה, צריך להעריך אילו ConfigMap וסודות נמצאים בשימוש בעומס העבודה הזה, ואיך מאכלסים את האובייקטים האלה.
  • תלות. סביר להניח שעומסי העבודה שלכם לא פועלים בבידוד. יכול להיות שיש להם תלות, פנימית לאשכול או ממערכות חיצוניות. לכל עומס עבודה, צריך לתעד את התלות שלו, ואם יש לעומסי העבודה סבילות כלשהי למצב שבו התלות לא זמינה. לדוגמה, תלות נפוצה כוללת מערכות קבצים מבוזרות, מסדי נתונים, פלטפורמות להפצת סודות, מערכות לניהול זהויות והרשאות גישה, מנגנונים לאיתור שירותים ומערכות חיצוניות אחרות.
  • שירותי Kubernetes. כדי לחשוף את עומסי העבודה ללקוחות פנימיים וחיצוניים, משתמשים בServices. לכל שירות צריך לדעת את הסוג שלו. לגבי שירותים שחשופים חיצונית, צריך להעריך את האינטראקציה של השירות עם שאר התשתית. לדוגמה, איך התשתית שלכם תומכת בשירותי LoadBalancer, באובייקטים של Gateway ובאובייקטים של Ingress? אילו בקרי Ingress פרסתם באשכולות?
  • Service mesh. אם אתם משתמשים ב-service mesh בסביבה שלכם, כדאי לבדוק איך הוא מוגדר. צריך גם לדעת כמה אשכולות הוא כולל, אילו שירותים הם חלק מהרשת ואיך משנים את הטופולוגיה של הרשת.
  • דחיות (taints) וטולרנטיות וזיקה (affinity) ואנטי-זיקה. לכל Pod ולכל Node, בודקים אם הגדרתם Node taints,‏ Pod tolerations או affinities כדי להתאים אישית את התזמון של ה-Pods באשכולות Kubernetes. המאפיינים האלה יכולים גם לספק תובנות לגבי הגדרות אפשריות של צמתים או של תרמילים שלא בהכרח זהות, ויכול להיות שצריך לבדוק את התרמילים, את הצמתים או את שניהם באופן מיוחד וקפדני. לדוגמה, אם הגדרתם קבוצה מסוימת של Pods כך שהם יתוזמנו רק בצמתים מסוימים באשכול Kubernetes, יכול להיות שהמשמעות היא שה-Pods צריכים משאבים מיוחדים שזמינים רק בצמתים האלה.
  • אימות: הערכה של אופן האימות של עומסי העבודה מול משאבים באשכול ומול משאבים חיצוניים.

הערכת שירותים תומכים ויחסי תלות חיצוניים

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

  • ‫StorageClasses ו-PersistentVolumes. כדי להעריך איך התשתית מגבה את PersistentVolumeClaims, צריך לרשום את StorageClasses עבור הקצאת משאבים דינמית וPersistentVolumes שהוקצו באופן סטטי. לכל PersistentVolume, כדאי לשקול את הפרמטרים הבאים: קיבולת, מצב נפח, מצב גישה, סיווג, מדיניות שחזור, אפשרויות הרכבה וזיקה לצומת.
  • ‫VolumeSnapshots ו-VolumeSnapshotContents. לכל PersistentVolume, בודקים אם הגדרתם VolumeSnapshot, ואם צריך להעביר VolumeSnapshotContents קיים.
  • מנהלי התקנים של Container Storage Interface‏ (CSI). אם הם נפרסו באשכולות שלכם, צריך לבדוק אם מנהלי ההתקנים האלה תואמים ל-GKE, ואם צריך להתאים את ההגדרה של אמצעי האחסון כדי לעבוד עם מנהלי התקנים של CSI שתואמים ל-GKE.
  • אחסון נתונים. אם אתם מסתמכים על מערכות חיצוניות כדי להקצות PersistentVolumes, אתם צריכים לספק דרך לעומסי העבודה בסביבת GKE להשתמש במערכות האלה. למיקום הנתונים יש השפעה על הביצועים של עומסי עבודה עם שמירת מצב, כי זמן האחזור בין המערכות החיצוניות לבין סביבת GKE פרופורציונלי למרחק ביניהן. לכל מערכת אחסון נתונים חיצונית, צריך לקחת בחשבון את הסוג שלה, כמו נפחי בלוקים, אחסון קבצים או אחסון אובייקטים, וכל דרישה לביצועים ולזמינות שהיא צריכה לעמוד בה.
  • משאבים מותאמים אישית ותוספים ל-Kubernetes. כדאי לאסוף מידע על משאבי Kubernetes בהתאמה אישית ועל תוספים ל-Kubernetes שאולי פרסתם באשכולות, כי יכול להיות שהם לא יפעלו ב-GKE או שתצטרכו לשנות אותם. לדוגמה, אם משאב מותאם אישית מקיים אינטראקציה עם מערכת חיצונית, צריך להעריך אם זה רלוונטי לסביבה שלכם Google Cloud .
  • גיבוי. צריך להעריך איך מגבים את ההגדרות של האשכולות ואת נתוני עומס העבודה עם שמירת מצב בסביבת המקור.

כלים לבניית המלאי ולהערכת סביבת המקור

כדי לאסוף את נקודות הנתונים הנדרשות לגבי אובייקטים ואשכולות של Amazon EKS, צריך להשתמש בכלים הבאים:

  • גילוי אשכולות של Amazon EKS, גילוי צמתים והערכה. כדי לגלות את אשכולי Amazon EKS, מומלץ להשתמש ב-KubeScan ולשפר את המלאי באמצעות Migration Center. ‫Migration Center היא פלטפורמה מאוחדת של Google Cloudשעוזרת לכם להאיץ את המעבר המלא לענן מהסביבה הנוכחית שלכם אל Google Cloud. ‫Migration Center מגלה את אשכולות Amazon EKS וצמתי האשכולות שלכם, ומספק המלצות להערכה לגבי בחירת הגודל המתאים לסביבת GKE.
  • מאגר אובייקטים של Kubernetes. כדי ליצור את מלאי האובייקטים שנפרסו באשכולות Kubernetes, מומלץ להשתמש ב-KubeScan.
  • הערכת אובייקט Kubernetes. כדי להעריך את אובייקטי Kubernetes, מומלץ להשתמש ב-Gemini CLI. לדוגמה, אתם יכולים להוסיף את קובצי המלאי שמפרטים את אובייקטי Kubernetes באשכולות שלכם להקשר של Gemini CLI, ואז להנחות את Gemini לעזור לכם להעריך את האובייקטים האלה. מידע נוסף זמין במאמר העברות ל-Google Cloud שמבוססות על Gemini.

שיפור המלאי של אשכולות ועומסי עבודה ב-Amazon EKS

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

בנוסף לנתונים שמתקבלים ממרכז ההעברה, כדאי לשקול את נקודות הנתונים הבאות לגבי כל אשכול Amazon EKS שרוצים להעביר:

  • כדאי לשקול היבטים ותכונות ספציפיים ל-Amazon EKS עבור כל אשכול של Amazon EKS, כולל אלה:
    • אשכולות פרטיים
    • בקרת גישה לנקודות קצה של אשכול
    • הצפנת סודות
    • תגים במשאבי Amazon EKS
    • ‫Amazon Custom AMIs ב-EKS
    • שימוש ב-Amazon EKS Managed Prometheus
    • הגדרת אימות OpenID Connect
  • בודקים איך מתבצעת האימות מול אשכולות Amazon EKS ואיך הגדרתם את ניהול הזהויות והרשאות הגישה (IAM) של AWS עבור Amazon EKS.
  • הערכת הגדרות הרשת של אשכולות Amazon EKS.

הערכת תהליכי הפריסה והתפעול

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

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

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

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

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

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

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

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

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

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

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

  • אימות. בודקים איך מתבצע אימות מול סביבת המקור.

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

    • משאבים ב-Terraform Provider: מתחילים מאפס באמצעות אבני בניין בסיסיות. Google Cloud
    • מודולים ותוכניות לניהול של Terraform ב- Google Cloud: מתחילים מבסיס של מודולים של Terraform עם דעות מוצקות. הגישה הזו מבוססת על משאבים ב- Google Cloud Terraform Provider.
    • תוכנית Enterprise Foundations Blueprint: מתחילים מיסודות ומתחומי נחיתה מוגדרים. הגישה הזו מבוססת על מודולים ותוכניות לניהול של Terraform ב- Google Cloud.
    • ‫Cloud Foundation Fabric: מתחילים עם בסיס מוטה ואזורי נחיתה. ‫Cloud Foundation Fabric היא הטמעה עצמאית שמשתמשת במודולים משלה של Terraform. הגישה הזו מבוססת על משאבים ב- Google Cloud Terraform Provider.

תכנון ובנייה של הבסיס

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

  • תמיכה בעומסי העבודה בסביבת Google Cloud .
  • כדי להשלים את ההעברה, צריך לחבר את סביבת המקור ואת סביבת Google Cloud היעד.

שלב התכנון והבנייה מורכב מהמשימות הבאות:

  1. בניית היררכיית משאבים.
  2. מגדירים את ניהול הזהויות והרשאות הגישה (IAM) של Google Cloud.
  3. הגדרת חיוב.
  4. הגדרת חיבור לרשת.
  5. הגברת האבטחה.
  6. הגדרת רישום ביומן, מעקב והתראות.

מידע נוסף על כל אחת מהמשימות האלה זמין במאמר מעבר אל Google Cloud: תכנון ובניית הבסיס.

בקטעים הבאים משולבים השיקולים שבמאמר בנושא מעבר אלGoogle Cloud: תכנון ובניית הבסיס.

תכנון של ארכיטקטורת מולטי-טננט

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

  • יצירת פרויקט אחד לכל דייר. Google Cloud
  • שיתוף פרויקט אחד בין דיירים שונים והקצאת משאבים לכמה אשכולות GKE.
  • שימוש במרחבי שמות של Kubernetes.

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

הגדרת ניהול זהויות והרשאות גישה

‫GKE תומך בכמה אפשרויות לניהול גישה למשאבים ב Google Cloud פרויקט ובאשכולות שלו באמצעות RBAC. מידע נוסף זמין במאמר בנושא בקרת גישה.

הגדרת רשתות ב-GKE

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

הגדרה של מעקב והתראות

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

העברת הנתונים ופריסת עומסי עבודה

בשלב הפריסה, מבצעים את הפעולות הבאות:

  1. הקצאה והגדרה של סביבת GKE.
  2. מגדירים את אשכולות GKE.
  3. ארגון מחדש של עומסי העבודה.
  4. שינוי מבנה של תהליכי פריסה ותפעול.
  5. העברת נתונים מסביבת המקור אל Google Cloud.
  6. פריסת עומסי העבודה בסביבת GKE.
  7. מאמתים את עומסי העבודה ואת סביבת GKE.
  8. חשיפת עומסי עבודה שפועלים ב-GKE.
  9. העברת התנועה מסביבת המקור לסביבת GKE.
  10. להוציא משימוש את סביבת המקור.

הקצאת הרשאות ידנית והגדרה של סביבת Google Cloud

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

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

אחרי שלב ההערכה, אתם יודעים איך להקצות את אשכולות GKE בסביבת Google Cloud החדשה כדי לענות על הצרכים שלכם. כדי להקצות את האשכולות, כדאי לשקול את הדברים הבאים:

מידע נוסף על הקצאת אשכולות GKE:

ניהול ה-Fleet

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

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

רישות מרובה אשכולות

כדי לשפר את המהימנות של סביבת GKE ולחלק את עומסי העבודה בין כמה אשכולות GKE, אפשר להשתמש ב:

  • Multi-Cluster Service Discovery (זיהוי שירותים מרובי אשכולות), מנגנון לזיהוי שירותים ולהפעלתם באשכולות שונים. אפשר לגלות את השירותים ולגשת אליהם באשכולות GKE. מידע נוסף זמין במאמר בנושא גילוי שירותים בכמה אשכולות.
  • שערים מרובי אשכולות, מנגנון לאיזון עומסים של תעבורת נתונים נכנסת (ingress) בין אשכולות. מידע נוסף זמין במאמר בנושא פריסת שערים מרובי-אשכולות.
  • רשת מרובת אשכולות ב-Cloud Service Mesh מנוהל. מידע נוסף מופיע במאמר בנושא הגדרת רשת מרובת אשכולות.

מידע נוסף על מעבר מסביבת GKE עם אשכול יחיד לסביבת GKE עם כמה אשכולות זמין במאמר מעבר לרשת עם כמה אשכולות.

הגדרת אשכולות GKE

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

כדי להגדיר אובייקטים של Kubernetes ו-GKE באשכולות GKE, מומלץ:

  1. חשוב לוודא שיש לכם את פרטי הכניסה וההרשאות הנדרשים כדי לגשת לאשכולות בסביבת המקור ובסביבת GKE.
  2. בודקים אם האובייקטים באשכולות Kubernetes בסביבת המקור תואמים ל-GKE, ומה ההבדלים בין ההטמעות שתומכות באובייקטים האלה בסביבת המקור וב-GKE.
  3. מבצעים רפקטורינג לאובייקט לא תואם כדי שיהיה תואם ל-GKE, או מוציאים אותו משימוש.
  4. יוצרים את האובייקטים האלה באשכולות GKE.
  5. מגדירים אובייקטים נוספים שנדרשים באשכולות GKE.

סנכרון תצורות

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

מידע נוסף זמין במאמר בנושא ארכיטקטורת Config Sync.

Policy Controller

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

מידע נוסף זמין במאמר בנושא Policy Controller.

ארגון מחדש של עומסי העבודה

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

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

כדי לבצע רפקטורינג של עומסי העבודה לפני שמעבירים אותם ל-GKE, צריך:

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

בדיקת תכונות ספציפיות לסביבת המקור

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

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

במסגרת הבדיקה הזו, מומלץ לבצע את הפעולות הבאות:

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

שימוש בפתרונות חלופיים מתאימים של GKE

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

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

ארגון מחדש של עומסי העבודה

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

השינוי הזה עשוי לכלול:

  • מתארים של אובייקטים ב-Kubernetes, כמו Deployments ו-Services, בפורמט YAML.
  • תיאורים של קובצי אימג' של קונטיינרים, כמו Dockerfiles ו-Containerfiles.
  • קוד המקור של עומסי העבודה.

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

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

כדי להאיץ את משימות בדיקת הקוד והפקטורינג, אתם יכולים להשתמש ב-Gemini כדי להגדיל את צוות ההעברה. לדוגמה, אתם יכולים להשתמש ב-Gemini CLI כדי:

  1. בודקים את קוד המקור של עומסי העבודה שרוצים להעביר ואת אובייקטי ה-Kubernetes שלהם, כמו Deployments,‏ Services ו-Gateways.
  2. תכנון של שינוי מבנה הקוד.
  3. מבצעים רפקטורינג של הקוד ומאמתים את השינויים.

מידע נוסף זמין במאמר בנושא העברות מבוססות-Gemini אל Google Cloud.

שינוי מבנה של תהליכי פריסה ותפעול

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

  • הקצאה והגדרה של משאבים בסביבת Google Cloud היעד במקום הקצאת משאבים בסביבת המקור.
  • ליצור ולהגדיר עומסי עבודה ולפרוס אותם ב- Google Cloudבמקום לפרוס אותם בסביבת המקור.

בשלב ההערכה בתהליך הזה, אספתם מידע על התהליכים האלה.

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

  • יכול להיות שהטמעתם את התהליכים האלה בסביבת המקור, ואתם מתכוונים לעצב ולהטמיע תהליכים דומים ב- Google Cloud. לדוגמה, אפשר לשנות את התהליכים האלה כך שישתמשו ב-Cloud Build, ב-Cloud Deploy וב-Infrastructure Manager.
  • יכול להיות שהטמעתם את התהליכים האלה בסביבה אחרת של צד שלישי, מחוץ לסביבת המקור. במקרה כזה, צריך לשנות את התהליכים האלה כך שיפעלו בסביבת Google Cloud היעד ולא בסביבת המקור.
  • שילוב של הגישות הקודמות.

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

למידע נוסף על תכנון והטמעה של תהליכי פריסה ב- Google Cloud:

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

  1. הקצאת מאגרי פריטי מידע שנוצרו בתהליך פיתוח (Artifact) ב- Google Cloud. לדוגמה, אפשר להשתמש ב-Artifact Registry כדי לאחסן פריטי מידע שנוצרו בתהליך פיתוח (artifacts) ויחסי תלות בגרסת build.
  2. מבצעים רפקטורינג בתהליכי ה-build כדי לאחסן את הארטיפקטים גם בסביבת המקור וגם ב-Artifact Registry.
  3. מבצעים רפקטורינג בתהליכי הפריסה כדי לפרוס את עומסי העבודה בסביבת היעד שלGoogle Cloud . לדוגמה, אפשר להתחיל בפריסה של קבוצת משנה קטנה של עומסי העבודה ב- Google Cloud, באמצעות ארטיפקטים שמאוחסנים ב-Artifact Registry. לאחר מכן, מגדילים בהדרגה את מספר עומסי העבודה שנפרסים ב- Google Cloud, עד שכל עומסי העבודה להעברה יפעלו ב- Google Cloud.Google Cloud
  4. מבצעים רפקטורינג בתהליכי ה-build כדי לאחסן את הארטיפקטים רק ב-Artifact Registry.
  5. במקרה הצורך, מעבירים גרסאות קודמות של הארטיפקטים כדי לפרוס ממאגרי המידע בסביבת המקור אל Artifact Registry. לדוגמה, כדי להעביר תמונות של קונטיינרים אל Artifact Registry, אפשר להשתמש בכלים כמו gcrane או Rackware SWIFT.
  6. להוציא משימוש את המאגרים בסביבת המקור כשאין בהם יותר צורך.

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

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

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

העברת נתונים

כשמעבירים את עומסי העבודה ל-GKE, צריך להעריך את מצבם. קל יותר להעביר עומסי עבודה ללא מצב (stateless) מאשר עומסי עבודה עם מצב (stateful). כשמעבירים עומסי עבודה ללא מצב (stateless), פורסים אותם מחדש בסביבת היעד בלי להשפיע על הנתונים שלהם. עם זאת, כשמעבירים עומסי עבודה עם שמירת מצב, צריך להעביר גם את הנתונים שלהם, כמו PersistentVolumes ו-ConfigMaps עם שמירת מצב.

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

כדי להעביר נתונים לסביבת GKE, מבצעים את הפעולות הבאות:

  1. הקצאה והגדרה של כל תשתית האחסון הנדרשת.
  2. מגדירים אמצעי הקצאה של StorageClass באשכולות GKE. לא כל אמצעי ההקצאה של StorageClass תואמים לכל הסביבות. לפני שמפעילים כלי הקצאה של StorageClass, מומלץ לבדוק את התאימות שלו ל-GKE ואת התלות שלו.
  3. הגדרת StorageClasses.
  4. מגדירים את PersistentVolumes ואת PersistentVolumeClaims כדי לאחסן את הנתונים להעברה.
  5. העברת נתונים מסביבת המקור אל PersistentVolumes האלה. הפרטים הספציפיים של העברת הנתונים הזו תלויים במאפיינים של סביבת המקור.

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

  • אם עומס העבודה מספק כלים או תכונות להעברה או לשכפול של נתונים, אפשר להשתמש בכלים האלה כדי ליישם את תוכנית ההעברה. לדוגמה, כדי להעביר נתונים ממופע של עומס עבודה עם שמירת מצב למופע של עומס עבודה יעד שפועל ב-GKE, אפשר להשתמש באפשרויות הבאות:

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

  • אם עומס העבודה לא מספק כלים או תכונות ברמת האפליקציה להעברת נתונים, אפשר להשתמש בכלי של צד שלישי כמו Rackware SWIFT או Velero.

מידע נוסף על תכנון של העברת נתונים זמין במאמר העברה אל Google Cloud: העברת מערכי נתונים גדולים.

העברת נתונים מ-EKS ל-GKE

‫AWS מספקת כמה אפשרויות לאחסון נתונים ב-Amazon EKS. המסמך הזה מתמקד בתרחישים הבאים של העברת נתונים:

  • העברת נתונים מנפחי Amazon EBS למשאבי GKE PersistentVolume.
  • העתקת נתונים מנפחי Amazon EBS אל Amazon S3 או אל Cloud Storage, ואז העברת הנתונים אל משאבי GKEPersistentVolume.
העברת נתונים מנפחי Amazon EBS ל-PersistentVolumes ב-GKE

אפשר להעביר נתונים מנפחי Amazon EBS למשאבי GKE PersistentVolume באחת מהדרכים הבאות:

  • העתקת נתונים ישירות מנפחי Amazon EBS לדיסקים לאחסון מתמיד ב-Compute Engine:
    1. הקצאת מופעי Amazon EC2 וצירוף אמצעי האחסון של Amazon EBS שמכילים את הנתונים להעברה.
    2. הקצאת מכונות וירטואליות ב-Compute Engine עם דיסקים מתמשכים ריקים שיש להם מספיק קיבולת לאחסון הנתונים להעברה.
    3. מריצים כלי לסנכרון נתונים, כמו rsync, כדי להעתיק נתונים מהנפחים של Amazon EBS לדיסקים הקבועים של Compute Engine.
    4. מנתקים את הדיסקים לאחסון מתמיד מהמכונות ב-Compute Engine.
    5. מוציאים משימוש את המכונות של Compute Engine.
    6. מגדירים את הדיסקים של אחסון מתמיד כמשאבי GKE PersistentVolume.
  • העברת מכונות וירטואליות של Amazon EC2 ונפחי Amazon EBS אל Compute Engine:
    1. הקצאת מופעי Amazon EC2 וצירוף אמצעי האחסון של Amazon EBS שמכילים את הנתונים להעברה.
    2. מעבירים את המכונות הווירטואליות של Amazon EC2 ואת אמצעי האחסון של Amazon EBS אל Compute Engine באמצעות Migrate for Virtual Machines.
    3. מנתקים את הדיסקים לאחסון מתמיד מהמכונות ב-Compute Engine.
    4. מוציאים משימוש את המכונות של Compute Engine.
    5. מגדירים את הדיסקים של אחסון מתמיד כמשאבי GKE PersistentVolume.

מידע נוסף על העברת מופעים של Amazon EC2 ל-Compute Engine זמין במאמר העברה מ-AWS ל- Google Cloud: העברה מ-Amazon EC2 ל-Compute Engine.

מידע נוסף על שימוש בדיסקים לאחסון מתמיד ב-Compute Engine כמשאבי GKE PersistentVolume זמין במאמר בנושא שימוש בדיסקים לאחסון מתמיד קיימים כ-PersistentVolumes.

העתקת נתונים מנפחי Amazon EBS לגיבוי זמני, והעברה ל-PersistentVolumes ב-GKE

במקום להעביר ישירות נפחי Amazon EBS למשאבי GKE PersistentVolume, אפשר להשתמש באמצעי ביניים כמו מאגר אובייקטים:

  1. מעלים נתונים מנפחי Amazon EBS למדיה זמנית כמו קטגוריה של Amazon S3 או קטגוריה של Cloud Storage.
  2. מורידים את הנתונים מהמדיה הזמנית למשאבי GKE PersistentVolume.

בתרחישים מסוימים, שימוש בכמה אמצעי אחסון יכול לפשט את העברת הנתונים בהתאם להגדרות הרשת והאבטחה. לדוגמה, אפשר להעלות את הנתונים לקטגוריית S3, להעתיק אותם מקטגוריית S3 לקטגוריית Cloud Storage, ובסוף להוריד את הנתונים לנפחי האחסון הקבועים. לא משנה באיזו גישה תבחרו, כדי להבטיח מעבר חלק תוך התייחסות לשיקולים חשובים, מומלץ לעיין במאמר העברה מ-AWS ל- Google Cloud: העברה מ-Amazon S3 ל-Cloud Storage.

בחירת אפשרות העברה

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

  • כמות הנתונים שצריך להעביר.
    • אם יש לכם כמות קטנה של נתונים להעברה, כמו כמה קובצי נתונים, כדאי להשתמש בכלים כמו rsync כדי להעתיק את הנתונים ישירות לדיסקים מתמידים של Compute Engine. האפשרות הזו יחסית מהירה, אבל היא לא מתאימה לכמות גדולה של נתונים.
    • אם יש לכם כמות גדולה של נתונים להעברה, כדאי להשתמש ב-Migrate to Virtual Machines כדי להעביר את הנתונים ל-Compute Engine. האפשרות הזו מורכבת יותר מהעתקה ישירה של נתונים, אבל היא אמינה וניתנת להרחבה.
  • סוג הנתונים שצריך להעביר.
  • הקישוריות של הרשת בין סביבות המקור והיעד.
    • אם אי אפשר ליצור קישוריות רשת ישירה בין מכונות AWS EC2 לבין מכונות Compute Engine, כדאי לשקול שימוש ב-Amazon S3 או ב-Cloud Storage כדי לאחסן את הנתונים באופן זמני בזמן ההעברה ל-Compute Engine. האפשרות הזו עשויה להיות זולה יותר כי לא תצטרכו להפעיל את המופעים של EC2 ו-Compute Engine בו-זמנית.
  • ציר הזמן של ההעברה.
    • אם רוחב הפס של הרשת מוגבל או שיש לכם כמות גדולה של נתונים, והלוח זמנים שלכם לא צפוף, אתם יכולים גם להשתמש ב-Transfer Appliance כדי להעביר את הנתונים מ-AWS אל Google Cloud.

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

פריסת עומסי העבודה

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

כדי להכין את עומסי העבודה לפריסה ב-GKE, מומלץ לנתח את תיאורי ה-Kubernetes, כי חלק מהמשאבים ש-GKE מקצה לכם באופן אוטומטי ניתנים להגדרה באמצעות תוויות והערות של Kubernetes, במקום להקצות את המשאבים האלה באופן ידני. Google Cloud לדוגמה, אפשר להקצות מאזן עומסים פנימי במקום מאזן עומסים חיצוני על ידי הוספת הערה לשירות LoadBalancer.

אימות עומסי העבודה

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

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

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

חשיפת עומסי העבודה

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

כדי לחשוף עומסי עבודה שפועלים בסביבת GKE, אפשר להשתמש בשירותי Kubernetes וב-service mesh.

מידע נוסף על חשיפת עומסי עבודה שפועלים ב-GKE זמין במאמרים הבאים:

העברת תנועה לסביבה Google Cloud

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

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

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

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

  • מאזן עומסים של Cloud Load Balancing שהוגדר ידנית, שאליו מצורפים הרכיבים הבאים:

    לאחר מכן מגדירים את מאזן העומסים כך שיעביר בהדרגה את תעבורת הנתונים מסביבת המקור לסביבת GKE. בשיטה הזו, אתם מעבירים את איזון העומסים ל-Cloud Load Balancing, אבל אתם צריכים להגדיר את מאזן העומסים בעצמכם. הטכניקה הזו יוצרת גם בעיות אם רוצים לעבור למאזן עומסים שמנוהל על ידי GKE, למשל כשמקצים שער Kubernetes,‏ Ingress או שירות מסוג LoadBalancer.

  • שרת proxy שמוטמע בסביבת GKE ויכול להעביר תנועה מסביבת GKE לסביבת המקור. לאחר מכן מגדירים את Cloud Service Mesh כך שיעביר בהדרגה את תעבורת הנתונים משרת ה-proxy למופעים של עומסי העבודה שנפרסו ב-GKE.

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

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

הוצאה משימוש של סביבת המקור

אחרי שעומסי העבודה בסביבת GKE משרתים בקשות בצורה תקינה, משביתים את סביבת המקור.

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

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

כדי להוציא משימוש את סביבת המקור:

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

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

אופטימיזציה של Google Cloud הסביבה

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

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

חוזרים על הרצף הזה עד שמשיגים את יעדי האופטימיזציה.

מידע נוסף על אופטימיזציה של סביבת Google Cloud זמין במאמרים מעבר אל Google Cloud: אופטימיזציה של הסביבה וGoogle Cloud מסגרת Well-Architected: אופטימיזציה של ביצועים.

בקטעים הבאים משולבים השיקולים שמופיעים במאמר בנושא מעבר אל Google Cloud: אופטימיזציה של הסביבה.

הגדרת דרישות האופטימיזציה

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

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

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

אבטחה, פרטיות ותאימות

אמינות

  • שיפור המהימנות של האשכולות. כדי לעזור לכם לתכנן אשכול GKE שהוא עמיד יותר להפסקות לא סבירות של אזורים, מומלץ להשתמש באשכולות אזוריים במקום באשכולות אזוריים או רב-אזוריים.

  • גיבוי ושחזור של עומסי עבודה. להגדיר תהליך עבודה לגיבוי ולשחזור של עומסי עבודה באמצעות גיבוי ל-GKE.

הוזלת עלויות

מידע נוסף על אופטימיזציה של העלויות בסביבת GKE זמין במאמרים הבאים:

יעילות תפעולית

כדי למנוע בעיות שמשפיעות על סביבת הייצור, מומלץ:

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

למידע נוסף על הגדרת מעקב, רישום ביומן ופרופילים בסביבת GKE, אפשר לעיין במאמרים הבאים:

אופטימיזציה של הביצועים

  • הגדרה של התאמה אוטומטית לעומס (autoscaling) באשכול וניהול הקצאות אוטומטי של צמתים. כדי לשנות את הגודל של אשכול GKE באופן אוטומטי בהתאם לביקוש, אפשר להשתמש בהתאמה אוטומטית לעומס באשכול ובהקצאה אוטומטית של צמתים.
  • התאמה אוטומטית של עומסי עבודה. ‫GKE תומך בכמה מנגנוני שינוי גודל, כמו:
    • שינוי אוטומטי של עומסי העבודה על סמך מדדים.
    • שינוי הצורה של מספר ה-Pods בעומסי העבודה של Kubernetes כדי לשנות את גודל עומסי העבודה באופן אוטומטי באמצעות הגדרה של Horizontal Pod Autoscaling.
    • כדי לשנות את בקשות המשאבים והמגבלות שלהם ולהתאים את עומסי העבודה באופן אוטומטי, צריך להגדיר התאמה אנכית של קבוצות Pod לעומס.

מידע נוסף זמין במאמר מידע על יכולות המדרגיות של GKE.

המאמרים הבאים

שותפים ביצירת התוכן

מחברים: