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

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

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

שיטה מומלצת:

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

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

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

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

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

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

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

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

מידע נוסף על המצבים האלה ועל 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 הם תמיד אזוריים.

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

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

שיטה מומלצת:

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

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

לאשכול אזורי יש כמה עותקים של מישור הבקרה, שפועלים בכמה אזורים ב 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 באותו אזור.
    • המכונות הווירטואליות שאינן TPU הן מכונות וירטואליות מסוג Spot, מכונות שמשוריינות להזמנה או מכונות שמשויכות למאגר צמתים עם יחס ספציפי בין מאיץ ל-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.

המשתמשים בפלח

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

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

אחרי שיוצרים את האשכול, אפשר לעדכן את ההגדרה הזו כדי לרשום את האשכול או לבטל את הרישום שלו. עם זאת, אנחנו לא ממליצים להעביר אשכולות עם עומסי עבודה פעילים מ-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, אפשר להבחין בין אשכולות לפי האופן שבו הם מנתבים תנועה מפוד אחד לפוד אחר. אשכול שמשתמש בכתובות 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 (לפעמים נקראים feature gates). אתם יכולים להשתמש באשכולות אלפא כדי לבדוק ולאמת תכונות של 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 צריך, וזה עלול לחשוף אתכם לסיכוני אבטחה.

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

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

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

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

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

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

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

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

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

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