קוברנטיס שלעיתים נכתב בקיצור K8s היא מערכת קוד פתוח לניהול ופריסה אוטומטית של יישומים על גבי קונטיינרים. המערכת תוכננה במקור על ידי גוגל וכיום מתוחזקת על ידי Cloud Native Computing.‏ קוברנטיס תומכת במגוון כלים של קונטיינרים, בין היתר Docker או RKT. קוברנטיס נוצרה על ידי גוגל, והוצגה באופן רשמי באמצע שנת 2014.

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

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

רכיבים ומושגים כללים

כאמור, ישנם רכיבים רבים בטכנולוגיה של Kubernetes התרשים מטה מתאר באופן כללי את הרכיבים הכללים שנעבור עליהם במאמר.

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

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

פקודות מסוימות אל מול POD יכולות להיות:

• kubectl get services בכדי לראות services במערכת (באותו namespaces)
• kubectl get pods –all-namespaces שמציג את כל הפודים באותו namespaces

NODES הוא למעשה worker machine ויכול להתבסס על מכונה וירטואלית או פיזית, וזאת בהתאם לקלאסטר. כל NODE יכול להכיל מספר PODים שונים. במצב רגיל, לכל קוברנטיס קלאסטר חייב להיות לפחות Node אחד על מנת שהוא יהיה Node מנהל, ומשם הוא מריץ Kubernetes API ואת שאר כלי הניהול של קוברנטיס. כל Node מורכב מרכיב Pod אחד או יותר.

ניתן להציג רשימת NODEים ואת הסטטוס שלהם בצורה הפשוטה ביותר ע"י הפקודה kubectl get node

Services הם שיטה לגישה לעומסי עבודה אשר חשופים לעולם, Service בהשוואה אל PODים אינם חלופיים. ניתן לגשת אל Service באמצעות DNS פנימי.

למעשה, Services הם דרך מופשטת לחשוף יישום הפועל על סט של PODים כשירות רשת, ולכן עם קוברנטיס אין צורך לבצע שיוניים ברמת היישום (במצבים שונים) על מנת לחשוף את המנגנון. קורנטיס מספק לרכיבי PODים כתובות IP ייעודיות וכן שם DNS עבור קבוצת PODים.

בפקודה הבסיסית של kubectl get services ניתן להציג Services קיימים ופרטים לגבי כתובת IP, שם DNS, פורט וכן הלאה.

התרשים מטה 👇 הוא תרשים כללי של רכיבים שונים במבנה של קוברנטיס. רוב הרכיבים מוזכרים במאמר עם שייכות לרכיבים אחרים.

kube-apiserver – הוא ה API הראשי של קוברנטיס. אשר מבוסס על גבי REST. רכיבים אחרים מקיימים אינטרקציה עם Kubernetes אך ורק דרך API, והוא למעשה פועל כמעין שומר סף בגישה אל ה Cluster בכך שהוא מטפל באימות, בקשות ואלידציה וכן בקרת כניסה בנוסף להיותו בפרונט של מערכת הנתונים.

למשל, כאשר מריצים את הפקודה kubectl get pods אז נעשית פנייה אל API.

etcd – מנהל, מחזיק ושומר מידע של התצורה, קונפיגורציה ומצב הקוברנטיס וכן מטהדאטה. Kubernetes היא מערכת מבוזרת, ולכן היא זקוקה לאחסון נתונים מבוזרים בכדי שיאפשרו לרכיבי Nodes לקרוא ולכתוב נתונים אליו וממנו. etcd שומר את האובייקטים ומידע של התצורה, או לחלופין שומר את הנתונים אשר קשורים לכמות רכיבי PODS אשר רצים כרגע, או רכיבי NODES, שיוכים לכתובות IP's וכן הלאה. לצד זה, חשוב להדגיש כי הוא אינו מאחסן מידע אחר, למשל, מידע מסוג קבצים.

חשוב להדגיש כי etcd מחזיק את כל הנתונים הנדרשים לניהול הקלאסטר של קוברנטיס.

במידה וישנו בארכיקטרטוה יותר מאשר MASTER אחד, באחריות etcd לוודא שהדאטהיהיה מסונכרן בין כל ה Masters שלנו. למשל, בדוגמה המצורפת ישנו Master והיתר הם worker nodes.

כאמור, בתהליכים של רכיב etcd ישנם מגוון תחומי אחריות, כולל הבאים:

• טיפול בבקשות API של kubectl
• תזמון של רכיבי POD להפעלה מול worker nodes
• הפעלת POD על גבי אותם worker nodes
• אם למשל נריץ את הפקודה kubectl get xyz כל המידע שיתקבל יהיה מתוך etcd
• במידה ונריץ את הפקודה kubectl create כל אותו מידע יעודכן מול רכיב etcd
• כל רכיב Node שיתרסק (מסיבה כלשהיא)

kube-controller-manager מאחד מספר רכיבים שונים במקום אחד, ולמעשה הוא התהליך הראשי שמנהל את כל לולאת הבקרה של רכיבי הליבה. בנוסף לכך, מנטר את המצב המצוי של ה- Cluster. בנוסף לכך, הוא מחזיק בתוכו את כל השירותים והספריות הדרושות לקוברנטיס. אפשר בהשוואה מסוימת אל jube-apiserver לומר ש kube-controller-manager הוא הבקאנד של קוברנטיס.

kube-proxy אחראי על התקשורת בין NODES שונים על ידי ניתובים שונים שנעשים על גבי חוקי Firewall. למשל, תקשורת בין שני PODים שונים על גבי NODEים שונים מחייבים Route המאפשר זאת. הניתוב יכול להיעשות בין בתוך הקלאסטר ומחוצה לקלאסטר. בנוסף לכך, מבצע איזון עומסים עבור שירותי הליבה של Kubernetes.

kube-scheduler הוא רכיב שאחראי על יצירת POD, מתזמן את הריצה שלהם, מתזמן כיבוי, וכן באיזה Node עצמאי להריץ אותם כל אחד מהם. בנוסף לכך הוא מעריך דרישות עומס עבודה ומנסה למקם על משאב תואם. דרישות עומס עבודה יכולות לכלול, בין היתר, דרישות חומרה.

kubelet משמש כסוכן על גבי כל אחד מאותם Nodes של Kubernetes ומאפשר לנהל את מחזור החיים של כל אחד מאותם PODים שנמצאים על אותו שרת  Node. בנוסף לכך, הסוכן שמריץ את הקונטיינרים בכל NODE הוא מתווך ברמת API של קוברנטיס לדוקר. , ומשם הוא רץ כ SERVICE ולא כרכיב POD, ולכן הוא לא מופיע לנו ברשימת POD.

Container runtime engine או Container runtime הוא רכיב (חלק ברמת תוכנה) שמקבל בקשות משתמשים, בקשות ברמת פקודה, מאפשר למשוך אימייגים ומנקודת המבט של משתמש הקצה מפעיל את הקונטיינר. אנו צריכים להתקין Container runtimes בכל NODE בקלאסטר בכדי שהוא יוכל להריץ POD.

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

הפקודה הבסיסית של kubectl get namespaces מציגה namespaces פעילים.

נקודות נוספות לגבי רכיבים בקוברנטיס

• היררכיית הרכיבים בקוברנטיס היא לפי Cluster > Node > Pod
• המטרה בקוברנטיס היא לאפשר לקונטיינרים לתקשר בניהם כאשר הם נמצאים ברכיבי NODES שונים
• מניעת כפילות של כתובת IP זהה בין דוקרים שממוקמים ברכיבי NODES שונים
• כאשר שמחליפים קונטיינר, לרוב הוא יקבל כתובת IP חדשה – לעיתים לא מצב אופטימלי
• היחידה הקטנה ביותר בקוברנטיס נקראת POD
• POD יכול להכיל קונטיינר אחד או קבוצה של קונטיינרים
• קונטיינרים שנמצאים באותו POD יקבלו את אותה כתובת IP
• כל POD שממוקם בקלאסטר יקבל כתובת IP ייחודית באותו מרחב כתובות
• קונטיינרים יכולים לתקשר עם קונטיינרים אחרים ללא צורך באפשרות NAT
• רכיב etcd הוא Key-Value דאטאבייס לאובייקטים של קוברנטיס
• Kubelet הוא service של קוברנטיס אשר רץ על NODEים שונים בקלאסטר – יכול לרוץ גם ברמת מאסטר וגם בברמת WORKERS

קישורים נבחרים

• פקודות מתוך kubectl Cheat Sheet
• איך להקים AKS באמצעות Azure CLI בקישור How To Build AKS with Azure CLI
• הבלוג הרשמי של Kubernetes
• מידע נוסף על Azure Kubernetes Service