בדף הזה מוסבר על זמן הריצה של קונטיינרים containerd, על התמיכה ב-Docker ב-Google Kubernetes Engine (GKE), ועל הסיבות שבגללן צריך לבצע מיגרציה לתמונות צמתים שמשתמשות ב-containerd.
סקירה כללית
צמתי Kubernetes משתמשים בזמן הריצה של הקונטיינר כדי להפעיל, לנהל ולעצור קונטיינרים שפועלים ב-Pods. פרויקט Kubernetes מסיר את התמיכה המובנית בזמן הריצה של Docker ב-Kubernetes בגרסה 1.24 ואילך. כדי לעשות את זה, Kubernetes מסירה רכיב שנקרא dockershim, שמאפשר ל-Docker לתקשר עם רכיבי Kubernetes כמו kubelet.
Containerd, זמן הריצה החדש שמוגדר כברירת מחדל, הוא זמן ריצה של קונטיינרים לפי תקן התעשייה, שנתמך על ידי Kubernetes ומשמש פרויקטים רבים אחרים. זמן הריצה של containerd מספק את ההפשטה של השכבות שמאפשרת הטמעה של מערך עשיר של תכונות כמו gVisor וImage streaming כדי להרחיב את הפונקציונליות של GKE. סביבת ההרצה גם נחשבת ליעילה יותר מבחינת משאבים ומאובטחת יותר מסביבת ההרצה של Docker.
בגלל השינוי הזה, GKE לא תומך בתמונות צומת שמשתמשות ב-Docker כזמן הריצה ב-GKE מגרסה 1.24 ואילך. אשכול מושפע אם אחד ממאגרי הצמתים שלו משתמש בתמונות צמתים מבוססות Docker או משתמש בהקצאה אוטומטית של צמתים עם סוג ברירת מחדל של תמונת צומת מבוססת Docker.
לפני 31 ביולי 2023, תאריך סוף חיי המוצר של GKE בגרסה 1.23, מערכת GKE משהה את השדרוגים האוטומטיים ומונעת שדרוגים ידניים לגרסה 1.24. כדי לשדרג את מישור הבקרה של האשכול לגרסה 1.24 של GKE ומעלה לפני התאריך הזה, צריך לעדכן את ההגדרה של הקצאת הצמתים האוטומטית ואת כל הצמתים לזמן הריצה של containerd. כדי לשדרג מאגר צמתים, צריך לעבור לתמונת צומת שמשתמשת בזמן הריצה של containerd.
אחרי שגרסה 1.23 תגיע לסוף חיי המוצר, GKE יבטל את החסימה של שדרוגים ידניים של מישור הבקרה לגרסה 1.24 באשכולות שעדיין לא סיימו את ההעברה, ויתחיל בהדרגה לשדרג את האשכולות למטרות אבטחה ותאימות. מידע נוסף על שדרוג האשכולות לגרסה 1.24 ב-GKE ועל הפעולות המומלצות להעברת האשכולות מתמונות של צומתי Docker זמין במאמר העברה אוטומטית כשגרסה 1.23 מגיעה לסוף חיי המוצר.
קובצי אימג' של צמתים ב-Docker וב-containerd
Containerd היא סביבת זמן הריצה שמוגדרת כברירת מחדל לכל צומתי GKE חדשים החל מגרסה 1.19 ב-Linux ומגרסה 1.21 ב-Windows. עם זאת, אשכולות GKE Standard המשיכו לתמוך גם בתמונות צמתים שהשתמשו ב-Docker כסביבת זמן הריצה. בטבלה הבאה מפורטים קובצי אימג' של צמתים מבוססי Docker שלא נתמכים ב-GKE מגרסה 1.24 ואילך, והמקבילים שלהם ב-containerd:
| זמן ריצה של Docker | זמן ריצה של containerd |
|---|---|
מערכת הפעלה שמותאמת לקונטיינרים עם Docker (cos) |
מערכת הפעלה שמותאמת לקונטיינרים עם containerd (cos_containerd) |
Ubuntu עם Docker (ubuntu) |
Ubuntu עם containerd (ubuntu_containerd) |
Windows Server LTSC עם Docker (windows_ltsc) |
Windows Server LTSC עם containerd (windows_ltsc_containerd) |
ציר זמן ואבני דרך
בגרסה 1.23 של GKE, כבר אי אפשר לבצע את הפעולות הבאות:
- ליצור אשכולות חדשים שמשתמשים בתמונות צמתים מבוססות Docker.
- להוסיף מאגרי צמתים חדשים עם תמונות צמתים מבוססות Docker לאשכול קיים.
- מפעילים הקצאת צמתים אוטומטית (NAP) באמצעות הדגל
--autoprovisioning-image-typeשמוגדר לתמונות צמתים מבוססות Docker.
אם משדרגים לגרסה 1.23 של GKE, אפשר להמשיך להשתמש בפריטים הבאים:
- מאגרי צמתים קיימים עם תמונות צמתים מבוססות-Docker שנוצרו לפני השדרוג.
- Cluster Autoscaler במאגרי צמתים עם תמונות צמתים של Docker.
- הקצאת צמתים אוטומטית (NAP) עם הדגל
--autoprovisioning-image-typeשמוגדר לתמונות צמתים מבוססות Docker, אם ההגדרה הזו הופעלה לפני השדרוג.
בגרסה 1.24 של GKE, אי אפשר יותר לבצע את הפעולות הבאות:
- אם מישור הבקרה מריץ גרסה 1.24, אי אפשר להשתמש באספקת צמתים אוטומטית עם הדגל
--autoprovisioning-image-typeשמוגדר לתמונות צמתים מבוססות Docker. - אם מאגר הצמתים מריץ גרסה 1.24, הצמתים לא יכולים להשתמש בתמונות צמתים מבוססות Docker.
בטבלה הבאה מפורטים השינויים הצפויים כשמשתמשים בגרסאות GKE עתידיות:
| פעולה | GKE version 1.23 | GKE version 1.24 |
|---|---|---|
| יצירת אשכולות חדשים באמצעות Docker | לא | לא |
| יצירת מאגרי צמתים חדשים באמצעות Docker | לא | לא |
| הפעלת הקצאת צמתים אוטומטית (NAP) באמצעות Docker | לא | לא |
| שדרוג מגרסה קודמת עם הגדרה קיימת של הקצאת משאבים אוטומטית של צומת Docker | כן | לא |
| שימוש בקובצי אימג' של צמתים מבוססי Docker | כן | לא |
העברה אוטומטית כשגרסה 1.23 מגיעה לסוף חיי המוצר
אם לא תשדרגו לגרסה 1.24 ותעברו לקובצי אימג' של צמתים של containerd לפני שגרסה 1.23 תגיע לסוף חיי המוצר ב-31 ביולי 2023, מערכת GKE תבצע את הפעולות הבאות לאורך זמן:
אם באשכול שלכם מופעל הקצאת צמתים אוטומטית (NAP) עם סוג ברירת מחדל של תמונת צומת שמבוסס על Docker, GKE מעדכן את ההגדרה כך שישתמש בתמונת הצומת המקבילה שמבוססת על זמן הריצה containerd. אי אפשר לחסום את הפעולה הזו באמצעות החרגה של תחזוקה. כדי לוודא שלא תהיה השפעה שלילית על עומסי העבודה, מומלץ לעדכן ידנית את סוג ברירת המחדל של תמונת הקצאת צמתים אוטומטית (NAP) לתמונה שמבוססת על containerd לפני ש-GKE יעודכן אוטומטית.
GKE משדרג את מישור הבקרה של האשכול לגרסה 1.24.
מערכת GKE תעביר את כל מאגרי הצמתים שעדיין משתמשים ב-Docker לקובצי אימג' של צמתים של containerd החל מ-1 בספטמבר 2023. מומלץ להעביר את תמונות הצמתים באופן ידני לפני התאריך הזה. לחלופין, אתם יכולים לבקש מ-GKE להתחיל פעולה להעברת האשכול שלכם לשימוש בתמונות containerd. כדי לשלוח את הבקשה הזו, צריך לפנות אל Cloud Customer Care.
כדי לחסום באופן זמני את ההעברה האוטומטית, צריך לשדרג את האשכול לגרסה 1.24 ואילך ולהגדיר החרגה מתחזוקה. מידע נוסף על החרגה של תחזוקה זמין במאמר בנושא השהיה זמנית של ההעברה האוטומטית לתמונות של צומתי containerd.
מערכת GKE משדרגת מאגרי צמתים בגרסה 1.23 לגרסה 1.24, כמו שקורה עם כל גרסה לא נתמכת, כדי לוודא שהתקינות של האשכול תואמת למדיניות לגבי הבדלים בין גרסאות קוד פתוח. מידע נוסף מופיע במאמר על מחזור החיים של גרסאות משניות של GKE. אפשר לחסום זמנית את השדרוג הזה באמצעות החרגה לצורך תחזוקה.
השהיה זמנית של ההעברה האוטומטית לתמונות של צומתי containerd
אחרי שרמת הבקרה של האשכול תשודרג לגרסה 1.24 ואילך, תוכלו להגדיר החרגה של תחזוקה כדי למנוע באופן זמני את העברת הצמתים עד 29 בפברואר 2024, שבו גרסה 1.25 תגיע לסוף התמיכה.
כדי לעמוד בדרישות להחרגה הזו מתחזוקה, האשכול שלכם צריך להיות רשום בערוץ הפצה.
מגדירים את ההחרגה של תחזוקה באמצעות ההגדרה 'ללא שדרוגים משניים או שדרוגים של צמתים', ומגדירים את הדגל --add-maintenance-exclusion-end לערך 2024-02-29T00:00:00Z או לערך מוקדם יותר. מומלץ לבטל את החסימה של ההעברה בהקדם האפשרי ולאפשר את השדרוג של הצמתים לגרסה 1.24. גרסאות משניות שהגיעו לסוף תקופת התמיכה לא יקבלו יותר תיקוני אבטחה ותיקוני באגים.
מעבר מקובצי אימג' של צמתים ב-Docker לקובצי אימג' של צמתים ב-containerd
במסגרת מודל האחריות המשותפת של GKE, באחריות הלקוח לשמור על תקינות עומסי העבודה, ובאחריות Google לוודא שהאשכול יישאר תקין, כולל הפעלת גרסה נתמכת. מומלץ מאוד לבדוק את עומסי העבודה ולהעביר את האשכול לפני ש-GKE יעשה זאת באופן אוטומטי.
לפני שגרסה 1.23 תצא משימוש, GKE ימנע שדרוגים אוטומטיים או ידניים לגרסה 1.24 באשכולות שיש להם מאגרי צמתים שמשתמשים בתמונות צמתים של Docker. אחרי שמעבירים את האשכול לשימוש רק בתמונות של containerd, אפשר להמשיך בשדרוגים אוטומטיים תוך יום – בהתאם ללוח הזמנים לפרסום של GKE – או לשדרג את האשכול באופן ידני.
אחרי שגרסה 1.23 תצא משימוש, GKE יבטל את החסימה של שדרוגים אוטומטיים או ידניים לגרסה 1.24, ויפעל לפי תהליך ההעברה האוטומטית.
ההשפעה של ההעברה
השינוי העיקרי כשעוברים לקובצי אימג' של צמתים של containerd הוא ש-Docker כבר לא מנהל את מחזור החיים של הקונטיינרים (למשל, הפעלה והפסקה שלהם). לכן אי אפשר להשתמש בפקודות Docker או ב-Docker API כדי להציג או ליצור אינטראקציה עם קונטיינרים של GKE שפועלים בצמתים שמשתמשים בתמונות של containerd.
לרוב עומסי העבודה של המשתמשים אין תלות בזמן הריצה של הקונטיינר. סביבת זמן הריצה של Docker גם מטמיעה את containerd, כך שעומסי העבודה מתנהגים באופן דומה בקובצי אימג' של צמתים של containerd.
יכול להיות שהשינוי ישפיע עליכם אם אחד מהמצבים הבאים רלוונטי לגביכם:
- אתם מריצים Pods עם הרשאות שמבצעים פקודות Docker.
- מריצים סקריפטים בצמתים מחוץ לתשתית Kubernetes (לדוגמה, כדי להשתמש ב-SSH לפתרון בעיות).
- אתם מפעילים כלים של צד שלישי שמבצעים פעולות עם הרשאות דומות.
- חלק מהכלים שלכם מגיבים ליומנים ספציפיים של Docker במערכת המעקב שלכם.
- אתם פורסים באשכול GKE כלים לרישום ביומן, למעקב, לאבטחה או לאינטגרציה רציפה שסופקו על ידי ספקים חיצוניים. כדי לברר את ההשפעה, צריך לפנות לספקים האלה.
לא תושפעו במקרים הבאים:
- יש לכם צינור עיבוד נתונים (pipeline) מחוץ לאשכול GKE שמשתמש ב-Docker כדי ליצור קובצי אימג' של קונטיינרים ולהעביר אותם בדחיפה.
- אתם משתמשים בפקודות
docker buildו-docker pushבאשכול GKE. קובצי אימג' של צמתים ב-Linux עם containerd כוללים את קובץ ה-Docker הבינארי ותומכים בפקודות האלה.
שימוש ב-Pods עם הרשאות מיוחדות כדי לגשת ל-Docker
אם המשתמשים שלכם ניגשים ל-Docker Engine בצומת באמצעות Pod עם הרשאות, כדאי לעדכן את עומסי העבודה האלה כך שלא תהיה תלות ישירה ב-Docker. לדוגמה, אפשר להעביר את תהליך החילוץ של הרישום ביומן והמעקב מ-Docker Engine לתוספים של מערכת GKE.
פיתוח קובצי אימג' של קונטיינרים באמצעות containerd
אי אפשר להשתמש ב-containerd כדי ליצור קובצי אימג' של קונטיינרים. קובצי אימג' של Linux עם containerd כוללים את קובץ ה-Docker הבינארי, כך שאפשר להשתמש ב-Docker כדי ליצור קובצי אימג' ולהעביר אותם בדחיפה. עם זאת, לא מומלץ להשתמש בקונטיינרים בודדים ובצמתים מקומיים כדי להריץ פקודות ליצירת תמונות.
מערכת Kubernetes לא מודעת למשאבי המערכת שמשמשים תהליכים מקומיים מחוץ להיקף של Kubernetes, ורמת הבקרה של Kubernetes לא יכולה להתחשב בתהליכים האלה כשמקצים משאבים. הפעולה הזו עלולה לגרום למחסור במשאבים בעומסי העבודה של GKE או לאי יציבות בצומת.
כדאי לבצע את המשימות האלה באמצעות שירותים אחרים מחוץ להיקף של הקונטיינר הספציפי, כמו Cloud Build, או להשתמש בכלי כמו kaniko כדי ליצור תמונות כעומס עבודה של Kubernetes.
אם אף אחת מההצעות האלה לא מתאימה לכם, ואתם מבינים את הסיכונים, אתם יכולים להמשיך להשתמש ב-Docker בצומת המקומי כדי ליצור קובצי אימג'. כדי להשתמש בתמונות באשכול GKE, צריך להעביר אותן למאגר. מערכת Kubernetes עם containerd לא מודעת לקובצי אימג' שנוצרו מקומית באמצעות Docker.
ניפוי באגים בקונטיינרים בצמתים של containerd
כדי לבצע ניפוי באגים או לפתור בעיות בצמתי Linux, אפשר ליצור אינטראקציה עם containerd באמצעות כלי שורת הפקודה הנייד שנוצר עבור זמני ריצה של קונטיינרים ב-Kubernetes: crictl. crictl תומך בפונקציות נפוצות לצפייה בקונטיינרים ובקובצי אימג', לקריאת יומנים ולהרצת פקודות בקונטיינרים. במדריך למשתמש של crictl אפשר למצוא את כל התכונות הנתמכות ומידע על השימוש בהן.
בצמתים של Windows Server, הדמון containerd פועל כשירות Windows בשם containerd.
היומנים זמינים באופן הבא:
- ב-Windows:
C:\etc\kubernetes\logs\containerd.log - Linux: מריצים את
journalctl -u containerd
אפשר גם לראות את היומנים של צמתי Windows ו-Linux ב-Logs Explorer בקטע LOG NAME: "container-runtime".
פתרון בעיות
לפתרון בעיות, אפשר לעבור אל פתרון בעיות שקשורות לזמן הריצה של containerd.