ארכיטקטורת אשכול GKE

בדף הזה מתוארת הארכיטקטורה של אשכולות 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

מישור הבקרה הוא נקודת הקצה המאוחדת של האשכול. אתם יכולים ליצור אינטראקציה עם מישור הבקרה באמצעות קריאות ל-API של Kubernetes. מישור הבקרה מריץ את תהליך שרת ה-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 באשכול. לדוגמה, מסד הנתונים של מצב האשכול מאחסן כל Secret,‏ ConfigMap ו-Deployment.

אשכולות GKE מאחסנים את מצב האשכול באחד ממאגרי המפתח/ערך הבאים:

  • ‫etcd: ‏GKE שומר את מצב האשכול במכונות etcd שפועלות בכל מכונה וירטואלית (VM) של מישור הבקרה.
  • ‫Spanner: ‏GKE מאחסן את מצב האשכול ב-Spanner. מסד הנתונים של Spanner לא פועל במישור הבקרה של האשכול.

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

אינטראקציה בין מישור הבקרה לצומת

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

אינטראקציות של מישור הבקרה עם Artifact Registry

כשיוצרים או מעדכנים אשכול, GKE שולף קובצי אימג' של קונטיינרים בשביל תוכנת המערכת של Kubernetes שפועלת במישור הבקרה ובצמתים ממאגרי Artifact Registry בדומיין pkg.dev או gcr.io. הפסקה בשירות שמשפיעה על מאגרי הנתונים האלה עלולה לגרום לפעולות הבאות להיכשל:

  • יצירת אשכול חדש
  • שדרוגי גרסאות של אשכולות

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

אם ההפסקה בפעילות של מאגר Artifact Registry היא אזורית, יכול להיות שנפנה את הבקשות לאזור שלא מושפע מההפסקה.

כדי לבדוק את הסטטוס של שירותי Google Cloud , נכנסים ללוח הבקרה של סטטוס שירותי GoogleGoogle 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 ולגשת אליהן.
קישוריות אין חיבור ישיר למכונות הווירטואליות הבסיסיות. להתחבר למכונות הווירטואליות הבסיסיות באמצעות SSH.
מערכת ההפעלה (OS) של הצומת מנוהל על ידי GKE. כל הצמתים משתמשים במערכת הפעלה שמותאמת לקונטיינרים עם containerd‏ (cos_containerd). בחירת מערכת הפעלה לצמתים.
בחירת חומרה למכונה

מבקשים מחלקות מחשוב ב-Pods בהתאם לתרחיש לדוגמה.

‫GKE מנהל את הגדרת המכונה, התזמון, הכמות ומחזור החיים.

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

רישום צומת באמצעות Kubernetes API

כשנוצר צומת באשכול GKE, התהליך kubelet באותו צומת יוצר חיבור TLS עם שרת ה-API של Kubernetes. במהלך האתחול של הצומת, ה-kubelet יוצר CertificateSigningRequest כדי לבקש אישור לקוח ייחודי משרת ה-API. ה-kubelet משתמש באישור כדי ליצור אובייקט Node ב-Kubernetes API.

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

כדי לצמצם את ההשפעה הפוטנציאלית במקרה שצומת נפגע, אתם יכולים לדרוש שרכיב מהימן של מישור הבקרה של GKE ייצור את האובייקטים האלה של Node במקום kubelet. מידע נוסף זמין במאמר יצירת צומת של מישור הבקרה (גרסת טרום-השקה (Preview)).

המאמרים הבאים