למה אנחנו צריכים את קוברנטיס?

אפליקציה מודרנית מורכבת לרוב מכמה רכיבים שכל אחד מהם תלוי ברכיבים האחרים. למשל web application יכול להיות מורכב מצד-לקוח, מצד-שרת ודאטה בייס. בצורה מונוליטית הם ירוצו כפרוססים שונים באותו שרת וכשמפתח רוצה להוסיף פיצ’ר בפרונט הוא צריך לראות שהוא לא שובר שום דבר ברכיבים האחרים של האפליקציה מכיוון שהכל תלוי אחד בשני ויושב באותו שרת. 

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

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

קוברנטיס

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

אז למה בעצם קוברנטיס ומה הוא נותן לנו? 

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

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

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

יכולות

ניהול ישיר

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

סקייל

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

שדרוג ללא זמן אופליין

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

מעטפת Network וDNS

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

מילון מושגי יסוד

• Controller/Master – השרתים המנהלים שבהם מוחזקים הרכיבים שמנהלים את הקלאסטר. הקריאות ליצור משאבים מגיעות אליו.
• Worker/Node – השרתים המנוהלים שבהם מריצים את האפליקציות עצמם. ה nodes יכולים להיות מסוג לינוקס או וינדוס.
• Pod – הרכיב הקטן ביותר בקוברנטיס, הוא שווה ערך לקונטיינר בודד(יכול להכיל יותר מאחד).לכל pod יש את המשאבים שלו שכוללים זיכרון cpu ו Storage .
• ReplicaSet – אחראי שכמות הרצויה של פודים ירוצו.
• Deployment – מגדיר איך נראה האפליקציה בשלמותה בתוך הקלאסטר. נגדיר בו את כמות הפודים שנרצה(הוא יצור את ה ReplicaSet) ואיך לעשות שדרוג ועוד. 
• Service – הרכיב המנגיש את האפליקציה בתוך הקלאסטר (ומחוצה לה). בנוסף יש לו את היכולת לעשות איזון עומסים בין הפודים השונים באפליקציה. 
• Namespace – נותן את היכולת ליצור משאבים ב קוברנטיס בצורה מבודלת. דוגמה מאוד נפוצה היא לתת סביבה זהה לכמה קבוצות עם אותם אפליקציות האפליקציות בתוך הnamespace ידברו ביניהם אך לא אם האפליקציות מחוצה לו.
• Configmap – דרך להגיש לאפליקציות ב קוברנטיס קבצי קונפיגורציה.
• Secrets – מחזיק סיסמאות ודברים שלא אמורים להיות חשופים לכולם אלא רק בשביל האפליקציה. 
• Kubectl – הcli שבו נשתמש לדבר עם קוברנטיס למשל לומר ל קוברנטיס שיצור pod כלשהו.

איך זה נראה מלמעלה

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

אז איך יוצרים משאבים ב קוברנטיס? 

ישנם שני דרכים, נדגים יצירה של pod:

: Imperative 

kubectl run nginx --image=nginx --port=80

אחרי שיצרנו את הpod הזה ניתן לראות שהוא רץ:

$ kubectl get pod 
NAME                  READY   STATUS    RESTARTS   AGE
nginx                 1/1     Running   0          23s

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

אחרי שיצרנו את הpod הזה ניתן לראות שהוא רץ

Declarative

ניצור את הקובץ:

apiVersion: v1
kind: Pod
:metadata
name: nginx  
:spec
:containers  
 name: nginx -  
image: nginx:latest    
:ports    
          containerPort: 80 -    

כדי ליצור את הpod נריץ:

kubectl apply -f nginx-pod.yaml

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

אנקדוטה נחמדה: 

קוברנטיס נקרא בקיצור k8s וזה בגלל ה8 אותיות בין הk לs במילה kubernetes

לסיכום

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

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