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

טייס אוטומטי רגילה

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

סקירה כללית

יומני GKE שנשלחים אל Cloud Logging מאוחסנים במאגר נתונים ייעודי וקבוע. למרות ש-GKE עצמו מאחסן יומנים, היומנים האלה לא מאוחסנים באופן קבוע. לדוגמה, יומני GKE container מוסרים כשה-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 כוללים את כל היומנים שנוצרו על ידי שרת Kubernetes API ‏(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.

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

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

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

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

איסוף יומנים באמצעות 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 נדרש כדי ליצור sink לרישום ביומן, שמשמש בדרך כלל להפניית הרישומים לפרויקט ספציפי או מרכזי. לדוגמה, אפשר להשתמש ביעד של יומנים יחד עם מסנן יומנים כדי להפנות את כל היומנים של מרחב שמות לקטגוריה מרכזית של יומנים.

מידע נוסף זמין במדריך בקרת גישה ל-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` runtime, `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.
חיבורי רשת במישור הבקרה	`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 לפרויקט. בנוסף, אם מחליטים למחוק יומנים מסוימים של מישור הבקרה בגלל בעיות שקשורות לפרטיות או לאבטחה, אחסון שלהם בקטגוריה נפרדת ביומן עם גישה מוגבלת מאפשר למחוק את היומנים בלי להשפיע על יומנים מרכיבים או משירותים אחרים.