Memecahkan masalah distribusi traffic yang tidak merata

Autopilot Standard

Dokumen ini menunjukkan cara menyelesaikan masalah terkait distribusi traffic yang tidak merata ke Layanan Kubernetes.

Mengidentifikasi gejala distribusi traffic yang tidak merata

Distribusi traffic yang tidak merata, yang sering disebut sebagai hotspot, terjadi saat subset Pod atau node menangani jumlah total workload yang tidak proporsional sementara yang lain tetap kurang dimanfaatkan.

Gejala umum meliputi:

• Hambatan Performa: pengguna mungkin mengalami timeout sesekali, error HTTP 5xx, atau kehilangan paket pada koneksi jaringan yang terlalu banyak digunakan.
• Kehabisan Resource: Pod atau node tertentu menunjukkan pemakaian CPU atau memori yang jauh lebih tinggi daripada bagian fleet lainnya.
• Pola Ketidakseimbangan Traffic:
  • Ketidakseimbangan Per-Pod: traffic hanya mencapai sebagian kecil Pod yang tersedia, meskipun semua Pod dilaporkan responsif dan siap.
  • Ketidakseimbangan Per-Node: satu atau beberapa node menerima lebih banyak paket atau permintaan daripada yang lain, sering terlihat saat menggunakan externalTrafficPolicy: Local dengan penempatan Pod yang tidak merata.
  • Sesi Klien Sticky: semua permintaan dari satu klien bervolume tinggi secara konsisten dirutekan ke Pod backend yang sama.

Diagnosis menggunakan Cloud Monitoring

Untuk mengonfirmasi gejala ini, visualisasikan pola traffic menggunakan metrik berikut:

• Untuk Layer 7 (Ingress/Gateway): petakan loadbalancing.googleapis.com/backend/request_count dan kelompokkan menurut backend_target untuk membandingkan volume permintaan di berbagai backend.

Memahami penyebab umum distribusi traffic yang tidak merata

Bagian ini menjelaskan penyebab umum distribusi traffic yang tidak merata ke Layanan Kubernetes. Ketidakseimbangan ini dapat menyebabkan hambatan performa, kehabisan resource pada Pod tertentu, dan penurunan ketersediaan aplikasi, dengan beberapa Pod menerima traffic yang jauh lebih banyak daripada yang lain, sementara beberapa Pod menerima sangat sedikit atau tidak ada traffic.

Afinitas sesi menyebabkan distribusi yang tidak merata

Masalah berikut terjadi saat load balancer dengan afinitas sesi yang diaktifkan secara konsisten merutekan permintaan dari klien yang sama ke Pod backend yang sama. Jika klien tertentu menghasilkan volume traffic yang besar, Pod tersebut akan kelebihan beban, sehingga menyebabkan hotspot yang menerima beban jauh lebih besar daripada Pod lainnya, sementara Pod lain tetap kurang dimanfaatkan.

Anda dapat mengonfigurasi afinitas sesi di objek Layanan Kubernetes menggunakan kolom sessionAffinity.

Jika sessionAffinity disetel ke ClientIP, Service akan memastikan bahwa semua koneksi yang berasal dari alamat IP klien yang sama secara konsisten dirutekan ke Pod backend yang sama. Hal ini memberikan afinitas sesi berbasis IP klien yang sebenarnya.

Jika sessionAffinity disetel ke None (perilaku default), load balancer Lapisan 4 biasanya mendistribusikan koneksi menggunakan hash berbagai parameter jaringan, seperti 4-tuple (alamat IP klien, alamat IP tujuan, port tujuan, protokol) atau 5-tuple (termasuk port sumber). Meskipun hashing ini dapat memberikan beberapa "kelekatan" koneksi dengan merutekan koneksi secara konsisten dengan nilai tuple yang identik ke backend yang sama, hashing ini tidak menjamin bahwa semua koneksi dari alamat IP klien tertentu akan selalu mengarah ke Pod yang sama jika elemen tuple lainnya berubah.

Untuk mengetahui informasi selengkapnya, lihat Afinitas Sesi.

Untuk GKE Gateway, GCPTrafficDistributionPolicyCRD mengonfigurasi afinitas sesi. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi resource Gateway menggunakan Kebijakan.

Untuk Load Balancer Jaringan passthrough eksternal regional, Anda dapat menggunakan afinitas sesi untuk mempertahankan kelekatan koneksi ke backend tertentu. Namun, perhatikan bahwa afinitas sesi itu sendiri dapat menyebabkan distribusi yang tidak merata jika beberapa klien menghasilkan lebih banyak traffic daripada yang lain.

Untuk mengetahui informasi selengkapnya, lihat Afinitas Sesi dan Ringkasan Load Balancer Jaringan passthrough eksternal berbasis layanan backend.

Contoh berikut menunjukkan manifes Service dengan sessionAffinity: ClientIP:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: LoadBalancer
  sessionAffinity: ClientIP  # This can cause uneven distribution
  ports:
  -   port: 80
    targetPort: 8080
  selector:
    app: my-app

Penggabungan koneksi menyebabkan distribusi yang tidak merata

Penggabungan koneksi terjadi saat load balancer menggunakan kembali koneksi yang ada ke Pod tertentu, meskipun Pod lain memiliki kapasitas yang tersedia. Perilaku ini dapat menyebabkan ketidakseimbangan jika beberapa koneksi berdurasi lebih lama atau menangani permintaan yang jauh lebih banyak daripada yang lain. Hal ini memusatkan traffic pada Pod tertentu, mirip dengan afinitas sesi, sehingga menciptakan hotspot tempat Pod tersebut menjadi kelebihan beban, sementara Pod lainnya tetap kurang dimanfaatkan.

Load balancer menerapkan penggabungan koneksi untuk meningkatkan performa dengan mengurangi overhead pembuatan koneksi baru. Namun, jika tidak dikelola dengan benar, penggabungan koneksi dapat menyebabkan distribusi traffic yang tidak merata, terutama dengan aplikasi yang mempertahankan koneksi berdurasi panjang.

Untuk memitigasi distribusi yang tidak merata yang disebabkan oleh penggabungan koneksi, terapkan strategi di tingkat aplikasi atau klien:

• Mengonfigurasi klien untuk menggunakan beberapa koneksi: alih-alih mengandalkan satu koneksi yang berjalan lama, konfigurasi klien untuk membuka dan mengelola kumpulan beberapa koneksi ke load balancer. Hal ini memungkinkan load balancer untuk mendistribusikan upaya koneksi baru di seluruh Pod backend yang tersedia, sehingga meningkatkan distribusi traffic secara keseluruhan.

• Tutup dan buka kembali koneksi secara berkala: untuk aplikasi yang secara alami mempertahankan koneksi yang berjalan lama, konfigurasikan aplikasi tersebut atau kliennya agar menutup dan membuka kembali koneksi secara berkala. Meskipun hal ini menimbulkan sedikit overhead dalam pembuatan ulang koneksi, hal ini memberi load balancer peluang baru untuk mendistribusikan upaya koneksi berikutnya ke Pod backend yang berbeda dan kurang dimanfaatkan. Pendekatan ini sangat efektif untuk layanan yang penghentian dan pembentukan kembali koneksinya tidak terlalu mengganggu.

• Terapkan pengosongan koneksi yang agresif: pastikan Pod Anda dikonfigurasi untuk penghentian normal dan pengosongan koneksi. Saat Pod dihentikan dengan benar (misalnya, selama deployment atau pengurangan skala), load balancer harus berhenti mengirim koneksi baru ke Pod tersebut dan mengizinkan koneksi yang ada untuk diselesaikan atau dikosongkan. Hal ini memungkinkan traffic beralih ke Pod lain dengan lebih lancar dan membantu mencegah traffic terkonsentrasi pada Pod yang mengakhiri koneksi.

Dengan mengelola perilaku koneksi secara aktif, Anda dapat membantu load balancer mendistribusikan traffic secara lebih merata, bahkan dengan koneksi yang berjalan lama.

Hashing 5-Tuple menyebabkan distribusi yang tidak merata

Ini adalah perilaku default untuk banyak load balancer Layer 4 saat Anda tidak mengonfigurasi afinitas sesi secara eksplisit. Jika banyak koneksi berasal dari klien yang sama atau menggunakan kombinasi port yang sama, hal ini akan menghasilkan distribusi yang tidak merata.

Untuk mengatasi ketidakseimbangan yang disebabkan oleh hashing, pertimbangkan hal berikut:

• Gunakan load balancing Lapisan 7: GKE Ingress dan Gateway beroperasi di tingkat permintaan, sehingga dapat mendistribusikan permintaan dari satu klien ke beberapa Pod backend.

• Menyesuaikan perilaku klien: mengonfigurasi klien untuk menggunakan beberapa koneksi atau kumpulan port sumber yang lebih besar.

Distribusi Pod yang tidak merata di seluruh node menyebabkan distribusi yang tidak merata

Masalah ini muncul saat Pod tidak didistribusikan secara merata di seluruh node dan load balancer tidak menggunakan load balancing berbasis container. Node dengan lebih banyak Pod menerima lebih banyak traffic, yang dapat menyebabkan beberapa node kelebihan beban sementara node lainnya kurang dimanfaatkan.

Masalah ini sangat relevan saat Anda menggunakan externalTrafficPolicy: Local.

Setelan kebijakan traffic eksternal menyebabkan distribusi yang tidak merata

Setelan externalTrafficPolicy di Service Anda memengaruhi cara perutean traffic.

• Cluster: memungkinkan load balancer mendistribusikan traffic ke node mana pun di cluster. Gunakan setelan Cluster untuk distribusi yang paling merata di semua node dan Pod yang tersedia.
• Lokal: merutekan traffic hanya ke Pod yang berjalan di node yang sama dengan yang menerima traffic. Hal ini dapat menyebabkan distribusi yang tidak merata jika Anda tidak mendistribusikan Pod secara merata di seluruh node.

Afinitas node menyebabkan distribusi yang tidak merata

Menggunakan afinitas node untuk membatasi Pod ke subset node dapat menyebabkan node tersebut kelebihan beban, terutama jika workload tidak seimbang di seluruh node.

Pastikan Pod Anda tidak disematkan ke node tertentu.