פתרון בעיות ופעולות ב-Multi Cluster Ingress

טייס אוטומטי רגילה

הגדרות שגויות ב-Multi Cluster Ingress או במשאבי Compute Engine הבסיסיים שלו עלולות לגרום לבעיות באיזון העומסים בין האשכולות, כמו ניתוב שגוי של תעבורת נתונים, כתובות IP וירטואליות (VIP) חסרות או שגיאות בשירות 502.

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

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

הסבר על מיפוי משאבים של Multi Cluster Ingress

ה-GKE Enterprise Ingress controller מנהל משאבים של Compute Engine. המשאבים MultiClusterIngress ו-MultiClusterService ממופים למשאבים שונים ב-Compute Engine, ולכן חשוב להבין את הקשר בין המשאבים האלה כדי לפתור בעיות. לדוגמה, בודקים את המשאב MultiClusterIngress הבא:

apiVersion: extensions/v1beta1
kind: MultiClusterIngress
metadata:
  name: foo-ingress
spec:
  template:
    spec:
      rules:
      - host: store.foo.com
        http:
          paths:
          - backend:
              serviceName: store-foo
              servicePort: 80
      - host: search.foo.com
        http:
          paths:
          - backend:
              serviceName: search-foo
              servicePort: 80

מיפויים של משאבי Compute Engine למשאבי Multi Cluster Ingress

בטבלה הבאה מוצג מיפוי של משאבים בצי למשאבים שנוצרו באשכולות Kubernetes וב- Google Cloud:

משאב Kubernetes	משאבGoogle Cloud	תיאור
MultiClusterIngress	כלל העברה	כתובת ה-VIP של מאזן העומסים מסוג HTTP(S).
	שרת proxy יעד	הגדרות סיום HTTP/S נלקחות מההערות ומבלוק ה-TLS.
	מפה של כתובות URL	מיפוי נתיב של מארח וירטואלי מהקטע 'כללים'.
MultiClusterService	Kubernetes Service	משאב שנוצר מתבנית.
	שירות לקצה העורפי	שירות לקצה העורפי נוצר לכל זוג (Service, ServicePort).
	קבוצות של נקודות קצה ברשת	קבוצה של Pods בשרת העורפי שמשתתפים בשירות.

בדיקת משאבים של מאזן עומסים ב-Compute Engine

אחרי שיוצרים מאזן עומסים, הסטטוס של Multi Cluster Ingress יכלול את השמות של כל משאבי Compute Engine שנוצרו כדי לבנות את מאזן העומסים. לדוגמה:

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
  CloudResources:
    Firewalls: "mci-l7"
    ForwardingRules: "mci-abcdef-myforwardingrule"
    TargetProxies: "mci-abcdef-mytargetproxy"
    UrlMap: "mci-abcdef-myurlmap"
    HealthChecks: "mci-abcdef-80-myhealthcheck"
    BackendServices: "mci-abcdef-80-mybackendservice"
    NetworkEndpointGroups: "k8s1-neg1", "k8s1-neg2", "k8s1-neg3"

לא נוצר VIP

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

kubectl describe mci shopping-service

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

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
Events:
  Type     Reason  Age   From                              Message
  ----     ------  ----  ----                              -------
  Warning  SYNC    29s   multi-cluster-ingress-controller  error translating MCI prod/shopping-service: exceeded 4 retries with final error: error translating MCI prod/shopping-service: multiclusterservice prod/shopping-service does not exist

בדוגמה הזו, השגיאה הייתה שהמשתמש לא יצר משאב MultiClusterService שהופנה על ידי MultiClusterIngress.

תגובה 502

אם מאזן העומסים קיבל כתובת VIP אבל הוא מחזיר באופן עקבי תגובה 502, יכול להיות שבדיקות תקינות של מאזן העומסים נכשלות. בדיקות התקינות עלולות להיכשל משתי סיבות:

1. תקינות הפודים של האפליקציה לא תקינה (לדוגמה, אפשר לראות ניפוי באגים במסוף Cloud).
2. חומת אש שהוגדרה בצורה שגויה חוסמת את בודקי התקינות של Google ומפריעה להם לבצע בדיקות תקינות.

במקרה מספר 1, צריך לוודא שהאפליקציה באמת מציגה תגובה 200 בנתיב '/'.

במקרה של #2, צריך לוודא שקיימת חומת אש בשם mci-default-l7 ב-VPC. בקר התעבורה הנכנסת (ingress) יוצר את חומת האש ב-VPC כדי לוודא שכלי הבדיקה של Google יכולים להגיע לשרתים העורפיים (backend) שלכם. אם חומת האש לא קיימת, צריך לוודא שאין אוטומציה חיצונית שמוחקת את חומת האש הזו כשהיא נוצרת.

תנועה שלא נוספה לאשכול או הוסרה ממנו

כשמוסיפים חברות חדשה, התנועה צריכה להגיע לשרתי הקצה בענן (backend) באשכול הבסיסי, כשזה רלוונטי. באופן דומה, אם מסירים חברות, לא אמור להגיע תנועה לשרתי הקצה בעורף בקלאסטר הבסיסי. אם לא נתקלתם בהתנהגות הזו, כדאי לבדוק אם יש שגיאות במשאב MultiClusterIngress ובמשאב MultiClusterService.

מקרים נפוצים שבהם השגיאה הזו מתרחשת כוללים הוספה של חברות חדשה באשכול GKE שלא נמצא במצב VPC-native או הוספה של חברות חדשה בלי לפרוס אפליקציה באשכול GKE.

1. מתארים את הMultiClusterService:

   kubectl describe mcs zone-svc
   

2. מתארים את הMultiClusterIngress:

   kubectl describe mci zone-mci
   

העברת אשכול הגדרות

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

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

1. חשוב להשתמש בהערה static-ip במשאבי MultiClusterIngress. אם לא תעשו את זה, יהיו שיבושים בתנועת הגולשים במהלך ההעברה. כתובות IP זמניות ייווצרו מחדש כשמעבירים אשכולות של הגדרות.
2. צריך לפרוס את המשאבים MultiClusterIngress ו-MultiClusterService באופן זהה לאשכול התצורה הקיים ולזה החדש. אם יש הבדלים בין המשאבים, הם יתוקנו במשאבים MultiClusterService ו-MultiClusterIngress ששונים באשכול התצורה החדש.
3. בכל רגע נתון פעיל רק אשכול תצורה אחד. עד שמשנים את אשכול ההגדרות, המשאבים MultiClusterIngress ו-MultiClusterService באשכול ההגדרות החדש לא משפיעים על משאבי איזון העומסים.

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

  gcloud container fleet ingress update \
    --config-membership=projects/project_id/locations/global/memberships/new_config_cluster

כדי לוודא שהפקודה פעלה, בודקים שאין שגיאות גלויות בקטע Feature state:

  gcloud container fleet ingress describe

ניפוי באגים במסוף

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

קודי שגיאה או אזהרה

‫Multi Cluster Ingress פולט קודי שגיאה ואזהרה במשאבי MultiClusterIngress ו-MultiClusterService, וגם בשדה התיאור של gcloud multiclusteringress, לגבי בעיות ידועות. בהודעות האלה יש קודי שגיאה ואזהרה מתועדים, כדי שיהיה קל יותר להבין מה קורה כשמשהו לא פועל כצפוי. כל קוד מורכב ממזהה שגיאה בפורמט AVMBR123 כאשר 123 הוא מספר ייחודי שמתאים לשגיאה או לאזהרה, והצעות לפתרון.

AVMBR101: Annotation [NAME] not recognized

השגיאה הזו מוצגת כשמציינים הערה במניפסט MultiClusterIngress או MultiClusterService שלא מזוהה. יכולות להיות כמה סיבות לכך שההערה לא מזוהה:

1. ההערה לא נתמכת ב-Multi Cluster Ingress. יכול להיות שזה צפוי אם מוסיפים הערות למשאבים שלא אמורים לשמש את בקר ה-Ingress של GKE Enterprise.

2. ההערה נתמכת, אבל יש בה שגיאת כתיב ולכן היא לא מזוהה.

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

AVMBR102: [RESOURCE_NAME] not found

השגיאה הזו מוצגת כשמציינים משאב משלים ב-MultiClusterIngress אבל אי אפשר למצוא אותו ב-Config Membership. לדוגמה, השגיאה הזו מופיעה כש-MultiClusterIngress מפנה אל MultiClusterService שלא ניתן למצוא, או כש-MultiClusterService מפנה אל BackendConfig שלא ניתן למצוא. יכולות להיות כמה סיבות לכך שלא נמצא משאב:

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

AVMBR103: [CLUSTER_SELECTOR] is invalid

השגיאה הזו מוצגת כשבורר אשכולות שצוין בתג MultiClusterService לא תקין. יכול להיות שהסלקטור הזה לא תקין בגלל כמה סיבות:

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

AVMBR104: Cannot find NEGs for Service Port [SERVICE_PORT]

השגיאה הזו מתרחשת כשלא ניתן למצוא את קבוצות נקודות הקצה ברשת (NEGs) עבור זוג נתון של MultiClusterService ויציאת שירות. קבוצות NEG הן המשאבים שמכילים את נקודות הקצה של ה-Pod בכל אחד מהאשכולות של השרת העורפי. הסיבה העיקרית לכך שקבוצות ה-NEG לא קיימות היא שהייתה שגיאה ביצירה או בעדכון של שירותים נגזרים באשכולות העורפיים. מידע נוסף מופיע באירועים במשאב MultiClusterService.

AVMBR105: Missing GKE Enterprise license.

השגיאה הזו מוצגת בקטע 'מצב התכונה', והיא מציינת ש-GKE Enterprise API ‏(anthos.googleapis.com) לא מופעל.

‫AVMBR106: Derived service is invalid: [REASON].

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

לדוגמה, ל-MultiClusterService הזה לא מוגדרים ServicePort במפרט שלו.

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: zone-mcs
  namespace: whereami
spec:
  clusters:
  - link: "us-central1-a/gke-us"
  - link: "europe-west1-c/gke-eu"

AVMBR107: Missing GKE cluster resource link in Membership.

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

gcloud container fleet memberships describe membership-name

ולוודא שאין קישור למשאב של אשכול GKE בשדה של נקודת הקצה.

AVMBR108: GKE cluster [NAME] not found.

השגיאה הזו מוצגת בקטע 'מצב התכונה' ומופיעה אם אשכול GKE הבסיסי של המינוי לא קיים.

AVMBR109: [NAME] is not a VPC-native GKE cluster.

השגיאה הזו מוצגת בקטע 'מצב התכונה'. השגיאה הזו מופיעה אם אשכול GKE שצוין הוא אשכול מבוסס-נתיבים. בקר Multi Cluster Ingress יוצר מאזן עומסים ברמת הקונטיינר באמצעות NEGs. כדי להשתמש במאזן עומסים שמקורו בקונטיינר, האשכולות צריכים להיות מקוריים ל-VPC.

מידע נוסף זמין במאמר בנושא יצירת אשכול המותאם ל-VPC.

AVMBR110: [IAM_PERMISSION] permission missing for GKE cluster [NAME].

השגיאה הזו מוצגת בקטע 'מצב התכונה'. יש כמה סיבות לשגיאה הזו:

1. אשכול GKE הבסיסי של המינוי ממוקם בפרויקט אחר מהמינוי עצמו.
2. ההרשאה שצוינה ב-IAM הוסרה מסוכן השירות MultiClusterIngress.

AVMBR111: Failed to get Config Membership: [REASON].

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

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

AVMBR112: HTTPLoadBalancing Addon is disabled in GKE Cluster [NAME].

השגיאה הזו מוצגת בקטע 'מצב התכונה' ומתרחשת כשתוסף HTTPLoadBalancing מושבת באשכול GKE. אפשר לעדכן את אשכול GKE כדי להפעיל את התוסף HTTPLoadBalancing:

gcloud container clusters update name --update-addons=HttpLoadBalancing=ENABLED

AVMBR113: This resource is orphaned.

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

הערה: השגיאה הזו מתקבלת גם כתוצאה מבעיה מוכרת שבה Multi Cluster Ingress לא מזהה מתי נעשה שימוש ב-BackendConfig על ידי Ingress, אבל לא על ידי Multi Cluster Ingress.