פתרון בעיות שקשורות לבידוד רשת ב-GKE

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

המסמך הזה מספק הנחיות לפתרון בעיות כמו גישה למישור הבקרה, חפיפות בטווח כתובות ה-CIDR, שגיאות בשליפת תמונות ממאגרים ציבוריים ובעיות שקשורות לקישור בין רשתות VPC שכנות (peering) או ל-Private Service Connect.

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

אשכול GKE לא פועל

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

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

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

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

  • צריך ליצור אשכולות בגרסה 1.28 או בגרסה מוקדמת יותר באופן סדרתי, כך שיהיו כבר נתיבים של VPC Peering לכל אשכול עוקב ללא נקודת קצה חיצונית. ניסיון ליצור אשכול יחיד עלול לגרום לפסק זמן אם יש פעולות שפועלות ב-VPC.

  • יצירת אשכולות בגרסה 1.29 ואילך.

חיבור קישור בין רשתות VPC שכנות נמחק בטעות

תסמינים

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

error checking if node NODE_NAME is shutdown: unimplemented
סיבות אפשריות

מחקתם בטעות את החיבור של רשתות VPC.

הפתרון

  1. יוצרים אשכול GKE חדש עם גרסה שקדמה למעבר ל-PSC וההגדרות הספציפיות שלו. הפעולה הזו נדרשת כדי לאלץ יצירה מחדש של חיבור ה-VPC, וכך לשחזר את האשכול הישן לפעולה תקינה.
    • משתמשים בהגדרות הספציפיות הבאות עבור האשכול החדש:
      • ערוץ הפצה: מורחב
      • גרסת האשכול: גרסה מוקדמת יותר מ-1.29, כמו 1.28.15-gke.2403000
      • Master IPv4 CIDR: טווח כתובות IP ספציפי, כמו --master-ipv4-cidr=172.16.0.192/28
  2. עוקבים אחרי הסטטוס של האשכול המקורי.
    • אחרי שנוצר האשכול החדש (וכך נוצר מחדש ה-VPC peering), האשכול המקורי אמור לצאת ממצב התיקון, והצמתים שלו אמורים לחזור לסטטוס Ready.
  3. מוחקים את אשכול ה-GKE שנוצר באופן זמני.
    • אחרי שהאשכול המקורי ישוחזר במלואו ויפעל כרגיל, תוכלו למחוק את אשכול GKE שנוצר באופן זמני.

נקודת קצה וכלל העברה של Private Service Connect נמחקו בטעות

תסמינים

אם מוחקים בטעות נקודת קצה או כלל העברה של Private Service Connect, האשכול עובר למצב תיקון וכל הצמתים מציגים סטטוס UNKNOWN. לא תוכלו לבצע פעולות באשכול כי הגישה למישור הבקרה מנותקת. כשבודקים את מישור הבקרה, ביומנים מוצגת שגיאה שדומה לשגיאה הבאה:

error checking if node NODE_NAME is shutdown: unimplemented
סיבות אפשריות

מחקתם בטעות את נקודת הקצה של Private Service Connect או את כלל ההעברה. לשני המשאבים קוראים gke-[cluster-name]-[cluster-hash:8]-[uuid:8]-pe והם מאפשרים למישור הבקרה ולצמתים להתחבר באופן פרטי.

רזולוציה

החלפת כתובת ה-IP של מישור הבקרה

חפיפה בין אשכולות לבין עמית פעיל

תסמינים

ניסיון ליצור אשכול ללא נקודת קצה חיצונית מחזיר שגיאה שדומה לזו:

Google Compute Engine: An IP range in the peer network overlaps with an IP
range in an active peer of the local network.
סיבות אפשריות

בחרתם CIDR של מישור בקרה חופף.

רזולוציה

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

  • מוחקים את האשכול ויוצרים אותו מחדש באמצעות CIDR אחר של מישור הבקרה.
  • יוצרים מחדש את האשכול בגרסה 1.29 וכוללים את הדגל --enable-private-nodes.

אי אפשר להגיע למישור הבקרה של אשכול ללא נקודת קצה חיצונית

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

תסמינים

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

Unable to connect to the server: dial tcp [IP_ADDRESS]: connect: connection
timed out.

Unable to connect to the server: dial tcp [IP_ADDRESS]: i/o timeout.
סיבות אפשריות

ל-kubectl אין אפשרות לתקשר עם מישור הבקרה של האשכול.

רזולוציה

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

  • הפעלת גישת DNS מאפשרת גישה מאובטחת לאשכול בצורה פשוטה יותר. מידע נוסף זמין במאמר בנושא נקודת קצה (endpoint) מבוססת DNS.

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

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

    1. מוודאים שכתובת ה-IP של המקור מורשית להגיע למישור הבקרה:

        gcloud container clusters describe CLUSTER_NAME \
      --format="value(controlPlaneEndpointsConfig.ipEndpointsConfig.authorizedNetworksConfig)"\
      --location=COMPUTE_LOCATION

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

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

      cidrBlocks:
  cidrBlock: 10.XXX.X.XX/32
  displayName: jumphost
  cidrBlock: 35.XXX.XXX.XX/32
  displayName: cloud shell
enabled: true

    2. הוספת רשתות מורשות לגישה למישור הבקרה.

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

    1. כדי לראות את התגובה של הגדרת בקרת הגישה, מתארים את האשכול:

      gcloud container clusters describe CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --flatten "controlPlaneEndpointsConfig.ipEndpointsConfig.globalAccess"

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

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

        enabled: true

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

אי אפשר ליצור אשכול בגלל חפיפה בבלוק IPv4 CIDR

תסמינים

הפונקציה gcloud container clusters create מחזירה שגיאה שדומה לזו:

The given master_ipv4_cidr 10.128.0.0/28 overlaps with an existing network
10.128.0.0/20.
סיבות אפשריות

ציינתם בלוק CIDR של מישור הבקרה שחופף לתת-רשת קיימת ב-VPC.

רזולוציה

מציינים בלוק CIDR עבור --master-ipv4-cidr שלא חופף לרשת משנה קיימת.

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

תסמינים

ניסיון ליצור אשכול מחזיר שגיאה שדומה לזו:

Services range [ALIAS_IP_RANGE] in network [VPC_NETWORK], subnetwork
[SUBNET_NAME] is already used by another cluster.
סיבות אפשריות

הגדרות אפשריות שגורמות לשגיאה הזו:

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

איך לעשות את זה?

  1. בודקים אם טווח השירותים נמצא בשימוש על ידי אשכול קיים. אפשר להשתמש בפקודה gcloud container clusters list עם הדגל filter כדי לחפש את האשכול. אם יש אשכול קיים שמשתמש בטווח השירותים, צריך למחוק את האשכול הזה או ליצור טווח שירותים חדש.
  2. אם טווח השירותים לא נמצא בשימוש על ידי אשכול קיים, צריך להסיר את רשומת המטא-נתונים באופן ידני שתואמת לטווח השירותים שרוצים להשתמש בו.

אי אפשר ליצור רשת משנה

תסמינים

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

An IP range in the peer network overlaps
with an IP range in one of the active peers of the local network.

Error: Error waiting for creating GKE cluster: Invalid value for field
PrivateClusterConfig.MasterIpv4CidrBlock: x.x.x.x/28 conflicts with an
existing subnet in one of the peered VPCs.
סיבות אפשריות

טווח ה-CIDR של מישור הבקרה שציינתם חופף לטווח IP אחר באשכול. שגיאה ביצירת רשת משנה יכולה להתרחש גם אם מנסים לעשות שימוש חוזר ב-CIDR master-ipv4-cidr ששימש באשכול שנמחק לאחרונה.

רזולוציה

אפשר לנסות להשתמש בטווח CIDR אחר.

אי אפשר למשוך תמונה מ-Docker Hub ציבורי

תסמינים

מוד של Pod שפועל באשכול מציג אזהרה ב-kubectl describe:

Failed to pull image: rpc error: code = Unknown desc = Error response
from daemon: Get https://registry-1.docker.io/v2/: net/http: request canceled
while waiting for connection (Client.Timeout exceeded while awaiting
headers)
סיבות אפשריות

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

רזולוציה

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

  • מעתיקים את התמונות באשכול מ-Docker Hub אל Artifact Registry. מידע נוסף זמין במאמר בנושא העברת מאגרי תמונות ממאגר צד שלישי.

  • ‫GKE בודק אוטומטית את mirror.gcr.io כדי למצוא עותקים במטמון של תמונות Docker Hub שמתבצעת אליהן גישה לעיתים קרובות.

  • אם אתם חייבים לשלוף תמונות מ-Docker Hub או ממאגר ציבורי אחר, השתמשו ב-Cloud NAT או בפרוקסי מבוסס-אינסטנס שהוא היעד של מסלול סטטי 0.0.0.0/0.

בקשת API שמפעילה פסק זמן של webhook של הרשאת גישה

תסמינים

בקשת API שמפעילה webhook של אישור בקשות שהוגדר לשימוש בשירות עם יציאה targetPort שאינה 443, מובילה לפסק זמן שגורם לכשל בבקשה:

Error from server (Timeout): request did not complete within requested timeout 30s
סיבות אפשריות

כברירת מחדל, חומת האש לא מאפשרת חיבורי TCP לצמתים, למעט ביציאות 443 ‏ (HTTPS) ו-10250 ‏ (kubelet). ניסיון של webhook של אישור גישה לתקשר עם Pod ביציאה שאינה 443 ייכשל אם אין כלל חומת אש בהתאמה אישית שמאפשר את התנועה.

רזולוציה

מוסיפים כלל לחומת האש לתרחיש השימוש הספציפי.

אי אפשר ליצור אשכול בגלל שכשל בבדיקת תקינות

תסמינים

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

All cluster resources were brought up, but only 0 of 2 have registered.

All cluster resources were brought up, but: 3 nodes out of 4 are unhealthy
סיבות אפשריות

הגדרות אפשריות שגורמות לשגיאה הזו:

  • לא ניתן להוריד צורפים בינאריים נדרשים מצומתי אשכול מ-Cloud Storage API (storage.googleapis.com).
  • כללי חומת אש שמגבילים תעבורת נתונים יוצאת (egress).
  • ההרשאות ב-IAM של ה-VPC המשותף שגויות.
  • כדי להשתמש בגישה פרטית ל-Google, צריך להגדיר DNS ל-*.gcr.io.
רזולוציה

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

‫kubelet: יצירת ארגז חול של פוד נכשלה

תסמינים

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

Warning  FailedCreatePodSandBox  12s (x9 over 4m)      kubelet  Failed to create pod sandbox: rpc error: code = Unknown desc = Error response from daemon: Get https://registry.k8s.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized
סיבות אפשריות

ל-calico-node או ל-netd Pod אין גישה ל-*.gcr.io.

רזולוציה

חשוב לוודא שהשלמתם את ההגדרה הנדרשת של Container Registry או Artifact Registry.

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

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

  • ‎*.googleapis.com
  • *.gcr.io
  • gcr.io

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

עומסי עבודה באשכולות GKE לא יכולים לגשת לאינטרנט

לפודים שפועלים בצמתים עם כתובות IP פרטיות אין גישה לאינטרנט. לדוגמה, אחרי שמריצים את הפקודה apt update מה-Pod exec shell, מוצגת שגיאה דומה לזו:

0% [Connecting to deb.debian.org (199.232.98.132)] [Connecting to security.debian.org (151.101.130.132)]

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

חשוב להגדיר את שער Cloud NAT כך שיחולו לפחות טווחי כתובות ה-IP של רשתות המשנה הבאות על רשת המשנה שבה נעשה שימוש באשכול:

  • טווח כתובות ה-IP הראשי של רשת המשנה (בשימוש הצמתים)
  • טווח כתובות ה-IP המשני של תת-הרשת שמשמש ל-Pods באשכול
  • טווח כתובות ה-IP המשניות של תת-הרשת שמשמש לשירותים באשכול

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

אי אפשר להשבית גישה ישירה לכתובות IP באשכולות ציבוריים

תסמינים

אחרי השבתת נקודת הקצה של כתובת ה-IP, מוצגת הודעת שגיאה שדומה להודעה הבאה:

Direct IP access can't be disabled for public clusters
סיבות אפשריות

האשכול שלך משתמש ברשת מדור קודם.

רזולוציה

מעבירים את האשכולות ל-Private Service Connect. לקבלת מידע נוסף על סטטוס ההעברה, אפשר לפנות לתמיכה .

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

תסמינים

אחרי השבתת נקודת הקצה של כתובת ה-IP, מוצגת הודעת שגיאה שדומה להודעה הבאה:

Direct IP access can't be disabled for public clusters
סיבות אפשריות

האשכול שלך משתמש ברשת מדור קודם.

רזולוציה

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

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

אי אפשר להפעיל את נקודת הקצה הפנימית של מישור הבקרה

תסמינים

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

private_endpoint_enforcement_enabled can't be enabled when envoy is disabled

private_endpoint_enforcement_enabled is unsupported. Please upgrade to the minimum support version
סיבות אפשריות

האשכול צריך לבצע רוטציה של כתובות IP או עדכון גרסה.

רזולוציה

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

יצירת האשכול נכשלת כשהוגדרו מדיניות ארגונית

תסמינים

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

compute.disablePrivateServiceConnectCreationForConsumers violated for projects
סיבות אפשריות

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

רזולוציה

כדי לאפשר למופעים ליצור נקודות קצה עם האילוץ compute.restrictPrivateServiceConnectProducer, צריך לבצע את השלבים במאמר מדיניות ארגון בצד הצרכן.

יכול להיות שנקודת הקצה של Private Service Connect תדלוף במהלך מחיקת האשכול

תסמינים

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

  • אתם לא רואים נקודת קצה מחוברת בקטע Private Service Connect באשכול שמבוסס על Private Service Connect.

  • אי אפשר למחוק את רשת המשנה או את רשת ה-VPC שהוקצו לנקודת הקצה הפנימית באשכול שמשתמש ב-Private Service Connect. מוצגת הודעת שגיאה דומה לזו:

    projects/<PROJECT_ID>/regions/<REGION>/subnetworks/<SUBNET_NAME> is already being used by projects/<PROJECT_ID>/regions/<REGION>/addresses/gk3-<ID>
סיבות אפשריות

באשכולות GKE שמשתמשים ב-Private Service Connect, ‏ GKE פורס נקודת קצה של Private Service Connect באמצעות כלל העברה שמקצה כתובת IP פנימית לגישה למישור הבקרה של האשכול ברשת של מישור הבקרה. כדי להגן על התקשורת בין מישור הבקרה לבין הצמתים באמצעות Private Service Connect,‏ GKE שומר על נקודת הקצה כבלתי נראית, ולא ניתן לראות אותה במסוףGoogle Cloud או ב-CLI של gcloud.

רזולוציה

כדי למנוע חשיפה של נקודת הקצה של Private Service Connect לפני מחיקת האשכול, צריך לבצע את השלבים הבאים:

  1. מקצים את התפקיד Kubernetes Engine Service Agent role לחשבון השירות של GKE.
  2. מוודאים שההרשאות compute.forwardingRules.* ו-compute.addresses.* לא נדחות באופן מפורש מחשבון השירות של GKE.

אם אתם רואים שנקודת הקצה של Private Service Connect דלפה, פנו לתמיכה .

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

תסמינים

אי אפשר ליצור אשכול בגרסה 1.29 ואילך. מוצגת הודעת שגיאה דומה לזו:

Unable to parse cluster.master_ipv4_cidr "" into a valid IP address and mask
סיבות אפשריות

בפרויקט Google Cloud שלכם נעשה שימוש ב-webhook מבוסס-IP פרטי. לכן, אי אפשר ליצור אשכול עם Private Service Connect. במקום זאת, האשכול משתמש בקישור בין רשתות VPC שכנות (peering) שמנתח את האפשרות master-ipv4-cidr.

רזולוציה

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

  • ממשיכים ליצור את אשכול ה-VPC Network Peering וכוללים את master-ipv4-cidr כדי להגדיר CIDR תקין. הפתרון הזה כולל את המגבלות הבאות:

    • הדגל master-ipv4-cidr יצא משימוש במסוף Google Cloud . כדי לעדכן את הדגל הזה, אפשר להשתמש רק ב-Google Cloud CLI או ב-Terraform.
    • התכונה 'קישור בין רשתות VPC שכנות (peering)' הוצאה משימוש ב-GKE בגרסה 1.29 ואילך.

  • כדי להעביר את ה-webhook שמבוסס על כתובת IP פרטית, צריך לבצע את השלבים שמפורטים במאמר מגבלות של Private Service Connect. לאחר מכן, פונים לתמיכה כדי להצטרף לשימוש באשכולות עם Private Service Connect.

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

תסמינים

אי אפשר להגדיר טווח כתובות IP פנימיות באמצעות הדגל --master-ipv4-cidr. מוצגת הודעת שגיאה דומה לזו:

ERROR: (gcloud.container.clusters.create) Cannot specify --master-ipv4-cidr
  without --enable-private-nodes
סיבות אפשריות

אתם מגדירים טווח כתובות IP פנימיות עבור מישור הבקרה באמצעות הדגל master-ipv4-cidr באשכול ללא הדגל enable-private-nodes. כדי ליצור אשכול עם master-ipv4-cidr מוגדר, צריך להגדיר את האשכול כך שיוקצו לו צמתים עם כתובות IP פנימיות (צמתים פרטיים) באמצעות הדגל enable-private-nodes.

רזולוציה

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

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

    gcloud container clusters create-auto CLUSTER_NAME \
    --enable-private-nodes \
    --master-ipv4-cidr CP_IP_RANGE

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

    • ‫CLUSTER_NAME: השם של האשכול.
    • ‫CLUSTER_NAME: טווח כתובות ה-IP הפנימיות של מישור הבקרה.

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

אי אפשר לתזמן עומסי עבודה ציבוריים באשכולות של Autopilot

תסמינים
באשכולות במצב Autopilot, אם האשכול משתמש רק בצמתים פרטיים, אי אפשר לתזמן עומסי עבודה בתרמילי Pod ציבוריים באמצעות cloud.google.com/private-node=falsenodeSelector
.
סיבות אפשריות
ההגדרה של הדגל private-node שמוגדר כ-false ב-nodeSelector של ה-Pod זמינה רק באשכולות בגרסה 1.30.3 ואילך.
רזולוציה
משדרגים את האשכול לגרסה 1.30 ואילך.

הגישה לנקודת הקצה (endpoint) שמבוססת על DNS מושבתת

תסמינים

ניסיון להריץ פקודות kubectl מול האשכול מחזיר שגיאה דומה לזו:

couldn't get current server API group list:
control_plane_endpoints_config.dns_endpoint_config.allow_external_traffic is
disabled
סיבות אפשריות

הגישה על בסיס DNS הושבתה באשכול שלכם.

רזולוציה

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

הקצאת כתובת IP לצמתים נכשלת במהלך שינוי קנה מידה

תסמינים

ניסיון להרחיב את טווח כתובות ה-IP הראשיות של רשת המשנה לרשימת הרשתות המורשות מחזיר שגיאה שדומה לזו:

 authorized networks fields cannot be mutated if direct IP access is disabled
סיבות אפשריות

השבתת את נקודת הקצה מבוססת ה-IP של האשכול.

רזולוציה

משביתים ומפעילים את נקודת הקצה מבוססת ה-IP של האשכול באמצעות הדגל enable-ip-access.

יש יותר מדי חסימות CIDR

‫gcloud מחזירה את השגיאה הבאה כשמנסים ליצור או לעדכן אשכול עם יותר מ-50 בלוקים של CIDR:

ERROR: (gcloud.container.clusters.update) argument --master-authorized-networks: too many args

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:

אין אפשרות להתחבר לשרת

פסק זמן של kubectl פקודות בגלל בלוקים של CIDR שהוגדרו בצורה שגויה:

Unable to connect to the server: dial tcp MASTER_IP: getsockopt: connection timed out

כשיוצרים או מעדכנים אשכול, חשוב לוודא שמציינים את בלוקי ה-CIDR הנכונים.

לצמתים יש גישה לתמונות של קונטיינרים ציבוריים למרות הבידוד ברשת

תסמינים

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

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

סיבות אפשריות

ההתנהגות הזו מתרחשת בגלל שתי תכונות שפועלות יחד:

  • גישה פרטית ל-Google: התכונה הזו מאפשרת לצמתים עם כתובות IP פנימיות להתחבר לממשקי Google Cloud API ולשירותים בלי צורך בכתובות IP ציבוריות. הגישה הפרטית ל-Google מופעלת ברשת המשנה של האשכול בתוך ה-VPC שמשמש את הצמתים באשכול. כשיוצרים או מעדכנים אשכול או מאגר צמתים עם הדגל --enable-private-nodes, ‏ GKE מפעיל באופן אוטומטי גישה פרטית ל-Google ברשת המשנה הזו. החריגה היחידה היא אם משתמשים ב-VPC משותף, שבו צריך להפעיל באופן ידני גישה פרטית ל-Google.
  • מאגר התמונות של Google (mirror.gcr.io): כברירת מחדל,‏ GKE מגדיר את הצמתים שלו כך שינסו קודם למשוך תמונות מ-mirror.gcr.io, מאגר Artifact Registry בניהול Google שמבצע קירור של תמונות קונטיינר ציבוריות שמבוקשות לעיתים קרובות.

כשמנסים לשלוף תמונה כמו redis, הצומת משתמש בנתיב הפרטי מ-גישה פרטית ל-Google כדי להתחבר אל mirror.gcr.io. מכיוון שהתמונה redis נפוצה מאוד, היא קיימת במטמון והשליפה מצליחה. עם זאת, אם תבקשו תמונה שלא נמצאת במטמון הציבורי הזה, הפעולה תיכשל כי לצומת המבודד שלכם אין דרך אחרת להגיע למקור המקורי.

רזולוציה

אם תמונה שאתם צריכים לא זמינה במטמון mirror.gcr.io, אתם יכולים לארח אותה במאגר פרטי משלכם ב-Artifact Registry. הצמתים המבודדים ברשת יכולים לגשת למאגר הזה באמצעות גישה פרטית ל-Google.

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