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

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

לקבלת עזרה נוספת, אפשר לפנות אל Cloud Customer Care.

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

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

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

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

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

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

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

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

לא נאספים מדדים של 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 crash looping

תסמין

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

הסיבה

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

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

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

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

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

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

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

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

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

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

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

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

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

          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, מפעילים מחדש את הפריסה של KSM על ידי מחיקת ה-Pod של 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.
      • אפשר להקטין את מספר הרפליקות 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 crash looping

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

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

stackdriver-metadata-agent crash looping

תסמין

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

הסיבה

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

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

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

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

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

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

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

metrics-server crash looping

תסמין

התכונות Horizontal Pod Autoscaler ו-kubectl top לא פועלות באשכול.

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

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

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

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

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

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

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

תסמין

הודעות השגיאה Permission denied מוצגות במאגר של פרוקסי Cloud Audit Logs.

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

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 Audit Logs מהפרויקט:

    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: המיקום של החברים בצי לאשכולות. זה יכול להיות אזור ספציפי כמו 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.

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