מה זה Kubernetes? הסבר פשוט + משרות פתוחות בישראל

Kubernetes היא מערכת שמנהלת קונטיינרים על פני שרתים רבים: מחליטה איפה כל אחד ירוץ, מפעילה מחדש מה שנפל, מגדילה ומקטינה לפי עומס, ומנתבת אליהם תעבורה. בלוח HiTakeJob פתוחות כרגע 110 משרות שמזכירות Kubernetes - יותר מכל כלי תשתית אחר - לצד 68 שמזכירות Docker ו-12 שמזכירות Helm.

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

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

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

המושגים שחוזרים בכל משרה

מושג	מה זה
Pod	יחידת ההרצה הקטנה ביותר - קונטיינר אחד או כמה שחולקים רשת ואחסון
Deployment	הגדרה של כמה עותקים לרוץ ואיך לעדכן אותם בהדרגה
Service	כתובת יציבה שמפנה ל-Pods שמשתנים כל הזמן
Ingress	הכניסה מבחוץ - ניתוב לפי דומיין ונתיב, כולל TLS
ConfigMap ו-Secret	הגדרות וסודות שמופרדים מה-image
Namespace	הפרדה לוגית בין סביבות או צוותים באותו אשכול

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

מה באמת קורה כשמשחררים גרסה

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

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

איך הוא מחליט איפה להריץ מה

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

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

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

מתי Kubernetes לא הבחירה הנכונה?

זו השאלה שחשוב לשאול לפני שמאמצים, כי המורכבות התפעולית שלה אמיתית:

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

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

איך שירותים מוצאים זה את זה

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

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

מה נשבר בפועל

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

מה צריך לדעת כדי לעבוד עם זה

סדר הלמידה שעובד, ולא הסדר שרובם מנסים:

• Linux ורשתות ברמה מעשית - בלי זה, שגיאות הרשת נראות כמו קסם.
• Docker: בניית image, שכבות, ומשתני סביבה.
• המושגים הבסיסיים והפעלה שלהם בפועל על אשכול מקומי או קטן בענן.
• Helm לניהול גרסאות של פריסות - 12 משרות פעילות מזכירות אותו.
• ניטור: איך רואים למה Pod נפל, כולל לוגים ואירועים.
• אבטחה בסיסית: הרשאות, ניהול סודות והפרדת רשת.

אפשר לראות את המשרות במשרות Kubernetes ובמשרות Docker, ולהבין את התפקידים שנשענים על זה במה זה DevOps ובמה זה Platform Engineering.

שאלות נפוצות

מה ההבדל בין Docker ל-Kubernetes?

Docker אורז ומריץ קונטיינר בודד; Kubernetes מנהל מאות כאלה על פני שרתים - מתזמן, מרפא, מגדיל ומנתב. הם משלימים ולא מתחרים, ולכן 110 משרות מזכירות את השני ו-73 את הראשון.

למה קוראים לזה k8s?

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

צריך ללמוד את זה כדי להיות מפתח Backend?

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

כמה עולה להריץ אשכול?

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

מה ההבדל בין אשכול מנוהל להקמה עצמית?

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

אפשר ללמוד את זה בלי גישה לענן?

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