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

בדף הזה מובאת סקירה כללית על אשכולות מקוריים של VPC ב-Google Kubernetes Engine ‏ (GKE).

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

סקירה כללית

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

קלאסטר שמשתמש בטווחי כתובות IP של כינויים נקרא אשכול המותאם ל-VPC. אשכול שמשתמש בנתיבים סטטיים בהתאמה אישית ברשת VPC נקרא אשכול מבוסס-נתיבים.

שיטה מומלצת:

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

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

לאשכולות שמותאמים ל-VPC יש כמה יתרונות:

  • אפשר להגדיר ניתוב של כתובות ה-IP של הפודים באופן מקורי ברשת ה-VPC של האשכול וברשתות VPC אחרות שמקושרות אליה באמצעות קישור בין רשתות VPC שכנות (peering).

  • כתובות ה-IP של ה-Pods שמורות ברשת ה-VPC לפני שה-Pods נוצרים באשכול. כך נמנעים עימותים עם משאבים אחרים ברשת ה-VPC, ואפשר לתכנן טוב יותר את הקצאות כתובות ה-IP.

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

  • אתם יכולים ליצור כללי חומת אש שחלים רק על טווחי כתובות ה-IP של ה-Pod, במקום על כל כתובת IP בצמתים של האשכול.

  • אפשר לגשת לטווחי כתובות ה-IP של הפודים ולטווחי כתובות ה-IP המשניים של רשתות המשנה באופן כללי מרשתות מקומיות שמחוברות ל-Cloud VPN או ל-Cloud Interconnect באמצעות Cloud Routers.

  • חלק מהתכונות, כמו קבוצות של נקודות קצה ברשת (NEGs), פועלות רק עם אשכולות מקוריים של VPC.

מצב רשת ברירת המחדל של האשכול

ההגדרה 'מותאם ל-VPC' היא מצב הרשת שמוגדר כברירת מחדל לכל האשכולות בגרסאות GKE‏ 1.21.0-gke.1500 ואילך. בגרסאות קודמות, מצב הרשת של האשכול שמוגדר כברירת מחדל תלוי באופן שבו יוצרים את האשכול.

בטבלה הבאה מפורט מצב הרשת של האשכול שמוגדר כברירת מחדל לגרסאות של אשכולות GKE ולשיטות ליצירת אשכולות.

גרסאות GKE שיטת יצירת האשכול מצב הרשת של האשכול
כל הגרסאות מסוף Google Cloud מותאם ל-VPC
‫1.21.0-gke.1500 ואילך ‫GKE API או Google Cloud CLI מותאם ל-VPC

אפשר גם ליצור אשכול מבוסס-נתיבים על ידי ציון הדגל --no-enable-ip-alias כשיוצרים את האשכול.

טווחים של כתובות IP לאשכולות המותאמים ל-VPC

כשיוצרים אשכול המותאם ל-VPC, מציינים רשת משנה ברשת VPC. האשכול משתמש בטווחים הבאים של כתובות IP של רשתות משנה:

הקצאת כתובות IPv4

באשכולות המותאמים ל-VPC, כתובות IPv4 מוקצות לצמתים, ל-Pods ולשירותים באופן הבא.

  • כתובות IPv4 של הצמתים: האשכול משתמש בטווח הכתובות הראשי של רשת המשנה מסוג IPv4 כדי להקצות כתובות IP לכל הצמתים.

  • כתובות IPv4 של Pod: האשכול משתמש בטווח אחד או יותר של כתובות IPv4 משניות של רשתות משנה לכל כתובות ה-IPv4 של ה-Pod. בדף הזה מתמקדים בשימוש בטווח כתובות IPv4 משני של רשת משנה אחת. מידע על שימוש בכמה טווחים זמין במאמר הוספת טווחי כתובות IPv4 של Pod.

  • כתובות IPv4 של שירותים: יש שתי אפשרויות:

    • כתובות IPv4 של שירותים מ-34.118.224.0/20: אשכולות GKE Autopilot שמריצים גרסה 1.27 ואילך ואשכולות GKE Standard שמריצים גרסה 1.29 ואילך משתמשים בטווח כתובות ה-IPv4 של שירותים.Google Cloud משתמשים בטווח הכתובות לצרכים פרטיים ולא מפרסמים מסלולים באינטרנט הציבורי לטווח הזה.34.118.224.0/2034.118.224.0/20 אי אפשר להשתמש בטווח הזה לכתובות IPv4 חיצוניות של המשאבים.

    • כתובות IPv4 של שירותים מטווח כתובות IPv4 משני של רשת משנה: לכל הכתובות של השירות (ClusterIP), האשכול משתמש בטווח כתובות IPv4 משני של רשת משנה, ששונה מהטווחים שבהם משתמשים הפודים.

הקצאת כתובות IPv6 (רשת עם תמיכה כפולה ב-IPv4 וב-IPv6)

  • כתובות IPv6 של צמתים ו-Pods: באשכולות שמופעלת בהם רשת דו-ערכית, כתובת ה-IPv6 של הצומת וכל כתובות ה-IPv6 של ה-Pods מקורן בטווח כתובות ה-IPv6 המיועד של הצומת /96. כתובת ה-IP של הצומת עצמה היא הראשונה /128 (כתובת IPv6 יחידה) בטווח הזה. מידע נוסף זמין במאמר בנושא רשתות עם פרוטוקול כפול.

  • כתובות IPv6 של שירותים: באשכולות GKE נעשה שימוש ב2600:2D00:0:4::0:0/64טווח כתובות IPv6 לשירותים Google Cloud.נעשה שימוש ב2600:2D00:0:4::0:0/64טווח הכתובות למטרות פרטיות, ולא מתפרסמים נתיבים באינטרנט הציבורי לטווח הזה. אי אפשר להשתמש בטווח הזה לכתובות IPv6 חיצוניות של המשאבים.

בטבלה הבאה מופיע סיכום של טווחי כתובות ה-IP לצמתים, ל-Pods ולשירותים:

טווח הסבר דוגמה
צמתים

כתובות ה-IP של הצמתים מוקצות מתוך טווח כתובות ה-IP הראשי של רשת המשנה שמשויכת לאשכול.

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

אם אתם מתכננים ליצור אשכול עם 900 צמתים, טווח כתובות ה-IP הראשי של רשת המשנה של האשכול צריך להיות לפחות /22 (2(32-22) = 210 = 1,024 כתובות). מתוך 1,024 הכתובות האלה, אפשר להשתמש ב-1,020 כי ארבע כתובות IP שמורות בכל טווח כתובות IP ראשי.

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

קבוצת Pod

כתובות ה-IP של ה-Pod נלקחות מטווח כתובות ה-IP המשני של תת-הרשת של האשכול עבור ה-Pods. אלא אם מגדירים מספר מקסימלי שונה של Pods לכל צומת, מערכת GKE מקצה /24 טווח כתובות IP של כינוי (256 כתובות) לכל צומת עבור ה-Pods שפועלים בו. בכל צומת, 256 כתובות ה-IP החלופיות האלה משמשות לתמיכה בעד 110 פודים.

לצורך אשכול עם 900 צמתים שתומך בעד 110 פודים לכל צומת, צריך 900 × 256 = 230,400 כתובות IP לפודים. (לכל צומת מוקצה טווח כתובות IP של כינוי שגודל מסכת הרשת שלו הוא ‎ /24). בקטע הזה נדרשת תת-רשת עם טווח כתובות IP משני עבור Pods, ומסכה של רשת משנה שלא גדולה מ-‎ /14. טווח כתובות ה-IP המשני מספק 2(32-14) = 218 = 262,144 כתובות IP ל-Pods.

מידע נוסף זמין במאמר בנושא טווח כתובות IP משני של רשת משנה עבור Pods.

שירותים

כתובות של שירותים (IP של אשכול) נלקחות מטווח כתובות ה-IP המשני של תת-הרשת של האשכול לשירותים. צריך לוודא שהטווח הזה גדול מספיק כדי לספק כתובות לכל שירותי Kubernetes שמתארחים באשכול.

באשכולות GKE Autopilot שפועלת בהם גרסה 1.27 ואילך, ובאשכולות GKE Standard שפועלת בהם גרסה 1.29 ואילך, כתובות ה-IP לשירותי GKE מוקצות על ידי GKE מטווח שמנוהל על ידי GKE: ‏ 34.118.224.0/20 כברירת מחדל. כך לא תצטרכו לציין טווח כתובות IP משלכם לשירותים. לפרטים נוספים, אפשר לעיין במאמר בנושא טווח כתובות IP משני של רשת משנה לשירותים.

בשביל אשכול שמריץ עד 3,000 שירותים, צריך 3,000 כתובות IP של האשכול. צריך להוסיף טווח גדלים משני של 20 ומעלה. טווח של /20 כתובות IP יניב 2(32-20) = 212 = 4,096 כתובות IP.

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

כתובות IPv4 פנימיות

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

מידע חשוב על שימוש בכתובות פרטיות שאינן כתובות RFC 1918 זמין במאמר שימוש בטווחים של כתובות IPv4 פרטיות שאינן RFC 1918.

מידע חשוב על שימוש בטווחים של כתובות IPv4 ציבוריות לשימוש פרטי זמין במאמר הפעלת טווחים של כתובות IP ציבוריות לשימוש פרטי.

שיטות להקצאת טווח IPv4 משני לתת-רשת

אפשר להקצות טווחי כתובות IP של Pod וטווחי כתובות של שירות (ClusterIP) לאשכול המותאם ל-VPC. אפשר לנהל את טווחי כתובות ה-IP האלה באמצעות GKE או באמצעות ניהול על ידי המשתמש.

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

הקצאה: הקצאה של טווחי כתובות IP מתייחסת לתהליך של הקצאת טווח ספציפי של רשתות משנה לאשכול המותאם ל-VPC. כך נוצר מאגר של כתובות IP שהרכיבים יכולים להשתמש בהן בתוך האשכול, כמו Pods ו-Services.

ניהול: ניהול טווח כתובות ה-IP מתייחס לפעולות CRUD שמתבצעות באופן שוטף (יצירה, עדכון, מחיקה, קריאה) ברמת האשכול, מאגר הצמתים או ה-Pod, שקשורות לטווחים של רשתות המשנה שהוקצו ולהקצאת המשאבים באשכול המותאם ל-VPC.

טווחים משניים שמנוהלים על ידי GKE (ברירת מחדל)

באשכולות GKE Autopilot שפועלת בהם גרסה 1.27 ואילך, ובאשכולות GKE Standard שפועלת בהם גרסה 1.29 ואילך, מערכת GKE מקצה כתובות IP לשירותים מטווח שמנוהל על ידי GKE כברירת מחדל: 34.118.224.0/20. כך לא תצטרכו לציין טווח כתובות IP משלכם לשירותים. צריך להתחשב בשיקולים הבאים:

  • אפשר גם לציין טווחים מותאמים אישית לשירותים באמצעות הדגל --services-ipv4-cidr.
  • אם מציינים רק גודל טווח באמצעות הדגל --services-ipv4-cidr (לדוגמה, /22), GKE עדיין משתמש בטווח שמנוהל על ידי GKE כדי לקבל את טווח המשנה של הכתובות.
  • אם מציינים רק גודל לטווח כתובות ה-IP של ה-Pod, למשל --cluster-ipv4-cidr=/17,‏ GKE בוחר באופן אוטומטי טווח כתובות IP משני זמין מרשת ה-VPC.
  • ‫GKE לא יוצר טווח כתובות IP משניות נפרד לשירותים כשמשתמשים בטווח שמנוהל על ידי GKE.

בניהול המשתמש

כדי לקבל שליטה מלאה בהקצאת כתובות IP, אתם יכולים לנהל באופן ידני את רשתות המשנה של אשכול מקורי של VPC.

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

טווח כתובות ה-IP הקטן ביותר שאפשר ליצור בלי להשתמש בCIDR של כמה אזורי זמינות לא רציפים הוא ‎ /28, אבל הטווח הזה מאפשר ליצור רק צומת אחד עם 8 אזורי זמינות לכל היותר. צריך להשתמש בטווח שגדול מספיק למספר המקסימלי של הצמתים שאתם צריכים.

הטווח המינימלי שניתן לשימוש תלוי גם במספר המקסימלי של יחידות Pod לכל צומת.

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

אם מיציתם את טווח כתובות ה-IP של ה-Pods, אתם צריכים לבצע אחת מהפעולות הבאות:

  • יוצרים אשכול חדש עם טווח כתובות גדול יותר של Pod.
  • צריך ליצור מחדש את מאגרי הצמתים אחרי שמקטינים את --max-pods-per-node של מאגרי הצמתים.
  • מרחיבים את טווח כתובות ה-IP של ה-Pod המשני באמצעות CIDR של כמה Pods לא רציפים.

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

סכמת ההקצאה של כתובות Pod ו-Service ‏ (ClusterIP) שונה מהסכמה שבה נעשה שימוש באשכול מבוסס-ניתוב. במקום לציין CIDR יחיד עבור Pods ו-Services ביחד, צריך לבחור או ליצור שני טווחי כתובות IP משניים ברשת המשנה של האשכול: אחד ל-Pods ואחד ל-Services.

שיקולים לגבי VPC משותף

כשיוצרים אשכול המותאם ל-VPC בסביבת VPC משותף, בעלי פרויקט, עורך או ישות מורשית ב-Identity and Access Management‏ (IAM) עם תפקיד אדמין הרשת בפרויקט המארח של ה-VPC המשותף צריכים ליצור ידנית את רשת המשנה של האשכול ואת טווחי כתובות ה-IP המשניות. לאדמין בפרויקט שירות שיוצר אשכול צריכות להיות לפחות הרשאות ברמת רשת המשנה לרשת המשנה בפרויקט המארח של רשת ה-VPC המשותפת.

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

תכנון טווח כתובות IP

המידע בקטעים הבאים יעזור לכם לחשב את הגדלים של טווחי כתובות ה-IP הראשיות והמשניות של רשת המשנה שבה נעשה שימוש באשכול.

טווח כתובות ה-IPv4 הראשי של רשת המשנה

כשמתכננים את טווח כתובות ה-IPv4 הראשי של רשת משנה של אשכול, כדאי לקחת בחשבון את הנקודות הבאות:

  • לכל רשת משנה חייב להיות טווח כתובות IP ראשי. זהו טווח כתובות ה-IP ש-GKE משתמש בו כדי להקצות כתובות IP למאזני עומסים פנימיים ולצמתים.
  • אי אפשר לצמצם או לשנות את טווח כתובות ה-IP הראשי של רשת משנה אחרי שהיא נוצרה.
  • אחרי שיוצרים רשת משנה, אפשר להרחיב את טווח כתובות ה-IP הראשי שלה, אבל אי אפשר לצמצם אותו. אם מרחיבים רשת משנה שמשמשת אשכול עם רשתות מורשות, צריך להוסיף את טווח כתובות ה-IP המורחב לרשימת הרשתות המורשות של מישור הבקרה. לפני שמרחיבים טווח, חשוב לעיין במגבלות ובהמלצות שבמאמר הרחבת טווח IPv4 ראשי.
  • שתי כתובות ה-IP הראשונות ושתי כתובות ה-IP האחרונות בטווח כתובות ה-IP הראשי שמורות על ידיGoogle Cloud.
  • באשכולות עם Private Service Connect נעשה שימוש בטווח רשת המשנה הראשי כדי להקצות את כתובת ה-IP הפנימית שמוקצית לנקודת הקצה של מישור הבקרה. עם זאת, אפשר לשנות את הקצאת כתובת ה-IP הזו באמצעות הדגל private-endpoint-subnetwork. מידע נוסף זמין במאמר בנושא יצירת אשכול ובחירת טווח כתובות ה-IP של מישור הבקרה.

הטבלה הבאה מראה את המספר המקסימלי של צמתים שאפשר ליצור בהתאם לגודל של טווח כתובות ה-IPv4 הראשי של רשת המשנה ולהגדרת האשכול:

  • תרחיש 1: מספר הצמתים המקסימלי באשכול שמשתמש ברשת המשנה שמוגדרת כברירת מחדל.
  • תרחיש 2: מספר הצמתים המקסימלי באשכול Private Service Connect שלא נעשה בו שימוש בדגל private-endpoint-subnetwork.
טווח כתובות ה-IP הראשי של רשת המשנה תרחיש 1 תרחיש 2
‫‎/29
הגודל המינימלי של טווח כתובות ה-IP הראשי של תת-רשת		 ‫4 צמתים ‫3 צמתים
/28 ‫12 צמתים ‫11 צמתים
/27 ‫28 צמתים ‫27 צמתים
/26 ‫60 צמתים ‫59 צמתים
/25 ‫124 צמתים ‫123 צמתים
/24 ‫252 צמתים ‫251 צמתים
/23 ‫508 צמתים ‫507 צמתים
/22 ‫1,020 צמתים ‫1,019 צמתים
/21 ‫2,044 צמתים ‫2,043 צמתים
‫/20
גודל ברירת המחדל של טווח כתובות ה-IP הראשי של תת-רשת ברשתות במצב אוטומטי		 ‫4,092 צמתים ‫4,091 צמתים
/19 ‫8,188 צמתים ‫8,187 צמתים
‫‎/8
הגודל המקסימלי של טווח כתובות ה-IP הראשי של תת-רשת		 ‫16,777,212 צמתים ‫16,777,211 צמתים

הרחבת טווח כתובות ה-IP הראשי

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

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

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

נוסחאות שימושיות

אפשר להשתמש בנוסחאות הבאות כדי:

  • חישוב המספר המקסימלי של צמתים, N, שניתן לתמוך בהם במסכת רשת נתונה באשכולות שמשתמשים ברשת המשנה שמוגדרת כברירת מחדל. משתמשים ב-S כדי לציין את הגודל של מסכת הרשת. הטווח התקף הוא בין 8 ל-29, כולל.

    ‫N = 2(32 -S) - 4

  • חשבו את הגודל של מסכת הרשת, S, שנדרשת לתמיכה במקסימום של N צמתים:

    ‫S = 32 - ⌈log2(N + 4)⌉

    ‫⌈⌉ היא פונקציית העיגול כלפי מעלה (המספר השלם הקטן ביותר), כלומר עיגול כלפי מעלה למספר השלם הבא. הטווח התקין של גודל מסכת הרשת, S, הוא בין 8 ל-29, כולל.

באשכולות של Private Service Connect שלא נעשה בהם שימוש בדגל private-endpoint-subnetwork, אפשר להשתמש בנוסחאות שלמעלה, אבל צריך להקטין את הערך של N ב-1.

שיקולים לגבי גודל האשכול לטווח כתובות IP משני ל-Pods

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

משתנים מרכזיים

  • ‫Q: המספר המקסימלי של רכיבי Pod לכל צומת.
  • ‫DS: גודל חסימת ה-CIDR שנבחרה עבור תת-הרשת של ה-Pod (לדוגמה, /17).
  • ‫M: גודל מסכת הרשת לטווח ה-Pod של כל צומת.
  • ‫HM: מספר הביטים של המארח עבור מסכת הרשת של טווח ה-Pod של הצומת.
  • ‫HD: מספר הביטים של המארח לחסימת ה-CIDR של רשת המשנה של ה-Pod.
  • ‫MN: המספר המקסימלי של הצמתים שאפשר לתמוך בהם.
  • ‫MP: המספר המקסימלי של Pods שאפשר לתמוך בהם.
  • ‫S: אורך הקידומת של טווח כתובות ה-IP הראשי של רשת המשנה.
  • ‫N: מספר כתובות ה-IP שניתן להשתמש בהן בטווח כתובות ה-IP הראשי של רשת המשנה.

שלבים לחישוב מספר הפודים המקסימלי

  1. קובעים את מספר ה-Pods המקסימלי לכל צומת (Q):

    • באשכולות Autopilot, הערך של Q קבוע על 32.
    • במערכות Standard, אפשר להגדיר Q.

  2. מגדירים את הגודל של חסימת ה-CIDR עבור רשת המשנה של ה-Pod ‏ (DS):

    • קובעים את הגודל של בלוק ה-CIDR שנבחר לרשת המשנה של ה-Pod (לדוגמה, /17).

  3. חישוב הגודל של מסכת הרשת (M):

    M = 31 - ⌈log₂(Q)⌉

    מחליפים את Q בערך של maximum Pods per node. משתמשים בפונקציה ceiling ‏ (⌈ ⌉) כדי לעגל כלפי מעלה למספר השלם הקרוב ביותר.

  4. חישוב הביטים של המארח לטווח ה-Pod ‏ (HM):

    HM = 32 - M

  5. חישוב הביטים של המארח לחסימת ה-CIDR שנבחרה (HD):

    HD = 32 - DS

  6. חישוב מספר הצמתים המקסימלי (MN):

    MN = 2<sup>(HD - HM)</sup>

    התוצאה של החישוב הזה היא המספר המקסימלי של צמתים שרשת המשנה של ה-Pod שנבחר יכולה לתמוך בהם.

  7. חישוב מספר ה-Pods המקסימלי (MP):

    MP = MN * Q

    התוצאה של החישוב הזה היא המספר המקסימלי של Pods שהאשכול יכול לתמוך בהם.

  8. חישוב מספר כתובות ה-IP שניתן להשתמש בהן בטווח הראשי (N): none N = 2<sup>(32-S)</sup> - 4 כאשר S הוא אורך הקידומת של טווח ה-CIDR הראשי של רשת המשנה.

הערות חשובות

  • אפשר להשתמש בכל כתובות ה-IP בטווח המשני בשביל Pods.
  • החישובים האלה מספקים את הערכים המקסימליים התיאורטיים. ביצועים בעולם האמיתי יכולים להיות מושפעים מגורמים אחרים.

דוגמה

נניח שאתם יוצרים אשכול GKE Autopilot עם הפרטים הבאים:

  • חסימת CIDR של תת-רשת של Pod‏ /17 (DS = 17).
  • מקסימום 32 פודים לכל צומת (Q = 32).

חישוב מספר ה-Pods המקסימלי:

  1. M = 31 - ⌈log₂(32)⌉ = 26
  2. HM = 32 - 26 = 6
  3. HD = 32 - 17 = 15
  4. MN = 2(15 - 6) = 512
  5. MP = 512 * 32 = 16,384

האשכול הזה יכול לתמוך ב-512 צמתים וב-16,384 פודים לכל היותר.

כדי להוסיף עוד כתובות IPv4 ל-Pods, אפשר להוסיף טווחים של כתובות IPv4 ל-Pods או להוסיף רשתות משנה לאשכולות.

טווח כתובות IP משני של רשת משנה לשירותים

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

אם אתם משתמשים בשירותים מרובי-אשכולות, אובייקט ServiceImport משתמש בכתובות IP מטווח כתובות ה-IP המשני לשירותים.

באשכולות GKE Autopilot שפועלת בהם גרסה 1.27 ואילך, ובאשכולות GKE Standard שפועלת בהם גרסה 1.29 ואילך, מערכת GKE מקצה כתובות IP לשירותים מטווח שמנוהל על ידי GKE כברירת מחדל: 34.118.224.0/20. כך לא תצטרכו לציין טווח כתובות IP משלכם לשירותים. צריך להתחשב בשיקולים הבאים:

  • אפשר גם לציין טווחים מותאמים אישית לשירותים באמצעות הדגל --services-ipv4-cidr או הדגל --services-secondary-range-name.
  • אם מציינים רק גודל טווח באמצעות הדגל --services-ipv4-cidr (לדוגמה, /22), GKE עדיין משתמש בטווח שמנוהל על ידי GKE כדי לקבל את טווח המשנה של הכתובות.
  • ‫GKE לא יוצר טווח כתובות IP משני נפרד עבור Services כשמשתמשים בטווח שמנוהל על ידי Google. הטווח שמנוהל על ידי GKE לא משתמש במכסת טווח כתובות ה-IP המשני של רשת המשנה.

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

טווח IP משני לשירותים מספר השירותים המקסימלי
/28
טווח כתובות השירות הקטן ביותר האפשרי כאשר שיטת הקצאת הטווח המשני היא בניהול המשתמש		 ‫16 שירותים
‫‎/27
טווח כתובות השירות הכי קטן שאפשר כששיטת הקצאת הטווח המשני מנוהלת על ידי GKE		 ‫32 Services
/26 ‫64 שירותים
/25 ‫128 Services
/24 ‫256 שירותים
/23 ‫512 שירותים
/22 ‫1,024 שירותים
/21 ‫2,048 שירותים
‫‎/20
גודל ברירת המחדל של טווח כתובות ה-IP המשני של רשת המשנה לשירותים כששיטת ההקצאה של הטווח המשני מנוהלת על ידי GKE		 ‫4,096 שירותים
/19 ‫8,192 שירותים
/18 ‫16,384 שירותים
/17 ‫32,768 שירותים
/16
טווח כתובות השירות הגדול ביותר האפשרי		 ‫65,536 שירותים

שיתוף טווחי כתובות IP בין אשכולות GKE

אפשר לשתף את הטווח הראשי, את טווח כתובות ה-IP המשני של Pod ואת טווח כתובות ה-IP המשני של Services בין אשכולות באותה תת-רשת. ההתנהגות הזו זמינה גם באשכולות רגילים וגם באשכולות במצב טייס אוטומטי.

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

שיתוף טווח רשתות המשנה המותאם אישית עבור רמת הבקרה

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

שיתוף טווח כתובות ה-IP הראשי של הצמתים

אם יוצרים יותר מאשכול אחד ברשת המשנה, טווח כתובות ה-IP הראשי של הצמתים משותף כברירת מחדל.

יש מגבלות על שיתוף כתובת ה-IP הראשית של הצמתים:

  • אם משתפים את טווח כתובות ה-IP הראשי של הצמתים עם שני אשכולות או יותר של VPC-native, אשכול אחד יכול להשתמש בחלק גדול מטווח כתובות ה-IP המשותף, כך שלאשכולות האחרים לא יהיו מספיק כתובות IP להרחבה.

שיתוף טווח כתובות ה-IP המשניות של Pods

כשמשתפים את הטווח המשני של כתובות ה-IP של ה-Pods, כל Pod עדיין מקבל כתובת IP ייחודית.

יש מגבלות על שיתוף טווח כתובות ה-IP המשני של ה-Pods:

  • אם משתפים את טווח כתובות ה-IP המשני של ה-Pods עם שני אשכולות או יותר של VPC-native, אשכול אחד יכול להשתמש בחלק גדול מטווח כתובות ה-IP המשותף, כך שלאשכולות האחרים לא יהיו מספיק כתובות IP להרחבה.

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

  • כדי לשתף טווח כתובות IP משני, מעבירים אותו בשורת הפקודה עם --cluster-secondary-range. אי אפשר להשתמש בטווח משני משותף כשיוצרים אשכולות בממשק המשתמש.

שיתוף טווח כתובות ה-IP המשני לשירותים

אם משתמשים בטווחים משניים בניהול המשתמש, שני אשכולות או יותר יכולים להשתמש בו-זמנית באותו טווח כתובות IPv4 משני ברשת משנה לשירותים.

כדי להגדיר שני אשכולות או יותר שישתפו טווח משני משותף של כתובות IPv4 ברשת משנה לשירותים, צריך להשתמש באותו טווח משני של כתובות IPv4 ברשת משנה כשיוצרים כל אשכול. לא נדרש דגל הגדרה נפרד כדי לשתף טווח כתובות IPv4 משותף לשירותים.

כשמשתפים טווח כתובות IPv4 משותף לשירותים, כל אשכול משתמש באופן פנימי בטווח המשני של כתובות IPv4 של רשת המשנה לשירותים. כתובות ה-IP של השירותים מתוכנתות בצומת של כל אשכול, אבל הן לא מוקצות לממשק הרשת של אף צומת. אי אפשר לנתב כתובות IP של שירותים ברשת ה-VPC של האשכול. אפשר להשתמש בכתובות ה-IP של השירות רק על ידי פודים של לקוחות באותו אשכול כמו השירות.

כש-Pod שולח מנה לכתובת IP של שירות, הגדרת iptables או eBPF בצומת מבצעת תרגום כתובות רשת (NAT) של היעד, ומשנה את כתובת ה-IP של היעד של המנה מכתובת ה-IP של השירות לכתובת IP של Pod שמשרת את המנה. ניתוב חבילת הנתונים מבוסס על כתובת ה-IP של יעד ה-Pod.

שיתוף טווח כתובות ה-IP המשני לשירותים מספק את היתרונות הבאים:

  • צמצום מספר הטווחים הייחודיים של כתובות IP משניות לשירותים שנוצרו ברשת משנה
  • שימוש בפחות כתובות IP

יש מגבלות על שיתוף טווח כתובות ה-IP המשני לשירותים:

  • שיתוף טווח כתובות ה-IP המשני לשירותים אינו נתמך באמצעות Cloud DNS בהיקף VPC ל-GKE.

  • אי אפשר לשתף טווחים שתואמים לביטוי הרגולרי הבא:

    ^gke-.*-services-[abcdef0-9]{8}

  • כדי לשתף טווח משני של כתובות IP לשירותים, מעבירים אותו בשורת הפקודה עם --cluster-secondary-range. אי אפשר להשתמש בטווח משני משותף לשירותים כשיוצרים אשכולות בממשק המשתמש.

טווחים להגבלת צמתים

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

הודעת השגיאה הבאה מציינת שטווח כתובות ה-IP הראשי של רשת המשנה או טווח כתובות ה-IP של ה-Pod באשכול (טווח כתובות ה-IP המשני של רשת המשנה עבור ה-Pods) מוצה:

Instance [node name] creation failed: IP space of [cluster subnet] is
exhausted

כדי להוסיף עוד כתובות IP לצמתים, מרחיבים את רשת המשנה הראשית, או מוסיפים כתובות IP חדשות ל-Pods באמצעות CIDR רב-Pod לא רציף. מידע נוסף זמין במאמר בנושא אין מספיק נפח אחסון פנוי לכתובות IP עבור Pods.

רשתות עם מחסנית כפולה של IPv4/‏IPv6

עם רשתות IPv4/IPv6 dual-stack, אתם יכולים להגדיר איך GKE מקצה כתובות IP ‏ (ipFamilies) לאובייקטים הבאים:

  • ל-Pods ולצמתים, מערכת GKE מקצה כתובות IPv4 ו-IPv6.
  • ב-Services,‏ GKE מקצה כתובות מסוג single-stack (IPv4 בלבד או IPv6 בלבד) או dual-stack.

בגרסה 1.24 של GKE ואילך, אפשר להפעיל רשתות עם תמיכה בשני פרוטוקולים (IPv4 ו-IPv6) באשכולות GKE חדשים ברשתות VPC עצמאיות וברשתות VPC משותפות. אפשר גם להחיל מדיניות רשת עם הפעלה של רשתות בעלות מחסנית כפולה. אם מוצגות שגיאות אימות כשמפעילים רשתות בעלות מחסנית כפולה באשכולות GKE ששודרגו מגרסאות 1.24 לגרסאות 1.25 או 1.26, אפשר לפנות אל Google Cloud צוות התמיכה.

יתרונות

היתרונות של רשתות עם תמיכה כפולה בפרוטוקולים:

  • ההגדרה הזו מאפשרת תקשורת IPv6 מקצה לקצה.
  • מאפשר ביצועים טובים יותר בהשוואה לתרגום כתובות רשת (NAT) או למנהור IP. הדבר מתאפשר כי אין תרגום מ-IPv6 ל-IPv4.

זמינות

הרישות ב-GKE עם תמיכה כפולה ב-IPv4 ו-IPv6 כפוף להגבלות הבאות:

  • רשתות עם תמיכה בשני פרוטוקולים זמינות רק באשכולות מקומיים ב-VPC עם GKE Dataplane V2 מופעל.
  • רשתות עם פרוטוקול כפול נתמכות רק ברשתות משנה ב-VPC במצב מותאם אישית. מידע נוסף זמין במאמר בנושא Google Cloud סוגים של רשתות VPC.
  • אין תמיכה בכתובות IPv6 חד-ערימות עבור Pods או צמתים.
  • אשכולות עם תמיכה כפולה צורכים יותר זיכרון לכל צומת כדי לתמוך גם ב-IPv4 וגם ב-IPv6, בהשוואה לאשכולות עם IPv4 בלבד. כדאי לקחת את המאפיין הזה בחשבון כשמגדירים אשכולות בקנה מידה גדול.
  • קלאסטרים עם תמיכה כפולה לא תומכים בגישה פרטית ל-Google דרך IPv6.
  • ב-GKE בגרסה 1.26.0-gke.2200 ואילך יש תמיכה ב-IPv6 (רשומות AAAA) עם Cloud DNS לפעולות פנימיות של אשכולות ולשאילתות DNS חיצוניות.
  • שירותי Dual-stack נתמכים בשירותים ClusterIP, NodePort ו-LoadBalancer.
  • אין תמיכה ב-IPv6 בצמתי Windows.

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

הקצאה של כתובות IPv6 ציבוריות ופרטיות

בטבלה הבאה מופיע סיכום של כתובות IPv6 ציבוריות ופרטיות עם התנהגות והגדרות של רשתות עם תמיכה כפולה ב-IPv4 וב-IPv6:

ipv6-access-type דגל הקצאת כתובות IP טווח תת-רשת
EXTERNAL

‫GKE מקצה כתובות IPv6 חיצוניות שניתן לנתב לאינטרנט.

 החל מ-2600:1900/28
INTERNAL

‫GKE מקצה כתובות IPv6 פנימיות שלא ניתן לנתב לאינטרנט.

ל клаסטרים עם סוג הגישה INTERNAL IPv6 אין גישה לאינטרנט דרך כתובות IPv6. ‫Cloud NAT לא תומך בכתובות IPv6.

 מ-fd20::/20 (שהוא קבוצת משנה של טווח ה-ULA הכולל: fc00::/7).

מידע נוסף זמין במאמר איך משתמשים ברשת עם תמיכה בשני הפרוטוקולים עבור אשכול מקורי של VPC.

ארכיטקטורה

באשכול עם רשתות IPv4/IPv6 dual-stack, מוקצים הטווחים הבאים:

  • טווח ‎ /64 לכל רשת משנה כטווח ראשי.
  • טווח של ‎ /96 לכל צומת מהטווח הראשי, לשימוש כטווח כתובות IP של צומת ראשי.

  • טווח של ‎ /112 לכל צומת מטווח כתובות ה-IP של הצומת הראשי, לשימוש כטווח כתובות ה-IP של ה-Pod עבור אותו צומת. בשימוש ברשתות עם תמיכה כפולה ב-IPv4 וב-IPv6, כתובות ה-IPv6 של ה-Pods מתקבלות מטווח כתובות ה-IP הכולל של ה-Pods (בדומה לצמתים), ולא מטווח משני של כתובות IPv4 ששמורות ל-Pods.

    טווח כתובות ה-IP הכולל של ה-Pod מורכב מטווחים לא חופפים מתוך טווח כתובות ה-IP של הצומת הראשי. לכן, טווח כתובות ה-IP של ה-Pod הזה הוא לא רציף.

  • טווח של ‎ /112 לשימוש בשירותים. הטווח הזה מגיע מטווח ‎ /64 מטווח הכתובות הפרטיות של Google, שהוזמן לטווח כתובות ה-IP של שירותים משניים ב-GKE.

בתרשים הבא מוצג אופן ההקצאה של כתובות IPv6 ב- Google Cloud וב-GKE:

הקצאת כתובות IPv6 ב-GKE. תרשים שמראה איך Google Cloud ו-GKE מקצים כתובות IPv6.

בתרשים, הטווח הראשי של רשת המשנה ב-VPC הוא 2600:1900:0:1::/64 והטווח השמור לשירותי GKE הוא 2600:2D00:0:4::0:0/64. לכל צומת באשכול יש טווח של ‎ /96 לטווח כתובות ה-IP של הצומת הראשי וטווח של ‎ /112 לטווח כתובות ה-IP של ה-Pod. ל-cluster יש גם טווח כתובות IP משני לשירותים, בגודל ‎ /112.

שירותים

אפשר ליצור שירות IPv4/IPv6 dual-stack מסוג ClusterIP או NodePort. אשכולות GKE חדשים שפועלת בהם גרסה 1.29 ואילך תומכים בשירותים עם מחסנית כפולה מסוג LoadBalancer.

אפשר לחשוף פריסה באמצעות שירות מסוג ClusterIP, NodePort או LoadBalancer. לכל אחד מסוגי השירותים האלה, אפשר להגדיר את השדות ipFamilies ו-ipFamilyPolicy כ-IPv4,‏ IPv6 או שירות dual-stack. מידע נוסף זמין בדוגמה להגדרת פריסה.

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