Container Service for Kubernetes：Gunakan KubeSkoop untuk memecahkan masalah jaringan

Instal komponen ACK KubeSkoop

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

2. Di halaman Clusters, temukan kluster yang ingin Anda kelola dan klik namanya. Di panel navigasi kiri, klik Add-ons.

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

4. Di halaman Install Component ACK KubeSkoop, klik Confirm.

Konfigurasikan komponen KubeSkoop

• Untuk mengonfigurasi komponen KubeSkoop dengan ConfigMap, jalankan perintah berikut:

  kubectl edit cm kubeskoop-config -n ack-kubeskoop

• Anda juga dapat mengonfigurasi komponen KubeSkoop di konsol.

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

  2. Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Configurations > ConfigMaps.

  3. Di halaman ConfigMaps, atur Namespace menjadi ack-kubeskoop, cari kubeskoop-config, lalu klik Edit di kolom Actions untuk kubeskoop-config.

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

     Parameter	Deskripsi	Nilai default
     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 melakukan tugas pemantauan atau manajemen.	true
     controllerAddr	Alamat komponen KubeSkoop Controller.	dns:kubeskoop-controller:10263
     metrics.probes	Daftar jenis metrik pemantauan yang akan dikumpulkan. Setiap probe berkaitan dengan kategori metrik tertentu.	- name: conntrack - name: qdisc - name: netdev - name: io - name: sock - name: tcpsummary - name: tcp - name: tcpext - name: udp - name: rdma Untuk informasi lebih lanjut tentang probe, lihat Probes, Metrics, and Events.

     Anda tidak perlu me-restart komponen ACK KubeSkoop setelah memperbarui ConfigMap. Komponen tersebut secara otomatis melakukan hot-reload perubahan untuk mengaktifkan atau menonaktifkan probe yang sesuai.

Konfigurasikan dasbor ARMS Prometheus

1. Masuk ke Konsol ARMS.

2. Di panel navigasi kiri, klik Integration Management.

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

4. Di 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 Konsol ACK. Di panel navigasi kiri, klik Clusters.

6. Di halaman Clusters, temukan kluster yang Anda inginkan dan klik namanya. Di panel kiri, pilih Operations > Prometheus Monitoring.

7. Klik tab Others. Anda dapat menemukan dasbor pemantauan node dan Pod yang dibuat oleh KubeSkoop dalam daftar dasbor.

Lihat metrik pemantauan KubeSkoop secara manual

KubeSkoop menyediakan data pemantauan dalam format Prometheus. Setelah menginstal KubeSkoop, Anda dapat mengakses port layanan dari instans Pod KubeSkoop apa 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 yang diperoleh pada 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

Pecahkan masalah timeout DNS

Di lingkungan cloud-native, masalah timeout layanan DNS dapat menyebabkan kegagalan akses layanan. Alasan 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.

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

Anda dapat menggunakan metrik berikut untuk membantu memecahkan 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.

Pecahkan masalah error HTTP 499/502/503/504 pada Nginx Ingress

Di lingkungan cloud-native, gateway Ingress atau 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: Klien yang meminta Nginx 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: Gagal melakukan resolusi DNS untuk backend yang dikonfigurasi, yang sering terjadi saat menggunakan Kubernetes Service sebagai backend.

  • Gagal melakukan resolusi DNS 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: Di Nginx, kode status ini digunakan untuk menunjukkan bahwa semua server hulu tidak tersedia. Dalam skenario cloud-native, kode status ini memiliki beberapa makna spesifik. Penyebab umum meliputi:

  • Tidak ada backend yang tersedia, yang merupakan situasi langka.

  • Trafik terlalu berat dan dikendalikan oleh pengaturan limit-req Ingress.

• 504: 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 pemecahan masalah:

• Informasi access_log Nginx, terutama request_time, upstream_connect_time, dan upstream_response_time.

• Informasi error_log Nginx. Periksa adanya pesan error abnormal saat masalah terjadi.

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

Berdasarkan informasi di atas, perhatikan perubahan metrik berikut saat kegagalan koneksi mungkin terjadi:

Jika Anda mengalami respons Nginx yang lambat, seperti terjadinya timeout meskipun request_time Nginx pendek, perhatikan perubahan metrik berikut:

Berdasarkan perubahan metrik ini pada saat masalah terjadi, Anda dapat mempersempit cakupan investigasi..

Pecahkan masalah reset TCP

Paket reset TCP adalah respons terhadap situasi tak terduga dalam protokol TCP. Paket ini biasanya memiliki efek berikut pada program pengguna:

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

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

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

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

• 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 pembungkusan 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. Perhatikan perubahan metrik berikut:

   Nama metrik	Deskripsi
   kubeskoop_tcpext_tcpabortontimeout	Bertambah ketika reset dikirim karena jumlah maksimum panggilan keepalive, probe window, atau retransmisi telah terlampaui.
   kubeskoop_tcpext_tcpabortonlinger	Jumlah reset yang dikirim untuk segera mereklamasi koneksi dalam keadaan FIN_WAIT2 ketika opsi TCP Linger2 diaktifkan.
   kubeskoop_tcpext_tcpabortonclose	Bertambah ketika 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 melalui reset 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.

Pecahkan masalah jitter latensi jaringan intermiten

Jitter latensi jaringan intermiten adalah salah satu masalah paling 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 yang berbeda, menyebabkan sistem yang sangat terbebani mengalami lag.

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

Saat menghadapi masalah seperti ini, meskipun tampak sebagai masalah jaringan, akar penyebabnya sering kali terkait dengan faktor sistem operasi lainnya. Perhatikan metrik berikut untuk mempersempit cakupan investigasi:

Kasus 1: Masalah timeout DNS intermiten

Masalah

Seorang pelanggan mengalami timeout resolusi DNS intermiten. Bisnis pengguna berjalan di PHP, dan layanan DNS dikonfigurasi dengan CoreDNS.

Proses pemecahan masalah

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

2. Analisis data selama periode error mengungkapkan masalah berikut:

   • 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 yang lambat adalah akar penyebabnya. Paket respons DNS tiba setelah aplikasi sisi pengguna sudah mengalami timeout.

Kasus 2: Kegagalan koneksi intermiten pada aplikasi Java

Masalah

Seorang pelanggan menemukan anomali di mana Tomcat menjadi tidak tersedia secara intermiten, dengan setiap kejadian berlangsung sekitar 5 hingga 10 detik.

Proses pemecahan masalah

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 ketika Java Runtime pelanggan melakukan GC, kecepatan pemrosesan permintaan melambat, menunda pelepasan koneksi. Namun, permintaan koneksi baru terus berdatangan, menciptakan banyak koneksi. Hal ini mengisi backlog socket listen hingga penuh dan menyebabkan overflow, yang mengakibatkan peningkatan kubeskoop_tcpext_listendrops.

4. Akumulasi koneksi pelanggan bersifat sementara, dan kapasitas pemrosesan itu sendiri bukan masalah. Kami merekomendasikan pelanggan untuk menyesuaikan parameter Tomcat terkait, yang menyelesaikan masalah tersebut.

Kasus 3: Jitter latensi jaringan intermiten untuk pelanggan

Masalah

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

Proses pemecahan masalah

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 pada 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. Panggilan dengan le=15 menyebabkan penundaan lebih dari 36 ms, dan panggilan dengan le=18 menyebabkan penundaan lebih dari 200 ms.

3. Karena panggilan virtualisasi kernel menggunakan CPU dan tidak dapat dipreempt, latensi intermiten pelanggan disebabkan oleh beberapa panggilan virtualisasi yang membutuhkan waktu terlalu lama untuk dieksekusi selama pembuatan dan penghapusan Pod secara batch.

Kasus 4: Kegagalan Pemeriksaan Kesehatan intermiten untuk Ingress Nginx

Masalah

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

Proses pemecahan masalah

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 aktual. Kami menduga adanya masalah penjadwalan atau batasan sumber daya pada proses pengguna.

3. Kami menyarankan pengguna untuk memeriksa pemantauan Cgroup dan menemukan bahwa pelanggan mengalami fenomena CPU Throttled pada saat masalah terjadi. Hal ini membuktikan bahwa batasan Cgroup secara intermiten mencegah proses pengguna dijadwalkan.

4. Dengan mengikuti panduan Aktifkan kebijakan optimasi performa CPU Burst, kami mengonfigurasi fitur CPU Burst untuk Ingress, yang menyelesaikan jenis masalah ini.