בדף הזה מתוארת הארכיטקטורה של אשכולות Google Kubernetes Engine (GKE) שמריצים את עומסי העבודה בקונטיינרים. בדף הזה מוסבר על מישור הבקרה, על הצמתים ועל האינטראקציה בין הרכיבים השונים של אשכול GKE.
הדף הזה מיועד לאדמינים, לאדריכלים ולמפעילים שמגדירים פתרונות IT וארכיטקטורת מערכת. מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם בתוכן זמין במאמר תפקידים נפוצים של משתמשים ומשימות ב-GKE. Google Cloud
לפני שקוראים את הדף הזה, חשוב להכיר את הארכיטקטורה של אשכול Kubernetes.
אשכול GKE מורכב ממישור בקרה וממכונות עבודה שנקראות צמתים. מישור הבקרה והצמתים מרכיבים את מערכת תזמור האשכולות של Kubernetes. GKE Autopilot מנהל את כל התשתית הבסיסית של האשכולות, כולל מישור הבקרה, הצמתים וכל רכיבי המערכת.
אם אתם משתמשים במצב GKE Standard, GKE מנהל את מישור הבקרה ואת רכיבי המערכת, ואתם מנהלים את הצמתים.
התרשים הבא מציג את הארכיטקטורה של אשכול GKE:
בתרשים הזה מוצגים הרכיבים הבאים:
- מישור הבקרה: מנוהל על ידי GKE. מריץ את שרת ה-API של Kubernetes, את בקרי עומסי העבודה, את מתזמן Kubernetes ואת אחסון מצב האשכול.
- צמתים: מנוהלים על ידי GKE במצב Autopilot, ומנוהלים על ידי לקוחות במצב Standard. כל ה-Pods פועלים בצמתים.
- שירותים Google Cloud אחרים: אפשר לשלב אותם עם GKE.
מידע על מישור הבקרה
מישור הבקרה מפעיל תהליכים כמו שרת ה-API של Kubernetes, מתזמן ובקרי משאבים מרכזיים. GKE מנהל את מחזור החיים של מישור הבקרה, החל מיצירת האשכול ועד למחיקתו. השדרוגים האלה כוללים שדרוגים לגרסת Kubernetes שפועלת במישור הבקרה, ש-GKE מבצע באופן אוטומטי, או באופן ידני לפי בקשתכם אם אתם מעדיפים לשדרג לפני התזמון האוטומטי.
מישור הבקרה ו-Kubernetes API
מישור הבקרה הוא נקודת הקצה המאוחדת של האשכול. האינטראקציה עם רמת הבקרה מתבצעת באמצעות קריאות ל-Kubernetes API. מישור הבקרה מריץ את תהליך שרת ה-API של Kubernetes (kube-apiserver) כדי לטפל בבקשות API. אפשר לשלוח קריאות ל-Kubernetes API בדרכים הבאות:
- שיחות ישירות: HTTP/gRPC
- קריאות עקיפות: לקוחות של שורת הפקודה של Kubernetes, כמו
kubectl, או מסוףGoogle Cloud .
תהליך שרת ה-API הוא מרכז התקשורת של האשכול. כל הרכיבים הפנימיים של האשכול, כמו צמתים, תהליכי מערכת ובקרי אפליקציות, פועלים כלקוחות של שרת ה-API.
בקשות ה-API שלכם מציינות ל-Kubernetes מה המצב הרצוי של האובייקטים באשכול. מערכת Kubernetes מנסה לשמור על המצב הזה כל הזמן. ב-Kubernetes אפשר להגדיר אובייקטים ב-API בשיטה אימפרטיבית או דקלרטיבית.
מידע נוסף על ניהול אובייקטים ב-Kubernetes זמין בדפים הבאים:
מישור הבקרה ומסד הנתונים של מצב האשכול
פרויקט הקוד הפתוח Kubernetes משתמש ב-etcd כמאגר הנתונים לאחסון של כל נתוני האשכול כברירת מחדל. מצב האשכול נשמר במאגר מפתח/ערך שמכיל מידע על המצב של כל אובייקט Kubernetes API באשכול. לדוגמה, מסד הנתונים של מצב האשכול מאחסן כל סוד, ConfigMap ופריסה.
אשכולות GKE מאחסנים את מצב האשכול באחד ממאגרי המידע הבאים של זוגות מפתח/ערך:
- etcd: GKE מאחסן את מצב האשכול במכונות וירטואליות (VM) של מישורי בקרה שפועלות בכל מכונה וירטואלית של מישור הבקרה.
- Spanner: GKE מאחסן את מצב האשכול ב-Spanner. מסד הנתונים של Spanner לא פועל במישור הבקרה של האשכול.
לא משנה איזה סוג מסד נתונים, כל אשכול GKE משרת את etcd API במישור הבקרה. שרת ה-API של Kubernetes משתמש ב-etcd API כדי לתקשר עם מסד הנתונים של מצב אשכול ה-backend.
אינטראקציה בין מישור הבקרה לצומת
מישור הבקרה מנהל את מה שמופעל בכל הצמתים של האשכול. מישור הבקרה מתזמן עומסי עבודה ומנהל את מחזור החיים, ההרחבה והשדרוגים של עומסי העבודה. מישור הבקרה גם מנהל את משאבי הרשת והאחסון של עומסי העבודה האלה. רמת הבקרה והצמתים מתקשרים זה עם זה באמצעות ממשקי Kubernetes API.
אינטראקציות של מישור הבקרה עם Artifact Registry
כשיוצרים או מעדכנים אשכול, GKE מושך תמונות של קונטיינרים של תוכנת מערכת Kubernetes שפועלת במישור הבקרה ובצמתים ממאגרי Artifact Registry בדומיין pkg.dev או בדומיין gcr.io. הפסקה זמנית בשירות
שמשפיעה על המאגרים האלה עלולה לגרום לכשל בפעולות הבאות:
- יצירת אשכול חדש
- שדרוגים של גרסאות אשכולות
יכול להיות שיהיו שיבושים בעומסי העבודה גם בלי התערבות שלכם, בהתאם לאופי הספציפי של ההפסקה הזמנית בשירות ולמשך שלה.
אם ההשבתה של מאגר Artifact Registry היא אזורית, יכול להיות שנפנה בקשות לאזור או לאזור שאינם מושפעים מההשבתה.
כדי לבדוק את הסטטוס של שירותי Google Cloud , עוברים אל Google Cloud לוח הבקרה של הסטטוס.
פריסה בכמה אזורים כדי לאפשר זמינות של אפליקציות במהלך הפסקות חשמל באזור.
מידע על הצמתים
צמתים הם מכונות עבודה שמריצות את האפליקציות בקונטיינרים ועומסי עבודה אחרים. המכונות הפרטיות הן מכונות וירטואליות (VM) של Compute Engine שנוצרות על ידי GKE. מישור הבקרה מנהל את הסטטוס שכל צומת מדווח על עצמו ומקבל עדכונים לגביו.
בצומת מופעלים השירותים שנדרשים לתמיכה בקונטיינרים שמרכיבים את עומסי העבודה של האשכול. הם כוללים את זמן הריצה ואת סוכן הצומת של Kubernetes (kubelet), שמתקשר עם מישור הבקרה ואחראי על הפעלה והרצה של קונטיינרים שמתוזמנים בצומת.
ב-GKE פועלות גם כמה תוכנות קונטיינר של המערכת שפועלות כסוכנים לכל צומת, שנקראים DaemonSets, ומספקות פונקציונליות כמו איסוף יומנים וקישוריות רשת בתוך האשכול.
מומלץ להשתמש ב-stdout לאפליקציות בקונטיינרים, כי stdout מאפשר לפלטפורמה לטפל ביומני האפליקציות.
ניהול הצמתים משתנה בהתאם למצב הפעולה של האשכול, באופן הבא:
| רכיב הצומת | מצב טייס אוטומטי | מצב רגיל |
|---|---|---|
| מחזור חיים | מנוהל באופן מלא על ידי GKE, כולל:
|
GKE מנהל את הדברים הבאים:
אפשר לנהל את ההגדרות הבאות:
|
| הרשאות גישה | צפייה בצמתים באמצעות kubectl. מכונות וירטואליות בסיסיות של Compute Engine שלא ניתן לראות או לגשת אליהן ב-CLI של gcloud או במסוף Google Cloud . |
אפשר להציג את הצמתים באמצעות kubectl, ה-CLI של gcloud ומסוף Google Cloud . הצגה וגישה למכונות וירטואליות ב-Compute Engine. |
| קישוריות | אין חיבור ישיר למכונות ה-VM הבסיסיות. | מתחברים למכונות הווירטואליות הבסיסיות באמצעות SSH. |
| מערכת ההפעלה (OS) של הצומת | מנוהל על ידי GKE. כל הצמתים משתמשים ב-מערכת הפעלה שמותאמת לקונטיינרים עם containerd (cos_containerd). |
בוחרים מערכת הפעלה לצמתים. |
| בחירת חומרת המכונה | בקשה compute classes ב-Pods על סמך תרחיש לדוגמה. GKE מנהל את הגדרת המכונה, התזמון, הכמות ומחזור החיים. |
בוחרים ומגדירים סוגי מכונות של Compute Engine כשיוצרים מאגרי צמתים. מגדירים את הגודל, ההתאמה, הכמות, התזמון והמיקום לפי הצורך. |
המאמרים הבאים
- מידע נוסף על GKE Autopilot
- מידע נוסף על אשכולות אזוריים
- מידע נוסף על GKE
- איך יוצרים אשכול אזורי
- מידע נוסף על מאגרי צמתים