Tentang log GKE

Halaman ini menyediakan ringkasan opsi logging yang tersedia di Google Kubernetes Engine (GKE).

Ringkasan

Log GKE yang dikirim ke Cloud Logging disimpan di datastore khusus dan persisten. Meskipun GKE menyimpan log, log tersebut tidak disimpan secara permanen. Misalnya, log container GKE dihapus saat Pod host-nya dihapus, saat disk tempatnya disimpan kehabisan ruang, atau saat diganti dengan log yang lebih baru. Log sistem dihapus secara berkala untuk mengosongkan ruang bagi log baru. Peristiwa cluster dihapus setelah satu jam.

Agen logging GKE

Untuk log container dan sistem, GKE men-deploy, secara default, agen logging per node yang membaca log container, menambahkan metadata yang berguna, lalu menyimpannya di Cloud Logging. Agen logging GKE memeriksa log container di sumber berikut:

  • Output standar dan log error standar dari proses dalam container

  • log runtime kubelet dan container

  • Log untuk komponen sistem, seperti skrip startup VM

Untuk peristiwa, GKE menggunakan deployment di namespace sistem kube yang otomatis mengumpulkan peristiwa dan mengirimkannya ke Logging.

Log yang dikumpulkan

Secara default, GKE mengumpulkan beberapa jenis log dari cluster Anda dan menyimpannya di Cloud Logging:

  • Log audit mencakup log Aktivitas Admin, log Akses Data, dan log Peristiwa. Untuk mengetahui informasi mendetail tentang Log Audit untuk GKE, lihat dokumentasi Log Audit untuk GKE. Log audit untuk GKE tidak dapat dinonaktifkan.

  • Log sistem mencakup log dari sumber berikut:

    • Semua Pod yang berjalan di namespace kube-system, istio-system, knative-serving, gke-system, dan config-management-system.

    • Layanan utama yang tidak berada dalam container, termasuk runtime docker/containerd, kubelet, kubelet-monitor, node-problem-detector, dan kube-container-runtime-monitor.

    • Output port serial node, jika metadata instance VM serial-port-logging-enable ditetapkan ke true. Mulai GKE 1.16-13-gke.400, output port serial untuk node dikumpulkan oleh agen Logging. Untuk menonaktifkan logging output port serial, tetapkan --metadata serial-port-logging-enable=false selama pembuatan cluster. Output port serial berguna untuk memecahkan masalah error, booting gagal, masalah startup, atau masalah penonaktifan dengan node GKE. Menonaktifkan log ini dapat membuat pemecahan masalah menjadi lebih sulit.

  • Log aplikasi mencakup semua log yang dibuat oleh container non-sistem yang berjalan pada node pengguna.

Secara opsional, GKE dapat mengumpulkan jenis log tambahan dari komponen bidang kontrol Kubernetes tertentu dan menyimpannya di Cloud Logging:

  • Log server API mencakup semua log yang dihasilkan oleh server Kubernetes API (kube-apiserver).

  • Log penjadwal mencakup semua log yang dibuat oleh Penjadwal Kubernetes (kube-scheduler).

  • Log Controller Manager mencakup semua log yang dibuat oleh Kubernetes Controller Manager (kube-controller-manager).

Untuk mempelajari masing-masing komponen bidang kontrol ini lebih lanjut, lihat arsitektur cluster GKE.

Mengumpulkan log Anda

Saat Anda membuat cluster GKE baru, integrasi dengan Cloud Logging akan diaktifkan secara default.

Log sistem dan aplikasi dikirim ke Router Log di Cloud Logging.

Dari sana, log dapat diserap ke Cloud Logging, dikecualikan, atau diekspor ke BigQuery, Pub/Sub, atau Cloud Storage.

Mulai GKE versi 1.15.7, Anda dapat configure cluster Standar untuk hanya merekam log sistem dan tidak mengumpulkan log aplikasi. Untuk cluster Autopilot dan Standar, filter pengecualian dapat digunakan untuk mengurangi volume log yang dikirim ke Cloud Logging.

Throughput logging

Saat logging sistem diaktifkan, agen Cloud Logging khusus akan otomatis di-deploy dan dikelola. Cloud Logging berjalan pada semua node GKE dalam sebuah cluster untuk mengumpulkan log, menambahkan metadata bermanfaat tentang container, pod, dan cluster, lalu mengirimkan log tersebut ke Cloud Logging menggunakan agen berbasis fluentbit.

Jika node GKE memerlukan lebih dari throughput log default, dan cluster GKE Standard Anda menggunakan bidang kontrol versi 1.23.13-gke.1000 atau yang lebih baru, Anda dapat mengonfigurasi GKE untuk men-deploy konfigurasi alternatif agen Logging yang didesain untuk memaksimalkan throughput logging.

Untuk mengetahui informasi selengkapnya, lihat Menyesuaikan throughput log.

Koleksi log dengan fluentbit atau fluentbit kustom

Agen logging default GKE menyediakan solusi terkelola untuk men-deploy dan mengelola agen yang mengirim log untuk cluster Anda ke Cloud Logging. Bergantung pada versi bidang kontrol GKE Anda, fluentd atau fluentbit digunakan untuk mengumpulkan log. Mulai GKE 1.17, log dikumpulkan menggunakan agen berbasis fluentbit. Cluster GKE yang menggunakan versi sebelum GKE 1.17 menggunakan agen berbasis yang lancar. Jika ingin mengubah perilaku default agen fluentd, Anda dapat menjalankan agen fluentd yang disesuaikan atau agen fluentbit yang disesuaikan.

Kasus penggunaan umum mencakup:

  • menghapus data sensitif dari log Anda

  • mengumpulkan log tambahan yang tidak ditulis ke STDOUT atau STDERR

  • menggunakan setelan terkait performa tertentu

  • pemformatan log yang disesuaikan

Mengumpulkan log auditd Linux untuk node GKE

Anda dapat mengaktifkan log audit sistem operasi panjang pada node GKE yang menjalankan Container-Optimized OS. Log sistem operasi di node Anda memberikan informasi berharga tentang status cluster dan workload Anda, seperti pesan error, upaya login, dan eksekusi biner. Anda dapat menggunakan informasi ini untuk melakukan debug masalah atau menyelidiki insiden keamanan.

Untuk mempelajari lebih lanjut, baca bagian Mengaktifkan log audit Linux di node GKE.

Log Audit GKE

Untuk mengetahui informasi mendetail tentang entri log yang berlaku untuk jenis resource Cluster Kubernetes dan Operasi Cluster GKE, buka Logging audit.

Kontrol Akses Logging

Ada dua aspek kontrol akses logging: akses aplikasi dan akses pengguna. Cloud Logging memberikan peran Identity and Access Management (IAM) yang dapat Anda gunakan untuk memberikan akses yang sesuai.

Akses Aplikasi

Aplikasi memerlukan izin untuk menulis log ke Cloud Logging, yang diberikan dengan menetapkan peran IAM roles/logging.logWriter ke akun layanan yang dikaitkan ke kumpulan node yang mendasarinya.

Akses Lihat Pengguna

Anda harus memiliki peran roles/logging.viewer untuk melihat log di project Anda. Jika perlu memiliki akses ke log Akses Data, Anda harus memiliki izin IAM logging.privateLogViewer.

Untuk mengetahui informasi selengkapnya tentang izin dan peran, buka panduan Kontrol akses. Anda juga dapat meninjau Praktik terbaik untuk Cloud Audit Logs, yang juga berlaku untuk Cloud Logging secara umum.

Akses Admin Pengguna

Peran IAM roles/logging.configWriter dan roles/logging.admin memberikan kemampuan administratif. Peran roles/logging.configWriter diperlukan untuk membuat sink logging yang biasanya digunakan untuk mengarahkan log Anda ke project tertentu atau terpusat. Misalnya, Anda mungkin ingin menggunakan sink logging bersama dengan filter logging untuk mengarahkan semua log untuk sebuah namespace ke bucket logging terpusat.

Untuk mempelajari lebih lanjut, buka panduan Kontrol Akses untuk Cloud Logging.

Praktik terbaik

  • Logging terstruktur: Agen logging yang terintegrasi dengan GKE akan membaca dokumen JSON yang diserialisasi ke string satu baris dan ditulis ke output standar atau error standar, lalu akan mengirimkannya ke Kemampuan Observasi Google Cloud sebagai entri log terstruktur.
    • Lihat Logging terstruktur untuk detail selengkapnya tentang cara bekerja dengan agen logging terintegrasi.
    • Anda dapat menggunakan Filter log lanjutan untuk memfilter log berdasarkan kolom dokumen JSON.
    • Log yang dibuat dengan glog akan mengurai kolom umum, misalnya, severity, pid, source_file, source_line. Namun, payload pesan itu sendiri tidak diurai dan muncul kata demi kata dalam pesan log yang dihasilkan di Kemampuan Observasi Google Cloud.
  • Keparahan: Secara default, log yang ditulis ke output standar berada pada level INFO, dan log yang ditulis ke error standar berada pada level ERROR. Log terstruktur dapat menyertakan kolom severity, yang menentukan tingkat keparahan log.
  • Mengekspor ke BigQuery: Untuk analisis tambahan, Anda dapat mengekspor log ke layanan eksternal, seperti BigQuery atau Pub/Sub. Log yang diekspor ke BigQuery mempertahankan format dan strukturnya. Lihat Ringkasan pemilihan rute dan penyimpanan untuk informasi selengkapnya.
  • Pemberitahuan: Saat Logging mencatat perilaku yang tidak terduga, Anda dapat menggunakan metrik berbasis log untuk menyiapkan kebijakan pemberitahuan. Sebagai contoh, lihat Membuat kebijakan pemberitahuan pada metrik penghitung. Untuk informasi selengkapnya tentang metrik berbasis log, lihat Ringkasan metrik berbasis log.
  • Error Reporting: Untuk mengumpulkan error dari aplikasi yang berjalan di cluster, Anda dapat menggunakan Error Reporting.

Log bidang kontrol

Anda dapat mengonfigurasi cluster GKE untuk mengirim log yang dikeluarkan oleh server Kubernetes API, Scheduler, dan Controller Manager ke Cloud Logging.

Persyaratan

Pengiriman log yang dimunculkan oleh komponen bidang kontrol Kubernetes ke Cloud Logging memerlukan bidang kontrol GKE versi 1.22.0 atau yang lebih baru dan mengharuskan pengumpulan log sistem diaktifkan.

Mengonfigurasi kumpulan log bidang kontrol

Baca petunjuk untuk mengonfigurasi dukungan logging untuk cluster baru atau untuk cluster yang ada.

Harga

Log bidang kontrol GKE diekspor ke Cloud Logging. Harga Cloud Logging berlaku.

Kuota

Log bidang kontrol menggunakan kuota "Permintaan tulis per menit" dari Cloud Logging API. Sebelum mengaktifkan log bidang kontrol, periksa penggunaan puncak terbaru Anda dari kuota tersebut. Jika memiliki banyak cluster dalam project yang sama atau sudah mendekati batas kuota, Anda dapat meminta peningkatan batas kuota sebelum mengaktifkan log bidang kontrol.

Kontrol akses

Jika ingin membatasi akses ke log bidang kontrol Kubernetes dalam organisasi, Anda dapat membuat bucket log terpisah dengan kontrol akses yang lebih terbatas.

Dengan menyimpannya di bucket log terpisah dengan akses terbatas, log bidang kontrol di bucket log tidak akan otomatis dapat diakses oleh siapa saja yang memiliki akses roles/logging.viewer ke project. Selain itu, jika Anda memutuskan untuk menghapus log bidang kontrol tertentu karena masalah privasi atau keamanan, menyimpannya dalam bucket log terpisah dengan akses terbatas akan memungkinkan penghapusan log tersebut tanpa memengaruhi log dari komponen atau layanan lainnya.