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

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

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

סקירה כללית

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

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

שיטה מומלצת:

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

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

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

  • אפשר להגדיר ניתוב של כתובות IP של Pod באופן מקורי ברשת ה-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.

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

מצב הרשת שמוגדר כברירת מחדל לכל האשכולות החדשים בכל הגרסאות הזמינות שנוצרו דרך כל ממשק, כולל Google Cloud CLI, Google Cloud המסוף או GKE API, הוא VPC-native. מידע נוסף על הגרסאות הזמינות מופיע במאמר גרסאות נוכחיות.

אם אתם לא רוצים להשתמש במצב הרשת המומלץ של VPC-native, תוכלו לעיין במאמר בנושא יצירת אשכול מבוסס-ניתוב.

טווחים של כתובות 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 משני של רשת משנה, ששונה מהטווחים שבהם נעשה שימוש ב-Pods.

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

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

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

שירותים

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

באשכולות GKE Autopilot שפועלת בהם גרסה 1.27 ואילך, ובאשכולות GKE Standard שפועלת בהם גרסה 1.29 ואילך, מערכת GKE מקצה כתובות IP לשירותי 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 משניות עבור Services כשמשתמשים בטווח שמנוהל על ידי GKE.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מחשבון כתובות IP ב-GKE

אפשר להשתמש במחשבון הזה כדי לתכנן את הקצאת כתובות ה-IP לאשכולות רגילים שמוגדרים כ-VPC-native, שבהם לכל מאגר צמתים יש מספר קבוע של Pods לכל צומת. אתם יכולים להזין את מספר הצמתים (nodes) וה-Pods כדי לקבוע את הגדלים המתאימים של קידומות רשתות המשנה, או להזין את הגדלים של רשתות המשנה כדי לראות את המספר המקסימלי של הצמתים וה-Pods שנתמכים. המחשבון הזה מקצה טווחים מספיקים של כתובות 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 צמתים
‫‎/9
הגודל המקסימלי של טווח כתובות ה-IP הראשי של תת-רשת		 ‫8,388,604 צמתים ‫8,388,603 צמתים

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

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

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

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

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

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

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

    $$ N = 2^{(32 - S)} - 4 $$

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

    $$ S = 32 - \lceil{log_2(N + 4)}\rceil $$

    ‫\( \lceil{ }\rceil \) היא פונקציית העיגול כלפי מעלה (המספר השלם הקטן ביותר), כלומר עיגול כלפי מעלה למספר השלם הבא. הטווח התקף של גודל מסכת הרשת, S, הוא בין 9 ל-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 clusters, אפשר להגדיר Q.

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

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

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

    $$ M = 31 - \lceil{log_2(Q)}\rceil $$

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

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

    $$ HM = 32 - M $$

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

    $$ HD = 32 - DS $$

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

    $$ MN = 2^{(HD - HM)} $$

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

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

    $$ MP = MN * Q $$

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

  8. מחשבים את מספר כתובות ה-IP שניתן להשתמש בהן בטווח הראשי (N):

    $$ N = 2^{(32 - S)} - 4 $$

    כאשר S הוא אורך הקידומת של טווח ה-CIDR הראשי של רשת המשנה.

הערות חשובות

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

דוגמה

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

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

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

  1. \( M = 31 - \lceil{log_2(32)}\rceil = 26 \)
  2. \( HM = 32 - 26 = 6 \)
  3. \( HD = 32 - 17 = 15 \)
  4. \( MN = 2^{(15 - 6)} = 512 \)
  5. \( MP = 512 * 32 = 16384 \)

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

כדי להוסיף עוד כתובות 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 שירותים
/26 ‫64 שירותים
/25 ‫128 שירותים
/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 של שירותים רק על ידי Pods של לקוחות באותו אשכול כמו השירות.

כש-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, אתם יכולים להגדיר איך GKE מקצה כתובות IP ‏ (ipFamilies) לאובייקטים הבאים:

  • ל-Pods ולצמתים, מערכת GKE מקצה כתובות IPv4 ו-IPv6.
  • ב-Services,‏ GKE מקצה כתובות של סטאק יחיד (IPv4 בלבד או IPv6 בלבד) או של סטאק כפול.

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

יתרונות

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

  • הפעלת תקשורת 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 ציבוריות ופרטיות עם התנהגות והגדרות של רשתות עם סטאק כפול:

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 עבור הצומת הזה. ברשתות עם סטאק כפול, כתובות ה-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 מסוג ClusterIP או NodePort. באשכולות GKE חדשים שפועלת בהם גרסה 1.29 ואילך יש תמיכה בשירותים עם כתובות IPv4 ו-IPv6 (dual-stack) מסוג LoadBalancer.

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

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