Ringkasan Load Balancer Jaringan proxy eksternal

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

Network Load Balancer proxy eksternal adalah load balancer proxy terbalik yang mendistribusikan traffic TCP yang berasal dari internet ke instance virtual machine (VM) di jaringan Virtual Private Cloud (VPC) Anda.Trusted Cloud Saat menggunakan Load Balancer Jaringan proxy eksternal, traffic TCPyang masuk dihentikan di load balancer. Koneksi baru kemudian meneruskan traffic ke backend terdekat yang tersedia.

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

Load balancer ini tersedia untuk Anda dalam mode regional, dan selanjutnya disebut sebagai Load Balancer Jaringan proxy eksternal regional. Load balancer diimplementasikan sebagai layanan terkelola berdasarkan proxy Envoy open source. Mode regional memastikan bahwa semua klien dan backend berada di region tertentu. Gunakan load balancer ini jika Anda ingin menayangkan konten hanya dari satu geolokasi (misalnya, untuk mematuhi peraturan kepatuhan).

Arsitektur

Diagram berikut menunjukkan komponen Load Balancer Jaringan proxy eksternal.

Regional

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

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

Berikut adalah komponen Load Balancer Jaringan proxy eksternal.

Subnet khusus proxy

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

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

Poin yang perlu diingat:

  • Subnet khusus proxy hanya digunakan untuk proxy Envoy, bukan backend Anda.
  • Alamat IP load balancer tidak berada di subnet khusus proxy. Alamat IP load balancer ditentukan oleh aturan penerusan terkelola eksternalnya.

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

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

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

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

Mode load balancer Network Service Tier Aturan penerusan, alamat IP, dan skema load balancing Merutekan dari internet ke frontend load balancer
Load Balancer Jaringan proxy eksternal regional Paket Premium

Aturan penerusan eksternal regional

Alamat IP eksternal regional

Skema load balancing: EXTERNAL_MANAGED

 Permintaan yang dirutekan ke proxy Envoy di region yang sama dengan load balancer.

Aturan penerusan dan jaringan VPC

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

Mode load balancer Asosiasi jaringan VPC
Load Balancer Jaringan proxy eksternal regional

Jaringan VPC aturan penerusan adalah jaringan tempat subnet khusus proxy telah dibuat. Anda menentukan jaringan saat membuat aturan penerusan.

Proxy target

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

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

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

Mode load balancer Network Service Tier Proxy target
Load Balancer Jaringan proxy eksternal regional Paket Premium dan Standar regionTargetTcpProxies

Layanan backend

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

Setiap load balancer memiliki satu resource layanan backend yang menentukan health check yang akan dilakukan untuk backend yang tersedia.

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

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

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

Mode load balancer Backend yang didukung pada layanan backend
Grup instance NEG Zona NEG Internet NEG Serverless NEG Hybrid GKE
Load Balancer Jaringan proxy eksternal regional Endpoint jenis GCE_VM_IP_PORT Khusus NEG regional

Backend dan jaringan VPC

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

  • 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, atau lampiran VLAN Cloud Interconnect.

    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.

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

Protokol untuk berkomunikasi dengan backend

Saat mengonfigurasi layanan backend untuk Load Balancer Jaringan proxy eksternal, Anda menetapkan protokol yang digunakan layanan backend untuk berkomunikasi dengan backend. Load balancer hanya menggunakan protokol yang Anda tentukan, dan tidak mencoba menegosiasikan koneksi dengan protokol lain. Load Balancer Jaringan proxy eksternal hanya mendukung TCP untuk berkomunikasi dengan backend.

Aturan firewall

Aturan firewall berikut diperlukan:

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

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

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

Port untuk aturan firewall ini harus dikonfigurasi sebagai berikut:

  • Izinkan traffic ke port tujuan untuk health check setiap layanan backend.
  • Untuk backend grup instance: tentukan port yang akan dikonfigurasi dengan 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 zonal GCE_VM_IP_PORT NEG: izinkan traffic ke nomor port endpoint.

Alamat IP sumber

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

Untuk Load Balancer Jaringan proxy eksternal regional:

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

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

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

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

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

Port yang terbuka

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

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

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

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

    GFE menerapkan fitur keamanan seperti Google Cloud Armor. Dengan Cloud Armor Standard, GFE memberikan perlindungan yang selalu aktif dari serangan DDoS berbasis protokol dan volumetrik serta serangan bertubi-tubi menggunakan SYN. Perlindungan ini tersedia meskipun Anda belum secara eksplisit mengonfigurasi Cloud Armor. Anda hanya dikenai biaya jika mengonfigurasi kebijakan keamanan atau jika Anda mendaftar ke Managed Protection Plus.

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

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

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

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

Arsitektur VPC Bersama

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

Alamat IP Aturan penerusan Proxy target Komponen backend
Alamat IP eksternal harus ditentukan dalam project yang sama dengan load balancer. Aturan penerusan eksternal harus ditentukan dalam project yang sama dengan instance backend (project layanan). Target TCP harus ditentukan dalam project yang sama dengan instance backend.

Untuk Load Balancer Jaringan proxy eksternal regional, VM backend biasanya berada di project layanan. Layanan backend dan health check regional harus ditentukan dalam project layanan tersebut.

Distribusi traffic

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

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

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

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

Load Balancer Jaringan proxy eksternal regional

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

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

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

Untuk informasi selengkapnya, lihat referensi berikut:

Afinitas sesi

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

Load Balancer Jaringan proxy eksternal menawarkan jenis afinitas sesi berikut:

  • Tidak ada

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

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

    Afinitas sesi NONE adalah nilai default.

  • Afinitas IP klien

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

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

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

Perhatikan hal-hal berikut saat mengonfigurasi afinitas sesi:

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

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

Kehilangan afinitas sesi

Semua opsi afinitas sesi memerlukan hal berikut:

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

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

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

    • Menambahkan instance atau endpoint baru:

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

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

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

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

    • Setiap instance atau endpoint lulus health check-nya, bertransisi dari tidak responsif menjadi responsif.
    • Instance atau endpoint apa pun gagal dalam health check-nya, yang bertransisi dari responsif menjadi tidak responsif atau waktu tunggu habis.

Failover

Failover untuk Load Balancer Jaringan proxy eksternal berfungsi sebagai berikut:

  • Jika backend menjadi tidak responsif, traffic akan otomatis dialihkan ke backend yang responsif dalam region yang sama.
  • Jika semua backend tidak responsif, load balancer akan menghapus traffic.

Load balancing untuk aplikasi GKE

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

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

Batasan

  • Anda tidak dapat membuat Load Balancer Jaringan proxy eksternal regional di Paket Premium menggunakan Trusted Cloud konsol. Gunakan gcloud CLI atau API.

  • Trusted Cloud tidak memberikan jaminan apa pun tentang masa aktif koneksi TCP saat Anda menggunakan Load Balancer Jaringan proxy eksternal. Klien harus tahan terhadap koneksi yang terputus, baik karena masalah internet yang lebih luas maupun karena memulai ulang proxy yang mengelola koneksi secara terjadwal.

Langkah berikutnya