פריסה של
Microservice
בקלסטר של k8s

בלי כתוביותעם כתוביות

מילון מושגים:

פריסה - העברת תוכנה מסביבת פיתוח לסביבה שבה היא תרוץ בפועל, כדי להעמידה לשימוש.

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

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

Terraform - כלי להגדרת תשתית כקוד, שמאפשר ליצור ולנהל משאבי ענן ותשתית בעזרת קובצי תצורה.

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

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

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

פריסה של Microservice בקלסטר של k8s

הפרויקט של המיקרו-סרביסים עולה ל-cluster דרך קובצי ה-YAML של Kubernetes, בלי Terraform. ההרצאה עוברת על מבנה קובץ אחד, ואז פורסת את כל הפרויקט בפקודה אחת.

מה יש בקובץ של שירות

1. Deployment: ב-Deployment של ה-cart service יש קונטיינר בשם server שחושף פורט 7070 ומשתנה סביבה REDIS_ADDRESS שמצביע על redis-cart בפורט 6379. כך השירות מתקשר עם מסד הנתונים.

2. משאבים: ה-request הוא 200 מילי-CPU (חמישית ליבה) ו-64 מגה זיכרון. ה-limits הם 300 מילי-CPU ו-128 מגה. חריגה מהזיכרון הורגת את הקונטיינר ויוצרת חדש, וחריגה מה-CPU רק מאטה את השירות.

3. בדיקות: readiness ו-liveness probe פונים לפורט 7070 ב-gRPC. אחרי 15 שניות מתחילות בדיקות כל עשר שניות, וקונטיינר שלא עונה נהרג.

4. Service: cart-service מסוג ClusterIP, כלומר רק פודים אחרים כמו frontend ו-Checkout פונים אליו. כדי לחשוף החוצה היה צריך LoadBalancer.

5. מסד הנתונים: Redis קיבל Deployment משלו בפורט 6379 עם mount לדיסק חיצוני, כך שהמידע נשמר גם כשהקונטיינר מת, ועם service בשם redis-cart.

6. נתיב ה-image: בקבצים הנפרדים חסר נתיב מלא ל-image, ולכן משתמשים בתיקיית release שמכילה manifest מאוחד של 981 שורות עם נתיבים מלאים.

הפריסה

1. בתיקיית release מריצים kubectl apply -f ..

2. kubectl get all מראה בהתחלה פודים ב-pending ו-Ready 0/1, וה-LoadBalancer היחיד ממתין ל-IP חיצוני.

3. אחרי כמה שניות רוב הפודים עולים. email קרס ארבע פעמים ו-recommendation שלוש, ובסוף הכול עלה.

4. דרך ה-IP החיצוני אפשר לגלוש לחנות, להוסיף מוצר לסל ולראות את עמוד /cart, בלי לדעת שמאחורי הקלעים רצים מיקרו-סרביסים.

אחרי ההרצאה אפשר להסביר מה כולל manifest של שירות ב-Kubernetes ולפרוס פרויקט שלם בפקודת apply אחת.

השיעור הבא בקורס: Postman gRPC Microservice ב-Kubernetes

פרקי ההרצאה: פריסה של Microservice בקלסטר של k8s

תמלול ההרצאה: פריסה של Microservice בקלסטר של k8s

הטקסט המלא של הדקות הראשונות בהרצאה «פריסה של Microservice בקלסטר של k8s» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.

00:02
שלום לכולם. היום בהרצאה אנחנו הולכים להעלות את כל הפרויקטים שלנו, את כל המיקרוסרביסים שלנו לענן. בשביל זה בתיקייה הראשית יש לנו כמה אפשרויות כמו להעלות את זה בעזרת Terraform.
00:16
על Terraform יש לנו קורס נפרד. אנחנו רוצים להתרכז ב-Kubernetes ויש לנו פה עבור כל service קובץ YAML שמעלה אותו לענן. בואו ניקח אחד מהם, נעשה עליו Edit ונראה שיש לנו פה הכרזה על deployment שינהל את הפודים של ה-cart service.
00:35
שימו לב, אני רואה פה בעיה. נתיב לא תקין ל-image. קונטיינר שלנו נקרא, יש לו שם server, זה השם של הקונטיינר בתוך הפוד. יכול להיות שבפוד הזה יהיו גם עוד קונטיינרים נוספים.
00:48
כרגע אני רואה רק קונטיינר אחד בשם server שהוא חושף port שבעים שבעים החוצה ויש לו משתנה סביבה בתוך הקונטיינר בשם REDIS_ADDRESS. Redis זה הדאטה בייס שלו, כמו SQL עם ערך redis-cart, זה השם של ה-service ופורט שש שלוש שבע תשע.
01:07
למעשה דרך משתנה סביבה הזה ה-service מתקשר מול הדאטה בייס. מה עוד אנחנו רואים בתוך הקונטיינר? שיש לנו פה בקשה למשאבים, request לקבל מאתיים אלפיות המעבד.
01:22
זאת אומרת חמישית מליבה אחת של מעבד. זה אומר שעל ליבה אחת יכולים לשבת חמישה קונטיינרים כאלו. היום בתוך מעבד פיזי אחד יש הרבה ליבות ואנחנו אומרים שלעבודה רגילה של השירות הזה צריך חמישית מכוח העיבוד של ליבה אחת.
01:42
צריך לתת לשירות הזה שישים וארבע מגה זיכרון ופה ב-limits יש את הגבול האדום. אין מצב שה-service הזה יעבור שלוש מאות מילי CPU ומאה עשרים ושמונה מגה בייט זיכרון.
01:56
אם הוא עובר את המאה עשרים ושמונה מגה זה אומר שמשהו השתבש שם בקוד. אולי יש שם באג. מה שיעשה ה-Kubernetes הוא פשוט יהרוג את הקונטיינר הזה וייצור אחד חדש נקי.
02:09
זה הגבול האדום שאחריו משמידים את הקונטיינר הזה. וב-CPU הוא יותר סלחן, כי אם אתה עובר את השלוש מאות אלפיות המעבד אז הוא פשוט לא יתן לך יותר זמן מעבד.
02:21
ה-service הזה יעבוד לאט. זאת אומרת שהוא לא יקבל זמן עיבוד, זמן לרוץ על הפקודות שלו ב-C# יותר משלושים אחוז מליבה אחת. זה המקסימום של זמן מעבד שהוא יקבל.
02:34
מה יש לנו פה עוד בתוך הפוד? יש לנו את ה-READINESS. איך בודקים שהקונטיינר מוכן לפעולה. אחרי חמש עשרה שניות פונים לפורט שבעים שבעים.
02:44
שימו לב לא ב-HTTPS רגיל אלא ב-gRPC. gRPC זה שידרוג של HTTP. למעשה כל המיקרוסרביסים מתקשרים מול ה-frontend ב-gRPC ורק ה-frontend מתקשר מול הלקוח ב-HTTP רגיל.
03:00
gRPC זה כמו HTTP עם תוספות. עוד מעט נרים את הכל באוויר ונפנה לכל ה-services האלו ב-gRPC ונקבל מהם תשובה כאילו אנחנו ה-frontend. יש פה גם LIVENESS.
03:12
איך בודקים שהקונטיינר הזה חי או מת? כי אם הוא מת אז זורקים את הכל לפח ובתוך הפוד הזה, בתוך הקפסולה מעלים קונטיינר חדש נקי. אחרי חמש עשרה שניות מתחילים כל עשר שניות לבדוק פורט שבעים שבעים.
03:29
אז שימו לב, הבדיקה הזאת מתבצעת כל עשר שניות. פרט לחמש עשרה השניות הראשונות שהקונטיינר מתעורר לחיים ואחרי זה נתחיל כל עשר שניות לבדוק שפורט שבעים שבעים חי והוא עונה לנו לתקשורת ב-gRPC.
03:44
ואם יש לו איזשהו באג או שהוא השתגע ולא עונה לי יותר, זה אומר שהוא גם לא עונה ל-frontend וללקוחות, אז נהרוג אותו. ויש פה עוד אובייקט בתוך הקובץ הזה, זה