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

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

סקירה כללית

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

סוכן Logging של GKE

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

  • יומני פלט סטנדרטי (stdout) ושגיאה סטנדרטית (stderr) מתהליכים בקונטיינרים

  • יומני 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 מופעל כברירת מחדל.

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

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

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

קצב העברת הנתונים של הרישום ביומן

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

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

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

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

סוכן Logging שמוגדר כברירת מחדל ב-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, צריך להקצות את התפקיד roles/logging.logWriter ב-IAM לחשבון השירות שמצורף למאגר הצמתים הבסיסי.

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

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

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

הרשאת אדמין של משתמשים

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

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

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

  • רישום מובנה ביומן: סוכן Logging שמשולב ב-GKE יקרא מסמכי JSON שעברו סריאליזציה למחרוזות של שורה אחת ונכתבו לפלט סטנדרטי או לשגיאה סטנדרטית, וישלח אותם ל-Google Cloud Observability כרשומות ביומן מובנה.
    • למידע נוסף על עבודה עם סוכן Logging משולב, ראו רישום ביומן מובנה.
    • אתם יכולים להשתמש במסנני יומנים מתקדמים כדי לסנן יומנים על סמך השדות של מסמך ה-JSON.
    • ביומנים שנוצרו באמצעות glog, השדות הנפוצים ינותחו, למשל severity,‏ pid,‏ source_file,‏ source_line. עם זאת, המטען הייעודי (payload) של ההודעה עצמה לא מנותח ומופיע מילה במילה בהודעת היומן שנוצרת ב-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.
  • הפלט של היציאות הטוריות של הצומת, אם המטא-נתונים של המכונה הווירטואלית serial-port-logging-enable מוגדרים כ-true.

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

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

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

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

‫Vertical Pod autoscaler (גרסת טרום-השקה) KCP_VPA

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

מידע נוסף זמין במאמר הצגת אירועים של Vertical Pod Autoscaler.

חיבורים לרשת של מישור הבקרה KCP_CONNECTION

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

יומני חיבור לרשת נכנסת של מכונות במישור הבקרה של GKE. למידע נוסף, קראו את המאמר אימות החיבורים של Google למישור הבקרה של האשכול.

אירועי SSH במישור הבקרה KCP_SSHD

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

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

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

מכסה

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

אם תחרגו מהמכסה האזורית, יכול להיות שבקשות הכתיבה שלכם ל-Cloud Logging API יידחו ותופיע הודעת השגיאה "resource exhausted". חריגה מהמכסה הזו משפיעה על הניראות ועל פתרון הבעיות, אבל לא מגבילה את הפעולות של מישור הבקרה של GKE ולא משפיעה על עומסי העבודה שפועלים. במאמר בדיקת השימוש במכסה של Cloud Logging API מוסבר איך פותרים בעיות.

אמצעי בקרת גישה

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

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

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