פתרון בעיות בניהול כתובות IP באשכולות VPC

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

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

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

אבחון של מיצוי כתובות IP

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

מערכת GKE מחשבת את ניצול כתובות ה-IP באמצעות נתונים מ תובנות של Network Analyzer וממקורות נתונים אחרים של GKE. המעקב הזה זמין לכל האשכולות המקוריים של VPC.

כדי לראות את ניצול כתובות ה-IP של אשכול:

  1. נכנסים לדף Kubernetes clusters במסוף Google Cloud .

    מעבר אל Kubernetes clusters

  2. לוחצים על שם האשכול שרוצים לבדוק. הפעולה הזו פותחת את הדף פרטים של האשכול.

  3. מנווטים לדף IP utilization (ניצול כתובות IP) באחת מהשיטות הבאות:

    • לוחצים על הכרטיסייה Observability ואז בתפריט הניווט של Observability לוחצים על IP utilization.

    • בקטע Networking, מאתרים את השורה Cluster Pod IPv4 range (default) ולוחצים על View IP utilization.

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

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

אם הניצול של כתובות ה-IP גבוה (קרוב ל-100%), כדאי לשקול את הפתרונות הבאים כדי למנוע מיצוי של כתובות ה-IP:

  • מוסיפים עוד טווחי כתובות IPv4 של Pod באמצעות multi-Pod CIDR לא רציף. התכונה הזו מאפשרת להוסיף עוד כתובות IPv4 ל-Pods בלי ליצור מחדש את האשכול או להגדיר רשתות משנה חדשות.
  • מוסיפים עוד רשתות משנה עם טווחים נוספים של כתובות IPv4 באשכול. התכונה הזו מאפשרת למאגרי צמתים חדשים להשתמש בכתובות IP מרשתות משנה שנוספו לאחרונה.
  • יוצרים אשכול חדש עם ערך נמוך יותר למספר המקסימלי של Pods. בגישה הזו נשמרות פחות כתובות IP לכל צומת, מה שיכול לעזור לכם לנהל את צריכת כתובות ה-IP הכוללת בטווח הרשת של האשכול. מידע נוסף זמין במאמר בנושא הגדרת מספר מקסימלי של Pods לכל צומת.
  • אם אין לכם מספיק טווחים של כתובות IP או מרחב כתובות RFC 1918, כדאי לשקול טווחים שאינם RFC 1918 (כולל מרחב הכתובות מסוג Class E).

פתרון בעיות ספציפיות ברשת

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

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

תסמינים

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

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default
סיבות אפשריות

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

רזולוציה

מנסים להריץ שוב את הפקודה.

ערך לא תקין של IPCidrRange

תסמינים

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

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'
סיבות אפשריות

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

אותו טווח משני מתווסף לרשת המשנה באותה רשת VPC.

רזולוציה

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

אין מספיק מקום לכתובות IP פנויות בשביל Pods

תסמינים

האשכול תקוע במצב הקצאה למשך זמן ממושך.

יצירת האשכול מחזירה שגיאה של קבוצת מופעי מכונה מנוהלים (MIG).

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

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/[SUBNET_NAME]-[SECONDARY_RANGE_NAME]-[HASH_8BYTES]' is exhausted. The secondary range name is in the format of 'gke-[CLUSTER_NAME]-[HASH_8BYTES]'.
סיבות אפשריות

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

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

מיצוי של כתובות ה-IP של ה-Pods: טווח ה-CIDR של ה-Pods שהוקצה לאשכול מלא. המצב הזה קורה כשמספר ה-Pods חורג מהקיבולת של Pod CIDR, במיוחד בצפיפות גבוהה של Pods לכל צומת או בפריסות גדולות.

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

מיצוי של טווח משני (Autopilot): באשכולות של Autopilot, הטווחים המשניים שהוקצו לכתובות ה-IP של ה-Pod מוצו בגלל שינוי גודל או צפיפות גבוהה של Pod.

פתרון

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

אישור בעיה של מיצוי כתובות IP

  • ‫Network Intelligence Center: בודקים אם יש שיעורי הקצאה גבוהים של כתובות IP בטווחים של כתובות ה-IP של הפוד ב-Network Intelligence Center עבור אשכול ה-GKE.

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

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

  • יומני ביקורת: בודקים את השדה resourceName ברשומות IP_SPACE_EXHAUSTED, ומשווים אותו לשמות של רשתות משנה או לשמות של טווח כתובות ה-IP של ה-Pod המשני.

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

    כדי לוודא אם טווח כתובות ה-IP שהתמלא הוא טווח כתובות ה-IP של הצומת או טווח כתובות ה-IP של ה-Pod, בודקים אם הערך של resourceName בחלק ipSpaceExhausted של רשומה ביומן IP_SPACE_EXHAUSTED תואם לשם רשת המשנה או לשם של טווח כתובות IPv4 משני של ה-Pods שמשמשים באשכול GKE המושפע.

    אם הערך של resourceName הוא בפורמט [Subnet_name], אז טווח כתובות ה-IP של הצומת מוצה. אם הערך של resourceName הוא בפורמט ‎"[Subnet_name]-[Name_of_Secondary_IPv4_range_for_pods]-[HASH_8BYTES]"‎, אז טווח כתובות ה-IP של הפוד מוצה.

פתרון בעיה של מיצוי כתובות IP של Pod:

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

מצמצמים את מספר ה-Pods לכל צומת כדי לפנות כתובות IP:

מיצוי של כתובות IP של צומת כתובות:

ניפוי באגים בבעיות שקשורות למיצוי של כתובות IP באמצעות gcpdiag

‫gcpdiag הוא כלי בקוד פתוח. זה לא מוצר נתמך רשמית של Google Cloud . אפשר להשתמש בgcpdiagכלי כדי לזהות ולפתור Google Cloudבעיות בפרויקט. מידע נוסף זמין בפרויקט gcpdiag ב-GitHub.

כדי לבדוק את הסיבות למיצוי כתובות IP באשכולות GKE במצב Autopilot ובמצב Standard, כדאי לשים לב לנקודות הבאות:
  • סטטוס האשכול: בדיקת סטטוס האשכול אם דווח על מיצוי של כתובות IP.
  • כלי לניתוח רשת: שולח שאילתות ליומנים של Stackdriver כדי לבדוק אם יש ניצול יתר של כתובות IP של צומת או של Pod.
  • סוג האשכול: בדיקה של סוג האשכול ומתן המלצות רלוונטיות על סמך סוג האשכול.

מסוףGoogle Cloud

  1. משלימים את הפקודה הבאה ואז מעתיקים אותה. 
    2. gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \
  2. פותחים את Google Cloud המסוף ומפעילים את Cloud Shell.
    3. פתיחת מסוף Cloud
  3. מדביקים את הפקודה שהועתקה.
  4. מריצים את הפקודה gcpdiag, שמורידה את תמונת ה-Docker‏ gcpdiag, ואז מבצעת בדיקות אבחון. אם יש הוראות לגבי הפלט, פועלים לפיהן כדי לתקן את הבדיקות שנכשלו.

Docker

אפשר להריץ את gcpdiag באמצעות wrapper שמתחיל את gcpdiag בקונטיינר של Docker. צריך להתקין את Docker או את Podman.

  1. מעתיקים את הפקודה הבאה ומריצים אותה בתחנת העבודה המקומית. 
    curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
  2. מריצים את הפקודה gcpdiag. 
    ./gcpdiag runbook gke/ip-exhaustion \
    --parameter project_id=PROJECT_ID \
    --parameter name=CLUSTER_NAME \
    --parameter location=ZONE|REGION \
    --parameter start_time=yyyy-mm-ddThh:mm:ssZ \
    --parameter end_time=yyyy-mm-ddThh:mm:ssZ \

כאן אפשר לראות את הפרמטרים הזמינים של קובץ ה-runbook הזה.

מחליפים את מה שכתוב בשדות הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט שמכיל את המשאב
  • ‫CLUSTER_NAME: השם של אשכול GKE היעד בפרויקט.
  • ‫LOCATION: האזור או האזור שבו נמצא האשכול.
  • start_time: השעה שבה הבעיה התחילה.
  • ‫end_time: השעה שבה הבעיה הסתיימה. אם הבעיה נמשכת, צריך להגדיר את השעה הנוכחית.

דגלים שימושיים:

  • ‫--universe-domain: אם רלוונטי, הדומיין של Trusted Partner Sovereign Cloud שמארח את המשאב
  • ‫--parameter או -p: פרמטרים של Runbook

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

בדיקה אם ה-SNAT שמוגדר כברירת מחדל מושבת

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

gcloud container clusters describe CLUSTER_NAME

מחליפים את CLUSTER_NAME בשם האשכול.

הפלט אמור להיראות כך:

networkConfig:
  disableDefaultSnat: true
  network: ...

אי אפשר להשתמש ב---disable-default-snat בלי --enable-ip-alias

הודעת השגיאה הזו, וגם must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster, מציינות שצריך להגדיר במפורש את הדגל --disable-default-snat כשיוצרים את האשכול, כי אתם משתמשים בכתובות IP ציבוריות באשכול הפרטי.

אם מופיעות הודעות שגיאה כמו cannot disable default sNAT ... , המשמעות היא שלא ניתן להשבית את ה-SNAT שמוגדר כברירת מחדל באשכול. כדי לפתור את הבעיה, צריך לבדוק את הגדרות האשכול.

ניפוי באגים ב-Cloud NAT כשה-SNAT המוגדר כברירת מחדל מושבת

אם יצרתם אשכול פרטי עם הדגל --disable-default-snat והגדרתם Cloud NAT לגישה לאינטרנט, ואתם לא רואים תנועה שיוצאת מה-Pods לאינטרנט, ודאו שטווח ה-Pods כלול בהגדרת Cloud NAT.

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

מידע נוסף זמין במאמרי העזרה בנושא הסתרת כתובות IP ב-GKE.

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

התקשורת ברשת של אשכולות עם פרוטוקול כפול לא פועלת כמו שצריך

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

  1. בודקים את התוכן של כלל חומת האש:

    gcloud compute firewall-rules describe FIREWALL_RULE_NAME

    מחליפים את FIREWALL_RULE_NAME בשם של כלל חומת האש.

    כל אשכול עם תמיכה ב-IPv4 ו-IPv6 יוצר כלל חומת אש שמאפשר לצמתים ול-Pods לתקשר זה עם זה. התוכן של כלל חומת האש דומה לתוכן הבא:

    allowed:
- IPProtocol: esp
- IPProtocol: ah
- IPProtocol: sctp
- IPProtocol: tcp
- IPProtocol: udp
- IPProtocol: '58'
creationTimestamp: '2021-08-16T22:20:14.747-07:00'
description: ''
direction: INGRESS
disabled: false
enableLogging: false
id: '7326842601032055265'
kind: compute#firewall
logConfig:
  enable: false
name: gke-ipv6-4-3d8e9c78-ipv6-all
network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
priority: 1000
selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
sourceRanges:
- 2600:1900:4120:fabf::/64
targetTags:
- gke-ipv6-4-3d8e9c78-node

    הערך של sourceRanges חייב להיות זהה לערך של subnetIpv6CidrBlock. הערך של targetTags חייב להיות זהה לתגים בצמתי GKE. כדי לפתור את הבעיה, צריך לעדכן את כלל חומת האש עם פרטי הבלוק של אשכול ipAllocationPolicy.

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