ארכיטקטורה של Kubernetes
IP tables).kubectl ששולח בקשות HTTP. הוא היחיד שניגש לדאטה בייס שבו נשמר כל המידע.פרקי ההרצאה: ארכיטקטורה של Kubernetes
תמלול ההרצאה: ארכיטקטורה של Kubernetes
הטקסט המלא של הדקות הראשונות בהרצאה «ארכיטקטורה של Kubernetes» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
שלום לכולם. בסרטון זה נדבר על המרכיבים שיש לנו בתוך הקוברנטיס. קודם כל יש לנו חלוקה בין שרתים שמריצים את הפודים ואת הקונטיינרים שנקראים worker nodes, שתכלס עליהם רצים הקונטיינרים, השרתים שלנו והיוזרים מתחברים אליהם ומקבלים את השירות שלהם דרך load balancer חיצוני.
ויש לנו את המאסטרים שמנהלים את כל הקלסטר ומחליטים על איזה worker יעבוד איזה קונטיינר. הם אלו שעוקבים אחרי המצב של הקלסטר, אחרי העומס של הקלסטר.
הם מקבלים את ההחלטות. האם צריך להרים עוד פוד, עוד קונטיינר או שצריך להוריד קונטיינר? תלוי בעומס, תלוי בדרישות, תלוי במה שמנהל רשת העביר.
אז המאסטרים פה למטה הם המפקדים שמקבלים החלטות והworkerים, אלו הם החיילים שמבצעים את זה בפועל. דרך אגב, אם יש לי רשת קטנה, אני יכול להתקין את שני התפקידים האלו של worker ושל המאסטר על אותו שרת פיזי.
זאת אומרת שאני יכול לקחת שרת אחד פיזי ולשים עליו גם את התוכנה של worker וגם את התוכנה של המאסטר, ואז יהיה לי קלסטר קטן של שלושה שרתים פיזיים בלבד, וכל שרת גם יהיה שותף בקבלת החלטות.
הוא גם יהיה מפקד וגם החייל הפשוט שמבצע את ההחלטות. זה מה שקורה ברשתות קטנות. שמים הכל על אותו שרת. יותר מזה, אפשר לעשות את כל הקלסטר על שרת אחד בלבד.
יהיה מאסטר אחד ועליו worker אחד וזהו. כל הקוברנטיס יהיה על שרת אחד. אחרי זה אפשר יהיה להוסיף עוד אחד, אבל בפועל רוב הארגונים הם יותר גדולים והם שמים בנפרד את workerים עם הרבה זיכרון, הרבה מעבדים, ויכולים להיות עשרות workerים כאלו שמריצים את הקונטיינרים.
הכל תלוי בעומס הפיזי שיש על השרתים, ובנפרד שמים שרתים שיהיו רק המאסטרים שיקבלו החלטות. בגלל שהמאסטר הזה הוא מאוד מאוד חשוב בלעדיו הworker לא ידע מה לעשות, אז שמים שלושה או חמישה מאסטרים כי יש חוק בקלסטר שהקלסטר ממשיך לעבוד אך ורק עם רוב השרתים בו זמינים, ואנחנו מדברים על הרוב של המאסטרים שחייב להיות זמין.
זה אומר שאם יש לי פה שלושה שרתים, לפחות שניים חייבים להיות זמינים והשלישי יכול ליפול ולהתנתק. אם אני רוצה ששני שרתים יפלו והקלסטר ימשיך לעבוד תקין, אני צריך שבקלסטר יהיו חמישה שרתים, חמישה מאסטרים.
אם אני אשים חמישה מאסטרים, שניים יפלו, אבל עדיין שלושה מאסטרים יישארו באוויר, ושלושה זה יותר מחצי זה רוב והקלסטר ימשיך לעבוד. אז אתם מקבלים החלטה מה הסנריו, מה התסריט שאליו אתם רוצים להיות מוכנים.
אם אתם רוצים להיות מוכנים לתסריט ששרת אחד נופל ואתם זריז מחליפים אותו, אז מספיק לכם שלושה מאסטרים. אם אתם יודעים שלוקח בארגון שלכם מלא זמן לאשר תקציב, מלא זמן להביא את השרת, להחליף אותו, אז עד שמתקנים שרת אחד יכול בינתיים ליפול גם שרת שני, ואתם רוצים להיות מוכנים לתסריט של שני שרתים בו זמנית נופלים והקלסטר ממשיך לעבוד, אז מראש תקנו חמישה מאסטרים.
בכל מקרה, כדי שכל הקוברנטיס יעבוד תקין צריך שהקלסטר של המאסטרים יענה לשאילתות שמגיעות מ-kublet service, מהמרכיב הזה, לתוך API server, וכדי ש-API server בתוך המאסטר יעבוד צריך שהקלסטר של המאסטרים יעבוד תקין.
ה-kublet service הוא זה שאחראי על הרצה של הקונטיינרים, לבדוק את התקינות שלהם, להרים קונטיינר חדש, להוריד קונטיינר. הוא מתעדכן מול API server במאסטר, לבדוק את המצב שהוא צריך לתחזק אצלו, והחבר שלו cube proxy אחראי על כל הנושא של תקשורת.
תקשורת בין הפודים, תקשורת מול היוזרים. הוא מתעסק בכל ה networking, routing, ניהול של ה-firewall, של IP tables. כל הנושא של תקשורת זה ב-cube proxy. כל הנושא של ניהול פוד של הקונטיינר זה kubelet.
בכל מקרה, שניהם מתקשרים מול שרת API במאסטר. שימו לב שכל התקשורת בקלסטר מתבצעת מול שרת API שנמצא בתוך המאסטר. יש לו עוד שם Control plane.
אז גם ה-worker nodes וגם כל המרכיבים של המאסטר, כולם מתקשרים אחד עם השני דרך שרת API. גם המנהל הרשת עם הכלי שלו kubectl שולח את ההוראות שלו לשרת API.
למעשה kubectl הזה מאחורי הקלעים שולח בקשות HTTP לתוך שרת API, ושרת API מתקשר מול כל הרכיבים האחרים כולל הדאטה בייס. למעשה כל המידע נשמר בדאטה בייס והיחיד שניגש לדאטה בייס זה שרת API.
אז נניח שמנהל רשת דרך kubectl או דרך שילטות HTTP רגילה מעביר בקשה לשרת API שיהיו מינימום שלושה פודים, שלושה קונטיינרים מאפליקציה מסוימת. שרת API מעביר בקשה ל-controller manager.
התוכנה הזאת משווה בין המצב הקיים בתוך