תמלול הפרק (לחצו לפתיחה)
קוברנטיס פרק 2: ארכיטקטורה – המאסטר והוורקר
היי, ברוכים הבאים ל"הייטקיסטים בדרכים". אני אורן, והיום נדבר על הארכיטקטורה של קוברנטיס.
כדי להבין את המטרה של ההרצאה הזאת, חשוב להבין שבקוברנטיס יש שני סוגי משתמשים בחלוקה גסה:
מקימים ומתחזקים: אנשי DevOps, IT או SRE. התפקיד שלהם הוא לבנות את התשתיות מאפס ולוודא שהן עובדות.
משתמשי קצה: מפתחים ואנשי QA. הם משתמשים במערכת ביומיום אבל לא תמיד מכירים את ה"קרביים" שלה.
היום נלמד את ה-Internals של קוברנטיס. זה רלוונטי במיוחד למי שרוצה לראות את קוברנטיס כקופסה לבנה.
מה זה קופסה שחורה לעומת קופסה לבנה?
זהו מושג שמתאר איך אנחנו מסתכלים על טכנולוגיה:
קופסה שחורה: אנחנו יודעים רק איך לבצע אינטראקציה עם הרכיב. כמו נהג שרק יודע שלחיצה על הגז מאיצה את הרכב, בלי להבין מה קורה במנוע.
קופסה לבנה: אנחנו מכירים את המנגנון הפנימי. הנהג יודע שלחיצה על הגז מזרימה דלק לתא הבעירה ולחיצה על הברקס מצמידה דיסק לגלגל.
ההרצאה הזו תהפוך את קוברנטיס עבורכם לקופסה לבנה.
מבנה הקלאסטר: Nodes
קלאסטר קוברנטיס מורכב מ-Nodes (נודים). נוד יכול להיות שרת פיזי או מכונה וירטואלית. הם מחולקים לשני סוגים:
Master Node: המנהל. הוא זה שנותן את הפקודות ושולט במערכת.
Worker Node (או Minions): הפועלים. הם אלו שמבצעים את העבודה בפועל ומריצים את האפליקציות.
ה-Worker Node: שלושת הרכיבים המרכזיים
על כל וורקר נוד רצים שלושה רכיבים:
Container Runtime: הטכנולוגיה שיודעת לקחת Image ולהפוך אותו לקונטיינר רץ. ברוב המקרים זה יהיה Docker, אבל קוברנטיס לא מחויבת לדוקר – היא יכולה לעבוד עם כל טכנולוגיה שמממשת את האינטרפייס המתאים.
Kubelet (קובלט): המקשר בין ה-Container Runtime למכונה הפיזית/וירטואלית. הוא האחראי על ה-Lifecycle של הפודים (Pods) – הוא מקים אותם, מריץ אותם והורג אותם לפי הצורך.
Kube-proxy (קוב פרוקסי): שכבת הנטוורקינג. הוא מנהל את התקשורת של הנוד, מקבל ומחזיר בקשות רשת.
ה-Master Node: ארבעת רכיבי הניהול
המאסטר מנהל את הכל דרך ארבעה רכיבים:
API Server: השער (Gateway) למערכת. הוא מקבל בקשות REST ומעביר אותן פנימה. הדרך המוכרת לתקשר איתו היא דרך ה-KubeCTL (כלי CLI – Command Line Interface).
Scheduler (סקדולר): מקבל בקשה ליצירת פוד מה-API Server ומחליט באיזה Worker Node הכי כדאי להקים אותו. הוא מפעיל לוגיקה חכמה שמתחשבת בבריאות הנודים, במשאבי CPU פנויים וכו'.
Controller Manager: רכיב שרץ בלופ אינסופי ובודק את הסטטוס של המערכת. הוא משווה בין שני מצבים:
Desired State: מה שאנחנו רוצים שיקרה (למשל: "אני רוצה 4 עותקים של סרויס A").
Actual State: מה שקורה במציאות.
אם יש פער (Gap) – למשל פוד אחד נפל ויש רק 3 – הקונטרולר מנג'ר יפעל כדי להחזיר את המצב ל-Desired ולהקים פוד חדש.
etcd (Data Store): דאטה-בייס מסוג Key-Value שמכיל את כל המידע על הקלאסטר (Metadata). הוא Shared – אם יש כמה מאסטרים, הם מסנכרנים את המידע ביניהם. הוא לא מכיל את הנתונים של האפליקציות שלכם, אלא רק נתונים על המערכת (סטטוס נודים, כתובות IP וכו').
סיכום
Master Node: API Server (שער), Scheduler (מתכנן), Controller Manager (משגיח), etcd (מסד נתונים).
Worker Node: Container Runtime (מריץ), Kubelet (מנהל פודים), Kube-proxy (תקשורת).
עכשיו כשהבנו איך המערכת בנויה, אנחנו יכולים לעבור בפרק הבא לדברים שמעניינים יותר מפתחים ואנשי QA – איך משתמשים בה בפועל.
תודה שהקשבתם, אם יש שאלות אני אשמח לשמוע ונמשיך בפרק הבא!