מסלול לימוד: אפליקציות שניתנות להרחבה – הדמיית כשל

סדרת המדריכים הזו מיועדת לאדמינים ולמפעילים בתחום ה-IT שרוצים לפרוס, להריץ ולנהל סביבות אפליקציות מודרניות שפועלות ב-Google Kubernetes Engine‏ (GKE). בסדרת המדריכים הזו תלמדו איך להגדיר מעקב והתראות, לשנות את גודל עומסי העבודה ולבצע סימולציה של כשל, והכול באמצעות אפליקציית המיקרו-שירותים לדוגמה של Cymbal Bank:

  1. יצירת אשכול ופריסת אפליקציה לדוגמה
  2. מעקב באמצעות השירות המנוהל של Google Cloud ל-Prometheus
  3. התאמה לעומסי עבודה
  4. סימולציה של כשל (במדריך הזה)
  5. ניהול שינויים באופן מרכזי

סקירה כללית ומטרות

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

במדריך הזה תלמדו איך לדמות כשל ב- Google Cloud ולראות איך שירותי האפליקציה באשכול GKE מגיבים. תלמדו איך לבצע את המשימות הבאות:

  • בודקים את הפצת הצמתים והשירותים.
  • הדמיה של כשל בצומת או באזור.
  • מוודאים שהשירותים ממשיכים לפעול בצמתים הנותרים.

עלויות

אם תפעילו את GKE ותפרוסו את אפליקציית הדוגמה Cymbal Bank בסדרת מדריכים זו, תחויבו על GKE on Google Cloud לפי אשכול, כפי שמפורט בדף התמחור, עד שתשביתו את GKE או תמחקו את הפרויקט.

אתם גם אחראים לעלויות אחרות Google Cloud שנובעות מהרצת אפליקציית הדוגמה Cymbal Bank, כמו חיובים על מכונות וירטואליות ב-Compute Engine.

לפני שמתחילים

כדי ללמוד איך לדמות כשל, צריך להשלים את המדריך הראשון כדי ליצור אשכול GKE שמשתמש ב-Autopilot ולפרוס את אפליקציית הדוגמה Cymbal Bank שמבוססת על מיקרו-שירותים.

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

בדיקת הפצת הצמתים והשירותים

ב- Google Cloud, אזור הוא מיקום גיאוגרפי ספציפי שבו אפשר לארח את המשאבים. באזורים יש שלושה תחומים או יותר. לדוגמה, האזור us-central1 נמצא במערב התיכון של ארצות הברית ומכיל כמה אזורים, כמו us-central1-a,‏ us-central1-b ו-us-central1-c. לתחומים יש חיבורי רשת עם רוחב פס גבוה וזמן אחזור נמוך לתחומים אחרים באותו אזור.

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

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

  1. בודקים את התפלגות הצמתים באשכול GKE:

    kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
    

    התוצאה דומה לפלט הבא, שבו אפשר לראות שהצמתים מפוזרים על פני כל שלושת האזורים באזור:

    NAME                         ZONE            INT_IP
    scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
    scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
    scalable-apps-pool-2-node2   us-central1-a   10.148.0.8
    scalable-apps-pool-2-node1   us-central1-a   10.148.0.9
    scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
    scalable-apps-pool-2-node4   us-central1-b   10.148.0.4
    
  2. בודקים את ההפצה של שירותי האפליקציה לדוגמה Cymbal Bank בצמתי אשכול GKE:

    kubectl get pods -o wide
    

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

    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
    accounts-db-0                         1/1     Running   0          6m30s   10.28.1.5   scalable-apps-pool-2-node3
    balancereader-7dc7d9ff57-shwg5        1/1     Running   0          6m30s   10.28.5.6   scalable-apps-pool-2-node1
    contacts-7ddc76d94-qv4x5              1/1     Running   0          6m29s   10.28.4.6   scalable-apps-pool-2-node2
    frontend-747b84bff4-xvjxq             1/1     Running   0          6m29s   10.28.3.6   scalable-apps-pool-2-node6
    ledger-db-0                           1/1     Running   0          6m29s   10.28.5.7   scalable-apps-pool-2-node1
    ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          6m29s   10.28.1.6   scalable-apps-pool-2-node3
    loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          6m29s   10.28.4.7   scalable-apps-pool-2-node2
    transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          6m29s   10.28.3.7   scalable-apps-pool-2-node6
    userservice-cd5ddb4bb-zfr2g           1/1     Running   0          6m28s   10.28.5.8   scalable-apps-pool-2-node1
    

סימולציה של הפסקה זמנית בשירות

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

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

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

  • מגדירים את הצמתים באחד מהתחומים ומרוקנים אותם. בדוגמה הבאה, המטרה היא שני הצמתים ב-us-central1-a:

    kubectl drain scalable-apps-pool-2-node1 \
        --delete-emptydir-data --ignore-daemonsets
    
    kubectl drain scalable-apps-pool-2-node2 \
        --delete-emptydir-data --ignore-daemonsets
    

    הפקודה הזו מסמנת את הצמתים ככאלה שלא ניתן לתזמן אותם, כך שאי אפשר יותר להפעיל Pods בצמתים האלה. ‫Kubernetes מתזמן מחדש את ה-Pods לצמתים אחרים באזורים מתפקדים.

בדיקת התגובה לסימולציה של כשל

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

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

  1. בודקים שוב את התפלגות הצמתים באשכול GKE:

    kubectl get nodes -o=custom-columns='NAME:.metadata.name,ZONE:.metadata.labels.topology\.kubernetes\.io/zone,INT_IP:.status.addresses[0].address'
    

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

    NAME                         ZONE            INT_IP
    scalable-apps-pool-2-node5   us-central1-c   10.148.0.6
    scalable-apps-pool-2-node6   us-central1-c   10.148.0.7
    scalable-apps-pool-2-node3   us-central1-b   10.148.0.5
    scalable-apps-pool-2-node4   us-central1-b   10.148.0.4
    
  2. הבקר של Kubernetes מזהה ששניים מהצמתים כבר לא זמינים, ומפיץ מחדש את השירותים בין הצמתים הזמינים. כל השירותים צריכים להמשיך לפעול.

    בודקים את ההפצה של שירותי האפליקציה לדוגמה Cymbal Bank בצמתי אשכול GKE:

    kubectl get pods -o wide
    

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

    NAME                                  READY   STATUS    RESTARTS   AGE     IP          NODE
    accounts-db-0                         1/1     Running   0          28m     10.28.1.5   scalable-apps-pool-2-node3
    balancereader-7dc7d9ff57-shwg5        1/1     Running   0          9m21s   10.28.5.6   scalable-apps-pool-2-node5
    contacts-7ddc76d94-qv4x5              1/1     Running   0          9m20s   10.28.4.6   scalable-apps-pool-2-node4
    frontend-747b84bff4-xvjxq             1/1     Running   0          28m     10.28.3.6   scalable-apps-pool-2-node6
    ledger-db-0                           1/1     Running   0          9m24s   10.28.5.7   scalable-apps-pool-2-node3
    ledgerwriter-f6cc7889d-mttmb          1/1     Running   0          28m     10.28.1.6   scalable-apps-pool-2-node3
    loadgenerator-57d4cb57cc-7fvrc        1/1     Running   0          9m21s   10.28.4.7   scalable-apps-pool-2-node5
    transactionhistory-5dd7c7fd77-cmc2w   1/1     Running   0          28m     10.28.3.7   scalable-apps-pool-2-node6
    userservice-cd5ddb4bb-zfr2g           1/1     Running   0          9m20s   10.28.5.8   scalable-apps-pool-2-node1
    
  3. כדאי לעיין בAGE של השירותים. בדוגמה הקודמת של הפלט, חלק מהשירותים מוגבלים לגיל צעיר יותר מאחרים באפליקציית הדוגמה של Cymbal Bank. בעבר, השירותים החדשים יותר האלה פעלו באחד מהצמתים שבהם הדמייתם כשל. בקר Kubernetes הפעיל מחדש את השירותים האלה בצמתים זמינים.

בתרחיש אמיתי, הייתם מנסים לפתור את הבעיה או מחכים שהבעיה הבסיסית בתחזוקה תיפתר. אם הגדרתם את Prometheus לשלוח הודעות ל-Slack על סמך התראות, תוכלו לראות את ההתראות האלה. אפשר גם לחזור על השלבים מהמדריך הקודם כדי להגדיל את המשאבים ולראות איך אשכול GKE מגיב לעומס מוגבר כשיש רק שני אזורים באזור. האשכול צריך להתרחב עם שני האזורים הנותרים שזמינים.

הסרת המשאבים

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

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

המאמרים הבאים

במדריך הבא מוסבר איך לרכז את ניהול השינויים באמצעות סנכרון תצורות.