ניהול יעיל של כתובות IP הוא חיוני ליציבות ולגמישות של אשכולות מקוריים של VPC ב-Google Kubernetes Engine (GKE). בעיות יכולות למנוע שינוי גודל או לגרום לכשלים בעומסי עבודה, כמו כשלים בתזמון של Pods.
במאמר הזה מוסבר איך לפתור בעיות שקשורות להקצאת כתובות IP, ליציבות הרשת ולתכונות מתקדמות של רשתות באשכולות המותאמים ל-VPC ב-GKE.
המידע הזה מיועד בעיקר לאדמינים ולמפעילים של פלטפורמות שמנהלים את תשתית הרשת של האשכול. הוא גם עוזר למפתחי אפליקציות להבין איך מגבלות בסיסיות ברשת, כמו מיצוי של מרחב כתובות IP, יכולות להשפיע על עומסי העבודה שלהם. יכול להיות שמפתחים לא יגדירו ישירות רשתות VPC, אבל הבנה של הבעיות הנפוצות האלה תעזור להם לשתף פעולה בצורה טובה יותר עם אדמינים ומפעילים של פלטפורמות כדי לפתור בעיות מהר יותר. מידע נוסף על תפקידים נפוצים ומשימות לדוגמה שאנחנו מתייחסים אליהם ב Cloud de Confiance by S3NS תוכן זמין במאמר תפקידי משתמשים נפוצים ומשימות ב-GKE.
אבחון של מיצוי כתובות IP
אם נגמרות כתובות ה-IP באשכול, יכול להיות שלא תהיה אפשרות להרחיב את הצמתים ויהיו שיבושים בעומסי העבודה. בקטע הזה מוסבר איך להשתמש במעקב אחרי ניצול כתובות ה-IP ב-GKE כדי לזהות ולפתור בעיות פוטנציאליות של מיצוי כתובות ה-IP.
GKE מחשב את ניצול כתובות ה-IP באמצעות נתונים מ תובנות של Network Analyzer וממקורות נתונים אחרים של GKE. המעקב הזה זמין לכל האשכולות המותאמים ל-VPC.
כדי לראות את ניצול כתובות ה-IP של אשכול:
נכנסים לדף Kubernetes clusters במסוף Cloud de Confiance .
לוחצים על השם של האשכול שרוצים לבדוק. הפעולה הזו פותחת את הדף פרטים של האשכול.
מנווטים לדף IP utilization (ניצול כתובות IP) באחת מהשיטות הבאות:
לוחצים על הכרטיסייה Observability ואז בתפריט הניווט של Observability לוחצים על IP utilization.
בקטע Networking (רשת), מאתרים את השורה Cluster Pod IPv4 range (default) (טווח כתובות IPv4 של Cluster Pod (ברירת מחדל)) ולוחצים על View IP utilization (הצגת ניצול כתובות IP).
בודקים את העמודה סטטוס הקצאת כתובות IP. בעמודה הזו מוצג אחוז כתובות ה-IP שהוקצו בטווח כתובות ה-IP של ה-Pod. מערכת GKE מחשיבה את כל כתובות ה-IP בטווח ה-CIDR שהוקצה לצומת ככתובות שהוקצו, בלי קשר לשאלה אם כתובות IP ספציפיות הוקצו ל-Pods. המשמעות היא שהאחוז משקף את כל טווח ה-Pod של צומת, ולא רק את כתובות ה-IP שבשימוש. אם לאשכולות יש טווחי כתובות IP זהים, אחוז הניצול מציג את הסכום המשולב שלהם.
כדי לראות תצוגה מפורטת של השימוש בכתובות IP, כולל טווחי CIDR, מידע על רשתות משנה והמלצות, לוחצים על Show details.
אם ניצול כתובות ה-IP שלכם גבוה (קרוב ל-100%), כדאי לשקול את הפתרונות הבאים כדי למנוע מיצוי של כתובות ה-IP:
- מוסיפים עוד טווחי כתובות IPv4 של Pod באמצעות multi-Pod CIDR לא רציף. התכונה הזו מאפשרת להוסיף עוד כתובות IPv4 ל-Pods בלי ליצור מחדש את האשכול או להגדיר רשתות משנה חדשות.
- מוסיפים עוד תת-רשתות עם טווחי כתובות IPv4 נוספים באשכול. התכונה הזו מאפשרת למאגרי צמתים חדשים להשתמש בכתובות IP מרשתות משנה שנוספו לאחרונה.
- יוצרים אשכול חדש עם ערך נמוך יותר למספר המקסימלי של יחידות Pod. בגישה הזו נשמרות פחות כתובות IP לכל צומת, מה שיכול לעזור לכם לנהל את צריכת כתובות ה-IP הכוללת בטווח הרשת של האשכול. מידע נוסף זמין במאמר בנושא הגדרת מספר מקסימלי של Pods לכל צומת.
- אם אין לכם מספיק טווחי כתובות IP או מרחב כתובות RFC 1918, כדאי להשתמש בטווחים שאינם RFC 1918 (כולל מרחב הכתובות מסוג Class E).
פתרון בעיות ספציפיות ברשת
בקטעים הבאים מוסבר איך לפתור בעיות שקשורות לאשכולות המותאמים ל-VPC. אפשר גם לצפות בתובנות לגבי ניצול כתובות IP ב-GKE.
משאב הרשת שמוגדר כברירת מחדל לא מוכן
- תסמינים
מופיעה הודעת שגיאה שדומה להודעה הבאה:
projects/[PROJECT_NAME]/regions/XXX/subnetworks/default- סיבות אפשריות
יש פעולות מקבילות באותה רשת משנה. לדוגמה, אם נוצר אשכול נוסף שמוגדר כ-VPC-native, או אם נוסף או נמחק טווח משני ברשת המשנה.
- רזולוציה
מנסים להריץ שוב את הפקודה.
ערך לא תקין של IPCidrRange
- תסמינים
מופיעה הודעת שגיאה שדומה להודעה הבאה:
resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'- סיבות אפשריות
אשכול נוסף שמוגדר כ-VPC-native נוצר באותו הזמן ומנסה להקצות את אותם טווחים באותה רשת 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 הראשי של רשת המשנה שהוקצתה לאשכול שלכם נגמר. הבעיה הזו מתרחשת בדרך כלל כשמגדילים את מספר הצמתים במאגרי הצמתים או כשיוצרים אשכולות גדולים.
מספר גבוה של צמתים ראשוניים במאגרי צמתים שהוקטנו: GKE שומר כתובות IP לפודים על סמך הקיבולת הראשונית שביקשתם כשיצרתם מאגר צמתים. אם יוצרים מאגר צמתים עם ערך גבוה של
initial_node_countואז מקטינים את מספר הצמתים, GKE ממשיך לשריין מרחב של כתובות IP על סמך הערך הגדול יותר מביןinitial_node_countשל מאגר הצמתים או מספר הצמתים הנוכחי במאגר הצמתים. המצב הזה יכול להוביל למצב שבו האשכול מדווח על מיצוי של כתובות ה-IP, גם אם המספר הנוכחי של הצמתים הפעילים נמוך.מיצוי כתובות ה-IP של Pod: טווח ה-CIDR של Pod שהוקצה לאשכול מלא. המצב הזה מתרחש כשמספר ה-Pods חורג מהקיבולת של Pod CIDR, במיוחד בצפיפות גבוהה של Pods לכל צומת או בפריסות גדולות.
מוסכמות ספציפיות למתן שמות לרשתות משנה: הדרך שבה רשת משנה נקראת בהודעת שגיאה יכולה לעזור לכם להבין אם הבעיה היא בטווח כתובות ה-IP של הצומת (שבו הצמתים עצמם מקבלים את כתובות ה-IP שלהם) או בטווח כתובות ה-IP של ה-Pod (שבו הקונטיינרים בתוך ה-Pods מקבלים את כתובות ה-IP שלהם).
מיצוי של טווח משני (Autopilot): באשכולות של Autopilot, הטווחים המשניים שהוקצו לכתובות ה-IP של ה-Pod מוצו בגלל שינוי גודל או צפיפות גבוהה של ה-Pod.
- פתרון
אוספים את המידע הבא על האשכול: שם, גרסת מישור הבקרה, מצב הפעולה, שם ה-VPC המשויך, שם רשת המשנה ו-CIDR. בנוסף, שימו לב לטווחי ברירת המחדל ולכל טווח IPv4 נוסף של 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 הוא בפורמט [שם_רשת_משנה]-[שם_טווח_משני_של_כתובות_IPv4_לפודים]-[HASH_8BYTES], אז טווח כתובות ה-IP של הפודים מוצה.
פתרון בעיות של ניצול יתר של כתובות IP של Pod:
- Resize existing Pod CIDR: הגדלת הטווח של כתובות ה-IP של הפודים הקיימים. אתם יכולים להוסיף לאשכול טווחי כתובות IP של Pods באמצעות CIDR לא רציף של כמה Pods.
- יוצרים רשתות משנה נוספות: מוסיפים רשתות משנה עם כתובות CIDR ייעודיות של Pod לאשכול.
מצמצמים את מספר ה-Pods לכל צומת כדי לפנות כתובות IP:
- יוצרים מאגר צמתים חדש עם מספר מקסימלי קטן יותר של Pods לכל צומת.
- מעבירים את עומסי העבודה למאגר הצמתים הזה, ואז מוחקים את מאגר הצמתים הקודם. הקטנת המספר המקסימלי של יחידות Pod לכל צומת מאפשרת לתמוך ביותר צמתים בטווח קבוע של כתובות IP משניות ליחידות Pod. פרטים על החישובים מופיעים במאמרים טווח משני של כתובות IP של רשתות משנה עבור Pods וטווחים להגבלת צמתים.
מיצוי של כתובות IP של צומת כתובות:
- בודקים את תכנון כתובות ה-IP: מוודאים שטווח כתובות ה-IP של הצומת תואם לדרישות ההתאמה לגודל.
- יוצרים אשכול חדש (אם צריך): אם טווח כתובות ה-IP של הצומת מוגבל מאוד, יוצרים אשכול חלופי עם גודל מתאים של טווח כתובות ה-IP. מידע נוסף זמין במאמרים טווחי כתובות IP לאשכולות מקוריים של VPC ותכנון טווחי כתובות IP.
ניפוי באגים בבעיות שקשורות למיצוי של כתובות IP באמצעות gcpdiag
gcpdiag
הוא כלי בקוד פתוח. הוא לא מוצר נתמך רשמית Cloud de Confiance by S3NS .
אתם יכולים להשתמש בכלי gcpdiag כדי לזהות ולפתור בעיות בפרויקט Cloud de Confiance by S3NS. מידע נוסף זמין בפרויקט gcpdiag ב-GitHub.
- סטטוס האשכול: בדיקת סטטוס האשכול אם דווח על מיצוי של כתובות IP.
- כלי לניתוח רשת: שולח שאילתות ליומנים של כלי ניתוח הרשת ב-Stackdriver כדי לוודא שאין מיצוי של כתובות IP של Pod או של צומת.
- סוג האשכול: בדיקה של סוג האשכול ומתן המלצות רלוונטיות על סמך סוג האשכול.
מסוףCloud de Confiance
- משלימים את הפקודה הבאה ומעתיקים אותה.
- פותחים את המסוף Cloud de Confiance ומפעילים את Cloud Shell. פתיחת מסוף Cloud
- מדביקים את הפקודה שהועתקה.
- מריצים את הפקודה
gcpdiag, שמורידה את קובץ האימג' של Dockergcpdiag, ואז מבצעים בדיקות אבחון. אם רלוונטי, פועלים לפי ההוראות שמופיעות בפלט כדי לתקן את הבדיקות שנכשלו.
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 \Docker
אתם יכולים
להריץ את gcpdiag באמצעות wrapper שמפעיל את gcpdiag בקונטיינר של Docker. צריך להתקין את Docker או את Podman.
- מעתיקים את הפקודה הבאה ומריצים אותה בתחנת העבודה המקומית.
curl https://gcpdiag.dev/gcpdiag.sh >gcpdiag && chmod +x gcpdiag
- מריצים את הפקודה
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 \
כאן אפשר לראות את הפרמטרים הזמינים של חוברת ההוראות הזו.
מחליפים את מה שכתוב בשדות הבאים:
- 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.
אם יש בעיה בתקשורת בין Pod ל-Pod, בודקים את כללי iptables בצמתים כדי לוודא שכללי iptables לא מסווים את טווחי ה-Pod.
מידע נוסף מופיע במאמרי העזרה בנושא הסתרת כתובות IP ב-GKE.
אם לא הגדרתם סוכן הסתרת IP לאשכול, GKE מוודא באופן אוטומטי שהתקשורת בין Pod ל-Pod לא מוסתרת. עם זאת, אם מוגדר סוכן הסתרת IP, הוא מבטל את כללי ברירת המחדל של הסתרת ה-IP. צריך לוודא שכללים נוספים מוגדרים בסוכן של הסוואת כתובות ה-IP כדי להתעלם מהסוואה של טווחי ה-Pod.
התקשורת ברשת של אשכול עם פרוטוקול כפול לא פועלת כמצופה
- סיבות אפשריות
- כללי חומת האש שנוצרו על ידי אשכול ה-GKE לא כוללים את כתובות ה-IPv6 שהוקצו.
- רזולוציה
- כדי לאמת את כלל חומת האש, פועלים לפי השלבים הבאים:
בודקים את התוכן של כלל חומת האש:
gcloud compute firewall-rules describe FIREWALL_RULE_NAMEמחליפים את
FIREWALL_RULE_NAMEבשם של כלל חומת האש.כל אשכול עם מחסנית כפולה יוצר כלל של חומת אש שמאפשר לצמתים ול-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.
המאמרים הבאים
מידע כללי על אבחון בעיות DNS ב-Kubernetes זמין במאמר בנושא ניפוי באגים ברזולוציית DNS.
אם לא מצאתם פתרון לבעיה במסמכי העזרה, תוכלו לקבל עזרה נוספת בקבלת תמיכה, כולל עצות בנושאים הבאים:
- פתיחת בקשת תמיכה באמצעות פנייה אל Cloud Customer Care.
- קבלת תמיכה מהקהילה על ידי פרסום שאלות ב-StackOverflow ושימוש בתג
google-kubernetes-engineכדי לחפש בעיות דומות. אתם יכולים גם להצטרף לערוץ Slack של#kubernetes-engineכדי לקבל תמיכה מהקהילה. - פתיחת דיווחים על בעיות או בקשות למאפיינים חדשים באמצעות הכלי הציבורי Issue Tracker.