מהו Kubernetes?

הקדמה

קוברנטס הוא מערכת קוד פתוח עוצמתית, שפותחה בהתחלה על ידי Google ומתומכת על ידי ה־Cloud Native Computing Foundation (CNCF), לניהול של יישומים בתכונת נושאים בסביבה מקוונת. המטרה היא לספק דרכים טובות יותר לניהול רכיבים מתואמים ושירותים מתואם בתשתיות מגוונות. למידע נוסף על Kubernetes, ניתן לעיין במדריך למטה. אם אתה מחפש שירות ניהול Kubernetes מנוהל, בדוק את שירות ה־Kubernetes הפשוט שלנו, הנבנה לצמיחה.

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

מהו Kubernetes?

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

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

ארכיטקטורת Kubernetes

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

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

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

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

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

רכיבי שרת המאסטר

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

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

etcd

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

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

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

kube-apiserver

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

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

kube-controller-manager

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

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

kube-scheduler

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

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

cloud-controller-manager

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

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

רכיבי השרתים של הצומת

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

A Container Runtime

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

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

kubelet

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

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

kube-proxy

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

אובייקטים ועובדות של Kubernetes

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

גבות

A pod is the most basic unit that Kubernetes deals with. Containers themselves are not assigned to hosts. Instead, one or more tightly coupled containers are encapsulated in an object called a pod.

A pod generally represents containers that should be controlled as a single application. Pods consist of containers that operate closely together, share a life cycle, and should always be scheduled on the same node. They are managed entirely as a unit and share their environment, volumes, and IP space. In spite of their containerized implementation, you should generally think of pods as a single, monolithic application to best conceptualize how the cluster will manage the pod’s resources and scheduling.

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

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

בקרי שיבוץ וקבוצות שיבוץ

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

A replication controller is an object that defines a pod template and control parameters to scale identical replicas of a pod horizontally by increasing or decreasing the number of running copies. This is an easy way to distribute load and increase availability natively within Kubernetes. The replication controller knows how to create new pods as needed because a template that closely resembles a pod definition is embedded within the replication controller configuration.

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

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

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

הטמעות

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

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

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

סטים מודיעים

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

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

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

סטי דיימון

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

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

עבודות ו-Cron Jobs

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

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

רכיבים נוספים של Kubernetes

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

שירותי Kubernetes

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

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

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

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

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

נפחים ונפחים עמידים

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

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

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

תוויות והערות

A Kubernetes organizational abstraction related to, but outside of the other concepts, is labeling. A label in Kubernetes is a semantic tag that can be attached to Kubernetes objects to mark them as a part of a group. These can then be selected for when targeting different instances for management or routing. For instance, each of the controller-based objects use labels to identify the pods that they should operate on. Services use labels to understand the backend pods they should route requests to.

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

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

מסקנה

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