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 di penyimpanan data persisten khusus. Meskipun GKE sendiri menyimpan log, log ini tidak disimpan secara permanen. Misalnya, log container GKE dihapus saat Pod host-nya dihapus, saat disk tempat log tersebut disimpan kehabisan ruang, atau saat log tersebut digantikan oleh log yang lebih baru. Log sistem dihapus secara berkala untuk mengosongkan ruang bagi log baru. Acara cluster dihapus setelah satu jam.

Agen logging GKE

Untuk log sistem dan container, 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 yang di-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 apa 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 penampung 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 khusus dalam pipeline logging GKE. Kunci stream dalam log json aplikasi dapat menyebabkan perilaku yang tidak terduga dan log dihilangkan.
    • Cloud Logging memiliki batas ukuran per LogEntry. LogEntry yang melebihi batas ukuran akan dihapus 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 Controller 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 Anda

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

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

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

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

Throughput logging

Jika 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 mengirimkan 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 versi bidang kontrol 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 menyediakan solusi terkelola untuk men-deploy dan mengelola agen yang mengirim log untuk cluster Anda ke Cloud Logging. Log dikumpulkan menggunakan agen berbasis fluentbit.

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, lihat Mengaktifkan log auditd Linux di node GKE.

Log Audit GKE

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

Kontrol Akses Logging

Ada dua aspek kontrol akses logging: akses aplikasi dan akses pengguna. Cloud Logging menyediakan 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 terlampir pada kumpulan node pokok.

Akses Tampilan 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 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 diserialisasi 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 dibuat dengan glog akan memiliki kolom umum yang diuraikan, misalnya, severity, pid, source_file, source_line. Namun, payload pesan itu sendiri tidak diuraikan dan muncul kata demi kata dalam pesan log yang dihasilkan di Google Cloud Observability.
  • Tingkat keparahan: Secara default, log yang ditulis ke output standar berada di level INFO dan log yang ditulis ke error standar berada di 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 perutean dan penyimpanan untuk informasi lebih lanjut.

  • Pemberitahuan: Saat Logging mencatat perilaku yang tidak terduga, Anda dapat menggunakan metrik berbasis log untuk menyiapkan kebijakan pemberitahuan. Untuk mengetahui 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 Error Reporting.

Log yang tersedia

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

Tabel berikut menunjukkan nilai yang didukung untuk tanda --logging untuk perintah create 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 berikut ini:
  • Semua Pod yang berjalan di namespace kube-system, istio-system, knative-serving, gke-system, dan config-management-system.
  • Layanan yang tidak dikontainerkan, 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 disetel ke benar (true).

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

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

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

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

Hanya tersedia dengan otoritas bidang kontrol GKE

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

Hanya tersedia dengan otoritas bidang kontrol GKE

Membuat 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 panel kontrol cluster.

Log yang diaktifkan secara default di GKE Enterprise

Saat Anda membuat cluster GKE baru di Trusted Cloud by S3NS, log workload diaktifkan secara default untuk semua cluster Autopilot, tetapi dapat dinonaktifkan.

Untuk project edisi GKE Enterprise, log tambahan yang berguna diaktifkan secara default jika Anda mendaftar ke fleet saat membuat cluster.

Dalam tabel berikut, tanda centang () menunjukkan log mana yang diaktifkan secara default saat Anda membuat dan mendaftarkan cluster baru dalam project dengan GKE Enterprise yang diaktifkan:

Nama log Autopilot Standar
Sistem
Beban kerja
Server API
Scheduler
Controller Manager
Koneksi jaringan bidang kontrol
Peristiwa SSH bidang kontrol

Kuota

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 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 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, menyimpan log tersebut di bucket log terpisah dengan akses terbatas memungkinkan penghapusan log tanpa memengaruhi log dari komponen atau layanan lain.