Tentang log GKE

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

Ringkasan

Log GKE yang dikirim ke Cloud Logging disimpan dalam penyimpanan data khusus dan persisten. Meskipun GKE menyimpan log, log ini tidak disimpan secara permanen. Misalnya, log container GKE akan dihapus saat Pod host-nya dihapus, saat disk tempat log disimpan kehabisan ruang, atau saat log tersebut 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:

  • Log output standar dan error standar dari proses dalam container

  • Log kubelet dan runtime container

  • Log untuk komponen sistem, seperti skrip startup VM

Untuk peristiwa, GKE menggunakan deployment di namespace kube-system yang secara 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 termasuk log yang tercantum dalam log yang tersedia.

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

    Batasan berikut dapat menyebabkan log aplikasi gagal dikirim ke Cloud Logging:

    • Untuk log json, kunci json duplikat tidak didukung.
    • stream adalah kunci yang dicadangkan dalam pipeline logging GKE. Kunci stream dalam log json aplikasi dapat menyebabkan perilaku yang tidak terduga dan log yang dihilangkan.
    • Cloud Logging memiliki batas ukuran per LogEntry. LogEntry yang melebihi batas ukuran akan dihilangkan untuk log jsonPayload dan dipangkas untuk log textPayload.

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 scheduler mencakup semua log yang dihasilkan oleh Kubernetes Scheduler (kube-scheduler).

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

Untuk mempelajari lebih lanjut setiap komponen bidang kontrol ini, lihat Arsitektur cluster GKE.

Mengumpulkan log

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

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

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

Anda juga dapat mengonfigurasi cluster Standar untuk hanya menangkap log sistem dan tidak mengumpulkan log aplikasi. Untuk cluster Autopilot dan Standar, filter pengecualian memungkinkan Anda mengurangi volume log yang dikirim ke Cloud Logging.

Throughput logging

Saat logging sistem diaktifkan, agen Cloud Logging khusus akan otomatis di-deploy dan dikelola. Agen ini berjalan di semua node GKE dalam cluster untuk mengumpulkan log, menambahkan metadata yang berguna tentang container, pod, dan cluster, lalu mengirim log ke Cloud Logging menggunakan agen berbasis fluentbit.

Jika ada node GKE yang memerlukan throughput log lebih dari default dan cluster GKE Standar 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 dirancang untuk memaksimalkan throughput logging.

Untuk mengetahui informasi selengkapnya, lihat Menyesuaikan throughput log.

Pengumpulan log dengan fluentd atau fluentbit kustom

Agen logging default GKE men-deploy dan mengelola agen yang mengirim log untuk cluster Anda ke Cloud Logging. Log dikumpulkan menggunakan agen berbasis fluentbit.

Meskipun Anda tidak dapat menyesuaikan konfigurasi agen terkelola ini secara langsung, Anda dapat men-deploy DaemonSet fluentd atau fluentbit kustom Anda sendiri untuk mengumpulkan log aplikasi.

Untuk mengetahui informasi selengkapnya tentang konfigurasi logging yang tersedia, lihat bagian Log yang tersedia di halaman ini.

Mengumpulkan log auditd Linux untuk node GKE

Anda dapat mengaktifkan log audit sistem operasi panjang di 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, lihat Mengaktifkan log audit Linux di node GKE.

Log Audit GKE

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

Kontrol Akses Logging

Ada dua aspek kontrol akses logging: akses aplikasi dan akses pengguna. Cloud Logging menyediakan peran Identity and Access Management (IAM) roles 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 terlampir ke node pool yang mendasarinya.

Akses Lihat Pengguna

Anda harus memiliki peran roles/logging.viewer untuk melihat log di project Anda. Jika Anda 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 guide. 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 menyediakan 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 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 di-serialisasi ke string satu baris dan ditulis ke output standar atau error standar, lalu mengirimkannya ke Google Cloud Observability sebagai entri log terstruktur.
    • Lihat Logging terstruktur untuk mengetahui detail selengkapnya tentang cara menggunakan agen logging terintegrasi.
    • Anda dapat menggunakan Filter log lanjutan untuk memfilter log berdasarkan kolom dokumen JSON.
    • Log yang dihasilkan dengan glog akan memiliki kolom umum yang diuraikan, misalnya, severity, pid, source_file, source_line. Namun, payload pesan itu sendiri tidak diuraikan dan muncul verbatim dalam pesan log yang dihasilkan di Google Cloud Observability.
  • Tingkat keparahan: Secara default, log yang ditulis ke output standar berada di tingkat INFO dan log yang ditulis ke error standar berada di tingkat 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 perutean dan penyimpanan untuk mengetahui informasi lebih lanjut.

  • Pemberitahuan: Saat Logging mencatat perilaku yang tidak terduga, Anda dapat menggunakan metrik berbasis log untuk menyiapkan kebijakan pemberitahuan. Untuk contohnya, lihat Membuat kebijakan pemberitahuan pada metrik penghitung. Untuk mengetahui informasi mendetail tentang metrik berbasis log, lihat Ringkasan metrik berbasis log.

  • Pelaporan error: Untuk mengumpulkan error dari aplikasi yang berjalan di cluster Anda, Anda dapat menggunakan Pelaporan Error.

Log yang tersedia

Jika memilih untuk mengirim log ke Cloud Logging, Anda harus mengirim log sistem, dan secara opsional dapat mengirim log dari sumber tambahan.

Tabel berikut menunjukkan nilai yang didukung untuk flag --logging untuk perintah pembuatan dan update.

Sumber log Nilai --logging Log yang dikumpulkan
Tidak ada NONE Tidak ada log yang dikirim ke Cloud Logging; tidak ada agen pengumpulan log yang diinstal di cluster. Nilai ini tidak didukung untuk cluster Autopilot.
Sistem SYSTEM Mengumpulkan log dari hal berikut:
  • Semua Pod yang berjalan di namespace kube-system, istio-system, knative-serving, gke-system, dan config-management-system.
  • Layanan yang tidak dalam container, termasuk docker/containerd runtime, 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 benar (true).

Juga mengumpulkan peristiwa Kubernetes. Nilai ini diperlukan untuk semua jenis cluster.

Workload WORKLOAD Semua log yang dihasilkan oleh container non-sistem yang berjalan di node pengguna. Nilai ini aktif secara default, tetapi opsional untuk semua jenis cluster.
Server API API_SERVER Semua log yang dihasilkan oleh kube-apiserver. Nilai ini bersifat opsional untuk semua jenis cluster.
Scheduler SCHEDULER Semua log yang dihasilkan oleh kube-scheduler. Nilai ini bersifat opsional untuk semua jenis cluster.
Pengontrol manager CONTROLLER_MANAGER Semua log yang dihasilkan oleh kube-controller-manager. Nilai ini bersifat opsional untuk semua jenis cluster.
Autoscaler Pod Horizontal KCP_HPA

Mengekspor log keputusan rekomendasi atomik dan akhir untuk setiap objek HPA di cluster GKE Anda.

Untuk mengetahui detailnya, lihat Melihat peristiwa Autoscaler Pod Horizontal.
Koneksi jaringan bidang kontrol KCP_CONNECTION

Hanya tersedia dengan otoritas bidang kontrol GKE

Log koneksi jaringan masuk untuk instance bidang kontrol GKE instances. Untuk mengetahui detailnya, lihat Memverifikasi koneksi Google ke bidang kontrol cluster.
Peristiwa SSH bidang kontrol KCP_SSHD

Hanya tersedia dengan otoritas bidang kontrol GKE

Menghasilkan log untuk semua peristiwa SSH, seperti penerimaan kunci publik dan penutupan sesi, yang terjadi saat personel Google terhubung ke instance bidang kontrol cluster Anda selama kasus dukungan atau untuk akses administratif lainnya.

Untuk mengetahui detailnya, lihat Memverifikasi koneksi Google ke bidang kontrol cluster.

Harga

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

Anda akan dikenai biaya untuk biaya penyimpanan yang terakumulasi saat mengekspor log ke layanan Google Cloud lain, seperti BigQuery. Untuk mengetahui biaya yang terkait dengan Cloud Logging, lihat Harga.

Quota

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

Kontrol akses

Jika ingin membatasi akses dalam organisasi Anda ke log bidang kontrol Kubernetes, 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 pun 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 di bucket log terpisah dengan akses terbatas memungkinkan Anda menghapus log tanpa memengaruhi log dari komponen atau layanan lain.

Langkah berikutnya