
cgroup v1 מת ב-Kubernetes: מה על מפעילים לדעת הלאה
Kubernetes הפסיקה את התמיכה ב-cgroup v1 וממשק ניהול משאבי הקונטיינרים ההיסטורי חותם את דורו. מפעילים שעדיין פועלים על מערכות ישנות חייבים עכשיו לתכנן את המעבר ל-cgroup v2.
Kubernetes סגרה את הדלת בפני cgroup v1
התמיכה ב-cgroup v1 ב-Kubernetes הסתיימה, ובכך נקבעה קו תחתונה לעידן של אחד הממשקים העתיקים ביותר ששימשו להגבלת משאבי קונטיינרים. The New Stack כתב על השינוי ב-9 באוקטובר 2026 והציג אותו כסיום סופי, ולא כאזהרה שהוכבדה על ידי התיישנות.
עבור קהילת Kubernetes צעד זה מסמן את סיום תקופת מעבר ארוכה. cgroup v1 שימש במשך שנים כממשק ההיסטורי לבידוד משאבים ב-Linux, ו-cgroup v2 הוא היורש המוכרז שלו. עכשיו, כש-v1 כבר רשמית מחוץ לפרויקט, כל תלות שנותרה בו מהווה סיכון ולא אסטרטגיה ארוכת טווח בתוקף.
מה זה אומר עבור צטרים שעדיין נמצאים על ממשק ישן
מפעילים שהצמתים או ההפצות המנוהלות שלהם עדיין משתמשים ב-cgroup v1 כברירת מחדל צריכים להגדיר את המיגרציה כעדיפות. תמונות הצטר, מערכות ההפעלה של הצמתים ו-runtime-י הקונטיינרים קובעים איזו גרסת cgroup נמצאת בשימוש על ידי העומס העובד, ולכן השינוי נוגע לכל הסטאק ולא רק למתג תצורה אחד.
במקור לא תוארה דרך מסוימת לעדכון נתמך, אך הכיוון ברור: צוותים צריכים לבדוק את הציים שלהם, לאתר על איזו גרסת cgroup פועלים הצמתים שלהם ולתכנן את המעבר ל-cgroup v2 בכל סביבה.
מה יהיה הלאה
סיום התמיכה ב-cgroup v1 יסייע לחסל מקור פרגמנטציה מתמיד במערכת האקולוגית. בהפצות קלות ומוכוונות edge, שבהן ממשקים ישנים לעיתים נשארים, השינוי מורגש במיוחד, מכיוון שסביבות כאלה פועלות לעיתים קרובות על מערכות הפעלה מינימליות או מותאמות אישית ויש צורך לבדוק תאימות ל-cgroup v2.
עבור הקהילה הרחבה יותר של Kubernetes שינוי זה הוא שלב ניקוי שמאפשר לפרויקט להתמקד בממשק אחד ועכשווי לניהול משאבים. עבור מפעילים המסר המעשי פשוט: אמתו את cgroup v2 בכל הצי, שדרגו את כל מה שעדיין תלוי בממשק הישן וראו ב-cgroup v1 כדבר שהלך לעולמו.
מקורות: The New Stack
SiTech — פיתוח אתרים בכוח ה-AI
אנחנו בונים אתרים מהירים ומודרניים ומשלבים AI בתהליכי עבודה אמיתיים. יש לכם פרויקט או שאלה? נשמח לעזור.