ארגז כלים – kubectl לעבודה עם קוברנטיס

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

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

הכלי הכי שימושי שאני משתמשת בו בעבודה היומיומית עם סביבות הקובה ² שלי הוא ה-kubectl. מדובר בכלי שרץ ב-CLI, מתחבר לקלאסטר הקוברנטיס, ומאפשר שליטה ושלל פקודות שימושיות.

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

set-context

הפקודה set-context מאפשרת לכן להגדיר את הסביבה והקלאסטר שאתן רוצות לעבוד איתו.

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

kubectl config set-context <cluster_name> --namespace <my_namespace>

Get Pods

הפקודה get pods מחזירה את כל הפודים שרצים בסביבה שלכן

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

kubectl get pods

Logs

הפקודה logs מחזירה את כל הלוגים שמגיעים מפוד יחיד

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

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

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

שם הפוד פה הוא השם המלא שאתן יכולות להעתיק מהתוצאה של פקודת ה-get pods שהרצתן. אני תמיד משתמשת ב- f- שמפעיל את הפקודה במצב tail. כלומר – ממשיך לרשום את הלוגים כשהם מגיעים, בלי לעצור.

kubectl logs --<my_pod> -f

Scale deployment

הפקודה scale deployment מאפשרת לכן להגדיל או להקטין את כמות הפודים שמריצים אפליקציה מסוימת. 

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

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

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

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

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

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

 kubectl scale deployment <deployment_name-name> --replicas=0 -n <my_namespace>

כדי להעלות בחזרה את מספר הרפליקות והפוד נשתמש ב –

 kubectl scale deployment <deployment_name> --replicas=1 -n <my_namespace>

Edit deployment

הפקודה edit deployment מאפשרת לכן לערוך את הגדרות ה-deployment של אפליקציה ספציפית.

עוד פקודה מסוכנת אך מאוד שימושית בסביבת סטייג’ינג. הפקודה edit deployment מאפשרת לכן לערוך את קובץ ה-deployment של אפליקציה מסוימת. כלומר – לשנות את הגדרות ההרצה שלה.

אני משתמשת בפקודה הזו בדרך כלל כשאני רוצה לשנות את ה-branch או הגרסה שפוד מסוים מריץ – אני פשוט מחליפה את ה-image שממנו הפוד נמשך ב-image הרצוי.

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

 kubectl edit deployments.apps <deployment_name> -n <my_namespace>

Port-Forward

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

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

בגדול מה ש-port-forward מאפשרת לכן לעשות זה להתחבר לשירותים שונים שרצים על הפוד, כאילו הם רצים לוקאלית על המחשב שלכן. כך אפשר לעשות כל מיני דברים כיפים – למשל, להשתמש בתוכנות  GUI שאתן רגילות לעבוד איתן.

בפוסט הזה הסברתי איך להשתמש ב-ssh-tunneling, וכדוגמא נתתי את השימוש ב-robo3t לעבודה נוחה על שרת מרוחק. אותו הדבר נכון גם פה. אם תשתמשו ב-port-forward שמחבר בין הפורט של מונגו על הפוד שלכן לפורט לוקאלי על המחשב שלכן, תוכלו להתחבר למונגו על הפוד בעזרת robo3t.

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

 kubectl port-forward svc/<app_name> <local-port>:<service-port>

אם אתן לא יודעות מה הוא בדיוק השם של ה-service שאתן צריכות, אתן יכולות להשתמש גם בשם המלא של הפוד – 

 kubectl port-forward <pod_name> <local-port>:<service-port>

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

הערות: