פתרון בעיות שקשורות ל-Observability ב-Google Distributed Cloud

כדי לשחזר יומני ביקורת, מדדים או תוויות של מטא-נתונים שחסרים באשכולות של Google Distributed Cloud, אתם יכולים להשתמש בתיקונים הבאים לבעיות נפוצות שקשורות ליכולת התצפית. רוב הבעיות האלה נגרמות בגלל שגיאות בהרשאות או בגלל קריסות שנובעות ממחסור בזיכרון ברכיבים כמו kube-state-metrics באשכולות גדולים. חלק מהבעיות משפיעות גם על Horizontal Pod Autoscaler (HPA) ועל kubectl top.

אם אתם צריכים עזרה נוספת, תוכלו לפנות אל Cloud Customer Care.

במאמר קבלת תמיכה תוכלו לקרוא מידע נוסף על מקורות המידע לתמיכה, כולל:

יומני הביקורת של Cloud לא נאספים

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

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

הקונטיינר של שרת ה-proxy של יומני הביקורת של Cloud פועל באחת מהדרכים הבאות:

  • פוד סטטי באשכול האדמין או באשכול העצמאי.
  • כקונטיינר משני (sidecar) ב-Pod של kube-apiserver.

אם מופיעות שגיאות שקשורות להרשאות, פעלו לפי השלבים לפתרון בעיות שקשורות להרשאות.

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

‫kube-state-metrics מדדים לא נאספים

kube-state-metrics (KSM) פועל כפריסה של רפליקה אחת באשכול, ומייצר מדדים כמעט לכל המשאבים באשכול. כש-KSM ו-gke-metrics-agent פועלים באותו צומת, יש סיכון גבוה יותר להפסקת פעילות של סוכני המדדים בכל הצמתים.

השמות של מדדי KSM מבוססים על התבנית kube_<ResourceKind>, למשל kube_pod_container_info. מדדים שמתחילים ב-kube_onpremusercluster_ מגיעים מבקר האשכול המקומי, ולא מ-KSM.

אם חסרים מדדי KSM, נסו את השלבים הבאים לפתרון הבעיה:

  • ב-Cloud Monitoring, בודקים את המעבד (CPU), הזיכרון ומספר ההפעלות מחדש של KSM באמצעות מדדי ה-API לסיכום, כמו kubernetes.io/anthos/container/... . זהו צינור עיבוד נתונים נפרד עם KSM. מוודאים שה-KSM Pod לא מוגבל בגלל מחסור במשאבים.
    • אם מדדי הסיכום האלה של ה-API לא זמינים ל-KSM, gke-metrics-agent באותו צומת כנראה יש את אותה בעיה.
  • באשכול, בודקים את הסטטוס והיומנים של ה-Pod של KSM ושל ה-Pod של gke-metrics-agent באותו צומת עם KSM.

לולאת קריסות של kube-state-metrics

תסמין

אין מדדים של kube-state-metrics ‏ (KSM) שזמינים ב-Cloud Monitoring.

הסיבה

התרחיש הזה סביר יותר באשכולות גדולים, או באשכולות עם כמויות גדולות של משאבים. ‫KSM פועל כ-Deployment של רפליקה אחת ומציג כמעט את כל המשאבים באשכול, כמו Pods, ‏ Deployments, ‏ DaemonSets,‏ ConfigMaps, ‏ Secrets ו-PersistentVolumes. המדדים נוצרים בכל אחד מאובייקטי המשאבים האלה. אם באחד מהמשאבים יש הרבה אובייקטים, כמו אשכול עם יותר מ-10,000 Pods, יכול להיות שייגמר הזיכרון של KSM (אין זיכרון פנוי).

גרסאות שהושפעו

הבעיה הזו יכולה להתרחש בכל גרסה של Google Distributed Cloud.

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

תיקון ופתרון עקיף

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

  • משתמשים ב-kubectl describe pod או ב-kubectl get pod -o yaml ובודקים את הודעת הסטטוס של השגיאה.
  • בודקים את מדד צריכת הזיכרון והניצול של KSM ומוודאים אם הוא מגיע למגבלה לפני ההפעלה מחדש.

אם וידאתם שהבעיה היא אין זיכרון פנוי (OOM), אתם יכולים להשתמש באחד מהפתרונות הבאים:

  • מגדילים את בקשת הזיכרון ואת המגבלה של KSM.

    כדי לשנות את המעבד (CPU) והזיכרון של KSM:

    • בגרסאות 1.16.0 ואילך של Google Distributed Cloud, ‏ Google Cloud Observability מנהל את KSM. כדי לעדכן את KSM, קראו את המאמר שינוי ברירת המחדל של בקשות ומגבלות של מעבד (CPU) וזיכרון לרכיב Stackdriver.

    • בגרסאות של Google Distributed Cloud מ-1.10.7 ואילך, מ-1.11.3 ואילך, מ-1.12.2 ואילך ומ-1.13 ואילך, אבל לפני 1.16.0, צריך ליצור ConfigMap כדי לשנות את המעבד (CPU) והזיכרון:

      1. יוצרים ConfigMap בשם kube-state-metrics-resizer-config במרחב השמות kube-system (gke-managed-metrics-server לגרסה 1.13 ואילך) עם ההגדרה הבאה. משנים את מספר המעבדים (CPU) והזיכרון לפי הצורך:

          apiVersion: v1
  kind: ConfigMap
  metadata:
    name: kube-state-metrics-resizer-config
    namespace: kube-system
  data:
    NannyConfiguration: |-
      apiVersion: nannyconfig/v1alpha1
      kind: NannyConfiguration
      baseCPU: 200m
      baseMemory: 1Gi
      cpuPerNode: 3m
      memoryPerNode: 20Mi
  ```

      2. אחרי שיוצרים את ConfigMap, מוחקים את ה-Pod של KSM באמצעות הפקודה הבאה כדי להפעיל מחדש את הפריסה של KSM:

        kubectl -n kube-system rollout restart deployment kube-state-metrics

    • בגרסאות 1.9 ומטה, 1.10.6 ומטה, 1.11.2 ומטה ו-1.12.1 ומטה של Google Distributed Cloud:

      • אין פתרון טוב לטווח הארוך – אם עורכים את המשאב שקשור ל-KSM, השינויים מבוטלים באופן אוטומטי על ידי monitoring-operator.
      • אפשר לצמצם אנכית בהתאם לעומס (scale down) את monitoring-operator ל-0 רפליקות, ואז לערוך את פריסת ה-KSM כדי לשנות את מגבלת המשאבים שלה. עם זאת, האשכול לא יקבל תיקוני פגיעויות שמופצים בגרסאות תיקון חדשות באמצעות monitoring-operator. חשוב לזכור להגדיל את monitoring-operator בחזרה אחרי שמשדרגים את האשכול לגרסה מאוחרת יותר עם תיקון.

  • צמצום מספר המדדים מ-KSM.

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

    בגרסאות של Google Distributed Cloud שקודמות ל-1.13, ב-KSM נעשה שימוש בדגלי ברירת המחדל. ההגדרה הזו חושפת מספר גדול של מדדים.

לולאת קריסות של gke-metrics-agent

אם ב-gke-metrics-agent יש בעיות של אין זיכרון פנוי (OOM) רק בצומת שבו נמצא kube-state-metrics, הסיבה היא מספר גדול של מדדי kube-state-metrics. כדי לצמצם את הבעיה, אפשר להקטין את stackdriver-operator ולשנות את KSM כך שיחשוף קבוצה קטנה של מדדים נדרשים, כפי שמפורט בסעיף הקודם. חשוב לזכור להגדיל את stackdriver-operator אחרי שמשדרגים את האשכול ל-Google Distributed Cloud בגרסה 1.13, שבה KSM חושף כברירת מחדל מספר קטן יותר של מדדי ליבה.

אם הבעיות לא קשורות לאירועים של אין זיכרון פנוי (OOM), בודקים את היומנים של Pods ב-gke-metric-agent. כדי לשנות את המעבד והזיכרון של כל Pods של gke-metrics-agent, מוסיפים את השדה resourceAttrOverride למשאב המותאם אישית של Stackdriver.

לולאת קריסות של stackdriver-metadata-agent

תסמין

כשמסננים מדדים ב-Cloud Monitoring, אין תווית זמינה למטא-נתונים של המערכת.

הסיבה

הסיבה הנפוצה ביותר לקריסה בלולאה של stackdriver-metadata-agent היא אירועים של אין זיכרון פנוי (OOM). האירוע הזה דומה לאירוע kube-state-metrics. למרות ש-stackdriver-metadata-agent לא מפרט את כל המשאבים, הוא עדיין מפרט את כל האובייקטים של סוגי המשאבים הרלוונטיים כמו Pods,‏ Deployments ו-NetworkPolicy. הסוכן פועל כפריסה של רפליקה אחת, מה שמגדיל את הסיכון לאירועים של אין זיכרון פנוי (OOM) אם מספר האובייקטים גדול מדי.

הגרסה המושפעת

הבעיה הזו יכולה להתרחש בכל גרסה של Google Distributed Cloud.

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

תיקון ופתרון עקיף

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

  • משתמשים ב-kubectl describe pod או ב-kubectl get pod -o yaml ובודקים את הודעת הסטטוס של השגיאה.
  • בודקים את מדד צריכת הזיכרון והניצול של stackdriver-metadata-agent ומוודאים אם הוא מגיע למגבלה לפני ההפעלה מחדש.
אם אתם בטוחים שהבעיות נגרמות בגלל בעיות אין זיכרון פנוי (OOM), הגדילו את מגבלת הזיכרון בשדה resourceAttrOverride של המשאב בהתאמה אישית של Stackdriver.

לולאת קריסות של metrics-server

תסמין

‫Horizontal Pod Autoscaler ו-kubectl top לא פועלים באשכול.

הסיבה והגרסאות המושפעות

הבעיה הזו לא נפוצה, אבל היא נגרמת בגלל שגיאות של אין זיכרון פנוי (OOM) באשכולות גדולים או באשכולות עם צפיפות גבוהה של Pods.

הבעיה הזו יכולה להתרחש בכל גרסה של Google Distributed Cloud.

תיקון ופתרון עקיף

הגדלת מגבלות המשאבים של שרת המדדים. בגרסה 1.13 ואילך של Google Distributed Cloud, מרחב השמות של metrics-server וההגדרות שלו הועברו מ-kube-system אל gke-managed-metrics-server.

לא כל המשאבים מוסרים במהלך המחיקה של חשבון השירות של יומני הביקורת של Cloud

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

תסמין

הודעות השגיאה Permission denied (אין הרשאה) מוצגות במאגר ה-proxy של יומני הביקורת של Cloud.

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

curl -X GET -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/global/features/cloudauditlogging

מחליפים את PROJECT_NUMBER במספר הפרויקט.

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

הסיבה והגרסאות המושפעות

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

הבעיה הזו יכולה להתרחש בכל גרסה של Google Distributed Cloud.

תיקון ופתרון עקיף

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

    SERVICE_ACCOUNT_EMAILS="'SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com'"

    מחליפים את מה שכתוב בשדות הבאים:

    • PROJECT_ID: מזהה הפרויקט.
    • ‫SERVICE_ACCOUNT_NAME: השם של חשבון השירות.

    הרשימה המלאה אמורה להיראות כמו בדוגמה הבאה:

    "'sa_name1@example-project-12345.iam.gserviceaccount.com','sa_name2@example-project-12345.iam.gserviceaccount.com','sa_name3@example-project-12345.iam.gserviceaccount.com'"

  2. מריצים את הפקודה הבאה כדי להסיר את התכונה "יומני ביקורת של Cloud" מהפרויקט:

    curl -X DELETE -H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json" \
https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION /features/cloudauditlogging

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_NUMBER: מספר הפרויקט.
    • ‫FLEET_REGION: המיקום של האשכולות ב-Fleet. זה יכול להיות אזור ספציפי כמו us-central1 או global. אפשר להריץ את הפקודה gcloud container fleet memberships list כדי לקבל את מיקום החברות.

    הפקודה הזו מוחקת את כל חשבונות השירות.

  3. יוצרים מחדש את התכונה "יומני ביקורת של Cloud" רק עם חשבונות השירות שרוצים לשמור:

    curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    -H "Content-Type: application/json" \
    https://gkehub.googleapis.com/v1alpha/projects/PROJECT_NUMBER/locations/FLEET_REGION/features?feature_id=cloudauditlogging \
    -d '{"spec":{"cloudauditlogging":{"allowlistedServiceAccounts":[$SERVICE_ACCOUNT_EMAILS]}}}'

תוויות המטא-נתונים נעלמות מהמדדים

תסמין

תוויות של מטא-נתונים, כמו node_name, לא מאוכלסות ב-Cloud Monitoring.

הסיבה והגרסאות המושפעות

הבעיה הזו יכולה להתרחש בכל גרסה של Google Distributed Cloud.

תיקון ופתרון עקיף

כל שינוי ב-Pod יחזיר את תוויות המטא-נתונים. לדוגמה, הרצת פקודות כמו kubectl rollout restart deployment <workload_name>.

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

אם אתם צריכים עזרה נוספת, תוכלו לפנות אל Cloud Customer Care.

במאמר קבלת תמיכה תוכלו לקרוא מידע נוסף על משאבי התמיכה, כולל: