פתרון בעיות בכמה אשכולות
בקטע הזה מוסבר על בעיות נפוצות ב-Cloud Service Mesh ואיך לפתור אותן. לקבלת עזרה נוספת, אפשר לעיין במאמר בנושא קבלת תמיכה.
סודות חסרים
Cloud Service Mesh מסתמך על קובץ kubeconfig שמוטמע בסוד של Kubernetes כדי לגלות נקודות קצה מרוחקות בצורה תקינה. בלי הסודות, המשתמשים תמיד יראו בקשות שפוגעות בתרמילים באשכול המקומי במהלך איזון עומסים בין אשכולות.
מריצים את הפקודה הבאה בכל אשכול כדי לוודא שהסוד נוצר:
kubectl get secret istio-remote-secret-CLUSTER_NAME_i -n istio-system
בודקים את הפלט הצפוי:
NAME TYPE DATA AGE
istio-remote-secret-CLUSTER_NAME_i Opaque 1 44s
כדי לפתור את הבעיה, צריך למחוק את כל הסודות המרוחקים ולהריץ מחדש את הפקודה create-mesh.
לא ניתן לגשת לשרת ה-API
מישור הבקרה של Cloud Service Mesh צריך להגיע לשרת ה-API של האשכול המרוחק. המצבים הבאים עלולים לגרום לכך שלא תהיה גישה לאשכול המרוחק:
- האשכול המרוחק נמחק.
- האשכול המרוחק הוא אשכול פרטי שלא מופעלת בו גישה גלובלית.
- האשכול המרוחק הוא אשכול פרטי עם Master Authorized Network מופעל, אבל כתובת ה-IP של מישור הבקרה של Cloud Service Mesh לא נוספה לרשימת ההיתרים.
אם שרת ה-API לא נגיש, Istiod יציג הודעות שגיאה ביומן. המשתמשים תמיד יראו שבקשות מגיעות ל-pod המקומי במהלך איזון עומסים בין אשכולות.
בממשק של Logs Explorer, מגדירים את השאילתה resource.type ל-istio_control_plane.
בודקים אם יש שגיאות שקשורות לסודות לא תקינים.
כדי לצאת מהמצב שמתואר למעלה, קודם צריך לפתור את הבעיה הבסיסית בנגישות של שרת ה-API. לאחר מכן, מוחקים את כל הסודות המרוחקים בכל אשכול ומריצים מחדש את הפקודה create-mesh.
כלל חומת אש חסר
בלי כלל חומת האש המתאים, המשתמשים יחוו עיכוב של 10 שניות ואחריו זמן קצוב לתפוגה כשמבצעים איזון עומסים בין אשכולות.
כדי לפתור את הבעיה, פועלים לפי השלבים שמפורטים במאמר בנושא יצירת כלל בחומת האש.