פתרון בעיות בהגדרות

בקטע הזה מוסבר על בעיות נפוצות ב-Cloud Service Mesh ואיך לפתור אותן. לקבלת עזרה נוספת, אפשר לעיין במאמר בנושא קבלת תמיכה.

בדיקת הערך של MembershipState

בכל שלב אפשר לבדוק את הסטטוס העדכני ביותר של הרשת על ידי הרצת הפקודה הבאה:

gcloud container fleet mesh describe

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

...
membershipSpecs:
  projects/project_id/locations/global/memberships/cluster:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/project_id/locations/global/memberships/cluster:
    servicemesh:
      ...
      conditions:
        - code: CONFIG_VALIDATION_WARNING
          documentationLink: https://cloud.google.com/...
          details: Application of one or more configs has failed. Error details are shown on individual config resources. See documentation link for more detail.
          severity: WARNING
...

קודי שגיאה של MembershipState

אם Cloud Service Mesh מדווח על תנאים ל-MembershipState של אשכול, יכול להיות שלא הייתה אפשרות להחיל הגדרות של Mesh (כמו משאבים מותאמים אישית של Istio). בתיאורים הבאים של קודי השגיאה מוסבר איך לטפל בהם.

קוד שגיאה הסיבה רזולוציה
CONFIG_APPLY_INTERNAL_ERROR לא ניתן להחיל הגדרה אחת או יותר בגלל שגיאה פנימית. פנייה לתמיכת הלקוחות.
QUOTA_EXCEEDED_* לא הצלחנו להחיל הגדרה אחת או יותר כי המשאבים הגיעו למגבלת מכסה. במאמר מכסות מוסבר על המכסות הספציפיות ואיך להגדיל אותן.
CONFIG_VALIDATION_ERROR החלת ההגדרות נכשלה באחת או יותר מההגדרות בגלל הגדרה לא תקינה. ב-Istio CRs, ההגדרות הלא תקינות מושמטות לחלוטין מהתרגום. שגיאות ספציפיות נכתבות בקובצי ההגדרות שגרמו להן. מידע נוסף על אבחון השגיאות האלה מופיע בקטע שגיאות באימות ההגדרה.
CONFIG_VALIDATION_WARNING נתקלנו בבעיות פוטנציאליות באחד או יותר מקובצי ההגדרות. ב-CR של Istio, המערכת מתעלמת משדות ספציפיים לא תקינים, אבל מעבדת את ההגדרות הכוללות. יכול להיות שתהיה התנהגות לא צפויה. מידע נוסף על אבחון השגיאות האלה מופיע בקטע שגיאות באימות ההגדרה.
MULTICLUSTER_SECRET_WARNING האשכול משתמש בסוד רב-אשכולי של Istio שנוצר באופן ידני, במקום להשתמש ב-API מבוסס-הצהרות של Istio לחיפוש נקודות קצה. להעביר את ההגדרה של גילוי נקודות קצה מרובות אשכולות להטמעה דקלרטיבית. מידע נוסף זמין בדף Multi-cluster Secrets.
WORKLOAD_IDENTITY_REQUIRED זהות עומס העבודה לא מופעלת באשכול או לפחות באחד ממאגרי הצמתים. הפעלת Workload Identity ברמת האשכול וברמת מאגר הצמתים. הוראות מפורטות מופיעות בדף הפעלת זהות עומס עבודה.
MANAGED_CNI_NOT_ENABLED האפשרות Managed CNI לא מופעלת באשכול הזה. כדי לשמור על שיטות מומלצות ברשת שלכם, מומלץ להפעיל CNI מנוהל. מידע נוסף זמין בדף הפעלת CNI מנוהל.
NON_STANDARD_SIDECAR_BINARY_USAGE פקודה אחת או יותר בתוך מאגרי Istio משתמשת בקבצים בינאריים שאינם `envoy`,‏ `pilot_agent` או `iptables`. הסרת התלות בקבצים בינאריים שלא נתמכים. מידע נוסף זמין בדף שימוש בקבצים בינאריים שלא נתמכים.
UNSUPPORTED_GATEWAY_CLASS_USAGE האשכול מוגדר עם מחלקות שערים (Istio ו-Anthos Service Mesh) שנדרשת העברה שלהן אל Istio Ingress Gateway כדי להתאים לשיטות המומלצות. הוראות מפורטות מופיעות במסמכי התיעוד.
UNSUPPORTED_MULTIPLE_CONTROL_PLANES הקלאסטר הקצה מספר ערוצים של מישור הבקרה. ‫Cloud Service Mesh תומך רק בערוץ אחד לכל אשכול. מידע נוסף זמין במאמר בנושא תיקון של כמה מישורי בקרה.
REQUIRED_ORG_POLICY_DISABLED צריך להפעיל מדיניות ארגון מושבתת. כדי להבטיח את הפונקציונליות של Cloud Service Mesh, צריך להשבית את המדיניות הזו בפרויקט. מידע נוסף זמין במאמר בנושא הפעלת מדיניות ארגון נדרשת.
MISSING_CONTROL_PLANE_CONFIG ב-cluster חסרה ההגדרה של Cloud Service Mesh. כדי ליצור את ההגדרה הזו, צריך לפעול לפי ההוראות במאמר Missing Control Plane Configuration. רשת השירותים שלכם עדיין פועלת, אבל נדרש עדכון.

שגיאות באימות ההגדרה

הקודים CONFIG_VALIDATION_WARNING ו- CONFIG_VALIDATION_ERROR מציינים שנמצאו בעיות בהגדרות של רשתות (Istio או Kubernetes Custom Resources) ושיכול להיות שחלק מההגדרות לא הוחלו בצורה תקינה.

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

ב-Cloud Service Mesh נעשה שימוש בתהליך אימות הגדרות בשתי רמות:

  1. אימות סינכרוני: תגובה לפעולה מאתר אחר (Webhook) לצורך אימות מבצעת בדיקות תחביר ראשוניות. אם ההגדרה פגומה באופן מהותי, העדכון נדחה בשכבת ה-API של Kubernetes ו-kubectl apply נכשל באופן מיידי.
  2. אימות אסינכרוני: אימות סמנטי מתבצע ברקע במהלך התרגום. אם בשלב הזה מזוהה הגדרה לא תקינה, המערכת משמיטה באופן אסינכרוני את המשאב המותאם אישית (CR) כדי למנוע ממנו לשבור את שאר הרשת, וממשיכה להחיל את שאר ההגדרות התקינות.

כדי להבין טוב יותר את ההתנהגות הזו, מומלץ לעיין בקטע הסבר על אימות ההגדרות.

איתור הגדרות לא תקינות

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

אפשר להשתמש בפקודה הבאה כדי לאתר את ההגדרות הלא תקינות ולראות את הודעות השגיאה הספציפיות. (הערה: אלה שגיאות שקשורות ספציפית למשאבי Istio, ויכול להיות שלא כל שגיאות האימות יוצגו כאן).

for resource in serviceentries destinationrules virtualservices gateways peerauthentications authorizationpolicies requestauthentications sidecars telemetries envoyfilters;
  do kubectl get $resource --all-namespaces --output=json | \
   jq  '.items[] | select(.status.conditions != null and any(.status.conditions[]; .type == "Accepted" and .status == "False")) | {"name": .metadata.name, "namespace": .metadata.namespace, "kind": .kind, "conditions": .status.conditions}';
done

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

{
  "name": "demo-envoy-filter",
  "namespace": "default",
  "kind": "EnvoyFilter",
  "conditions": [
    {
      "lastTransitionTime": "2024-04-04T21:10:18.046975988Z",
      "message": "This API is not supported",
      "reason": "Invalid",
      "status": "False",
      "type": "Accepted"
    }
  ]
}