Ringkasan grup endpoint jaringan internet

Cloud Load Balancing mendukung traffic proxy ke backend eksternal di luar Google Cloud. Untuk menentukan backend eksternal untuk load balancer, Anda menggunakan resource yang disebut grup endpoint jaringan (NEG) internet.

Anda dapat menggunakan jenis deployment ini saat ingin menayangkan konten dari backend eksternal, tetapi Anda ingin load balancer Google Cloud menjadi frontend. Hal ini memungkinkan Anda melakukan hal berikut:

• Gunakan infrastruktur Google Edge untuk mengakhiri koneksi pengguna Anda.
• Arahkan koneksi ke backend eksternal Anda.
• Kirimkan traffic ke endpoint publik Anda di seluruh backbone pribadi Google, yang meningkatkan keandalan dan dapat mengurangi latensi antara klien dan server.
• Dengan load balancer global, Anda dapat menggunakan Cloud CDN untuk menyimpan konten ke dalam cache untuk backend eksternal Anda.

Gambar 1 menunjukkan Load Balancer Aplikasi eksternal dengan beberapa jenis backend, salah satunya adalah backend eksternal yang dikonfigurasi dengan NEG internet.

Backend NEG internet didukung dengan berbagai load balancer global dan regional. Bergantung pada load balancer (global atau regional), dukungan NEG internet berbeda dalam hal DNS, health check, jumlah endpoint yang tersedia, dan perilaku perutean traffic.

Bagian berikut menjelaskan cara backend eksternal digunakan dengan Cloud Load Balancing. Jika Anda ingin menggunakan backend eksternal dengan Cloud Service Mesh, lihat Cloud Service Mesh dengan grup endpoint jaringan internet.

Terminologi

Istilah berikut terkadang digunakan secara bergantian karena memiliki arti yang sama atau mirip:

• backend eksternal: Backend yang berada di luar Google Cloud dan dapat dijangkau di internet. Endpoint di NEG internet.
• origin kustom: Sama seperti backend eksternal. Di CDN, asal adalah istilah standar industri untuk instance backend yang menyajikan konten web.
• Grup endpoint jaringan (NEG) internet: Resource API yang Anda gunakan untuk menentukan backend eksternal. Google Cloud
• endpoint eksternal: Sama seperti backend eksternal.

Dokumen ini menggunakan istilah backend eksternal kecuali saat merujuk ke resource API NEG internet.

Komponen load balancer

Bagian ini menjelaskan arsitektur load balancing dan resource yang diperlukan untuk mengonfigurasi load balancer dengan backend eksternal. Load balancer memerlukan konfigurasi khusus hanya untuk layanan backend. Konfigurasi frontend sama dengan load balancer lainnya.

Gambar berikut menunjukkan Google Cloud resource yang diperlukan untuk menyiapkan load balancer dengan backend eksternal.

Anda hanya dapat menggunakan NEG internet di tingkat layanan jaringan Premium.

Konfigurasi frontend

Tidak diperlukan konfigurasi frontend khusus untuk membuat load balancer dengan backend NEG internet. Aturan penerusan digunakan untuk merutekan traffic menurut alamat IP, port, dan protokol ke proxy target. Kemudian, target proxy menghentikan koneksi dari klien. Selain itu, load balancer berbasis Envoy memerlukan subnet khusus proxy.

Load Balancer Aplikasi juga menggunakan peta URL untuk menyiapkan perutean permintaan berbasis URL ke layanan backend yang sesuai.

Untuk mengetahui detail selengkapnya tentang setiap komponen ini, lihat bagian arsitektur dari load balancer masing-masing:

• Ringkasan Load Balancer Aplikasi Eksternal
• Ringkasan Load Balancer Aplikasi Internal
• Ringkasan Load Balancer Jaringan proxy eksternal
• Ringkasan Load Balancer Jaringan proxy internal

NEG Internet

NEG internet adalah resource yang digunakan untuk menentukan backend eksternal untuk load balancer. Ada dua jenis NEG internet: NEG internet global dan NEG internet regional. Perbedaannya terletak pada cakupan (global versus regional) dan perilaku. Backend eksternal yang dirujuk oleh NEG internet global harus dapat dijangkau secara eksklusif melalui internet; backend tersebut tidak dapat dijangkau melalui Cloud VPN atau Cloud Interconnect. Jika backend eksternal mereferensikan API atau layanan Google, layanan harus dapat dijangkau melalui port TCP 80 atau 443 menggunakan protokol HTTP, HTTPS, atau HTTP/2.

Ada dua cara untuk mengonfigurasi endpoint eksternal yang dirujuk oleh NEG: INTERNET_FQDN_PORT atau INTERNET_IP_PORT. Jika format INTERNET_IP_PORT dipilih, hanya alamat IP yang dapat dirutekan ke internet publik yang dapat digunakan; jika format INTERNET_FQDN_PORT dipilih, FQDN dapat diselesaikan ke alamat IP yang dapat dirutekan ke internet publik atau ke alamat IP pribadi, bergantung pada cakupan endpoint: regional atau global.

NEG internet global didukung oleh teknologi Google Front End (GFE). Load balancer menggunakan kumpulan tetap alamat IP tetap untuk traffic keluar ke semua klien. NEG ini hanya mendukung satu endpoint per NEG dan satu NEG internet per layanan backend.

Tabel berikut menjelaskan cara berbagai load balancer mendukung NEG internet global.

Load balancer	Jenis endpoint	Definisi endpoint	Cakupan	Health check
Load Balancer Aplikasi eksternal global Load Balancer Aplikasi Klasik	INTERNET_FQDN_PORT	Nama domain yang sepenuhnya memenuhi syarat dan dapat di-resolve secara publik, serta port opsional. Misalnya, backend.example.com:443†. Nama domain harus dapat diselesaikan oleh infrastruktur DNS publik Google. Hanya satu endpoint per NEG yang diizinkan.	Global	Tidak didukung
	INTERNET_IP_PORT	Alamat IP yang dapat dirutekan secara publik dan port opsional. Misalnya, 8.8.8.8:4431. Alamat IP tidak boleh berupa alamat RFC 1918. Hanya satu endpoint per NEG yang diizinkan.

NEG internet regional didukung oleh proxy Envoy terkelola. Setiap NEG dapat memiliki beberapa endpoint, dan layanan backend dapat mencakup beberapa NEG internet.

Untuk traffic keluar, Anda dapat mengonfigurasi gateway Cloud NAT untuk menetapkan alamat IP sumber. Atau, Anda dapat merutekan traffic menggunakan rute yang dipelajari dalam jaringan VPC. Meskipun Cloud NAT tidak diperlukan untuk metode perutean ini, Cloud NAT didukung.

Tabel berikut menjelaskan cara berbagai load balancer mendukung NEG internet regional.

Load balancer	Jenis endpoint	Definisi endpoint	Cakupan	Health check
Load Balancer Aplikasi eksternal regional Load Balancer Aplikasi internal regional Load Balancer Jaringan proxy eksternal regional Load Balancer Jaringan proxy internal regional	INTERNET_FQDN_PORT	Nama domain yang sepenuhnya memenuhi syarat yang dapat di-resolve secara publik atau pribadi dan port opsional. Misalnya, backend.example.com:443*. Proses resolusi nama domain mengikuti proses urutan resolusi nama Cloud DNS. Maksimum 256 endpoint per NEG yang diizinkan.	Regional	Pemeriksaan kesehatan terdistribusi Envoy
	INTERNET_IP_PORT	Hanya alamat IP yang dapat dirutekan secara publik dan port opsional. Misalnya, 8.8.8.8:4432. Alamat IP tidak boleh berupa alamat RFC 1918. Maksimum 256 endpoint per NEG yang diizinkan.

Resolusi DNS untuk endpoint INTERNET_FQDN_PORT regional

Jika domain Anda dapat diakses melalui internet, tidak ada konfigurasi lain yang diperlukan untuk menyiapkan DNS. Namun, jika Anda me-resolve FQDN pribadi, Anda harus mengonfigurasi Cloud DNS untuk memfasilitasi resolusi DNS. Nama harus dihosting di Cloud DNS atau dapat di-resolve menggunakan penerusan DNS dari Cloud DNS ke DNS lokal atau peering DNS jika mereferensikan zona DNS Pribadi di jaringan VPC lain.

Mulai dengan membuat zona Cloud DNS untuk menghosting data DNS di project Anda. Kemudian, tambahkan data DNS ke domain tersebut. Untuk mengetahui langkah-langkah konfigurasi tertentu, lihat dokumentasi Cloud DNS. Urutan resolusi Cloud DNS dijelaskan di Urutan resolusi nama.

Jika Anda menggunakan VPC Bersama, perhatikan persyaratan jaringan tertentu. Anda juga dapat menggunakan fitur Cloud DNS lainnya, seperti zona penerusan, untuk mengambil data dari server DNS lokal.

Resolusi alamat IP untuk endpoint INTERNET_FQDN_PORT global

Jika endpoint INTERNET_FQDN_PORT mengarah ke data DNS yang menampilkan beberapa alamat IP, alamat IP akan di-resolve dengan cara berikut:

• Load balancer menggunakan resolver DNS di region Google Cloud yang paling dekat dengan kliennya di internet. Jika data DNS untuk endpoint INTERNET_FQDN_PORT Anda menampilkan alamat IP yang berbeda berdasarkan lokasi klien, pastikan setiap alamat IP tersebut dapat dijangkau oleh load balancer.

• Load balancer mencoba terhubung ke alamat IP pertama dalam respons DNS. Jika alamat IP tersebut tidak dapat dijangkau, load balancer akan menampilkan respons HTTP 502 (Bad Gateway). Hal ini berlaku meskipun alamat IP lain dari respons DNS tersedia.

Untuk mengetahui informasi selengkapnya tentang rentang IP dan lokasi yang digunakan oleh infrastruktur resolver DNS Google, lihat dokumentasi DNS publik Google. Nama yang tidak dapat diselesaikan oleh sistem DNS publik tidak dapat digunakan sebagai backend eksternal.

Resolusi alamat IP untuk endpoint INTERNET_FQDN_PORT regional

NEG internet regional mendukung resolusi nama domain menggunakan Cloud DNS dan DNS publik Google.

• Untuk resolusi DNS Publik, Cloud DNS meneruskan traffic ke server DNS publik Google.
• Untuk Cloud DNS, nama domain harus salah satu dari berikut ini:
  • Dihosting di Cloud DNS
  • Dapat di-resolve menggunakan penerusan DNS dari Cloud DNS ke server DNS lokal
  • Dapat diselesaikan menggunakan peering DNS jika Anda mereferensikan zona DNS pribadi di jaringan VPC lain.

Jika server DNS menampilkan beberapa alamat IP, Envoy akan menyeimbangkan beban traffic di antara alamat IP yang ditampilkan berdasarkan algoritma penyeimbangan beban yang dikonfigurasi (round robin, permintaan paling sedikit, dan sebagainya). Daftar endpoint diperbarui secara berkala berdasarkan TTL DNS. Anda dapat mengonfigurasi kebijakan coba lagi untuk memaksa Envoy mencoba terhubung ke alamat IP lain jika salah satu alamat IP gagal.

Layanan backend

Layanan backend memberikan informasi konfigurasi ke load balancer. Load balancer menggunakan informasi dalam layanan backend untuk mengarahkan traffic masuk ke satu atau beberapa backend yang terpasang.

Untuk menyiapkan load balancer dengan backend eksternal, Anda mengonfigurasi layanan backend dengan backend NEG internet. Saat Anda menambahkan NEG internet ke layanan backend, pertimbangan berikut berlaku, bergantung pada cakupan NEG:

• Layanan backend juga tidak dapat menggunakan jenis backend lain (seperti NEG zonal atau grup instance) sebagai backend.

• Jumlah NEG per layanan backend

  • NEG Global. Anda hanya dapat menambahkan satu backend NEG internet ke layanan backend.
  • NEG regional. Anda dapat menambahkan hingga 50 NEG internet ke layanan backend yang sama.

• Jumlah endpoint per NEG

  • NEG Global. Anda hanya dapat menambahkan satu endpoint ke NEG internet.

    Karena hanya satu endpoint yang diizinkan di setiap NEG internet global, load balancing tidak benar-benar dilakukan. Load balancer hanya berfungsi sebagai frontend, dan memproksi traffic ke backend eksternal yang ditentukan. Artinya, Anda tidak dapat menggunakan mode load balancing apa pun, seperti kecepatan, koneksi, atau pemanfaatan.

  • NEG regional. Anda dapat menambahkan hingga 256 endpoint per NEG ke layanan backend yang sama.

  NEG regional tidak mendukung mode load balancing, seperti rasio, koneksi, atau pemakaian. Semua endpoint dari semua NEG yang terlampir ke layanan backend dikumpulkan ke dalam satu grup. Load balancing traffic di antara kumpulan endpoint ini ditangani menggunakan algoritma load balancing Envoy. Untuk algoritma kebijakan load balancing yang didukung, lihat localityLbPolicy dalam dokumentasi API layanan backend regional.

• Health check

  • NEG Global. Layanan backend tidak dapat mereferensikan pemeriksaan kesehatan.
  • NEG regional. Load balancer menggunakan health check Envoy terdistribusi.

• Skema load balancing layanan backend harus cocok dengan skema yang diperlukan oleh load balancer yang Anda deploy. Untuk daftar lengkapnya, lihat Layanan backend.

• Protokol layanan backend harus berupa salah satu dari HTTP, HTTPS, atau HTTP2.

  Sebaiknya Anda menggunakan HTTPS atau HTTP/2 sebagai protokol saat mengonfigurasi layanan backend dengan NEG internet agar komunikasi antara load balancer dan backend dienkripsi dan diautentikasi saat transit di internet publik.

  Selain itu, saat menggunakan HTTPS atau HTTP/2 sebagai protokol backend, pastikan Anda menggunakan endpoint INTERNET_FQDN_PORT untuk membuat backend eksternal. Hal ini memiliki dua keunggulan:

  • Kebijakan ini memastikan bahwa load balancer memvalidasi sertifikat server SSL yang ditampilkan oleh backend eksternal dan memverifikasi bahwa informasi berikut benar:

    • Sertifikat ditandatangani oleh certificate authority (CA) yang terkenal.
    • Masa berlaku sertifikat belum berakhir.
    • Tanda tangan sertifikat valid.
    • FQDN yang dikonfigurasi cocok dengan salah satu Nama Alternatif Subjek (SAN) dalam sertifikat.

    Jika Anda membuat backend eksternal menggunakan endpoint INTERNET_IP_PORT, validasi sertifikat server SSL tidak dilakukan.

  • Ekstensi SSL Server Name Indication (SNI) hanya didukung dengan endpoint INTERNET_FQDN_PORT. FQDN yang dikonfigurasi akan dikirim SNI di client hello selama handshake SSL antara load balancer dan endpoint eksternal. SNI tidak dikirim saat Anda menggunakan endpoint INTERNET_IP_PORT karena literal alamat IP tidak diizinkan di kolom HostName payload SNI.

Health check

Konfigurasi health check Anda bervariasi, bergantung pada jenis load balancer:

• Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik. Layanan backend dengan NEG internet global tidak mendukung health check.

  Jika backend eksternal Anda tidak dapat dijangkau atau jika nama host (FQDN) yang dikonfigurasi tidak dapat diselesaikan, load balancer akan menampilkan respons HTTP 502 (Bad Gateway) kepada kliennya.

• Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, Load Balancer Jaringan proxy eksternal regional, dan Load Balancer Jaringan proxy internal regional. Pemeriksaan kondisi bersifat opsional. Pemeriksaan health check untuk load balancer ini berasal dari subnet khusus proxy dan kemudian diterjemahkan NAT (dengan menggunakan Cloud NAT) ke alamat IP yang telah dicadangkan sebelumnya atau alamat IP NAT yang dialokasikan secara otomatis. Untuk mengetahui detailnya, lihat NEG regional: Menggunakan gateway Cloud NAT.

  Health check Envoy terdistribusi dibuat dengan menggunakan proses Google Cloud konsol, gcloud CLI, dan API yang sama seperti health check terpusat. Tidak diperlukan konfigurasi lain.

  Poin yang perlu diperhatikan:

  • Health check gRPC tidak didukung.
  • Pemeriksaan kesehatan dengan protokol PROXY v1 yang diaktifkan tidak didukung.

  • Karena bidang data Envoy menangani pemeriksaan kondisi, Anda tidak dapat menggunakan konsolGoogle Cloud , API, atau gcloud CLI untuk memeriksa status kondisi endpoint eksternal ini. Untuk NEG hybrid dengan load balancer berbasis Envoy, Google Cloud konsol menampilkan status health check sebagai N/A. Hal ini sudah diperkirakan.

  • Setiap proxy Envoy yang ditetapkan ke subnet khusus proxy di region dalam jaringan VPC memulai health check secara independen. Oleh karena itu, Anda mungkin melihat peningkatan traffic jaringan karena pemeriksaan kondisi. Peningkatan ini bergantung pada jumlah proxy Envoy yang ditetapkan ke jaringan VPC Anda di suatu region, jumlah traffic yang diterima oleh proxy ini, dan jumlah endpoint yang perlu diperiksa kondisinya oleh setiap proxy Envoy. Dalam skenario terburuk, traffic jaringan karena pemeriksaan health check meningkat pada tingkat kuadratik (O(n^2)).

  • Log health check untuk health check Envoy terdistribusi tidak menyertakan status kesehatan yang mendetail. Untuk mengetahui detail tentang apa yang dicatat, lihat Logging health check. Untuk memecahkan masalah konektivitas lebih lanjut dari proxy Envoy ke endpoint NEG Anda, Anda juga harus memeriksa log load balancer masing-masing.

    • Logging Load Balancer Aplikasi eksternal regional
    • Logging Load Balancer Aplikasi Internal
    • Logging Load Balancer Jaringan proxy

Aktifkan backend eksternal untuk menerima permintaan

Konfigurasi backend eksternal Anda untuk mengizinkan traffic dari Google Cloud.

Prosedur ini bergantung pada cakupan NEG: global atau regional.

NEG Global: Mengizinkan alamat IP keluar Google default

Jika menggunakan NEG internet global, Anda harus menambahkan rentang alamat IP yang digunakan Google untuk mengirim permintaan ke backend eksternal ke daftar yang diizinkan. Untuk mencari alamat IP yang akan ditambahkan ke daftar yang diizinkan, kueri data TXT DNS _cloud-eoips.googleusercontent.com menggunakan alat seperti dig atau nslookup.

Untuk contohnya, lihat Mengizinkan backend eksternal menerima traffic dari Google Cloud.

NEG regional: Menggunakan gateway Cloud NAT

Jika menggunakan NEG internet regional, Anda harus menyiapkan gateway Cloud NAT terlebih dahulu untuk mengalokasikan serangkaian rentang alamat IP dari tempat Google Cloud traffic harus berasal.

Endpoint gateway harus berjenis ENDPOINT_TYPE_MANAGED_PROXY_LB.

Gateway Cloud NAT dapat dikonfigurasi untuk mengalokasikan alamat IP eksternal secara otomatis berdasarkan permintaan atau menggunakan serangkaian alamat IP eksternal yang telah dipesan secara manual.

• Alamat IP yang dialokasikan secara otomatis

  Gunakan alamat IP yang dialokasikan secara otomatis jika lingkungan backend eksternal Anda tidak mengharuskan Anda menambahkan alamat IP tertentu yang dapat mengirim traffic ke backend eksternal ke daftar yang diizinkan. Google Cloud

• Alamat IP yang dialokasikan secara manual

  Gunakan alamat IP yang dialokasikan secara manual hanya jika lingkungan backend eksternal Anda mengharuskan Anda menambahkan alamat IP tertentu ke daftar yang diizinkan. Google Cloud Karena setiap Envoy yang ditetapkan ke subnet proxy Anda menggunakan seluruh alamat IP, pastikan kumpulan alamat IP yang dicadangkan cukup besar untuk mengakomodasi semua Envoy.

  Jika Anda mengalami masalah konektivitas dalam skala besar, periksa apakah Anda telah mencapai batas Cloud NAT. Secara default, Anda dibatasi hingga 50 alamat IP NAT yang dialokasikan secara manual per gateway.

Alokasi port dinamis didukung untuk NEG internet regional. Alamat IP dapat dibagikan oleh proxy, sehingga dapat dimanfaatkan sepenuhnya.

Konfigurasi Cloud NAT ini berlaku untuk seluruh subnet khusus proxy. Traffic internet yang terkait dengan semua load balancer berbasis Envoy regional di region tersebut menggunakan gateway NAT yang sama.

Penggunaan Cloud NAT menimbulkan biaya untuk traffic pengguna dan traffic health check. Untuk mengetahui detail tentang cara kerja harga NEG internet regional, lihat Harga NEG internet regional.

Ada batasan tertentu untuk gateway NAT yang dikonfigurasi di subnet khusus proxy:

• Hanya terjemahan NAT one-to-one yang dilakukan. Berbagi alamat IP tidak didukung.
• Logging dan pemantauan tidak didukung. Artinya, tanda --enable-logging dan --log-filter tidak didukung.

Mengautentikasi permintaan ke backend eksternal

Bagian ini hanya berlaku untuk Load Balancer Aplikasi.

Untuk mengautentikasi permintaan yang dikirim ke backend eksternal, Anda dapat melakukan salah satu hal berikut:

• Tetapkan header kustom untuk menunjukkan bahwa permintaan berasal dari load balancer Google Cloud dengan menggunakan header permintaan kustom. Misalnya, Anda dapat menggunakan 16 byte atau lebih yang acak secara kriptografis sebagai kunci bersama.

  Penerapan transformasi header kustom bergantung pada jenis load balancer yang Anda gunakan:

  • Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik. Transformasi header kustom dapat dikonfigurasi di layanan backend atau peta URL.

    Misalnya, Anda dapat mengonfigurasi backend eksternal agar mengharapkan nilai tertentu untuk header Host permintaan HTTP, dan Anda dapat mengonfigurasi load balancer untuk menyetel header Host ke nilai yang diharapkan tersebut. Jika Anda tidak mengonfigurasi header permintaan kustom, load balancer akan mempertahankan header yang digunakan klien untuk terhubung ke load balancer dan menyertakan header yang sama dalam responsnya. Namun, perhatikan bahwa pengubahan header Host tidak didukung di peta URL.

    Ada batasan tambahan terkait konfigurasi header Host. Untuk mengetahui detailnya, lihat Membuat header kustom di layanan backend. Untuk contoh tertentu, lihat Menyiapkan Load Balancer Aplikasi eksternal global dengan backend eksternal.

  • Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi internal regional. Transformasi header kustom hanya dapat dikonfigurasi di peta URL.

    Untuk load balancer berbasis Envoy ini, Host dan authority adalah kata kunci khusus yang dicadangkan oleh Google Cloud. Anda tidak dapat mengubah header ini untuk load balancer ini. Sebagai gantinya, sebaiknya buat header kustom lainnya (misalnya, MyHost) agar Anda tidak mengganggu nama header yang dicadangkan.

• Aktifkan IAP dan verifikasi bahwa JWT bertanda tangan di header permintaan ditandatangani oleh Google, dan bahwa klaim aud (audiens) berisi nomor project tempat load balancer Anda ditentukan.

  Perhatikan hal berikut:

  • IAP tidak kompatibel dengan Cloud CDN.
  • IAP tidak didukung dengan Load Balancer Jaringan proxy (internal dan eksternal).

• Aktifkan autentikasi asal pribadi, yang memberikan akses jangka panjang ke Load Balancer Aplikasi eksternal ke bucket Amazon Simple Storage Service (Amazon S3) pribadi atau penyimpanan objek kompatibel lainnya. Cloud CDN (dan oleh karena itu, autentikasi origin pribadi) tidak didukung dengan Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi internal regional.

Log

Permintaan yang di-proxy ke backend eksternal dicatat ke Cloud Logging dengan cara yang sama seperti permintaan untuk backend lainnya dicatat.

Untuk informasi selengkapnya, lihat referensi berikut:

• Logging dan pemantauan Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik

• Logging Load Balancer Aplikasi eksternal regional
• Logging Load Balancer Aplikasi internal regional
• Logging Load Balancer Jaringan proxy

Jika Anda mengaktifkan Cloud CDN untuk Load Balancer Aplikasi eksternal menggunakan backend eksternal, hit cache juga dicatat.

Pemrosesan header dengan backend eksternal

Load balancer yang berbeda dapat menangani pemrosesan header dengan cara yang berbeda saat membuat proxy permintaan ke backend eksternal. Tinjau informasi berikut untuk memahami cara jenis load balancer Anda memproses header HTTP.

Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik

Saat memproksi permintaan ke backend eksternal, Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik menyesuaikan header HTTP dengan cara berikut:

• Beberapa header digabungkan. Jika ada beberapa instance dari kunci header yang sama (misalnya, Via), load balancer akan menggabungkan nilainya menjadi satu daftar yang dipisahkan koma untuk satu kunci header. Hanya header yang nilainya dapat direpresentasikan sebagai daftar yang dipisahkan koma yang digabungkan. Header lainnya, seperti Set-Cookie, tidak pernah digabungkan.

• Header menggunakan huruf kapital yang tepat jika protokol layanan backend adalah HTTP atau HTTPS:

  • Huruf pertama kunci header dan setiap huruf setelah tanda hubung (-) dikapitalisasi untuk mempertahankan kompatibilitas dengan klien HTTP/1.1. Misalnya, user-agent diubah menjadi User-Agent, dan content-encoding diubah menjadi Content-Encoding.

  • Header tertentu, seperti Accept-CH (client hints), dikonversi agar sesuai dengan representasi huruf campuran standar.

• Beberapa header ditambahkan, atau nilai ditambahkan ke header tersebut. Load Balancer Aplikasi eksternal selalu menambahkan atau mengubah header tertentu seperti Via dan X-Forwarded-For.

Load Balancer Aplikasi eksternal regional dan Load Balancer Aplikasi internal regional

Tidak ada pemrosesan header khusus untuk load balancer berbasis Envoy yang menggunakan NEG internet. Untuk mempelajari cara Envoy biasanya memproses header, lihat Manipulasi header HTTP.

Batasan

• Tinjau bagian layanan backend untuk mengetahui batasan yang terkait dengan mengonfigurasi NEG internet sebagai backend.
• Saat Anda mengubah load balancer untuk mengubah backend dari NEG internet ke jenis backend lain, atau mengubah backend dari jenis backend lain ke NEG internet, aplikasi Anda akan mengalami periode nonaktif sementara selama sekitar 30-90 detik. Misalnya, selama periode nonaktif ini, klien yang mengirim permintaan ke Load Balancer Aplikasi eksternal global akan melihat error 502 dengan kode error failed_to_connect_to_backend. Hal ini normal.

• Fitur pengelolaan traffic lanjutan berikut tidak didukung dengan backend NEG internet global:
  • Meminta pencerminan
  • Kebijakan coba lagi
  • Kebijakan traffic (termasuk kebijakan lokalitas load balancing, afinitas sesi, dan deteksi pencilan)

• Tinjau bagian gateway Cloud NAT untuk mengetahui batasan yang terkait dengan gateway NAT yang dikonfigurasi di subnet khusus proxy.

Kuota dan batas

Untuk mengetahui informasi tentang kuota dan batas, lihat tabel kuota backend NEG dan tabel kuota Endpoint per NEG.

Harga

Traffic keluar ke endpoint NEG internet eksternal dikenai biaya sesuai tarif traffic keluar internet untuk jaringan Tingkat Premium. Sumber didasarkan pada lokasi klien, dan tujuan didasarkan pada lokasi endpoint publik Anda.

Jika Anda mengonfigurasi gateway Cloud NAT untuk memetakan subnet khusus proxy load balancer berbasis Envoy regional, Anda akan dikenai biaya Cloud NAT. Gateway Cloud NAT yang dialokasikan untuk load balancer akan dikenai biaya per jam yang setara dengan jaringan yang memiliki lebih dari 32 instance VM. Untuk mengetahui detailnya, lihat Harga Cloud NAT.

Untuk mengetahui informasi selengkapnya, lihat harga Cloud Load Balancing.

Langkah berikutnya

• Menyiapkan Load Balancer Aplikasi eksternal global dengan NEG internet
• Menyiapkan Load Balancer Aplikasi klasik dengan NEG internet
• Menyiapkan Cloud CDN untuk Load Balancer Aplikasi eksternal dengan backend eksternal
• Ringkasan Cloud Service Mesh dengan grup endpoint jaringan internet

• Menyiapkan Load Balancer Aplikasi eksternal regional dengan NEG internet
• Menyiapkan Load Balancer Jaringan proxy eksternal regional dengan NEG internet