כיצד להשתמש ב-kubectl בצורה יעילה יותר: מדריך מפורט

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

קבוצה Kubernetes aaS מ-Mail.ru תרגם מאמר מאת דניאל וויבל בו תמצאו טיפים וטריקים לעבודה יעילה עם kubectl. זה גם יעזור לך לקבל הבנה מעמיקה יותר של Kubernetes.

לדברי המחבר, מטרת המאמר היא להפוך את העבודה היומיומית שלך עם Kubernetes לא רק ליעילה יותר, אלא גם למהנה יותר!

מבוא: מה זה kubectl

לפני שתוכל ללמוד להשתמש ב-kubectl בצורה יעילה יותר, עליך לקבל הבנה בסיסית של מה זה ואיך זה עובד.

מנקודת מבט של משתמש, kubectl הוא לוח בקרה המאפשר לך לבצע פעולות Kubernetes.

מבחינה טכנית, kubectl הוא לקוח של Kubernetes API.

Kubernetes API הוא HTTP REST API. API זה הוא ממשק המשתמש האמיתי של Kubernetes, שדרכו הוא נשלט לחלוטין. המשמעות היא שכל פעולת Kubernetes נחשפת כנקודת קצה API וניתן לבצע אותה באמצעות בקשת HTTP לאותה נקודת קצה.

לכן, התפקיד העיקרי של kubectl הוא לבצע בקשות HTTP ל-Kubernetes API:

Kubernetes היא מערכת מוכוונת משאבים לחלוטין. המשמעות היא שהיא שומרת על המצב הפנימי של המשאבים וכל פעולות Kubernetes הן פעולות CRUD.

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

בואו נסתכל על דוגמה.

נניח שאתה רוצה ליצור משאב ReplicaSet. לשם כך, אתה מתאר את ReplicaSet בקובץ לפי שם replicaset.yaml, ואז הפעל את הפקודה:

$ kubectl create -f replicaset.yaml

פעולה זו תיצור משאב ReplicaSet. אבל מה קורה מאחורי הקלעים?

ל-Kubernetes יש פעולת יצירת ReplicaSet. כמו כל פעולה אחרת, היא חשופה כנקודת קצה של API. נקודת הקצה הספציפית של ה-API עבור פעולה זו נראית כך:

POST /apis/apps/v1/namespaces/{namespace}/replicasets

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

לפיכך, כאשר אתה מבצע את הפקודה לעיל, kubectl שולח בקשת HTTP POST לנקודת הקצה של ה-API שלמעלה. הגדרת ReplicaSet שסיפקת בקובץ replicaset.yaml, נשלח בגוף הבקשה.

כך פועל kubectl עבור כל הפקודות המקיימות אינטראקציה עם אשכול Kubernetes. בכל המקרים הללו, kubectl פשוט מבצע בקשות HTTP לנקודות הקצה המתאימות של Kubernetes API.

שים לב שאתה יכול לנהל את Kubernetes באופן מלא באמצעות כלי שירות כגון curlעל ידי שליחת בקשות HTTP ידנית ל-Kubernetes API. Kubectl פשוט מקל על השימוש ב-Kubernetes API.

זה היסודות של מה זה kubectl ואיך זה עובד. אבל יש משהו אחר ב-Kubernetes API שכל משתמש kubectl צריך לדעת. בואו נסתכל במהירות על העולם הפנימי של Kubernetes.

העולם הפנימי של Kubernetes

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

להלן הרכיבים החשובים ביותר בצמתים הראשיים:

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

והנה מרכיב אחד חשוב ביותר בצמתי העובד:

1. קובלט - מנהל את ההשקה של מכולות בצומת העבודה.

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

בוא נניח שזה עתה סיימת kubectl create -f replicaset.yaml, שלאחריו kubectl ביצעה בקשת HTTP POST אל נקודת קצה של ReplicaSet API (מעביר את הגדרת המשאב של ReplicaSet).

מה קורה באשכול?

1. לאחר מעשה kubectl create -f replicaset.yaml שרת ה-API מאחסן את הגדרת המשאב של ReplicaSet באחסון:

   

2. לאחר מכן, בקר ה-ReplicaSet מופעל במנהל הבקר, המטפל ביצירה, שינוי ומחיקה של משאבי ReplicaSet:

   

3. בקר ה-ReplicaSet יוצר הגדרת פוד עבור כל העתק של ReplicaSet (לפי תבנית הפוד בהגדרת ReplicaSet) ומאחסן אותם באחסון:

   

4. מתזמן מופעל, עוקב אחר תרמילים שעדיין לא הוקצו לשום צומת עובדים:

   

5. המתזמן בוחר צומת עובד מתאים לכל פוד ומוסיף מידע זה להגדרת הפוד בחנות:

   

6. בצומת העובד שאליו מוקצה הפוד, Kubelet מופעל, הוא עוקב אחר הפודים שהוקצו לצומת זה:

   

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

   

להלן גרסת טקסט של תיאור זה.

בקשת ה-API לנקודת הקצה של יצירת ReplicaSet מעובדת על ידי שרת ה-API. שרת ה-API מאמת את הבקשה ומאחסן את הגדרת המשאב של ReplicaSet באחסון.

אירוע זה מתחיל את בקר ReplicaSet, שהוא תת-תהליך של מנהל הבקר. בקר ReplicaSet עוקב אחר יצירה, עדכון ומחיקה של משאבי ReplicaSet בחנות ומקבל הודעה על אירוע כאשר זה מתרחש.

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

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

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

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

בשלב זה, אפליקציית ReplicaSet שלך סוף סוף פועלת!

תפקיד ה-API של Kubernetes

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

כמובן שרכיבים אלו אינם מקיימים אינטראקציה ישירה עם האחסון, אלא רק דרך ה-API של Kubernetes.

שקול את הדוגמאות הבאות:

1. בקר ReplicaSet משתמש בנקודת הקצה של ה-API רשימת ReplicaSets עם פרמטר watch כדי לנטר שינויים במשאבי ReplicaSet.
2. בקר ReplicaSet משתמש בנקודת הקצה של ה-API ליצור Pod (יצירת תרמיל) כדי ליצור תרמילים.
3. מתזמן משתמש בנקודת קצה API תרמיל תיקון (ערוך פוד) כדי לעדכן פודים עם מידע על צומת העבודה שנבחר.

כפי שאתה יכול לראות, זהו אותו API אליו kubectl ניגשת. שימוש באותו API עבור רכיבים פנימיים ומשתמשים חיצוניים הוא רעיון בסיסי בעיצוב Kubernetes.

עכשיו אנחנו יכולים לסכם איך Kubernetes עובד:

1. חנויות האחסון מציינות, כלומר משאבי Kubernetes.
2. שרת ה-API מספק ממשק לאחסון בצורה של ה-API של Kubernetes.
3. כל שאר הרכיבים והמשתמשים של Kubernetes קוראים, מתבוננים ומתפעלים את מצב Kubernetes (משאבים) באמצעות ה-API.

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

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

1. האץ את הקלט באמצעות השלמת פקודה

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

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

ראה כיצד פועלת השלמת פקודות kubectl:

השלמת הפקודה פועלת עבור פגזי Bash ו-Zsh.

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

כיצד פועלת השלמת פקודה

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

Kubectl מייצר ומוציא אוטומטית סקריפטים של הרחבות עבור Bash ו-Zsh באמצעות הפקודות הבאות:

$ kubectl completion bash

Или:

$ kubectl completion zsh

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

בפועל, שיטת החיבור שונה עבור Bash (כולל הבדלים בין לינוקס ו-MacOS) ו-Zsh. להלן נבחן את כל האפשרויות הללו.

Bash על לינוקס

סקריפט השלמת Bash תלוי בחבילת bash-completion, אז תחילה עליך להתקין אותו:

$ sudo apt-get install bash-completion

Или:

$ yum install bash-completion

אתה יכול לבדוק שהחבילה מותקנת בהצלחה באמצעות הפקודה הבאה:

$ type _init_completion

אם זה מוציא קוד פונקציית מעטפת, אז bash-completion מותקן כהלכה. אם הפקודה מציגה שגיאה "לא נמצא", עליך להוסיף את השורה הבאה לקובץ שלך ~ / .bashrc:

$ source /usr/share/bash-completion/bash_completion

האם יש צורך להוסיף שורה זו לקובץ ~ / .bashrc או לא תלוי במנהל החבילות שבו השתמשת להתקנת bash-completion. זה הכרחי עבור APT, אבל לא עבור YUM.

לאחר התקנת bash-completion, עליך להגדיר הכל כך שסקריפט ההשלמה של kubectl יופעל בכל הפעלות המעטפת.

אחת הדרכים לעשות זאת היא להוסיף את השורה הבאה לקובץ ~ / .bashrc:

source <(kubectl completion bash)

דרך נוספת היא להוסיף את סקריפט ההרחבה kubectl לספרייה /etc/bash_completion.d (צור אותו אם הוא לא קיים):

$ kubectl completion bash >/etc/bash_completion.d/kubectl

כל הסקריפטים התוספים בקטלוג /etc/bash_completion.d נכללים אוטומטית בהשלמת bash.

שתי האפשרויות ישימות באותה מידה.

לאחר הפעלה מחדש של המעטפת, השלמת הפקודה kubectl תעבוד.

Bash על MacOS

ב-MacOS ההגדרה קצת יותר מסובכת. העובדה היא שכברירת מחדל, MacOS משתמש בגרסה 3.2 של Bash, וסקריפט ההשלמה האוטומטית של kubectl דורשת גרסת Bash של לפחות 4.1 ואינו עובד ב-Bash 3.2.

ישנן בעיות רישוי הקשורות לשימוש בגרסה מיושנת של Bash ב-MacOS. Bash גרסה 4 מורשית תחת GPLv3, שאינה נתמכת על ידי אפל.

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

לפני שתמשיך, ודא שאתה משתמש בגרסה עדכנית של Bash (בדוק את הפלט bash --version).

סקריפט השלמת Bash משתנה לפי פרויקט bash-השלמה, אז תחילה עליך להתקין אותו.

אתה יכול להתקין bash-completion באמצעות Homebrew:

$ brew install bash-completion@2

כאן @2 מייצג את גרסה 2 של השלמת bash. השלמה אוטומטית של kubectl דורשת השלמת bash v2, והשלמת bash v2 דורשת מינימום של Bash גרסה 4.1.

פלט פקודה brew-install מכיל קטע אזהרות, המציין מה צריך להוסיף לקובץ ~/.bash_profile:

export BASH_COMPLETION_COMPAT_DIR=/usr/local/etc/bash_completion.d
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . 
"/usr/local/etc/profile.d/bash_completion.sh"

עם זאת, אני ממליץ להוסיף שורות אלה לא ~/.bash_profile, בעוד ב ~/.bashrc. במקרה זה, השלמה אוטומטית תהיה זמינה לא רק בחלק הראשי, אלא גם במעטפות פקודות של ילד.

לאחר הפעלה מחדש של מעטפת הפקודה, תוכל לוודא שההתקנה נכונה באמצעות הפקודה הבאה:

$ type _init_completion

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

כעת עלינו לוודא שההשלמה האוטומטית של kubectl מופעלת בכל ההפעלות.

דרך אחת היא להוסיף את השורה הבאה שלך ~/.bashrc:

source <(kubectl completion bash)

הדרך השנייה היא להוסיף סקריפט השלמה אוטומטית לתיקיה /usr/local/etc/bash_completion.d:

$ kubectl completion bash
>/usr/local/etc/bash_completion.d/kubectl

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

אם התקנת kubectl באמצעות Homebrew, אז אין צורך לבצע את השלב הקודם, מכיוון שסקריפט ההשלמה האוטומטית ימוקם אוטומטית בתיקייה /usr/local/etc/bash_completion.d תוך כדי התקנה. במקרה זה, ההשלמה האוטומטית של kubectl תתחיל לעבוד ברגע שתתקין bash-completion.

כתוצאה מכך, כל האפשרויות הללו שוות ערך.

ZSH

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

אתה יכול לעשות זאת על ידי הוספת שורה לשורה שלך ~/.zshrc קוֹבֶץ:

source <(kubectl completion zsh)

אם אתה מקבל שגיאה not found: compdef לאחר הפעלה מחדש של המעטפת שלך, עליך להפעיל את הפונקציה המובנית compdef. אתה יכול להפעיל אותו על ידי הוספתו לתחילת הקובץ ~/.zshrc התעופה post

autoload -Uz compinit
compinit

2. הצג במהירות מפרטי משאבים

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

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

פורמט הפקודה הוא כדלקמן:

$ kubectl explain resource[.field]...

הפקודה תוציא את המפרט של המשאב או השדה המבוקש. המידע המוצג זהה לזה הכלול במדריך ה-API.

ברירת מחדל kubectl explain מציג רק את הרמה הראשונה של קינון של שדות.

תראה איך זה נראה לאחר מכן תוכל.

תוכל להציג את כל העץ אם תוסיף את האפשרות --recursive:

$ kubectl explain deployment.spec --recursive

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

$ kubectl api-resources

פקודה זו מציגה שמות משאבים בצורת רבים, למשל. deployments במקום deployment. זה גם מציג את השם הקצר, למשל deploy, עבור אותם משאבים שיש להם את זה. אל תדאג לגבי ההבדלים האלה. כל אפשרויות השמות הללו מקבילות עבור kubectl. כלומר, אתה יכול להשתמש בכל אחד מהם עבור kubectl explain.

כל הפקודות הבאות שוות ערך:

$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или        
$ kubectl explain deploy.spec

3. השתמש בפורמט פלט עמודה מותאם אישית

פורמט פלט פקודה ברירת מחדל kubectl get:

$ kubectl get pods
NAME                     READY    STATUS    RESTARTS  AGE
engine-544b6b6467-22qr6   1/1     Running     0       78d
engine-544b6b6467-lw5t8   1/1     Running     0       78d
engine-544b6b6467-tvgmg   1/1     Running     0       78d
web-ui-6db964458-8pdw4    1/1     Running     0       78d

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

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

השימוש בפורמט מותאם אישית נקבע באמצעות האפשרויות:

-o custom-columns=<header>:<jsonpath>[,<header>:<jsonpath>]...

ניתן להגדיר כל עמודת פלט כזוג <header>:<jsonpath>איפה <header> הוא שם העמודה, ו <jsonpath> - ביטוי המגדיר שדה משאבים.

בואו נסתכל על דוגמה פשוטה:

$ kubectl get pods -o custom-columns='NAME:metadata.name'

NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4

הפלט מכיל עמודה אחת עם שמות הפודים.

ביטוי האפשרות בוחר את שמות התרמילים מהשדה metadata.name. הסיבה לכך היא ששם הפוד מוגדר בשדה שם הילד metadata בתיאור המשאב של הפוד. פרטים נוספים ניתן למצוא ב מדריך API או הקלד את הפקודה kubectl explain pod.metadata.name.

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

$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,NODE:spec.nodeName'

NAME                       NODE
engine-544b6b6467-22qr6    ip-10-0-80-67.ec2.internal
engine-544b6b6467-lw5t8    ip-10-0-36-80.ec2.internal
engine-544b6b6467-tvgmg    ip-10-0-118-34.ec2.internal
web-ui-6db964458-8pdw4     ip-10-0-118-34.ec2.internal

הביטוי בוחר את שם הצומת spec.nodeName - כאשר פוד מוקצה לצומת, שמו כתוב בשדה spec.nodeName מפרט משאבי הפוד. מידע מפורט יותר ניתן למצוא בפלט kubectl explain pod.spec.nodeName.

שים לב ששדות המשאבים של Kubernetes הם תלויי רישיות.

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

אבל ראשית, בואו נסתכל מקרוב על ביטויי בחירת שדות.

ביטויי JSONPath

ביטויים לבחירת שדות משאבים מבוססים על JSON Path.

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

Kubectl explain תומך במספר מוגבל של תכונות JSONPath. האפשרויות והדוגמאות לשימוש בהן מתוארות להלן:

# Выбрать все элементы списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[*].image'
# Выбрать специфический элемент списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[0].image'
# Выбрать элементы списка, попадающие под фильтр
$ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'
# Выбрать все поля по указанному пути, независимо от их имени
$ kubectl get pods -o custom-columns='DATA:metadata.*'
# Выбрать все поля с указанным именем, вне зависимости от их расположения
$ kubectl get pods -o custom-columns='DATA:..image'

האופרטור [] חשוב במיוחד. שדות משאבים רבים של Kubernetes הם רשימות, ואופרטור זה מאפשר לך לבחור חברים ברשימות אלו. הוא משמש לעתים קרובות עם תו כללי כמו [*] כדי לבחור את כל הרכיבים של רשימה.

דוגמאות ליישום

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

1. הצגת תמונות מיכל עבור תרמילים:

   $ kubectl get pods 
     -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'
   
   NAME                        IMAGES
   engine-544b6b6467-22qr6     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-lw5t8     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-tvgmg     rabbitmq:3.7.8-management,nginx
   web-ui-6db964458-8pdw4      wordpress

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

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

2. הצגת אזורי זמינות של צומת:

   $ kubectl get nodes 
     -o 
   custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain.beta.kubernetes.io/zone'
   
   NAME                          ZONE
   ip-10-0-118-34.ec2.internal   us-east-1b
   ip-10-0-36-80.ec2.internal    us-east-1a
   ip-10-0-80-67.ec2.internal    us-east-1b

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

   אזור זמינות הוא מושג ענן המגביל את אזור השכפול לאזור גיאוגרפי.

   אזורי זמינות עבור כל צומת מתקבלים באמצעות תווית מיוחדת - failure-domain.beta.kubernetes.io/zone. אם האשכול פועל בענן ציבורי, תווית זו נוצרת באופן אוטומטי ומתמלאת בשמות של אזורי הזמינות עבור כל צומת.

   תוויות אינן חלק ממפרט המשאבים של Kubernetes, כך שלא תמצא מידע עליהן ב מדריך API. עם זאת, ניתן לראות אותם (כמו כל תוויות אחרות) אם אתה מבקש מידע על הצמתים בפורמט YAML או JSON:

   $ kubectl get nodes -o yaml
   # или
   $ kubectl get nodes -o json

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

4. מעבר בקלות בין אשכולות ומרחבי שמות

כאשר kubectl שולח בקשה לממשק ה-API של Kubernetes, הוא קורא תחילה את קובץ kubeconfig כדי לקבל את כל הפרמטרים הדרושים לחיבור.

כברירת מחדל, קובץ kubeconfig הוא ~/.kube/config. בדרך כלל קובץ זה נוצר או מתעדכן על ידי פקודה מיוחדת.

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

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

בפרק זה נסביר כיצד זה עובד וכיצד לגרום לזה לעבוד ביעילות.

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

קבצי kubeconfig

בוא נראה מה בדיוק מכיל קובץ kubeconfig:

כפי שאתה יכול לראות, קובץ kubeconfig מכיל קבוצה של הקשרים. ההקשר מורכב משלושה אלמנטים:

• אשכול - כתובת API של שרת האשכול.
• משתמש - אישורי אימות משתמש באשכול.
• מרחב שמות - מרחב השמות המשמש בעת ההצטרפות לאשכול.

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

בכל זמן נתון, אחד ההקשרים הוא עדכני:

כאשר kubectl קורא קובץ תצורה, הוא תמיד לוקח מידע מההקשר הנוכחי. בדוגמה למעלה, kubectl יתחבר לאשכול הארנב.

בהתאם, כדי לעבור לאשכול אחר, עליך לשנות את ההקשר הנוכחי בקובץ kubeconfig:

כעת kubectl יתחבר לאשכול פוקס.

כדי לעבור למרחב שמות אחר באותו אשכול, עליך לשנות את הערך של רכיב מרחב השמות עבור ההקשר הנוכחי:

בדוגמה שלמעלה, kubectl ישתמש במרחב השמות Prod של אשכול Fox (קודם לכן הוגדר מרחב השמות Test).

שימו לב ש-kubectl מספקת גם אפשרויות --cluster, --user, --namespace и --context, המאפשרים לך להחליף אלמנטים בודדים ואת ההקשר הנוכחי עצמו, ללא קשר למה שהוגדר ב-kubeconfig. תראה kubectl options.

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

השתמש ב-kubectx

כלי עזר פופולרי מאוד למעבר בין אשכולות ומרחבי שמות.

כלי השירות מספק פקודות kubectx и kubens כדי לשנות את ההקשר הנוכחי ואת מרחב השמות בהתאמה.

כאמור, שינוי ההקשר הנוכחי פירושו שינוי האשכול אם יש לך רק הקשר אחד לכל אשכול.

להלן דוגמה להפעלת הפקודות הללו:

בעיקרו של דבר, פקודות אלה פשוט עורכות את קובץ kubeconfig כמתואר לעיל.

להתקין kubectx, עקוב אחר ההוראות ב גית'וב.

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

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

שימוש בכינויי מעטפת

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

הנה כמה מהם:

• kubectl config get-contexts: הצג את כל ההקשרים;
• kubectl config current-context: לקבל הקשר נוכחי;
• kubectl config use-context: לשנות את ההקשר הנוכחי;
• kubectl config set-context: שנה את רכיב ההקשר.

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

יצרתי קבוצה של כינויים המבוססים על הפקודות הללו המספקות פונקציונליות דומה ל-kubectx. כאן תוכלו לראות אותם בפעולה:

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

להלן ההגדרות של הכינויים עצמם:

# Получить текущий контекст
alias krc='kubectl config current-context'
# Список всех контекстов
alias klc='kubectl config get-contexts -o name | sed "s/^/  /;|^  $(krc)$|s/ /*/"'
# Изменить текущий контекст
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'

# Получить текущее пространство имен
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print $5}" | sed "s/^$/default/"'
# Список всех пространств имен
alias kln='kubectl get -o name ns | sed "s|^.*/|  |;|^  $(krn)$|s/ /*/"'
# Изменить текущее пространство имен
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

כדי להגדיר כינויים אלה עליך להוסיף את ההגדרות לעיל לקובץ שלך ~/.bashrc או ~/.zshrc ואתחל מחדש את המעטפת שלך.

שימוש בתוספים

Kubectl מאפשר לך לטעון תוספים המופעלים באותו אופן כמו פקודות בסיסיות. אתה יכול, למשל, להתקין את התוסף kubectl-foo ולהפעיל אותו על ידי ביצוע הפקודה kubectl foo.

זה יהיה נוח לשנות את ההקשר ומרחב השמות בדרך זו, למשל על ידי הפעלה kubectl ctx לשנות הקשר ו kubectl ns כדי לשנות את מרחב השמות.

כתבתי שני תוספים שעושים את זה:

• kubectl-ctx
• kubectl-ns

עבודת התוספים מבוססת על כינויים מהסעיף הקודם.

כך הם עובדים:

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

כדי להתקין תוספים, עליך להוריד סקריפטים של מעטפת בשם kubectl-ctx и kubectl-ns לכל ספרייה במשתנה PATH שלך ולהפוך אותם לניתנים להפעלה עם למשל. chmod +x. מיד לאחר מכן תוכל להשתמש kubectl ctx и kubectl ns.

5. צמצם את הקלט עם כינויים אוטומטיים

כינויים של מעטפת הם דרך טובה להאיץ את הקלט. פּרוֹיֶקט kubectl-כינויים מכיל כ-800 קיצורי דרך לפקודות kubectl בסיסיות.

אתה אולי תוהה - איך אתה זוכר 800 כינויים? אבל אתה לא צריך לזכור את כולם, כי הם בנויים על פי תוכנית פשוטה, המפורטת להלן:

לדוגמה:

1. kgpooyaml - kubectl get pods oyaml
2. ksysgsvcw — kubectl -n kube-system קבל svc w
3. ksysrmcm -kubectl -n kube-system rm cm
4. kgdepallsl - kubectl קבל פריסה כל sl

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

התרשים המפורט הנוכחי נמצא ב- GitHub. שם גם אפשר למצוא רשימה מלאה של כינויים.

לדוגמה, הכינוי kgpooyamlall שווה ערך לפקודה kubectl get pods -o yaml --all-namespaces.

הסדר היחסי של האפשרויות אינו חשוב: פקודה kgpooyamlall שווה לפקודה kgpoalloyaml.

אינך חייב להשתמש בכל הרכיבים ככינויים. לדוגמה k, kg, klo, ksys, kgpo ניתן להשתמש גם. יתר על כן, ניתן לשלב כינויים ופקודות או אפשרויות רגילות בשורת הפקודה:

לדוגמה:

1. במקום זאת kubectl proxy אתה יכול לכתוב k proxy.
2. במקום זאת kubectl get roles אתה יכול לכתוב kg roles (אין כרגע כינוי למשאב התפקידים).
3. כדי לקבל נתונים עבור פוד ספציפי, אתה יכול להשתמש בפקודה kgpo my-pod — kubectl get pod my-pod.

שים לב שחלק מהכינויים דורשים ארגומנט שורת פקודה. למשל, כינוי kgpol אמצעים kubectl get pods -l. אוֹפְּצִיָה -l דורש ארגומנט - מפרט תווית. אם אתה משתמש בכינוי זה ייראה kgpol app=ui.

מכיוון שחלק מהכינויים דורשים ארגומנטים, הכינויים a, f ו-l חייבים לשמש אחרונים.

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

התקנה

כדי להתקין kubectl-aliases, עליך להוריד את הקובץ ‎.kubectl_aliases מ-GitHub ולכלול אותו בקובץ ~/.bashrc או ~/.zshrc:

source ~/.kubectl_aliases

השלמה אוטומטית

כפי שאמרנו קודם, לעתים קרובות אתה מוסיף מילים נוספות לכינוי בשורת הפקודה. לדוגמה:

$ kgpooyaml test-pod-d4b77b989

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

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

התשובה תלויה באיזו מעטפת אתה משתמש:

1. עבור Zsh, השלמת הכינוי פועלת מחוץ לקופסה.
2. עבור Bash, למרבה הצער, נדרשת עבודה מסוימת כדי שההשלמה האוטומטית תעבוד.

הפעלת השלמה אוטומטית עבור כינויים ב-Bash

הבעיה עם Bash היא שהוא מנסה להשלים (בכל פעם שאתה לוחץ על Tab) את הכינוי, ולא את הפקודה שהכינוי מתייחס אליה (כמו ש-Zsh עושה, למשל). מכיוון שאין לך סקריפטים להשלמה עבור כל 800 הכינויים, השלמה אוטומטית לא עובדת.

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

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

התקנת כינוי שלם

קודם כל, כינוי השלם תלוי ב bash-השלמה. לכן, לפני התקנת complete-alias, עליך לוודא שה-bash-completion מותקן. הוראות התקנה סופקו בעבר עבור Linux ו-MacOS.

הערה חשובה למשתמשי MacOS: כמו סקריפט ההשלמה האוטומטית של kubectl, complete-alias לא עובד עם Bash 3.2, שהיא ברירת המחדל ב-MacOS. בפרט, כינוי השלמה תלוי בהשלמה של bash v2 (brew install bash-completion@2), הדורש לפחות Bash 4.1. משמעות הדבר היא שכדי להשתמש בכינוי שלם ב-MacOS, עליך להתקין גרסה חדשה יותר של Bash.

אתה צריך להוריד את הסקריפט bash_completion.sh של מאגר GitHub ולכלול אותו בקובץ שלך ~/.bashrc:

source ~/bash_completion.sh

לאחר אתחול מחדש של המעטפת, ה-complet-alias יותקן במלואו.

הפעלת השלמה אוטומטית עבור כינויים של kubectl

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

כדי לשייך פונקציה לכינוי ספציפי, עליך להשתמש במנגנון Bash המובנה להשלים, להתקין _complete_alias כפונקציית השלמת כינוי.

כדוגמה, ניקח את הכינוי k, המייצג את הפקודה kubectl. להתקין _complete_alias כפונקציה משלימה עבור כינוי זה, עליך להפעיל את הפקודה הבאה:

$ complete -F _complete_alias k

התוצאה של זה היא שבכל פעם שאתה משלים אוטומטית כינוי k, הפונקציה נקראת _complete_alias, שבודק את הכינוי ומחזיר רמזים להשלמת הפקודה kubectl.

כדוגמה שנייה, ניקח את הכינוי kg, המציין kubectl get:

$ complete -F _complete_alias kg

בדיוק כמו בדוגמה הקודמת, כאשר אתה משלים אוטומטית ק"ג, אתה מקבל את אותם רמזי השלמה שהיית מקבל עבור kubectl get.

שים לב שאתה יכול להשתמש בכינוי השלם עבור כל כינוי במערכת שלך.

לכן, כדי לאפשר השלמה אוטומטית עבור כל הכינויים של kubectl, עליך להפעיל את הפקודה לעיל עבור כל אחד מהם. הקטע הבא עושה בדיוק את זה, בתנאי שהגדרת kubectl-כינויים ל ~/.kubectl-aliases:

for _a in $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases); 
do
  complete -F _complete_alias "$_a"
done

יש למקם את פיסת הקוד הזו בקובץ שלך ~/.bashrc, הפעל מחדש את מעטפת הפקודה וההשלמה האוטומטית תהיה זמינה עבור כל 800 הכינויים של kubectl.

6. הרחבת kubectl עם תוספים

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

אם אתה מכיר מנגנוני התוסף של Git, אז תוספי kubectl בנויים על אותו עיקרון.

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

התקנת תוספים

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

לדוגמה, תוסף hello יופץ כקובץ שנקרא kubectl-hello.

כדי להתקין את התוסף, עליך להעתיק את הקובץ kubectl-x לכל ספרייה ב-PATH שלך ולהפוך אותה לניתנת להפעלה, למשל עם chmod +x. מיד אחרי זה אתה יכול להתקשר עם התוסף kubectl x.

אתה יכול להשתמש בפקודה הבאה כדי לרשום את כל התוספים המותקנים כעת במערכת שלך:

$ kubectl plugin list

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

איתור והתקנה של תוספים באמצעות Krew

ניתן לשתף תוספים של Kubectl או לעשות בהם שימוש חוזר כמו חבילות תוכנה. אבל איפה אתה יכול למצוא תוספים שאחרים שיתפו?

פרויקט קרו שואפת לספק פתרון מאוחד לשיתוף, חיפוש, התקנה וניהול של תוספי kubectl. הפרויקט מכנה את עצמו "מנהל חבילות עבור תוספים של kubectl" (Krew דומה ל לְהִתְבַּשֵׁל).

Krew היא רשימה של תוספים של kubectl שאתה יכול לבחור ולהתקין. במקביל, Krew הוא גם תוסף ל-kubectl.

המשמעות היא שהתקנת Krew עובדת בעצם כמו התקנת כל תוסף kubectl אחר. תוכל למצוא הנחיות מפורטות בכתובת עמוד GitHub.

הפקודות החשובות ביותר של Krew הן:

# Поиск в списке плагинов
$ kubectl krew search [<query>]
# Посмотреть информацию о плагине
$ kubectl krew info <plugin>
# Установить плагин
$ kubectl krew install <plugin>
# Обновить все плагины до последней версии
$ kubectl krew upgrade
# Посмотреть все плагины, установленные через Krew
$ kubectl krew list
# Деинсталлировать плагин
$ kubectl krew remove <plugin>

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

שימו לב שהפקודה kubectl krew list מציג רק תוספים שהותקנו באמצעות Krew, ואילו הפקודה kubectl plugin list מפרט את כל התוספים, כלומר אלה שהותקנו באמצעות Krew ואלה שהותקנו בשיטות אחרות.

מציאת תוספים במקום אחר

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

אני ממליץ להסתכל בקטע GitHub kubectl-plugins. שם תמצאו עשרות תוספים זמינים ששווה לבדוק.

כתיבת תוספים משלך

אתה יכול בעצמך ליצור תוספים - זה לא קשה. אתה צריך ליצור קובץ הפעלה שעושה את מה שאתה צריך, שם זה כמו kubectl-x ולהתקין כמתואר לעיל.

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

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

צור קובץ kubectl-img התוכן הבא:

#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

כעת הפוך את הקובץ לניתן להפעלה עם chmod +x kubectl-img והעבר אותו לכל ספרייה ב-PATH שלך. מיד לאחר מכן תוכל להשתמש בתוסף kubectl img.

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

כיצד לשתף את התוספים שלך

אם אתה חושב שהתוספים שלך יכולים להיות שימושיים לאחרים, אל תהסס לשתף אותם ב-GitHub. הקפד להוסיף אותם לנושא kubectl-plugins.

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

השלמת פקודה

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

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

בהצלחה!!!

מה עוד לקרוא בנושא:

1. שלוש רמות של קנה מידה אוטומטי ב-Kubernetes וכיצד להשתמש בהן ביעילות.
2. Kubernetes ברוח הפיראטיות עם תבנית ליישום.
3. הערוץ שלנו Around Kubernetes בטלגרם.

מקור: www.habr.com