Memecahkan masalah kemampuan observasi jaringan GKE

Autopilot Standard

Dokumen ini memberikan petunjuk dan prosedur diagnostik untuk mendiagnosis masalah jaringan di cluster Google Kubernetes Engine (GKE) menggunakan kemampuan observasi GKE Dataplane V2, Hubble, dan Cloud Monitoring.

Untuk ringkasan arsitektur dan praktik terbaik konseptual, lihat Praktik terbaik untuk kemampuan pengamatan jaringan.

Pohon keputusan pemecahan masalah dan konsep inti

Sebelum meninjau prosedur, gunakan matriks keputusan berikut untuk mengidentifikasi tingkat stack jaringan GKE yang kemungkinan menyebabkan masalah Anda, dan buka bagian yang sesuai.

Gejala atau pertanyaan diagnostik	Tingkat yang dicurigai	Prosedur yang direkomendasikan
Pod gagal me-resolve domain eksternal atau Layanan Kubernetes internal (waktu tunggu DNS habis, NXDOMAIN, SERVFAIL).	Tingkat 1: Pod dan Service (DNS)	Mendiagnosis kegagalan resolusi DNS
Layanan tidak dapat berkomunikasi; waktu tunggu koneksi habis atau paket dihentikan di antara Pod.	Tingkat 1: Pod dan Layanan (Kebijakan atau paket yang terputus)	Mendiagnosis paket yang terputus dan pemblokiran NetworkPolicy
Replika workload memiliki beban traffic yang tidak merata, atau Pod mencatat tingkat reset TCP (RST) yang tinggi.	Tingkat 1: Pod dan Layanan (Load balancing atau transport)	Mendiagnosis ketidakseimbangan traffic dan reset TCP
Latensi umum, waktu tunggu habis sesekali, atau memulai ulang CNI di seluruh node.	Tingkat 2: Node dan CNI (Kernel)	Triage untuk latensi tingkat node dan hambatan CNI
Pod tidak dapat menjangkau resource di luar GKE (Cloud SQL, API eksternal, atau VPC lainnya).	Tingkat 3: VPC dan perutean	Mengisolasi masalah konektivitas GKE versus VPC atau eksternal
Memerlukan simulasi jalur otomatis untuk memverifikasi apakah aturan firewall, rute, atau NetworkPolicy memblokir traffic.	Tingkat 3: VPC dan perutean (Simulasi)	Mendiagnosis konektivitas menggunakan Uji Konektivitas
Perlu mengidentifikasi workload mana yang mengirim traffic ke internet dan menjalani NAT.	Tingkat 4: Gateway eksternal dan biaya	Mengidentifikasi traffic NAT (keluar ke internet)
Biaya transfer data antar-zona yang tinggi atau perlu memvisualisasikan pengguna yang paling banyak menggunakan data tanpa menulis kueri SQL.	Tingkat 4: Gateway eksternal dan biaya	Menganalisis biaya dan performa traffic cluster menggunakan Flow Analyzer

Konsep jaringan inti

Jika Anda baru mengenal Kubernetes atau Google Cloud jaringan, ingatlah konsep inti berikut:

• eBPF (Extended Berkeley Packet Filter): teknologi sistem operasi yang memungkinkan program pemantauan dan perutean yang aman dijalankan langsung di dalam kernel Linux. GKE Dataplane V2 menggunakan eBPF untuk merutekan paket dan menerapkan NetworkPolicy dengan overhead performa minimal.
• Penyamaran IP (SNAT): proses penulisan ulang alamat IP sumber paket. Saat Pod GKE (yang memiliki alamat IP pribadi) berkomunikasi dengan internet atau resource VPC eksternal, GKE menyamarkan (menulis ulang) alamat IP Pod ke alamat IP node sehingga sistem eksternal mengetahui cara merutekan balasan.
• Pelacakan koneksi (Conntrack): fitur kernel yang melacak semua koneksi jaringan aktif. Di cluster GKE Dataplane V2, pelacakan ini dibagi antara dua tabel: conntrack kernel Linux standar (yang digunakan oleh ip-masq-agent) dan tabel conntrack yang dikelola Cilium dan GKE Dataplane V2 yang disimpan dalam peta eBPF. Jika node menangani terlalu banyak koneksi serentak, salah satu tabel pelacakan ini dapat terisi penuh (kelelahan conntrack), sehingga menyebabkan node secara diam-diam membuang paket baru.
• Hubble: mesin kemampuan observasi untuk GKE Dataplane V2. Alat ini berjalan di atas eBPF dan memberikan visibilitas real-time ke alur traffic, paket yang terputus, dan evaluasi NetworkPolicy.

Tingkat 1: Kemampuan observasi Pod dan Layanan (Aplikasi)

Tingkat Pod dan Service mencakup komunikasi jaringan antara Pod, Service, dan DNS cluster. Masalah di tingkat ini biasanya muncul sebagai waktu tunggu koneksi aplikasi habis, kegagalan resolusi nama, atau distribusi beban yang tidak merata.

Mendiagnosis kegagalan resolusi DNS

Tinjau cakupan diagnostik dan prasyarat sebelum memecahkan masalah DNS:

• Area fokus: komunikasi antara Pod dan CoreDNS atau NodeLocal DNSCache, latensi DNS, waktu tunggu resolusi DNS upstream, dan validasi NetworkPolicy FQDN.
• Prasyarat: Metrik GKE Dataplane V2 diaktifkan; akses kubectl.
• Kompatibilitas CNI: GKE Dataplane V2 (Advanced Datapath) dan CNI GKE standar.
• Gejala: Pod mencatat dial tcp: lookup <domain>: i/o timeout, NXDOMAIN, atau latensi terputus-putus pada panggilan API keluar.
• Tujuan: menentukan apakah kegagalan DNS berasal dari dalam cluster (saturasi kube-dns atau NodeLocal DNSCache), NetworkPolicy yang memblokir port UDP atau TCP 53, atau penurunan kualitas jaringan upstream.

Langkah 1: Pemeriksaan jangkauan dasar

Sebelum memecahkan masalah lapisan DNS, verifikasi apakah tujuan dapat dijangkau secara langsung menggunakan alamat IP-nya dari dalam Pod yang terpengaruh:

# 1. Test raw IP reachability (bypasses DNS entirely)
kubectl exec -it my-pod -n default -- curl -v --connect-timeout 5 http://10.240.0.10:8080

# 2. Test domain resolution
kubectl exec -it my-pod -n default -- curl -v --connect-timeout 5 http://my-service.default.svc.cluster.local:8080

• Jika koneksi IP berhasil, tetapi domain gagal: masalahnya terisolasi di lapisan resolusi DNS. Lanjutkan ke Langkah 2.
• Jika keduanya gagal: masalahnya adalah perutean tingkat jaringan atau penerapan kebijakan. Lanjutkan ke Mendiagnosis penurunan paket dan pemblokiran NetworkPolicy.

Memeriksa pengisian awal DNS FQDN NetworkPolicy

Jika cluster Anda menggunakan NetworkPolicy berbasis FQDN (FQDNNetworkPolicy), verifikasi bahwa nama domain diizinkan secara eksplisit. Jika Pod membuat kueri domain eksternal yang tidak diisi sebelumnya di cache proxy DNS GKE Dataplane V2 atau diizinkan oleh kebijakan, GKE Dataplane V2 akan memblokir traffic keluar ke alamat IP yang di-resolve:

# Verify whether UDP or TCP port 53 egress is permitted in the Pod's namespace
kubectl get networkpolicy -n default -o yaml | grep -A 5 -B 2 "port: 53"

Langkah 2: Periksa metrik DNS di Cloud Monitoring

GKE mengekspos metrik DNS bawaan di Cloud Monitoring dengan awalan kubernetes.io/networking/dns/.

Penting: Jika cluster Anda menggunakan Cloud DNS untuk GKE, kueri DNS tidak melintasi Pod kube-dns atau NodeLocal DNSCache. Metrik kube-dns ini tetap datar. Lihat dokumentasi Cloud DNS untuk pemecahan masalah kueri DNS dalam mode tersebut.

Untuk memeriksa metrik DNS di Cloud Monitoring, lakukan hal berikut:

1. Di konsol Google Cloud , buka Cloud Monitoring > Dashboards.
2. Pilih dasbor GKE DNS Observability - Cluster View yang telah ditentukan sebelumnya (atau buka Metrics Explorer dan filter kubernetes.io/networking/dns/).
3. Evaluasi sinyal utama berikut (untuk NodeLocal DNSCache, ganti kubedns dengan node_local_dns di jalur metrik):

Nama metrik	Nilai minimum peringatan	Akar masalah
kubernetes.io/networking/dns/kubedns/max_concurrent_rejected_request_count	> 0	Batas kueri serentak tercapai. kube-dns atau NodeLocal DNSCache membatalkan kueri.
kubernetes.io/networking/dns/kubedns/dns_request_latencies	p99 > 100 md	Latensi resolusi DNS end-to-end yang tinggi di kube-dns atau NodeLocal DNSCache.
kubernetes.io/networking/dns/kubedns/forwarding_request_latencies	p99 > 100 md	Latensi atau saturasi server DNS upstream.

Urutan triase performa dan waktu tunggu DNS

Ikuti urutan triase ini untuk mendiagnosis latensi DNS, cache miss, dan waktu tunggu habis upstream:

1. Periksa rasio cache ditemukan: kueri kubernetes.io/networking/dns/kubedns/dns_cache_request_count (atau node_local_dns/dns_cache_request_count) dikelompokkan menurut label cache_status. Jika cache_status="hit" rendah dan cache_status="miss" tinggi, aplikasi mungkin mengeluarkan kueri non-FQDN (seperti my-service, bukan my-service.default.svc.cluster.local), sehingga menyebabkan penelusuran jalur di semua entri dalam /etc/resolv.conf.
2. Mengevaluasi latensi upstream: nilai tinggi forwarding_request_latencies menunjukkan masalah pada server DNS upstream (misalnya, DNS lokal perusahaan yang dijangkau melalui Cloud Interconnect atau Cloud VPN, atau batas Cloud DNS).

3. Mengaudit penggantian DNS kustom: periksa kube-dns ConfigMap kustom untuk stub atau penerusan upstream yang salah dikonfigurasi:

   kubectl get configmap kube-dns -n kube-system -o yaml
   

Langkah 3: Streaming traffic DNS langsung dengan Hubble CLI

Gunakan alias helper Hubble CLI untuk memeriksa permintaan dan respons DNS live yang di-streaming dari kernel node:

# 1. Ensure the helper alias is set in your terminal session
alias gke-hubble="kubectl exec -it -n gke-managed-dpv2-observability deployment/hubble-relay -c hubble-cli -- hubble"

# 2. Observe live DNS (Port 53) traffic for a specific Pod
gke-hubble observe --pod default/my-pod --port 53

Catatan: Hubble CLI mem-parsing header DNS di lapisan aplikasi (Lapisan 7 OSI). Pada output alur, cari kolom DNS Query dan DNS Answer. Jika kueri menampilkan RCODE: NXDOMAIN atau RCODE: SERVFAIL, server DNS menolak atau tidak dapat me-resolve data.

Langkah 4: Validasi perbaikan

Jika penolakan kueri serentak terjadi, terapkan NodeLocal DNSCache untuk menyerap pencarian DNS frekuensi tinggi langsung di node tanpa mencapai batas kube-dns di seluruh cluster:

# Verify NodeLocal DNSCache DaemonSet is running
kubectl get daemonset node-local-dns -n kube-system

---

Mendiagnosis paket yang terputus dan pemblokiran NetworkPolicy

Tinjau cakupan diagnostik dan prasyarat sebelum menyelidiki penurunan paket dan penolakan kebijakan:

• Area fokus: penurunan traffic antara objek Pod atau antara objek Pod dan Service, penerapan NetworkPolicy, alasan penurunan eBPF kernel.
• Prasyarat: Kemampuan Observasi Flow GKE Dataplane V2 diaktifkan; logging NetworkPolicy dikonfigurasi.
• Kompatibilitas CNI: Hanya GKE Dataplane V2.
• Gejala: upaya koneksi aplikasi gagal dengan Connection timed out atau Connection reset by peer.
• Sasaran: menentukan alasan pasti NetworkPolicy atau eBPF yang membuang paket tanpa perubahan coba-coba pada kebijakan keamanan.

Langkah 1: Pantau metrik penurunan Hubble

Saat GKE Dataplane V2 melepaskan paket, GKE Dataplane V2 akan memancarkan metrik hubble_drop_total yang diberi tag dengan alasan pelepasan dan metadata sumber serta tujuan. Untuk memantau metrik pelepasan Hubble, lakukan hal berikut:

1. Jika belum dikonfigurasi, deploy resource PodMonitoring Google Cloud Managed Service for Prometheus untuk menyalin metrik Hubble:

   apiVersion: monitoring.googleapis.com/v1
   kind: PodMonitoring
   metadata:
     name: hubble-metrics
     namespace: gke-managed-dpv2-observability
   spec:
     selector:
       matchLabels:
         k8s-app: cilium
     endpoints:
     - port: hubble-metrics
       interval: 30s
   

2. Jalankan kueri berikut di Cloud Monitoring > Metrics Explorer untuk melihat penurunan menurut alasan:

   sum by (reason) (rate(hubble_drop_total[5m])) > 0
   

3. Menafsirkan kode reason umum:

   • Policy denied: NetworkPolicy Kubernetes secara eksplisit atau implisit memblokir koneksi.
   • CT: Map insertion failed: tabel pelacakan koneksi (conntrack) sudah penuh.
   • Unsupported L3 protocol: paket non-IPv4 atau IPv6 atau header yang rusak.

Langkah 2: Periksa log NetworkPolicy di Cloud Logging

Logging NetworkPolicy mengekspor log JSON terstruktur untuk semua keputusan kebijakan. Untuk mengirim kueri log NetworkPolicy di Cloud Logging, lakukan hal berikut:

1. Di konsol Google Cloud , buka Cloud Logging > Logs Explorer.

2. Jalankan kueri berikut:

   resource.type="k8s_node"
   log_name:"projects/PROJECT_ID/logs/events"
   jsonPayload.connection.verdict="DENY"
   jsonPayload.src.pod_name="my-source-pod"
   

3. Periksa payload JSON:

   • jsonPayload.drop_reason: menunjukkan alasan paket dihentikan.
   • jsonPayload.policies: mencantumkan NetworkPolicy yang dievaluasi. Jika daftar kosong ditampilkan dengan putusan DENY, namespace beroperasi dalam mode penolakan default dan tidak ada kebijakan yang mengizinkan traffic.

Jika tidak ada log NetworkPolicy yang muncul, verifikasi bahwa logging diaktifkan di resource kustom NetworkLogging cluster. Misalnya, periksa apakah kolom spec.cluster.deny.log ditetapkan ke true:

kubectl get networklogging default -o yaml

Langkah 3: Lacak penurunan live dengan Hubble CLI

Streaming rilis langsung secara langsung dengan menggunakan Hubble CLI untuk memeriksa paket real-time:

gke-hubble observe --verdict DROPPED --namespace default --follow

Contoh output:

TIMESTAMP             SOURCE               DESTINATION          TYPE     VERDICT
10:14:22.102          default/frontend     default/backend:80   to-stack DROPPED (Policy denied by NetworkPolicy: backend-deny-all)

Output menunjukkan NetworkPolicy yang tepat yang memblokir traffic (backend-deny-all).

Langkah 4: Periksa kehabisan conntrack

Jika alasan penurunan menunjukkan CT: Map insertion failed:

1. Periksa log agen GKE Dataplane V2 untuk mengetahui saturasi tabel conntrack:

   kubectl logs -n kube-system daemonset/anetd -c cilium-agent --tail=100 | grep "Conntrack table full"
   

2. Periksa ukuran maksimum tabel conntrack pada node yang terpengaruh:

   kubectl exec -it -n kube-system daemonset/anetd -c cilium-agent -- cilium status --all-controllers | grep -i conntrack
   

   Jika tabel conntrack penuh, lakukan penskalaan horizontal pada beban kerja Anda di lebih banyak node atau kurangi kecepatan koneksi dari Pod klien.

---

Mendiagnosis ketidakseimbangan traffic dan reset TCP

Tinjau cakupan diagnostik dan prasyarat sebelum memecahkan masalah ketidakseimbangan traffic dan reset koneksi:

• Area fokus: ketidakseimbangan load balancing, kegagalan handshake TCP, penghentian koneksi secara tiba-tiba.
• Prasyarat: Metrik GKE Dataplane V2 diaktifkan.
• Kompatibilitas CNI: GKE Dataplane V2.
• Gejala: replika Pod tertentu menerima traffic berlebih, sementara replika lainnya tetap tidak aktif; aplikasi klien mencatat connection reset by peer atau broken pipe.
• Sasaran: menentukan apakah ketidakseimbangan traffic disebabkan oleh kelekatan koneksi di lapisan transport (OSI Layer 4, TCP) versus lapisan aplikasi (OSI Layer 7, HTTP/2 atau gRPC), dan mengidentifikasi sumber paket TCP RST.

Langkah 1: Bandingkan alur traffic tingkat Pod

Untuk menentukan apakah traffic didistribusikan secara merata di seluruh replika, lakukan hal berikut:

1. Di Cloud Monitoring, kueri jumlah aliran ingress di semua Pod dalam Deployment:

   sum by (pod) (rate(pod_flow_ingress_flows_count{destination_workload="my-service"}[5m]))
   

2. Mengevaluasi distribusi traffic di seluruh Pod. Jika satu Pod menerima sebagian besar traffic, selidiki penggunaan ulang koneksi atau sesi persisten:

   • gRPC atau HTTP/2: koneksi TCP yang berjalan lama menyebabkan semua permintaan melalui satu aliran TCP ke satu Pod backend. Perutean Layanan Kubernetes lapisan transpor (OSI Layer 4, TCP) tidak dapat menyeimbangkan permintaan di dalam koneksi HTTP/2 yang sudah dibuat.
   • Afinitas Sesi ClientIP: verifikasi apakah Layanan dikonfigurasi dengan sessionAffinity: ClientIP.
   • Layanan Headless: klien dapat menyelesaikan DNS satu kali dan menyimpan alamat IP tunggal secara permanen.

Langkah 2: Analisis metrik reset TCP

Reset TCP (RST) menghentikan koneksi dengan segera. ICMP ini dipancarkan oleh kernel sistem operasi saat endpoint menerima paket untuk port yang tidak diketahui, atau saat aplikasi menutup koneksi dengan data yang belum dibaca dalam buffer.

Jalankan kueri MQL berikut di Cloud Monitoring:

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, metric.traffic_direction], sum(val())

Tinjau hasil kueri untuk menentukan sumber reset:

• RST keluar (traffic_direction=egress): Pod lokal membuat reset. Periksa apakah aplikasi Pod mengalami error, mencapai batas koneksinya, atau secara aktif menolak koneksi.
• RST masuk (traffic_direction=ingress): peer jarak jauh (database eksternal, API, atau Pod jarak jauh) mengirim reset. Periksa kondisi server tujuan dan status firewall.

Langkah 3: Streaming reset TCP secara langsung

Gunakan Hubble CLI untuk merekam handshake reset langsung:

gke-hubble observe --type trace --verdict FORWARDED --tcp-flags RST --namespace default

Langkah 4: Perbaikan dan solusi yang dapat ditindaklanjuti

Terapkan langkah-langkah perbaikan berikut, bergantung pada penyebab ketidakseimbangan traffic atau reset TCP:

• Untuk kelekatan koneksi gRPC atau lapisan aplikasi (OSI Layer 7):
  • Deploy Cloud Service Mesh untuk mengaktifkan load balancing tingkat permintaan (OSI Layer 7) di lapisan aplikasi.
  • Konfigurasi batas koneksi sisi klien atau waktu tunggu keep-alive (misalnya, gRPC MAX_CONNECTION_AGE dan MAX_CONNECTION_AGE_GRACE) untuk memaksa pembentukan ulang koneksi secara berkala.
• Untuk afinitas IP Layanan: hapus service.spec.sessionAffinity kecuali jika status aplikasi benar-benar memerlukannya.
• Untuk caching DNS Service headless: pastikan runtime aplikasi (seperti JVM networkaddress.cache.ttl) tidak menyimpan hasil DNS dalam cache tanpa batas waktu.
• Untuk overflow antrean backlog aplikasi: saat antrean pendengar aplikasi penuh, kernel Linux akan membuang paket SYN yang masuk atau mengirim TCP RST. Lakukan penskalaan replika Pod atau tingkatkan backlog pendengar aplikasi (somaxconn).

---

Tingkat 2: Kemampuan observasi Node dan CNI (Kernel)

Tingkat node dan CNI mencakup kernel Linux host, program eBPF, dan antarmuka jaringan node. Hambatan di tingkat ini memengaruhi semua beban kerja yang berjalan di node yang terpengaruh.

Pemeriksaan integritas sistem: Mendeteksi patching anetd yang tidak sah

Perhatian: Mengubah atau memulai ulang DaemonSet jaringan GKE Dataplane V2 (anetd) secara manual dapat menyebabkan gangguan jaringan di seluruh cluster dan melanggar tujuan tingkat layanan yang dikelola GKE.

GKE Dataplane V2 berjalan sebagai DaemonSet terkelola (anetd) di namespace kube-system. Di Cloud Logging, Anda dapat mengkueri log audit Kubernetes untuk mendeteksi apakah pengguna yang tidak sah atau skrip otomatis telah menerapkan patch atau memulai ulang anetd:

protoPayload.methodName="io.k8s.core.v1.daemonsets.patch" OR
protoPayload.methodName="io.k8s.core.v1.daemonsets.update"
protoPayload.resourceName="namespaces/kube-system/daemonsets/anetd"

Jika patching yang tidak sah terdeteksi, kembalikan DaemonSet ke konfigurasi default atau picu pembuatan ulang node pool untuk memulihkan status terkelola.

---

Triage untuk latensi tingkat node dan hambatan CNI

Tinjau cakupan diagnostik dan prasyarat sebelum mendiagnosis latensi tingkat node dan hambatan kernel:

• Area fokus: latensi kernel host, paket yang terputus di antarmuka VM, saturasi agen eBPF GKE Dataplane V2, kelelahan conntrack.
• Prasyarat: Metrik VM Compute Engine diaktifkan; kubectl akses.
• Kompatibilitas CNI: GKE Dataplane V2 dan CNI GKE standar.
• Gejala: traffic lintas node mengalami lonjakan latensi atau penurunan acak, sementara traffic intra-node tetap normal.
• Tujuan: membedakan antara throttling jaringan VM host, penurunan kernel Linux, dan hambatan tingkat CNI.

Langkah 1: Membedakan masalah di luar GKE dengan masalah di dalam GKE

Jalankan uji dasar VM Compute Engine: Deploy VM Compute Engine mandiri di subnet VPC yang sama dengan node cluster GKE. Uji konektivitas dari VM ke tujuan target.

• Jika VM mandiri mengalami latensi atau kehilangan paket yang sama: masalahnya berada di luar GKE (firewall VPC, Cloud NAT, Cloud Interconnect, atau server eksternal). Lanjutkan ke Mengisolasi masalah konektivitas GKE versus VPC atau eksternal.
• Jika VM mandiri berkomunikasi secara normal, tetapi Pod GKE gagal: masalahnya ada di dalam GKE (eBPF tingkat node, conntrack, atau CNI). Lanjutkan ke Langkah 2.

Batasan pengujian dasar VM: Pengujian ini mungkin tidak mendeteksi penurunan kecepatan yang terjadi sesekali atau penurunan kecepatan rendah yang hanya terjadi pada volume traffic gabungan yang tinggi. Selain itu, jika masalah hanya terjadi pada hardware pokok dari satu host VM, VM lain mungkin tidak mereproduksi perilaku tersebut.

Langkah 2: Membedakan masalah aplikasi dengan masalah tingkat node dan CNI

Memecahkan masalah tabrakan port SNAT ip-masq-agent kustom: Cluster yang menggunakan konfigurasi ip-masq-agent kustom dengan flag --random-fully dapat mengalami latensi keluar yang terputus-putus. Dengan volume traffic yang tinggi, iptables --random-fully mungkin mengalokasikan port sementara yang bertabrakan dengan NodePort aktif, sehingga menyebabkan penundaan koneksi. Upgrade ip-masq-agent ke versi 2.11.1 atau yang lebih tinggi, atau hapus --random-fully untuk menghindari konflik port.

Untuk menentukan apakah latensi berasal dari aplikasi atau di tingkat node dan CNI, lakukan hal berikut:

1. Periksa saturasi resource aplikasi: Pastikan node tidak mengalami pembatasan CPU atau tekanan memori, yang menunda pemrosesan paket di ruang pengguna:

   kubectl top nodes
   kubectl top pods -n default
   

2. Periksa jumlah conntrack kernel Linux: Periksa jumlah conntrack aktif di host:

   # On a node where you have debugging access
   cat /proc/sys/net/netfilter/nf_conntrack_count
   cat /proc/sys/net/netfilter/nf_conntrack_max
   

   Jika nf_conntrack_count mendekati nf_conntrack_max, kernel host akan melepaskan paket TCP SYN baru.

Langkah 3: Verifikasi paket yang terputus di tingkat VM menggunakan telemetri Compute Engine

Google Cloud Compute Engine mengekspor metrik antarmuka jaringan tingkat VM ke Cloud Monitoring.

Di Cloud Monitoring > Metrics Explorer, lakukan kueri:

sum by (drop_reason) (rate(compute_googleapis_com:instance_network_dropped_packets_count[5m]))

• FQ_CODEL_DROP: paket di-drop karena saturasi antrean Fair Queuing atau CoDel (batas bandwidth keluar VM terlampaui).
• FIREWALL_RULE_DROP: paket yang dihentikan oleh aturan firewall VPC.
• RATE_LIMIT_DROP: paket di-drop karena VM melampaui kuota paket per detik (PPS) maksimum antarmuka jaringannya.

Langkah 4: Menyelidiki penurunan tingkat kernel menggunakan eBPF

Jika metrik tingkat VM menunjukkan nol pelepasan, tetapi Pod GKE masih melepaskan paket, periksa agen GKE Dataplane V2 (anetd) untuk mengetahui pelepasan peta eBPF:

kubectl logs -n kube-system daemonset/anetd -c cilium-agent --tail=200 | grep -i "drop"

Cari ct-map-insertion-failed atau fib-lookup-failed.

---

Tingkat 3: Kemampuan pengamatan VPC dan Routing (Cloud Network)

Tingkat perutean VPC dan cloud menghubungkan node GKE ke layanan Google Cloud lain, jaringan lokal, dan internet. Kegagalan di sini biasanya berasal dari aturan firewall VPC, rute kustom, atau konfigurasi gateway.

Mengisolasi masalah konektivitas GKE versus VPC atau eksternal

Tinjau cakupan diagnostik dan prasyarat sebelum mengisolasi masalah jaringan eksternal dari kegagalan dalam cluster:

• Area fokus: isolasi batas antara perutean internal Kubernetes dan perutean cloud VPC.
• Prasyarat: gcloud CLI; izin untuk membuat Uji Konektivitas.
• Kompatibilitas CNI: semua cluster.
• Gejala: Pod gagal terhubung ke resource eksternal (misalnya, Cloud SQL, API lokal, atau endpoint pihak ketiga).
• Tujuan: dengan cepat menentukan apakah penurunan terjadi dalam node GKE atau di dalam Google Cloud VPC atau jaringan eksternal.

Langkah 1: Pengujian dasar VM Compute Engine

Untuk men-deploy VM dasar dan mengevaluasi apakah masalah berlanjut di luar GKE, lakukan hal berikut:

1. Deploy instance VM Compute Engine sementara di subnet dan zona VPC yang sama dengan node pool GKE Anda:

   gcloud compute instances create gke-baseline-tester \
       --zone=us-central1-a \
       --subnet=gke-subnet \
       --machine-type=e2-micro
   

2. Hubungkan ke instance menggunakan SSH dan uji konektivitas ke tujuan:

   curl -v --connect-timeout 5 https://api.example.com
   

3. Mengevaluasi hasilnya:

   • Jika VM Compute Engine tidak dapat terhubung: masalahnya ada di VPC atau jaringan eksternal (aturan firewall, tabel perutean, kehabisan IP Cloud NAT, atau daftar yang diizinkan IP eksternal).
   • Jika VM Compute Engine berhasil terhubung: masalahnya ada di dalam GKE (NetworkPolicy memblokir egress, CIDR Pod yang tidak di-masquerade, atau DNS tingkat container).

Langkah 2: Jalankan pengujian Uji Konektivitas sesuai permintaan

Jalankan pengujian Google Cloud Uji Konektivitas dari VM node ke tujuan:

gcloud network-management connectivity-tests create test-node-to-dest \
    --source-instance=projects/PROJECT_ID/zones/us-central1-a/instances/gke-baseline-tester \
    --destination-ip-address=203.0.113.10 \
    --destination-port=443 \
    --protocol=TCP

Periksa hasilnya di konsol Google Cloud untuk mengidentifikasi apakah aturan firewall atau rute VPC membatalkan traffic.

---

Mendiagnosis konektivitas menggunakan Uji Konektivitas

Uji Konektivitas menyimulasikan jalur paket di seluruh resource GKE dan VPC tanpa mengirim traffic langsung. Simulasi ini mengevaluasi resolusi DNAT Service ClusterIP-to-Pod, aturan ingress dan egress NetworkPolicy GKE Dataplane V2, serta penyamaran IP node (SNAT). Tinjau cakupan diagnostik dan prasyarat sebelum menjalankan simulasi jalur otomatis:

• Area fokus: simulasi jalur statis otomatis untuk Pod, Layanan, NetworkPolicy, dan rute VPC GKE.
• Prasyarat: Network Intelligence Center diaktifkan; Network Management API diaktifkan.
• Kompatibilitas CNI: GKE Dataplane V2 (analisis yang ditingkatkan).
• Gejala: konektivitas turun tanpa alasan yang jelas meskipun semua konfigurasi tampak valid saat diperiksa secara manual.
• Sasaran: mensimulasikan dan melacak jalur paket secara statis dari sumber Pod ke tujuan, mengidentifikasi baris kebijakan yang menyebabkan penurunan.

Skenario A: Memverifikasi apakah NetworkPolicy GKE memblokir pengumpulan metrik

Saat meng-scrape metrik dari Pod di namespace yang aman, pengumpul Google Cloud Managed Service for Prometheus mungkin diblokir oleh NetworkPolicy tolak-bawaan:

gcloud network-management connectivity-tests create test-gmp-to-pod \
    --source-ip-address=10.0.0.15 \
    --destination-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/backend-pod \
    --destination-port=8080 \
    --protocol=TCP

Periksa rekaman aktivitas pengujian di Google Cloud console. Jika pengujian berakhir pada langkah GKE Network Policy evaluation dengan DROP, aturan ingress harus ditambahkan untuk mengizinkan traffic dari Pod pengumpul.

Skenario B: Memverifikasi jangkauan ke Layanan GKE

Simulasikan keterjangkauan dari VM klien ke Layanan Kubernetes internal:

gcloud network-management connectivity-tests create test-vm-to-service \
    --source-instance=projects/PROJECT_ID/zones/us-central1-a/instances/client-vm \
    --destination-ip-address=10.96.0.100 \
    --destination-port=80 \
    --protocol=TCP

Rekaman aktivitas simulasi menunjukkan:

1. Pencocokan rute VPC.
2. Izinkan traffic keluar dan masuk firewall VPC.
3. Tiba di node GKE.
4. DNAT Service ke alamat IP Pod backend.
5. Evaluasi Ingress NetworkPolicy pada Pod backend.

Skenario C: Mendiagnosis masalah keluar Pod ke internet

Jika Pod tidak dapat menjangkau API eksternal di internet:

1. Buat pengujian dari Pod ke alamat IP publik eksternal (seperti 8.8.8.8):

   gcloud network-management connectivity-tests create test-pod-to-internet \
       --source-gke-pod=projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME/k8s/namespaces/prod/pods/app-pod \
       --destination-ip-address=8.8.8.8 \
       --destination-port=53 \
       --protocol=UDP
   

2. Periksa titik pelepasan:

   • Dibatalkan di NetworkPolicy: Pod tidak memiliki NetworkPolicy keluar yang mengizinkan traffic ke 0.0.0.0/0.
   • Dihapus di Firewall VPC: aturan firewall VPC menolak traffic keluar dari subnet node.
   • Dihapus di Cloud NAT atau Rute: subnet tidak memiliki rute default ke gateway internet atau Cloud NAT tidak dikonfigurasi untuk subnet.

---

Tingkat 4: Observabilitas Gateway Eksternal dan Biaya (Internet dan NAT)

Tingkat gateway eksternal mengelola traffic keluar ke tujuan internet publik melalui Cloud NAT atau gateway eksternal. Kemampuan pengamatan di tingkat ini membantu mengidentifikasi workload dengan traffic keluar tinggi dan mengontrol biaya transfer data.

Mengidentifikasi traffic NAT (keluar ke internet)

Tinjau cakupan diagnostik dan prasyarat sebelum menganalisis traffic NAT dan internet keluar:

• Area fokus: traffic internet keluar, pemanfaatan port Cloud NAT, biaya transfer data eksternal.
• Prasyarat: Kemampuan Observasi Alur GKE Dataplane V2 diaktifkan.
• Kompatibilitas CNI: GKE Dataplane V2.
• Gejala: Error kehabisan port Cloud NAT atau biaya traffic keluar internet yang sangat tinggi dan tidak terduga.
• Tujuan: mengidentifikasi objek Pod dan Service GKE tertentu yang mengirimkan traffic ke endpoint internet eksternal.

Langkah 1: Pahami konsep "to-stack" dan "world" di GKE Dataplane V2

Di GKE Dataplane V2:

• world: merepresentasikan tujuan apa pun di luar cluster GKE dan di luar VPC (internet publik).
• to-stack: menampilkan paket yang bertransisi dari antarmuka veth container eBPF ke stack jaringan Linux host untuk menjalani penyamaran IP (SNAT) sebelum mencapai Cloud NAT.

Langkah 2: Streaming dan filter traffic NAT dengan Hubble CLI

Streaming alur internet keluar langsung yang berasal dari cluster Anda:

# Stream egress flows heading to external internet ("world")
gke-hubble observe \
    --traffic-direction egress \
    --verdict FORWARDED \
    --to-identity world \
    --follow

Contoh output:

TIMESTAMP             SOURCE               DESTINATION          TYPE     VERDICT
10:25:01.120          default/worker-pod   142.250.190.46:443   to-stack FORWARDED

Untuk mengidentifikasi sumber traffic keluar teratas, Anda juga dapat menyalurkan output JSON Hubble ke jq untuk menghitung aliran keluar eksternal menurut Pod:

timeout 60s gke-hubble observe \
    --traffic-direction egress \
    --verdict FORWARDED \
    --to-identity world \
    -o json | jq -r '.flow.source.namespace + "/" + .flow.source.pod_name' | sort | uniq -c | sort -nr | head -n 10

Langkah 3: Pantau traffic eksternal menggunakan metrik

Di Cloud Monitoring, lacak volume alur eksternal:

fetch prometheus_target
| metric 'prometheus.googleapis.com/pod_flow_egress_flows_count/counter'
| filter (metric.destination_identity == 'world')
| align rate(1m)
| every 1m
| group_by [metric.source_workload, metric.source_namespace], sum(val())

---

Menganalisis biaya dan performa traffic cluster menggunakan Flow Analyzer

Tinjau cakupan diagnostik dan prasyarat sebelum memvisualisasikan alur traffic dan biaya lintas zona:

• Area fokus: biaya transfer data lintas zona, top talker, visibilitas traffic antar-node tanpa kueri SQL.
• Prasyarat: Log Aliran VPC diaktifkan dengan INCLUDE_ALL_METADATA; Visibilitas Intranode diaktifkan; Observability Analytics diaktifkan di bucket log.
• Kompatibilitas CNI: semua cluster.
• Gejala: biaya transfer data antar-zona yang tinggi pada tagihan Google Cloud bulanan.
• Tujuan: mengidentifikasi secara visual workload GKE mana yang menghasilkan traffic lintas zona dan mengoptimalkan penempatan tanpa mengkueri log mentah.

Prasyarat

Untuk menggunakan Flow Analyzer untuk GKE:

1. Log Aliran VPC: harus diaktifkan di subnet cluster dengan metadata="INCLUDE_ALL_METADATA".
2. Visibilitas Intranode: harus diaktifkan di cluster agar traffic pod-ke-pod diekspos ke pipeline logging alur VPC.
3. Log Analytics: bucket _Default di Cloud Logging harus diupgrade untuk menggunakan Observability Analytics.

Catatan: Log alur ditulis ke project yang memiliki jaringan. Dalam penyiapan VPC Bersama, project ini adalah project host, bukan project layanan yang berjalan di cluster GKE Anda. Jalankan Flow Analyzer di project host, dan gunakan ID project host untuk PROJECT_ID dalam kueri Observability Analytics.

Langkah 1: Identifikasi pembicara teratas GKE di Flow Analyzer

Untuk melihat beban kerja bervolume tinggi di Flow Analyzer, lakukan hal berikut:

1. Di konsol Google Cloud , buka halaman Flow Analyzer.
2. Klik Bucket sumber, lalu pilih bucket log yang menyimpan log alur Anda. Kecuali jika Anda telah merutekannya ke tempat lain, ini adalah bucket _Default.
3. Di Traffic aggregation, pilih Source - Destination.
4. Tetapkan rentang waktu untuk periode analisis Anda.
5. Di bagian Atur alur menurut, pilih kolom Pod atau workload GKE.
6. Klik Run new query. Diagram Highest data flows menunjukkan beban kerja mana yang memindahkan data paling banyak.

Langkah 2: Menganalisis biaya traffic antar-zona

Traffic lintas zona dikenai biaya transfer data. Untuk menemukan workload yang mengirimkan data lintas zona:

1. Di bagian Atur alur menurut, pilih kolom zona sumber dan zona tujuan.
2. Klik Run new query dan baca tabel All data flows. Baris dengan zona sumber dan tujuan yang berbeda adalah traffic lintas zona Anda. Filter Flow Analyzer cocok dengan nilai, sehingga Anda tidak dapat memfilter "tidak sama"; bandingkan pasangan zona dalam hasil.
3. Luaskan pasangan zona bervolume tinggi untuk melihat workload GKE sumber dan tujuan yang mendasarinya.

Perbaikan:

• Terapkan topologySpreadConstraints atau podAffinity Kubernetes untuk menempatkan layanan yang berkomunikasi di zona ketersediaan yang sama.
• Aktifkan Topology Aware Routing (service.kubernetes.io/topology-mode: Auto) di Layanan untuk menjaga traffic tetap berada dalam zona asal.

Langkah 3: Melihat perincian Observability Analytics (Untuk kueri SQL tingkat lanjut)

Dari Flow Analyzer, klik Lihat di Log Analytics untuk menjalankan kueri SQL terhadap data alur.

Kueri SQL berikut menghitung Pod lintas-zona yang paling banyak berkomunikasi:

SELECT
  JSON_VALUE(json_payload.src_gke_details.pod.workload.workload_name) AS src_workload,
  JSON_VALUE(json_payload.dest_gke_details.pod.workload.workload_name) AS dest_workload,
  JSON_VALUE(json_payload.src_instance.zone) AS src_zone,
  JSON_VALUE(json_payload.dest_instance.zone) AS dest_zone,
  SUM(CAST(JSON_VALUE(json_payload.bytes_sent) AS INT64)) / 1024 / 1024 / 1024 AS total_gb_sent
FROM
  `PROJECT_ID.global._Default._AllLogs`
WHERE
  log_name LIKE '%vpc_flows%'
  AND timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND JSON_VALUE(json_payload.src_instance.zone) != JSON_VALUE(json_payload.dest_instance.zone)
GROUP BY
  1, 2, 3, 4
ORDER BY
  total_gb_sent DESC
LIMIT 20;

---

Referensi Hubble CLI dan ringkasan kueri

Hubble CLI men-streaming dan memfilter data aliran jaringan live langsung dari buffer ring kernel GKE Dataplane V2.

Penyiapan: Buat alias helper

Karena Hubble berjalan di dalam bidang kontrol cluster, konfigurasikan alias shell untuk menjalankan perintah Hubble tanpa men-deploy biner lokal:

alias gke-hubble="kubectl exec -it -n gke-managed-dpv2-observability deployment/hubble-relay -c hubble-cli -- hubble"

Resep pemfilteran umum

Memecahkan masalah sasaran	Perintah Hubble CLI
Mengamati semua paket yang di-drop secara real time di seluruh cluster	gke-hubble observe --verdict DROPPED --follow
Streaming semua traffic untuk Pod tertentu di namespace mana pun	gke-hubble observe --pod default/my-pod --follow
Memfilter traffic antara dua namespace tertentu	gke-hubble observe --from-namespace frontend --to-namespace backend
Mengisolasi traffic pada port tertentu (seperti Port 80)	gke-hubble observe --port 80
Memeriksa kueri dan jawaban DNS langsung	gke-hubble observe --port 53
Melihat reset TCP langsung (paket RST)	gke-hubble observe --type trace --verdict FORWARDED --tcp-flags RST
Mengalirkan semua traffic keluar yang menuju internet publik	gke-hubble observe --traffic-direction egress --to-identity world
Memeriksa traffic lapisan aplikasi HTTP (Lapisan 7 OSI)	gke-hubble observe --protocol http

Pemfilteran lanjutan dengan negasi (--not)

Anda dapat mengecualikan traffic yang responsif atau bervolume tinggi yang diketahui untuk berfokus pada anomali:

# Observe drops, but exclude internal kube-system health probes and DNS
gke-hubble observe \
    --verdict DROPPED \
    --not --namespace kube-system \
    --not --port 53

Pemformatan output dan integrasi jq

Untuk memproses rekaman alur secara terprogram, output dalam format JSON:

# Extract only source, destination, and drop reason from the last 100 flows
gke-hubble observe --verdict DROPPED -o json --last 100 | \
    jq -r '[.time, .flow.source.pod_name, .flow.destination.pod_name, .flow.drop_reason_desc] | @tsv'

Batasan

Saat menggunakan Hubble CLI untuk pemecahan masalah langsung, perhatikan batasan teknis berikut:

• Buffer ring lokal node efemeral: Aliran Hubble disimpan dalam buffer ring dalam memori di setiap node. Selama peristiwa dengan traffic tinggi, log alur yang lebih lama akan ditimpa dalam hitungan detik. Untuk analisis historis, andalkan logging NetworkPolicy dan Log Aliran VPC di Cloud Logging.
• Tidak ada OR logis bawaan: Flag Hubble CLI mengevaluasi beberapa argumen menggunakan AND logis. Untuk menelusuri beberapa kondisi (seperti Port 80 ATAU Port 443), jalankan perintah terpisah atau filter output JSON menggunakan jq.

Langkah berikutnya

• Praktik terbaik untuk kemampuan pengamatan jaringan
• Memecahkan masalah jaringan GKE
• Memecahkan masalah konektivitas di cluster Anda
• Tentang kemampuan observasi GKE Dataplane V2
• Memecahkan masalah data di Flow Analyzer