העברה מ-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 בכמה אזורים.
  • יצירה ומחיקה אוטומטיות של מאגרי צמתים באמצעות הקצאת צמתים אוטומטית (NAP).
  • רשתות מרובות אשכולות בניהול 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. מאמתים את תוכנית ההעברה.

מידע נוסף על שלב ההערכה ועל המשימות האלה זמין במאמר Migrate to Google Cloud: Assess and discover your workloads. הקטעים הבאים מבוססים על מידע שמופיע במאמר הזה.

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

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

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

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

בנוסף לנתונים שמתקבלים מ-Migration Center, כדאי לשקול את נקודות הנתונים הבאות לגבי כל אשכול 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. הגישה הזו מבוססת על משאבים ב-Terraform Provider של Google Cloud .
    • תוכנית לניהול של תשתיות לארגונים: מתחילים מתשתית מקובעת ומאזורי נחיתה. הגישה הזו מבוססת על מודולים ותוכניות לניהול של 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 ולהשתמש בסנכרון תצורות כדי להחיל את ההגדרה הזו.

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

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

כדי להאיץ את משימות סקר הקוד וארגון הקוד מחדש (Refactoring), אתם יכולים להשתמש ב-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. הקצאת מאגרי פריטי מידע שנוצרו בתהליך פיתוח (artifacts) ב- Google Cloud. לדוגמה, אפשר להשתמש ב-Artifact Registry כדי לאחסן פריטי מידע שנוצרו בתהליך פיתוח ויחסי תלות בגרסת build.
  2. מבצעים רפקטורינג בתהליכי ה-build כדי לאחסן את הארטיפקטים גם בסביבת המקור וגם ב-Artifact Registry.
  3. מבצעים רפקטורינג לתהליכי הפריסה כדי לפרוס את עומסי העבודה בסביבת היעדGoogle Cloud . לדוגמה, אפשר להתחיל בפריסה של קבוצת משנה קטנה של עומסי העבודה ב- Google Cloud, באמצעות ארטיפקטים שמאוחסנים ב-Artifact Registry. לאחר מכן, מגדילים בהדרגה את מספר עומסי העבודה שנפרסים ב- 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 כדי לאחסן את הארטיפקטים, מומלץ להגדיר אמצעי בקרה שיעזרו לכם לאבטח את מאגרי הארטיפקטים, כמו בקרת גישה, מניעת גניבת נתונים, סריקת פגיעויות ו-Binary Authorization. מידע נוסף זמין במאמר בנושא שליטה בגישה לארטיפקטים והגנה עליהם.

העברת נתונים

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

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

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

  1. הקצאה והגדרה של כל תשתית האחסון הנדרשת.
  2. צריך להגדיר מנהלי הקצאות (provisioners) של StorageClass באשכולות GKE. לא כל מנהלי הקצאות (provisioners) של StorageClass תואמים לכל הסביבות. לפני שפורסים מנהל הקצאות (provisioner) של 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 Framework: אופטימיזציה של ביצועים.

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

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

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

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

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

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

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

אמינות

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

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

הוזלת עלויות

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

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

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

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

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

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

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

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

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

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

מחברים: