מידע על יומני GKE

בדף הזה מובאת סקירה כללית של אפשרויות הרישום שזמינות ב-Google Kubernetes Engine ‏ (GKE).

סקירה כללית

יומני GKE שנשלחים אל Cloud Logging מאוחסנים במאגר נתונים ייעודי וקבוע. למרות ש-GKE עצמו מאחסן יומנים, היומנים האלה לא מאוחסנים באופן קבוע. לדוגמה, יומנים של קונטיינרים ב-GKE מוסרים כשה-Pod המארח שלהם מוסר, כשנגמר המקום בדיסק שבו הם מאוחסנים או כשהם מוחלפים ביומנים חדשים יותר. יומני המערכת מוסרים מעת לעת כדי לפנות מקום ליומנים חדשים. אירועים מקובצים מוסרים אחרי שעה.

סוכן הרישום ביומן (logging) של GKE

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

  • יומני פלט רגילים ויומני שגיאות רגילים מתהליכים במאגרים

  • יומני kubelet ויומני זמן ריצה של מאגרי מידע

  • יומנים של רכיבי מערכת, כמו סקריפטים להפעלה של מכונות וירטואליות

במקרה של אירועים, GKE משתמש בפריסה במרחב השמות kube-system, שאוספת אירועים באופן אוטומטי ושולחת אותם ל-Logging.

אילו יומנים נאספים

כברירת מחדל, מערכת GKE אוספת כמה סוגים של יומנים מהאשכול ומאחסנת אותם ב-Cloud Logging:

  • יומני הביקורת כוללים את יומן פעילות האדמין, יומן הגישה לנתונים ויומן האירועים. למידע מפורט על יומני הביקורת של GKE, אפשר לעיין במסמכי התיעוד בנושא יומני ביקורת של GKE. אי אפשר להשבית את יומני הביקורת של GKE.

  • יומני מערכת, כולל היומנים שמפורטים ביומנים זמינים.

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

    יכול להיות שההגבלות הבאות יגרמו לכך שיומני האפליקציה לא יישלחו אל Cloud Logging:

    • במקרה של יומני JSON, אין תמיכה במפתחות JSON כפולים.
    • ‫stream הוא מפתח שמור בצינור העברת הנתונים של רישום ביומן ב-GKE. מפתח stream ביומן JSON של האפליקציה עלול לגרום להתנהגות לא צפויה ולשגיאה ביומנים.
    • ב-Cloud Logging יש מגבלת גודל לכל LogEntry. כל LogEntry שחורג ממגבלת הגודל מושמט ביומני jsonPayload, ונחתך ביומני textPayload.

אופציונלי, GKE יכול לאסוף סוגים נוספים של יומנים מרכיבים מסוימים של מישור הבקרה של Kubernetes ולאחסן אותם ב-Cloud Logging:

  • יומני שרת ה-API כוללים את כל היומנים שנוצרו על ידי שרת ה-API של Kubernetes ‏(kube-apiserver).

  • יומני Scheduler כוללים את כל היומנים שנוצרו על ידי Kubernetes Scheduler‏ (kube-scheduler).

  • יומני Controller Manager כוללים את כל היומנים שנוצרו על ידי Kubernetes Controller Manager‏ (kube-controller-manager).

מידע נוסף על כל אחד מרכיבי מישור הבקרה האלה זמין במאמר ארכיטקטורת אשכול GKE.

איסוף היומנים

כשיוצרים אשכול GKE חדש, השילוב עם Cloud Logging מופעל כברירת מחדל.

יומני המערכת והאפליקציות מועברים אל Log Router ב-Cloud Logging.

משם, אפשר להעביר את היומנים ל-Cloud Logging, להחריג אותם או לייצא אותם ל-BigQuery, ל-Pub/Sub או ל-Cloud Storage.

אפשר גם להגדיר אשכול רגיל כך שיתעד רק יומני מערכת ולא יאסוף יומני אפליקציות. גם באשכולות במצב Autopilot וגם באשכולות רגילים, מסנני החרגה מאפשרים לצמצם את נפח היומנים שנשלחים אל Cloud Logging.

תפוקת רישום ביומן

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

אם יש צורך בנפח נתונים גדול יותר של יומנים בכל אחד מצמתי GKE, ואם אשכול GKE Standard שלכם משתמש במישור בקרה מגרסה 1.23.13-gke.1000 ואילך, אתם יכולים להגדיר את GKE כך שיפרוס תצורה חלופית של סוכן רישום ביומן שנועדה למקסם את נפח הנתונים של היומנים.

מידע נוסף מופיע במאמר בנושא שינוי קצב העברת הנתונים של היומנים.

איסוף יומנים באמצעות fluentd או fluentbit בהתאמה אישית

סוכן הרישום ביומן שמוגדר כברירת מחדל ב-GKE פורס ומנהל את הסוכנים ששולחים את היומנים של האשכולות אל Cloud Logging. היומנים נאספים באמצעות סוכן שמבוסס על fluentbit.

למרות שאי אפשר להתאים אישית את ההגדרה של הסוכן המנוהל הזה באופן ישיר, אפשר לפרוס DaemonSet fluentd או fluentbit מותאמים אישית משלכם כדי לאסוף יומני אפליקציות.

מידע נוסף על הגדרות הרישום ביומן זמין בקטע יומנים זמינים בדף הזה.

איסוף יומנים של Linux‏ auditd לצומתי GKE

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

מידע נוסף זמין במאמר בנושא הפעלת יומני auditd של Linux בצמתי GKE.

יומני ביקורת של GKE

מידע מפורט על רשומות ביומן שרלוונטיות לסוגי המשאבים Kubernetes Cluster ו-GKE Cluster Operations זמין במאמר בנושא יומני ביקורת.

רישום ביומן של בקרת גישה

יש שני היבטים של רישום ביומן של בקרת גישה: גישה לאפליקציה וגישת משתמש. ב-Cloud Logging יש תפקידים בניהול זהויות והרשאות גישה (IAM) שאפשר להשתמש בהם כדי להעניק גישה מתאימה.

גישה לאפליקציות

לאפליקציות נדרשות הרשאות כדי לכתוב יומנים ב-Cloud Logging. ההרשאות האלה ניתנות על ידי הקצאת תפקיד ה-IAM‏ roles/logging.logWriter לחשבון השירות שמצורף למאגר הצמתים הבסיסי.

גישת משתמשים לתצוגה

כדי לראות את היומנים בפרויקט, צריכה להיות לכם הרשאת roles/logging.viewer. אם אתם צריכים גישה ליומני Data Access, אתם צריכים את הרשאת ה-IAM‏ logging.privateLogViewer.

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

גישת אדמין למשתמשים

תפקידי ה-IAM‏ roles/logging.configWriter ו-roles/logging.admin מספקים את היכולות האדמיניסטרטיביות. התפקיד roles/logging.configWriter נדרש כדי ליצור יעד ליומן, שמשמש בדרך כלל להפניית היומנים לפרויקט ספציפי או מרכזי. לדוגמה, אפשר להשתמש ביעד ליומן יחד עם מסנן יומן כדי להפנות את כל היומנים של מרחב שמות מסוים אל מאגר יומנים מרכזי.

מידע נוסף זמין במדריך בקרת גישה ל-Cloud Logging.

שיטות מומלצות

  • רישום מובנה ביומן: סוכן רישום ביומן שמשולב עם GKE יקרא מסמכי JSON שעברו סריאליזציה למחרוזות של שורה אחת ונכתבו לפלט רגיל או לשגיאה רגילה, וישלח אותם ל-Google Cloud Observability כרשומות מובְנות ביומן.
    • מידע נוסף על עבודה עם סוכן תיעוד משולב זמין במאמר בנושא תיעוד מובנה.
    • אפשר להשתמש במסנני יומנים מתקדמים כדי לסנן יומנים על סמך השדות במסמך ה-JSON.
    • ביומנים שנוצרו באמצעות glog, השדות הנפוצים ינותחו, למשל severity, pid, source_file, source_line. עם זאת, מטען הנתונים של ההודעה עצמו לא מנותח ומופיע כלשונו בהודעת היומן שמתקבלת ב-Google Cloud Observability.
  • רמות חומרה: כברירת מחדל, יומנים שנכתבים לפלט הסטנדרטי הם ברמה INFO, ויומנים שנכתבים לשגיאה הסטנדרטית הם ברמה ERROR. יומנים מובנים יכולים לכלול שדה severity, שמגדיר את רמת החומרה של היומן.
  • ייצוא ל-BigQuery: כדי לבצע ניתוח נוסף, אפשר לייצא יומנים לשירותים חיצוניים, כמו BigQuery או Pub/Sub. הפורמט והמבנה של היומנים שיוצאו ל-BigQuery נשמרים. מידע נוסף זמין במאמר סקירה כללית על ניתוב ואחסון.

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

  • דיווח על שגיאות: כדי לאסוף שגיאות מאפליקציות שפועלות באשכולות, אפשר להשתמש ב-Error Reporting.

יומנים זמינים

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

בטבלה הבאה מפורטים הערכים הנתמכים של הדגל --logging בפקודות create ו-update.

מקור יומן ערך של --logging היומנים שנאספו
ללא NONE לא נשלחו יומנים ל-Cloud Logging, ולא הותקן סוכן לאיסוף יומנים באשכול. הערך הזה לא נתמך באשכולות של Autopilot.
מערכת SYSTEM אוסף יומנים מהמקורות הבאים:
  • כל ה-Pods שפועלים במרחבי השמות kube-system, istio-system, knative-serving, gke-system ו-config-management-system.
  • שירותים שלא מבוססים על קונטיינרים, כולל זמן ריצה של docker/containerd, kubelet,‏ kubelet-monitor, node-problem-detector ו-kube-container-runtime-monitor.
  • הפלט של היציאות הטוריות של הצומת, אם המטא-נתונים של מופע ה-VM‏ serial-port-logging-enable מוגדרים כ-true.

גם אוסף אירועים של Kubernetes. חובה לציין את הערך הזה לכל סוגי האשכולות.

עומסי עבודה WORKLOAD כל היומנים שנוצרו על ידי מאגרי מידע שאינם מערכתיים ופועלים בצמתים של משתמשים. הערך הזה מופעל כברירת מחדל, אבל הוא אופציונלי לכל סוגי האשכולות.
שרת API API_SERVER כל היומנים שנוצרו על ידי kube-apiserver. הערך הזה הוא אופציונלי לכל סוגי האשכולות.
Scheduler SCHEDULER כל היומנים שנוצרו על ידי kube-scheduler. הערך הזה הוא אופציונלי לכל סוגי האשכולות.
מנהל הבקרים CONTROLLER_MANAGER כל היומנים שנוצרו על ידי kube-controller-manager. הערך הזה הוא אופציונלי לכל סוגי האשכולות.
Horizontal Pod Autoscaler (HPA) KCP_HPA

מייצא את יומני ההחלטות של ההמלצות האטומית והסופית לכל אובייקט HPA באשכול GKE.

פרטים נוספים מופיעים במאמר בנושא הצגת אירועים של Horizontal Pod Autoscaler.
Vertical Pod Autoscaler (טרום השקה) KCP_VPA

מייצא את יומני ההחלטות של כל אובייקט VPA באשכול GKE.

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

זמין רק עם שליטה במישור הבקרה של GKE

יומנים של חיבורים לרשתות נכנסות עבור מופעים של מישור הבקרה של GKE. פרטים נוספים זמינים במאמר בנושא אימות החיבורים של Google למישור הבקרה של האשכול.
אירועי SSH במישור הבקרה KCP_SSHD

זמין רק עם שליטה במישור הבקרה של GKE

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

פרטים נוספים זמינים במאמר בנושא אימות החיבורים של Google למישור הבקרה של האשכול.

תמחור

יומני GKE מיוצאים ל-Cloud Logging. התמחור של Cloud Logging חל.

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

מכסה

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

בקרות גישה

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

אם מאחסנים את היומנים האלה בקטגוריית יומנים נפרדת עם גישה מוגבלת, לא תהיה גישה אוטומטית ליומני מישור הבקרה בקטגוריית היומנים לכל מי שיש לו גישת roles/logging.viewer לפרויקט. בנוסף, אם מחליטים למחוק יומנים מסוימים של מישור הבקרה בגלל בעיות שקשורות לפרטיות או לאבטחה, אפשר לאחסן אותם בדלי יומנים נפרד עם גישה מוגבלת. כך אפשר למחוק את היומנים בלי להשפיע על יומנים מרכיבים או משירותים אחרים.

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