Diagnosis & Selesaikan Masalah Jaringan Kubernetes melalui KubeSkoop - ACK

Kegagalan jaringan kontainer—seperti timeout DNS intermiten, reset TCP, error Nginx 499/502/503/504, dan lonjakan latensi—terkenal sulit dilokalisasi karena bersifat sementara dan sulit direproduksi. ACK KubeSkoop (sebelumnya dikenal sebagai ACK Net Exporter) adalah suite pemantauan dan troubleshooting jaringan open-source yang menggunakan eBPF untuk mengumpulkan metrik jaringan per-Pod langsung dari setiap node, sehingga Anda dapat mengidentifikasi akar permasalahan tanpa perlu melakukan packet capture secara manual atau menebak-nebak.

Topik ini menjelaskan cara menginstal KubeSkoop di kluster ACK terkelola, mengonfigurasi pemantauan, serta menggunakan metrik per-Pod untuk mendiagnosis empat jenis kegagalan jaringan umum.

Cara kerja

KubeSkoop berjalan sebagai DaemonSet, menempatkan satu agen di setiap node. Setiap agen menggunakan eBPF untuk mengumpulkan data jaringan tingkat rendah dari node tersebut dan mengagregasikannya per Pod. Agen tersebut mengekspos metrik Prometheus dan event abnormal melalui endpoint HTTP pada port 9102.

KubeSkoop mendukung:

Pemantauan jaringan mendalam
Diagnostik konektivitas
Pengambilan paket (Packet capturing)
Probing latensi

Gambar berikut menunjukkan arsitektur inti KubeSkoop.

Prasyarat

Sebelum memulai, pastikan Anda telah memiliki:

Kluster ACK terkelola
Akses ke Konsol ACK
Akses ke Konsol ARMS (diperlukan untuk dasbor Prometheus)

Instal dan konfigurasi ACK KubeSkoop

Instal add-on ACK KubeSkoop

Masuk ke Konsol ACK. Di panel navigasi kiri, klik Clusters.
Pada halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Add-ons.
Pada halaman Add-ons, cari ACK KubeSkoop, temukan add-on tersebut, lalu klik Install.
Pada halaman Install Component ACK KubeSkoop, klik Confirm.

Konfigurasi add-on KubeSkoop

KubeSkoop dikonfigurasi melalui ConfigMap bernama kubeskoop-config di namespace ack-kubeskoop. Perubahan berlaku segera—tidak diperlukan restart.

Opsi 1: Edit melalui kubectl

kubectl edit cm kubeskoop-config -n ack-kubeskoop

Opsi 2: Edit melalui konsol

Masuk ke ACK console. Pada panel navigasi kiri, klik Clusters.
Klik nama kluster Anda. Di panel navigasi kiri, pilih Configurations > ConfigMaps.
Pada halaman ConfigMaps, atur Namespace menjadi ack-kubeskoop, cari kubeskoop-config, lalu klik Edit di kolom Actions.
Di panel Edit, perbarui parameter dan klik OK.

Tabel berikut menjelaskan parameter yang didukung.

Parameter	Deskripsi	Nilai default
`debugmode`	Aktifkan mode debug. Jika diatur ke `true`, menyediakan log tingkat DEBUG, antarmuka debugging, serta alat diagnostik Go pprof dan gops.	`false`
`port`	Port untuk endpoint HTTP metrik.	`9102`
`enableController`	Aktifkan komponen Controller, yang berinteraksi dengan API Kubernetes untuk menjalankan tugas pemantauan dan manajemen.	`true`
`controllerAddr`	Alamat komponen KubeSkoop Controller.	`dns:kubeskoop-controller:10263`
`metrics.probes`	Daftar jenis probe yang akan dikumpulkan. Setiap probe dipetakan ke kategori metrik. Probe default: `conntrack`, `qdisc`, `netdev`, `io`, `sock`, `tcpsummary`, `tcp`, `tcpext`, `udp`, `rdma`. Untuk referensi lengkap probe, lihat Probes, metrics, and events.	Lihat deskripsi

Siapkan dasbor ARMS Prometheus

Masuk ke Konsol ARMS. Di panel navigasi kiri, klik Integration Management.
Di halaman Integration Management, klik Add Integration, cari KubeSkoop, lalu klik ACK KubeSkoop Network Monitoring.
Pada kotak dialog ACK KubeSkoop Network Monitoring, pilih kluster ACK, masukkan Integration Name, lalu klik OK.
Masuk ke Konsol ACK. Klik nama kluster. Di panel navigasi kiri, pilih Operations > Prometheus Monitoring.
Klik tab Others. Dasbor pemantauan node dan Pod yang dibuat oleh KubeSkoop akan muncul dalam daftar dasbor.

KubeSkoop Prometheus dashboards in the ACK console

Untuk informasi lebih lanjut tentang Alibaba Cloud Prometheus Service, lihat Use Alibaba Cloud Prometheus Service.

Akses metrik KubeSkoop secara manual

KubeSkoop mengekspos metrik dalam format Prometheus pada port 9102 di setiap Pod agen. Untuk mengkueri metrik secara langsung:

Dapatkan daftar Pod agen KubeSkoop beserta IP node-nya:

kubectl get pod -n ack-kubeskoop -o wide | grep kubeskoop-agent

Output yang diharapkan:

kubeskoop-agent-2chvw   1/1   Running   0   43m   172.16.16.xxx   cn-hangzhou.172.16.16.xxx   <none>   <none>
kubeskoop-agent-2qtbf   1/1   Running   0   43m   172.16.16.xxx   cn-hangzhou.172.16.16.xxx   <none>   <none>
kubeskoop-agent-72pgf   1/1   Running   0   43m   172.16.16.xxx   cn-hangzhou.172.16.16.xxx   <none>   <none>

Ambil semua metrik dari sebuah agen. Ganti 172.16.16.xxx dengan IP dari langkah sebelumnya.
```
curl http://172.16.16.xxx:9102/metrics
```

Metrik mengikuti format berikut:

kubeskoop_netdev_rxbytes{k8s_namespace="",k8s_node="cn-hangzhou.172.16.16.xxx",k8s_pod=""} 2.970963745e+09

Setiap metrik diberi label k8s_namespace, k8s_node, dan k8s_pod, sehingga Anda dapat memfilter berdasarkan namespace, node, atau Pod dalam kueri Prometheus.

Troubleshooting masalah jaringan umum

Bagian berikut menjelaskan metrik yang perlu dipantau untuk setiap jenis kegagalan dan cara menginterpretasikannya.

Troubleshooting timeout DNS

Timeout DNS di lingkungan kontainer biasanya disebabkan oleh salah satu dari tiga akar permasalahan berikut:

Server DNS merespons lambat sehingga melewatkan timeout di sisi klien.
Pengirim tidak dapat mengirimkan paket kueri DNS tepat waktu.
Server merespons tepat waktu, tetapi pengirim membuang respons tersebut karena kendala sumber daya seperti memori tidak mencukupi.

Karena sebagian besar workload cloud-native bergantung pada CoreDNS, pantau metrik berikut untuk Pod aplikasi Anda maupun Pod CoreDNS.

Metric	Apa yang diukur
`kubeskoop_pod_udpsndbuferrors`	Error saat mengirim paket UDP melalui lapisan jaringan
`kubeskoop_pod_udpincsumerrors`	Error checksum saat menerima paket UDP
`kubeskoop_pod_udpnoports`	Jumlah kali lapisan jaringan tidak dapat menemukan socket yang cocok saat menerima dengan `__udp4_lib_rcv`
`kubeskoop_pod_udpinerrors`	Error saat menerima paket UDP
`kubeskoop_pod_udpoutdatagrams`	Paket yang berhasil dikirim oleh UDP melalui lapisan jaringan
`kubeskoop_pod_udprcvbuferrors`	Error akibat antrian penerima socket tidak mencukupi saat menyalin data ke lapisan aplikasi

Troubleshooting error Nginx Ingress 499/502/503/504

Keempat kode status ini masing-masing menunjukkan lapisan kegagalan yang berbeda.

Status code	Makna	Penyebab umum
`499`	Klien menutup koneksi TCP sebelum Nginx memberikan respons	Timeout di sisi klien tercapai selama Nginx sedang memproses; server memproses koneksi secara lambat setelah koneksi terbentuk; backend upstream lambat
`502`	Nginx tidak dapat memperoleh respons valid dari upstream	Resolusi DNS untuk backend gagal (umum terjadi saat menggunakan Service Kubernetes); gagal membuat koneksi dengan upstream; permintaan atau respons upstream terlalu besar, menyebabkan kegagalan alokasi memori
`503`	Semua server upstream tidak tersedia	Tidak ada backend yang tersedia; traffic dibatasi oleh pengaturan `limit-req` pada Ingress
`504`	Nginx mengalami timeout saat menunggu respons dari upstream	Respons dari backend upstream tertunda

Kumpulkan informasi garis dasar terlebih dahulu. Sebelum memeriksa metrik KubeSkoop, kumpulkan:

access_log Nginx, khususnya request_time, upstream_connect_time, dan upstream_response_time
Entri error_log Nginx sekitar waktu kejadian
Status pemeriksaan kesiapan (readiness probe) dan pemeriksaan kesehatan (liveness probe) jika dikonfigurasi

Jika Anda mencurigai kegagalan koneksi, periksa perubahan pada metrik berikut:

Metric	Apa yang diukur
`kubeskoop_tcpext_listenoverflow`	Antrian half-connection meluap pada socket dalam status LISTEN
`kubeskoop_tcpext_listendrops`	Kegagalan membuat socket SYN_RECV dari socket LISTEN
`kubeskoop_netdev_txdropped`	Paket yang dibuang oleh NIC (network interface card) karena error transmisi
`kubeskoop_netdev_rxdropped`	Paket yang dibuang oleh NIC karena error penerimaan
`kubeskoop_tcp_activeopens`	Jumlah kali sebuah Pod memulai handshake TCP dengan paket SYN (koneksi gagal juga menambah penghitung ini)
`kubeskoop_tcp_passiveopens`	Jumlah kali sebuah Pod menyelesaikan handshake TCP dan mengalokasikan socket (setara dengan koneksi yang berhasil dibentuk)
`kubeskoop_tcp_retranssegs`	Total segmen yang dikirim ulang dalam satu Pod, dihitung setelah TCP Segmentation Offload (TSO)
`kubeskoop_tcp_estabresets`	Jumlah kali koneksi TCP ditutup secara abnormal dalam satu Pod
`kubeskoop_tcp_outrsts`	Paket reset yang dikirim oleh TCP dalam satu Pod
`kubeskoop_conntrack_invalid`	Jumlah kali entri connection tracking (conntrack) tidak dapat dibentuk, tetapi paket tidak dibuang
`kubeskoop_conntrack_drop`	Paket yang dibuang karena entri conntrack tidak dapat dibentuk

Jika respons Nginx lambat (misalnya, request_time panjang tetapi upstream_response_time pendek), periksa penumpukan antrian:

Metric	Apa yang diukur
`kubeskoop_tcpsummary_tcpestablishedconn`	Koneksi TCP saat ini dalam status ESTABLISHED
`kubeskoop_pod_tcpsummarytcptimewaitconn`	Koneksi TCP saat ini dalam status TIME_WAIT
`kubeskoop_tcpsummary_tcptimewaitconn`	Total byte dalam antrian kirim koneksi TCP ESTABLISHED
`kubeskoop_tcpsummary_tcprxqueue`	Total byte dalam antrian terima koneksi TCP ESTABLISHED
`kubeskoop_tcpext_tcpretransfail`	Paket yang dikirim ulang tetapi mengembalikan error selain EBUSY, menandakan kegagalan pengiriman ulang

Troubleshooting reset TCP

Reset TCP muncul di aplikasi sebagai error connection reset by peer (umum pada aplikasi berbasis C seperti Nginx) atau error Broken pipe (umum pada aplikasi Java atau Python yang menggunakan wrapper koneksi TCP).

Penyebab umum di lingkungan cloud-native:

Kelelahan sumber daya di sisi server, seperti memori TCP tidak mencukupi, memicu reset proaktif.
Load Balancing atau Service Kubernetes meneruskan traffic ke backend yang tidak diharapkan karena anomali dalam pemilihan Endpoint atau status conntrack.
Kebijakan keamanan menutup koneksi.
Di lingkungan NAT atau di bawah konkurensi tinggi, terjadi Protection Against Wrapped Sequence Numbers (PAWS) atau wraparound nomor urut.
Keepalive TCP kedaluwarsa karena tidak ada traffic bisnis yang melewati koneksi dalam periode yang lama.

Mulailah dengan memetakan topologi jaringan antara klien dan server pada saat reset terjadi. Lalu periksa metrik berikut:

Metric	Apa yang diukur
`kubeskoop_tcpext_tcpabortontimeout`	Reset yang dikirim karena jumlah maksimum upaya keepalive, probing window, atau pengiriman ulang telah terlampaui
`kubeskoop_tcpext_tcpabortonlinger`	Reset yang dikirim untuk mereklaim koneksi dalam status FIN_WAIT2 ketika opsi TCP Linger2 diaktifkan
`kubeskoop_tcpext_tcpabortonclose`	Reset yang dikirim karena terdapat data yang belum dibaca saat koneksi TCP ditutup
`kubeskoop_tcpext_tcpabortonmemory`	Reset yang dikirim karena memori tidak mencukupi saat alokasi sumber daya `tw_sock` atau `tcp_sock`
`kubeskoop_tcpext_tcpabortondata`	Reset yang dikirim untuk reklamasi koneksi cepat saat opsi Linger atau Linger2 diaktifkan
`kubeskoop_tcpext_tcpackskippedsynrecv`	Jumlah kali socket dalam status SYN_RECV tidak membalas dengan ACK
`kubeskoop_tcpext_tcpackskippedpaws`	Jumlah kali ACK tidak dikirim karena pembatasan laju out-of-window (OOW), meskipun mekanisme PAWS telah memicu koreksi
`kubeskoop_tcp_estabresets`	Jumlah kali koneksi TCP ditutup secara abnormal dalam satu Pod
`kubeskoop_tcp_outrsts`	Paket reset yang dikirim oleh TCP dalam satu Pod

Troubleshooting jitter latensi jaringan

Lonjakan latensi intermiten di jaringan kontainer sering kali memiliki penyebab yang tidak jelas. Meskipun gejalanya tampak sebagai keterlambatan jaringan, akar permasalahannya sering kali merupakan isu penjadwalan atau sumber daya sistem operasi.

Penyebab umum:

Proses real-time yang dikelola oleh scheduler RT berjalan terlalu lama, sehingga menghabiskan sumber daya proses bisnis atau thread kernel jaringan.
Workload mengalami panggilan eksternal lambat sesekali, seperti I/O disk cloud berlatensi tinggi atau lonjakan RTT (Round-Trip Time) RDS yang intermiten.
Beban tidak merata antar CPU atau node NUMA menyebabkan beberapa CPU tertinggal.
Mekanisme kernel stateful seperti operasi konfirmasi conntrack, atau jumlah besar socket orphan, memperlambat pencarian socket.

Pantau metrik berikut untuk mempersempit penyebabnya:

Metric	Apa yang diukur
`kubeskoop_io_ioreadsyscall`	Jumlah kali proses melakukan operasi baca sistem file (`read`, `pread`)
`kubeskoop_io_iowritesyscall`	Jumlah kali proses melakukan operasi tulis sistem file (`write`, `pwrite`)
`kubeskoop_io_ioreadbytes`	Byte yang dibaca proses dari sistem file (biasanya dari perangkat blok)
`kubeskoop_io_iowritebytes`	Byte yang ditulis proses ke sistem file
`kubeskoop_tcpext_tcptimeouts`	Paket SYN yang tidak diakui dan dikirim ulang (bertambah saat status congestion avoidance belum memasuki recovery, loss, atau disorder)
`kubeskoop_tcpsummary_tcpestablishedconn`	Koneksi TCP saat ini dalam status ESTABLISHED
`kubeskoop_tcpsummary_tcptimewaitconn`	Koneksi TCP saat ini dalam status TIME_WAIT
`kubeskoop_tcpsummary_tcptxqueue`	Total byte dalam antrian kirim koneksi TCP ESTABLISHED
`kubeskoop_tcpsummary_tcprxqueue`	Total byte dalam antrian terima koneksi TCP ESTABLISHED
`kubeskoop_softnet_processed`	Paket dari backlog NIC yang diproses oleh semua CPU dalam satu Pod
`kubeskoop_softnet_dropped`	Paket yang dibuang oleh semua CPU dalam satu Pod

Kasus penggunaan pelanggan

Kasus berikut menunjukkan bagaimana ACK KubeSkoop digunakan untuk mengidentifikasi dan menyelesaikan masalah produksi nyata.

Kasus 1: Timeout DNS intermiten

Masalah: Pelanggan yang menjalankan aplikasi PHP mengalami timeout resolusi DNS intermiten. Layanan DNS adalah CoreDNS, dengan resolver upstream yang dikonfigurasi mengarah ke penyedia publik.

Temuan: Selama jendela error:

kubeskoop_udp_noports meningkat sebesar 1.
kubeskoop_packetloss_total meningkat sebesar 1.

Kedua perubahan tersebut kecil dalam nilai absolut.

Akar permasalahan: Server DNS publik merespons secara lambat. Respons tiba setelah aplikasi PHP telah mengalami timeout di sisi klien. Peningkatan metrik yang kecil konsisten dengan keterlambatan paket yang sesekali, bukan sistematis.

Kasus 2: Kegagalan koneksi intermiten pada aplikasi Java

Masalah: Layanan Tomcat pelanggan menjadi tidak tersedia secara intermiten, dengan setiap gangguan berlangsung sekitar 5 hingga 10 detik.

Temuan: Analisis log mengonfirmasi bahwa jeda Garbage Collection (GC) terjadi pada saat setiap insiden. Setelah menerapkan KubeSkoop, kubeskoop_tcpext_listendrops meningkat signifikan selama kejadian GC.

Akar permasalahan: Selama GC, pemrosesan permintaan melambat dan koneksi tidak dilepaskan dengan cepat. Permintaan koneksi masuk terus menumpuk, mengisi backlog socket listen hingga meluap, yang memicu lonjakan kubeskoop_tcpext_listendrops.

Resolusi: Pelanggan menyesuaikan parameter backlog koneksi Tomcat, yang menyelesaikan masalah tersebut.

Kasus 3: Lonjakan RTT intermiten ke Redis

Masalah: Pelanggan mengamati permintaan Redis intermiten dengan total waktu respons melebihi 300 ms, tetapi tidak dapat mereproduksi masalah tersebut sesuai permintaan.

Temuan: Setelah menerapkan KubeSkoop, kubeskoop_virtcmdlatency_latency meningkat selama jendela latensi:

Bucket le=15 (ambang batas ~36 ms) meningkat, menunjukkan setidaknya satu panggilan melebihi 36 ms.
Bucket le=18 (ambang batas ~200 ms) meningkat, menunjukkan adanya panggilan yang melebihi 200 ms.

Akar permasalahan: Panggilan virtualisasi kernel yang dipicu selama pembuatan dan penghapusan Pod secara batch menduduki core CPU dan tidak dapat dipreempt, menyebabkan latensi intermiten pelanggan.

Kasus 4: Kegagalan pemeriksaan kesehatan intermiten untuk Nginx Ingress

Masalah: Pemeriksaan kesehatan Nginx Ingress gagal secara intermiten, disertai kegagalan permintaan bisnis.

Temuan: Pada saat setiap kegagalan:

kubeskoop_tcpsummary_tcprxqueue dan kubeskoop_tcpsummary_tcptxqueue keduanya meningkat.
kubeskoop_tcpext_tcptimeouts meningkat.
kubeskoop_tcpsummary_tcptimewaitconn menurun sementara kubeskoop_tcpsummary_tcpestablishedconn meningkat.

Jalur kernel dan pembentukan koneksi tampak normal, tetapi proses user-space tidak mengonsumsi paket dari antrian terima atau mengosongkan antrian kirim.

Akar permasalahan: Pembatasan kecepatan (throttling) cgroup CPU secara intermiten mencegah proses Ingress dijadwalkan, sehingga menghentikan pemrosesan dan transmisi paket.

Resolusi: Pelanggan mengaktifkan CPU Burst untuk Pod Nginx Ingress dengan mengikuti panduan Enable CPU Burst, yang menghilangkan throttling tersebut.

Langkah selanjutnya

Probes, metrics, and events — referensi lengkap untuk semua probe KubeSkoop dan metrik yang diekspos
Use Alibaba Cloud Prometheus Service — siapkan pemantauan Prometheus untuk kluster ACK Anda
Enable CPU Burst — konfigurasi CPU Burst untuk mencegah throttling cgroup pada workload yang sensitif terhadap latensi