סדרת המדריכים הזו מיועדת לאדמינים ולמפעילים בתחום ה-IT שרוצים לפרוס, להריץ ולנהל סביבות אפליקציות מודרניות שפועלות ב-Google Kubernetes Engine (GKE). בסדרת המדריכים הזו תלמדו איך להגדיר מעקב והתראות, לשנות את גודל עומסי העבודה ולבצע סימולציה של כשל, והכול באמצעות אפליקציית המיקרו-שירותים לדוגמה של Cymbal Bank:
- יצירת אשכול ופריסת אפליקציה לדוגמה
- מעקב באמצעות השירות המנוהל של Google Cloud ל-Prometheus
- התאמה לעומסי עבודה
- סימולציה של כשל (במדריך הזה)
- ניהול שינויים באופן מרכזי
סקירה כללית ומטרות
האפליקציות צריכות להיות מסוגלות להתמודד עם הפסקות זמניות ותקלות. היכולת הזו מאפשרת למשתמשים להמשיך לגשת לאפליקציות שלכם גם כשיש בעיה. אפליקציית הדוגמה 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 כבר נפרסה בכמה אזורים, מה שעוזר להגן מפני תקלות בלתי צפויות.
בודקים את התפלגות הצמתים באשכול 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בודקים את ההפצה של שירותי האפליקציה לדוגמה 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 כדי לעקוב אחרי חלק מהשירותים וליצור התראות אם יש בעיה. אם הפעלתם Pods בצמתים באזור שבו הדמייתם הפסקת חשמל, תקבלו הודעות התראה ב-Slack שנוצרו על ידי Prometheus. ההתנהגות הזו מדגימה איך אפשר ליצור סביבת אפליקציה מודרנית שעוקבת אחרי התקינות של הפריסות, שולחת התראות אם יש בעיה ויכולה להתאים את עצמה באופן אוטומטי לשינויים בעומס או לכשלים.
אשכול GKE שלכם מגיב אוטומטית להפסקת השירות המדומה. כל השירותים בצמתים המושפעים מופעלים מחדש בצמתים שנותרו.
בודקים שוב את התפלגות הצמתים באשכול 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הבקר של 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כדאי לעיין ב
AGEשל השירותים. בדוגמה הקודמת של הפלט, חלק מהשירותים מוגבלים לגיל צעיר יותר מאחרים באפליקציית הדוגמה Cymbal Bank. בעבר, השירותים החדשים יותר האלה פעלו באחד מהצמתים שבהם הדמייתם כשל. בקר Kubernetes הפעיל מחדש את השירותים האלה בצמתים זמינים.
בתרחיש אמיתי, הייתם פותרים את הבעיה או מחכים שהבעיה הבסיסית בתחזוקה תיפתר. אם הגדרתם את Prometheus לשלוח הודעות ל-Slack על סמך התראות, תוכלו לראות את ההתראות האלה. אפשר גם לחזור על השלבים מהמדריך הקודם כדי להגדיל את המשאבים ולראות איך אשכול GKE מגיב לעומס מוגבר כשיש רק שני אזורים באזור. האשכול צריך להתרחב עם שני האזורים שנותרו זמינים.
הסרת המשאבים
כדי להימנע מחיובים בחשבון Google Cloud על המשאבים שבהם השתמשתם במדריך הזה, מוחקים את הפרויקט שיצרתם.
- במסוף Google Cloud , נכנסים לדף Manage resources.
- ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
- כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.
המאמרים הבאים
במדריך הבא מוסבר איך לנהל שינויים באופן מרכזי באמצעות סנכרון תצורות.