Load Balancer Jaringan proxy internal Google Cloud adalah load balancer berbasis proxy yang didukung oleh software proxy Envoy open source dan stack virtualisasi jaringan Andromeda.
Load Balancer Jaringan proxy internal adalah load balancer lapisan 4 yang memungkinkan Anda menjalankan dan menskalakan traffic layanan TCP di balik alamat IP internal regional yang hanya dapat diakses oleh klien di jaringan VPC yang sama atau klien yang terhubung ke jaringan VPC Anda. Load balancer pertama-tama menghentikan koneksi TCP antara klien dan load balancer di proxy Envoy. Proxy membuka koneksi TCP kedua ke backend yang dihosting di Google Cloud, lokal, atau lingkungan cloud lainnya. Untuk mengetahui kasus penggunaan lainnya, lihat Ringkasan Load Balancer Jaringan Proxy.
Mode operasi
Anda dapat mengonfigurasi Network Load Balancer proxy internal dalam mode berikut:
Load Balancer Jaringan proxy 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 Jaringan proxy 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 manajemen 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.
Tabel berikut menjelaskan perbedaan penting antara mode regional dan lintas wilayah:
Fitur Load Balancer Jaringan proxy internal regional Load Balancer Jaringan proxy internal lintas region Alamat IP virtual (VIP) load balancer. Dialokasikan dari subnet di region Google Cloud tertentu. Dialokasikan dari subnet di region Google Cloud tertentu. Alamat VIP dari beberapa region dapat menggunakan layanan backend global yang sama.
Akses klien Tidak dapat diakses secara global secara default.
Secara opsional, Anda dapat mengaktifkan akses global.Selalu dapat diakses secara global. Klien dari region Google Cloud mana pun dapat mengirim traffic ke load balancer. Backend load balanced Backend regional.
Load balancer hanya dapat mengirim traffic ke backend yang berada di region yang sama dengan proxy load balancer.Backend global.
Load balancer dapat mengirim traffic ke backend di region mana pun.Ketersediaan tinggi dan failover Failover otomatis ke backend yang responsif di region yang sama. Failover otomatis ke backend yang sehat di region yang sama atau berbeda.
Mengidentifikasi mode
Cloud Console
Di konsol Google Cloud, buka halaman Load balancing.
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 Jaringan proxy internal regional Jaringan (Proxy) Internal Menentukan region Load Balancer Jaringan proxy internal lintas region Jaringan (Proxy) Internal
gcloud
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 Jaringan proxy internal regional INTERNAL_MANAGED Regional Load Balancer Jaringan proxy internal lintas region INTERNAL_MANAGED Global
Arsitektur
Diagram berikut menunjukkan resource Google Cloud yang diperlukan untuk Load Balancer Jaringan proxy internal.
Regional
Diagram ini menunjukkan komponen deployment Load Balancer Jaringan proxy internal regional di Paket Premium.
Lintas region
Diagram ini menunjukkan komponen deployment Load Balancer Jaringan proxy internal lintas region di Paket Premium dalam jaringan VPC yang sama. Setiap aturan penerusan global menggunakan alamat IP regional yang digunakan klien untuk terhubung.
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 Jaringan proxy internal berbasis Envoy.
Tabel berikut menjelaskan persyaratan subnet khusus proxy untuk Load Balancer Jaringan proxy internal:
Mode load balancer | Nilai flag --purpose subnet khusus proxy |
---|---|
Load Balancer Jaringan proxy internal regional |
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. |
Load Balancer Jaringan proxy internal lintas region |
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 menggunakan subnet khusus proxy yang sama. |
Lebih lanjut:
- Subnet khusus proxy hanya digunakan untuk proxy Envoy, bukan backend Anda.
- Instance virtual machine (VM) backend atau endpoint dari semua Load Balancer Jaringan proxy internal di region dan jaringan VPC menerima koneksi dari subnet khusus proxy.
- Alamat IP Load Balancer Jaringan proxy internal tidak berada di subnet khusus proxy. Alamat IP load balancer ditentukan oleh aturan penerusan internal yang dikelolanya.
Aturan penerusan dan alamat IP
Aturan penerusan merutekan 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 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 TCP. Untuk mengetahui daftar lengkap protokol yang didukung, lihat Perbandingan 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 yang Anda gunakan di Load Balancer Jaringan proxy internal dapat mereferensikan satu port dari 1-65535. Untuk mendukung beberapa port, Anda harus mengonfigurasi beberapa aturan penerusan.
Tabel berikut menunjukkan persyaratan aturan penerusan untuk Load Balancer Jaringan proxy internal:
Mode load balancer | Aturan penerusan, alamat IP, dan subnet khusus proxy --purpose |
Pemuatan dari klien ke frontend load balancer |
---|---|---|
Load Balancer Jaringan proxy internal regional |
Skema load balancing:
Subnet khusus proxy
Alamat IP
|
Anda dapat mengaktifkan akses global untuk mengizinkan klien dari region mana pun mengakses load balancer Anda. Backend juga harus berada di region yang sama dengan load balancer. |
Load Balancer Jaringan proxy internal lintas region |
Skema load balancing:
Subnet khusus proxy
Alamat IP
|
Akses global diaktifkan secara default untuk mengizinkan klien dari region mana pun mengakses load balancer Anda. Backend dapat berada di beberapa region. |
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 Jaringan proxy lintas region Load Balancer Jaringan proxy 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
Load Balancer Jaringan proxy internal menghentikan koneksi TCP dari klien dan membuat koneksi baru ke backend. Secara default, alamat IP klien asli dan informasi port tidak dipertahankan. Anda dapat mempertahankan informasi ini dengan menggunakan protokol PROXY. Proxy target merutekan permintaan masuk secara langsung ke layanan backend load balancer.
Tabel berikut menunjukkan API proxy target yang diperlukan oleh Load Balancer Jaringan proxy internal:
Mode load balancer | Proxy target |
---|---|
Load Balancer Jaringan proxy internal regional | regionTargetTcpProxies Regional |
Load Balancer Jaringan proxy internal lintas region | targetTcpProxies Global |
Layanan backend
Layanan backend mengarahkan traffic masuk ke satu atau beberapa backend yang terpasang. Backend adalah grup instance atau grup endpoint jaringan. Backend berisi informasi mode penyeimbangan untuk menentukan kelengkapan berdasarkan koneksi (atau, khusus backend grup instance, penggunaan).
Setiap Load Balancer Jaringan proxy internal memiliki satu resource layanan backend.
Tabel berikut menentukan persyaratan layanan backend untuk Load Balancer Jaringan proxy internal:
Mode load balancer | Jenis layanan backend |
---|---|
Load Balancer Jaringan proxy internal regional | regionBackendServices Regional |
Load Balancer Jaringan proxy internal lintas region | backendServices Global |
Backend yang didukung
Layanan backend mendukung jenis backend berikut:
Mode load balancer | Backend yang didukung di layanan backend | ||||||
---|---|---|---|---|---|---|---|
Grup instance | NEG Zona | NEG Internet | NEG Serverless | NEG Hybrid | NEG Private Service Connect | GKE | |
Load Balancer Jaringan proxy internal regional |
Endpoint jenis GCE_VM_IP_PORT |
Khusus NEG regional | Menambahkan NEG Private Service Connect | ||||
Load Balancer Jaringan proxy internal lintas region |
Endpoint jenis GCE_VM_IP_PORT |
Menambahkan NEG Private Service Connect |
Semua backend harus memiliki jenis yang sama (grup instance atau NEG). Anda dapat menggunakan berbagai jenis backend grup instance secara bersamaan, atau Anda dapat menggunakan berbagai jenis backend NEG secara bersamaan, tetapi Anda tidak dapat menggunakan backend grup instance dan NEG secara bersamaan di layanan backend yang sama.
Anda dapat mencampur NEG zonal dan NEG hybrid dalam layanan backend yang sama.
Untuk memastikan gangguan minimal bagi pengguna, Anda dapat mengaktifkan pengosongan koneksi di layanan backend. Gangguan tersebut dapat terjadi saat backend dihentikan, dihapus secara manual, atau dihapus oleh autoscaler. Untuk mempelajari lebih lanjut cara menggunakan pengosongan koneksi untuk meminimalkan gangguan layanan, lihat Mengaktifkan pengosongan koneksi.
Backend dan jaringan VPC
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.
Protokol untuk berkomunikasi dengan backend
Saat mengonfigurasi layanan backend untuk Load Balancer Jaringan proxy internal, Anda menetapkan protokol yang digunakan layanan backend untuk berkomunikasi dengan backend. Load balancer hanya menggunakan protokol yang Anda tentukan, dan tidak mencoba melakukan negosiasi koneksi dengan protokol lain. Load Balancer Jaringan proxy internal hanya mendukung TCP untuk berkomunikasi dengan backend.
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.
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 TCP menguji konektivitas TCP ke backend dengan paling akurat. Untuk daftar protokol health check yang didukung, lihat Fitur load balancing.
Tabel berikut menentukan cakupan pemeriksaan kesehatan yang didukung oleh Network Load Balancer proxy internal dalam setiap mode:
Mode load balancer | Jenis health check |
---|---|
Load Balancer Jaringan proxy internal regional | regionHealthChecks Regional |
Load Balancer Jaringan proxy internal lintas region | healthChecks Global |
Untuk mengetahui informasi selengkapnya tentang pemeriksaan kesehatan, lihat artikel berikut:
Aturan firewall
Load Balancer Jaringan proxy internal memerlukan aturan firewall berikut:
- Aturan izin masuk yang mengizinkan traffic dari probe health check Google.
35.191.0.0/16
130.211.0.0/22
2600:2d00:1:b029::/64
- Aturan izin masuk yang mengizinkan traffic dari subnet khusus proxy.
Port untuk aturan firewall ini harus dikonfigurasi sebagai berikut:
Izinkan traffic ke port tujuan untuk setiap health check layanan backend.
Untuk backend grup instance: Tentukan port yang akan dikonfigurasi oleh pemetaan antara port bernama layanan backend dan nomor port yang terkait dengan port bernama tersebut di setiap grup instance. Nomor port dapat bervariasi di antara grup instance yang ditetapkan ke layanan backend yang sama.
Untuk backend NEG
GCE_VM_IP_PORT
: Izinkan traffic ke nomor port endpoint.
Ada pengecualian tertentu untuk persyaratan aturan firewall bagi load balancer 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 Jaringan proxy 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 mengakses load balancer Anda.
Untuk Load Balancer Jaringan proxy internal lintas region, akses global diaktifkan secara default. Klien dari region mana pun dapat mengakses load balancer Anda.
Tabel berikut merangkum akses klien untuk Load Balancer Jaringan proxy 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. |
Arsitektur VPC Bersama
Load Balancer Jaringan proxy internal mendukung jaringan yang menggunakan VPC Bersama. VPC Bersama memungkinkan Anda mempertahankan pemisahan tanggung jawab yang jelas antara administrator jaringan dan developer layanan. Tim pengembangan Anda dapat berfokus pada pembuatan layanan dalam project layanan, dan tim infrastruktur jaringan dapat menyediakan dan mengelola load balancing. Jika Anda belum memahami VPC Bersama, baca dokumentasi ringkasan VPC Bersama.
Alamat IP | Aturan penerusan | Proxy target | Komponen backend |
---|---|---|---|
Alamat IP internal harus ditentukan dalam project yang sama dengan backend. Agar load balancer tersedia di jaringan VPC Bersama, alamat IP internal harus ditentukan dalam project layanan yang sama dengan lokasi VM backend, dan harus mereferensikan subnet di jaringan VPC Bersama yang diinginkan di project host. Alamat itu sendiri berasal dari rentang IP utama subnet yang dirujuk. |
Aturan penerusan internal harus ditentukan dalam project yang sama dengan backend. Agar load balancer tersedia di jaringan VPC Bersama, aturan penerusan internal harus ditentukan dalam project layanan yang sama dengan lokasi VM backend, dan harus mereferensikan subnet yang sama (di jaringan VPC Bersama) dengan referensi alamat IP internal terkait. |
Proxy target harus ditentukan dalam project yang sama dengan backend. | Dalam skenario VPC Bersama, VM backend biasanya berada dalam project layanan. Layanan backend internal regional dan health check harus ditentukan dalam project layanan tersebut. |
Distribusi traffic
Load Balancer Jaringan proxy internal mendistribusikan traffic ke backend-nya sebagai berikut:
- Koneksi yang berasal dari satu klien dikirim ke zona yang sama
selama backend yang sehat (grup instance atau NEG) dalam zona tersebut
tersedia dan memiliki kapasitas, seperti yang ditentukan oleh
mode balancing.
Untuk Load Balancer Jaringan proxy internal regional, mode balancing dapat berupa
CONNECTION
(backend grup instance atau NEG) atauUTILIZATION
(khusus backend grup instance). - Koneksi dari klien dikirim ke backend yang sama jika Anda telah mengonfigurasi afinitas sesi.
- Setelah backend dipilih, traffic kemudian didistribusikan di antara instance (dalam grup instance) atau endpoint (dalam NEG) sesuai dengan kebijakan load balancing. Untuk algoritma kebijakan load balancing
yang didukung, lihat setelan
localityLbPolicy
di dokumentasi API layanan backend regional.
Afinitas sesi
Afinitas sesi memungkinkan Anda mengonfigurasi layanan backend load balancer untuk mengirim semua permintaan dari klien yang sama ke backend yang sama, selama backend responsif dan memiliki kapasitas.
Network Load Balancer proxy internal menawarkan afinitas IP klien, yang meneruskan semua permintaan dari alamat IP klien yang sama ke backend yang sama, selama backend tersebut memiliki kapasitas dan tetap responsif.
Failover
Jika backend menjadi tidak responsif, traffic akan otomatis dialihkan ke backend yang responsif.
Tabel berikut menjelaskan perilaku failover untuk Network Load Balancer proxy internal:
Mode load balancer | Perilaku failover | Perilaku saat semua backend tidak responsif |
---|---|---|
Load Balancer Jaringan proxy internal regional | Load balancer menerapkan algoritma failover yang halus per zona. Daripada menunggu semua backend di zona menjadi tidak responsif, load balancer akan mulai mengalihkan traffic ke zona lain jika rasio backend yang responsif terhadap backend yang tidak responsif di zona mana pun lebih rendah dari nilai minimum persentase tertentu (70%; nilai minimum ini tidak dapat dikonfigurasi). Jika semua backend di semua zona tidak berfungsi, load balancer akan segera menghentikan koneksi klien. Proxy Envoy mengirim traffic ke backend yang responsif di region berdasarkan distribusi traffic yang dikonfigurasi. |
Menghentikan koneksi |
Load Balancer Jaringan proxy 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. |
Menghentikan koneksi |
Load balancing untuk aplikasi GKE
Jika Anda mem-build aplikasi di Google Kubernetes Engine, Anda dapat menggunakan NEG zona mandiri untuk melakukan load balancing traffic langsung ke container. Dengan NEG mandiri, Anda bertanggung jawab untuk membuat objek Service yang membuat NEG zona, lalu mengaitkan NEG dengan layanan backend sehingga load balancer dapat terhubung ke Pod.
Dokumentasi GKE terkait:
Kuota dan batas
Untuk mengetahui informasi tentang kuota dan batas, lihat Kuota resource load balancing.
Batasan
- Load Balancer Jaringan proxy internal tidak mendukung traffic IPv6.
- Load Balancer Jaringan proxy internal tidak mendukung deployment VPC Bersama dengan frontend load balancer berada di satu host atau project layanan dan layanan backend serta backend berada di project layanan lain (juga dikenal sebagai referensi layanan lintas project).
Langkah selanjutnya
Menyiapkan Load Balancer Aplikasi internal lintas region dengan backend grup instance VM
Menyiapkan Load Balancer Aplikasi internal lintas region dengan konektivitas hybrid
Menyiapkan Load Balancer Jaringan proxy internal regional dengan backend grup instance
Menyiapkan Load Balancer Jaringan proxy internal regional dengan backend NEG zona
Menyiapkan Load Balancer Jaringan proxy internal regional dengan backend NEG hibrida
Menyiapkan Load Balancer Jaringan proxy internal regional dengan backend NEG internet