Sebagian atau seluruh informasi di halaman ini mungkin tidak berlaku untuk Cloud de Confiance dari S3NS. Lihat Perbedaan dengan Google Cloud untuk mengetahui detail selengkapnya.

Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

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 intermiten, error HTTP 5xx, atau kehilangan paket pada koneksi jaringan yang terlalu banyak digunakan.
Kehabisan Resource: Pod atau node tertentu menunjukkan penggunaan CPU atau memori yang jauh lebih tinggi daripada armada lainnya.
Pola Ketidakseimbangan Traffic:
- Ketidakseimbangan Per-Pod: traffic hanya mencapai subset kecil Pod yang tersedia, meskipun semua Pod dilaporkan sehat dan siap.
- Ketidakseimbangan Per-Node: satu atau beberapa node menerima paket atau permintaan yang jauh lebih banyak daripada yang lain, yang sering terlihat saat menggunakan externalTrafficPolicy: Local dengan penempatan Pod yang tidak merata.
- Sesi Klien Tetap: 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 Lapisan 7 (Ingress/Gateway): buat plot 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.

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 traffic bervolume besar, Pod tersebut akan kelebihan beban, sehingga menyebabkan hotspot yang menerima beban yang jauh lebih banyak daripada yang lain, sementara Pod lain tetap kurang dimanfaatkan.

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

Jika sessionAffinity ditetapkan ke ClientIP, Layanan 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 ditetapkan ke None (perilaku default), load balancer Lapisan 4 biasanya mendistribusikan koneksi menggunakan hash dari 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 "ketetapan" koneksi dengan secara konsisten merutekan koneksi dengan nilai tuple yang identik ke backend yang sama, hashing ini tidak menjamin bahwa semua koneksi dari alamat IP klien tertentu akan selalu menuju ke Pod yang sama jika elemen tuple lainnya berubah.

Untuk mengetahui informasi selengkapnya, lihat Afinitas Sesi.

Untuk GKE Gateway, GCPTrafficDistributionPolicy CRD 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 ketetapan 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 Layanan 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 berumur lebih panjang atau menangani permintaan yang jauh lebih banyak daripada yang lain. Hal ini memusatkan traffic pada Pod tertentu, mirip dengan afinitas sesi, sehingga membuat hotspot tempat Pod tersebut kelebihan beban, sementara Pod lain 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 berumur panjang.

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

Mengonfigurasi klien untuk menggunakan beberapa koneksi: daripada mengandalkan satu koneksi berumur panjang, konfigurasi klien untuk membuka dan mengelola kumpulan beberapa koneksi ke load balancer. Hal ini memungkinkan load balancer mendistribusikan upaya koneksi baru di seluruh Pod backend yang tersedia, sehingga meningkatkan distribusi traffic secara keseluruhan.
Menutup dan membuka kembali koneksi secara berkala: untuk aplikasi yang secara alami mempertahankan koneksi berumur panjang, konfigurasikan aplikasi atau kliennya untuk menutup dan membuka kembali koneksi secara berkala. Meskipun hal ini menimbulkan sedikit overhead pembentukan ulang koneksi, hal ini memberikan peluang baru bagi load balancer untuk mendistribusikan upaya koneksi berikutnya ke Pod backend yang berbeda dan kurang digunakan. Pendekatan ini sangat efektif untuk layanan yang penghentian dan pembentukan ulang koneksinya tidak terlalu mengganggu.
Menerapkan pengosongan koneksi yang agresif: pastikan Pod Anda dikonfigurasi untuk penghentian normal dan pengosongan koneksi. Saat Pod dihentikan dengan lancar (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 dihentikan.

Dengan mengelola perilaku koneksi secara aktif, Anda dapat membantu load balancer mendistribusikan traffic secara lebih merata, bahkan dengan koneksi berumur panjang.

Hashing 5-Tuple menyebabkan distribusi yang tidak merata

Ini adalah perilaku default untuk banyak load balancer Lapisan 4 jika 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:

Menggunakan load balancing Lapisan 7: GKE Ingress dan Gateway beroperasi di tingkat permintaan, sehingga memungkinkan keduanya mendistribusikan permintaan dari satu klien ke beberapa Pod backend.
Menyesuaikan perilaku klien: konfigurasi 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 asal container. Node dengan lebih banyak Pod menerima lebih banyak traffic, yang dapat menyebabkan beberapa node kelebihan beban, sementara yang lain kurang dimanfaatkan.

Masalah ini sangat relevan saat Anda menggunakan externalTrafficPolicy: Local.

Setelan kebijakan traffic eksternal menyebabkan distribusi yang tidak merata

Setelan externalTrafficPolicy pada Layanan 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 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.