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. Load Balancer Aplikasi internal mendistribusikan traffic HTTP dan HTTPS ke backend yang dihosting di berbagai platform seperti Compute Engine, Google Kubernetes Engine (GKE), dan Cloud Run. Google Cloud 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 diimplementasikan 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 manajemen traffic yang membantu 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 salah satu region tidak berfungsi, traffic dapat dialihkan ke region lain.

• Load Balancer Aplikasi internal regional. Load balancer ini adalah load balancer regional yang diimplementasikan sebagai layanan terkelola berdasarkan proxy Envoyopen source. Mode regional mengharuskan backend berada di satu Google Cloud region. Klien dapat dibatasi ke region tersebut atau dapat berada di region mana pun, berdasarkan apakah akses global dinonaktifkan atau diaktifkan pada aturan penerusan. Load balancer ini diaktifkan dengan kemampuan kontrol traffic yang beragam berdasarkan parameter HTTP atau HTTPS. Setelah load balancer dikonfigurasi, load balancer akan otomatis mengalokasikan proxy Envoy untuk memenuhi kebutuhan traffic Anda.

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

  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 berbagi layanan backend global yang sama. Anda dapat mengonfigurasi load balancing global berbasis DNS dengan 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 Google Cloud region 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 yang di-load balance	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 berfungsi baik di region yang sama atau berbeda.	Failover otomatis ke backend yang responsif di region yang sama.

Mengidentifikasi mode

Arsitektur dan resource

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

Resource berikut diperlukan untuk deployment Load Balancer Aplikasi internal:

Subnet khusus proxy

Pada diagram sebelumnya, subnet khusus proxy menyediakan serangkaian 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 region:

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 berbagi subnet khusus proxy yang sama

Selanjutnya:

• Subnet khusus proxy hanya digunakan untuk proxy Envoy, bukan backend Anda.
• VM atau endpoint backend 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 terkelola internalnya, yang dijelaskan di bawah.

Aturan penerusan dan alamat IP

Aturan penerusan mengarahkan traffic menurut 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 catatan DNS untuk aplikasi Anda. Anda dapat memesan alamat IP statis yang dapat digunakan atau membiarkan Cloud Load Balancing menetapkan alamat IP untuk Anda. Sebaiknya cadangkan 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 Load Balancer Aplikasi 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 mereferensikan target HTTP atau HTTPS yang sama selama kombinasi alamat IP, port, dan protokol secara keseluruhan 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	Merutekan 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 memungkinkan 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 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 internal dikaitkan dengan jaringan VPC.

Mode load balancer	Asosiasi 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 tempat subnet khusus proxy telah dibuat. Dengan demikian, ada pengaitan jaringan tersirat.

Proxy target

Proxy HTTP atau HTTPS target menghentikan koneksi HTTP(S) dari klien. Proxy HTTP(S) berkonsultasi dengan peta URL untuk menentukan cara merutekan traffic ke backend. Proxy HTTPS target menggunakan sertifikat SSL untuk mengautentikasi dirinya sendiri 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, kedua 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 lainnya 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 mungkin mencatat alamat ini serta alamat IP instance backend itu sendiri.

Bergantung pada jenis traffic yang perlu ditangani aplikasi Anda, 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	Global targetHttpProxies Global targetHttpsProxies
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 Load Balancer Aplikasi internal dalam setiap mode:

Mode load balancer	Jenis sertifikat SSL
Load Balancer Aplikasi internal regional	Sertifikat SSL regional Compute Engine Certificate Manager sertifikat yang dikelola sendiri secara regional dan sertifikat yang dikelola Google. Jenis sertifikat yang dikelola Google berikut didukung dengan Certificate Manager: Sertifikat yang dikelola Google regional dengan otorisasi DNS per project. Untuk mengetahui informasi selengkapnya, lihat Men-deploy sertifikat yang dikelola Google regional. Sertifikat yang dikelola Google regional 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	Certificate Manager sertifikat yang dikelola sendiri dan sertifikat yang dikelola Google. Jenis sertifikat yang dikelola Google berikut didukung dengan Certificate Manager: Otorisasi DNS dengan DNS Publik. Untuk mengetahui informasi selengkapnya, lihat Men-deploy sertifikat yang dikelola Google global 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 perutean berdasarkan atribut HTTP (seperti jalur permintaan, cookie, atau header). Berdasarkan keputusan perutean, proxy meneruskan permintaan klien ke layanan backend tertentu. Peta URL dapat menentukan tindakan tambahan yang harus dilakukan, seperti menulis ulang header, mengirim pengalihan ke klien, dan mengonfigurasi kebijakan waktu tunggu (serta tindakan 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 sehingga load balancer 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 ada TLS
• HTTPS, yang menggunakan HTTP/1.1 dan TLS
• HTTP/2, yang menggunakan HTTP/2 dan TLS (HTTP/2 tanpa enkripsi tidak didukung).
• H2C, yang menggunakan HTTP/2 melalui TCP. TLS tidak diperlukan. H2C tidak didukung untuk Load Balancer Aplikasi klasik.

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

Protokol layanan backend tidak harus 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 pada layanan backend1						Mendukung bucket backend	Mendukung Google Cloud Armor	Mendukung Cloud CDN	Mendukung IAP	Mendukung Ekstensi Layanan
	Instance groups2	NEG Zonal3	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 dan jaringan VPC

Batasan lokasi backend bergantung pada jenis backend.

• Untuk grup instance, NEG zonal, dan NEG konektivitas hibrida, 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 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 zonal 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 mengizinkan komunikasi antara subnet khusus proxy di jaringan VPC aturan penerusan dan subnet yang digunakan oleh instance atau endpoint backend.

• Jaringan VPC backend dan jaringan VPC aturan penerusan harus berupa spoke VPC yang terhubung ke 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 region dan jaringan VPC yang sama.

Backend dan antarmuka jaringan

Jika Anda menggunakan backend grup instance, paket akan selalu dikirimkan ke nic0. Jika Anda ingin mengirim paket ke antarmuka non-nic0 (baik vNIC atau Antarmuka Jaringan Dinamis), 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

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, subsetting backend dinonaktifkan. Untuk mengetahui informasi tentang cara mengaktifkan fitur ini, lihat Subset backend untuk Load Balancer Aplikasi internal regional.

Health check

Setiap layanan backend menentukan health check yang secara berkala memantau kesiapan backend untuk menerima koneksi dari load balancer. Hal ini mengurangi risiko permintaan 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 yang mengizinkan pemeriksaan health check menjangkau instance backend Anda. Biasanya, pemeriksaan health check berasal dari mekanisme pemeriksaan kondisi terpusat Google. Namun, untuk NEG hybrid, health check berasal dari subnet khusus proxy. Untuk mengetahui detailnya, lihat Pemeriksaan kondisi Envoy terdistribusi.

Protokol health check

Meskipun tidak wajib dan tidak selalu memungkinkan, sebaiknya gunakan health check yang protokolnya cocok dengan protokol layanan backend. Misalnya, health check HTTP/2 paling akurat menguji konektivitas HTTP/2 ke backend. Sebaliknya, Load Balancer Aplikasi internal yang menggunakan backend NEG hibrida tidak mendukung health check gRPC. Untuk daftar protokol health check yang didukung, lihat fitur load balancing di bagian Health check.

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 kondisi, lihat artikel berikut:

• Ringkasan health check
• Membuat health check

Aturan firewall

Load Balancer Aplikasi internal memerlukan aturan firewall berikut:

• Aturan izinkan masuk yang mengizinkan traffic dari rentang health check pusat Google. Untuk mengetahui informasi selengkapnya tentang rentang alamat IP pemeriksaan health check tertentu dan alasan mengapa perlu mengizinkan traffic dari rentang tersebut, lihat Rentang IP pemeriksaan dan aturan firewall.
• Aturan izinkan masuk yang mengizinkan traffic dari subnet khusus proxy.

Ada pengecualian tertentu untuk persyaratan aturan firewall untuk rentang ini:

• Mengizinkan traffic dari rentang pemeriksaan health check Google tidak diperlukan untuk NEG hibrida. Namun, jika Anda menggunakan kombinasi NEG hybrid dan zona dalam satu layanan backend, Anda harus mengizinkan traffic dari rentang pemeriksaan kondisi 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 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.

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 untuk mengizinkan klien dari region mana pun di VPC 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. Backend 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 region mana pun. Backend tersebut harus tetap 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 GKE Gateway 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 berupa 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 tersebut 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 di project host atau project layanan, tetapi harus menggunakan subnet di jaringan VPC Bersama yang diinginkan dalam 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 dengan 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. Pemeriksaan kondisi yang terkait dengan layanan backend juga harus ditentukan dalam project yang sama dengan layanan backend.

Meskipun Anda dapat membuat semua komponen load balancing dan backend 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 load balancer dan backend 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 Shared VPC yang sama dengan load balancer. Klien dapat berada di project host, atau di project layanan yang terpasang, atau di jaringan yang terhubung.

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 lain dalam lingkungan VPC Bersama yang sama.

Referensi layanan lintas project

Referensi layanan lintas project adalah model deployment yang menempatkan frontend dan peta URL load balancer di satu project, serta layanan backend dan backend load balancer di 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 perutean traffic secara terpusat dalam satu peta URL. Anda juga dapat mengaitkan load balancer dengan satu set nama host dan sertifikat SSL. Oleh karena itu, Anda dapat mengoptimalkan jumlah load balancer yang diperlukan untuk men-deploy aplikasi, serta menurunkan kemudahan 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 dalam project lain, dan keduanya dapat terhubung menggunakan referensi layanan lintas project.

Pemilik layanan dapat mempertahankan otonomi atas eksposur layanan mereka dan mengontrol pengguna mana yang dapat mengakses layanan mereka dengan menggunakan load balancer. Hal ini dicapai dengan peran IAM khusus yang disebut peran Compute Load Balancer Services User (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.

Catatan penggunaan untuk 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 Anda 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 di mana frontend dan peta URL load balancer 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 memerlukan akses ke layanan backend di project layanan B. Admin project layanan B memberikan peran Compute Load Balancer Services User (roles/compute.loadBalancerServiceUser) kepada Admin Load Balancer di project layanan A yang ingin mereferensikan layanan backend di project layanan B.

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, serta layanan backend (dan backend) dibuat di project layanan.

Dalam kasus ini, Admin Jaringan atau Admin Load Balancer di project host memerlukan akses ke layanan backend di project layanan. Admin project layanan memberikan peran Compute Load Balancer Services User (roles/compute.loadBalancerServiceUser) kepada Admin Load Balancer di project host A yang ingin mereferensikan layanan backend di project layanan.

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. Mewakili 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 dihilangkan.	Untuk NEG tanpa server pada layanan backend: 60 menit Untuk semua jenis backend lainnya di layanan backend: 30 detik
Waktu tunggu aktif HTTP klien Waktu maksimum koneksi TCP antara klien dan proxy Envoy yang dikelola load balancer dapat tidak aktif. (Koneksi TCP yang sama dapat digunakan untuk beberapa permintaan HTTP.)	610 detik
Waktu tunggu keep-alive HTTP backend Jumlah waktu maksimum koneksi TCP antara proxy Envoy terkelola load balancer dan backend dapat tidak aktif. (Koneksi TCP yang sama dapat digunakan untuk beberapa permintaan HTTP.)	10 menit (600 detik)

Waktu tunggu layanan backend

Waktu tunggu layanan backend yang dapat dikonfigurasi menunjukkan jumlah waktu maksimum yang ditunggu load balancer agar 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 akan mengharapkan backend mengirimkan seluruh file berukuran 500 MB dalam waktu 90 detik. Waktu tunggu layanan backend dapat dikonfigurasi agar tidak cukup bagi backend untuk mengirim respons HTTP lengkapnya. Dalam situasi ini, jika load balancer telah menerima header respons HTTP dari backend, load balancer akan menampilkan header respons lengkap dan isi respons sebanyak yang dapat diperoleh dalam waktu tunggu layanan backend.

Sebaiknya tetapkan waktu tunggu layanan backend ke waktu terlama yang Anda perkirakan dibutuhkan backend untuk memproses respons HTTP. Jika software yang berjalan di backend Anda memerlukan lebih banyak waktu untuk memproses permintaan HTTP dan menampilkan seluruh responsnya, sebaiknya tingkatkan waktu tunggu layanan backend.

Waktu tunggu layanan backend menerima nilai antara 1 dan 2,147,483,647 detik; namun, nilai yang lebih besar bukanlah opsi konfigurasi yang praktis. Google Cloud juga tidak menjamin bahwa koneksi TCP yang mendasarinya dapat tetap terbuka selama seluruh nilai waktu tunggu layanan backend. Sistem klien harus menerapkan logika percobaan ulang, bukan mengandalkan koneksi TCP agar tetap terbuka dalam 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 aktif akan ditutup setelah waktu tunggu layanan backend berakhir.

Google Cloud secara berkala memulai ulang atau mengubah jumlah tugas software Envoy penayangan. Semakin lama nilai waktu tunggu layanan backend, semakin besar kemungkinan tugas Envoy dimulai ulang atau diganti akan menghentikan koneksi TCP.

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

Waktu tunggu keep-alive HTTP klien

Waktu tunggu keep-alive HTTP klien menunjukkan jumlah waktu maksimum koneksi TCP dapat tidak ada aktivitas antara klien (downstream) dan proxy Envoy. Nilai waktu tunggu HTTP keep-alive klien default adalah 610 detik. Anda dapat mengonfigurasi waktu tunggu dengan nilai antara 5 dan 1.200 detik.

Waktu tunggu HTTP keep-alive juga disebut waktu tunggu TCP idle.

Waktu tunggu HTTP keep-alive klien load balancer harus lebih besar daripada waktu tunggu HTTP keep-alive (TCP idle) yang digunakan oleh klien atau proxy hilir. Jika klien hilir memiliki waktu tunggu HTTP keep-alive (TCP idle) yang lebih besar daripada waktu tunggu HTTP keep-alive klien load balancer, kondisi persaingan dapat terjadi. Dari perspektif klien hilir, koneksi TCP yang dibuat diizinkan untuk tidak aktif lebih lama daripada yang diizinkan oleh load balancer. Artinya, klien hilir dapat mengirim paket setelah load balancer menganggap koneksi TCP telah ditutup. Jika hal itu terjadi, load balancer akan merespons dengan paket reset TCP (RST).

Saat waktu tunggu keep-alive HTTP klien berakhir, proxy GFE atau Envoy akan mengirim TCP FIN ke klien untuk menutup koneksi dengan benar.

Waktu tunggu keep-alive 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 tetap aktif HTTP backend menentukan waktu tunggu tidak ada aktivitas TCP antara load balancer dan backend Anda. Waktu tunggu HTTP keep-alive backend tidak berlaku untuk websocket.

Waktu tunggu tetap aktif backend ditetapkan pada 10 menit (600 detik) dan tidak dapat diubah. Hal ini membantu memastikan load balancer mempertahankan koneksi tidak aktif selama minimal 10 menit. Setelah periode ini, load balancer dapat mengirimkan paket penghentian ke backend kapan saja.

Waktu tunggu tetap aktif backend load balancer harus kurang dari waktu tunggu tetap aktif yang digunakan oleh software yang berjalan di backend Anda. Hal ini menghindari kondisi race di mana sistem operasi backend Anda dapat menutup koneksi TCP dengan reset TCP (RST). Karena waktu tunggu tetap aktif backend untuk load balancer tidak dapat dikonfigurasi, Anda harus mengonfigurasi software backend sehingga nilai waktu tunggu tetap aktif HTTP (TCP idle) lebih besar dari 600 detik.

Saat waktu tunggu keep-alive HTTP backend berakhir, GFE atau proxy Envoy akan mengirim TCP FIN ke VM backend untuk menutup koneksi dengan benar.

Tabel berikut mencantumkan perubahan yang diperlukan untuk mengubah nilai waktu tunggu tetap aktif 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 yang dapat dikonfigurasi maksimum 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 satu kali.

Permintaan POST HTTP tidak dicoba ulang.

Permintaan yang dicoba lagi 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 cara berikut:

• Peering Jaringan VPC
• Cloud VPN dan Cloud Interconnect

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

Failover

Jika backend bermasalah, traffic akan otomatis dialihkan ke backend yang berfungsi dengan baik.

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 responsif di region yang sama atau region lain. Traffic didistribusikan di antara backend yang responsif di 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 suatu 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 gangguan 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 paling optimal berikutnya kepada klien Anda, sehingga memastikan aplikasi Anda tetap aktif meskipun terjadi pemadaman layanan regional.

   

2. Jika backend di region tertentu tidak berfungsi, traffic Load Balancer Aplikasi internal lintas region akan melakukan failover 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 berlokasi di wilayah RegionA.
   • Layanan backend global yang mereferensikan backend di region RegionA dan RegionB Google Cloud .
   • Jika backend di region RegionA tidak berfungsi, traffic akan dialihkan ke region RegionB.

   

Dukungan WebSocket

Load balancer berbasis HTTP(S) mendukung protokol websocket saat Anda menggunakan HTTP atau HTTPS sebagai protokol ke backend.Google Cloud Load balancer tidak memerlukan konfigurasi apa pun untuk memproksi 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 websocket Upgrade dari klien HTTP atau HTTPS. Permintaan berisi header Connection: Upgrade dan Upgrade: websocket, diikuti dengan header permintaan terkait websocket lainnya yang relevan.
2. Backend mengirim respons websocket Upgrade. Instance backend mengirimkan respons 101 switching protocol dengan header Connection: Upgrade dan Upgrade: websocket serta header respons terkait websocket lainnya.
3. Load balancer memproksi traffic dua arah selama durasi koneksi saat ini.

Jika instance backend menampilkan kode status 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 HTTP/2

HTTP/2 adalah revisi besar protokol HTTP/1. Ada 2 mode dukungan HTTP/2:

• HTTP/2 melalui TLS
• HTTP/2 Cleartext melalui TCP

HTTP/2 melalui TLS

HTTP/2 melalui TLS didukung untuk koneksi antara klien dan Load Balancer Aplikasi eksternal, serta untuk koneksi antara load balancer dan backend-nya.

Load balancer otomatis menegosiasikan HTTP/2 dengan klien sebagai bagian dari handshake TLS menggunakan ekstensi TLS ALPN. Meskipun load balancer dikonfigurasi untuk menggunakan HTTPS, klien modern secara default menggunakan HTTP/2. Hal ini dikontrol di klien, bukan di load balancer.

Jika klien tidak mendukung HTTP/2 dan load balancer dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan instance backend, load balancer mungkin masih menegosiasikan koneksi HTTPS atau menerima permintaan HTTP yang tidak aman. Permintaan HTTPS atau HTTP tersebut kemudian diubah oleh load balancer untuk memproksi permintaan melalui HTTP/2 ke instance backend.

Untuk menggunakan HTTP/2 melalui TLS, Anda harus mengaktifkan TLS di backend dan menetapkan protokol layanan backend ke HTTP2. Untuk mengetahui informasi selengkapnya, lihat Enkripsi dari load balancer ke backend.

Streaming serentak maksimum HTTP/2

Setelan HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS menjelaskan jumlah maksimum aliran yang diterima endpoint, yang dimulai oleh peer. Nilai yang diiklankan oleh klien HTTP/2 ke load balancerGoogle Cloud pada dasarnya tidak berarti karena load balancer tidak memulai streaming ke klien.

Jika load balancer menggunakan HTTP/2 untuk berkomunikasi dengan server yang berjalan di VM, load balancer akan mematuhi nilai SETTINGS_MAX_CONCURRENT_STREAMS yang diiklankan oleh server. Jika nilai nol diiklankan, load balancer tidak dapat meneruskan permintaan ke server, dan hal ini dapat menyebabkan error.

Batasan HTTP/2

• HTTP/2 antara load balancer dan instance dapat memerlukan koneksi TCP yang jauh lebih banyak ke instance daripada HTTP atau HTTPS. Penggabungan koneksi, pengoptimalan yang mengurangi jumlah koneksi ini dengan HTTP atau HTTPS, tidak tersedia dengan HTTP/2. Akibatnya, Anda mungkin melihat latensi backend yang tinggi karena koneksi backend dibuat lebih sering.
• HTTP/2 antara load balancer dan backend tidak mendukung menjalankan Protokol WebSocket melalui satu aliran koneksi HTTP/2 (RFC 8441).
• HTTP/2 antara load balancer dan backend tidak mendukung push server.
• Volume permintaan dan rasio error gRPC tidak terlihat di Google Cloud API atau konsol Google Cloud . Jika endpoint gRPC menampilkan error, log load balancer dan data pemantauan akan melaporkan kode status HTTP 200 OK.

HTTP/2 teks biasa melalui TCP (H2C)

HTTP/2 cleartext melalui TCP, juga dikenal sebagai H2C, memungkinkan Anda menggunakan HTTP/2 tanpa TLS. H2C didukung untuk kedua koneksi berikut:

• Koneksi antara klien dan load balancer. Tidak diperlukan konfigurasi khusus.

• Koneksi antara load balancer dan backend-nya.

  Untuk mengonfigurasi H2C untuk koneksi antara load balancer dan backend-nya, Anda menetapkan protokol layanan backend ke H2C.

Dukungan H2C juga tersedia untuk load balancer yang dibuat menggunakan pengontrol Gateway GKE dan Cloud Service Mesh.

H2C tidak didukung untuk Load Balancer Aplikasi klasik.

Dukungan gRPC

gRPC adalah framework open source untuk remote procedure call. gRPC didasarkan pada standar HTTP/2. Kasus penggunaan untuk gRPC mencakup hal berikut:

• Sistem terdistribusi yang berlatensi rendah dan sangat skalabel
• Mengembangkan klien seluler yang berkomunikasi dengan server cloud
• Merancang 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 mem-proxy permintaan end-to-end melalui HTTP/2. Untuk melakukannya, Anda membuat Load Balancer Aplikasi dengan salah satu konfigurasi berikut:

• Untuk traffic tidak terenkripsi end-to-end (tanpa TLS): Anda membuat load balancer HTTP (dikonfigurasi dengan proxy HTTP target). Selain itu, Anda mengonfigurasi load balancer untuk menggunakan HTTP/2 untuk koneksi yang tidak dienkripsi antara load balancer dan backend-nya dengan menyetel protokol layanan backend ke H2C.

• Untuk traffic terenkripsi end-to-end (dengan TLS): Anda membuat load balancer HTTPS (dikonfigurasi dengan proxy HTTPS target dan sertifikat SSL). Load balancer menegosiasikan HTTP/2 dengan klien sebagai bagian dari handshake SSL menggunakan ekstensi TLS ALPN.

  Selain itu, Anda harus memastikan bahwa backend dapat menangani traffic TLS dan mengonfigurasi load balancer untuk menggunakan HTTP/2 untuk koneksi terenkripsi antara load balancer dan backend-nya dengan menyetel protokol layanan backend ke HTTP2.

  Load balancer mungkin masih melakukan negosiasi HTTPS dengan beberapa klien atau menerima permintaan HTTP yang tidak aman pada load balancer yang dikonfigurasi untuk menggunakan HTTP/2 antara load balancer dan instance backend. Permintaan HTTP atau HTTPS tersebut diubah oleh load balancer untuk memproksi permintaan melalui HTTP/2 ke instance 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.

Jika menggunakan HTTPS sebagai protokol layanan backend, Load Balancer Aplikasi internal dapat menegosiasikan TLS 1.2 atau 1.3 ke backend.

Dukungan TLS bersama

TLS timbal balik, atau mTLS, adalah protokol standar industri untuk autentikasi timbal balik antara klien dan server. mTLS membantu memastikan bahwa klien dan server saling mengautentikasi dengan memverifikasi bahwa masing-masing memegang sertifikat valid yang dikeluarkan oleh otoritas sertifikat (CA) tepercaya. Tidak seperti TLS standar, yang hanya mengautentikasi server, mTLS mengharuskan klien dan server untuk memberikan sertifikat, yang mengonfirmasi identitas kedua pihak sebelum komunikasi dilakukan.

Semua Load Balancer Aplikasi mendukung mTLS. Dengan mTLS, load balancer meminta klien mengirimkan sertifikat untuk mengautentikasi dirinya sendiri selama handshake TLS dengan load balancer. Anda dapat mengonfigurasi trust store Certificate Manager yang kemudian digunakan load balancer untuk memvalidasi rantai kepercayaan sertifikat klien.

Untuk mengetahui informasi selengkapnya tentang mTLS, lihat Autentikasi TLS bersama.

Batasan

• Tidak ada jaminan bahwa permintaan dari klien di satu zona region 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
  • Sertifikat SSL yang dikelola Google di Compute Engine (sertifikat yang dikelola Google di Certificate Manager didukung)

• Untuk menggunakan sertifikat Certificate Manager dengan Load Balancer Aplikasi internal, Anda harus menggunakan API atau gcloud CLI. Konsol Google Cloud tidak mendukung sertifikat Certificate Manager.

• 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 proxykehabisan alamat IP.

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

• 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 umum.

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

• Load Balancer Aplikasi internal tidak mendukung Cloud Functions generasi ke-1 dan App Engine. Untuk mengetahui informasi selengkapnya, lihat Ringkasan NEG serverless: Load balancer yang didukung.

• Load Balancer Aplikasi Internal tidak mendukung Cloud Trace.

Langkah berikutnya

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

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

• Untuk mengelola resource subnet khusus proxy, lihat Subnet khusus proxy untuk load balancer berbasis Envoy.

• Untuk mengonfigurasi subset backend di Load Balancer Aplikasi internal regional, lihat Subset backend.

• Untuk mengonfigurasi Load Balancer Aplikasi internal regional dengan Private Service Connect, lihat Mengakses Google API regional melalui backend.

• Untuk menyisipkan logika kustom ke jalur data load balancing, konfigurasi ekstensi Cloud Load Balancing.