פתרון בעיות ופעולות ב-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 מנהל את המשאבים של 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).
	קבוצות של נקודות קצה ברשת	קבוצה של פודים בקצה העורפי שמשתתפים בשירות.

בדיקת משאבים של מאזן עומסים ב-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. ה-Pods של האפליקציה לא תקינים (לדוגמה, אפשר לראות ניפוי באגים במסוף Cloud).
2. חומת אש שהוגדרה בצורה שגויה חוסמת את בודקי התקינות של Google ומפריעה להם לבצע בדיקות תקינות.

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

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

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

כשמוסיפים חברות חדשה, התנועה צריכה להגיע לשרתי הקצה בענן במקרים הרלוונטיים. באופן דומה, אם מסירים חברות, לא אמור להגיע תעבורה לשרתי הקצה באשכול הבסיסי. אם לא נתקלתם בהתנהגות הזו, כדאי לבדוק אם יש שגיאות במשאב 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

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

  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. יכול להיות שזה צפוי אם מוסיפים הערות למשאבים שלא אמורים לשמש את בקר הכניסה של 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. המחרוזת שסופקה מתייחסת לחברות באשכול שכבר לא קיים ב-Fleet.

AVMBR104: Cannot find NEGs for Service Port [SERVICE_PORT]

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

AVMBR105: Missing GKE Enterprise license.

השגיאה הזו מוצגת בקטע Feature state (מצב התכונה), והיא מציינת ש-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.

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

gcloud container fleet memberships describe membership-name

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

AVMBR108: GKE cluster [NAME] not found.

השגיאה הזו מוצגת בקטע Feature state (מצב התכונה) ומופיעה אם אשכול 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].

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

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

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.