הגדרת קונטיינרים מסוג Sidecar ב-Kubernetes לתהליכי עזר

הגדרת קונטיינרים צדדיים (Sidecar) של Kubernetes לתהליכי עזר

אנו ממקמים מספר קונטיינרים ב-Pod אחד של Kubernetes — הם חולקים את הרשת ויכולים להתקין כרכים משותפים. זהו הבסיס לתבנית ה-sidecar: תהליך עזר חי לצד היישום הראשי מבלי לשנות את התמונה שלו. אנו מטפלים במשימות רוחביות — איסוף לוגים, פרוקסי תעבורה, סנכרון סודות. גישה זו מבודדת את התצורה, מפשטת עדכונים ומפחיתה תקורה תשתיתית. עם 50 פודים שלכל אחד שני sidecars, עומס CPU יכול להגיע ל-10 ליבות רק עבור תהליכי עזר, כך שתכנון משאבים נכון חוסך עד 40% CPU. תבנית זו מתוארת בתיעוד Kubernetes.

למה sidecar עדיף על DaemonSet למשימות מסוימות?

רישום לוגים. היישום הראשי כותב לוגים לקובץ ב-/var/log/app/. אנו ממקמים sidecar של Fluentd שקורא את אותו כרך דרך emptyDir ושולח לוגים ל-Elasticsearch. DaemonSet עם Fluentd על כל צומת קורא /var/log/containers/, אך הניתוח אחיד לכל הפודים. Sidecar מספק כוונון עדין לפורמט הלוג של שירות ספציפי — ללא עקיפות ועם ערבויות אספקה.

פרוקסי Envoy/Istio. רשת שירות (Service Mesh) בנויה על תבנית ה-sidecar: Istio מזריק istio-proxy (Envoy) אוטומטית דרך MutatingAdmissionWebhook כאשר ה-namespace מתויג ב-istio-injection: enabled. היישום אינו מודע לאימות TLS הדדי, מעגלי ניתוק (circuit breaking) וניטור (tracing) — הפרוקסי מטפל בהכל. אנו מגדירים זאת ב-1-2 ימים.

סנכרון תצורה. Git-sync sidecar (registry.k8s.io/git-sync/git-sync:v4.2.1) משכפל מאגר לתוך emptyDir ועוקב אחר שינויים. היישום הראשי קורא תצורות מכרך זה. עדכוני תצורה ללא הפעלה מחדש של הפוד — קריטי לשירותים עם דרישת אפס זמן השבתה.

איך להגדיר sidecar לאיסוף לוגים?

הוראות שלב אחר שלב:

1. צור ConfigMap עם תצורת Fluent Bit: ציין קלט מקובץ, פלט ל-Elasticsearch או Loki.
2. הוסף קונטיינר שני במפרט הפוד עם התמונה fluent/fluent-bit, התקן את אותו כרך emptyDir עם הלוגים.
3. הגדר משאבים: requests 50m CPU / 64Mi זיכרון, limits 100m CPU / 128Mi זיכרון.
4. ודא אספקת לוגים עם spec: containers: - name: app image: myapp:v3.1.0 volumeMounts: - name: app-logs mountPath: /var/log/app - name: log-shipper image: fluent/fluent-bit:3.0 volumeMounts: - name: app-logs mountPath: /var/log/app readOnly: true - name: fluent-bit-config mountPath: /fluent-bit/etc resources: requests: cpu: "50m" memory: "64Mi" limits: cpu: "100m" memory: "128Mi" volumes: - name: app-logs emptyDir: {} - name: fluent-bit-config configMap: name: fluent-bit-config .

הנה מניפסט טיפוסי:

---
spec:
  containers:
    - name: app
      image: myapp:v3.1.0
      volumeMounts:
        - name: app-logs
          mountPath: /var/log/app
    - name: log-shipper
      image: fluent/fluent-bit:3.0
      volumeMounts:
        - name: app-logs
          mountPath: /var/log/app
          readOnly: true
        - name: fluent-bit-config
          mountPath: /fluent-bit/etc
      resources:
        requests:
          cpu: "50m"
          memory: "64Mi"
        limits:
          cpu: "100m"
          memory: "128Mi"
  volumes:
    - name: app-logs
      emptyDir: {}
    - name: fluent-bit-config
      configMap:
        name: fluent-bit-config

נקודת משאבים מרכזית: קונטיינרים צדדיים מסוכמים בעת תזמון הפוד. Fluentd צורך זיכרון רב — ללא limits, הוא יכול בקלות לצרוך 500+ MiB על צומת בעומס לוגים גבוה. תמיד הגדר limits. בפרויקטים שלנו, אנו משתמשים ב-128Mi עבור Fluent Bit — מספיק אפילו ב-10,000 לוגים/שנייה.

ניהול מחזור החיים של sidecar

ה-sidecar מתחיל במקביל לקונטיינר הראשי, מה שיוצר מרוץ: היישום עשוי לנסות לכתוב לוגים לפני ש-Fluent Bit פעיל. למקרים קריטיים, השתמש ב-hook של postStart על הקונטיינר הראשי או עבור ל-sidecar טבעי (מגרסה 1.29).

Sidecar טבעי מוצהר ב-spec.initContainers עם restartPolicy: Always:

spec: initContainers: - name: log-shipper image: fluent/fluent-bit:3.0 restartPolicy: Always # ... 

זה מבטיח שה-sidecar מתחיל לפני הקונטיינר הראשי ומתחיל מחדש במקרה של כשל מבלי להשפיע על הקונטיינר הראשי.

מתי כדאי להשתמש ב-sidecar טבעי?

Sidecar טבעי פותר את מרוץ ההתחלה ותליית פוד Job. אם ה-sidecar מבצע אתחול קריטי (למשל, טעינת תצורות ממאגר), השתמש בו. הוא מסתיים בצורה חלקה יחד עם הקונטיינר הראשי, ומונע פודים "זומביים".

השוואה בין sidecar ל-DaemonSet לאיסוף לוגים

מלכודות טיפוסיות

תליית פוד Job. ה-sidecar אינו מסתיים כשהקונטיינר הראשי של Job מסתיים. הפוד נשאר במצב spec: initContainers: - name: log-shipper image: fluent/fluent-bit:3.0 restartPolicy: Always # ... כי Fluentd או sidecar אחר ממשיך לפעול. פתרון: או sidecar טבעי (מסתיים כראוי) או Running ואות לתהליך ה-sidecar מהקונטיינר הראשי בסיום.

צריכת משאבים. עם 50 פודים שלכל אחד שני sidecars (100m CPU לכל sidecar), זה 10 ליבות CPU רק עבור תהליכי עזר. קח זאת בחשבון בתכנון קיבולת. אנו ממליצים להשתמש בפרופילי משאבים ו-HPA.

מורכבות ניפוי שגיאות. צפייה בלוגים ממספר קונטיינרים בפוד אחד היא מסורבלת. השתמש ב-shareProcessNamespace: true או בכלים כמו Stern.

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

• שכחת limits — sidecar צורך זיכרון גבוה באופן בלתי צפוי.
• שימוש ב-sidecar רגיל ב-Job — הפוד נתלה.
• אי הגדרת kubectl logs <pod> -c <container> על הכרך המשותף — sidecar עלול להשחית נתונים.
• אי התחשבות ב-sidecar ב-HPA — קנה מידה אוטומטי מסכם את כל הקונטיינרים של הפוד.
• אי הגדרת restartPolicy: Always ב-sidecars טבעיים — הקונטיינר לא יתחיל מחדש במקרה של כשל.

איך לחשב משאבים ל-sidecar?

ערכי התחלה מומלצים:

מה כלול ביישום תבנית ה-sidecar?

כל שלב מועבר במפתח פתוח (turnkey). השאר בקשה — אנו נעריך את הפרויקט שלך, נציג דוגמאות תצורה ונעזור להימנע מטעויות טיפוסיות. קבל ייעוץ: פשוט תאר את המשימה.

לוחות זמנים ועלות

סוג אחד של sidecar (רישום לוגים או git-sync) — 1-2 ימים לעיצוב ובדיקות. רשת שירות עם Istio — עד שבוע. העלות מחושבת באופן אישי לפי מורכבות ומספר השירותים. חיסכון ממוצע במשאבים במעבר מ-DaemonSet ל-sidecar — עד 40% CPU.

הזמן ביקורת על התשתית הנוכחית שלך — אנו נזהה צווארי בקבוק ונציע פתרון אופטימלי.