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

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

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

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

כן. אדמינים בארגון יכולים לאכוף את אילוץ מדיניות הארגון compute.managed.disableVmsWithContainerStartupAgent כדי להשבית את היצירה של משאבים שמשתמשים בסוכן ההפעלה של המאגר ובמפתח המטא-נתונים 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 יכול להוביל לחיסכון בעלויות, במיוחד באפליקציות עם שימוש משתנה. בניגוד למכונות וירטואליות שחייבים לשלם עליהן גם כשהן לא פעילות, השירותים המנוהלים האלה יכולים להיות יעילים יותר. בנוסף, רמות שירות חינמיות יכולות להפחית עוד יותר את העלויות של עומסי עבודה קטנים וזמניים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

קבלת תמיכה

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

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

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

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