מידע על אפשרויות ההגדרה של אשכולים

בדף הזה מוסבר על אפשרויות ההגדרה העיקריות של אשכולות שזמינות כשיוצרים אשכול ב-Google Kubernetes Engine‏ (GKE), בין אם משתמשים במסוףGoogle Cloud , ב-Google Cloud CLI או ב-Terraform. האפשרויות האלה מאפשרות לכם להתאים אישית מגוון רחב של מאפיינים והתנהגויות של האשכול, כדי שיתאימו לצרכים שלכם. למשל, האם האשכול נגיש מרשתות ציבוריות ואיך אתם רוצים שהוא יקבל שדרוגי גרסה.

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

שיטה מומלצת:

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

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

לפני שקוראים את הדף הזה, כדאי להכיר את הנושאים הבאים, וגם את המושגים הבסיסיים של Kubernetes:

רמת ניהול האשכול

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

כשיוצרים אשכול ב-GKE, אפשר לעשות זאת באמצעות אחד ממצבי הפעולה הבאים:

  • ‫Autopilot (מומלץ): מספק הגדרת אשכולות עם הקצאת משאבים וניהול מלאים. אשכולות Autopilot מוגדרים מראש עם תצורת אשכול אופטימלית שמוכנה לעומסי עבודה (workloads) בסביבת ייצור.

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

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

אפשר למצוא השוואה בטבלה מפורטת בין שני המצבים במאמר השוואה בין GKE Standard לבין Autopilot.

אפשרויות להגדרת אשכולים

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

אפשרויות ההגדרה לכל האשכולות מחולקות לקטגוריות הבאות:

  • שם ומטא-נתונים אחרים: לכל אשכול צריך להיות שם ייחודי שמזהה אותו בפרויקט. אפשר גם להוסיף תיאור ותוויות לאשכול.
  • זמינות ומדרגיות: מציינים איפה רוצים שמישור הבקרה והצמתים של האשכול יפעלו, ואם רוצים כמה רפליקות של מישור הבקרה. כל אשכולות Autopilot הם אזוריים, כלומר יש להם כמה מישורי בקרה בכמה אזורי מחשוב באזור Google Cloud.
  • חברות ב-Fleet: בוחרים אם רוצים שהאשכול יהיה חבר ב-Fleet.
  • רשת: אפשרויות רשת, כולל רשת הענן הווירטואלי הפרטי (VPC) ורשת המשנה שבה נמצא האשכול, והאם רוצים שהאשכול יהיה נגיש מרשתות ציבוריות.
  • ניהול גרסאות ושדרוגים: אפשר להשתמש בערוצי הפצה כדי לבחור את האיזון המועדף בין תכונות חדשות ליציבות כשמשדרגים את התוכנה של האשכול הזה, ולהגדיר חלונות זמן לתחזוקה והחרגות כדי לבחור מתי אפשר לבצע שדרוגים ומתי אי אפשר.
  • אבטחה: כולל מידע על השימוש באיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE ועל חשבון השירות שבו משתמשים הצמתים של האשכול כדי לבצע אימות ב-Google Cloud.
  • תכונות של אשכול: הפעלה והגדרה של תכונות נוספות של GKE ו-Google Cloud באשכול הזה, כולל גיבויים ויכולת צפייה. במצב רגיל אפשר גם ליצור אשכולות אלפא לטווח קצר כדי לנסות תכונות אלפא של Kubernetes.

בנוסף לאפשרויות האלה, באשכולות רגילים יש גם אפשרויות בקטגוריה הבאה:

  • מאגרי צמתים: מציינים פרטים על הצמתים של האשכול, כולל מאגרי צמתים, מערכת הפעלה של הצמתים וגודל הצמתים.

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

בטבלה הבאה מוצגת השוואה בין האפשרויות הזמינות בתחומים מרכזיים מסוימים באשכולות במצב Autopilot ובאשכולות רגילים:

אפשרויות לאשכולות מצב
טייס אוטומטי רגילה
סוג הזמינות אזורי אזורי או Zonal
ערוץ הפצה מהירה, רגילה או יציבה כל ערוץ
גרסאות של אשכולות ברירת מחדל או גרסה זמינה אחרת ברירת מחדל או גרסה זמינה אחרת
ניתוב ברשת VPC-native ‫VPC-native או Routes-based
בידוד רשת ניתן להתאמה אישית ניתן להתאמה אישית
תכונות של Kubernetes Production Production או Alpha

זמינות של אשכולות

בעזרת GKE, אתם יכולים ליצור אשכול שמותאם לדרישות הזמינות של עומס העבודה ולתקציב שלכם. אתם יכולים לבחור בין אשכולות אזוריים עם כמה עותקים של מישור הבקרה בכמה אזורי מחשוב ב Google Cloud אזור, או אשכולות אזוריים עם מישור בקרה יחיד באזור יחיד. אשכולות Autopilot הם תמיד אזוריים.

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

אי אפשר לעדכן את ההגדרות האלה אחרי שיוצרים את האשכול: אשכול אזורי לא יכול להפוך לאשכול אזורי, ואשכול אזורי לא יכול להפוך לאשכול אזורי.

שיטה מומלצת:

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

אשכולות אזוריים

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

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

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

אי אפשר לשנות את האזור של אשכול אזורי אחרי שיוצרים את האשכול.

אשכולות אזוריים

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

כדי ליצור אשכול אזורי, ראו יצירת אשכול אזורי.

המיקום וההתפלגות של הצמתים

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

אשכולות של אזור יחיד

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

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

אשכולות מרובי אזורים

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

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

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

אזורי AI

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

לפני שמשתמשים באזור AI ב-GKE, כדאי להביא בחשבון את המאפיינים הבאים:

  • אזורי ה-AI נפרדים פיזית מאזורים רגילים כדי לספק נפח אחסון נוסף וחשמל. ההפרדה הזו עשויה להוביל לזמן אחזור ארוך יותר, שבדרך כלל נסבל בעומסי עבודה של AI/ML.
  • לאזורי AI יש סיומת עם הסימון ai. לדוגמה, אזור AI באזור us-central1 נקרא us-central1-ai1a.
  • בשלב הזה יש תמיכה רק במכונות וירטואליות של TPU.
  • מישור הבקרה של האשכול פועל באזור רגיל אחד או יותר באותו אזור כמו אזור ה-AI.

  • אפשר להריץ מכונות וירטואליות בלי יחידות TPU מצורפות באזור AI רק אם מתקיימות הדרישות הבאות:

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

  • אזורי AI חולקים רכיבים, כמו חיבורי רשת ופריסות תוכנה, עם אזורים רגילים שיש להם את אותו סיומת באותו אזור. לסביבות עבודה עם זמינות גבוהה, מומלץ להשתמש באזורים שונים. לדוגמה, לא מומלץ להשתמש גם ב-us-central1-ai1a וגם ב-us-central1-a כדי להשיג זמינות גבוהה.

כברירת מחדל, GKE לא פורס את עומסי העבודה שלכם באזורי AI. כדי להשתמש באזור AI, צריך להגדיר אחת מהאפשרויות הבאות:

  • ‫(מומלץ) ComputeClasses: מגדירים את העדיפות הכי גבוהה לבקשה של TPU לפי דרישה באזור AI. בעזרת ComputeClasses אפשר להגדיר רשימה מתועדפת של תצורות חומרה לעומסי העבודה. דוגמה מופיעה במאמר מידע על ComputeClasses.
  • Node auto-provisioning: use a nodeSelector or nodeAffinity in your Pod specification to instruct node auto-provisioning to create a node pool in the AI zone. אם עומס העבודה שלכם לא מכוון באופן מפורש לאזור AI, הקצאת משאבים אוטומטית של צמתים תתייחס רק לאזורים רגילים או לאזורים מ---autoprovisioning-locations כשיוצרים מאגרי צמתים חדשים. ההגדרה הזו מבטיחה שעומסי עבודה שלא מריצים מודלים של AI/ML יישארו באזורים רגילים, אלא אם תגדירו אחרת באופן מפורש. דוגמה למניפסט שמשתמש ב-nodeSelector מופיעה במאמר הגדרת אזורי ברירת המחדל לצמתים שנוצרו באופן אוטומטי.
  • ‫GKE Standard: אם אתם מנהלים ישירות את מאגרי הצמתים, השתמשו באזור AI בדגל --node-locations כשאתם יוצרים מאגר צמתים. לדוגמה, אפשר לעיין במאמר פריסת עומסי עבודה של TPU ב-GKE Standard.

חברות במועדון ה-Fleet

אם הארגון שלכם משתמש בכמה אשכולות, תוכלו לפשט את הניהול של כמה אשכולות על ידי הוספת האשכולות לצי: קיבוץ לוגי של אשכולות Kubernetes. יצירת צי מאפשרת לארגון לשדרג את הניהול מאשכולות בודדים לקבוצות שלמות של אשכולות, ומאפשרת להשתמש בתכונות שמופעלות בצי, כמו Multi Cluster Ingress, ‏ סנכרון תצורות ו- Policy Controller.

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

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

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

הגדרות רשת

כשיוצרים אשכול GKE, אפשר לציין מספר הגדרות רשת, כולל הרשת שבה האשכול נמצא, מצב ניתוב הרשת והאם רוצים שהגישה לצמתי האשכול תהיה אפשרית מרשתות ציבוריות.

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

רשת ורשת משנה

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

אי אפשר לעדכן את ההגדרות האלה אחרי שיוצרים את האשכול.

אפשרויות לבידוד רשת

כדי להתאים אישית את בידוד הרשת באשכול, צריך להתייחס לשני ההיבטים הבאים:

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

    • משביתים את נקודת הקצה החיצונית ואת נקודת הקצה הפנימית ומשתמשים רק בנקודת הקצה של DNS.
    • משביתים את נקודת הקצה החיצונית רק כדי למנוע גישה ללקוחות חיצוניים.
    • הפעלת רשתות מורשות כדי לקבוע אילו כתובות IP יכולות להגיע לנקודות הקצה של מישור הבקרה.

  • הגדרת רשת של אשכול: אתם יכולים להפעיל צמתים פרטיים באשכול כדי לבודד לחלוטין את עומסי העבודה מרשתות ציבוריות. אפשר להפעיל צמתים פרטיים עבור אשכולות שלמים או ברמת מאגר הצמתים (ב-Standard) או ברמת עומס העבודה (ב-Autopilot). הפעלת צמתים פרטיים ברמת מאגר הצמתים או ברמת עומס העבודה מבטלת כל הגדרה של צמתים ברמת האשכול.

אפשר לשנות את ההגדרות האלה אחרי שיוצרים את האשכול.

מידע נוסף על בידוד רשת זמין במאמרים מידע על התאמה אישית של בידוד רשת והתאמה אישית של בידוד רשת.

שיטה מומלצת:

משתמשים ב-Cloud NAT כדי לספק ל-Pods של GKE גישה למשאבים עם כתובות IP ציבוריות. ‫Cloud NAT משפר את מצב האבטחה הכולל של האשכול, כי הפודים לא חשופים ישירות לאינטרנט, אבל עדיין יכולים לגשת למשאבים שפונים לאינטרנט.

אשכולות המותאמים ל-VPC ואשכולות מבוססי-נתיבים

ב-GKE, אפשר להבחין בין אשכולות לפי האופן שבו הם מנתבים תנועה מ-Pod אחד ל-Pod אחר. אשכול שמשתמש בכתובות IP של כינוי נקרא אשכול המותאם ל-VPC. אשכול שמשתמש ב Google Cloud נתיבים נקרא אשכול מבוסס-נתיבים.

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

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

שיטה מומלצת:

משתמשים במצב הרשת המותאם ל-VPC באשכולות. זוהי ברירת המחדל עבור אשכולות Autopilot.

גרסאות ושדרוגים

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

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

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

אפשר לשנות את ערוץ ההפצה של אשכול בכל שלב.

מידע על שדרוגים אוטומטיים עתידיים זמין ב הערות הגרסה של GKE.

שיטה מומלצת:

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

תכונות בגרסת אלפא (רק באשכולות רגילים)

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

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

תכונות אלפא לא זמינות באשכולות של Autopilot.

במאמר יצירת אשכול אלפא מוסבר איך ליצור אשכול אלפא.

הגדרות אבטחה

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

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

חשבון שירות לצמתים

‫GKE משתמש בחשבונות שירות של IAM שמצורפים לצמתים כדי להריץ משימות מערכת כמו רישום ביומן ומעקב. לפחות, חשבונות השירות של הצמתים צריכים לקבל את התפקיד Kubernetes Engine Default Node Service Account ‏(roles/container.defaultNodeServiceAccount) בפרויקט. כברירת מחדל, GKE משתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, שנוצר באופן אוטומטי בפרויקט, כחשבון השירות של הצומת.

אם בארגון שלכם נאכף iam.automaticIamGrantsForDefaultServiceAccounts אילוץ מדיניות הארגון, יכול להיות שלחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine בפרויקט שלכם לא יוקצו באופן אוטומטי ההרשאות הנדרשות ל-GKE.

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

אי אפשר לשנות את חשבון השירות של אשכולות במצב Autopilot או של מאגרי צמתים במצב Standard אחרי שהם נוצרים.

הגדרות של מאגר צמתים (בקטרי סטנדרט בלבד)

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

אם בוחרים ליצור אשכול רגיל, אפשר לציין מספר אפשרויות של צמתים כשיוצרים אשכול, כולל:

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

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

הסבר על ההגדרות

רשימה מלאה של אפשרויות ההגדרה האפשריות מופיעה במדריכי העיון הבאים:

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