Ringkasan Load Balancer Aplikasi Internal

Dokumen ini memperkenalkan konsep yang perlu Anda pahami untuk mengonfigurasi Load Balancer Aplikasi internal.

Load Balancer Aplikasi internal Google Cloud adalah load balancer lapisan 7 berbasis proxy yang memungkinkan Anda menjalankan dan menskalakan layanan di balik satu alamat IP internal. Application Load Balancer internal mendistribusikan traffic HTTP dan HTTPS ke backend yang dihosting di berbagai platform Google Cloud seperti Compute Engine, Google Kubernetes Engine (GKE), dan Cloud Run. Untuk mengetahui detailnya, lihat Kasus penggunaan.

Mode operasi

Anda dapat mengonfigurasi Load Balancer Aplikasi internal dalam mode berikut:

• Load Balancer Aplikasi internal lintas region. Ini adalah load balancer multi-region yang diterapkan sebagai layanan terkelola berdasarkan proxy Envoy open source. Mode lintas region memungkinkan Anda melakukan load balancing traffic ke layanan backend yang didistribusikan secara global, termasuk pengelolaan traffic yang memastikan traffic diarahkan ke backend terdekat. Load balancer ini juga memungkinkan ketersediaan tinggi. Menempatkan backend di beberapa region membantu menghindari kegagalan di satu region. Jika backend satu region tidak berfungsi, traffic dapat gagal dan beralih ke region lain.

• Load Balancer Aplikasi internal regional. Ini adalah load balancer regional yang diterapkan sebagai layanan terkelola berdasarkan proxy Envoy open source. Mode regional memastikan bahwa semua klien dan backend berasal dari region yang ditentukan, yang membantu saat Anda memerlukan kepatuhan regional. Load balancer ini diaktifkan dengan kemampuan kontrol traffic yang beragam berdasarkan parameter HTTP(S). Setelah dikonfigurasi, load balancer akan otomatis mengalokasikan proxy Envoy untuk memenuhi kebutuhan traffic Anda.

  Tabel berikut menjelaskan perbedaan penting antara mode regional dan lintas wilayah:

  Fitur	Load Balancer Aplikasi internal lintas region	Load Balancer Aplikasi internal regional
  Alamat IP virtual (VIP) load balancer.	Dialokasikan dari subnet di region Google Cloud tertentu. Alamat VIP dari beberapa region dapat menggunakan layanan backend global yang sama. Anda dapat mengonfigurasi load balancing global berbasis DNS menggunakan kebijakan perutean DNS untuk merutekan permintaan klien ke alamat VIP terdekat.	Dialokasikan dari subnet di region Google Cloud tertentu.
  Akses klien	Selalu dapat diakses secara global. Klien dari region Google Cloud mana pun di VPC dapat mengirim traffic ke load balancer.	Tidak dapat diakses secara global secara default. Secara opsional, Anda dapat mengaktifkan akses global.
  Backend load balanced	Backend global. Load balancer dapat mengirim traffic ke backend di region mana pun.	Backend regional. Load balancer hanya dapat mengirim traffic ke backend yang berada di region yang sama dengan proxy load balancer.
  Ketersediaan tinggi dan failover	Failover otomatis ke backend yang sehat di region yang sama atau berbeda.	Failover otomatis ke backend yang responsif di region yang sama.

Mengidentifikasi mode

Cloud Console

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

   Buka Load balancing

2. Di tab Load Balancer, Anda dapat melihat jenis, protokol, dan region load balancer. Jika region kosong, berarti load balancer berada dalam mode lintas region. Tabel berikut meringkas cara mengidentifikasi mode load balancer.

   Mode load balancer	Jenis load balancer	Jenis akses	Wilayah
   Load Balancer Aplikasi internal regional	Aplikasi	Internal	Menentukan region
   Load Balancer Aplikasi internal lintas region	Aplikasi	Internal

gcloud

1. Untuk menentukan mode load balancer, jalankan perintah berikut:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

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

   Mode load balancer	Skema load balancing	Aturan penerusan
   Load Balancer Aplikasi internal lintas region	INTERNAL_MANAGED	Global
   Load Balancer Aplikasi internal regional	INTERNAL_MANAGED	Regional

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

Arsitektur dan resource

Diagram berikut menunjukkan resource Google Cloud yang diperlukan untuk Load Balancer Aplikasi internal:

Lintas region

Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi internal lintas region di Paket Premium dalam jaringan VPC yang sama. Setiap aturan penerusan global menggunakan alamat IP regional yang digunakan klien untuk terhubung.

Komponen Load Balancer Aplikasi internal lintas region (klik untuk memperbesar).

Regional

Diagram ini menunjukkan komponen deployment Load Balancer Aplikasi internal regional di Paket Premium.

Komponen Load Balancer Aplikasi internal regional (klik untuk memperbesar).

Resource berikut diperlukan untuk deployment Load Balancer Aplikasi internal:

Subnet khusus proxy

Pada diagram sebelumnya, subnet khusus proxy menyediakan kumpulan alamat IP yang digunakan Google untuk menjalankan proxy Envoy atas nama Anda. Anda harus membuat subnet khusus proxy di setiap region jaringan VPC tempat Anda menggunakan Load Balancer Aplikasi internal.

Tabel berikut menjelaskan perbedaan antara subnet khusus proxy dalam mode regional dan lintas-wilayah:

Mode load balancer	Nilai flag --purpose subnet khusus proxy
Load Balancer Aplikasi internal lintas region	GLOBAL_MANAGED_PROXY Load balancer regional dan lintas region tidak dapat menggunakan subnet yang sama Load balancer lintas region berbasis Envoy harus memiliki subnet khusus proxy di setiap region tempat load balancer dikonfigurasi. Proxy load balancer lintas region di region dan jaringan yang sama berbagi subnet khusus proxy yang sama.
Load Balancer Aplikasi internal regional	REGIONAL_MANAGED_PROXY Load balancer regional dan lintas region tidak dapat menggunakan subnet yang sama Semua load balancer berbasis Envoy regional di region dan jaringan VPC memiliki subnet khusus proxy yang sama

Lebih lanjut:

• Subnet khusus proxy hanya digunakan untuk proxy Envoy, bukan backend Anda.
• VM backend atau endpoint dari semua Load Balancer Aplikasi internal di region dan jaringan VPC menerima koneksi dari subnet khusus proxy.
• Alamat IP virtual Load Balancer Aplikasi internal tidak berada di subnet khusus proxy. Alamat IP load balancer ditentukan oleh aturan penerusan internal yang dikelola, yang dijelaskan di bawah.

Aturan penerusan dan alamat IP

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 mereferensikan satu alamat IP regional yang dapat Anda gunakan dalam data DNS untuk aplikasi Anda. Anda dapat mencadangkan alamat IP statis yang dapat digunakan atau membiarkan Cloud Load Balancing menetapkannya untuk Anda. Sebaiknya Anda mencadangkan alamat IP statis. Jika tidak, Anda harus memperbarui data DNS dengan alamat IP efemeral yang baru ditetapkan setiap kali Anda menghapus aturan penerusan dan membuat yang baru.

Klien menggunakan alamat IP dan port untuk terhubung ke proxy Envoy load balancer. Alamat IP aturan penerusan adalah alamat IP load balancer (terkadang disebut alamat IP virtual atau VIP). Klien yang terhubung ke load balancer harus menggunakan HTTP versi 1.1 atau yang lebih baru. Untuk mengetahui daftar lengkap protokol yang didukung, lihat Fitur load balancer.

Alamat IP internal yang terkait dengan aturan penerusan dapat berasal dari subnet di jaringan dan region yang sama dengan backend Anda.

Spesifikasi port. Setiap aturan penerusan untuk Application Load Balancer dapat mereferensikan satu port dari 1-65535. Untuk mendukung beberapa port, Anda harus mengonfigurasi beberapa aturan penerusan. Anda dapat mengonfigurasi beberapa aturan penerusan untuk menggunakan alamat IP internal (VIP) yang sama dan untuk mereferensikan proxy HTTP(S) target yang sama selama keseluruhan kombinasi alamat IP, port, dan protokol unik untuk setiap aturan penerusan. Dengan cara ini, Anda dapat menggunakan satu load balancer dengan peta URL bersama sebagai proxy untuk beberapa aplikasi.

Jenis aturan penerusan, alamat IP, dan skema load balancing yang digunakan oleh Load Balancer Aplikasi internal bergantung pada mode load balancer.

Mode load balancer	Aturan penerusan, alamat IP, dan subnet khusus proxy --purpose	Pemuatan dari klien ke frontend load balancer
Load Balancer Aplikasi internal lintas region	Aturan penerusan global Alamat IP regional Skema load balancing: INTERNAL_MANAGED Subnet khusus proxy --purpose: GLOBAL_MANAGED_PROXY Alamat IP --purpose: SHARED_LOADBALANCER_VIP	Akses global diaktifkan secara default untuk mengizinkan klien dari region mana pun di VPC mengakses load balancer Anda. Backend dapat berada di beberapa region.
Load Balancer Aplikasi internal regional	Aturan penerusan regional Alamat IP regional Skema load balancing: INTERNAL_MANAGED Subnet khusus proxy --purpose: REGIONAL_MANAGED_PROXY Alamat IP --purpose: SHARED_LOADBALANCER_VIP	Anda dapat mengaktifkan akses global untuk mengizinkan klien dari region mana pun di VPC untuk mengakses load balancer Anda. Backend juga harus berada 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	Penautan jaringan VPC
Load Balancer Aplikasi internal lintas region Load Balancer Aplikasi internal regional	Alamat IPv4 internal regional selalu ada di dalam jaringan VPC. Saat membuat aturan penerusan, Anda harus menentukan subnet tempat alamat IP internal diambil. Subnet ini harus berada di region dan jaringan VPC yang sama dengan subnet khusus proxy yang telah dibuat. Dengan demikian, ada pengaitan jaringan yang tersirat.

Proxy target

Proxy HTTP(S) target menghentikan koneksi HTTP(S) dari klien. Proxy HTTP(S) akan melihat peta URL untuk menentukan cara merutekan traffic ke backend. Proxy HTTPS target menggunakan sertifikat SSL untuk mengautentikasi dirinya ke klien.

Load balancer mempertahankan header Host dari permintaan klien asli. Load balancer juga menambahkan dua alamat IP ke header X-Forwarded-For:

• Alamat IP klien yang terhubung ke load balancer
• Alamat IP aturan penerusan load balancer

Jika tidak ada header X-Forwarded-For pada permintaan masuk, dua alamat IP ini adalah seluruh nilai header. Jika permintaan memiliki header X-Forwarded-For, informasi lain, seperti alamat IP yang dicatat oleh proxy dalam perjalanan ke load balancer, akan dipertahankan sebelum dua alamat IP. Load balancer tidak memverifikasi alamat IP apa pun yang mendahului dua alamat IP terakhir di header ini.

Jika Anda menjalankan proxy sebagai server backend, proxy ini biasanya menambahkan informasi lebih lanjut ke header X-Forwarded-For, dan software Anda mungkin perlu mempertimbangkannya. Permintaan yang di-proxy dari load balancer berasal dari alamat IP di subnet khusus proxy, dan proxy Anda di instance backend dapat mencatat alamat ini serta alamat IP instance backend itu sendiri.

Bergantung pada jenis traffic yang perlu ditangani aplikasi, Anda dapat mengonfigurasi load balancer dengan proxy HTTP target atau proxy HTTPS target.

Tabel berikut menunjukkan API proxy target yang diperlukan oleh Load Balancer Aplikasi internal:

Mode load balancer	Proxy target
Load Balancer Aplikasi internal lintas region	targetHttpProxies Global targetHttpsProxies Global
Load Balancer Aplikasi internal regional	regionTargetHttpProxies regionTargetHttpsProxies

Sertifikat SSL

Load Balancer Aplikasi Internal yang menggunakan proxy HTTPS target memerlukan kunci pribadi dan sertifikat SSL sebagai bagian dari konfigurasi load balancer.

Tabel berikut menentukan jenis sertifikat SSL yang diperlukan oleh Application Load Balancer internal dalam setiap mode:

Mode load balancer	Jenis sertifikat SSL
Load Balancer Aplikasi internal regional	Sertifikat SSL regional Compute Engine Sertifikat yang dikelola sendiri secara regional dan sertifikat yang dikelola Google di Certificate Manager. Jenis sertifikat yang dikelola Google berikut didukung dengan Pengelola Sertifikat: Sertifikat regional yang dikelola Google dengan otorisasi DNS per project. Untuk mengetahui informasi selengkapnya, lihat Men-deploy sertifikat yang dikelola Google secara regional. Sertifikat regional yang dikelola Google dengan Certificate Authority Service pribadi. Untuk mengetahui informasi selengkapnya, lihat Men-deploy sertifikat yang dikelola Google regional dengan Layanan CA. Sertifikat yang dikelola Google dengan otorisasi load balancer tidak didukung.
Load Balancer Aplikasi internal lintas region	Sertifikat yang dikelola sendiri dan sertifikat yang dikelola Google di Certificate Manager. Jenis sertifikat yang dikelola Google berikut didukung dengan Certificate Manager: Otorisasi DNS dengan DNS Publik. Untuk mengetahui informasi selengkapnya, lihat Membuat sertifikat yang dikelola Google dengan otorisasi DNS. Private Certificate Authority Service. Untuk mengetahui informasi selengkapnya, lihat Membuat sertifikat yang dikelola Google yang diterbitkan oleh instance Layanan CA Anda. Sertifikat yang dikelola Google dengan otorisasi load balancer tidak didukung. Sertifikat SSL Compute Engine tidak didukung.

Peta URL

Proxy HTTP(S) target menggunakan peta URL untuk membuat penentuan pemilihan rute berdasarkan atribut HTTP (seperti jalur permintaan, cookie, atau header). Berdasarkan keputusan pemilihan rute, proxy meneruskan permintaan klien ke layanan backend tertentu. Peta URL dapat menentukan tindakan tambahan yang akan dilakukan seperti menulis ulang header, mengirim pengalihan ke klien, dan mengonfigurasi kebijakan waktu tunggu (di antara lainnya).

Tabel berikut menentukan jenis peta URL yang diperlukan oleh Load Balancer Aplikasi internal dalam setiap mode:

Mode load balancer	Jenis peta URL
Load Balancer Aplikasi internal lintas region	Peta URL global
Load Balancer Aplikasi internal regional	Peta URL wilayah

Layanan backend

Layanan backend memberikan informasi konfigurasi ke load balancer agar dapat mengarahkan permintaan ke backend-nya—misalnya, grup instance Compute Engine atau grup endpoint jaringan (NEG). Untuk mengetahui informasi selengkapnya tentang layanan backend, lihat Ringkasan layanan backend.

Cakupan layanan backend

Tabel berikut menunjukkan resource dan cakupan layanan backend yang digunakan oleh Load Balancer Aplikasi internal:

Mode load balancer	Resource layanan backend
Load Balancer Aplikasi internal lintas region	backendServices (global)
Load Balancer Aplikasi internal regional	regionBackendServices (regional)

Protokol ke backend

Layanan backend untuk Load Balancer Aplikasi harus menggunakan salah satu protokol berikut untuk mengirim permintaan ke backend:

• HTTP, yang menggunakan HTTP/1.1 dan tidak menggunakan TLS
• HTTPS, yang menggunakan HTTP/1.1 dan TLS
• HTTP/2, yang menggunakan HTTP/2 dan TLS (HTTP/2 tanpa enkripsi tidak didukung.)

Load balancer hanya menggunakan protokol layanan backend yang Anda tentukan untuk berkomunikasi dengan backend-nya. Load balancer tidak kembali ke protokol yang berbeda jika tidak dapat berkomunikasi dengan backend menggunakan protokol layanan backend yang ditentukan.

Protokol layanan backend tidak perlu cocok dengan protokol yang digunakan oleh klien untuk berkomunikasi dengan load balancer. Misalnya, klien dapat mengirim permintaan ke load balancer menggunakan HTTP/2, tetapi load balancer dapat berkomunikasi dengan backend menggunakan HTTP/1.1 (HTTP atau HTTPS).

Backend

Tabel berikut menentukan fitur backend yang didukung oleh Load Balancer Aplikasi internal dalam setiap mode.

Mode load balancer	Backend yang didukung di layanan backend^*						Mendukung bucket backend	Mendukung Google Cloud Armor	Mendukung Cloud CDN	Mendukung IAP	Mendukung Ekstensi Layanan
	Grup instance^†	NEG Zona^‡	NEG Internet	NEG Serverless	NEG Hybrid	NEG Private Service Connect
Load Balancer Aplikasi internal lintas region				Cloud Run
Load Balancer Aplikasi internal regional				Cloud Run

^* Backend di layanan backend harus memiliki jenis yang sama: semua grup instance atau semua jenis NEG yang sama. Pengecualian untuk aturan ini adalah bahwa NEG zona GCE_VM_IP_PORT dan NEG hybrid dapat digunakan di layanan backend yang sama untuk mendukung arsitektur hybrid.

^† Kombinasi grup instance terkelola zona, terkelola zona, dan terkelola regional didukung di layanan backend yang sama. Saat menggunakan penskalaan otomatis untuk grup instance terkelola yang merupakan backend untuk dua layanan backend atau lebih, konfigurasikan kebijakan penskalaan otomatis grup instance untuk menggunakan beberapa sinyal.

^‡ NEG zona harus menggunakan endpoint GCE_VM_IP_PORT.

Backend dan jaringan VPC

Catatan: Bagian ini menjelaskan pengaitan jaringan VPC untuk deployment tempat layanan backend dan backend load balancer berada dalam project yang sama dengan aturan penerusan. Jika Anda juga ingin layanan backend berada di project yang berbeda dengan aturan penerusan, Anda perlu mengonfigurasi load balancer di lingkungan VPC Bersama dengan referensi layanan lintas project.

Batasan lokasi backend bergantung pada jenis backend.

• Untuk grup instance, NEG zona, dan NEG konektivitas campuran, semua backend harus berada di project dan region yang sama dengan layanan backend. Namun, load balancer dapat mereferensikan backend yang menggunakan jaringan VPC yang berbeda di project yang sama dengan layanan backend (kemampuan ini dalam Pratinjau). 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 zonal dan NEG campuran, Anda menentukan jaringan VPC secara eksplisit 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 mengizinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh instance backend atau endpoint.

• Jaringan VPC backend dan jaringan VPC aturan penerusan harus berupa jari-jari VPC di hub Network Connectivity Center 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 dan region VPC yang sama.

Backend dan antarmuka jaringan

Jika Anda menggunakan backend grup instance, paket akan selalu dikirim ke nic0. Jika Anda ingin mengirim paket ke NIC yang berbeda, gunakan backend NEG.

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

Sub-setelan 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.

Subsetelan backend adalah fitur opsional yang didukung oleh Load Balancer Aplikasi internal regional yang meningkatkan performa dan skalabilitas dengan menetapkan subset backend ke setiap instance proxy.

Secara default, subset backend dinonaktifkan. Untuk mengetahui informasi tentang cara mengaktifkan fitur ini, lihat Subsetelan backend untuk Load Balancer Aplikasi internal.

Health check

Setiap layanan backend menentukan health check yang secara berkala memantau kesiapan backend untuk menerima koneksi dari load balancer. Hal ini mengurangi risiko bahwa permintaan mungkin dikirim ke backend yang tidak dapat melayani permintaan. Health check tidak memeriksa apakah aplikasi itu sendiri berfungsi.

Agar pemeriksaan health check berhasil, Anda harus membuat aturan firewall izinkan Ingress yang memungkinkan pemeriksaan health check menjangkau instance backend Anda. Biasanya, pemeriksaan health check berasal dari mekanisme pemeriksaan kondisi terpusat Google. Namun, untuk NEG campuran, health check berasal dari subnet khusus proxy. Untuk mengetahui detailnya, lihat health check Envoy terdistribusi di ringkasan NEG Hybrid.

Protokol health check

Meskipun tidak diperlukan dan tidak selalu memungkinkan, praktik terbaiknya adalah menggunakan health check yang protokolnya cocok dengan protokol layanan backend. Misalnya, health check HTTP/2 menguji konektivitas HTTP/2 ke backend dengan paling akurat. Sebaliknya, Load Balancer Aplikasi internal yang menggunakan backend NEG campuran tidak mendukung health check gRPC. Untuk daftar protokol health check yang didukung, lihat Fitur load balancing.

Tabel berikut menentukan cakupan health check yang didukung oleh Load Balancer Aplikasi internal:

Mode load balancer	Jenis health check
Load Balancer Aplikasi internal lintas region	Global
Load Balancer Aplikasi internal regional	Regional

Untuk mengetahui informasi selengkapnya tentang pemeriksaan kesehatan, lihat artikel berikut:

• Ringkasan health check
• Membuat health check

Aturan firewall

Load Balancer Aplikasi internal memerlukan aturan firewall berikut:

• Aturan izin masuk yang mengizinkan traffic dari rentang health check pusat Google.
  • 35.191.0.0/16
  • 130.211.0.0/22

  Untuk traffic IPv6 ke backend:

  • 2600:2d00:1:b029::/64
• Aturan izin masuk yang mengizinkan traffic dari subnet khusus proxy.

Ada pengecualian tertentu untuk persyaratan aturan firewall untuk rentang ini:

• Mencantumkan rentang pemeriksaan health check Google dalam daftar yang diizinkan tidak diperlukan untuk NEG hibrida. Namun, jika Anda menggunakan kombinasi NEG campuran dan zonal dalam satu layanan backend, Anda harus mengizinkan rentang probe pemeriksaan kesehatan Google untuk NEG zonal.
• 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 (dengan menggunakan Cloud NAT) ke alamat IP NAT yang dialokasikan secara manual atau otomatis. Traffic ini mencakup pemeriksaan health check dan permintaan pengguna dari load balancer ke backend. Untuk mengetahui detailnya, lihat NEG regional: Menggunakan Cloud NAT untuk keluar.

Akses klien

Klien dapat berada di jaringan yang sama atau di jaringan VPC yang terhubung menggunakan Peering Jaringan VPC.

Untuk Load Balancer Aplikasi internal lintas-region, akses global diaktifkan secara default. Klien dari region mana pun di VPC dapat mengakses load balancer Anda.

Untuk Load Balancer Aplikasi internal regional, klien harus berada di region yang sama dengan load balancer secara default. Anda dapat mengaktifkan akses global agar klien dari region mana pun di VPC dapat mengakses load balancer Anda.

Tabel berikut merangkum akses klien untuk Load Balancer Aplikasi internal regional:

Akses global dinonaktifkan	Akses global diaktifkan
Klien harus berada di region yang sama dengan load balancer. VM juga harus berada di jaringan VPC yang sama dengan load balancer atau di jaringan VPC yang terhubung ke jaringan VPC load balancer menggunakan Peering Jaringan VPC.	Klien dapat berada di wilayah mana pun. VM tersebut tetap harus berada di jaringan VPC yang sama dengan load balancer atau di jaringan VPC yang terhubung ke jaringan VPC load balancer menggunakan Peering Jaringan VPC.
Klien lokal dapat mengakses load balancer melalui tunnel Cloud VPN atau lampiran VLAN. Tunnel atau lampiran ini harus berada di region yang sama dengan load balancer.	Klien lokal dapat mengakses load balancer melalui tunnel Cloud VPN atau lampiran VLAN. Tunnel atau lampiran ini dapat berada di region mana pun.

Dukungan GKE

GKE menggunakan Load Balancer Aplikasi internal dengan cara berikut:

• Gateway Internal yang dibuat menggunakan pengontrol Gateway GKE dapat menggunakan mode Load Balancer Aplikasi Internal apa pun. Anda mengontrol mode load balancer dengan memilih GatewayClass. Pengontrol GKE Gateway selalu menggunakan backend NEG zonal GCE_VM_IP_PORT.

• Ingress internal yang dibuat menggunakan pengontrol Ingress GKE selalu merupakan Load Balancer Aplikasi internal Regional. Pengontrol GKE Ingress selalu menggunakan backend NEG zonal GCE_VM_IP_PORT.

• Anda dapat menggunakan NEG zonal GCE_VM_IP_PORT yang dibuat dan dikelola oleh Layanan GKE sebagai backend untuk Load Balancer Aplikasi atau Load Balancer Jaringan Proxy. Untuk mengetahui informasi selengkapnya, lihat Load balancing berbasis container melalui NEG zona mandiri.

Arsitektur VPC Bersama

Load Balancer Aplikasi internal mendukung jaringan yang menggunakan VPC Bersama. VPC Bersama memungkinkan organisasi menghubungkan resource dari beberapa project ke jaringan VPC umum sehingga resource dapat berkomunikasi satu sama lain secara aman dan efisien menggunakan IP internal dari jaringan tersebut. Jika Anda belum memahami VPC Bersama, baca dokumentasi ringkasan VPC Bersama.

Ada banyak cara untuk mengonfigurasi Load Balancer Aplikasi internal dalam jaringan VPC Bersama. Terlepas dari jenis deployment, semua komponen load balancer harus berada di organisasi yang sama.

Subnet dan alamat IP	Komponen frontend	Komponen backend
Buat jaringan dan subnet yang diperlukan (termasuk subnet khusus proxy), di project host VPC Bersama. Alamat IP internal load balancer dapat ditentukan dalam project host atau project layanan, tetapi harus menggunakan subnet dalam jaringan VPC Bersama yang diinginkan di project host. Alamat itu sendiri berasal dari rentang IP utama subnet yang dirujuk.	Alamat IP internal regional, aturan penerusan, proxy HTTP(S) target, dan peta URL terkait harus ditentukan dalam project yang sama. Project ini dapat berupa project host atau project layanan.	Anda dapat melakukan salah satu hal berikut: Buat layanan backend dan backend (grup instance, NEG tanpa server, atau jenis backend lain yang didukung) di project layanan yang sama sebagai komponen frontend. Buat layanan backend dan backend (grup instance, NEG tanpa server, atau jenis backend lain yang didukung) di sebanyak mungkin project layanan yang diperlukan. Satu peta URL dapat mereferensikan layanan backend di berbagai project. Jenis deployment ini dikenal sebagai referensi layanan lintas project. Setiap layanan backend harus ditentukan dalam project yang sama dengan backend yang dirujuknya. Health check yang terkait dengan layanan backend juga harus ditentukan dalam project yang sama dengan layanan backend.

Meskipun Anda dapat membuat semua komponen dan backend load balancing di project host VPC Bersama, jenis deployment ini tidak memisahkan tanggung jawab administrasi jaringan dan pengembangan layanan.

Semua komponen dan backend load balancer dalam project layanan

Diagram arsitektur berikut menunjukkan deployment VPC Bersama standar dengan semua komponen dan backend load balancer berada dalam project layanan. Jenis deployment ini didukung oleh semua Load Balancer Aplikasi.

Load balancer menggunakan alamat IP dan subnet dari project host. Klien dapat mengakses Load Balancer Aplikasi internal jika berada di jaringan dan region VPC Bersama yang sama dengan load balancer. Klien dapat berada di project host, atau di project layanan yang terpasang, atau jaringan terhubung apa pun.

Load Balancer Aplikasi Internal di jaringan VPC Bersama

Backend serverless di lingkungan VPC Bersama

Untuk Load Balancer Aplikasi internal yang menggunakan backend NEG serverless, layanan Cloud Run pendukung harus berada dalam project layanan yang sama dengan layanan backend dan NEG serverless. Komponen frontend load balancer (aturan penerusan, proxy target, peta URL) dapat dibuat di project host, project layanan yang sama dengan komponen backend, atau project layanan lainnya di lingkungan VPC Bersama yang sama.

Referensi layanan lintas project

Referensi layanan lintas project adalah model deployment dengan frontend dan peta URL load balancer berada dalam satu project, sedangkan layanan backend dan backend load balancer berada dalam project yang berbeda.

Referensi layanan lintas project memungkinkan organisasi mengonfigurasi satu load balancer pusat dan merutekan traffic ke ratusan layanan yang didistribusikan di beberapa project yang berbeda. Anda dapat mengelola semua aturan dan kebijakan pemilihan rute traffic secara terpusat di satu peta URL. Anda juga dapat mengaitkan load balancer dengan satu kumpulan nama host dan sertifikat SSL. Oleh karena itu, Anda dapat mengoptimalkan jumlah load balancer yang diperlukan untuk men-deploy aplikasi, serta menurunkan kemampuan pengelolaan, biaya operasional, dan persyaratan kuota.

Dengan memiliki project yang berbeda untuk setiap tim fungsional, Anda juga dapat mencapai pemisahan peran dalam organisasi. Pemilik layanan dapat berfokus pada pembuatan layanan dalam project layanan, sementara tim jaringan dapat menyediakan dan memelihara load balancer di project lain, dan keduanya dapat dihubungkan menggunakan referensi layanan lintas project.

Pemilik layanan dapat mempertahankan otonomi atas eksposur layanan mereka dan mengontrol pengguna mana yang dapat mengakses layanan mereka menggunakan load balancer. Hal ini dicapai dengan peran IAM khusus yang disebut peran Pengguna Layanan Load Balancer Compute (roles/compute.loadBalancerServiceUser).

Untuk Load Balancer Aplikasi internal, referensi layanan lintas project hanya didukung dalam lingkungan VPC Bersama.

Untuk mempelajari cara mengonfigurasi VPC Bersama untuk Load Balancer Aplikasi internal—dengan dan tanpa referensi layanan lintas project, lihat Menyiapkan Load Balancer Aplikasi internal dengan VPC Bersama.

Batasan umum terkait referensi layanan lintas project

• Anda tidak dapat mereferensikan layanan backend lintas project jika layanan backend memiliki backend NEG internet regional. Semua jenis backend lainnya didukung.
• Google Cloud tidak membedakan resource (misalnya, layanan backend) yang menggunakan nama yang sama di beberapa project. Oleh karena itu, saat menggunakan referensi layanan lintas project, sebaiknya Anda menggunakan nama layanan backend yang unik di seluruh project dalam organisasi Anda.

Contoh 1: Frontend dan backend load balancer di project layanan yang berbeda

Berikut adalah contoh deployment VPC Bersama dengan frontend dan peta URL load balancer yang dibuat di project layanan A dan peta URL mereferensikan layanan backend di project layanan B.

Dalam hal ini, Admin Jaringan atau Admin Load Balancer di project layanan A akan memerlukan akses ke layanan backend di project layanan B. Admin project layanan B memberikan peran IAM compute.loadBalancerServiceUser kepada Admin Load Balancer di project layanan A yang ingin mereferensikan layanan backend di project layanan B.

Frontend dan backend load balancer di project layanan yang berbeda

Contoh 2: Frontend load balancer di project host dan backend di project layanan

Berikut adalah contoh deployment VPC Bersama tempat frontend dan peta URL load balancer dibuat di project host dan layanan backend (dan backend) dibuat di project layanan.

Dalam hal ini, Admin Jaringan atau Admin Load Balancer di project host akan memerlukan akses ke layanan backend di project layanan. Admin project layanan memberikan peran IAM compute.loadBalancerServiceUser kepada Admin Load Balancer di project host A yang ingin mereferensikan layanan backend di project layanan.

Frontend load balancer dan peta URL di project host (klik untuk memperbesar).

Waktu tunggu dan percobaan ulang

Load Balancer Aplikasi internal mendukung jenis waktu tunggu berikut:

Jenis dan deskripsi waktu tunggu	Nilai default	Mendukung nilai kustom
		Lintas region	Regional
Waktu tunggu layanan backend Waktu tunggu permintaan dan respons. Merepresentasikan jumlah waktu maksimum yang diizinkan antara load balancer yang mengirim byte pertama permintaan ke backend dan backend yang menampilkan byte terakhir respons HTTP ke load balancer. Jika backend belum menampilkan seluruh respons HTTP ke load balancer dalam batas waktu ini, data respons yang tersisa akan dihapus.	Untuk NEG serverless di layanan backend: 60 menit Untuk semua jenis backend lainnya di layanan backend: 30 detik
Waktu tunggu keepalive HTTP klien Waktu maksimum koneksi TCP antara klien dan proxy Envoy terkelola load balancer dapat tidak aktif. (Koneksi TCP yang sama dapat digunakan untuk beberapa permintaan HTTP.)	10 menit (600 detik)
Waktu tunggu keepalive HTTP backend Jumlah waktu maksimum koneksi TCP antara proxy Envoy yang dikelola load balancer dan backend dapat tidak ada aktivitas. (Koneksi TCP yang sama mungkin digunakan untuk beberapa permintaan HTTP.)	10 menit (600 detik)

Waktu tunggu layanan backend

Waktu tunggu layanan backend yang dapat dikonfigurasi menunjukkan jumlah waktu maksimum load balancer menunggu backend Anda memproses permintaan HTTP dan menampilkan respons HTTP yang sesuai. Kecuali untuk NEG tanpa server, nilai default untuk waktu tunggu layanan backend adalah 30 detik.

Misalnya, jika Anda ingin mendownload file berukuran 500 MB, dan nilai waktu tunggu layanan backend adalah 90 detik, load balancer mengharapkan backend mengirimkan seluruh file berukuran 500 MB dalam waktu 90 detik. Anda dapat mengonfigurasi waktu tunggu layanan backend agar tidak cukup bagi backend untuk mengirim respons HTTP lengkap. Dalam situasi ini, jika load balancer setidaknya telah menerima header respons HTTP dari backend, load balancer akan menampilkan header respons lengkap dan sebanyak mungkin isi respons yang dapat diperoleh dalam waktu tunggu layanan backend.

Anda harus menetapkan waktu tunggu layanan backend ke jumlah waktu terlama yang diperlukan backend untuk memproses respons HTTP. Anda harus meningkatkan waktu tunggu layanan backend jika software yang berjalan di backend Anda memerlukan lebih banyak waktu untuk memproses permintaan HTTP dan menampilkan seluruh responsnya.

Waktu tunggu layanan backend menerima nilai antara 1 dan 2,147,483,647 detik; tetapi, nilai yang lebih besar bukanlah opsi konfigurasi yang praktis. Google Cloud juga tidak menjamin bahwa koneksi TCP yang mendasarinya dapat tetap terbuka selama keseluruhan nilai waktu tunggu layanan backend. Sistem klien harus menerapkan logika percobaan ulang, bukan mengandalkan koneksi TCP yang terbuka untuk jangka waktu yang lama.

Untuk koneksi websocket yang digunakan dengan Load Balancer Aplikasi internal, koneksi websocket aktif tidak mengikuti waktu tunggu layanan backend. Koneksi websocket yang tidak ada aktivitasnya akan ditutup setelah waktu tunggu layanan backend habis.

Google Cloud secara berkala memulai ulang atau mengubah jumlah tugas software Envoy yang ditayangkan. Makin lama nilai waktu tunggu layanan backend, makin besar kemungkinan tugas Envoy dimulai ulang atau penggantian akan menghentikan koneksi TCP.

Untuk mengonfigurasi waktu tunggu layanan backend, gunakan salah satu metode berikut:

Konsol

Ubah kolom Timeout pada layanan backend load balancer.

gcloud

Gunakan perintah gcloud compute backend-services update untuk mengubah parameter --timeout resource layanan backend.

API

Ubah parameter timeoutSec untuk resource regionBackendServices

Waktu tunggu keepalive HTTP klien habis

Waktu tunggu keepalive HTTP klien menunjukkan jumlah waktu maksimum yang dapat dihabiskan koneksi TCP dalam keadaan tidak ada aktivitas antara klien (downstream) dan proxy Envoy. Nilai waktu tunggu keepalive HTTP klien default adalah 600 detik. Anda dapat mengonfigurasi waktu tunggu dengan nilai antara 5 dan 600 detik.

Waktu tunggu keepalive HTTP juga disebut waktu tunggu tidak ada aktivitas TCP.

Waktu tunggu keepalive HTTP klien load balancer harus lebih besar dari waktu tunggu keepalive HTTP (TCP tidak ada aktivitas) yang digunakan oleh klien atau proxy downstream. Jika klien downstream memiliki waktu tunggu keepalive HTTP (TCP tidak ada aktivitas) yang lebih besar daripada waktu tunggu keepalive HTTP klien load balancer, kondisi perlombaan mungkin terjadi. Dari perspektif klien downstream, koneksi TCP yang sudah dibuat diizinkan untuk tidak ada aktivitas lebih lama dari yang diizinkan oleh load balancer. Artinya, klien downstream dapat mengirim paket setelah load balancer menganggap koneksi TCP ditutup. Jika hal itu terjadi, load balancer akan merespons dengan paket reset TCP (RST).

Waktu tunggu keepalive HTTP backend

Load Balancer Aplikasi internal adalah proxy yang menggunakan koneksi TCP pertama antara klien (downstream) dan proxy Envoy, serta koneksi TCP kedua antara proxy Envoy dan backend Anda.

Koneksi TCP sekunder load balancer mungkin tidak ditutup setelah setiap permintaan; koneksi tersebut dapat tetap terbuka untuk menangani beberapa permintaan dan respons HTTP. Waktu tunggu keepalive HTTP backend menentukan waktu tunggu tidak ada aktivitas TCP antara load balancer dan backend Anda. Waktu tunggu keepalive HTTP backend tidak berlaku untuk websocket.

Waktu tunggu keepalive backend ditetapkan pada 10 menit (600 detik) dan tidak dapat diubah. Waktu tunggu keepalive backend load balancer harus lebih singkat dari waktu tunggu keepalive yang digunakan oleh software yang berjalan di backend Anda. Hal ini menghindari kondisi race saat sistem operasi backend Anda dapat menutup koneksi TCP dengan reset TCP (RST). Karena waktu tunggu keepalive backend untuk load balancer tidak dapat dikonfigurasi, Anda harus mengonfigurasi software backend agar nilai waktu tunggu keepalive HTTP (TCP tidak ada aktivitas) lebih besar dari 600 detik.

Tabel berikut mencantumkan perubahan yang diperlukan untuk mengubah nilai waktu tunggu keepalive untuk software server web umum.

Software server web	Parameter	Setelan default	Setelan yang direkomendasikan
Apache	KeepAliveTimeout	KeepAliveTimeout 5	KeepAliveTimeout 620
nginx	keepalive_timeout	keepalive_timeout 75s;	keepalive_timeout 620s;

Upaya coba lagi

Untuk mengonfigurasi percobaan ulang, Anda dapat menggunakan kebijakan percobaan ulang di peta URL. Jumlah percobaan ulang default (numRetries) adalah 1. perTryTimeout maksimum yang dapat dikonfigurasi adalah 24 jam.

Tanpa kebijakan percobaan ulang, permintaan yang gagal dan tidak memiliki isi HTTP (misalnya, permintaan GET) yang menghasilkan respons HTTP 502, 503, atau 504 akan dicoba ulang sekali.

Permintaan POST HTTP tidak dicoba lagi.

Permintaan yang dicoba ulang hanya menghasilkan satu entri log untuk respons akhir.

Untuk mengetahui informasi selengkapnya, lihat Logging dan monitoring Load Balancer Aplikasi Internal.

Mengakses jaringan yang terhubung

Klien Anda dapat mengakses Load Balancer Aplikasi internal di jaringan VPC Anda dari jaringan yang terhubung menggunakan hal berikut:

• Peering Jaringan VPC
• Cloud VPN dan Cloud Interconnect

Untuk contoh mendetail, lihat Load Balancer Aplikasi Internal dan jaringan yang terhubung.

Failover

Jika backend menjadi tidak responsif, traffic akan otomatis dialihkan ke backend yang responsif.

Tabel berikut menjelaskan perilaku failover di setiap mode:

Mode load balancer	Perilaku failover	Perilaku saat semua backend tidak responsif
Load Balancer Aplikasi internal lintas region	Failover otomatis ke backend yang sehat di region yang sama atau region lain. Traffic didistribusikan di antara backend yang sehat yang mencakup beberapa region berdasarkan distribusi traffic yang dikonfigurasi.	Menampilkan HTTP 503
Load Balancer Aplikasi internal regional	Failover otomatis ke backend yang responsif di region yang sama. Proxy Envoy mengirim traffic ke backend yang responsif di region berdasarkan distribusi traffic yang dikonfigurasi.	Menampilkan HTTP 503

Ketersediaan tinggi dan failover lintas region

Untuk Load Balancer Aplikasi internal regional

Untuk mencapai ketersediaan tinggi, deploy beberapa Load Balancer Aplikasi internal regional individual di region yang paling mendukung traffic aplikasi Anda. Kemudian, Anda menggunakan kebijakan perutean geolokasi Cloud DNS untuk mendeteksi apakah load balancer merespons selama pemadaman layanan regional. Kebijakan geolokasi merutekan traffic ke region terdekat berikutnya yang tersedia berdasarkan asal permintaan klien. Health check tersedia secara default untuk Load Balancer Aplikasi internal.

Untuk Load Balancer Aplikasi internal lintas region

Anda dapat menyiapkan Load Balancer Aplikasi internal lintas region di beberapa region untuk mendapatkan manfaat berikut:

1. Jika Load Balancer Aplikasi internal lintas region di suatu region gagal, kebijakan pemilihan rute DNS akan merutekan traffic ke Load Balancer Aplikasi internal lintas region di region lain.

   Contoh deployment ketersediaan tinggi menunjukkan hal berikut:

   • Load Balancer Aplikasi internal lintas region dengan alamat IP virtual (VIP) frontend di region RegionA dan RegionB di jaringan VPC Anda. Klien Anda berada di region RegionA.
   • Anda dapat membuat load balancer dapat diakses dengan menggunakan VIP frontend dari dua region, dan menggunakan kebijakan perutean DNS untuk menampilkan VIP yang optimal kepada klien Anda. Gunakan kebijakan perutean geolokasi jika Anda ingin klien menggunakan VIP yang paling dekat secara geografis.
   • Kebijakan perutean DNS dapat mendeteksi apakah VIP tidak merespons selama pemadaman layanan regional, dan menampilkan VIP berikutnya yang paling optimal kepada klien Anda, sehingga memastikan aplikasi Anda tetap aktif bahkan selama pemadaman layanan regional.

   

   Load Balancer Aplikasi internal lintas region dengan deployment ketersediaan tinggi (klik untuk memperbesar).

2. Jika backend di region tertentu tidak beroperasi, traffic Load Balancer Aplikasi internal lintas region akan dialihkan ke backend di region lain dengan lancar.

   Contoh deployment failover lintas region menunjukkan hal berikut:

   • Load Balancer Aplikasi internal lintas region dengan alamat VIP frontend di region RegionA jaringan VPC Anda. Klien Anda juga berada di wilayah RegionA.
   • Layanan backend global yang mereferensikan backend di region Google Cloud RegionA dan RegionB.
   • Jika backend di region RegionA tidak aktif, traffic akan gagal ditransfer ke region RegionB.

   

   Load Balancer Aplikasi internal lintas region dengan deployment failover lintas region (klik untuk memperbesar).

Dukungan WebSocket

Load balancer berbasis HTTP(S) Google Cloud mendukung protokol websocket saat Anda menggunakan HTTP atau HTTPS sebagai protokol ke backend. Load balancer tidak memerlukan konfigurasi apa pun untuk membuat proxy koneksi websocket.

Protokol websocket menyediakan saluran komunikasi full-duplex antara klien dan load balancer. Untuk mengetahui informasi selengkapnya, lihat RFC 6455.

Protokol websocket berfungsi sebagai berikut:

1. Load balancer mengenali permintaan Upgrade websocket dari klien HTTP(S). Permintaan berisi header Connection: Upgrade, Upgrade: websocket, diikuti dengan header permintaan terkait websocket lainnya yang relevan.
2. Backend mengirimkan respons Upgrade websocket. Instance backend mengirimkan respons 101 switching protocol dengan header Connection: Upgrade, Upgrade: websocket, dan header respons terkait websocket lainnya.
3. Load balancer melakukan proxy traffic dua arah selama durasi koneksi saat ini.

Jika instance backend menampilkan respons error dengan kode respons 426 atau 502, load balancer akan menutup koneksi.

Afinitas sesi untuk websocket berfungsi sama seperti untuk permintaan lainnya. Untuk mengetahui informasi selengkapnya, lihat Afinitas sesi.

Dukungan gRPC

gRPC adalah framework open source untuk panggilan prosedur jarak jauh. Protokol ini didasarkan pada standar HTTP/2. Kasus penggunaan untuk gRPC mencakup hal berikut:

• Sistem terdistribusi berlatensi rendah dan sangat skalabel
• Mengembangkan klien seluler yang berkomunikasi dengan server cloud
• Mendesain protokol baru yang harus akurat, efisien, dan tidak bergantung pada bahasa
• Desain berlapis untuk mengaktifkan ekstensi, autentikasi, dan logging

Untuk menggunakan gRPC dengan aplikasi Google Cloud, Anda harus melakukan proxy permintaan secara menyeluruh melalui HTTP/2. Untuk melakukannya:

1. Mengonfigurasi load balancer HTTPS.
2. Aktifkan HTTP/2 sebagai protokol dari load balancer ke backend.

Load balancer menegosiasikan HTTP/2 dengan klien sebagai bagian dari handshake SSL dengan menggunakan ekstensi TLS ALPN.

Load balancer mungkin masih menegosiasikan HTTPS dengan beberapa klien atau menerima permintaan HTTP yang tidak aman di load balancer yang dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan instance backend. Permintaan HTTP atau HTTPS tersebut diubah oleh load balancer untuk melakukan proxy permintaan melalui HTTP/2 ke instance backend.

Anda harus mengaktifkan TLS di backend. Untuk mengetahui informasi selengkapnya, lihat Enkripsi dari load balancer ke backend.

Dukungan TLS

Secara default, proxy target HTTPS hanya menerima TLS 1.0, 1.1, 1.2, dan 1.3 saat menghentikan permintaan SSL klien.

Saat menggunakan HTTPS sebagai protokol layanan backend, load balancer dapat menegosiasikan TLS 1.0, 1.1, 1.2, atau 1.3 ke backend.

Dukungan TLS bersama

TLS Bersama, atau mTLS, adalah protokol standar industri untuk autentikasi bersama antara klien dan server. Hal ini memastikan bahwa klien dan server melakukan autentikasi satu sama lain dengan memverifikasi bahwa masing-masing memiliki sertifikat yang valid yang dikeluarkan oleh certificate authority (CA) tepercaya. Tidak seperti TLS standar, yang hanya mengautentikasi server, mTLS mewajibkan klien dan server untuk menunjukkan sertifikat, yang mengonfirmasi identitas kedua belah pihak sebelum komunikasi dilakukan.

Semua Load Balancer Aplikasi mendukung mTLS. Dengan mTLS, load balancer meminta klien mengirim sertifikat untuk mengautentikasi dirinya sendiri selama handshake TLS dengan load balancer. Anda dapat mengonfigurasi penyimpanan kepercayaan Pengelola Sertifikat yang kemudian digunakan load balancer untuk memvalidasi rantai kepercayaan sertifikat klien.

Untuk informasi selengkapnya tentang mTLS, lihat Autentikasi TLS bersama.

Batasan

• Tidak ada jaminan bahwa permintaan dari klien di satu zona region akan dikirim ke backend yang berada di zona yang sama dengan klien. Afinitas sesi tidak mengurangi komunikasi antar-zona.

• Load Balancer Aplikasi internal tidak kompatibel dengan fitur berikut:

  • Cloud CDN
  • Bucket Cloud Storage
  • Sertifikat SSL yang dikelola Google

• Load Balancer Aplikasi internal hanya mendukung HTTP/2 melalui TLS.

• Klien yang terhubung ke Load Balancer Aplikasi internal harus menggunakan HTTP versi 1.1 atau yang lebih baru. HTTP 1.0 tidak didukung.

• Google Cloud tidak memperingatkan Anda jika subnet khusus proxy kehabisan alamat IP.

• Aturan penerusan internal yang digunakan Load Balancer Aplikasi internal Anda harus memiliki tepat satu port.

• Load Balancer Aplikasi Internal tidak mendukung Cloud Trace.

• Saat menggunakan Load Balancer Aplikasi internal dengan Cloud Run di lingkungan VPC Bersama, jaringan VPC mandiri dalam project layanan dapat mengirim traffic ke layanan Cloud Run lainnya yang di-deploy di project layanan lain dalam lingkungan VPC Bersama yang sama. Ini adalah masalah yang diketahui dan bentuk akses ini akan diblokir di masa mendatang.

• Google Cloud tidak menjamin bahwa koneksi TCP yang mendasarinya dapat tetap terbuka selama keseluruhan nilai waktu tunggu layanan backend. Sistem klien harus menerapkan logika percobaan ulang, bukan mengandalkan koneksi TCP yang terbuka untuk jangka waktu yang lama.

Langkah selanjutnya

• Untuk mengonfigurasi load balancing di penyiapan VPC Bersama, lihat Menyiapkan Load Balancer Aplikasi internal untuk VPC Bersama.

• Untuk mengonfigurasi load balancing bagi layanan yang berjalan di pod GKE, lihat Men-deploy GKE Gateway, Load balancing native container dengan NEG mandiri, dan bagian Menempelkan Load Balancer Aplikasi internal ke NEG mandiri.

• Untuk mengelola resource subnet khusus proxy, lihat Subnet khusus proxy.

• Untuk mengonfigurasi subsetelan backend di Load Balancer Aplikasi internal regional, lihat Subsetelan backend.

• Untuk mengonfigurasi Load Balancer Aplikasi internal regional dengan Private Service Connect, lihat Mengonfigurasi Private Service Connect dengan kontrol layanan HTTP(S) konsumen.

• Untuk menyisipkan logika kustom ke jalur data load balancing, konfigurasikan plugin atau info Ekstensi Layanan.