Ringkasan Load Balancer Jaringan proxy eksternal

Dokumen ini memperkenalkan konsep yang perlu Anda pahami untuk mengonfigurasi Load Balancer Jaringan proxy eksternal Google Cloud .

Load Balancer Jaringan proxy eksternal adalah load balancer reverse proxy yang mendistribusikan traffic TCP yang berasal dari internet ke instance virtual machine (VM) di jaringan Virtual Private Cloud (VPC)Google Cloud Anda. Saat menggunakan Load Balancer Jaringan proxy eksternal, traffic TCP atau SSL yang masuk akan dihentikan di load balancer. Koneksi baru kemudian meneruskan traffic ke backend terdekat yang tersedia menggunakan TCP atau SSL (direkomendasikan). Untuk kasus penggunaan lainnya, lihat Ringkasan Load Balancer Jaringan proxy.

Load Balancer Jaringan proxy eksternal memungkinkan Anda menggunakan satu alamat IP untuk semua pengguna di seluruh dunia. Load balancer otomatis merutekan traffic ke backend yang paling dekat dengan pengguna.

Dalam contoh ini, traffic SSL dari pengguna di Kota A dan Kota B dihentikan di lapisan load balancing, dan koneksi terpisah dibuat ke backend yang dipilih.

Cloud Load Balancing dengan penghentian SSL (klik untuk memperbesar).

Catatan: Meskipun Load Balancer Jaringan proxy eksternal dapat mendukung traffic HTTPS, Anda harus menggunakan Load Balancer Aplikasi eksternal untuk traffic HTTPS. Load Balancer Aplikasi eksternal mendukung sejumlah fitur khusus HTTP, termasuk pemilihan rute berdasarkan jalur permintaan HTTP dan penyeimbangan berdasarkan rasio permintaan. Untuk mengetahui detail selengkapnya, lihat Ringkasan Load Balancer Aplikasi Eksternal.

Mode operasi

Anda dapat mengonfigurasi Load Balancer Jaringan proxy eksternal dalam mode berikut:

• Load Balancer Jaringan proxy klasik diimplementasikan di Google Front End (GFE) yang didistribusikan secara global. Load balancer ini dapat dikonfigurasi untuk menangani traffic TCP atau SSL dengan menggunakan proxy TCP target atau proxy SSL target. Dengan Paket Premium, load balancer ini dapat dikonfigurasi sebagai layanan load balancing global. Dengan Paket Standar, load balancer ini dikonfigurasi sebagai layanan load balancing regional. Load Balancer Jaringan proxy klasik juga dapat digunakan untuk protokol lain yang menggunakan SSL, seperti WebSockets dan IMAP melalui SSL.
• Load Balancer Jaringan proxy eksternal global diimplementasikan pada GFE yang didistribusikan secara global dan mendukung kemampuan pengelolaan traffic lanjutan. Load balancer ini dapat dikonfigurasi untuk menangani traffic TCP atau SSL dengan menggunakan proxy TCP target atau proxy SSL target. Load balancer ini dikonfigurasi sebagai layanan load balancing global dengan Paket Premium. Load Balancer Jaringan proxy eksternal global juga dapat digunakan untuk protokol lain yang menggunakan SSL, seperti WebSockets dan IMAP melalui SSL.
• Load Balancer Jaringan proxy eksternal regional diimplementasikan pada stack software proxy Envoy open source. Load balancer ini hanya dapat menangani traffic TCP. Load balancer ini dikonfigurasi sebagai layanan load balancing regional yang dapat menggunakan Paket Premium atau Standar.

Mengidentifikasi mode

Untuk menentukan mode load balancer, selesaikan langkah-langkah berikut.

Konsol

1. Di konsol Google Cloud , buka halaman Load balancing.

   Buka Load balancing

2. Di tab Load Balancers, jenis, protokol, dan region load balancer akan ditampilkan. Jika region kosong, berarti load balancer bersifat global.

   Tabel berikut merangkum cara mengidentifikasi mode load balancer.

   Mode load balancer	Jenis load balancer	Jenis akses	Wilayah
   Load Balancer Jaringan proxy klasik	Jaringan (Proxy klasik)	Eksternal
   Load Balancer Jaringan proxy eksternal global	Jaringan (Proxy)	Eksternal
   Load Balancer Jaringan proxy eksternal regional	Jaringan (Proxy)	Eksternal	Menentukan region

gcloud

1. Gunakan perintah gcloud compute forwarding-rules describe:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

2. Di output perintah, periksa skema load balancing, region, dan tingkat jaringan. Tabel berikut merangkum cara mengidentifikasi mode load balancer.

   Mode load balancer	Skema load balancing	Aturan penerusan	Tingkat jaringan
   Load Balancer Jaringan proxy klasik	EKSTERNAL	Global	Standard atau Premium
   Load Balancer Jaringan proxy eksternal global	EXTERNAL_MANAGED	Global	Premium
   Load Balancer Jaringan proxy eksternal regional	EXTERNAL_MANAGED	Regional	Standard atau Premium

Penting: Setelah membuat load balancer, Anda tidak dapat mengedit modenya. Sebagai gantinya, Anda harus menghapus load balancer dan membuat yang baru.

Arsitektur

Diagram berikut menunjukkan komponen Load Balancer Jaringan proxy eksternal.

Global

Diagram ini menunjukkan komponen deployment Load Balancer Jaringan proxy eksternal global. Arsitektur ini berlaku untuk Load Balancer Jaringan proxy eksternal global dan Load Balancer Jaringan proxy klasik di Paket Premium.

Komponen Load Balancer Jaringan proxy eksternal global (klik untuk memperbesar).

Regional

Diagram ini menunjukkan komponen deployment Load Balancer Jaringan proxy eksternal regional.

Komponen Load Balancer Jaringan proxy eksternal regional (klik untuk memperbesar).

Berikut adalah komponen Load Balancer Jaringan proxy eksternal.

Subnet khusus proxy

Catatan: Subnet khusus proxy hanya diperlukan untuk Load Balancer Jaringan proxy eksternal regional.

Subnet khusus proxy menyediakan sekumpulan alamat IP yang digunakan Google untuk menjalankan proxy Envoy atas nama Anda. Anda harus membuat satu subnet khusus proxy di setiap region jaringan VPC tempat Anda menggunakan load balancer. Flag --purpose untuk subnet khusus proxy ini ditetapkan ke REGIONAL_MANAGED_PROXY. Semua load balancer regional berbasis Envoy di region dan jaringan VPC yang sama berbagi kumpulan proxy Envoy dari subnet khusus proxy yang sama.

VM backend atau endpoint dari semua load balancer di suatu region dan jaringan VPC menerima koneksi dari subnet khusus proxy.

Hal yang perlu diingat:

• Subnet khusus proxy hanya digunakan untuk proxy Envoy, bukan backend Anda.
• Alamat IP load balancer tidak berada di subnet khusus proxy. Alamat IP load balancer ditentukan oleh aturan penerusan terkelola eksternalnya.
• Subnet khusus proxy harus dikonfigurasi dengan jenis stack IPV4_IPV6 untuk menghentikan traffic IPv6 yang masuk dan IPV4_ONLY atau IPV4_IPV6 untuk menghentikan traffic IPv4 yang masuk.

Aturan penerusan dan alamat IP

Pratinjau — Load Balancer Jaringan proxy lintas region, eksternal regional, dan internal regional mendukung penghentian traffic IPv6

Fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dari Persyaratan Khusus Layanan. Fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Aturan penerusan merutekan traffic berdasarkan alamat IP, port, dan protokol ke konfigurasi load balancing yang terdiri dari proxy target dan layanan backend.

Spesifikasi alamat IP. Setiap aturan penerusan merujuk ke satu alamat IP yang dapat Anda gunakan di data DNS untuk aplikasi Anda. Anda dapat mencadangkan alamat IP statis yang dapat Anda gunakan atau mengizinkan Cloud Load Balancing menetapkannya untuk Anda. Sebaiknya Anda mencadangkan alamat IP statis. Jika tidak, Anda harus memperbarui data DNS dengan alamat IP sementara yang baru ditetapkan setiap kali Anda menghapus aturan penerusan dan membuat aturan baru.

Spesifikasi port. Aturan penerusan eksternal yang digunakan dalam definisi load balancer ini dapat mereferensikan tepat satu port dari 1-65535. Jika ingin mendukung beberapa port berturut-turut, Anda harus mengonfigurasi beberapa aturan penerusan. Beberapa aturan penerusan dapat dikonfigurasi dengan alamat IP virtual yang sama dan port yang berbeda; oleh karena itu, Anda dapat mem-proxy beberapa aplikasi dengan port kustom terpisah ke alamat IP virtual proxy TCP yang sama. Untuk mengetahui detail selengkapnya, lihat Spesifikasi port untuk aturan penerusan.

Untuk mendukung beberapa port berturut-turut, Anda harus mengonfigurasi beberapa aturan penerusan. Beberapa aturan penerusan dapat dikonfigurasi dengan alamat IP virtual yang sama dan port yang berbeda. Oleh karena itu, Anda dapat mem-proxy beberapa aplikasi dengan port kustom terpisah ke alamat IP virtual proxy TCP yang sama.

Tabel berikut menunjukkan persyaratan aturan penerusan untuk Load Balancer Jaringan proxy eksternal.

Mode load balancer	Network Service Tier	Aturan penerusan, alamat IP, dan skema load balancing	Pemilihan rute dari internet ke frontend load balancer
Load Balancer Jaringan proxy klasik	Paket Premium	Aturan penerusan eksternal global Alamat IP eksternal global Skema load balancing: EXTERNAL	Permintaan dirutekan ke GFE yang paling dekat dengan klien di internet.
	Paket Standar	Aturan penerusan eksternal regional Alamat IP eksternal regional Skema load balancing: EXTERNAL	Permintaan dirutekan ke GFE di region load balancer.
Load Balancer Jaringan proxy eksternal global	Paket Premium	Aturan penerusan eksternal global Alamat IP eksternal global Skema load balancing: EXTERNAL_MANAGED	Permintaan dirutekan ke GFE yang paling dekat dengan klien di internet.
Load Balancer Jaringan proxy eksternal regional	Paket Premium dan Standar	Aturan penerusan eksternal regional Alamat IP eksternal regional Skema load balancing: EXTERNAL_MANAGED	Permintaan dirutekan ke proxy Envoy di region yang sama dengan load balancer.

Aturan penerusan dan jaringan VPC

Bagian ini menjelaskan cara aturan penerusan yang digunakan oleh Load Balancer Aplikasi eksternal dikaitkan dengan jaringan VPC.

Mode load balancer	Pengaitan jaringan VPC
Load Balancer Jaringan proxy eksternal global Load Balancer Jaringan proxy klasik	Tidak ada jaringan VPC terkait. Aturan penerusan selalu menggunakan alamat IP yang berada di luar jaringan VPC. Oleh karena itu, aturan penerusan tidak memiliki jaringan VPC terkait.
Load Balancer Jaringan proxy eksternal regional	Jaringan VPC aturan penerusan adalah jaringan tempat subnet khusus proxy dibuat. Anda menentukan jaringan saat membuat aturan penerusan. Bergantung pada apakah Anda menggunakan alamat IPv4 atau rentang alamat IPv6, selalu ada jaringan VPC eksplisit atau implisit yang terkait dengan aturan penerusan. Alamat IPv4 eksternal regional selalu ada di luar jaringan VPC. Namun, saat membuat aturan penerusan, Anda harus menentukan jaringan VPC tempat subnet khusus proxy telah dibuat. Oleh karena itu, aturan penerusan memiliki pengaitan jaringan yang eksplisit. Rentang alamat IPv6 eksternal regional selalu ada di dalam jaringan VPC. Saat membuat aturan penerusan, Anda harus menentukan subnet tempat rentang alamat IP diambil. Subnet ini harus berada di region dan jaringan VPC yang sama dengan tempat subnet khusus proxy dibuat. Dengan demikian, ada pengaitan jaringan tersirat. Persyaratan jaringan dan subnet. Untuk traffic IPv6, jaringan dan subnet Anda harus memenuhi persyaratan konfigurasi berikut: Jaringan VPC: Anda harus menggunakan jaringan VPC mode kustom yang dikonfigurasi dengan flag --enable-ula-internal-ipv6. Subnet aturan penerusan: subnet ini harus berupa subnet stack ganda (IPv4_IPv6) atau IPV6_ONLY dengan ipv6-access-type ditetapkan ke EXTERNAL. Opsi alokasi alamat IPv6. Aturan penerusan harus merujuk ke rentang alamat IPv6 /96 dari rentang alamat IPv6 eksternal /64 subnet. Anda dapat menetapkan rentang alamat IPv6 /96 ini menggunakan salah satu metode berikut: Menentukan alamat IPv6 eksternal yang dicadangkan. Menentukan alamat IPv6 sementara kustom. Membiarkan Google Cloud menetapkan alamat IPv6 ephemeral secara otomatis. Batasan. Untuk menentukan alamat IPv6 sementara kustom, Anda harus menggunakan Google Cloud CLI atau API. Konsol Google Cloud tidak mendukung penentuan alamat IPv6 sementara kustom untuk aturan penerusan.

Proxy target

Load Balancer Jaringan proxy eksternal menghentikan koneksi dari klien dan membuat koneksi baru ke backend. Proxy target merutekan koneksi baru ini ke layanan backend.

Bergantung pada jenis traffic yang perlu ditangani aplikasi, Anda dapat mengonfigurasi Load Balancer Jaringan proxy eksternal dengan proxy TCP target atau proxy SSL target.

• Proxy TCP target: Konfigurasikan load balancer dengan proxy TCP target jika Anda memperkirakan traffic TCP.
• Proxy SSL target: Konfigurasikan load balancer dengan proxy SSL target jika Anda memperkirakan traffic klien terenkripsi. Jenis load balancer ini hanya ditujukan untuk traffic non-HTTP(S). Untuk traffic HTTP(S), sebaiknya gunakan Load Balancer Aplikasi eksternal.

Secara default, proxy target tidak mempertahankan informasi alamat IP dan port klien asli. Anda dapat mempertahankan informasi ini dengan mengaktifkan protokol PROXY di proxy target.

Tabel berikut menunjukkan persyaratan proxy target untuk Load Balancer Jaringan proxy eksternal.

Mode load balancer	Network Service Tier	Proxy target	Referensi
Load Balancer Jaringan proxy klasik	Paket Premium	targetTcpProxies atau targetSslProxies	Proxy target mereferensikan satu layanan backend.
	Paket Standar	targetTcpProxies atau targetSslProxies
Load Balancer Jaringan proxy eksternal global	Paket Premium	targetTcpProxies atau targetSslProxies	Proxy target mereferensikan satu layanan backend.
Load Balancer Jaringan proxy eksternal regional	Paket Premium dan Standar	regionTargetTcpProxies	Proxy target mereferensikan satu layanan backend atau satu atau beberapa rute TLS.

Sertifikat SSL

Sertifikat SSL hanya diperlukan jika Anda men-deploy Load Balancer Jaringan proxy eksternal global dan Load Balancer Jaringan proxy klasik dengan proxy SSL target.

Load Balancer Jaringan proxy eksternal yang menggunakan proxy SSL target memerlukan kunci pribadi dan sertifikat SSL sebagai bagian dari konfigurasi load balancer.

• Google Cloud menyediakan dua metode konfigurasi untuk menetapkan kunci pribadi dan sertifikat SSL ke proxy SSL target: sertifikat SSL Compute Engine dan Certificate Manager. Untuk deskripsi setiap konfigurasi, lihat Metode konfigurasi sertifikat di ringkasan sertifikat SSL.

• Google Cloud menyediakan dua jenis sertifikat: Dikelola sendiri dan Dikelola Google. Untuk deskripsi setiap jenis, lihat Jenis sertifikat dalam ringkasan sertifikat SSL.

Rute TLS

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Resource rute TLS memungkinkan Anda menentukan cara traffic dirutekan ke layanan backend berdasarkan nama host SNI.

Jika proxy TCP target load balancer tidak direferensikan oleh rute TLS, hanya satu layanan backend default yang digunakan, dan nilai nama host SNI yang dikirim oleh klien atau ketiadaannya tidak relevan.

Rute TLS hanya tersedia untuk Load Balancer Jaringan proxy eksternal regional. Sertifikat ini tidak didukung untuk Load Balancer Jaringan proxy klasik dan Load Balancer Jaringan proxy eksternal global.

Anda dapat melampirkan konfigurasi rute TLS ke proxy target load balancer menggunakan perintah gcloud network-services tls-routes.

Tabel berikut menunjukkan API rute TLS yang diperlukan oleh Load Balancer Jaringan proxy eksternal:

Mode load balancer	Rute TLS	Referensi
Load Balancer Jaringan proxy eksternal regional	Regional tlsRoutes	Setiap rute TLS dapat merujuk ke satu atau beberapa layanan backend.

Layanan backend

Layanan backend mengarahkan traffic masuk ke satu atau beberapa backend yang terpasang. Setiap backend terdiri dari grup instance atau grup endpoint jaringan dan informasi tentang kapasitas penyaluran backend. Kapasitas penayangan backend dapat didasarkan pada CPU atau permintaan per detik (RPS).

Setiap load balancer memiliki setidaknya satu resource layanan backend. Jika Anda menggunakan rute TLS (Pratinjau) untuk mengonfigurasi perutean, Anda dapat mengonfigurasi beberapa layanan backend untuk load balancer. Tanpa rute TLS, Anda hanya dibatasi pada satu layanan backend per load balancer.

Layanan backend menentukan health check yang akan dilakukan untuk backend yang tersedia.

Perubahan yang dilakukan pada layanan backend tidak berjalan seketika. Diperlukan waktu beberapa menit agar perubahan diterapkan ke GFE. Untuk memastikan gangguan minimal pada pengguna, Anda dapat mengaktifkan pengosongan koneksi pada layanan backend. Gangguan tersebut dapat terjadi saat backend dihentikan, dihapus secara manual, atau dihapus oleh autoscaler. Untuk mempelajari lebih lanjut cara menggunakan pengosongan koneksi untuk meminimalkan gangguan layanan, lihat Mengaktifkan pengosongan koneksi.

Untuk mengetahui informasi selengkapnya tentang resource layanan backend, lihat Ringkasan layanan backend.

Tabel berikut menentukan berbagai backend yang didukung di layanan backend Load Balancer Jaringan proxy eksternal.

Mode load balancer	Backend yang didukung di layanan backend
	Grup instance	NEG Zona	NEG internet	NEG Serverless	NEG Hybrid	NEG Private Service Connect	GKE
Load Balancer Jaringan proxy klasik		Menggunakan NEG zona mandiri
Load Balancer Jaringan proxy eksternal global	^*	Endpoint jenis GCE_VM_IP_PORT ^*
Load Balancer Jaringan proxy eksternal regional		Endpoint jenis GCE_VM_IP_PORT	Khusus NEG regional			Menambahkan NEG Private Service Connect

^* Load Balancer Jaringan proxy eksternal global mendukung grup instance IPv4 dan IPv6 (dual stack) serta backend NEG zona dengan endpoint GCE_VM_IP_PORT.

Backend dan jaringan VPC

Untuk backend Load Balancer Jaringan proxy eksternal global dan Load Balancer Jaringan proxy klasik, semua backend instance dari backend grup instance dan semua endpoint backend dari backend NEG harus berada dalam project yang sama. Namun, backend grup instance atau NEG dapat menggunakan jaringan VPC yang berbeda dalam project tersebut. Jaringan VPC yang berbeda tidak perlu terhubung menggunakan Peering Jaringan VPC karena GFE berkomunikasi langsung dengan backend di jaringan VPC masing-masing.

Untuk backend Load Balancer Jaringan proxy eksternal regional, hal berikut berlaku:

• Untuk grup instance, NEG zona, dan NEG konektivitas hybrid, semua backend harus berada di project dan region yang sama dengan layanan backend. Namun, load balancer dapat mereferensikan backend yang menggunakan jaringan VPC berbeda dalam project yang sama dengan layanan backend. Konektivitas antara jaringan VPC load balancer dan jaringan VPC backend dapat dikonfigurasi menggunakan Peering Jaringan VPC, tunnel Cloud VPN, lampiran VLAN Cloud Interconnect, atau framework Network Connectivity Center.

  Definisi jaringan backend

  • Untuk NEG zona dan NEG hybrid, Anda secara eksplisit menentukan jaringan VPC saat membuat NEG.
  • Untuk grup instance terkelola, jaringan VPC ditentukan dalam template instance.
  • Untuk grup instance tidak terkelola, jaringan VPC grup instance ditetapkan agar cocok dengan jaringan VPC antarmuka nic0 untuk VM pertama yang ditambahkan ke grup instance.

  Persyaratan jaringan backend

  Jaringan backend Anda harus memenuhi salah satu persyaratan jaringan berikut:

  • Jaringan VPC backend harus sama persis dengan jaringan VPC aturan penerusan.

  • Jaringan VPC backend harus terhubung ke jaringan VPC aturan penerusan menggunakan Peering Jaringan VPC. Anda harus mengonfigurasi pertukaran rute subnet untuk memungkinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh backend instance atau endpoint.

  Persyaratan subnet IPv6 backend

  Pratinjau

  Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

  Versi IP yang digunakan untuk koneksi frontend tidak bergantung pada koneksi backend. Karena subnet khusus proxy adalah dual-stack (IPV4_IPV6), subnet khusus proxy dapat berkomunikasi dengan backend menggunakan IPv4 atau IPv6.

  Jika backend instance Anda menangani traffic IPv6, subnet backend dapat dikonfigurasi dengan jenis stack IPV4_ONLY atau IPV4_IPV6 (dual-stack). Jika jenis stack subnet backend menyertakan IPv6, Anda harus secara eksplisit menetapkan ipv6-access-type subnet ke EXTERNAL.

• Jaringan VPC backend dan jaringan VPC aturan penerusan harus berupa spoke VPC yang terpasang ke hub NCC yang sama. Filter impor dan ekspor harus mengizinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh instance atau endpoint backend.

• Untuk semua jenis backend lainnya, semua backend harus berada di jaringan VPC dan region yang sama.

Backend dan antarmuka jaringan

Jika Anda menggunakan backend grup instance, paket akan selalu dikirim ke nic0. Jika Anda ingin mengirim paket ke antarmuka non-nic0 (vNIC atau Dynamic Network Interface), gunakan backend NEG.

Jika Anda menggunakan backend NEG zona, paket akan dikirim ke antarmuka jaringan apa pun yang diwakili oleh endpoint di NEG. Endpoint NEG harus berada dalam jaringan VPC yang sama dengan jaringan VPC NEG yang ditentukan secara eksplisit.

Protokol untuk berkomunikasi dengan backend

Saat mengonfigurasi layanan backend untuk Load Balancer Jaringan proxy eksternal, Anda menetapkan protokol yang digunakan layanan backend untuk berkomunikasi dengan backend.

• Untuk Load Balancer Jaringan proxy klasik, Anda dapat memilih TCP atau SSL.
• Untuk Load Balancer Jaringan proxy eksternal global, Anda dapat memilih TCP atau SSL.
• Untuk Load Balancer Jaringan proxy eksternal regional, Anda dapat menggunakan TCP.

Load balancer hanya menggunakan protokol yang Anda tentukan, dan tidak mencoba menegosiasikan koneksi dengan protokol lain.

Aturan firewall

Aturan firewall berikut diperlukan:

• Untuk Load Balancer Jaringan proxy klasik, aturan firewall allow masuk untuk mengizinkan traffic dari GFE menjangkau backend Anda.

• Untuk Load Balancer Jaringan proxy eksternal global, aturan firewall allow masuk untuk mengizinkan traffic dari GFE menjangkau backend Anda.

• Untuk Load Balancer Jaringan proxy eksternal regional, aturan firewall ingress untuk mengizinkan traffic dari subnet khusus proxy untuk menjangkau backend Anda.

• Aturan firewall allow ingress untuk mengizinkan traffic dari rentang pemeriksaan health check menjangkau backend Anda. Untuk mengetahui informasi selengkapnya tentang pemeriksaan health check dan alasan perlunya mengizinkan traffic dari pemeriksaan tersebut, lihat Memeriksa rentang IP dan aturan firewall.

Aturan firewall diterapkan di tingkat instance VM, bukan di tingkat proxy GFE. Anda tidak dapat menggunakan aturan firewall untuk mencegah traffic mencapai load balancer.

Port untuk aturan firewall ini harus dikonfigurasi sebagai berikut:

• Izinkan traffic ke port tujuan untuk setiap health check layanan backend.
• Untuk backend grup instance: tentukan port yang akan dikonfigurasi oleh pemetaan antara port bernama layanan backend dan nomor port yang terkait dengan port bernama tersebut di setiap grup instance. Nomor port dapat bervariasi antara grup instance yang ditetapkan ke layanan backend yang sama.
• Untuk backend NEG zona GCE_VM_IP_PORT NEG: izinkan traffic ke nomor port endpoint.

Tabel berikut merangkum rentang alamat IP sumber yang diperlukan untuk aturan firewall.

Mode load balancer	Rentang sumber health check	Meminta rentang sumber
Load Balancer Jaringan proxy eksternal global	35.191.0.0/16 130.211.0.0/22 Untuk traffic IPv6 ke backend: 2600:2d00:1:b029::/64	Sumber traffic GFE bergantung pada jenis backend: Grup instance dan NEG zona (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Untuk traffic IPv6 ke backend: 2600:2d00:1:1::/64
Load Balancer Jaringan proxy klasik	35.191.0.0/16 130.211.0.0/22	Rentang ini berlaku untuk pemeriksaan health check dan permintaan dari GFE.
Load Balancer Jaringan proxy eksternal regional ^*, †	35.191.0.0/16 130.211.0.0/22 Untuk traffic IPv6 ke backend: 2600:2d00:1:b029::/64	Rentang ini berlaku untuk pemeriksaan health check.

^* Mengizinkan traffic dari rentang pemeriksaan health check Google tidak diperlukan untuk NEG hybrid. Namun, jika Anda menggunakan kombinasi NEG hybrid dan zona dalam satu layanan backend, Anda harus mengizinkan traffic dari rentang pemeriksaan health check Google untuk NEG zona.

^† Untuk NEG internet regional, health check bersifat opsional. Traffic dari load balancer yang menggunakan NEG internet regional berasal dari subnet khusus proxy, lalu diterjemahkan NAT (menggunakan Cloud NAT) ke alamat IP NAT yang dialokasikan secara manual atau alokasi otomatis. Traffic ini mencakup pemeriksaan health check dan permintaan pengguna dari load balancer ke backend. Untuk mengetahui detailnya, lihat NEG regional: Menggunakan gateway Cloud NAT.

Penting: Pastikan Anda mengizinkan paket dari rentang health check lengkap. Jika aturan firewall Anda hanya mengizinkan paket dari sebagian rentang, Anda mungkin akan melihat kegagalan health check karena load balancer tidak dapat berkomunikasi dengan backend Anda. Hal ini menyebabkan waktu tunggu koneksi habis.

Alamat IP sumber

Alamat IP sumber untuk paket, seperti yang dilihat oleh backend, bukan alamat IP eksternalGoogle Cloud load balancer. Dengan kata lain, ada dua koneksi TCP.

Untuk Load Balancer Jaringan proxy klasik dan Load Balancer Jaringan proxy eksternal global:

• Koneksi 1, dari klien asli ke load balancer (GFE):

  • Alamat IP sumber: klien asli (atau alamat IP eksternal jika klien berada di belakang gateway NAT atau proxy penerusan).
  • Alamat IP tujuan: alamat IP load balancer Anda.

• Koneksi 2, dari load balancer (GFE) ke VM atau endpoint backend:

  • Alamat IP sumber: alamat IP di salah satu rentang yang ditentukan dalam Aturan firewall.

  • Alamat IP tujuan: alamat IP internal VM backend atau container di jaringan VPC.

Untuk Load Balancer Jaringan proxy eksternal regional:

• Koneksi 1, dari klien asli ke load balancer (subnet khusus proxy):

  • Alamat IP sumber: klien asli (atau alamat IP eksternal jika klien berada di belakang gateway NAT atau proxy penerusan).
  • Alamat IP tujuan: alamat IP load balancer Anda.

• Koneksi 2, dari load balancer (subnet khusus proxy) ke VM atau endpoint backend:

  • Alamat IP sumber: alamat IP di subnet khusus proxy yang digunakan bersama di antara semua load balancer berbasis Envoy yang di-deploy di region dan jaringan yang sama dengan load balancer.

  • Alamat IP tujuan: alamat IP internal VM backend atau container di jaringan VPC.

Port yang terbuka

Load Balancer Jaringan proxy eksternal adalah load balancer reverse proxy. Load balancer menghentikan koneksi masuk, lalu membuka koneksi baru dari load balancer ke backend. Load balancer ini diimplementasikan menggunakan proxy Google Front End (GFE) di seluruh dunia.

GFE memiliki beberapa port terbuka untuk mendukung layanan Google lainnya yang berjalan pada arsitektur yang sama. Saat menjalankan pemindaian port, Anda mungkin melihat port terbuka lainnya untuk layanan Google lain yang berjalan di GFE.

Menjalankan pemindaian port pada alamat IP load balancer berbasis GFE tidak berguna dari perspektif audit karena alasan berikut:

• Pemindaian port (misalnya, dengan nmap) umumnya tidak mengharapkan paket respons atau paket TCP RST saat melakukan pemeriksaan TCP SYN. GFE mengirimkan paket SYN-ACK sebagai respons terhadap pemeriksaan SYN hanya untuk port yang telah Anda konfigurasi aturan penerusannya. GFE hanya mengirim paket ke backend Anda sebagai respons terhadap paket yang dikirim ke alamat IP load balancer Anda dan port tujuan yang dikonfigurasi pada aturan penerusannya. Paket yang dikirim ke alamat IP atau port yang berbeda tidak akan dikirim ke backend Anda.

• Paket yang dikirim ke alamat IP load balancer Anda dapat dijawab oleh GFE mana pun dalam fleet Google. Namun, pemindaian kombinasi alamat IP load balancer dan port tujuan hanya akan menginterogasi satu GFE per koneksi TCP. Alamat IP load balancer Anda tidak ditetapkan ke satu perangkat atau sistem. Oleh karena itu, memindai alamat IP load balancer berbasis GFE tidak akan memindai semua GFE di fleet Google.

Dengan mempertimbangkan hal tersebut, berikut adalah beberapa cara yang lebih efektif untuk mengaudit keamanan instance backend Anda:

• Auditor keamanan harus memeriksa konfigurasi aturan penerusan untuk konfigurasi load balancer. Aturan penerusan menentukan port tujuan tempat load balancer Anda menerima paket dan meneruskannya ke backend. Untuk load balancer berbasis GFE, setiap aturan penerusan eksternal hanya dapat mereferensikan satu port TCP tujuan.

• Auditor keamanan harus memeriksa konfigurasi aturan firewall yang berlaku untuk VM backend. Aturan firewall yang Anda tetapkan memblokir traffic dari GFE ke VM backend, tetapi tidak memblokir traffic masuk ke GFE. Untuk mengetahui praktik terbaik, lihat bagian aturan firewall.

Arsitektur VPC Bersama

Load Balancer Jaringan proxy eksternal regional dan Load Balancer Jaringan proxy klasik mendukung deployment yang menggunakan jaringan VPC Bersama. VPC Bersama memungkinkan Anda mempertahankan pemisahan tanggung jawab yang jelas antara administrator jaringan dan developer layanan. Tim pengembangan Anda dapat berfokus pada pembuatan layanan di project layanan, dan tim infrastruktur jaringan dapat menyediakan dan mengelola load balancing. Jika Anda belum memahami VPC Bersama, baca dokumentasi ringkasan VPC Bersama.

Alamat IP	Aturan penerusan	Proxy target	Komponen backend
Alamat IP eksternal harus ditentukan dalam project yang sama dengan load balancer.	Aturan penerusan eksternal harus ditentukan dalam project yang sama dengan instance backend (project layanan).	Proxy TCPatau SSL target harus ditentukan dalam project yang sama dengan backend instance.	Untuk Load Balancer Jaringan proxy klasik, layanan backend global harus ditentukan dalam project yang sama dengan backend instance. Instance ini harus berada dalam grup instance yang dilampirkan ke layanan backend sebagai backend. Health check yang terkait dengan layanan backend harus ditentukan dalam project yang sama dengan layanan backend. Untuk Load Balancer Jaringan proxy eksternal regional, VM backend biasanya berada di project layanan. Layanan backend regional dan health check harus ditentukan dalam project layanan tersebut.

Catatan: Load Balancer Jaringan proxy eksternal global tidak mendukung deployment yang menggunakan jaringan VPC Bersama.

Distribusi traffic

Saat menambahkan grup backend instance atau NEG ke layanan backend, Anda menentukan mode load balancing, yang menentukan metode yang mengukur beban backend dan kapasitas target.

Untuk Load Balancer Jaringan proxy eksternal, mode penyeimbangan dapat berupa CONNECTION atau UTILIZATION:

• Jika mode load balancing adalah CONNECTION, beban akan disebarkan berdasarkan jumlah total koneksi yang dapat ditangani backend.
• Jika mode load balancing adalah UTILIZATION, beban akan disebarkan berdasarkan pemakaian instance dalam grup instance. Mode penyeimbangan ini hanya berlaku untuk backend grup instance VM.

Distribusi traffic di seluruh backend ditentukan oleh mode load balancing dari load balancer.

Load Balancer Jaringan proxy klasik

Untuk Load Balancer Jaringan proxy klasik, mode load balancing digunakan untuk memilih backend yang paling menguntungkan (grup instance atau NEG). Traffic kemudian didistribusikan secara round robin di antara instance atau endpoint dalam backend.

Cara koneksi didistribusikan

Load Balancer Jaringan proxy klasik dapat dikonfigurasi sebagai layanan load balancing global dengan Paket Premium, dan sebagai layanan regional di Paket Standar.

Mode penyeimbangan dan pilihan target menentukan kepenuhan backend dari perspektif setiap NEG GCE_VM_IP_PORT zona, grup instance zona, atau zona grup instance regional. Traffic kemudian didistribusikan dalam zona menggunakan hashing yang konsisten.

Untuk Paket Premium

• Anda hanya dapat memiliki satu layanan backend, dan layanan backend tersebut dapat memiliki backend di beberapa region. Untuk load balancing global, Anda men-deploy backend di beberapa region, dan load balancer akan otomatis mengarahkan traffic ke region terdekat dengan pengguna. Jika suatu region sudah mencapai kapasitasnya, load balancer akan otomatis mengarahkan koneksi baru ke region lain yang memiliki kapasitas tersedia. Koneksi pengguna yang ada tetap berada di region saat ini.

• Google memberitahukan alamat IP load balancer Anda dari semua titik kehadiran, di seluruh dunia. Setiap alamat IP load balancer adalah anycast global.

• Jika Anda mengonfigurasi layanan backend dengan backend di beberapa region, Google Front End (GFE) akan mencoba mengarahkan permintaan ke grup instance backend atau NEG yang responsif di region terdekat dengan pengguna.

Untuk Paket Standar

• Google memberitahukan alamat IP load balancer Anda dari titik kehadiran yang terkait dengan region aturan penerusan. Load balancer menggunakan alamat IP eksternal regional.

• Anda hanya dapat mengonfigurasi backend di region yang sama dengan aturan penerusan. Load balancer hanya mengarahkan permintaan ke backend yang responsif di satu region tersebut.

Load Balancer Jaringan proxy eksternal global

Untuk Load Balancer Jaringan proxy eksternal global, distribusi traffic didasarkan pada mode load balancing dan kebijakan lokalitas load balancing.

Mode load balancing menentukan bobot dan fraksi traffic yang akan dikirim ke setiap grup (grup instance atau NEG). Kebijakan lokalitas load balancing (LocalityLbPolicy) menentukan cara backend dalam grup di-load balance.

Saat menerima traffic, layanan backend akan mengarahkan traffic ke backend (grup instance atau NEG) terlebih dahulu sesuai dengan mode load balancing backend. Setelah backend dipilih, traffic akan didistribusikan di antara instance atau endpoint dalam grup backend tersebut sesuai dengan kebijakan lokalitas load balancing.

Untuk informasi selengkapnya, lihat referensi berikut:

• Balancing mode.
• Kebijakan lokalitas load balancing (dokumentasi API layanan backend global).

Cara koneksi didistribusikan

Load Balancer Jaringan proxy eksternal global dapat dikonfigurasi sebagai layanan load balancing global dengan Paket Premium

Mode penyeimbangan dan pilihan target menentukan kepenuhan backend dari perspektif setiap NEG GCE_VM_IP_PORT zona, atau grup instance zona. Traffic kemudian didistribusikan dalam zona menggunakan hashing yang konsisten.

• Anda hanya dapat memiliki satu layanan backend, dan layanan backend tersebut dapat memiliki backend di beberapa region. Untuk load balancing global, Anda men-deploy backend di beberapa region, dan load balancer akan otomatis mengarahkan traffic ke region terdekat dengan pengguna. Jika suatu region sudah mencapai kapasitasnya, load balancer akan otomatis mengarahkan koneksi baru ke region lain yang memiliki kapasitas tersedia. Koneksi pengguna yang ada tetap berada di region saat ini.

• Google memberitahukan alamat IP load balancer Anda dari semua titik kehadiran, di seluruh dunia. Setiap alamat IP load balancer adalah anycast global.

• Jika Anda mengonfigurasi layanan backend dengan backend di beberapa region, Google Front End (GFE) akan mencoba mengarahkan permintaan ke grup instance backend atau NEG yang responsif di region terdekat dengan pengguna.

Load Balancer Jaringan proxy eksternal regional

Untuk Load Balancer Jaringan proxy eksternal regional, distribusi traffic didasarkan pada mode load balancing dan kebijakan lokalitas load balancing.

Mode penyeimbangan menentukan bobot dan fraksi traffic yang harus dikirim ke setiap backend (grup instance atau NEG). Kebijakan lokalitas load balancing (LocalityLbPolicy) menentukan cara backend dalam grup di-load balance.

Saat menerima traffic, layanan backend akan mengarahkan traffic ke backend (grup instance atau NEG) terlebih dahulu sesuai dengan mode balancing-nya. Setelah backend dipilih, traffic akan didistribusikan di antara instance atau endpoint dalam grup backend tersebut sesuai dengan kebijakan lokalitas load balancing.

Untuk informasi selengkapnya, lihat referensi berikut:

• Mode load balancing
• Kebijakan lokalitas load balancing (dokumentasi API layanan backend regional)

Pemilihan rute berbasis SNI dengan rute TLS

Pratinjau

Produk atau fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum di Persyaratan Khusus Layanan. Produk dan fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Catatan: Pemilihan rute berbasis SNI hanya didukung untuk Load Balancer Jaringan proxy eksternal regional.

Pemilihan rute berbasis SNI memungkinkan Load Balancer Jaringan proxy TCP Anda merutekan traffic ke layanan backend tertentu berdasarkan nama host Server Name Indication (SNI) yang diberikan selama TLS handshake. SNI adalah ekstensi TLS yang memungkinkan klien menentukan nama domain yang ingin dijangkau sebelum tunnel terenkripsi dibuat. Nama host SNI dikirimkan dalam format yang tidak dienkripsi dalam pesan ClientHello sehingga load balancer dapat memeriksa nilai ini dan merutekan traffic ke layanan backend yang sesuai.

Anda dapat menggunakan resource konfigurasi rute TLS untuk memetakan nama host SNI tertentu ke layanan backend. Saat pemilihan rute berbasis SNI dikonfigurasi, load balancer mengaktifkan TLS passthrough, yang meneruskan byte stream terenkripsi langsung ke backend tanpa didekripsi oleh load balancer.

Fitur ini memungkinkan beberapa kasus penggunaan utama seperti:

• Gunakan satu alamat IP anycast global dan port untuk menyajikan beberapa aplikasi, sehingga mengurangi konsumsi alamat IPv4.
• Mendukung deployment terenkripsi end-to-end, yang memungkinkan sertifikat tetap berada di backend, sehingga memastikan traffic tidak pernah tidak terenkripsi saat dalam pengiriman.
• Memungkinkan administrator platform mengelola infrastruktur inti, sementara pemilik layanan mengelola rute dan backend spesifik mereka secara independen.
• Memungkinkan pemilihan rute ke shard tertentu untuk aplikasi non-HTTP stateful (seperti MongoDB) berdasarkan SNI yang disediakan oleh klien.

Cara traffic didistribusikan saat rute TLS digunakan

Jika pemilihan rute berbasis SNI dikonfigurasi, traffic akan dirutekan ke layanan backend sebagai berikut:

1. Load balancer memproses IP dan port yang ditentukan dalam aturan penerusan.
2. Saat klien memulai koneksi TLS, load balancer akan menangkap pesan ClientHello dan mengekstrak nama host SNI.

3. SNI yang diekstrak dibandingkan dengan nama host yang ditentukan dalam rute TLS yang dikonfigurasi. Load balancer menggunakan logika berikut untuk menentukan layanan backend mana yang harus menerima traffic:

   1. Jika klien tidak menggunakan protokol TLS, load balancer akan menutup koneksi.
   2. Jika klien tidak mengirim nama host SNI dalam pesan ClientHello-nya, load balancer akan menutup koneksi.
   3. Jika klien mengirim nama host SNI yang bukan nama DNS yang valid, load balancer akan menutup koneksi.
   4. Jika klien mengirim nama host SNI yang tidak cocok dengan nama host SNI mana pun yang terkait dengan rute TLS, load balancer akan menutup koneksi.

   5. Dalam semua situasi lainnya: Load balancer memilih layanan backend menggunakan proses pencocokan berikut:

      Pencocokan dilakukan berdasarkan akhiran terpanjang (terpanjang dalam hal jumlah subdomain). Untuk mengilustrasikan metode pencocokan, pertimbangkan rute TLS yang SNI-nya adalah *.foo.com, rute TLS lain yang SNI-nya adalah *.bar.foo.com, dan rute TLS ketiga yang SNI-nya adalah baz.bar.foo.com.

      • Jika nama host SNI klien adalah baz.bar.foo.com, load balancer akan memilih layanan backend yang direferensikan oleh rute TLS yang SNI-nya adalah baz.bar.foo.com.
      • Jika nama host SNI klien adalah qux.bar.foo.com, load balancer akan memilih layanan backend yang direferensikan oleh rute TLS yang SNI-nya adalah *.bar.foo.com.
      • Jika nama host SNI klien adalah qux.qux.foo.com, load balancer akan memilih layanan backend yang direferensikan oleh rute TLS yang SNI-nya adalah *.foo.com.

   Setelah kecocokan ditemukan, byte stream terenkripsi akan di-proxy-kan langsung ke layanan backend yang ditetapkan tanpa menghentikan koneksi TLS (untuk passthrough TLS).

Batasan

Batasan berikut berlaku saat Anda menggunakan rute TLS untuk mengonfigurasi pemilihan rute berbasis SNI:

• Proxy TCP target dapat merujuk ke satu layanan backend atau satu atau beberapa rute TLS. Anda tidak dapat mengonfigurasi keduanya.

• Load Balancer Jaringan Proxy tidak dapat mendeteksi penggabungan koneksi HTTP, yang dapat menyebabkan permintaan HTTP salah rute.

  Secara default, browser sudah menggabungkan koneksi HTTP. Misalnya, saat browser membuka koneksi ke www.example.com dan server menampilkan sertifikat untuk *.example.com selama TLS handshake, browser akan menggunakan kembali koneksi ini untuk semua permintaan ke *.example.com, selama nama host di-resolve ke alamat IP yang sama. Hal ini sesuai dengan RFC 7540.

  Dengan pemilihan rute berbasis SNI, setelah koneksi dibuat, koneksi tersebut akan terikat secara permanen ke backend tujuannya. Pertimbangkan deployment tempat *.example.com disajikan oleh satu backend HTTPS dengan sertifikat TLS *.example.com, dan my.example.com disajikan oleh backend HTTPS lain. Jika koneksi ke *.example.com dibuat terlebih dahulu, permintaan HTTP berikutnya ke my.example.com akan digabungkan ke koneksi yang sama, menggunakan backend HTTPS *.example.com.

Afinitas sesi

Afinitas sesi memungkinkan Anda mengonfigurasi layanan backend load balancer untuk mengirim semua permintaan dari klien yang sama ke backend yang sama, selama backend tersebut responsif dan memiliki kapasitas.

Load Balancer Jaringan proxy eksternal menawarkan jenis afinitas sesi berikut:

• Tidak ada

  Setelan afinitas sesi NONE tidak berarti tidak ada afinitas sesi. Artinya, tidak ada opsi afinitas sesi yang dikonfigurasi secara eksplisit.

  Hashing selalu dilakukan untuk memilih backend. Setelan afinitas sesi NONE berarti load balancer menggunakan hash 5 tuple untuk memilih backend. Hash 5 tuple terdiri dari alamat IP sumber, port sumber, protokol, alamat IP tujuan, dan port tujuan.

  Afinitas sesi NONE adalah nilai default.

• Afinitas IP klien

  Afinitas sesi IP klien (CLIENT_IP) adalah hash 2 tuple yang dibuat dari alamat IP sumber dan tujuan paket. Afinitas IP klien meneruskan semua permintaan dari alamat IP klien yang sama ke backend yang sama, asalkan backend tersebut memiliki kapasitas dan tetap responsif.

  Saat Anda menggunakan afinitas IP klien, perhatikan hal-hal berikut:

  • Alamat IP tujuan paket hanya sama dengan alamat IP aturan penerusan load balancer jika paket dikirim langsung ke load balancer.
  • Alamat IP sumber paket mungkin tidak cocok dengan alamat IP yang terkait dengan klien asli jika paket diproses oleh sistem NAT atau proxy perantara sebelum dikirim ke load balancer Google Cloud . Dalam situasi ketika banyak klien menggunakan alamat IP sumber efektif yang sama, beberapa VM backend mungkin menerima lebih banyak koneksi atau permintaan daripada yang lain.

Perhatikan hal-hal berikut saat mengonfigurasi afinitas sesi:

• Jangan mengandalkan afinitas sesi untuk tujuan autentikasi atau keamanan. Afinitas sesi dapat terganggu setiap kali jumlah backend yang aktif dan responsif berubah. Untuk mengetahui detail selengkapnya, lihat Kehilangan afinitas sesi.

• Nilai default flag --session-affinity dan --subsetting-policy adalah NONE, dan hanya satu flag yang dapat ditetapkan ke nilai yang berbeda pada satu waktu.

Kehilangan afinitas sesi

Semua opsi afinitas sesi memerlukan hal berikut:

• Instance atau endpoint backend yang dipilih harus tetap dikonfigurasi sebagai backend. Afinitas sesi dapat terputus jika salah satu peristiwa berikut terjadi:
  • Anda menghapus instance yang dipilih dari grup instance-nya.
  • Penskalaan otomatis atau autohealing grup instance terkelola akan menghapus instance yang dipilih dari grup instance terkelola.
  • Anda menghapus endpoint yang dipilih dari NEG-nya.
  • Anda menghapus grup instance atau NEG yang berisi instance atau endpoint yang dipilih dari layanan backend.
• Instance atau endpoint backend yang dipilih harus tetap responsif. Afinitas sesi dapat terputus jika instance atau endpoint yang dipilih gagal dalam health check.
• Untuk Load Balancer Jaringan proxy eksternal global dan Load Balancer Jaringan proxy klasik, afinitas sesi dapat terganggu jika Google Front End (GFE) lapisan pertama yang berbeda digunakan untuk permintaan atau koneksi berikutnya setelah perubahan jalur perutean. GFE lapisan pertama yang berbeda mungkin dipilih jika jalur perutean dari klien di internet ke Google berubah di antara permintaan atau koneksi.

Semua opsi afinitas sesi memiliki persyaratan tambahan berikut:

• Grup instance atau NEG yang berisi instance atau endpoint yang dipilih tidak boleh penuh seperti yang ditentukan oleh kapasitas targetnya. (Untuk grup instance terkelola regional, komponen zona dari grup instance yang berisi instance yang dipilih tidak boleh penuh.) Afinitas sesi dapat terputus jika grup instance atau NEG penuh, sedangkan grup instance atau NEG lainnya tidak. Karena kepenuhan dapat berubah dengan cara yang tidak dapat diprediksi saat menggunakan mode balancing UTILIZATION, Anda harus menggunakan mode balancing RATE atau CONNECTION untuk meminimalkan situasi saat afinitas sesi dapat terganggu.

• Jumlah total endpoint atau backend instance yang dikonfigurasi harus tetap konstan. Jika setidaknya salah satu peristiwa berikut terjadi, jumlah backend instance atau endpoint yang dikonfigurasi akan berubah, dan afinitas sesi dapat terputus:

  • Menambahkan instance atau endpoint baru:

    • Anda menambahkan instance ke grup instance yang ada di layanan backend.
    • Penskalaan otomatis grup instance terkelola menambahkan instance ke grup instance terkelola di layanan backend.
    • Anda menambahkan endpoint ke NEG yang ada di layanan backend.
    • Anda menambahkan grup instance atau NEG yang tidak kosong ke layanan backend.

  • Menghapus instance atau endpoint apa pun, bukan hanya instance atau endpoint yang dipilih:

    • Anda menghapus instance apa pun dari backend grup instance.
    • Penskalaan otomatis atau autohealing grup instance terkelola akan menghapus instance apa pun dari backend grup instance terkelola.
    • Anda menghapus endpoint apa pun dari backend NEG.
    • Anda menghapus grup instance backend atau NEG yang ada dan tidak kosong dari layanan backend.

• Jumlah total endpoint atau backend instance yang responsif harus tetap konstan. Jika setidaknya salah satu peristiwa berikut terjadi, jumlah backend instance atau endpoint yang responsif akan berubah, dan afinitas sesi dapat terganggu:

  • Setiap instance atau endpoint lulus health check, bertransisi dari tidak responsif menjadi responsif.
  • Setiap instance atau endpoint gagal dalam health check, bertransisi dari responsif menjadi tidak responsif atau waktu tunggu habis.

Failover

Failover untuk Load Balancer Jaringan proxy eksternal berfungsi sebagai berikut:

• Jika backend tidak responsif, traffic akan otomatis dialihkan ke backend yang responsif dalam region yang sama.

• Jika semua backend dalam suatu region tidak responsif, traffic akan didistribusikan ke backend yang responsif di region lain (khusus mode global dan klasik).

• Jika semua backend tidak responsif, load balancer akan menghapus traffic.

Load balancing untuk aplikasi GKE

Jika Anda membangun aplikasi di Google Kubernetes Engine, Anda dapat menggunakan NEG mandiri untuk menyeimbangkan beban traffic langsung ke container. Dengan NEG mandiri, Anda bertanggung jawab untuk membuat objek Service yang membuat NEG, lalu mengaitkan NEG dengan layanan backend agar load balancer dapat terhubung ke Pod.

Untuk dokumentasi terkait, lihat Load balancing berbasis container melalui NEG zona mandiri.

Batasan

• Anda tidak dapat membuat Load Balancer Jaringan proxy eksternal regional di Paket Premium menggunakan konsolGoogle Cloud . Selain itu, hanya region yang mendukung Paket Standar yang tersedia untuk load balancer ini di konsolGoogle Cloud . Gunakan gcloud CLI atau API.

• Google Cloud tidak memberikan jaminan apa pun terkait masa aktif koneksi TCP saat Anda menggunakan Load Balancer Jaringan proxy eksternal. Klien harus tahan terhadap koneksi yang terputus, baik karena masalah internet yang lebih luas maupun karena mulai ulang proxy yang mengelola koneksi secara terjadwal. Jika proxy dimulai ulang, kolom proxyStatus status di log Load Balancer Jaringan Proxy akan menampilkan pesan status terkait.

• Batasan berikut hanya berlaku untuk Load Balancer Jaringan proxy klasik dan Load Balancer Jaringan proxy eksternal global yang di-deploy dengan proxy target SSL:

  • Load Balancer Jaringan proxy klasik dan Load Balancer Jaringan proxy eksternal global tidak mendukung autentikasi berbasis sertifikat klien, yang juga dikenal sebagai autentikasi TLS bersama.

  • Load Balancer Jaringan proxy klasik dan Load Balancer Jaringan proxy eksternal global hanya mendukung karakter huruf kecil di domain dalam atribut nama umum (CN) atau atribut nama alternatif subjek (SAN) sertifikat. Sertifikat dengan karakter huruf besar di domain hanya ditampilkan jika ditetapkan sebagai sertifikat utama di proxy target.

Langkah berikutnya

• Siapkan Load Balancer Jaringan proxy klasik (proxy TCP).
• Menyiapkan Load Balancer Jaringan proxy klasik (proxy SSL).
• Siapkan Load Balancer Jaringan proxy eksternal global (proxy TCP).
• Menyiapkan Load Balancer Jaringan proxy eksternal global (proxy SSL).

• Menyiapkan Load Balancer Jaringan proxy eksternal regional (proxy TCP).
• Logging dan pemantauan Load Balancer Jaringan Proxy.

• Menggunakan kebijakan SSL.

• Lokasi GFE.