Pengelolaan traffic gateway

Halaman ini menjelaskan cara kerja pengelolaan traffic Gateway.

Ringkasan

Jaringan Google Kubernetes Engine (GKE) dibuat berdasarkan Cloud Load Balancing.

Dengan menggunakan pengontrol Gateway GKE, pengguna GKE dapat mengontrol pengelolaan traffic secara deklaratif dan berbasis Kubernetes.

Pengelolaan traffic

Load balancing, penskalaan otomatis, dan pengelolaan kapasitas adalah dasar dari sistem pengelolaan traffic. Keduanya beroperasi bersama untuk menyamakan dan menstabilkan beban sistem.

Load balancing mendistribusikan traffic di seluruh Pod backend sesuai dengan lokasi, kondisi, dan beragam algoritma load balancing.
Autoscaling menskalakan replika workload untuk menciptakan kapasitas yang lebih besar guna menyerap lebih banyak traffic.
Pengelolaan kapasitas memantau penggunaan Layanan, sehingga traffic dapat membanjiri backend dengan kapasitas, bukan memengaruhi ketersediaan atau performa aplikasi.

Kemampuan pengelolaan traffic

Resource Gateway, HTTPRoute, Service, dan Policy menyediakan kontrol untuk mengelola traffic di GKE. Gateway GKE controller adalah bidang kontrol yang memantau resource ini.

Kemampuan pengelolaan traffic berikut tersedia saat men-deploy Layanan di GKE:

Kapasitas layanan: kemampuan untuk menentukan jumlah kapasitas traffic yang dapat diterima Layanan sebelum Pod diskalakan otomatis atau traffic diluapkan ke cluster lain yang tersedia.
Penskalaan otomatis berbasis traffic: penskalaan otomatis Pod dalam Layanan berdasarkan permintaan HTTP yang diterima per detik.

Pemisahan traffic: distribusi traffic eksplisit dan berbasis bobot di seluruh backend. Pemisahan traffic didukung dengan Gateway cluster tunggal di GA.

Dukungan pengelolaan traffic

Kemampuan pengelolaan traffic yang tersedia bergantung pada GatewayClass yang Anda deploy. Untuk daftar lengkap dukungan fitur, lihat Kemampuan GatewayClass. Tabel berikut merangkum dukungan GatewayClass untuk pengelolaan traffic:

GatewayClass	Kapasitas layanan	Penskalaan otomatis traffic	Load balancing multi-cluster	Pemisahan traffic¹
`gke-l7-global-external-managed`
`gke-l7-regional-external-managed`
`gke-l7-rilb`
`gke-l7-gxlb`
`gke-l7-global-external-managed-mc`
`gke-l7-regional-external-managed-mc`
`gke-l7-rilb-mc`
`gke-l7-gxlb-mc`

¹ Pemisahan traffic didukung dengan Gateway cluster tunggal di GA.

Load balancing regional dan zona

Kapasitas layanan, lokasi, dan kondisi layanan menentukan jumlah traffic yang dikirim load balancer ke backend tertentu. Keputusan load balancing dibuat pada level berikut:

Regional: traffic mengalami load balancing di seluruh zona sesuai dengan kapasitas penayangan yang tersedia di zona tersebut. Untuk mempelajari lebih lanjut, lihat load balancing regional.
Zonal: setelah traffic ditentukan untuk zona tertentu, load balancer mendistribusikan traffic secara merata di seluruh backend dalam zona tersebut. Koneksi TCP yang ada dan setelan persistensi sesi akan dipertahankan, sehingga permintaan berikutnya akan mengarah ke backend yang sama, asalkan Pod backend responsif. Untuk mempelajari lebih lanjut, lihat load balancing zonal.

Mencegah traffic luapan.

Traffic tambahan membantu mencegah melampaui kapasitas aplikasi yang dapat memengaruhi performa atau ketersediaan.

Namun, Anda mungkin tidak ingin meluapkan traffic. Aplikasi yang sensitif terhadap latensi, misalnya, mungkin tidak mendapatkan manfaat dari traffic luapan ke backend yang lokasinya lebih jauh.

Anda dapat menggunakan salah satu metode berikut untuk mencegah traffic luapan:

Hanya gunakan Gateway cluster tunggal yang dapat menghosting Layanan hanya dalam satu cluster.

Tetapkan kapasitas Layanan pada tingkat yang cukup tinggi sehingga kapasitas traffic tidak akan terlampaui secara realistis, kecuali jika benar-benar diperlukan.

Load balancing dalam suatu region

Dalam suatu region, traffic didistribusikan di seluruh zona sesuai dengan kapasitas backend yang tersedia. Ini tidak menggunakan luapan (overflow), melainkan load balancing secara proporsional dengan kapasitas Layanan di setiap zona. Setiap alur atau sesi individual selalu dikirim ke satu Pod backend yang konsisten dan tidak dibagi.

Diagram berikut menunjukkan bagaimana distribusi traffic dalam satu region:

Traffic didistribusikan dalam satu region

Dalam diagram:

Sebuah Layanan di-deploy di cluster GKE regional. Layanan memiliki 4 Pod yang di-deploy secara tidak merata di seluruh zona. 3 Pod berada di zona A, 1 Pod di zona B, dan 0 Pod di zona C.
Layanan dikonfigurasi dengan max-rate-per-endpoint="10". Zona A memiliki total kapasitas 30 RPS, zona B memiliki 10 RPS kapasitas total, dan zona C memiliki 0 RPS dari total kapasitas, karena tidak memiliki Pod.
Gateway menerima total 16 RPS traffic dari klien yang berbeda. Traffic ini didistribusikan di seluruh zona secara proporsional dengan kapasitas yang tersisa di setiap zona.
Alur traffic dari setiap sumber atau klien secara konsisten di-load balanced ke Pod backend tunggal sesuai dengan setelan persistensi sesi. Distribusi pemisahan traffic ke berbagai alur traffic sumber sehingga setiap alur tidak dibagi. Akibatnya, diperlukan jumlah minimum keberagaman sumber atau klien untuk mendistribusikan traffic secara terperinci di berbagai backend.

Misalnya, jika traffic masuk melonjak dari 16 RPS menjadi 60 RPS, maka tidak ada cluster lain yang dapat dilewati traffic ini. Traffic terus didistribusikan sesuai dengan kapasitas zona relatif, meskipun traffic masuk melebihi total kapasitas. Akibatnya, zona A menerima 45 RPS dan zona B menerima 15 RPS.

Load balancing dalam suatu zona

Setelah traffic dikirim ke suatu zona, traffic tersebut akan didistribusikan secara merata ke semua backend dalam zona tersebut. Sesi HTTP bersifat tetap, bergantung pada setelan afinitas sesi. Kecuali jika backend tidak tersedia, koneksi TCP yang ada tidak akan pernah dipindahkan ke backend yang berbeda. Ini berarti bahwa koneksi yang tahan lama akan terus mengarah ke Pod backend yang sama meskipun koneksi baru overflow karena kapasitas yang terbatas. Load balancer lebih memprioritaskan pemeliharaan koneksi yang ada daripada koneksi baru.

Kapasitas layanan

Dengan kapasitas layanan, Anda dapat menentukan nilai Permintaan per Detik (RPS) per Pod dalam Layanan. Nilai ini menunjukkan rata-rata RPS maksimum per Pod yang dapat diterima oleh Layanan. Nilai ini dapat dikonfigurasi di Layanan dan digunakan untuk menentukan penskalaan otomatis berbasis traffic dan load balancing berbasis kapasitas.

Persyaratan

Kapasitas layanan memiliki persyaratan dan batasan berikut:

Hanya didukung dengan resource GatewayClass dan jenis Ingress yang ditetapkan dalam Dukungan pengelolaan traffic.

Hanya memengaruhi load balancing jika Anda menggunakan penskalaan otomatis berbasis traffic. Jika tidak, Kapasitas layanan tidak berpengaruh pada traffic jaringan.

Mengonfigurasi kapasitas Layanan

Untuk mengonfigurasi kapasitas Layanan, buat Layanan menggunakan anotasi networking.gke.io/max-rate-per-endpoint. Manifes berikut menjelaskan Layanan dengan RPS maksimum:

apiVersion: v1
kind: Service
metadata:
  name: store
  annotations:
    networking.gke.io/max-rate-per-endpoint: "RATE_PER_SECOND"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP

Ganti RATE_PER_SECOND dengan permintaan HTTP/HTTPS maksimum per detik yang harus diterima satu Pod dalam Layanan ini.

Nilai max-rate-per-endpoint membuat kapasitas dinamis untuk Layanan berdasarkan jumlah Pod dalam Layanan. Total nilai kapasitas Layanan dihitung dengan mengalikan nilai max-rate-per-endpoint dengan jumlah replika, seperti yang dijelaskan dalam formula berikut:

Total Service capacity = max-rate-per-endpoint * number of replicas

Jika autoscaler meningkatkan jumlah Pod dalam Layanan, total kapasitas Layanan akan dihitung sebagaimana mestinya. Jika suatu Layanan diperkecil skalanya hingga nol Pod, berarti Layanan tersebut memiliki kapasitas nol dan tidak menerima traffic apa pun dari load balancer.

Kapasitas layanan dan NEG mandiri

Kapasitas layanan juga dapat dikonfigurasi saat menggunakan NEG mandiri, tetapi tidak menggunakan anotasi max-rate-per-endpoint. Jika menggunakan NEG mandiri, max-rate-per-endpoint dikonfigurasi secara manual saat menambahkan NEG ke resource Layanan Backend. Dengan menggunakan perintah gcloud compute backend-services add- backend, flag --max-rate-per-endpoint dapat mengonfigurasi kapasitas untuk setiap NEG satu per satu.

Tindakan ini dapat berguna untuk alur kerja berikut:

Saat men-deploy load balancer internal dan eksternal secara manual menggunakan NEG mandiri
Saat men-deploy Traffic Director di GKE menggunakan NEG mandiri

Tidak ada perbedaan fungsional saat mengonfigurasi kapasitas layanan dengan NEG mandiri. Penskalaan otomatis traffic dan spillover traffic didukung.

Menentukan kapasitas Layanan Anda

Menentukan nilai untuk max-rate-per-endpoint memerlukan pemahaman tentang karakteristik performa aplikasi dan sasaran load balancing Anda. Strategi berikut dapat membantu Anda menentukan karakteristik performa aplikasi:

Amati aplikasi Anda di lingkungan pengujian dan lingkungan produksi saat dikonfigurasi tanpa kapasitas Layanan.
Gunakan Cloud Monitoring untuk membuat korelasi antara permintaan traffic dan tujuan tingkat layanan performa (SLO) Anda.

Gunakan metrik load balancer, seperti https atau request_count untuk memetakan level RPS.

Tentukan SLO performa untuk aplikasi Anda. SLO tersebut mungkin salah satu atau beberapa dari yang berikut, bergantung pada apa yang Anda anggap sebagai performa "buruk" atau "tidak stabil". Semua hal berikut dapat dikumpulkan dari metrik load balancer Cloud Monitoring:
- Kode error response
- Respons atau latensi total
- Backend yang tidak responsif atau periode nonaktif
Amati aplikasi Anda dengan ramai traffic di lingkungan pengujian dan produksi. Dalam lingkungan pengujian, fokuskan aplikasi Anda pada peningkatan beban permintaan agar Anda dapat melihat dampak dari berbagai metrik performa ketika traffic meningkat. Dalam lingkungan produksi, amati level pola traffic yang realistis.

Kapasitas Layanan default

Semua Layanan yang terpasang ke resource GKE memiliki kapasitas Layanan default yang telah dikonfigurasi meskipun tidak dikonfigurasi secara eksplisit menggunakan anotasi tersebut. Untuk mempelajari lebih lanjut, lihat Kapasitas layanan default.

Tabel berikut menjelaskan kapasitas default:

Jenis resource load balancing	`max-rate-per-endpoint` Default
Ingress (internal dan external)	1 RPS
Gateway (semua GatewayClass)	100.000.000 RPS
MultiClusterIngress	100.000.000 RPS

Penskalaan otomatis berbasis traffic

Penskalaan otomatis berbasis traffic adalah kemampuan GKE yang mengintegrasikan sinyal traffic secara native dari load balancer untuk menskalakan Pod secara otomatis. Penskalaan otomatis berbasis traffic hanya didukung untuk Gateway cluster tunggal.

Untuk menggunakan penskalaan otomatis berbasis traffic, lihat Penskalaan otomatis berdasarkan traffic load balancer.

Penskalaan otomatis berbasis traffic memberikan manfaat berikut:

Aplikasi yang tidak terikat dengan CPU atau memori mutlak mungkin memiliki batas kapasitas yang tidak tercermin dalam penggunaan CPU atau memorinya.
Traffic, atau permintaan per detik (RPS) adalah metrik yang lebih mudah dipahami dalam beberapa kasus karena lebih selaras dengan penggunaan aplikasi dan metrik bisnis seperti kunjungan halaman atau pengguna aktif harian (DAU).
Traffic adalah indikator utama yang merepresentasikan permintaan instan dibandingkan dengan CPU atau memori yang merupakan indikator yang lambat.
Kombinasi metrik penskalaan otomatis CPU, memori, dan traffic memberikan cara holistik aplikasi penskalaan otomatis yang menggunakan beberapa dimensi untuk memastikan bahwa kapasitas disediakan dengan tepat.

Diagram berikut menunjukkan cara kerja penskalaan otomatis berbasis traffic:

Penskalaan otomatis berbasis traffic

Dalam diagram:

Pemilik layanan mengonfigurasi kapasitas Layanan dan pemakaian target untuk Deployment.
Gateway menerima traffic dari klien yang menuju ke Layanan store. Gateway mengirimkan telemetri pemakaian ke Autoscaler Pod GKE. Pemakaian setara dengan traffic aktual yang diterima oleh setiap Pod dibagi dengan kapasitas Pod yang dikonfigurasi.
Penskalaan otomatis Pod GKE menaikkan atau menurunkan skala Pod sesuai dengan penggunaan target yang dikonfigurasi.

Perilaku penskalaan otomatis

Diagram berikut menunjukkan cara kerja penskalaan otomatis berbasis traffic pada aplikasi yang menerima 10 RPS melalui load balancer:

Penskalaan otomatis berbasis traffic dengan 10 RPS

Dalam diagram, pemilik layanan telah mengonfigurasi kapasitas Layanan store ke 10 RPS, yang berarti bahwa setiap Pod dapat menerima maksimum 10 RPS. HorizontalPodAutoscaler dikonfigurasi dengan averageUtilization disetel ke 70, yang berarti bahwa target pemakaian adalah 70% dari 10 RPS per Pod.

Autoscaler mencoba menskalakan replika untuk mencapai persamaan berikut:

replicas = ceiling[ current traffic / ( averageUtilization * max-rate-per-endpoint) ]

Dalam diagram, persamaan ini dihitung dengan:

ceiling[ 10 rps / (0.7 * 10 rps) ] = ceiling[ 1.4 ] = 2 replicas

10 RPS traffic menghasilkan 2 replika. Setiap replika menerima 6 RPS, yang berada di bawah target penggunaan sebesar 7 RPS.

Pemisahan traffic

Pemisahan traffic menggunakan rasio eksplisit, yang disebut bobot, yang menentukan proporsi permintaan HTTP yang dikirim ke Layanan. Resource HTTPRoute memungkinkan Anda mengonfigurasi bobot pada daftar Layanan. Bobot relatif di antara Layanan menentukan pemisahan traffic di antara layanan-layanan tersebut. Hal ini berguna untuk memisahkan traffic selama peluncuran, perubahan terbatas, atau untuk keadaan darurat.

Diagram berikut menjelaskan contoh konfigurasi pemisahan traffic:

Konfigurasi pemisahan traffic

Dalam diagram:

Pemilik layanan mengonfigurasi dua layanan untuk satu rute, dengan aturan yang membagi traffic 90% ke store-v1 dan 10% ke store-v2.
Gateway menerima traffic dari klien yang mengarah ke URL aplikasi Play Store dan traffic tersebut dibagi sesuai dengan aturan yang telah dikonfigurasi. 90% rute lalu lintas ke store-v1 dan 10% rute ke store-v2.

Pembagian traffic digunakan untuk memisahkan traffic untuk peluncuran versi aplikasi. Dengan contoh pemisahan traffic, Anda akan memiliki dua Deployment terpisah, store-v1 dan store-v2, yang masing-masing memiliki Service sendiri, store-v1 dan store-v2. Bobot dikonfigurasi di antara dua Layanan untuk mengalihkan traffic secara bertahap hingga store-v2 diluncurkan sepenuhnya.

Bobot vs kapasitas

Bobot dan kapasitas mengontrol jumlah traffic yang dikirim ke berbagai Layanan. Meskipun memiliki efek yang mirip, keduanya beroperasi secara berbeda dan memiliki kasus penggunaan yang berbeda. Keduanya dapat dan harus digunakan bersama, meskipun untuk tujuan yang berbeda.

Bobot

Bobot adalah kontrol traffic eksplisit. Bobot menentukan proporsi traffic yang tepat, terlepas dari traffic yang masuk dan pemanfaatan backend. Dalam contoh pemisahan traffic, jika store-v2 kelebihan kapasitas, atau jika semua replikanya gagal, 10% traffic akan tetap dialokasikan untuk store-v2, yang berpotensi menyebabkan traffic berkurang. Hal ini karena bobot tidak mengubah proporsi traffic berdasarkan pemakaian atau kondisi.

Bobot paling cocok untuk kasus penggunaan berikut:

Mengalihkan traffic antara berbagai versi layanan untuk peluncuran.
Memberikan orientasi layanan secara manual menggunakan pemisahan traffic eksplisit.
Mengalihkan traffic dari set backend untuk keperluan darurat atau pemeliharaan.

Kapasitas

Kapasitas adalah kontrol traffic implisit. Kapasitas menentukan proporsi traffic secara tidak langsung karena proporsi traffic bergantung pada jumlah traffic masuk, pemakaian backend, dan lokasi sumber traffic. Kapasitas adalah properti yang melekat pada Layanan dan biasanya jauh lebih jarang diperbarui.

Kapasitas paling cocok untuk kasus penggunaan berikut:

Mencegah pemakaian backend yang berlebihan selama lonjakan traffic.
Mengontrol tingkat penskalaan otomatis terkait traffic.

Langkah selanjutnya

Pelajari cara Men-deploy Gateway.