הגדרת Kubernetes קל (k3s) עבור edge/IoT

k3s לפריפריה: היכן נשבר האשכול הקלאסי

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

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

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

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

מה נותן אשכול קל באתרים מרוחקים

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

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

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

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

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

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

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

מצבי פריסה של k3s: צומת בודד או אשכול

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

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

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

הטמעת k3s: שלבי עבודה מביקורת ועד מסירה

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

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

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

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

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

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

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

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

מה הלקוח מקבל לידיו לאחר ההטמעה

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

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

מקרה בוחן: 40 אתרים במעגל ניהול אחד

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

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

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

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

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

במה k3s שונה מ-Kubernetes קלאסי?

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

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

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

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

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

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

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

שאלות טכניות נפוצות בנוגע להטמעה

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

כיצד לעדכן בלי לעצור את השירות?

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

עד כמה האשכול באתר מאובטח?

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

כיצד לאסוף לוגים ומדדים כשהקשר אינו יציב?

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

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

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

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

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