Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Praktik terbaik untuk kemampuan pengamatan jaringan GKE

Autopilot Standard

Mengelola konektivitas jaringan dan kebijakan keamanan di lingkungan Kubernetes yang dinamis menimbulkan tantangan operasional yang signifikan. Kemampuan observasi GKE Dataplane V2 memberi administrator platform visibilitas tingkat kernel ke dalam traffic jaringan cluster, yang dapat membantu mengaktifkan pemecahan masalah yang cepat, audit kepatuhan berkelanjutan, dan validasi jalur proaktif.

Dokumen ini menguraikan arsitektur konseptual dan praktik terbaik untuk kemampuan pengamatan jaringan Google Kubernetes Engine (GKE), termasuk stack telemetri, model mental untuk triase, aturan pemberitahuan proaktif, otomatisasi Terraform, dan teknik pengoptimalan biaya.

Untuk petunjuk pemecahan masalah langkah demi langkah dan prosedur diagnostik, lihat Memecahkan masalah kemampuan pengamatan jaringan.

Manfaat kemampuan observasi jaringan GKE

Menerapkan strategi observabilitas di GKE memberikan keuntungan utama berikut:

Waktu Rata-Rata Penyelesaian Masalah (MTTR) yang Dipercepat: dengan memanfaatkan metrik yang didukung eBPF dan log alur Hubble, Anda dapat langsung mengisolasi anomali jaringan. Visibilitas ini memungkinkan Anda membedakan antara kegagalan tingkat aplikasi, pemblokiran NetworkPolicy Kubernetes, dan penghapusan firewall VPC, sehingga mengurangi siklus proses pen-debug-an dari berjam-jam menjadi beberapa menit.
Instrumentasi tingkat kernel tanpa sidecar: GKE Dataplane V2 menjalankan logika kemampuan pengamatan langsung dalam kernel Linux host menggunakan eBPF. Hal ini menghilangkan kebutuhan akan proxy sidecar yang intensif resource atau modifikasi kode tingkat aplikasi, sehingga memastikan biaya operasi minimal dan mempertahankan performa aplikasi.
Audit kepatuhan keamanan berkelanjutan: Logging NetworkPolicy menghasilkan log audit mendetail untuk setiap upaya koneksi (hasil ALLOW atau DENY). Log ini memberikan catatan traffic cluster yang kebal modifikasi, yang penting untuk memenuhi framework kepatuhan terhadap peraturan (seperti PCI-DSS, SOC 2, dan HIPAA).
Validasi jalur proaktif: integrasi dengan Uji Konektivitas memungkinkan Anda menyimulasikan jalur jaringan dan mengevaluasi NetworkPolicy GKE secara statis sebelum workload di-deploy, sehingga mencegah penyimpangan konfigurasi dan masalah konektivitas fase deployment.
Pengoptimalan resource dan biaya: Pelacakan alur yang mendetail akan mengekspos inefisiensi seperti penggunaan port Cloud NAT yang berlebihan, lonjakan transfer data antar-zona, dan pola resolusi DNS yang tidak di-cache, sehingga memungkinkan perencanaan kapasitas dan pengelolaan biaya yang lebih tepat.

Arsitektur kemampuan observasi jaringan GKE

GKE Dataplane V2 menawarkan stack kemampuan observasi berlapis yang dirancang untuk berbagai fase operasional. Tabel berikut menguraikan komponen inti dan kasus penggunaan yang direkomendasikan:

Komponen kemampuan observasi	Kasus penggunaan utama	Ketersediaan	Retensi data	Overhead performa	Sinyal telemetri utama
Metrik GKE Dataplane V2	Pemantauan kondisi, analisis tren, dan pemberitahuan di seluruh sistem.	Khusus GKE Dataplane V2	Retensi telemetri historis (Cloud Monitoring dan Google Cloud Managed Service for Prometheus menyimpan metrik dan log selama 30 hari atau lebih)	Dapat diabaikan (agregasi tingkat kernel)	Penghitung paket dan byte, jumlah reset TCP, dan rasio pelepasan koneksi (`pod_flow_drop_count`).
Log NetworkPolicy	Pengauditan kebijakan keamanan, analisis koneksi historis, dan kepatuhan.	Khusus GKE Dataplane V2 (untuk konfigurasi resource kustom `NetworkLogging`)	Dapat dikonfigurasi (Cloud Logging)	Rendah (ekspor log yang di-buffer)	Metadata koneksi (label sumber dan tujuan, alamat IP, port) dan hasil kebijakan (`ALLOW` atau `DENY`).
CLI dan UI Hubble	Analisis traffic interaktif secara langsung dan proses debug tingkat paket secara real-time.	Khusus GKE Dataplane V2	Efemer (buffer ring lokal node)	Rendah (aktifkan secara dinamis)	Perekaman aktivitas alur real-time, alasan penolakan yang mendetail (seperti ditolak kebijakan atau saturasi tabel conntrack).
Metrik DNS GKE	Memantau performa resolusi DNS, efisiensi cache, dan latensi upstream.	Semua cluster	Jangka panjang (Cloud Monitoring)	Negligible	Jumlah permintaan DNS, rasio cache ditemukan dan tidak ditemukan, latensi penerusan upstream, dan penolakan batas serentak.
Uji Konektivitas	Validasi jalur pra-deployment dan audit konfigurasi statis.	Semua cluster	Tidak berlaku (simulasi sesuai permintaan)	Tidak ada (disimulasikan secara statis)	Jalur perutean paket yang disimulasikan, termasuk evaluasi NetworkPolicy yang disimulasikan.
VPC Flow Logs	Audit traffic eksternal dan antar-node, forensik keamanan, dan analisis biaya.	Semua cluster	Dapat dikonfigurasi (Cloud Logging atau BigQuery)	Tidak ada (frekuensi pengambilan sampel yang dapat dikonfigurasi)	Detail koneksi 5-tuple, byte dan paket yang dikirim, metadata GKE (namespace, workload, layanan), dan RTT (untuk TCP).
Flow Analyzer	Analisis visual traffic VPC, mengidentifikasi sumber traffic teratas, dan menganalisis biaya lintas zona tanpa menulis kueri SQL.	Semua cluster	Bergantung pada retensi bucket Observability Analytics	Tidak ada (UI analitis)	Volume traffic dan latensi gabungan yang dikelompokkan menurut workload atau layanan GKE.

Dalam tabel sebelumnya, overhead performa Dapat Diabaikan berarti bahwa komponen tetap berada dalam jejak resource minimal (biasanya <0,1 vCPU dan memori minimal) terlepas dari volume traffic atau skala sistem. Komponen Rendah mempertahankan jejak minimal dalam kondisi standar, tetapi menskalakan secara dinamis dengan kepadatan traffic. Dalam skenario throughput tinggi, penggunaan resource dapat ditingkatkan skalanya hingga 2 vCPU dan beberapa ratus megabyte memori.

Model mental dan loop triase kemampuan observasi GKE

Untuk memecahkan masalah anomali jaringan secara efektif, Anda perlu memilih sinyal telemetri yang sesuai untuk cakupan operasional Anda dan mengikuti metodologi triase yang konsisten.

Memilih sumber telemetri yang tepat

Dengan tersedianya beberapa sumber telemetri, pilih alat yang sesuai dengan tugas operasional Anda saat ini:

Sumber telemetri	Jawaban	Ideal untuk	Google Cloud tujuan
Metrik GKE Dataplane V2	Apa yang terjadi dan dalam skala apa?	Dasbor, pemberitahuan, dan perencanaan kapasitas.	Cloud Monitoring (`prometheus.googleapis.com`)
Log NetworkPolicy	Mengapa koneksi diblokir di dalam GKE?	Audit keamanan dan analisis penyebab utama kebijakan keamanan.	Cloud Logging (log `policy-action`)
VPC Flow Logs	Apa yang terjadi pada traffic ini setelah keluar dari Pod?	Analisis traffic historis antara workload, biaya transfer data antar-zona, dan atribusi pelepasan tingkat VPC.	Cloud Logging dan Observability Analytics (`vpc_flows` log)
Hubble CLI dan UI	Apa yang sedang melewati node saat ini?	Proses debug langsung, alternatif tcpdump, dan insiden aktif.	Buffer ring sementara (Hubble CLI)
Uji Konektivitas	Apakah traffic dapat melakukan perjalanan dengan berhasil?	Analisis jalur dan pemeriksaan dataplane aktif: verifikasi jangkauan dan identifikasi titik pelepasan yang tepat di seluruh firewall VPC, rute, dan node GKE.	Network Intelligence Center (simulasi)

Loop pemecahan masalah standar

Gunakan alur kerja yang dapat diulang ini untuk menyeleksi insiden jaringan GKE:

Mendeteksi anomali: mengidentifikasi masalah melalui pemberitahuan Cloud Monitoring (misalnya, lonjakan reset TCP, penolakan batas serentak DNS, atau kehilangan paket).
Isolasi tingkat: jalankan uji dasar VM GCE (lihat Triage untuk latensi tingkat node dan hambatan CNI) untuk menentukan apakah pemblokiran terjadi di dalam cluster GKE (CNI, NetworkPolicy, penyamaran IP) atau di luar di VPC (aturan firewall, perutean, Cloud NAT).
Selidiki akar masalah: lakukan analisis mendetail terhadap alur:
- Untuk insiden langsung: gunakan Hubble CLI (hubble observe) untuk melakukan streaming alur real-time dan mengidentifikasi alasan penurunan.
- Untuk masalah historis atau terputus-putus: kueri log NetworkPolicy atau VPC Flow Logs di Cloud Logging.
Validasi perbaikan: jalankan Uji Konektivitas simulasi untuk memverifikasi bahwa jalur diizinkan secara statis, lalu periksa dasbor metrik untuk mengonfirmasi bahwa rasio pelepasan telah kembali ke nol.

Pemantauan dan pemberitahuan jaringan proaktif

Untuk mempertahankan ketersediaan tinggi, administrator platform harus membuat kebijakan pemberitahuan di Cloud Monitoring untuk mengidentifikasi penurunan kualitas jaringan sebelum memengaruhi beban kerja.

Pemberitahuan tentang lonjakan paket yang hilang

Peningkatan anomali pada aliran jaringan yang terputus biasanya menunjukkan kebijakan keamanan yang salah dikonfigurasi atau kelelahan pelacakan koneksi (conntrack) tingkat node.

Kueri Prometheus (PromQL):

sum(rate(pod_flow_egress_flows_count{verdict="DROPPED"}[5m])) by (source) > 10

Tindakan yang disarankan: lihat Mendiagnosis paket yang terputus dan pemblokiran NetworkPolicy untuk mengisolasi alasan paket terputus atau eBPF NetworkPolicy GKE tertentu yang menyebabkan paket hilang.

Peringatan tentang saturasi DNS

Saat CoreDNS atau NodeLocal DNSCache mencapai batas kueri serentaknya, pencarian DNS berikutnya akan ditolak, sehingga menyebabkan waktu tunggu aplikasi terputus-putus.

Kueri Prometheus (PromQL):

sum by (cluster_name) (rate(kubernetes_io_networking_dns_kubedns_max_concurrent_rejected_request_count[5m])) > 0

Tindakan yang direkomendasikan: menskalakan jumlah replika kube-dns atau menerapkan NodeLocal DNSCache untuk mendistribusikan beban resolusi. Untuk mengetahui langkah-langkah mendetail, lihat Mendiagnosis kegagalan resolusi DNS.

Pemberitahuan tentang lonjakan reset TCP

Lonjakan paket reset TCP sering menunjukkan bahwa layanan backend menolak koneksi, kemungkinan karena loop error aplikasi atau saturasi antrean soket.

Monitoring Query Language (MQL):

fetch prometheus_target
| metric 'prometheus.googleapis.com/hubble_tcp_flags_total/counter'
| filter (metric.flag == 'RST')
| align rate(1m)
| every 1m
| group_by [metric.source, metric.destination], sum(val())
| condition val() > 50

Tindakan yang disarankan: lihat Mendiagnosis ketidakseimbangan traffic dan reset TCP untuk menyelidiki kelekatan koneksi atau saturasi antrean aplikasi.

Validasi jalur otomatis di CI/CD

Integrasikan Uji Konektivitas ke dalam pipeline deployment untuk memvalidasi jalur jaringan secara statis sebelum merutekan traffic produksi. Gunakan gcloud CLI untuk memverifikasi bahwa workload yang baru di-deploy dapat menjangkau dependensi eksternal (seperti database dan API) tanpa pemblokiran kebijakan.

Contoh perintah:

gcloud network-management connectivity-tests create test-prod-db-egress \
    --source-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/my-app-pod \
    --destination-ip-address=10.240.0.100 \
    --protocol=TCP \
    --destination-port=5432

Aktifkan Analisis Observabilitas untuk analisis alur visual

Untuk mengaktifkan analisis visual tanpa SQL pada alur traffic VPC, upgrade bucket log GKE (biasanya bucket _Default) agar dapat menggunakan Observability Analytics. Dengan begitu, administrator platform dapat memanfaatkan Flow Analyzer untuk menyelidiki distribusi traffic dan biaya transfer data. Untuk mengetahui informasi selengkapnya, lihat Menganalisis biaya dan performa traffic cluster menggunakan Flow Analyzer.

Otomatisasi Terraform: Observability-as-Code

Untuk menerapkan arsitektur kemampuan pengamatan ini secara konsisten dan menghindari kesalahan penyiapan manual, deploy pipeline telemetri menggunakan konfigurasi Terraform berikut (memerlukan penyedia google-beta):

# Configure the VPC Subnet with VPC Flow Logs enabled and all metadata included
resource "google_compute_subnetwork" "gke_subnet" {
  name          = "gke-subnet"
  ip_cidr_range = "10.0.0.0/20"
  region        = "us-central1"
  network       = google_compute_network.custom.id

  # Enable VPC Flow Logs. flow_sampling is the secondary sampling rate, which
  # applies to flow log entries after they are generated. The primary packet
  # sampling rate is dynamic and isn't configurable.
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.5 # Default rate; satisfies the LIGHT org policy tier
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

# Configure GKE Cluster with Dataplane V2, Intranode Visibility, and Hubble
resource "google_container_cluster" "primary" {
  provider   = google-beta
  name       = "gke-observability-cluster"
  location   = "us-central1"
  network    = google_compute_network.custom.id
  subnetwork = google_compute_subnetwork.gke_subnet.id

  # Enable Dataplane V2 (Required for all advanced telemetry)
  datapath_provider = "ADVANCED_DATAPATH"

  # Enable Intranode Visibility (ensures local node pod-to-pod traffic hits the VPC)
  enable_intranode_visibility = true

  # Enable Managed Service for Prometheus (GMP)
  monitoring_config {
    enable_components = ["SYSTEM_COMPONENTS"]
    managed_prometheus {
      enabled = true
    }

    # Enable Dataplane V2 Flow Observability (Hubble Relay and metric exposure)
    advanced_datapath_observability_config {
      enable_metrics = true
      enable_relay   = true
    }
  }
}

# Upgrade the Default log bucket to use Log Analytics (required for Flow Analyzer)
resource "google_logging_project_bucket_config" "default_analytics" {
  project          = var.project_id
  location         = "global"
  bucket_id        = "_Default"
  enable_analytics = true
}

# Define a baseline static path validation test (Pod to external internet gateway)
resource "google_network_management_connectivity_test" "pod_to_internet" {
  name = "pod-to-internet-egress"
  source {
    gke_pod = "projects/${var.project_id}/locations/us-central1/clusters/${google_container_cluster.primary.name}/k8s/namespaces/prod/pods/my-app-pod"
  }
  destination {
    ip_address = "8.8.8.8"
    port       = 443
  }
  protocol = "TCP"
}

Pengoptimalan biaya dan pengurangan bising

Telemetri jaringan (metrik dan log) dapat menghasilkan volume data yang besar, sehingga menyebabkan biaya penyerapan dan penyimpanan yang tinggi. Gunakan strategi berikut untuk mengoptimalkan pengumpulan telemetri tanpa kehilangan visibilitas ke traffic penting:

Menonaktifkan log koneksi yang diizinkan

Secara default, logging NetworkPolicy mencatat koneksi yang diizinkan dan ditolak. Koneksi yang diizinkan mendominasi volume log (sering kali 99% atau lebih dari traffic). Anda dapat memperbarui konfigurasi NetworkLogging cluster untuk merekam hanya koneksi yang ditolak (pelepasan), yang secara signifikan mengurangi biaya logging:

Simpan manifes berikut sebagai network-logging-config.yaml:

apiVersion: networking.gke.io/v1alpha1
kind: NetworkLogging
metadata:
  name: default
spec:
  cluster:
    allow:
      log: false # Disable logging for allowed traffic
      delegate: false
    deny:
      log: true  # Keep logging for blocked traffic (critical for security/triage)
      delegate: false

Terapkan konfigurasi:

kubectl apply -f network-logging-config.yaml

Mendelegasikan pencatatan melalui anotasi

Untuk kontrol biaya yang lebih mendetail, delegasikan logging ke anotasi dengan menetapkan delegate: true di resource kustom NetworkLogging. Konfigurasi ini memastikan hal berikut:

Traffic yang diizinkan hanya dicatat jika NetworkPolicy yang cocok memiliki anotasi policy.network.gke.io/enable-logging: "true".
Traffic yang ditolak hanya dicatat untuk objek Pod di namespace yang diberi anotasi dengan policy.network.gke.io/enable-deny-logging: "true".

Konfigurasi ini memungkinkan Anda mengaktifkan logging hanya untuk beban kerja yang sangat penting (seperti gateway pembayaran) sambil mengabaikan layanan yang berisik dan berisiko rendah.

Menyesuaikan frekuensi pengambilan sampel Log Aliran VPC

Dalam konfigurasi Terraform (atau konsol Google Cloud ), turunkan frekuensi pengambilan sampel sekunder hanya di subnet tempat Anda memerlukan volume traffic dan agregat biaya, bukan catatan alur individual. Karena Log Aliran VPC memperkirakan total traffic dari paket yang diambil sampelnya, jumlah byte dan paket tetap dapat digunakan untuk analisis biaya pada frekuensi yang lebih rendah. Jangan menetapkan tarif flow_sampling lebih rendah dari 0.1, tarif minimum yang memenuhi tingkat ESSENTIAL dari kebijakan organisasi constraints/compute.requireVpcFlowLogs:

resource "google_compute_subnetwork" "gke_subnet" {
  # ... other subnet configs ...
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.1 # ESSENTIAL tier: volume and cost analysis, not per-flow troubleshooting
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

Tabel berikut merangkum rasio pengambilan sampel sekunder dan tingkat kebijakan organisasi constraints/compute.requireVpcFlowLogs yang sesuai:

Frekuensi sampling sekunder	Tingkatan kebijakan organisasi	Kapan menggunakannya
`1.0`	`COMPREHENSIVE`	Cluster dengan persyaratan tetap untuk forensik per aliran atau audit keamanan. Pilih tarif ini saat Anda mengonfigurasi subnet, karena menaikkan tarif setelah insiden tidak akan memulihkan alur yang tidak pernah diambil.
`0.5` (default)	`LIGHT`	Subnet yang mendukung cluster yang Anda pecahkan masalahnya. Ini adalah rasio default dan tolok ukur yang direkomendasikan.
`0.1`	`ESSENTIAL`	Subnet tempat Anda memerlukan gabungan volume traffic dan biaya, bukan aliran individual.

Menerapkan pengecualian Cloud Logging

Mengecualikan log yang tidak relevan atau mengganggu (seperti kube-systemtraffic internal) langsung di tingkat sink Cloud Logging. Tambahkan filter pengecualian ke sink _Default Anda untuk menghapus metadata internal atau log Pod sistem:

resource.type="gce_subnetwork" AND
log_name:"projects/PROJECT_ID/logs/compute.googleapis.com%2Fvpc_flows" AND
jsonPayload.src_gke_details.pod.pod_namespace="kube-system"

Praktik terbaik dan tips operasional

Pertimbangkan panduan operasional berikut saat men-deploy dan memelihara pipeline telemetri cluster Anda:

Mengaktifkan kemampuan observasi aliran GKE Dataplane V2 sesuai permintaan: Kemampuan observasi aliran (hubble-relay) dapat menimbulkan sedikit overhead. Untuk cluster produksi, Anda dapat mengaktifkannya selama sesi proses debug dan menonaktifkannya setelahnya untuk meminimalkan konsumsi resource pada node:
```
gcloud container clusters update CLUSTER_NAME \
    --enable-dataplane-v2-flow-observability \
    --location=LOCATION
```
Aktifkan Visibilitas Intranode: secara default, traffic antara dua objek Pod di node yang sama tidak meninggalkan node, sehingga tidak terlihat oleh VPC Flow Logs. Visibilitas Intranode diaktifkan secara default di cluster Autopilot dan dinonaktifkan secara default di cluster Standard, termasuk cluster Standard yang menggunakan GKE Dataplane V2. Mengaktifkan Visibilitas Intranode membelokkan traffic ini melalui VPC, dan membantu memastikan bahwa aturan firewall dan log aliran VPC diterapkan secara konsisten.
Memahami perilaku penyelesaian VIP Service: setelah IP Virtual (VIP) Service Kubernetes diselesaikan ke alamat IP Pod backend, metrik lapisan transport (OSI Layer 4) menghitungnya sebagai traffic pod-ke-pod. Untuk melacak VIP Layanan mana yang awalnya ditargetkan, andalkan alur live Hubble CLI selama handshake koneksi.
Menyelaraskan stempel waktu metrik dan log: saat menyelidiki insiden, korelasikan lonjakan metrik Cloud Monitoring dengan rentang waktu yang tepat saat membuat kueri log di Cloud Logging atau Hubble CLI untuk memastikan Anda menganalisis peristiwa yang sama.