הסרת צמתים שנחסמו על ידי PodDisruptionBudgets

בתנאים מסוימים, מדיניות PodDisruptionBudgets (PDB) יכולה למנוע הסרה מוצלחת של צמתים ממאגרי צמתים. בתנאים האלה, סטטוס הצומת מדווח על Ready,SchedulingDisabled למרות שהוא הוסר. במסמך הזה מוסבר איך להסיר צמתים מאשכולות Google Distributed Cloud שכרגע חסומים בגלל בעיות ב-PDB.

הדף הזה מיועד לאדמינים, לארכיטקטים ולמפעילים שמנהלים את מחזור החיים של תשתית הטכנולוגיה הבסיסית, ומגיבים להתראות ולדפים כשלא עומדים ביעדי רמת השירות (SLO) או כשאפליקציות נכשלות. מידע נוסף על תפקידים נפוצים ודוגמאות למשימות שאנחנו מתייחסים אליהן ב Google Cloudתוכן זמין במאמר תפקידי משתמשים נפוצים ומשימות ב-GKE.

התנגשות בין PDB לבין מספר הפודים הזמינים

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

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

לדוגמה, מדיניות PDB יכולה להגדיר שתמיד יהיו שני פודים זמינים במערכת (.spec.minAvailable הוא 2). אבל אם יש לכם רק שני Pods, ואתם מנסים להסיר את הצומת שמכיל אחד מהם, מדיניות ה-PDB תיכנס לתוקף ותמנע את הסרת הצומת.

באופן דומה, אם במדיניות PDB מוגדר שאף Pod לא צריך להיות זמין (.spec.maxUnavailable הוא 0), המדיניות גם מונעת מחיקה של צמתים משויכים. גם אם מנסים להסיר רק Pod אחד בכל פעם, מדיניות ה-PDB מונעת את מחיקת הצומת המושפע.

השבתה והפעלה מחדש של מדיניות PDB

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

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

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

כדי שיהיה קל יותר לקרוא, נעשה שימוש במשתנה ${KUBECONFIG} בפקודות הבאות.

בהתאם לסוג האשכול, מייצאים את הנתיב של kubeconfig של אשכול האדמין (ADMIN_KUBECONFIG) או של kubeconfig של אשכול המשתמש (USER_CLUSTER_CONFIG) אל $(KUBECONFIG) ומשלימים את השלבים הבאים:
- כדי למחוק צומת מאשכול משתמשים, מגדירים את export KUBECONFIG=USER_CLUSTER_CONFIG
- כדי למחוק צומת מאשכול אדמין, מגדירים את export KUBECONFIG=ADMIN_KUBECONFIG.
אופציונלי: אם אתם מוחקים צומת ממאגר צמתים של אשכול משתמשים, מריצים את הפקודה הבאה כדי לחלץ את קובץ ה-kubeconfig של אשכול המשתמשים:
```
kubectl --kubeconfig ADMIN_KUBECONFIG -n cluster-USER_CLUSTER_NAME \
  get secret USER_CLUSTER_NAME-kubeconfig  \
  -o 'jsonpath={.data.value}' | base64 -d > USER_CLUSTER_CONFIG
```
מחליפים את הערכים הבאים בפרטים שספציפיים לסביבת האשכול:
- ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.
- ‫CLUSTER_NAME: שם האשכול שרוצים ליצור לו snapshot.
- ‫USER_CLUSTER_CONFIG: הנתיב לקובץ התצורה של אשכול המשתמשים.

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

kubectl get nodes --kubeconfig ${KUBECONFIG}

הסטטוס של הצומת אמור להיראות כמו בדוגמת הפלט הבאה:

NAME   STATUS                    ROLES      AGE      VERSION
CP2    Ready                     Master     11m      v.1.18.6-gke.6600
CP3    Ready,SchedulingDisabled  <none>     9m22s    v.1.18.6-gke.6600
CP4    Ready                     <none>     9m18s    v.1.18.6-gke.6600

בודקים את ה-PDB באשכול:

kubectl get pdb --kubeconfig ${KUBECONFIG} -A

המערכת מדווחת על PDBs דומים לאלה שמוצגים בפלט של הדוגמה הבאה:

NAMESPACE     NAME             MIN AVAILABLE    MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress    1                N/A               1                     19m
gke-system    istiod           1                N/A               1                     19m
kube-system   coredns          1                N/A               0                     19m
kube-system   log-aggregator   N/A              0                 0                     19m
kube-system   prometheus       N/A              0                 0                     19m

בודקים את קובץ ה-PDB. למצוא התאמה בין התווית של ה-Pod ב-PDB לבין ה-Pods התואמים בצומת. ההתאמה הזו מבטיחה שתשביתו את ה-PDB הנכון כדי להסיר את הצומת בהצלחה:
```
kubectl --kubeconfig ${KUBECONFIG} get pdb log-aggregator -n kube-system -o 'jsonpath={.spec}'
```
המערכת מחזירה תוצאות של תוויות תואמות במדיניות של PDB:
```
{"maxUnavailable":0,"selector":{"matchLabels":{"app":"stackdriver-log-aggregator"}}}
```

חיפוש של Pods שתואמים לתווית המדיניות של PDB:

kubectl --kubeconfig ${KUBECONFIG} get pods -A --selector=app=stackdriver-log-aggregator  \
  -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\n"}{end}'

הפקודה מחזירה רשימה של Pods שתואמים לתווית ה-PDB, ומאמתת את מדיניות ה-PDB שצריך להסיר:

stackdriver-log-aggregator-0    CP3
stackdriver-log-aggregator-1    CP3

אחרי שמאשרים את ה-Pod המושפע, יוצרים עותק גיבוי של מדיניות ה-PDB. בדוגמה הבאה מוצג גיבוי של מדיניות log-aggregator:
```
kubectl get pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system  \
  -o yaml >> log-aggregator.yaml
```
מוחקים את המדיניות הספציפית של PDB. שוב, בדוגמאות הבאות נמחקת המדיניות log-aggregator:
```
kubectl delete pdb log-aggregator --kubeconfig ${KUBECONFIG} -n kube-system
```
אחרי שמוחקים את מדיניות ה-PDB, הצומת ממשיך לנקז את העומס. עם זאת, יכול להיות שיחלפו עד 30 דקות עד שהצומת יימחק באופן מלא. ממשיכים לבדוק את מצב הצומת כדי לוודא שהתהליך הסתיים בהצלחה.

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

משחזרים את מדיניות ה-PDB מהעותק:

kubectl apply -f log-aggregator.yaml --kubeconfig ${KUBECONFIG}

מוודאים שה-Pods שנמחקו נוצרו מחדש בהצלחה. בדוגמה הזו, אם היו שני stackdriver-log-aggregator-x Pods, הם נוצרים מחדש:
```
kubectl get pods -o wide --kubeconfig ${KUBECONFIG} -A
```
כדי לשחזר את הצומת, עורכים את ההגדרה המתאימה של מאגר הצמתים ומשחזרים את כתובת ה-IP של הצומת.

הסרת משאבי אחסון מצמתים שנמחקו באופן סופי

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

בודקים ומקבלים את השם של נפח האחסון הקבוע (PV) שמשויך לצומת:

kubectl get pv --kubeconfig ${KUBECONFIG}  \
  -A -o=jsonpath='{range .items[*]}{"\n"}{.metadata.name}{":\t"}{.spec.claimRef.name}{":\t"}  \
  {.spec.nodeAffinity.required.nodeSelectorTerms[0].matchExpressions[0].values}{"\n"}{end}'

מוחקים את ה-PV שמשויך לצומת:
```
kubectl delete pv PV_NAME --kubeconfig ${KUBECONFIG}
```
מחליפים את PV_NAME בשם של נפח האחסון הקבוע שרוצים למחוק.

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

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care. אפשר גם לעיין במאמר קבלת תמיכה לקבלת מידע נוסף על מקורות מידע לתמיכה, כולל:

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

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

התנגשות בין PDB לבין מספר הפודים הזמינים

השבתה והפעלה מחדש של מדיניות PDB

הסרת משאבי אחסון מצמתים שנמחקו באופן סופי

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

הסרת צמתים שנחסמו על ידי PodDisruptionBudgets