התקנה של Kubernetes - Kubectl
/usr/local/bin), כדי שאפשר יהיה להריץ אותו מכל מקום.kubectl config view מציג את הקונטקסט הפעיל, ו-kubectl version --short מציג גם את גרסת השרת.source <(kubectl completion bash) מוסיף השלמה בלחיצה על Tab. כך אפשר להקליד חלק מהפקודה ולקבל את שאר השם.kubectl version --short, kubectl config view, kubectl get pods, kubectl get deployment, kubectl get services, kubectl get nodes, kubectl logs -f, kubectl exec -it, kubectl delete.פרקי ההרצאה: התקנה של Kubernetes - Kubectl
תמלול ההרצאה: התקנה של Kubernetes - Kubectl
הטקסט המלא של הדקות הראשונות בהרצאה «התקנה של Kubernetes - Kubectl» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם, ברוכים הבאים להרצאות על קוברנטיס. אנחנו מתחילים סוף סוף את החלק החשוב הזה שמשתמשים בו המון בארגונים גדולים. ומה שעשינו בהרצאות קודמות, הקמנו קלאסטר של סוורם ושמנו בפנים אתר אינטרנט של קליינט 1 על וורדפרס וקליינט 2 על וורדפרס.
כל זה היה בהרצאות קודמות. עכשיו אנחנו רוצים להקים עוד פעם קלאסטר רק עם קוברנטיס. למעשה קוברנטי זה המתחרה של סוורם, הם עושים אותו דבר, מה הם עושים?
הם מנהלים את הנודים, את השרתים השונים שיעבדו כיחידה אחת ואם שרת אחד נופל הקונטיינרים שאמורים להיות עליו מורצים אוטומטית מתוך אימג' נקי על שרת פיזי אחר, זה נקרא אורקסטרציה.
אנחנו עכשיו הולכים לבטל את מה שעשינו בהרצאות קודמות, עשינו Layer 7 ראוטינג של Swarm, אתם רואים Swarm Layer 7 ראוטינג, שזה למעשה ניתוב בין קליינט 1 לקליינט 2, למרות ששניהם מגיעים בפורט 80. דיברנו על זה, אנחנו מבטלים אותו, ולמעשה מה שקורה, שאנחנו משחררים את פורט
80. בואו נעשה docker.ps.grep.2.80, הנה הוא שחרר לנו את פורט 80, לפני כן הוא כן היה תפוס, זאת אומרת, אם אני מחזיר את זה שנייה אחת, אני רק מראה לכם שלפני כן הוא היה תפוס, תכף הוא ייכנס לפעולה ואנחנו נראה אותו עובד.
רגע, בואו נעשה, נבדוק איפה יש פורט 80. הנה, אני רואה שיש לנו פה פורט 80. למה הוא לא פתוח לשום דבר, נכון?
למרות שהוא כן עובד, זאת אומרת שאם אנחנו ניכנס לקליינט 1 אנחנו נראה שהוא כן עובד, כן? וגם קליינט 2 הוא עובד. אז למה אנחנו לא רואים את המיפוי שלו?
בגלל שזה לא ברמת הקונטיינר ספציפי, אלא ברמת סרוויס. סרוויס ls אנחנו רואים פה בסרוויס ls שיש לנו פה פורט פתוח פורט 80 אתם רואים פה אנחנו רואים פה פורט 80 פתוח ואנחנו רוצים לסגור אותו ולבטל אותו כי אנחנו לא הולכים להשתמש יותר עם סרוויסים שהם חלק מסוורם נכון דיברנו על זה שזה חלק מסוורם אנחנו מבטלים
את זה ואנחנו הולכים להשתמש בקוברנטיס ל-R7 ראוטינג למעשה קוברנטיס וסוורם מתחרים ביניהם יופי אז חיבינו את זה ברגע אחרי שחיבינו את זה, בואו נראה מה קרה.
ServiceLS, אין לנו יותר port 80, אנחנו רואים פה 80.80 נשאר, שזה כבר משהו אחר, אבל port 80 התפנה לנו. יפה מאוד, כי אני צריך אותו.
בואו נראה מה עוד עשינו לפני כן. נסגור את זה. מה היה לנו עוד? קודם כל ככה, יש לנו shared resources, דברים משותפים, והולכים ל-stack.
דברים משותפים זה לדוגמה נודים של שירתים פיזיים, stack של תוכנות. הנה, פה אני רואה שזה Swarm Service, אז אני עושה לו פה Remove.
אני מזכיר לכם מה זה Service. Service מוודא שרצים קונטיינרים מסוימים, וגם נותן שירות של Name Resolving של DNS לפי השם של הסרוויס, וגם בונה להם נטוורק משלהם.
אתם רואים, גם נטוורק הוא בונה להם, גם מריץ להם קונטיינרים, גם עושה להם Name Resolving, וגם אם קונטיינר אחד נופל, הוא מרים אותו בשרת אחר, אז הוא עושה גם פרסום שלו על ידי נטוורקינג וגם לוודא שיש מספיק קונטיינרים.
כנראה בקוברנטיס שהם הפרידו את זה. יש אחד שמפרסם איזושהי אפליקציה כפרוקסי כזה, כרווירס פרוקסי, והשני שמוודא שיש מספיק קונטיינרים.
יופי, אז מחקנו את הסטייק, אז יופי, יש לנו הכל נקי. עכשיו, מה חשוב להדגיש? שגם קוברנטיס וגם Swarm בסוף מריצים קונטיינרים פשוטים. בסוף בסוף רצים קונטיינרים של דוקר.
לא משנה איזה ארכיסטרייטור, איזה מנהל גדול יריץ אותם. זה אותם אימייג'ים, אותם קונטיינרים. טוב, בואו נראה בסרוויסים מה יש לנו פה עוד. יש לנו את כל הסרוויסים האלו שעשינו בתוך ה-swarm.
גם אותם אני רוצה למחוק. אני עושה גם עליהם רימוב. יופי. וכשאני מוחק סרוויסים, נמחקים לי הקונטיינרים.
הנה, אתם רואים, הם נמחקו. ראיתם שהם עברו למצב של אדום כזה? אקזיט. יפה מאוד. טוב אז ניקינו אותו אין לנו סרוויסים נטוורקים נטוורק זה כל הדברים המובנים אני לא נוגע בהם סיקרט דיברנו עליהם זהו אז אנחנו נקיים ואפשר לעשות אותו דבר בקוברנטיס עוד פעם מה המטרה של קוברנטיס ומה המטרה של סוורם המטרה של שניהם זה אחד להריץ קונטיינרים שהגדרתי
להם כמצב רצוי לדוגמה הגדרתי שני קונטיינרים של וורדפרס כמצב רצוי אם אחד מהם נופל או השרת נופל או קונטיינר נופל הוא ישר מריץ אותו במקום אחר מחדש וגם הוא מפרסם אותם כלפי חוץ ברמת סרוויס ואז אם לקוח ניגש לא משנה לאיזה מהשרתים הפיזיים הוא יודע להיות מנותב לשרת שבו נמצא הקונטיינר
הבאמת ברגע זה יכול להיות שיש לי 20 שרתים ורק שני קונטיינרים אז הלקוח לא צריך לעקוב אחרי זה יש שירות של פרסום השירותים מה שנקרא אינגריס ה-Ingress הזה מוודא שהקליינט מגיע למקום הנכון.
יפה מאוד, ו-Volumes זה חיבור להרדיסק הפיזי. ו-Secretים זה מידע סודי שמוצפן בתוך הדאטאבייס של קלאסטר של Swarm, ונשמר שמה, וניתן לקונטיינר לפי הצורך.
Configuration זה הגדרות, כמו Secret, גם זה נשמר בדאטאבייס של קלאסטר, רק שהוא לא מוצפן, שהוא לא סודי.
ו-Secret הוא סודי, זה סתם הגדרות שאפשר להצמיד לקונטיינר. טוב, אז בואו נעבור לקוברנטיס.
אז עוד פעם, קוברנטיס בסופו של דבר יבנה לנו אותם קונטיינרים מאותם אימג'ים והוא ינהל אותם. בקוברנטיס יש לנו ניימספייסס, חלוקה לפי חברות.
אני יכול לכווץ אותם, להגביל אותם לפי חברה או לפי איזושהי קבוצה שאחד לא יראה את השני. ופה אני קובע האם אני כרגע רואה פה את כולם או רק משהו ספציפי. נניח, תראו, נניח ב-pods, pods זה קונטיינרים, בוא נניח כרגע שזה קונטיינרים למעשה זה קבוצה של קונטיינרים
הקוברנטיס לא עובד עם קונטיינר בודד הוא רוצה לאסוף אותם לקבוצה קטנה ולעבוד עם הקבוצות האלו בקבוצה יכולים להיות קונטיינר אחד או שתיים או שלוש אבל כל מי שבקבוצה רואה את כל מי שלידו ויש להם אותה כתובת IP יש להם את אותו סביבה מבודדת הם מאוד מאוד קשורים אחד לשני ולכן בפועל לרוב כל קונטיינר רטוב בפוד משלו אז פוד
זה משהו שלא היה בסוורם זה אריזה סביב קונטיינר ולרוב בכל פוד יהיה רק קונטיינר אחד אם אנחנו רוצים שהם יהיו ממש קשורים אחד לשני ויש להם אותו כתובת IP זה ממש כמו שני פרוצסים באותו מחשב שרואים אחד את השני ואין בידיהם שום בידוד נשים אותם באותו פוד לרוב זה לא נהוג אז ניימספייס בעצם אתם רואים אין לי פה אף פוד כרגע אבל אם אני אלך לניימספייס
ואני אגיד לו שאני רוצה לראות לדוגמה סיסטם, אני עושה קונטקסט של סיסטם במקום דיפולט, אז אני ארבה פודס, אני אראה את כל מה שקשור למערכת, לדוגמה יש לו את ה-DNS הפנימי.
זה למעשה קונטיינר שרץ, פודס זה קונטיינר שרץ ונותן שירותי DNS ללקוחות של קוברנטיס. אני יכול לעשות name space default שזה ברירת מחדל שהוא יראה לי, אני יכול לעשות סיסטם ואני יכול להגיד שאני רוצה לראות הכל, ברגע שאני רוצה לראות הכל אני אראה את כל הדברים.
לבחינתי אני לא רוצה לראות את הכל, אני רוצה לראות רק את הדיפולט, שזה זה שלי, מה שאני אבנה ייכנס לדיפולט, אין לי צורך לפרק אותם לחברות משניהם.
דרך אגב, אם אני רוצה לבנות פוד חדש, אני עושה קריאייט, ותראו איזה יופי ממשק גרפי, רק שואל אותי באיזה נדיים ספייס אני רוצה לעשות את זה, באיזה פרויקט או באיזה חברה, כאילו איך לבודד אותו, נניח דיפולט, וזהו.
ופה תכתוב מה שאתה רוצה. זאת אומרת, אתה צריך לכתוב את ה-yaml, yaml זה קובץ טקסט בפורמט שנקרא yaml, כמו json או כמו html, כל מיני פורמטים של קבצים יש, אז אנחנו צריכים פורמט yaml, ראינו אותו לפני כן, וצריך להכניס פה את הפורמט הזה וללחוץ לו create.
כמו שאתם רואים, זה לא באמת עוזר לי מאישור כל ה-create הזה. אין לו ממשק יפה כמו שהיה שם, לדוגמה services, וזה חושף לי את הפודים החוצה, את הקונטיינרים החוצה, מפרסם לי אותם החוצה.
שימו לב, הוא רק מפרסם החוצה, הוא לא מייצר קונטיינרים חדשים כמו שהיה בסוורם, הוא רק מפרסם אותם, אני עושה קריאייט, וגם פה אין כלום.
הבנתם שהממשק הגרפי של קוברנטיס צולע? לעומת, לעומת לדוגמה בסוורם, אם נלך לסרוויסס, שהוא גם מפרסם וגם מייצר אותם, תראו איזה יופי, יש פה את הכל מאוד יפה, הוא שואל אותי איזה אימג' והכל.
תשאלו למה בסווארם זה כזה יפה ובקוברנטיס זה לא יפה? כי סווארם הם מנסים לטפח כי זה חבר'ה של דוקר, מוכרים לך את הכלי הניהול הזה שמנהל את הסווארם.
הוא גם יודע לנהל את הקוברנטיס אבל הם רוצים שתשתמש בסווארם כי קוברנטיס זה המתחרה שלהם והמתחרה הזה מי שעשה אותו זה חברת גוגל. חברת גוגל השתמשו בקוברנטיס איזה 15 שנה ויש יש להם המון המון ניסיון עם הניהול של קונטיינרים אצלם בתוך החברה שזאת חברה נקית גוגל כן ובסוף הם נתנו את הקוד הזה באיזה 2014 משהו כזה לעולם אז קוברנטיס זה למעשה מוצר פנימי של
גוגל שניתן לכל העולם בחינם כאופן סורס והוא עושה את העבודה של סווארם שאותם מפתחים חברת דוקר עצמם אז אולי יש להם פה איזה מניע נסתר ככה לתמוך בקוברנטיס בקושי או שהם פשוט לא הספיקו לייצר לזה ממשק גרפי כמו שצריך, בכל מקרה זה לא משנה לנו.
דרך אגב, תראו פה, כשאנחנו משנים פה את ה-Namespace, תראו את זה, זה פה משתנה, אתם רואים? אז אתם רואים, על מה אתם מסתכלים? אתם רואים, אתם רואים פה פודים של קיוב, כן? פודים, אמרנו זה כמו קונטיינרים מבחינתי.
הלאה. אז אם אני עושה פה קונטקסט, זה default, ואם אני אעשה ככה, זה All Namespaces. טוב, בואו נעשוב את ה-Namespaces, תדעו שזה למעשה בידוד, זה בידוד גם ברמת הסרוויסים שהם רואים, ברמת הפרוצסים שהם רואים, את ה-Stack, כתובות ה-IP, כל פוד יש לו כתובת ה-IP משלה.
טוב, אז Namespaces זה למעשה בידוד של תהליך כלשהו במחשב. טוב, אנחנו רוצים להתחיל לעבוד, אז הבנו שזה לא יעזור לנו, הממשק הגרפי לא יעזור לנו, ניקינו את הכל, עכשיו אנחנו יכולים לעבור ל...
אה, רציתי לנקות עוד משהו, רציתי לנקות גם ב-My Profile את מה שעשינו לפני כן עם תעודות הדיגיטליות, כדי להתחיל הכל ממש מ-0,0 בדאונלודס.
אני גם מנקה את הבנדל הזה של התעודות הדיגיטליות, כי אני רוצה להתחיל הכל מ-0. טוב, חברים, אנחנו מוכנים להתקין, להתחיל להתקין את הכלי שזה Command Line, כי הדבר הזה לא ממש יעזור לי, נכון? אנחנו נצטרך לעשות הכל ב-Command Line, כל דבר שאני רוצה לעשות, אני צריך לכתוב את ה-object.yaml הזה, אז אני כבר אעשה הכל בשורת פקודה,
כי הממשק הזה לא באמת עוזר לי. אז איך אנחנו מריצים פקודות ב-Kubernetes? יש לנו כלי שזה קליינט שנקרא קיוב CTL. קיוב CTL שולח פקודות ל-API של קוברנטי. זה למעשה