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

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

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

שיטה מומלצת:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שיטה מומלצת:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אזורי AI

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

במסמך הזה ובמסמכי התיעוד של GKE, המונחים 'אזורים רגילים' או 'אזורים' מתייחסים לאזורים שאינם אזורי AI בתוך Cloud de Confiance by S3NS אזור.

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

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

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

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

  • אזורי 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.

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

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

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

הגדרות רשת

כשיוצרים אשכול 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. אשכול שמשתמש ב Cloud de Confiance by S3NS נתיבים נקרא אשכול מבוסס-נתיבים.

כברירת מחדל, כל אשכולות 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 או של מאגרי צמתים במצב רגיל אחרי שהם נוצרו.

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

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

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

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

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

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

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

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