הגדרת Managed Kubernetes (DigitalOcean DOKS) לסביבת ייצור

Kubernetes מנוהל ב-DigitalOcean: היכן נשברת סביבת הייצור

אשכול שנבנה ידנית מחזיק עד לשיא הרציני הראשון: כשהעומס יציב, פודים עולים, שירותים מגיבים, מדדים תקינים.

הכול נשבר בדיוק במקום שבו סביבה מנוהלת כבר הייתה מסירה חלק מהעבודה מהצוות — ב-Kubernetes מנוהל ב-DigitalOcean הספק מתחזק את שכבת הניהול, אבל מאגרי הצמתים, התזמון וסדרי העדכונים נשארים באחריות המהנדסים.

תרחיש הכשל הראשון — כשל של צומת באשכול. אם במאגר אין מרווח, ומדיניות הפינוי ובדיקות המוכנות לא הוגדרו, פודים על הצומת שנפל מפסיקים לקבל תעבורה, חלקם נשארים במצב סיום ולא מתוזמנים מחדש.

מכאן מתחיל שחזור ידני של השירות: מהנדס מרים צומת, ממתין למוכנותה, מסיר מגבלות מתזמן — ורק אז עומסי העבודה ממוקמים שוב.

צוואר הבקבוק השני — חוסר סנכרון בתצורות. שינויים שנעשו במקום סוטים מהמאגר, והפריסה הבאה מבטלת אותם בשקט. ברגע חקירת תקלה איש אינו יכול לומר איזו גרסת תצורה באמת פעלה.

השלישי — סקיילינג לפי עומס. בלי בקשות ומגבלות משאבים נכונות, בלי מדדים לסקיילינג אוטומטי ובלי צמתים מחוממים מראש, האשכול נתקל בתקרת המאגר. השבתה בעומס שיא נובעת לא מחוסר כוח, אלא מכך שצומת חדש מופיע מאוחר יותר ממה שמתכלה תור הבקשות.

איך שלושת המקומות האלה נסגרים בסביבה מנוהלת — נפרט בהמשך.

מה נותן המעבר של עומס ייצור לאשכול מנוהל

באשכול לא מנוהל כשל צומת הוא תרחיש עם המשך ידני: מהנדס נכנס למכונה, מוציא אותה מאיזון העומסים, ומרים מחליף. בזמן שזה קורה, חלק מהרפליקות של השירות אינן זמינות, וזמן השחזור תלוי במי שהבחין ראשון בהתראה, ולא בארכיטקטורה.

אשכול מנוהל מעביר את התרחיש הזה לאוטומטי: הצומת מסומן כלא כשיר, הפודים נוצרים מחדש על צמתים בריאים, והמחליף מגיע מהמאגר — בלי פקודות ידניות ובלי חלון שבו השירות ממתין לתורנות.

את שכבת הניהול מתחזק הספק, ולכן עדכונים ועמידות לתקלות של האשכול עצמו אינם מוטלים על הצוות שלכם — DigitalOcean סוגר את החלק הזה, ואנחנו בונים מעליו עומסי עבודה ומדיניות.

סקיילינג אוטומטי פועל בשתי רמות: מספר הרפליקות של היישום גדל לפי מדדי עומס, ומספר הצמתים — לפי ניצולת בפועל. הקיבולת לא נקבעת ידנית מראש לשיא, אלא מופיעה לפי העומס בתוך דקות ונעלמת בירידה — צריכת המשאבים מפסיקה ללכת אחרי תרחיש הגרוע ביותר.

זמן השחזור נקבע בהגדרות, לא במזל: בדיקות מוכנות וחיים, מדיניות הפסקה לעבודות מתוכננות, ופיזור רפליקות בין אזורים. כך נעלם סוג שלם של כשלים, שהסיבה להם אינה בתשתית אלא בפעולה ידנית — צומת שנשכח, עריכה בקונסולה מחוץ למניפסטים, תצורה שהתפצלה.

הכול מתואר באופן דקלרטיבי ונמצא במערכת ניהול גרסאות: rollback הוא החזרה של גרסת המניפסטים הקודמת, ולא שחזור מהזיכרון. את האפקט מודדים בשלושה מדדים — זמן שחזור השירות, שיעור התקלות שנסגרו ללא מעורבות אדם, ומרווח קיבולת בשיא.

Kubernetes: אשכול מנוהל, צמתים משלכם או היברידי

סביבה מנוהלת — למשל DigitalOcean DOKS — מסירה שגרה: שכבת הניהול, עדכוני גרסה, עמידות נקודות הגישה ותיקונים נלקחים על ידי הספק. אבל הבחירה כמעט אף פעם אינה «אשכול מנוהל או צמתים משלכם»: תצורת ייצור היא כמעט תמיד היברידית.

את המגבלות של סביבה מנוהלת כדאי להכיר מראש: אין גישה לצמתים של שכבת הניהול, מצבים privileged, סוכני מערכת ועריכות קרנל חסומים, דיסקים מקומיים אפמרליים, ומדיניות רשת מוגבלת ליכולות הספק. מכאן הפיצול — מה חי בסביבה מנוהלת ומה מוציאים לצמתים משלכם.

הדיון יוצא מדרישות העומס, לא מהנוחות: אם שירות צריך גישה לקרנל, דרייברים משלו או בידוד ברמת הצומת — הוא עובר לצמתים משלכם, והשאר נשאר בסביבה מנוהלת כדי שהצוות לא יבזבז כוחות על שגרה.

שלבי הטמעת אשכול מנוהל לעומס ייצור

אשכול ל-production נבדל מאשכול בדיקה לא במספר הצמתים, אלא בכך שכל פרמטר נגזר ממדידות: פרופיל צריכת הזיכרון, אופי התעבורה ודרישות לזמן השחזור. את העבודה מובילים בשלבים — מביקורת עומס ועד מסירה לתפעול, ולכל שלב יש תוצאה ניתנת לבדיקה.

1. ביקורת עומס. אוספים מדדים על פני תקופה מייצגת: עוצמת שיא של בקשות, יחס קריאה/כתיבה, פרופיל זיכרון, קפיצות והסיבה להן.
2. תרשים האשכול. מפרידים מאגרי צמתים לשירותים ולרכיבי מערכת, מגדירים סקיילינג אוטומטי, בקשות ומגבלות משאבים, וכללי מיקום פודים.
3. עמידות לתקלות. מפזרים עומסים בין אזורי זמינות, קובעים מספר רפליקות, תקציב הפרעות, בדיקות חיים ומוכנות, ואיסור על שכנות רפליקות של אותו שירות.
4. רשת, אחסון, הרשאות. נקודת כניסה לתעבורה ותעודות, רישום images פרטי, דיסקים למצב, מדיניות רשת בין שירותים, והרשאות צוותים לפי תפקידים.
5. בדיקת תרחישי כשל. מכבים בכוח צומת ואזור שלם, מפעילים מחדש פודים, מנתקים תלות חיצונית — מתעדים את זמן השחזור ואת תקינות המעבר.
6. יכולת ניטור. מדדים, לוגים והתראות עם קישור ליעדי זמינות, כדי לזהות ירידה בביצועים לפני תלונות משתמשים.
7. מסירה לתפעול. נהלים לעדכון ו-rollback של גרסאות, סבב סודות, גיבוי, והוראות למשמרת תורנות.

סדר כזה מסיר את הסיכון המרכזי: כשהאשכול כבר בנוי, אבל לא ידוע אם ישרוד אובדן אזור בשעת שיא.

מה מוסרים לידיים: תרשימים, מדיניות, נהלים

לאחר מסירה ללקוח נשאר לא רק אשכול פעיל, אלא גם סט מלא של ארטיפקטים שלפיהם הצוות יוכל לפתח אותו בלעדינו. הכול נמצא במאגר אחד ובתיקיית תיעוד אחת, והמבנה משויך לסביבות — כך אין צורך לאסוף את המצב משיחות ומממשקי ניהול.

• תצורות סביבה — תבניות אחידות לפיתוח, לבדיקות ולסביבת ייצור, וההבדלים מופרדים לשכבות נפרדות: הסביבות לא מתפצלות, כל שינוי עובר סקירה ומתפרס באופן צפוי.
• תרשימי גיבוי — מפת אזורי פריסה, לוח זמנים של snapshots לכרכים, יעדי שחזור לכל סביבה, ונוהל בדיקת גיבויים.
• מדיניות גישה — תפקידים, חשבונות שירות, הגבלת הרשאות ב-namespace של ייצור, ונוהל הענקה ושלילה של גישות.
• נוהל תפעול — תדירות עדכוני מאגרי צמתים, חלונות עבודה, נוהל rollback, תורנות וקריטריונים להסלמה.
• תיעוד האשכול — טופולוגיית מאגרי צמתים, סקיילינג אוטומטי, תלויות חיצוניות, נקודות אינטגרציה ואחראים על שירותים.
• הוראות שחזור — הרמה מדורגת של האשכול והשירותים מ-snapshots, שנבדקה מראש בסביבת בדיקה ולא נכתבה מהזיכרון.
• יכולת ניטור — רשימת מדדים והתראות עם ספים, dashboards לצמתים, לשירותים ולתלויות חיצוניות.

מקרה בוחן: מעבר שירות לסביבה מנוהלת ומדדים לפני ואחרי

לפני המעבר השירות חי על שלושה צמתים שהוגדרו ידנית: עדכוני חבילות מערכת בוצעו לפי צ'קליסט, תעודות הוארכו ידנית, וכללי איזון עומסים נערכו ישירות על תעבורה חיה. הפריסה ארכה ערב שלם — בנייה, העתקת ארטיפקטים, הפעלה מחדש, בדיקה. תקלה בלילה כללה 40–60 דקות רק לאבחון: המהנדס התורן בירר תחילה מה מצב הצמתים ומה בדיוק נפל.

את עומס העבודה העברנו לסביבה מנוהלת DigitalOcean: עדכוני צמתים, מאגרים עמידים לתקלות ומחזור החיים של האשכול עצמו הפכו למשימת הפלטפורמה, ואנחנו נשארנו עם עומס העבודה, מדיניות הגישה והיכולת לנטר. המצב מתואר דקלרטיבית, ולכן הסביבה עולה מהמאגר ולא נבנית מהזיכרון.

מדדים לפני ואחרי

פריסה: קודם — ערב שלם וצעדים ידניים, היום — 12–15 דקות של ריצה אוטומטית. Rollback לגרסה הקודמת — ריצה אחת במקום שחזור מגיבוי. שחזור לאחר כשל צומת: קודם 40–60 דקות, כעת 5–7 — הצומת מוצא מהמאגר, העומס עובר, והחדש עולה בעצמו.

פעולות ידניות הצטמצמו מ-30–40 פעולות בחודש ל-4–5: נותרו רק שדרוג גרסה ובחינה מחדש של מדיניות. שיעור ההשבתות בגלל טעות בצעד ידני ירד לאפס — לא מפני שהמהנדסים נעשו זהירים יותר, אלא מפני שהצעדים האלה כבר לא קיימים בתהליך.

במה אשכול מנוהל נבדל מצמתים שנבנו ידנית?

באשכול מנוהל שכבת הניהול — שרת API, אחסון המצב והמתזמן — חיה בצד הספק. DigitalOcean מחזיק אותו עמיד לתקלות, מיישם עדכוני אבטחה ואחראי לזמינות. עלינו נשארים צמתי העבודה, תצורת העומסים, מדיניות הרשת והקיבולת.

אם בונים ידנית גם את שכבת הניהול וגם את הצמתים, נוספים קוורום לאחסון המצב, סבב תעודות, גיבויים ועדכונים — חלק נכבד מהכשלים בלילה חי בדיוק שם.

עדכון שכבת הניהול בגרסה המנוהלת מתבצע בלי לעצור עומסים: הספק מגלגל אותו בעצמו, ואנחנו בוחרים את הגרסה הזמינה ואת הזמן. הגבול עובר בצמתים — אותם אנחנו מעדכנים: בודקים תאימות API, מוציאים צמתים מאיזון עומסים בזה אחר זה, בודקים ומחזירים בחזרה.

הקריטריון לבחירה פשוט: אשכול מנוהל לוקח על עצמו עבודה שלא יוצרת מוצר. צמתים משלכם מוצדקים כשצריך תוספות לא סטנדרטיות מעל שכבת הניהול או בידוד קשיח — ואז התחזוקה שלהם הופכת לאזור אחריות קבוע ונפרד.

שאלות טכניות נפוצות לפני פריסת האשכול

לפני פריסה לסביבת ייצור הספקות חוזרים: מה לעשות עם מצב היישומים, איך לעדכן את האשכול בלי השבתה, ולאן לחזור אם הגרסה לא עמדה בעומס. להלן תשובות קצרות לכל נקודה, כדי שההחלטות יתקבלו לפני ההרצה הראשונה ולא ברגע התקלה.

איך מתבצע עדכון האשכול ומה עם השבתה?

צמתים מתעדכנים ברצף: עומס העבודה מפונה למכונות פנויות, היישום ממתין למוכנות, ורק אז הצומת מוצא משירות. את החלון מתאמים מראש ושומרים רזרבה של משאבים פנויים, כדי שפודים שפונו ימוקמו בלי המתנה — השירות נשאר זמין לאורך כל העבודה.

איך מבצעים rollback לגרסה אם התבררה כבעייתית?

כל build מקבל תג בלתי משתנה, היסטוריית revisions נשמרת באשכול, ולכן החזרה לגרסה הקודמת אורכת דקות ולא דורשת בנייה מחדש. רישום ה-images מנוקה לפי כלל מחזור חיים: עשרת ה-builds האחרונים לכל תג נשארים זמינים ל-rollback, והשאר נמחקים.

האם גיבוי וניטור ברירת מחדל יספיקו?

Snapshots של כרכים ו-dumps של מסדי נתונים מגדירים לפי לוח זמנים עם אחסון במאגר נפרד, ואת השחזור בודקים בסביבת אימון — גיבוי שמעולם לא פרסו אותו אינו נחשב גיבוי. ניטור האשכול מכסה צמתים, פודים ונקודות כשל: התראות מגיעות לפני שהירידה בביצועים נהיית מורגשת למשתמשים.

נדון בעומס ונחזור עם תוכנית והערכה

כדי לחזור עם תוכנית הטמעה והערכת עבודה, די לנו בנתוני פתיחה על העומס והמגבלות — תרשים מפורט נבנה כבר בשיחה. המינימום ההנדסי הוא: כמה שירותים עוברים, מה פרופיל התעבורה שלהם ומה כבר פועל ב-Kubernetes מנוהל ב-DigitalOcean.

לפי הנתונים האלה אנחנו מחשבים גודל צמתים, פיזור בין אזורים, מכסות ונקודות כשל, ואחר כך שולחים סדר עבודה מחולק לשלבים. בנפרד נסכם את נוהל מסירת האשכול — גישות, תצורות, נהלי עדכונים, כדי שאחרי ההרצה לא יישארו הגדרות שרק קבלן החוץ יודע לתחזק.

מה לשלוח לצורך חישוב:

• רשימת שירותים ומשימות רקע שעוברים לאשכול, ומה נשאר מחוצה לו;
• פרופיל עומס: בקשות שיא, קפיצות עונתיות, דרישות לזמן תגובה;
• מצב נוכחי: איך השירותים עולים כעת, מה הוגדר ידנית, ומה מצב רישום ה-images;
• דרישות זמינות וחלון השבתה מותר בזמן עדכונים;
• כללי גישה: מי מקבל הרשאות אדמין, והאם צריך סביבות נפרדות לבדיקות עומס;
• מה ובאיזה סדר צריך להשתחזר לאחר תקלה, והיכן נמצאים גיבויי המצב;
• מגבלות לוחות זמנים והחלטות שנשארות בצד שלכם.

תארו את המשימה בצורה חופשית — זה יספיק כדי לדון בעומס ולחזור עם תוכנית והערכה.