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

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

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

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

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

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

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

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

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

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

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

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

תסמינים

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

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

מחקתם בטעות את חיבור ה-VPC Network Peering.

פתרון

  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 ועמדתם בדרישות הרשת שלה. Cloud de Confiance

רזולוציה

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

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

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

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

כשל ביצירת ווּבּהוּקים חיצוניים חדשים

השגיאה הבאה מתקבלת כשמנסים ליצור ValidatingWebhookConfigurations או MutatingWebhookConfigurations שמשתמשים בשדה clientConfig.url כדי ליצור קשר עם שרת webhook שנמצא מחוץ לאשכול:

ValidatingAdmissionPolicy 'gke-restrict-webhook-url' denied request: Egress
traffic from the API server through the control plane is disabled. As a result,
direct API server calls to external webhook servers are blocked. To connect to
external webhooks, update any webhook configurations that use clientConfig.url
to use clientConfig.service instead.

השגיאה הזו מתרחשת אם הגדרת האשכול מונעת תנועת יציאה ישירה משרת ה-API של Kubernetes על ידי השבתת כתובות ה-IP החיצוניות של מכונות וירטואליות של מישורי הבקרה. ‫GKE משתמש ב-ValidatingAdmissionPolicy כדי למנוע יצירה של הגדרות webhook או עדכונים שלהן שמשתמשים בשדה clientConfig.url.

כדי לזהות את הגורם לשגיאה הזו, צריך לתאר את הגדרות האשכול:

gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format='value(controlPlaneEgress)'

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

  • ‫CLUSTER_NAME: השם של האשכול.
  • ‫CONTROL_PLANE_LOCATION: האזור או האזור שבו נמצא האשכול, למשל us-central1 או us-central1-a.

אם התנועה היוצאת משרת ה-API מושבתת, הפלט הוא NONE.

כדי לפתור את השגיאה הזו, צריך לעדכן את הגדרות ה-webhook כך שישתמשו בשדה clientConfig.service. השדה הזה מאפשר לשרת ה-API לשלוח בקשות גישה לשירות באשכול במקום לשלוח תעבורה לכתובת IP או לכתובת URL. מידע נוסף על הגדרת תגובות לפעולה מאתר אחר (webhook) ושירות זמין במאמר הגדרת תגובות לפעולה מאתר אחר (webhook) חיצוני.

אם תמחקו את ValidatingAdmissionPolicy, בקשת היצירה או העדכון של ה-webhook תצליח, אבל בקשות הגישה לשרת ה-webhook ייכשלו.

כשלים בבקשות חיצוניות של webhook להרשאה

השגיאה הבאה מתרחשת כשמנסים לפרוס משאבי Kubernetes שמפעילים שרתי webhook של הרשאות כניסה מחוץ לרשת ה-VPC של האשכול:

Error from server (InternalError): error when creating "STDIN": Internal error occurred: failed calling webhook WEBHOOK_NAME": failed to call webhook: Post "WEBHOOK_URL": proxyconnect tcp: dial tcp: lookup master-internet-access-unavailable.localhost on 169.254.169.254:53: no such host

השגיאה הזו מתרחשת אם כל התנאים הבאים מתקיימים:

  • ההגדרה של ה-webhook משתמשת בכתובת IP או בכתובת URL כדי ליצור קשר עם שרת ה-webhook החיצוני.
  • הגדרת האשכול מונעת תעבורת נתונים יוצאת ישירה משרת ה-API של Kubernetes על ידי השבתת כתובות ה-IP החיצוניות של המכונות הווירטואליות של מישור הבקרה.

כדי לזהות את הגורם לשגיאה הזו, צריך לתאר את הגדרות האשכול:

gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --format='value(controlPlaneEgress)'

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

  • ‫CLUSTER_NAME: השם של האשכול.
  • ‫CONTROL_PLANE_LOCATION: האזור או האזור שבו נמצא האשכול, למשל us-central1 או us-central1-a.

אם התנועה היוצאת משרת ה-API מושבתת, הפלט הוא NONE.

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

  1. מזהים ב-cluster את כל ValidatingWebhookConfigurations או MutatingWebhookConfigurations שמשתמשים בשדה clientConfig.url.
  2. צריך לעדכן את ההגדרות של ה-webhook כדי להשתמש בשדה clientConfig.service. השדה הזה מאפשר לשרת ה-API לשלוח בקשות גישה לשירות באשכול במקום לשלוח תעבורה לכתובת IP או לכתובת URL. מידע נוסף על הגדרת התגובות לפעולות מאתר אחר (webhook) והשירות זמין במאמר הגדרת תגובות לפעולות מאתר אחר (webhook) חיצוני.

בקשת 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 לא יכולים לגשת לאינטרנט

ל-Pods שפועלים בצמתים עם כתובות 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 שומר על נקודת הקצה כבלתי נראית, ולא ניתן לראות אותה במסוףCloud de Confiance או ב-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
סיבות אפשריות

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

רזולוציה

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

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

    • הדגל master-ipv4-cidr הוצא משימוש במסוף Cloud de Confiance . כדי לעדכן את הדגל הזה, אפשר להשתמש רק ב-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 ולשירותים של Google Cloud בלי שיהיו להם כתובות 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.

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