בדף הזה מתוארת הארכיטקטורה של אשכולות Google Kubernetes Engine (GKE) שמריצים את עומסי העבודה בקונטיינרים. בדף הזה מוסבר על מישור הבקרה, על הצמתים ועל האינטראקציה בין הרכיבים השונים של אשכול GKE.
הדף הזה מיועד לאדמינים, לאדריכלים ולמפעילים שמגדירים פתרונות IT וארכיטקטורת מערכות. מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם ב Google Cloud תוכן זמין במאמר תפקידים נפוצים של משתמשים ומשימות ב-GKE.
לפני שקוראים את הדף הזה, חשוב להכיר את הארכיטקטורה של אשכול Kubernetes.
אשכול GKE מורכב ממישור בקרה וממכונות עבודה שנקראות צמתים. מישור הבקרה והצמתים מרכיבים את מערכת תזמור האשכולות של Kubernetes. ב-GKE Autopilot, כל התשתית הבסיסית של האשכולות מנוהלת, כולל מישור הבקרה, הצמתים וכל רכיבי המערכת.
אם אתם משתמשים במצב GKE Standard, GKE מנהל את מישור הבקרה ואת רכיבי המערכת, ואתם מנהלים את הצמתים.
התרשים הבא מציג את הארכיטקטורה של אשכול GKE:
בתרשים הזה מוצגים הרכיבים הבאים:
- מישור הבקרה: מנוהל על ידי GKE. מריץ את שרת ה-API של Kubernetes, את בקרי עומסי העבודה, את מתזמן Kubernetes ואת אחסון מצב האשכול.
- צמתים: מנוהלים על ידי GKE במצב Autopilot, ומנוהלים על ידי לקוחות במצב רגיל. כל ה-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 כשיוצרים מאגרי צמתים. מגדירים את ההגדרות של הגודל, ההתאמה, הכמות, התזמון והמיקום לפי הצורך. |
רישום הצומת ב-Kubernetes API
כשיוצרים צומת באשכול GKE, התהליך kubelet בצומת הזה יוצר חיבור TLS עם שרת ה-API של Kubernetes. במהלך האתחול של הצומת, ה-kubelet יוצר CertificateSigningRequest כדי לבקש אישור לקוח ייחודי משרת ה-API. kubelet משתמש באישור כדי ליצור אובייקט Node ב-Kubernetes API.
תכונה של GKE בשם Shielded GKE Nodes (צמתי GKE מוגנים), שמופעלת כברירת מחדל בכל האשכולות החדשים, משפרת את האבטחה של תהליך הרישום העצמי של הצומת באמצעות מודול פלטפורמה וירטואלי מהימן (vTPM) בצומת, כדי לאמת את זהות הצומת באמצעות הצפנה. האימות הזה מוודא שממשק השליטה מנפיק אישורים רק לצמתים לגיטימיים.
אפשר גם לדרוש מרכיב מהימן של מישור הבקרה ב-GKE ליצור את האובייקטים האלה של Node במקום kubelet, וכך לצמצם את ההשפעה הפוטנציאלית אם צומת ייפרץ. מידע נוסף זמין במאמר בנושא יצירה של צומת במישור הבקרה (גרסת Preview).
המאמרים הבאים
- מידע נוסף על GKE Autopilot
- מידע נוסף על אשכולות אזוריים
- מידע נוסף על GKE
- איך יוצרים אשכול אזורי
- מידע נוסף על מאגרי צמתים