אשכול DOKS: מה נשבר ללא תפעול מנוהל
אשכול מנוהל מסיר מהצוות רק את שכבת הניהול: מאגרי צמתים, מגבלות משאבים, עדכונים ותרחישי חירום נשארים בצד התפעול. אם לאחר הפריסה האשכול חי בלי נהלים, הגדרת DOKS מצטמצמת להרצה מוצלחת אחת — ומכאן והלאה התשתית מתדרדרת לפי תרחיש צפוי.
הכשל הטיפוסי הראשון — הידרדרות השירות תחת עומס. בתיאורי workloads אין requests ו-limits, pods מונחים על הצמתים בצורה לא מאוזנת, ה-autoscaling מוגדר לפי מדד אחד שלא משקף את העומס האמיתי.
בשיא, האפליקציות נתקלות בתקרת ה-pool, חלק מה-pods תלויים בהמתנה למשאבים, זמן התגובה עולה — והשירות נכשל לפני שה-scaling מספיק לפעול.
השני — כשל של צומת אחת הופך להשבתה של האשכול. אין readiness probes ו-PodDisruptionBudgets, ולכן pods שנדחקו מופעלים מחדש על הצמתים שנותרו ומכלים אותם בזיכרון.
סיפור נפרד — עדכוני גרסה ידניים דרך הקונסולה: בלי תוכנית, בלי הוצאה חלקה של צמתים מהרוטציה ובלי נקודת חזרה, שבה צעד כושל עוצר את כל האשכול.
השלישי — היעדר שחזור צפוי. אין גיבויים של המצב, התשתית מתוארת לא ב-repository אלא בראשים, ואין rollback בדוק. זמן השחזור לא נמדד, והוא תלוי במי מהמהנדסים זוכר איך האשכול הורכב.
כל שלושת התרחישים נסגרים באותה צורה — נהלי תפעול תשתית: limits ו-reservations, עדכונים אוטומטיים, rollback בדוק והתראות על צמתים. נסביר איך זה בנוי בפועל.
מה משתנה לאחר העברת האשכול לתפעול
לפני העברת האשכול לתפעול כמעט כל שינוי נעשה ביד: מהנדס מתקן קונפיגורציה, מעדכן צמתים ידנית, עוקב אחר ניצולת לפי גרפים. לאחר ההעברה הפעולות האלה הופכות לשגרתיות, ומצב ה-pools והעומסים מתואר באופן דקלרטיבי ונשמר במערכת בקרת גרסאות.
הפלטפורמה DigitalOcean מספקת מטריקות ואירועים של צמתים, שעליהם נבנים פתרונות אוטומטיים — בלעדיהם האוטומציה הייתה עובדת בעיוורון.
עדכון צמתים ללא השבתה מבוסס על דחיקת עומס: הצומת נסגרת למשימות חדשות, replicas עוברות לצמתים בריאות, ולאחר החלפת ה-image הצומת חוזרת ל-pool. השירות ממשיך להגיב כי ה-replicas מפוזרות בין zones, וחלונות התחזוקה לא חופפים לשיאים.
Autoscaling פותר שתי משימות שונות: מספר ה-replicas של השירות גדל לפי עומס, ומספר הצמתים ב-pool — לפי הניצולת האמיתית שלהם. המגבלות נקבעות מראש, לכן השיא מרחיב את האשכול, והשפל מחזיר אותו לגודל הבסיסי בלי התערבות ידנית.
עמידות בכשלים נבדקת בהתנהגות, לא בתרשים: באובדן צומת המשימות מופעלות מחדש על צמתים בריאות, זמן השחזור של השירות נמדד בדקות, לא בזמן עד להגעת התורן. התראות על אירועים מרכזיים באשכול מטופלות, וכל כשל מסתיים בתיקון קונפיגורציה.
אפשרויות פריסת DOKS: השוואת מצבים
DOKS לוקח על עצמו את ה-control plane, אבל מצב הפריסה והתפעול נשאר בידינו: כמה node pools להקים, איך לפזר ביניהם עומסים ואיפה נגמרת האוטומציה. DigitalOcean נותן פרימיטיבים זהים בכל המצבים — ההבדל הוא כמה בידוד עומסים ואוטומציה אנחנו בונים עליהם.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| pool צמתים אחד | שירות אחד או סביבת בדיקה עם תעבורה אחידה | אין בידוד: שכן רועש דוחק pods, וה-autoscaling של הצמתים בוחר גודל אחד לכל המשימות |
| pools נפרדים לעומסים שונים | API, תורים, batch ושירותי stateful באשכול אחד | נדרשים taints, tolerations ו-nodeSelector, מספר הצמתים והיקף העדכונים גדל |
| ניהול ידני של pools | תעבורה צפויה, חלונות שינויים נוקשים | השיא מטופל ביד, הקיבולת נשמרת עם מרווח ועומדת ללא שימוש |
| העברת תפעול מלאה | אין צוות תמיכה משלכם | התגובה לאירוע איטית יותר, נדרשים נהלי גישות ומטריקות שקופות |
גבול הישימות עובר במקום שבו מתחילה אי-התאמה בין פרופילי עומס: autoscaling של צמתים פועל ברמת ה-pool, לא ברמת pod בודד, לכן שירותים מעורבים ב-pool אחד מעוותים מטריקות, והגודל נבחר באקראי. פיצול דורש תמיכה ב-taints ו-tolerations כקוד, אחרת ה-scheduler מציב pods לא במקום הנכון. לכן את המצב בוחרים לפי פרופיל העומס ודרישות הכשל, לא לפי גודל האשכול.
שלבי יישום: מביקורת ועד העברה לתפעול
את העבודה מנהלים בשלבים קבועים: בכל שלב רואים מה כבר נבדק, מה תלוי בגורמים חיצוניים ואיפה צוואר הבקבוק. הסדר אינו מקרי — הגדרה לפני ביקורת נותנת אשכול שנופל כבר בשיא הראשון. להלן הרצף שלפיו אנחנו מובילים יישום של DigitalOcean Managed Kubernetes (DOKS).
- ביקורת אשכול ופרופיל עומס. בודקים node pools, requests ו-limits של קונטיינרים, הקצאה אוטומטית של משאבים, נקודות כשל. בפלט — צריכה אמיתית בשיא, לא הנחות מהתיעוד.
- סכימת תשתית. קובעים הפרדה בין סביבות ו-namespaces, network policies, כניסת תעבורה. הסכימה המסוכמת הופכת לבסיס שלפיו נבדק כל תיקון עתידי.
- הגדרת האשכול. Node pools לפי מחלקות עומס שונות, autoscaling, עדכונים ללא השבתה, אחסונים, image registry וניקוי builds ישנים. הרשאות גישה מחלקים מיד, לא «אחר כך».
- בדיקת עמידות בכשלים. מסירים צומת, מפילים שירות, מנתקים תקשורת עם האחסון — ומודדים כמה מהר האשכול חוזר לשגרה. צווארי בקבוק שנמצאו נסגרים לפני ההעברה.
- Observability. מטריקות, לוגים והתראות מוגדרות לפי סימפטומים, לא לפי הכל: התורן מבין את סיבת התקלה בדקות, לא מפרק דשבורדים.
- נהלים. סדר עדכונים, תוכנית שחזור, סכימה, הוראות לתורן — בצורה שצוות במשמרות עובד לפיה.
- העברה לתפעול. סקירה עם הצוות שלכם, גישות, גבולות תמיכה לאחר ההפעלה — כדי שהתשתית תמשיך לחיות בלעדינו.
מה מקבלים לאחר הגדרת DOKS מלאה
לאחר ההגדרה נשאר לכם לא «אשכול שעובד», אלא ערכת ארטיפקטים: אפשר להעביר אותה לצוות אחר, לשחזר מאפס ולהעביר לתפעול בלי הסכמות בעל פה. להלן מה בדיוק הצוות מוסר לידיים ובאיזו צורה זה קיים ב-repository ובתיעוד.
- קונפיגורציות וסכימות. אשכול DOKS, node pools, network policies וקשרים עם load balancers ואחסונים מתוארים באופן דקלרטיבי, infrastructure as code. לצד זה — סכימה: איך שירותים רואים זה את זה, ואיפה עוברות נקודות הכניסה החיצוניות. הסביבה עולה מחדש מה-repository, לא נבנית ביד לפי זיכרון.
- מדיניות גישה. תפקידים והרשאות מופרדים לפי עקרון המינימום ההכרחי: קונטורים נפרדים לפיתוח ולהרצה בפרודקשן, חשבונות שירות לאוטומציה, יומן פעולות פעיל. קבוע מי ומה יכול לשנות בקונטור הפרודקשן.
- נוהל עדכונים. סדר עדכון של שכבת הניהול ו-node pools, חלונות ביצוע, כללים להוצאת צמתים מפעילות תחת עומס, תנאים ונוהל rollback. העדכון מפסיק להיות פעולה ידנית עם השבתה.
- גיבוי. מה מגבים (מצב האשכול, דיסקים של מצב, קונפיגורציה), באיזו תדירות, כמה זמן נשמר. סעיף נפרד — בדיקת שחזור בסביבת בדיקה: rollback מאומת במקום «יש גיבויים» פורמלי.
- ניטור והתראות. מטריקות של צמתים ו-workloads, ספים למשאבים ולזמינות, פאנלים לתורן. התראה מגיעה לפני שמשתמשים מדווחים על תקלה.
- תיעוד ונוהל הסלמה. סכימה ארכיטקטונית, תיאור namespaces ושירותים, הוראות לפעולות שגרתיות, רמות הסלמה עם ערוצי תקשורת וזמני תגובה. צוות הלקוח מבצע פעולות שגרתיות בעצמו, בלי לחכות לספק.
מקרה בוחן: ייצוב DOKS תחת עומס שיא
פרויקט — שירות עם תעבורה לא אחידה בחדות: שיאים גבוהים פי כמה מהעומס הבסיסי, ובלילה האשכול כמעט עומד ללא שימוש.
האשכול על DigitalOcean Managed Kubernetes גדל לפני שהגענו באופן ספונטני: node pools נוצרו ביד, requests ו-limits למשאבים כמעט לא הוגדרו, והסקיילינג נעשה בידי מהנדס תורן ממש בזמן האירוע.
המשמעות של מצב כזה — 12–15 התערבויות ידניות בשבוע. שחזור לאחר תקלה ארך 40–60 דקות: עד שהתורן הבין מה בדיוק נפל, השיא כבר הסתיים, וחלק מהבקשות הלקוחות קיבלו כשגיאת שרת.
מה שינינו
פיצלנו את העומס לשני pools: קבוע לשירותים קריטיים ואלסטי לתורים ולעיבוד רקע. הגדרנו requests ו-limits ל-CPU ולזיכרון, הפעלנו autoscaling לפי עומס ואורך התור, הוספנו readiness probes ו-PodDisruptionBudget — פריסות מתוכננות הפסיקו לפגוע בזמינות.
מה התוצאה
התערבויות ידניות נותרו 1–2 בשבוע, והן מתוכננות: עדכון images ובדיקת מכסות מחדש. זמן השחזור הצטמצם ל-3–4 דקות — pod נוצר מחדש אוטומטית, והתעבורה עוברת ל-replicas חיות. בשיאים, שיעור שגיאות השרת ירד מ-2.3% ל-0.1%, וחלון הלילה הפסיק להיות זמן לתיקונים ידניים.
במה אשכול מנוהל שונה מאשכול עצמאי?
אשכול מנוהל נבדל לא במערך היכולות, אלא במקום שבו עובר גבול האחריות. הספק מחזיק את ה-control plane: שרת API, אחסון מצב, scheduler, תעודות ועדכונים של שכבת הניהול עצמה. עליכם נשארים צמתי עבודה, פריסת שירותים, network policies, נקודות כניסת תעבורה, volumes והרשאות גישה.
באשכול עצמאי השכבה הזו הופכת לאזור האחריות שלכם. עדכון רכיבי ניהול, רוטציית תעודות, שחזור לאחר כשל של צומת עם מצב, גיבויים — לא עבודה חד-פעמית בהפעלה, אלא רקע קבוע. מאמץ העבודה של הצוות לא מסתכם בתורנות: מהנדס אחד מחזיק את הנושא, אבל כל הצוות חוזר אליו.
מהירות השינויים שונה יותר ממה שנדמה. אשכול מנוהל נפרס ונוצר מחדש באופן דקלרטיבי מתוך תיאור, ועדכון שכבת הניהול הוא הליך של הספק שלא דורש השבתת שירותים. בהרכבה עצמאית, לפני כל עדכון נדרשים בדיקת תאימות, סדר החלפת צמתים ותוכנית rollback — משימה נפרדת לכמה ימים.
אשכול עצמאי מוצדק כשיש דרישות שהספק לא נותן להן מענה: network policies לא סטנדרטיים, controllers admission משלכם ברמת הניהול, דרישות נוקשות למיקום נתונים. אם אין דרישות כאלה, אשכול מנוהל כמו DigitalOcean Managed Kubernetes נותן את אותו מודל עבודה במאמץ עבודה נמוך יותר.
השאלה אינה איזה פתרון חזק יותר. זו בחירה כמה מעבודת התשתית אתם לוקחים על עצמכם וכמה מהר תוכלו לשנות את הסביבה לפי צורכי המוצר.
ספקות טכניים: גישות, עמידות בכשלים, גיבויים
הספקות של הלקוח בדרך כלל אותם ספקות: למי לתת גישה, מה לעשות עם אשכול שכבר פרוס, מי אחראי לנתונים ואיך בודקים עמידות בכשלים. נענה לפי סעיפים.
איך בנויה גישת מהנדסים לאשכול?
אנחנו מנפיקים חשבונות אישיים דרך תפקידים ומדיניות: מפתח רואה רק את ה-namespace שלו, מהנדס תמיכה — את כל האשכול, אבל בלי גישה לסודות. שינויים נרשמים ביומן ביקורת, ולאחר המסירה גישות הפרויקט מבוטלות.
יש לנו כבר אשכול פרוס — להרוס הכול?
בנייה מחדש מאפס כמעט אף פעם לא נדרשת. אנחנו מביאים את האשכול למצב הרצוי: מעבירים עומסים ל-node pools מנוהלים, מפעילים autoscaling, מוציאים סודות לאחסון נפרד. הכול מתואר דקלרטיבית — המצב משוחזר מה-repository, לא מתיקונים ידניים.
איך מתבצעת מיגרציה ללא השבתה?
קונטור חדש מקימים לצד הקיים, את התעבורה מעבירים בהדרגה — תחילה לחלק מהבקשות, ואחר כך במלואה. את המצב מעבירים דרך גיבויים ורেপליקציה, ובכל שלב מוגדר rollback אחורה. המשתמשים לא מבחינים במעבר.
מי אחראי לגיבויים ואיך נבדקת עמידות בכשלים?
גיבויים נלקחים לפי לוח זמנים ונשמרים בנפרד מהאשכול, ואת השחזור בודקים בתרגילים. עמידות בכשלים מאשרים באותה צורה: מוציאים צומת או zone מכלל פעולה ומתעדים שהשירות המשיך לעבוד.
נדון במשימה ונחזור עם אומדן ותוכנית
תארו את המשימה בצורה חופשית: מה כבר פרוס, איך בנוי האשכול כעת, מה פרופיל העומס ומה דרישות הזמינות. אנחנו מנתחים את הקונפיגורציה — node pools, סכימת רשת, אחסון, אספקת images — וחוזרים עם אומדן ותוכנית, לא עם מילים כלליות.
- היקף העבודות — רשימת סעיפים: פריסת אשכול DOKS, node pools ו-autoscaling, גישה חיצונית ותעודות, אחסונים, גיבוי, ניטור והתראות.
- אומדן המשימה — לכל סעיף מאמץ עבודה ותלויות: מה אנחנו עושים, מה נשאר בצד שלכם, ואילו מערכות חיצוניות מעורבות.
- תוכנית עבודה — רצף השלבים ונקודות תוצאה ביניים: אשכול עובד, תעבורה מועברת, rollback שנבדק.
- לוחות זמנים ליישום — משך לפי שלבים והזמן הכולל עד העלייה לתפעול, בנפרד — מרווח לפערים מול הקונפיגורציה הנוכחית.
- העברת גישות — אילו חשבונות ומפתחות נדרשים בהתחלה, איך מנפיקים ומבטלים אותם לאחר המסירה, ומה נשאר בבעלותכם הקבועה.
- קבלה — מריצים תרחישים של עדכון release, כשל צומת ושחזור מגיבוי, ואת התוצאה מתעדים בדוח עם לוגי הבדיקות.
תארו את המשימה — נחזור עם אומדן, היקף עבודות ותוכנית, ומכאן נתחיל לפי לוח זמנים מסוכם.