בדף הזה מוסבר על זמן הריצה של קונטיינרים containerd, על התמיכה ב-Docker ב-Google Kubernetes Engine (GKE) ועל הסיבות שבגללן צריך לעבור לתמונות צמתים שמשתמשות ב-containerd.
סקירה כללית
צמתי Kubernetes משתמשים בזמן הריצה של הקונטיינר כדי להפעיל, לנהל ולעצור קונטיינרים שפועלים ב-Pods. פרויקט Kubernetes מסיר את התמיכה המובנית בזמן הריצה של Docker ב-Kubernetes בגרסה 1.24 ואילך. כדי לעשות את זה, Kubernetes מסירה רכיב שנקרא dockershim, שמאפשר ל-Docker לתקשר עם רכיבי Kubernetes כמו kubelet.
Containerd, זמן הריצה החדש שמוגדר כברירת מחדל, הוא זמן ריצה של קונטיינרים לפי הסטנדרט בתעשייה, שנתמך על ידי Kubernetes ומשמש פרויקטים רבים אחרים. סביבת הריצה containerd מספקת את הפשטת השכבות שמאפשרת הטמעה של מערך עשיר של תכונות כמו gVisor והזרמת תמונות כדי להרחיב את הפונקציונליות של 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 | גרסה 1.24 של GKE |
|---|---|---|
| יצירת אשכולות חדשים באמצעות Docker | לא | לא |
| יצירת מאגרי צמתים חדשים באמצעות Docker | לא | לא |
| הפעלת הקצאת צמתים אוטומטית (NAP) באמצעות Docker | לא | לא |
| שדרוג מגרסה קודמת עם הגדרת הקצאת צמתים אוטומטית (NAP) קיימת של Docker | כן | לא |
| שימוש בקובצי אימג' של צמתים מבוססי Docker | כן | לא |
העברה אוטומטית כשגרסה 1.23 מגיעה לסוף מחזור החיים
אם לא תשדרגו לגרסה 1.24 ותעברו לקובצי אימג' של צמתים של containerd לפני שגרסה 1.23 תגיע לסוף תקופת החיים שלה ב-31 ביולי 2023, מערכת GKE תבצע את הפעולות הבאות לאורך זמן:
אם באשכול מופעל הקצאת צמתים אוטומטית (NAP) עם סוג ברירת מחדל של תמונת צומת שמבוסס על Docker, GKE מעדכן את ההגדרה כך שישתמש בתמונת הצומת המקבילה שמבוססת על זמן הריצה containerd. אי אפשר לחסום את הפעולה הזו באמצעות החרגה של תחזוקה. כדי לוודא שלא תהיה השפעה שלילית על עומסי העבודה, מומלץ לעדכן באופן ידני את סוג התמונה שמוגדר כברירת מחדל להקצאת צמתים אוטומטית לתמונה שמבוססת על containerd לפני ש-GKE יעודכן אוטומטית.
מערכת GKE משדרגת את מישור הבקרה של האשכול לגרסה 1.24.
החל מ-1 בספטמבר 2023, מערכת GKE תעביר את כל מאגרי הצמתים שעדיין משתמשים ב-Docker לקובצי אימג' של צמתים מסוג containerd. מומלץ להעביר את תמונות הצמתים באופן ידני לפני התאריך הזה. לחלופין, אפשר לבקש מ-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) של build מחוץ לאשכול 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.