הכנות להשבתת הסוכן להפעלת קונטיינרים

הוצאנו משימוש את הסוכן להפעלת קונטיינרים שפורס קונטיינרים במכונות ב-Compute Engine במהלך יצירת מכונת VM.

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

מידע כללי

מהו סוכן הפעלה של מאגר ב-Compute Engine?

הסוכן להפעלת קונטיינרים מאפשר לפרוס ולהגדיר קונטיינרים במכונות ב-Compute Engine או במכונות בקבוצת מופעי מכונה מנוהלים (MIG) במהלך יצירת מכונה וירטואלית, ומפעיל קונטיינר Docker.

למה הוצא משימוש סוכן הפעלת מאגר התגים?

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

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

מהן אבני הדרך העיקריות בתהליך ההוצאה משימוש, ומה יקרה אם לא אבצע פעולה עד המועד האחרון?

החל מ-31 ביולי 2026, כל תהליכי העבודה שמסתמכים על סוכן הפעלת מאגר התגים או על מטא-נתונים של מופע gce-container-declaration יפסיקו לפעול.

החל מ-31 ביולי 2027,‏ Google תפסיק את התמיכה בסוכן הפעלת הקונטיינר ולא יסופקו יותר עדכונים למכונות וירטואליות פעילות שמשתמשות במטא-נתונים gce-container-declaration. אתם מריצים את עומסי העבודה על אחריותכם בלבד, והדבר עלול להשפיע על תהליך העבודה שלכם.

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

מתי כבר לא אוכל ליצור מכונות וירטואליות חדשות או קבוצות של מכונות וירטואליות לניהול מופעים (MIG) עם קונטיינרים שנפרסו ישירות באמצעות מטא-נתונים של gce-container-declaration?

12 חודשים מההודעה הראשונית על הוצאה משימוש, כלומר 31 ביולי 2026.

מתי כבר לא אוכל להפעיל פריסות של קונטיינרים במכונות וירטואליות או בקבוצות של מכונות וירטואליות לניהול מופעים (MIG) שמשתמשות במטא-נתונים gce-container-declaration?

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

איך הוצאת התכונה משימוש משפיעה על הגדרת Terraform שלי?

אם אתם משתמשים ב-Terraform או באוטומציה דומה כדי ליצור או לעדכן מכונות וירטואליות או קבוצות של מכונות וירטואליות לניהול מופעים (MIG) על ידי הגדרה מפורשת של מפתח המטא-נתונים gce-container-declaration, תהליך העבודה שלכם יפסיק לפעול ב-31 ביולי 2026. כדי למנוע שיבושים, צריך לעדכן את ההגדרה של Terraform כך שתשתמש בסקריפט לטעינה בזמן ההפעלה לפריסת קונטיינרים ולהסיר את התלות במפתח המטא-נתונים gce-container-declaration. הוראות מפורטות זמינות במדריך להעברת נתונים.

האם ההוצאה משימוש הזו אומרת שקובצי אימג' של מערכת הפעלה שמותאמת לקונטיינרים יוצאו משימוש?

לא, אנחנו לא מוציאים משימוש תמונות של מערכת הפעלה שמותאמת לקונטיינרים. השינוי קשור לאופן הפריסה של קונטיינרים במכונות וירטואליות שמשתמשות במערכת הפעלה שמותאמת לקונטיינרים. גרסאות חדשות יותר של מערכת הפעלה שמותאמת לקונטיינרים כבר לא יתמכו ב-konlet, סוכן ההפעלה שמשתמש במפתח המטא-נתונים gce-container-declaration כדי לפרוס קונטיינרים. קובצי אימג' של מערכת הפעלה שמותאמת לקונטיינרים עדיין זמינים ויש להם תמיכה. עם זאת, צריך לעדכן את הגדרת ה-VM כדי להשתמש בסקריפט לטעינה בזמן ההפעלה או cloud-initלפרוס קונטיינרים במקום להסתמך על מפתח המטא-נתונים gce-container-declaration.

אני משתמש ב-cloud-init כדי להריץ קונטיינרים במכונות וירטואליות. האם השינוי הזה ישפיע עליי?

לא. הוצאת התכונה משימוש לא משפיעה על מכונות וירטואליות שהוגדרו באמצעות cloud-init. אפשר להמשיך להשתמש ב-cloud-init כדי להגדיר מופעים. מידע נוסף זמין במאמר שימוש ב-cloud-init עם Cloud config.

איך אפשר לדעת אם השינוי הזה ישפיע עליי?

אם אתם פורסים קונטיינר במכונה וירטואלית במהלך יצירת המכונה הווירטואלית באמצעות סוכן הפעלת הקונטיינר או על ידי ציון gce-container-declaration, אתם מושפעים מהוצאה משימוש. כדי לבדוק אם יש מקרים שמושפעים בפרויקט שלכם,מריצים את הפקודה הבאה ב-CLI של gcloud:

gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"

הפקודה הזו מספקת רשימה של כל מכונות ה-VM בפרויקט שמכילות את מפתח המטא-נתונים gce-container-declaration. מפתח המטא-נתונים מזהה באופן ייחודי מכונות וירטואליות שנכללות בהיקף של הוצאת המוצר משימוש. אם אתם משתמשים בכמה פרויקטים, צריך להריץ את הפקודה בכל הפרויקטים הפעילים.

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

אם רוצים לבדוק מופע ספציפי, מריצים את הפקודה הבאה ב-CLI של gcloud:

gcloud compute instances describe VM_NAME

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

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

האם יש סיכון לאבטחה או לפרטיות של הפרויקט במהלך ההעברה?

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

פתרונות חלופיים

מהם הפתרונות החלופיים המומלצים לשימוש בקונטיינרים ב-Compute Engine, ואיך בוחרים את הפתרון המתאים ביותר לדרישות שלי?

אפשר לבחור באחת מהאפשרויות הבאות להעברת מאגר התגים:

• אם אתם רוצים להמשיך לפרוס קונטיינרים במכונות וירטואליות או בקבוצות של מכונות וירטואליות לניהול מופעים (MIG), או להריץ קונטיינרים לצורך בדיקה ופיתוח, או להריץ עומס עבודה שמורכב ממכונה וירטואלית אחת, אתם יכולים להשתמש בסקריפטים להפעלה או ב-cloud-init.
• אם יש לכם אפליקציות בקונטיינרים בלי שמירת מצב ועבודות קטנות עד בינוניות, כדאי לשקול שימוש ב-Cloud Run. אפשר גם להשתמש בסקריפטים להפעלה.
• אם הקונטיינר הוא משימה באצווה שיש לה מצב סיום מוגדר ונדרשים לה משאבי מחשוב נוספים, כדאי לשקול שימוש ב-Batch. אפשר גם להשתמש בסקריפטים להפעלה.
• אם אתם צריכים שליטה מתקדמת ויכולת מדרגיות, או אם אתם לא יכולים לעמוד בדרישות שלכם באמצעות האפשרויות האחרות, כדאי לשקול את GKE.

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

למה כדאי לשקול מעבר לשירות מנוהל כמו Cloud Run, ‏ GKE או Batch במקום להשתמש בסקריפט לטעינה בזמן ההפעלה?

מומלץ לשקול מעבר לפתרונות קונטיינרים כמו Google Kubernetes Engine,‏ Cloud Run ו-Batch. השירותים המנוהלים האלה מציעים יתרונות משמעותיים בהשוואה לפריסות רגילות שמבוססות על מכונות וירטואליות, כולל יכולות משופרות של הרחבת היקף הפעילות, גמישות וניהול מתקדם.

בין היתרונות המרכזיים:

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

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

מהן העלויות של כל פתרון חלופי, ואיך הן בהשוואה להגדרה הנוכחית?

סקריפטים להפעלה של פריסת קונטיינרים או cloud-init: שימוש בסקריפטים להפעלה או ב-cloud-init כתחליף ישיר לא משנה באופן מהותי את העלויות שלכם ב-Compute Engine. עדיין משלמים על משאבי מכונות וירטואליות בסיסיים.

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

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

האם הוצאה משימוש הזו אומרת שתמונות של מערכת הפעלה שמותאמת לקונטיינרים יוצאו משימוש, ולכן אם נרצה להריץ Dockers במכונות וירטואליות של Compute Engine, נצטרך להגדיר תבנית משלנו למכונה וירטואלית?

לא, התמונות של מערכת הפעלה שמותאמת לקונטיינרים עצמן לא יוצאות משימוש. השינוי הוא באופן שבו קונטיינרים מופעלים במכונות וירטואליות באמצעות מערכת הפעלה שמותאמת לקונטיינרים. גרסאות חדשות יותר של מערכת הפעלה שמותאמת לקונטיינרים לא יתמכו יותר ב-konlet, שהוא סוכן ההפעלה שמפעיל קונטיינרים באמצעות מפתח המטא-נתונים gce-container-declaration. המשמעות היא שקובצי אימג' של מערכת הפעלה שמותאמת לקונטיינרים עדיין יהיו זמינים ונתמכים. עם זאת, עליך לעדכן את ה-VM כדי להשתמש בסקריפט לטעינה בזמן ההפעלה או בהגדרה cloud-init לפריסת קונטיינרים במקום להשתמש במפתח המטא-נתונים gce-container-declaration.

תהליך המיגרציה

מה הגישה המומלצת להעברת מאגרי תגים לפתרונות החלופיים?

מומלץ לבצע את השלבים הבאים לקראת ההעברה:

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

האם אני חייב לעבור לאחד מהפתרונות המומלצים או שיש חלופות שאני יכול להשתמש בהן?

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

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

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

כמה זמן ייקח לי לעבור לאחת מהחלופות, והאם יש גורמים שיכולים להשפיע על משך הזמן שיידרש ממני?

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

שירותים מנוהלים: בחירה בGoogle Cloud פתרונות כמו Cloud Run,‏ Batch או GKE, שהם פלטפורמות PaaS מנוהלות לחלוטין ללא שרתים, עשויה לדרוש השקעה גדולה יותר של זמן ומאמץ מראש. הסיבה לכך היא השינוי המהותי מגישה שמתמקדת במכונה וירטואלית (IaaS) שבה אתם מנהלים את התשתית, למודל PaaS שבו הפלטפורמה מטפלת ברוב הפעולות האלה. יכול להיות שתצטרכו לבצע שינויים באפליקציה, כמו לוודא שהיא בלי שמירת מצב, אבל היתרונות לטווח הארוך יכולים לכלול שיפורים משמעותיים ביעילות התפעולית, במדרגיות ובחיסכון בעלויות.

הנחיות בנוגע למעבר הזה זמינות במדריך להעברת נתונים.

אם אבחר לבצע מיגרציה לחלופה, האם היא תגרום להפרעות או להשבתה של Google Cloud פרויקטים, מכונות וירטואליות, שירותים ואפליקציות?

באופן כללי, המעבר לפתרון החלופי המומלץ מתוכנן כך שלא יהיה זמן השבתה.

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

איך ההעברה הזו משפיעה על הגדרת Terraform שלי?

אם אתם משתמשים ב-Terraform או באוטומציה דומה כדי ליצור או לעדכן מכונות וירטואליות או קבוצות של מכונות וירטואליות לניהול מופעים (MIG) עם קונטיינרים על ידי הגדרה מפורשת של מפתח המטא-נתונים gce-container-declaration, תהליך העבודה שלכם יפסיק לפעול ב-31 ביולי 2026. כדי למנוע שיבושים, צריך לעדכן את ההגדרה כך שתכלול סקריפט הפעלה לפריסת מאגר התגים ולהסיר את התלות בgce-container-declarationמפתח המטא-נתונים. הוראות מפורטות להטמעת השינוי הזה זמינות במאמר העברת מאגרי תגים שנפרסו במכונות וירטואליות במהלך יצירת המכונות הווירטואליות.

קבלת תמיכה

למי אפשר לפנות ב-Compute Engine אם יש לי שאלות לגבי תהליך ההעברה?

בכל שאלה או בקשת עזרה, אפשר לפנות אל צוות התמיכה של Google Cloud.

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

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