Container Service for Kubernetes:Troubleshoot masalah jaringan dengan ACK KubeSkoop

Instal ACK KubeSkoop

1. Masuk ke ACK console. Di panel navigasi kiri, klik Clusters.

2. Pada halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Components and Add-ons.

3. Pada halaman Add-ons, cari ACK KubeSkoop, temukan komponennya, lalu klik Install.

4. Pada panel Install ACK KubeSkoop, klik Confirm.

Konfigurasi KubeSkoop

• Untuk mengonfigurasi komponen KubeSkoop, edit ConfigMap-nya dengan menjalankan perintah berikut:

  kubectl edit cm kubeskoop-config -n ack-kubeskoop

• Atau, konfigurasikan komponen tersebut di ACK console:

  1. Masuk ke ACK console. Di panel navigasi kiri, klik Clusters.

  2. Pada halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Configurations > ConfigMaps.

  3. Pada halaman ConfigMaps, atur Namespace menjadi ack-kubeskoop, cari kubeskoop-config, lalu klik Edit di kolom Actions di sebelah kanan kubeskoop-config.

  4. Pada panel Edit, konfigurasikan parameter dan klik OK. Tabel berikut menjelaskan opsi konfigurasi yang didukung oleh KubeSkoop.

     Parameter	Deskripsi	Bawaan
     debugmode	Menentukan apakah mode debug diaktifkan. Nilai yang valid: false: Mode debug dinonaktifkan. true: Mode debug diaktifkan. Saat diaktifkan, opsi ini menyediakan log tingkat DEBUG, antarmuka debugging, serta alat diagnostik Go pprof dan gops.	false
     port	Port untuk layanan metrik, yang menyediakan titik akhir HTTP.	9102
     enableController	Menentukan apakah komponen controller diaktifkan. Controller berinteraksi dengan API Kubernetes untuk menjalankan tugas pemantauan dan manajemen.	true
     controllerAddr	Alamat komponen controller KubeSkoop.	dns:kubeskoop-controller:10263
     metrics.probes	Daftar jenis metrik pemantauan yang dikumpulkan. Setiap probe berkorespondensi dengan kategori metrik.	metrics: probes: - name: conntrack - name: qdisc - name: netdev - name: io - name: sock - name: tcpsummary - name: tcp - name: tcpext - name: udp - name: rdma Untuk informasi lebih lanjut, lihat Probes, Metrics, and Events.

     Komponen ACK KubeSkoop secara otomatis melakukan hot-reload terhadap perubahan konfigurasi dari ConfigMap, sehingga Anda tidak perlu me-restart-nya.

Konfigurasi dashboard ARMS Prometheus

1. Masuk ke ARMS console.

2. Di panel navigasi kiri, klik Integration Management.

3. Pada halaman Integration Management, klik Add Integration. Di kotak pencarian, cari KubeSkoop dan klik ACK KubeSkoop Network Monitoring.

4. Pada kotak dialog ACK KubeSkoop Network Monitoring, pilih kluster ACK yang akan diintegrasikan, masukkan Integration Name, lalu klik OK untuk mengaktifkan pemantauan KubeSkoop.

5. Masuk ke ACK console. Di panel navigasi kiri, klik Clusters.

6. Pada halaman Clusters, klik nama kluster Anda. Di panel navigasi kiri, klik Operations > Prometheus Monitoring.

7. Klik tab Others. Di daftar dashboard, Anda dapat menemukan dashboard pemantauan KubeSkoop untuk node dan Pod, bernama Ack KubeSkoop Network Monitor - Node dan Ack KubeSkoop Network Monitor - Pod.

Menampilkan metrik pemantauan KubeSkoop secara manual

KubeSkoop menyediakan data pemantauan dalam format Prometheus. Setelah menginstal KubeSkoop, Anda dapat mengakses port layanan dari instans Pod KubeSkoop mana pun untuk mengambil semua metrik.

1. Jalankan perintah berikut untuk mendapatkan semua instans KubeSkoop.

    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>

2. Jalankan perintah berikut untuk mendapatkan metrik. Ganti 172.16.16.xxx dengan alamat IP instans KubeSkoop dari langkah sebelumnya.

   curl http://172.16.16.xxx:9102/metrics

KubeSkoop menyediakan metrik pemantauan dalam format berikut:

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

Masalah timeout DNS

Di lingkungan cloud-native, masalah timeout layanan DNS dapat menyebabkan kegagalan akses layanan. Penyebab umum timeout DNS meliputi:

• Server DNS merespons lambat dan tidak dapat menyelesaikan kueri DNS sebelum aplikasi mengalami timeout.

• Pengirim gagal mengirim paket kueri DNS tepat waktu karena masalah di sisi klien.

• Server merespons dengan cepat, tetapi pengirim membuang paket karena masalah seperti memori tidak mencukupi.

Anda dapat menggunakan metrik berikut untuk membantu troubleshooting masalah timeout DNS intermiten:

Karena banyak layanan di lingkungan cloud-native bergantung pada CoreDNS untuk resolusi nama domain, Anda juga harus mengamati metrik di atas untuk Pod terkait CoreDNS jika masalah DNS terkait dengan CoreDNS.

Error HTTP 499/502/503/504 pada Nginx Ingress

Di lingkungan cloud-native, gerbang Ingress dan layanan proxy lainnya sering mengalami pengecualian intermiten. Untuk layanan proxy berbasis Nginx seperti Nginx Ingress, error 499, 502, 503, dan 504 adalah yang paling umum. Error tersebut menunjukkan hal berikut:

• 499 Client Closed Request: Klien menutup koneksi TCP sebelum Nginx merespons. Penyebab umum meliputi:

  • Klien membuat koneksi tetapi mengirim permintaan terlambat, sehingga timeout sisi klien tercapai saat Nginx sedang merespons. Hal ini umum terjadi pada framework permintaan asinkron di klien Android.

  • Server memproses koneksi secara lambat setelah koneksi dibuat. Hal ini memerlukan investigasi lebih lanjut.

  • Server lambat memproses permintaan yang dikirim ke backend hulu.

• 502 Bad Gateway: Biasanya menunjukkan masalah tingkat koneksi antara Nginx dan backend hulu, seperti kegagalan koneksi atau penutupan abnormal oleh backend. Penyebab umum meliputi:

  • Resolusi DNS gagal untuk backend yang dikonfigurasi, yang sering terjadi saat menggunakan Kubernetes Service sebagai backend.

  • Gagal membuat koneksi dengan hulu.

  • Permintaan atau respons hulu terlalu besar, menyebabkan kegagalan alokasi memori yang mengganggu interaksi bisnis normal.

• 503 Service Unavailable: Di Nginx, kode status ini menunjukkan bahwa semua server hulu tidak tersedia. Dalam skenario cloud-native, hal ini memiliki makna spesifik. Penyebab umum meliputi:

  • Tidak ada backend yang tersedia, yang jarang terjadi.

  • Trafik terlalu berat dan sedang dikendalikan lajunya oleh pembatas laju Ingress.

• 504 Gateway Timeout: Error ini menunjukkan masalah timeout pada paket terkait bisnis antara Nginx dan hulu. Penyebab umumnya adalah respons hulu yang tertunda.

Saat menghadapi masalah ini, pertama-tama kumpulkan informasi umum untuk menentukan cakupan masalah dan langkah selanjutnya dalam troubleshooting:

• Informasi log akses Nginx, terutama request_time, upstream_connect_time, dan upstream_response_time.

• Tinjau informasi error_log Nginx untuk pesan error abnormal saat masalah terjadi.

• Jika pemeriksaan kesehatan liveness atau readiness dikonfigurasi, periksa statusnya.

Berdasarkan informasi ini, pantau metrik berikut untuk perubahan saat kemungkinan terjadi kegagalan koneksi:

Jika Anda menghadapi situasi di mana respons Nginx lambat, misalnya saat terjadi timeout tetapi request_time Nginx pendek, Anda dapat memantau perubahan metrik berikut:

Perubahan metrik ini selama insiden dapat membantu mempersempit cakupan investigasi.

Masalah reset TCP

Paket reset TCP adalah respons terhadap situasi tak terduga dalam protokol TCP. Paket ini biasanya menyebabkan error berikut dalam program pengguna:

• Error connection reset by peer, umum ditemukan di aplikasi yang bergantung pada pustaka C, seperti Nginx.

• Error Broken pipe, umum ditemukan di aplikasi yang menggunakan wrapper koneksi TCP, seperti Java atau Python.

Di lingkungan jaringan cloud-native, ada banyak alasan umum untuk paket reset. Berikut beberapa penyebab umum:

• Pengecualian di sisi server mencegah layanan normal, seperti memori TCP yang tidak mencukupi. Situasi ini biasanya memicu reset proaktif.

• Saat menggunakan Service atau load balancing, trafik diteruskan ke backend yang tidak diharapkan karena anomali pada mekanisme stateful, seperti pemilihan endpoint atau conntrack.

• Pelepasan koneksi karena alasan keamanan.

• Di lingkungan NAT atau skenario konkurensi tinggi, terjadi Protection Against Wrapped Sequence Numbers (PAWS) atau wraparound nomor urut.

• Menggunakan TCP Keepalive untuk mempertahankan koneksi, tetapi tidak ada komunikasi bisnis normal dalam waktu lama.

Untuk membedakan akar penyebab ini dengan cepat, Anda dapat mengumpulkan beberapa informasi dan metrik dasar:

1. Analisis topologi jaringan antara klien dan server saat paket reset dihasilkan.

2. Pantau perubahan metrik berikut:

   Nama metrik	Deskripsi
   kubeskoop_tcpext_tcpabortontimeout	Ditambahkan saat reset dikirim karena jumlah maksimum panggilan keepalive, window probe, atau retransmisi terlampaui.
   kubeskoop_tcpext_tcpabortonlinger	Jumlah reset yang dikirim untuk segera mereklaim koneksi dalam keadaan FIN_WAIT2 saat opsi TCP Linger2 diaktifkan.
   kubeskoop_tcpext_tcpabortonclose	Ditambahkan saat paket reset dikirim karena masih ada data yang belum dibaca saat koneksi TCP ditutup karena alasan di luar mesin keadaan.
   kubeskoop_tcpext_tcpabortonmemory	Jumlah reset yang dikirim untuk menghentikan koneksi karena memori tidak mencukupi yang dipicu oleh tcp_check_oom saat mengalokasikan sumber daya seperti tw_sock atau tcp_sock.
   kubeskoop_tcpext_tcpabortondata	Jumlah reset yang dikirim untuk reklamasi koneksi cepat saat opsi Linger atau Linger2 diaktifkan.
   kubeskoop_tcpext_tcpackskippedsynrecv	Jumlah kali socket dalam keadaan SYN_RECV tidak membalas dengan ACK.
   kubeskoop_tcpext_tcpackskippedpaws	Jumlah kali paket ACK tidak dikirim karena pembatasan laju Out-of-Window (OOW), meskipun koreksi telah dipicu oleh mekanisme PAWS.
   kubeskoop_tcp_estabresets	Jumlah kali koneksi TCP ditutup secara abnormal dalam satu Pod. Metrik ini hanya menghitung hasilnya.
   kubeskoop_tcp_outrsts	Jumlah paket reset yang dikirim oleh TCP dalam satu Pod.

Jitter latensi jaringan intermiten

Jitter latensi jaringan intermiten adalah masalah umum dan sulit didiagnosis di lingkungan cloud-native. Masalah ini memiliki banyak penyebab dan dapat menyebabkan ketiga jenis masalah yang disebutkan sebelumnya. Dalam skenario jaringan kontainer, latensi jaringan dalam satu node biasanya disebabkan oleh:

• Proses real-time yang dikelola oleh penjadwal RT berjalan terlalu lama, menyebabkan proses bisnis atau thread kernel jaringan mengantre lama atau diproses secara lambat.

• Proses itu sendiri mengalami panggilan eksternal panjang sesekali, seperti respons lambat dari disk cloud atau peningkatan intermiten Round-Trip Time (RTT) RDS, yang memperlambat pemrosesan permintaan.

• Masalah konfigurasi node menyebabkan beban tidak merata antara CPU atau node NUMA berbeda, menyebabkan sistem yang sangat terbebani mengalami kelambatan.

• Latensi yang disebabkan oleh mekanisme stateful di kernel, seperti operasi confirm conntrack, atau banyak socket yatim yang memengaruhi pencarian socket normal.

Meskipun masalah ini tampak sebagai masalah jaringan, akar penyebabnya sering kali terkait dengan faktor sistem operasi lainnya. Pantau metrik berikut untuk mempersempit cakupan investigasi:

Kasus 1: Timeout DNS intermiten

Masalah

Pelanggan mengalami timeout resolusi DNS intermiten. Aplikasi pelanggan berjalan di PHP, dan layanan DNS dikonfigurasi dengan CoreDNS.

Proses troubleshooting

1. Berdasarkan deskripsi pelanggan, kami memperoleh data pemantauan terkait DNS.

2. Analisis data selama periode error mengungkapkan hal berikut:

   • Metrik kubeskoop_udp_noports meningkat sebesar 1 selama periode error. Nilai metrik keseluruhan kecil.

   • Metrik kubeskoop_packetloss_total meningkat sebesar 1. Perubahan kehilangan paket kecil.

3. Pelanggan melaporkan bahwa alamat DNS yang dikonfigurasi adalah alamat penyedia layanan publik. Informasi ini, dikombinasikan dengan data pemantauan, menunjukkan bahwa respons DNS lambat adalah akar penyebabnya. Paket respons DNS tiba setelah aplikasi sisi pengguna sudah mengalami timeout.

Kasus 2: Kegagalan koneksi intermiten di Java

Masalah

Pelanggan melaporkan bahwa instans Tomcat mereka menjadi tidak tersedia secara intermiten, dengan setiap gangguan berlangsung 5 hingga 10 detik.

Proses troubleshooting

1. Analisis log mengonfirmasi bahwa Java Runtime pelanggan melakukan operasi Garbage Collection (GC) saat masalah terjadi.

2. Setelah menerapkan pemantauan KubeSkoop, kami menemukan peningkatan signifikan pada metrik kubeskoop_tcpext_listendrops pada saat masalah terjadi.

3. Kami menyimpulkan bahwa saat Java Runtime pelanggan melakukan GC, kecepatan pemrosesan permintaan melambat, menunda pelepasan koneksi. Namun, permintaan koneksi baru tidak dibatasi, sehingga menciptakan banyak koneksi. Hal ini mengisi backlog socket listen dan menyebabkan overflow, yang mengakibatkan peningkatan kubeskoop_tcpext_listendrops.

4. Akumulasi koneksi pelanggan bersifat sementara, dan kapasitas pemrosesan tidak menjadi masalah. Kami merekomendasikan agar pelanggan menyesuaikan parameter Tomcat terkait, yang menyelesaikan masalah tersebut.

Kasus 3: Jitter latensi jaringan intermiten

Masalah

Pelanggan menemukan bahwa permintaan antara aplikasi mereka dan Redis mengalami peningkatan RTT intermiten, menyebabkan timeout bisnis. Namun, masalah tersebut tidak dapat direproduksi.

Proses troubleshooting

1. Analisis log menunjukkan bahwa pelanggan mengalami permintaan Redis intermiten dengan total waktu respons melebihi 300 ms.

2. Setelah menerapkan KubeSkoop, data pemantauan menunjukkan peningkatan metrik kubeskoop_virtcmdlatency_latency saat masalah terjadi. Nilai le (label bucket histogram Prometheus) yang meningkat adalah 18 dan 15. Hal ini menunjukkan bahwa dua panggilan virtualisasi berlatensi tinggi telah terjadi. Yang dengan le=15 menyebabkan penundaan lebih dari 36 ms, dan yang dengan le=18 menyebabkan penundaan lebih dari 200 ms.

3. Karena panggilan virtualisasi kernel menggunakan CPU dan tidak dapat dipreempt, latensi intermiten disebabkan oleh panggilan virtualisasi berdurasi panjang selama pembuatan dan penghapusan Pod batch.

Kasus 4: Kegagalan pemeriksaan kesehatan Ingress Nginx

Masalah

Mesin Ingress mengalami kegagalan pemeriksaan kesehatan intermiten, disertai kegagalan permintaan bisnis.

Proses troubleshooting

1. Setelah menerapkan pemantauan, kami menemukan bahwa beberapa metrik menunjukkan perubahan abnormal pada saat masalah terjadi:

   1. Kedua metrik kubeskoop_tcpsummary_tcprxqueue dan kubeskoop_tcpsummary_tcptxqueue meningkat.

   2. kubeskoop_tcpext_tcptimeouts meningkat.

   3. kubeskoop_tcpsummary_tcptimewaitconn menurun, dan kubeskoop_tcpsummary_tcpestablishedconn meningkat.

2. Analisis mengonfirmasi bahwa kernel bekerja normal dan koneksi dibuat dengan benar. Namun, eksekusi proses abnormal, termasuk pemrosesan paket dari socket penerima dan pengiriman paket. Kami mencurigai adanya masalah penjadwalan atau batasan sumber daya pada proses pengguna.

3. Tinjauan pemantauan Cgroup mengungkapkan bahwa pelanggan mengalami throttling CPU pada saat masalah terjadi. Hal ini membuktikan bahwa batasan Cgroup secara intermiten mencegah proses pengguna dijadwalkan.

4. Dengan mengikuti panduan Enable the CPU Burst performance optimization policy, kami mengonfigurasi fitur CPU Burst untuk Ingress, yang menyelesaikan jenis masalah ini.