פתרון בעיות שקשורות לשרתי proxy מסוג sidecar ב-Cloud Service Mesh

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

תהליך של מאגר התגים istio-proxy נקטע בגלל אירוע OOM

בקטע הזה אנחנו מניחים שקונטיינר istio-proxy לא מושבת על ידי אירוע SystemOOM, וצומת Kubernetes לא נמצא במצב MemoryPressure. כברירת מחדל, ל-istio-proxy sidecar container יש מגבלות משאבים. אם קונטיינר ה-istio-proxy נסגר עם Reason: OOMKilled, צריך להבין למה Envoy צורך את הזיכרון.

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

---
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  values:
    global:
      proxy:
        resources:
          requests:
               memory: 128Mi
          limits:
               memory: 1Gi

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

  • sidecar.istio.io/proxyMemory
  • sidecar.istio.io/proxyMemoryLimit

חשוב לוודא שלא הגדרתם מגבלות נמוכות יותר מערכי ברירת המחדל.

הפתרון לטווח הארוך הוא להקטין את הזיכרון שבשימוש של istio-proxy קונטיינרים מסוג sidecar. כברירת מחדל, כל שרתי ה-proxy מסוג sidecar מתוכנתים עם ההגדרה הנדרשת כדי להגיע לכל מופע אחר של עומס עבודה ברשת. ‫Istio מספק הגדרת משאב מותאם אישית Sidecar כדי להגביל את מספר נקודות הקצה שמוגדרות ל-proxy של sidecar, וכך להקטין את צריכת הזיכרון של קונטיינר istio-proxy.