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

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

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

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

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

התקן את סביבת ניסויי הרעש

התקן את LitmusChaos באשכול ה-Kubernetes שלך:

helm repo add litmuschaos https://litmuschaos.github.io/litmus-helm/

helm repo update

helm install litmus litmuschaos/litmus

אימות התקנה:

kubectl get pods -n litmus

הערה: וודא שהאשכול שלך מוכן לניסויים של כאוס.

הגדר את ניסיון הכאוס

צור קובץ YAML של ChaosExperiment כדי לדמות תרחיש מחיקת Pod.

דוגמה (pod-delete.yaml):

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosExperiment

metadata:

  name: pod-delete

  namespace: litmus

spec:

  definition:

    scope: Namespaced

    permissions:

      - apiGroups: ["*"]

        resources: ["*"]

        verbs: ["*"]

    image: "litmuschaos/go-runner:latest"

    args:

      - -c

      - ./experiments/generic/pod_delete/pod_delete.test

    command:

      - /bin/bash

התקן את ChaosOperator וקבע את חשבון השירות

הפעל את ChaosOperator כדי לנהל ניסויים:

kubectl apply -f https://raw.githubusercontent.com/litmuschaos/litmus/master/litmus-operator/cluster-k8s.yml

הערה: צור ServiceAccount כדי להעניק אישורים נדרשים.

הכנס כאוס לאפליקציית היעד

סמן את שטח השמות של האפליקציה לכאוס:

kubectl label namespace <target-namespace> litmuschaos.io/chaos=enabled

הפעל ChaosEngine כדי להפעיל את הניסוי:

דוגמה (chaosengine.yaml):

apiVersion: litmuschaos.io/v1alpha1

kind: ChaosEngine

metadata:

  name: pod-delete-engine

  namespace: <target-namespace>

spec:

  appinfo:

    appns: '<target-namespace>'

    applabel: 'app=<your-app-label>'

    appkind: 'deployment'

  chaosServiceAccount: litmus-admin

  monitoring: false

  experiments:

    - name: pod-delete

החל ChaosEngine:

kubectl apply -f chaosengine.yaml

נטה את הניסוי

צפה בהתקדמות:

kubectl describe chaosengine pod-delete-engine -n <target-namespace>

בדוק את מצב הפודים של הכאוס:

kubectl get pods -n <target-namespace>

נתח את התוצאות

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

כאן כמה מדדים לניטור:

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

פתרון

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

פתרונות שהוחלו:

• הגדלת מספר הרפליקות בהטמעה כדי להתמודד עם תעבורת גבוהה
• קונפיגורציה של בקשות ומשאבים נכונים עבור CPU וזיכרון במפרט הפוד
• היישום של מאזן אוטומטי לפודים אופקיים (HPA) כדי להתמודד עם עליות תנועה באופן דינמי

סיכום

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