בדף הזה מוסבר על זמן הריצה של קונטיינר 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-based node images, אם ההגדרה הזו הופעלה לפני השדרוג.
בגרסה 1.24 של GKE, אי אפשר יותר לבצע את הפעולות הבאות:
- אם מישור הבקרה מריץ גרסה 1.24, אי אפשר להשתמש באספקת צמתים אוטומטית עם הדגל
--autoprovisioning-image-typeשמוגדר לתמונות צמתים מבוססות Docker. - אם מאגר הצמתים מריץ גרסה 1.24, הצמתים לא יכולים להשתמש בתמונות צמתים מבוססות Docker.
בטבלה הבאה מופיע סיכום של השינויים הצפויים כשמשתמשים בגרסאות GKE עתידיות:
| פעולה | GKE version 1.23 | GKE version 1.24 |
|---|---|---|
| יצירת אשכולות חדשים באמצעות Docker | לא | לא |
| יצירת מאגרי צמתים חדשים באמצעות Docker | לא | לא |
| הפעלת הקצאת משאבים אוטומטית של צמתים באמצעות Docker | לא | לא |
| שדרוג מגרסה קודמת עם הגדרה קיימת של הקצאת משאבים אוטומטית של צומת Docker | כן | לא |
| שימוש בקובצי אימג' של צמתים מבוססי Docker | כן | לא |
העברה אוטומטית כשגרסה 1.23 תגיע לסוף החיים
אם לא תשדרגו לגרסה 1.24 ותעברו לקובצי אימג' של צמתים של containerd לפני שגרסה 1.23 תגיע לסוף תקופת החיים שלה ב-31 ביולי 2023, מערכת GKE תבצע את הפעולות הבאות לאורך זמן:
אם באשכול מופעל הקצאת צמתים אוטומטית (NAP) עם סוג ברירת מחדל של תמונת צומת שמבוסס על Docker, GKE מעדכן את ההגדרה כך שישתמש בתמונת הצומת המקבילה שמבוססת על זמן הריצה containerd. אי אפשר לחסום את הפעולה הזו באמצעות החרגה של תחזוקה. כדי לוודא שלא תהיה השפעה שלילית על עומסי העבודה, מומלץ לעדכן באופן ידני את סוג התמונה שמוגדר כברירת מחדל להקצאת צמתים אוטומטית לתמונה שמבוססת על 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.
יכול להיות שהשינוי ישפיע עליכם אם אחד מהמצבים הבאים רלוונטי לגביכם:
- אתם מריצים תרמילי Pod עם הרשאות שמבצעים פקודות 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.