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 observasi 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 Service 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 terputus di antara Pod.	Tingkat 1: Pod dan Service (Penurunan kebijakan atau paket)	Mendiagnosis penurunan paket dan pemblokiran NetworkPolicy
Replika workload memiliki beban traffic yang tidak merata, atau Pod mencatat tingkat reset TCP (RST) yang tinggi.	Tingkat 1: Pod dan Service (Load balancing atau transport)	Mendiagnosis ketidakseimbangan traffic dan reset TCP
Latensi umum, waktu tunggu yang terputus-putus, atau mulai ulang CNI di seluruh node.	Tingkat 2: Node dan CNI (Kernel)	Triase untuk latensi tingkat node dan bottleneck CNI
Pod tidak dapat menjangkau resource di luar GKE (Cloud SQL, API eksternal, atau VPC lain).	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 pemilihan rute (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 (egress ke internet)
Biaya transfer data antar-zona yang tinggi atau perlu memvisualisasikan top talker 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 jaringan Google Cloud , perhatikan konsep inti berikut:

• eBPF (Extended Berkeley Packet Filter): teknologi sistem operasi yang memungkinkan menjalankan program pemantauan keamanan dan pemilihan rute yang aman 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 akan menyamarkan (menulis ulang) alamat IP Pod ke alamat IP node sehingga sistem eksternal tahu cara merutekan balasan.
• Pelacakan koneksi (Conntrack): fitur kernel yang melacak semua koneksi jaringan yang aktif. Di cluster GKE Dataplane V2, pelacakan ini dibagi antara dua tabel: conntrack kernel Linux standar (digunakan oleh ip-masq-agent) dan tabel conntrack yang dikelola Cilium dan GKE Dataplane V2 yang disimpan dalam peta eBPF. Jika sebuah node menangani terlalu banyak koneksi serentak, salah satu tabel pelacakan ini dapat terisi penuh (kehabisan conntrack), sehingga menyebabkan node tersebut secara diam-diam menghapus paket baru.
• Hubble: mesin kemampuan observasi untuk GKE Dataplane V2. Alat ini berjalan di atas eBPF dan memberikan visibilitas real-time ke aliran traffic, penurunan paket, dan evaluasi NetworkPolicy.

Tingkat 1: Kemampuan observasi Pod dan Service (Aplikasi)

Tingkat Pod dan Service mencakup komunikasi jaringan antara Pod, Service, dan DNS cluster. Masalah pada tingkat ini biasanya bermanifestasi sebagai waktu tunggu koneksi aplikasi, 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 yang terputus-putus pada panggilan API keluar.
• Sasaran: 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 keterjangkauan dasar

Sebelum memecahkan masalah lapisan DNS, pastikan 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 terbatas pada lapisan resolusi DNS. Lanjutkan ke Langkah 2.
• Jika keduanya gagal: masalahnya adalah perutean atau penerapan kebijakan tingkat jaringan. Lanjutkan ke Mendiagnosis penurunan paket dan pemblokiran NetworkPolicy.

Memeriksa pra-populasi DNS NetworkPolicy FQDN

Jika cluster Anda menggunakan NetworkPolicies berbasis FQDN (FQDNNetworkPolicy), pastikan nama domain diizinkan secara eksplisit. Jika Pod mengkueri domain eksternal yang tidak diisi otomatis 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 akan melintasi Pod kube-dns atau NodeLocal DNSCache. kube-dns metrik 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 ditetapkan (atau buka Metrics Explorer dan filter untuk 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 menghapus kueri.
kubernetes.io/networking/dns/kubedns/dns_request_latencies	p99 > 100 md	Latensi resolusi DNS end-to-end yang tinggi di seluruh kube-dns atau NodeLocal DNSCache.
kubernetes.io/networking/dns/kubedns/forwarding_request_latencies	p99 > 100 md	Latensi atau saturasi server DNS upstream.

Urutan triase waktu tunggu dan performa DNS

Ikuti urutan triase ini untuk mendiagnosis latensi DNS, cache tidak ditemukan, dan waktu tunggu upstream:

1. Memeriksa 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 penjelajahan jalur penelusuran di semua entri di /etc/resolv.conf.
2. Evaluasi latensi upstream: forwarding_request_latencies yang tinggi 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 ConfigMap kube-dns kustom untuk mencari stub atau penerusan upstream yang salah dikonfigurasi:

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

Langkah 3: Streaming traffic DNS live dengan Hubble CLI

Gunakan alias helper Hubble CLI untuk memeriksa permintaan dan respons DNS langsung 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 mengurai header DNS di lapisan aplikasi (Lapisan 7 OSI). Pada output flow, 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 terjadi penolakan kueri serentak, 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 hilang 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: GKE Dataplane V2 Flow Observability diaktifkan; logging NetworkPolicy dikonfigurasi.
• Kompatibilitas CNI: Khusus GKE Dataplane V2.
• Gejala: upaya koneksi aplikasi gagal dengan Connection timed out atau Connection reset by peer.
• Sasaran: Menentukan alasan NetworkPolicy atau eBPF yang tepat yang menyebabkan paket dihapus tanpa perubahan coba-coba pada kebijakan keamanan.

Langkah 1: Pantau metrik penurunan Hubble

Saat GKE Dataplane V2 menghapus paket, GKE Dataplane V2 akan memunculkan metrik hubble_drop_total yang diberi tag dengan alasan penghapusan serta metadata sumber dan tujuan. Untuk memantau metrik penurunan 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 berdasarkan 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) habis.
   • 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 mengkueri 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 dihapus.
   • jsonPayload.policies: mencantumkan NetworkPolicy yang dievaluasi. Jika daftar kosong ditampilkan dengan verdict DENY, namespace beroperasi dalam mode default-deny dan tidak ada kebijakan yang mengizinkan traffic.

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

kubectl get networklogging default -o yaml

Langkah 3: Lacak penurunan traffic langsung dengan Hubble CLI

Streaming penurunan 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 penyebaran skala workload Anda di lebih banyak node atau kurangi rasio 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: ketidakmerataan load balancing, kegagalan handshake TCP, penghentian koneksi mendadak.
• 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 ke dalam log.
• Sasaran: menentukan apakah ketidakseimbangan traffic disebabkan oleh persistensi koneksi di lapisan transpor (Lapisan 4 OSI, TCP) atau lapisan aplikasi (Lapisan 7 OSI, 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, buat kueri jumlah alur traffic masuk di semua Pod dalam Deployment:

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

2. Evaluasi distribusi traffic di seluruh Pod. Jika satu Pod menerima sebagian besar traffic, selidiki penggunaan kembali koneksi atau sesi melekat:

   • gRPC atau HTTP/2: koneksi TCP yang berjalan lama menyebabkan semua permintaan melintasi satu aliran TCP ke satu Pod backend. Perutean Layanan Kubernetes lapisan transport (Lapisan 4 OSI, TCP) tidak dapat menyeimbangkan permintaan di dalam koneksi HTTP/2 yang sudah ada.
   • Afinitas Sesi ClientIP: verifikasi apakah Service dikonfigurasi dengan sessionAffinity: ClientIP.
   • Service Headless: klien mungkin me-resolve DNS sekali dan meng-cache satu alamat IP secara permanen.

Langkah 2: Analisis metrik reset TCP

Reset TCP (RST) akan segera menghentikan koneksi. Reset ini dikeluarkan oleh kernel sistem operasi saat endpoint menerima paket untuk port yang tidak diketahui, atau saat aplikasi menutup koneksi dengan data yang belum dibaca di 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 menghasilkan reset. Periksa apakah aplikasi Pod mengalami error, mencapai batas koneksi, atau secara aktif menolak koneksi.
• RST masuk (traffic_direction=ingress): peer jarak jauh (database eksternal, API, atau Pod jarak jauh) mengirim reset. Periksa status responsivitas server tujuan dan status firewall.

Langkah 3: Streaming reset TCP secara live

Gunakan Hubble CLI untuk menangkap handshake reset langsung:

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

Langkah 4: Remediasi dan perbaikan yang dapat ditindaklanjuti

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

• Untuk persistensi koneksi lapisan aplikasi (Lapisan 7 OSI) atau gRPC:
  • Deploy Cloud Service Mesh untuk mengaktifkan load balancing tingkat permintaan lapisan aplikasi (Lapisan 7 OSI).
  • Konfigurasikan batas koneksi sisi klien atau waktu tunggu keep-alive (misalnya, MAX_CONNECTION_AGE dan MAX_CONNECTION_AGE_GRACE gRPC) untuk memaksa pembuatan ulang koneksi secara berkala.
• Untuk afinitas IP Service: 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 meng-cache hasil DNS tanpa batas waktu.
• Untuk overflow antrean backlog aplikasi: saat antrean pemrosesan aplikasi penuh, kernel Linux akan menghapus paket SYN yang masuk atau mengirim TCP RST. Lakukan penyebaran skala replika Pod atau tingkatkan backlog pemrosesan aplikasi (somaxconn).

---

Tingkat 2: Kemampuan observasi Node dan CNI (Kernel)

Tingkat node dan CNI mencakup kernel Linux host, program eBPF, dan antarmuka jaringan node. Bottleneck pada tingkat ini memengaruhi semua workload yang berjalan pada 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 pemadaman jaringan di seluruh cluster dan melanggar tujuan tingkat layanan terkelola 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 melakukan 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.

---

Triase untuk latensi tingkat node dan bottleneck CNI

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

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

Langkah 1: Bedakan masalah di luar GKE dari masalah di dalam GKE

Jalankan pengujian dasar pengukuran 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 penurunan paket atau latensi yang sama: masalahnya terletak 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, conntrack, atau CNI level node). Lanjutkan ke Langkah 2.

Batasan pengujian dasar pengukuran VM: Pengujian ini mungkin tidak menangkap penurunan yang terputus-putus atau berkecepatan rendah yang hanya muncul dalam volume traffic gabungan yang tinggi. Selain itu, jika masalahnya hanya terjadi pada hardware yang mendasari satu host VM, VM lain mungkin tidak akan mereproduksi perilaku tersebut.

Langkah 2: Bedakan masalah aplikasi dari 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 egress yang terputus-putus. Dalam volume traffic yang tinggi, iptables --random-fully mungkin mengalokasikan port sementara yang bertabrakan dengan NodePort yang aktif, sehingga menyebabkan penundaan koneksi. Upgrade ip-masq-agent ke versi 2.11.1 atau yang lebih tinggi, atau hapus --random-fully untuk menghindari tabrakan 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 throttling CPU atau tekanan memori, yang menunda pemrosesan paket di ruang pengguna:

   kubectl top nodes
   kubectl top pods -n default
   

2. Memeriksa 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 menghapus paket TCP SYN baru.

Langkah 3: Verifikasi paket yang hilang di level VM menggunakan telemetri Compute Engine

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

Di Cloud Monitoring > Metrics Explorer, buat kueri:

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

• FQ_CODEL_DROP: paket dihapus karena saturasi antrean Fair Queuing atau CoDel (batas bandwidth egress VM terlampaui).
• FIREWALL_RULE_DROP: paket dihapus oleh aturan firewall VPC.
• RATE_LIMIT_DROP: paket dihapus karena VM melebihi kuota paket maksimum per detik (PPS) antarmuka jaringannya.

Langkah 4: Selidiki penurunan tingkat kernel menggunakan eBPF

Jika metrik tingkat VM menunjukkan penurunan nol, tetapi Pod GKE masih mengalami penurunan paket, periksa agen GKE Dataplane V2 (anetd) untuk mengetahui penurunan 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 observasi VPC dan pemilihan rute (Jaringan Cloud)

Lapisan perutean cloud dan VPC 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).
• Sasaran: menentukan dengan cepat apakah penurunan terjadi di dalam node GKE atau di dalam VPC Google Cloud atau jaringan eksternal.

Langkah 1: Pengujian dasar pengukuran VM Compute Engine

Untuk men-deploy VM dasar pengukuran dan mengevaluasi apakah masalah tetap ada 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. Evaluasi hasilnya:

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

Langkah 2: Jalankan pengujian Uji Konektivitas on demand

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 \
    --round-trip

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

---

Mendiagnosis konektivitas menggunakan Uji Konektivitas

Uji Konektivitas menyimulasikan jalur paket di seluruh resource GKE dan VPC tanpa mengirim traffic aktif. Simulasi ini mengevaluasi resolusi DNAT Service ClusterIP-ke-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, Service, NetworkPolicy, dan rute VPC GKE.
• Prasyarat: Network Intelligence Center diaktifkan; Network Management API diaktifkan.
• Kompatibilitas CNI: GKE Dataplane V2 (analisis yang ditingkatkan).
• Gejala: penurunan konektivitas yang tidak dapat dijelaskan, padahal semua konfigurasi tampak valid setelah pemeriksaan manual.
• Sasaran: menyimulasikan dan melacak seluruh jalur paket secara statis dari sumber Pod ke tujuan, mengidentifikasi baris kebijakan yang tepat yang menyebabkan penurunan.

Skenario A: Memverifikasi apakah NetworkPolicy GKE memblokir pengumpulan metrik

Saat mengumpulkan metrik dari Pod di namespace yang aman, kolektor Google Cloud Managed Service for Prometheus mungkin diblokir oleh NetworkPolicy default-deny:

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 \
    --round-trip

Periksa trace pengujian di konsol Google Cloud . Jika pengujian berakhir pada langkah GKE Network Policy evaluation dengan DROP, aturan ingress harus ditambahkan untuk mengizinkan traffic dari Pod kolektor.

Skenario B: Memverifikasi keterjangkauan ke Layanan GKE

Simulasikan keterjangkauan dari VM klien ke Service 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 \
    --round-trip

Trace yang disimulasikan menunjukkan:

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

Skenario C: Mendiagnosis masalah traffic egress 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 \
       --round-trip
   

2. Periksa titik penurunan:

   • Dihapus di NetworkPolicy: Pod tidak memiliki NetworkPolicy egress 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: Kemampuan observasi Gateway Eksternal dan Biaya (Internet dan NAT)

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

Mengidentifikasi traffic NAT (egress ke internet)

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

• Area fokus: traffic internet keluar, pemakaian 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 egress internet keluar yang sangat tinggi.
• Sasaran: 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: mewakili tujuan apa pun di luar cluster GKE dan di luar VPC (internet publik).
• to-stack: mewakili 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

Lakukan 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 pembicara keluar teratas, Anda juga dapat menyalurkan output JSON Hubble ke jq untuk menghitung alur traffic keluar eksternal berdasarkan 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 flow 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.
• Sasaran: 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 terekspos ke pipeline logging aliran VPC.
3. Analisis Log: 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 project ID host untuk PROJECT_ID dalam kueri Observability Analytics.

Langkah 1: Identifikasi pembicara teratas GKE di Flow Analyzer

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

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

Langkah 2: Analisis biaya traffic antar-zona

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

1. Di bagian Organize flows by, pilih kolom zona sumber dan zona tujuan.
2. Klik Run new query dan baca tabel All data flows. Baris yang zona sumber dan tujuannya berbeda adalah traffic lintas zona Anda. Filter Flow Analyzer cocok dengan nilai, sehingga Anda tidak dapat memfilter untuk "tidak sama dengan"; 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 dalam zona ketersediaan yang sama.
• Aktifkan Topology Aware Routing (service.kubernetes.io/topology-mode: Auto) pada Service untuk menjaga traffic tetap berada dalam zona asal.

Langkah 3: Lihat perincian Observability Analytics (Untuk kueri SQL lanjutan)

Dari Flow Analyzer, klik View in Log Analytics untuk menjalankan kueri SQL terhadap data flow.

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

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 tips kueri

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

Penyiapan: Membuat alias bantuan

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

Sasaran pemecahan masalah	Perintah Hubble CLI
Mengamati semua paket yang dihapus secara real time di seluruh cluster	gke-hubble observe --verdict DROPPED --follow
Melakukan 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 di 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
Melakukan streaming semua traffic keluar yang menuju ke 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 bervolume tinggi atau traffic normal 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 data flow 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:

• Ring buffer lokal node sementara: Alur Hubble disimpan dalam ring buffer dalam memori di setiap node. Selama peristiwa 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 observasi jaringan
• Memecahkan masalah jaringan GKE
• Memecahkan masalah konektivitas di cluster Anda
• Tentang kemampuan observasi GKE Dataplane V2
• Memecahkan masalah data di Flow Analyzer