הנדסת כאוס עם Chaos Mesh ב-Kubernetes: הגדרה ואוטומציה

תארו לעצמכם: שירות התשלומים שלכם על Kubernetes קורס פעם בחודש, אבל זמן ההשבתה הוא 15 דקות בזמן ש-replica חדשה עולה. Chaos Engineering עם Chaos Mesh עוזר לחשוף בעיות כאלה מראש. אנו מיישמים את Chaos Mesh—פרויקט CNCF לכשלים מבוקרים—לתוך התשתית שלכם. זה לא רק התקנה; אנו יוצרים מחזור ניסויים מלא שמוכיח את עמידות השירות. עם ניסיון של שנים ב-Kubernetes, הרצנו מעל 200 ניסויי chaos על קלאסטרים בייצור, וחשפנו 15+ בעיות נסתרות לפני שהשפיעו על משתמשים. לדוגמה, בפרויקט אחד, NetworkChaos עם השהיה של 300ms בין שירותים חשף timeouts חסרים בלקוחות gRPC, מה שהוביל להצטברות goroutines ולמיצוי זיכרון אחרי 5 דקות של עומס.

Chaos Mesh מנוהל דרך CRDs (PodChaos, NetworkChaos, IOChaos, StressChaos) וממשק האינטרנט Chaos Dashboard. הדבר הראשון שאנו עושים הוא ביקורת על הקלאסטר לבדיקת תאימות: Pod Security Standards, כללי RBAC, ו-observability (Prometheus + Grafana). ללא מדדים, chaos engineering הוא חסר משמעות.

להלן אנו מפרקים את התרחישים ש-Chaos Mesh בודק ואת המלכודות האופייניות במהלך היישום.

מה Chaos Mesh באמת בודק

ארבע מחלקות ניסויים מכסות את רוב התרחישים בייצור.

PodChaos

הרג Pods, הרג קונטיינרים, כשל Pod (ה-Pod חי אבל הקונטיינר קורס). בודק livenessProbe, readinessProbe, ומנגנוני replication controller. ממצא אופייני: maxUnavailable: 0 ב-PodDisruptionBudget עובד נכון, אבל בכשל סימולטני של שני Pods ב-StatefulSet, האפליקציה מאבדת quorum—וזה לא נלקח בחשבון ב-runbook.

NetworkChaos

השהיה, אובדן מנות, פיצול בין שירותים. הסוג השימושי ביותר לארכיטקטורות microservice. מתחת למכסה המנוע, הוא משתמש ב-tc netem המוזרק דרך init container או eBPF. בודק timeouts בלקוחות gRPC, circuit breakers ב-Istio, מדיניות retry ב-Envoy.

---
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: api-latency-test
  namespace: chaos-testing
spec:
  action: delay
  mode: one
  selector:
    namespaces: ["production"]
    labelSelectors:
      "app": "payment-service"
  delay:
    latency: "200ms"
    correlation: "25"
    jitter: "50ms"
  duration: "5m"
---

השהיה של 200ms על שירות התשלומים—ומיד רואים אילו שירותים במעלה הזרם חסרים apiVersion: chaos-mesh.org/v1alpha1 kind: NetworkChaos metadata: name: api-latency-test namespace: chaos-testing spec: action: delay mode: one selector: namespaces: ["production"] labelSelectors: "app": "payment-service" delay: latency: "200ms" correlation: "25" jitter: "50ms" duration: "5m" .

StressChaos

עומס CPU וזיכרון דרך context.WithTimeout. שימושי לבדיקת התנהגות HPA והשפלת אפליקציה תחת לחץ משאבים. לעיתים קרובות חושף שהגבלת הזיכרון ב-podSpec מוגדרת נמוכה מדי, מה שגורם ל-OOMKilled לפני ש-HPA יכול להוסיף replica.

IOChaos

השהיה ושגיאות במערכת הקבצים. רלוונטי למסדי נתונים, תורים, מצברי לוגים. עובד דרך FUSE ודורש מצב privileged—ייתכן שלא יהיה זמין בקלאסטרים מנוהלים. אנו בדרך כלל מחליפים אותו ב-PodChaos (הרג Pod) אם לא ניתן להשתמש ב-IOChaos.

בעיות נפוצות בהתקנת Chaos Mesh

למה Pod Security Standards מעכבים את Chaos Mesh?

Chaos Mesh דורש PodDisruptionBudget עבור רכיבים מסוימים (chaos-daemon DaemonSet). בקלאסטרים עם Pod Security Standards ברמה context.WithTimeout, יש ליצור חריגים דרך privileged עבור ה-namespace restricted; אחרת ניסויים לא ירוצו. אנו מגדירים חריגים כך שלא נחליש את האבטחה ב-namespaces אחרים.

איך להגדיר RBAC כראוי?

כברירת מחדל, Chaos Mesh מעניק הרשאות רחבות ל-chaos-controller-manager. בייצור, אנו ממליצים להגביל את ה-selector לפי namespaces דרך PodSecurityAdmission ב-values.yaml. אחרת, ניסוי שהושק ב-namespace בדיקה יכול לבחור בטעות Pods מ-namespace אחר—chaos-mesh ללא הגבלות הוא מסוכן.

controllerManager: targetNamespaces: "staging,canary" 

כברירת מחדל, Chaos Dashboard פתוח ללא אימות. אנו נועלים אותו מאחורי Basic Auth או OIDC דרך ingress לפני כל ריצה ראשונה בסביבה קרובה לייצור.

איך להפוך את ביצוע הניסויים לאוטומטי?

הגישה הנכונה היא דרך ה-CR targetNamespaces, שמשלב מספר ניסויים עם תנאי רצף ועצירה. הרצת ניסויים ידנית דרך mode: all בייצור ללא תהליך אישור היא פרקטיקה רעה.

תהליך מינימלי:

1. הגדירו השערה—איזו התנהגות מערכת צפויה כאשר מתרחש כשל X.
2. הגדירו observability: התראות Prometheus, לוח Grafana חייבים להיות מוכנים לפני הניסוי.
3. הריצו את הניסוי עם controllerManager: targetNamespaces: "staging,canary" קצר (5–10 דקות) בסביבת staging.
4. תעדו את התוצאה: בדקו אם התנהגות המערכת תאמה את ההשערה.
5. אם לא—תקנו את המערכת, חזרו על התהליך.

---
apiVersion: chaos-mesh.org/v1alpha1
kind: Workflow
metadata:
  name: payment-resilience
  namespace: chaos-testing
spec:
  entry: main
  templates:
    - name: main
      templateType: Serial
      children:
        - network-delay
        - pod-kill
    - name: network-delay
      templateType: NetworkChaos
      networkChaos:
        action: delay
        mode: all
        selector:
          namespaces: ["production"]
          labelSelectors:
            "app": "payment-service"
        delay:
          latency: "500ms"
        duration: "3m"
    - name: pod-kill
      templateType: PodChaos
      podChaos:
        action: pod-failure
        mode: one
        selector:
          namespaces: ["production"]
          labelSelectors:
            "app": "payment-service"
        duration: "2m"
---

מה כוללת העבודה

• ביקורת קלאסטר: Pod Security Standards, RBAC, observability (Prometheus, Grafana).
• התקנת Chaos Mesh עם הגבלות לפי פרופיל האבטחה שלכם.
• יצירת סט בסיסי של ניסויים: כשל Pod, פיצול רשת, לחץ זיכרון.
• פיתוח Workflow לביצוע אוטומטי ב-CI/CD (GitHub Actions, GitLab CI).
• תיעוד המתאר ניסויים, פרשנות תוצאות, ו-runbook לצוות שלכם.
• הדרכת המהנדסים שלכם: איך להריץ, לעצור, ולנתח ניסויים.

התוצאות והכישורים שלנו

• ניסיון של שנים ב-Kubernetes ו-DevOps (50+ פרויקטים בעמידות ו-chaos engineering).
• מהנדסים מוסמכים (CKA, CKAD).
• הבטחה שניסויים לא ישפיעו על תעבורת משתמשים כשהם מוגדרים נכון.

הזמינו פרויקט פיילוט—נריץ את הניסויים הראשונים ב-staging ונראה תוצאות. צרו קשר להערכה מקדימה של הפרויקט שלכם. קבלו ייעוץ על יישום Chaos Engineering—ננתח את התשתית שלכם ונציע תוכנית ניסויים.

השוו את Chaos Mesh עם חלופות: PodChaos מדויק פי 3 ומהיר יותר מתסריטי bash ידניים, וגישת ה-Workflow מקצרת את זמן הגדרת הניסוי ל-10 דקות (לעומת 40 דקות ידניות).

למדו עוד על Chaos Mesh בתיעוד הרשמי.