Ringkasan grup endpoint jaringan internet

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

Anda dapat menggunakan jenis deployment ini jika 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 menghentikan koneksi pengguna Anda.
• Arahkan koneksi ke backend eksternal Anda.
• Kirim traffic ke endpoint publik Anda melalui 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.

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

Gambar 1. Grup endpoint jaringan internet dalam load balancing (klik untuk memperbesar).

Backend NEG internet didukung dengan berbagai load balancer global dan regional. Bergantung pada load balancer Anda (global atau regional), dukungan NEG internet berbeda sehubungan dengan 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.

Catatan: Cloud Load Balancing juga mendukung koneksi ke backend di lokasi atau di lingkungan cloud lain di luar Google Cloud menggunakan NEG hybrid. Namun, koneksi ke endpoint NEG campuran menggunakan konektivitas campuran. Sebaliknya, koneksi ke endpoint NEG internet menggunakan internet sekaligus mempertahankan traffic Anda di backbone berperforma tinggi Google untuk jarak terjauh, sehingga mengurangi latensi dan meningkatkan throughput.

Terminologi

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

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

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

Komponen load balancer

Bagian ini menjelaskan arsitektur dan resource load balancing 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 resource Google Cloud yang diperlukan untuk menyiapkan load balancer dengan backend eksternal.

Global eksternal

Gambar ini menunjukkan resource Google Cloud yang diperlukan untuk menyiapkan Load Balancer Aplikasi eksternal global dengan backend eksternal.

Load Balancer Aplikasi eksternal global dengan backend eksternal (klik untuk memperbesar).

Eksternal regional

Gambar ini menunjukkan resource Google Cloud yang diperlukan untuk menyiapkan Load Balancer Aplikasi eksternal regional dengan backend eksternal.

Load Balancer Aplikasi eksternal regional dengan backend eksternal (klik untuk memperbesar).

Internal regional

Gambar ini menunjukkan resource Google Cloud yang diperlukan untuk menyiapkan Load Balancer Aplikasi internal regional dengan backend eksternal.

Load Balancer Aplikasi internal regional dengan backend eksternal (klik untuk memperbesar).

Gambar ini menunjukkan resource Google Cloud yang diperlukan untuk menyiapkan Load Balancer Jaringan proxy internal regional dengan backend eksternal.

Load Balancer Jaringan proxy internal regional dengan backend eksternal (klik untuk memperbesar).

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 berdasarkan alamat IP, port, dan protokol ke proxy target. Proxy target kemudian 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 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. Keduanya berbeda dalam cakupan (global versus regional) dan perilaku. Backend eksternal yang dirujuk oleh NEG internet global harus dapat dijangkau secara eksklusif melalui internet; backend tidak dapat dijangkau melalui Cloud VPN atau Cloud Interconnect. Jika backend eksternal mereferensikan API atau layanan Google, layanan tersebut 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 internet publik yang dapat dirutekan yang dapat digunakan; jika format INTERNET_FQDN_PORT dipilih, FQDN dapat di-resolve ke alamat IP internet publik yang dapat dirutekan atau ke alamat IP pribadi, bergantung pada cakupan endpoint: regional atau global.

NEG internet global didukung oleh teknologi Google Front End (GFE). Cluster ini menggunakan kumpulan alamat IP tetap untuk traffic keluar ke semua klien. NEG 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 balancers	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 di-resolve 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:443^1. Alamat IP tidak boleh berupa alamat RFC 1918. Hanya satu endpoint per NEG yang diizinkan.

^† Jika Anda tidak menentukan port saat menambahkan endpoint, port default NEG akan digunakan. Jika Anda tidak menentukan port default untuk NEG, port yang dikenal untuk protokol backend Anda akan digunakan (80 untuk HTTP dan 443 untuk HTTPS dan HTTP/2).

NEG internet regional didukung oleh proxy Envoy terkelola dan gateway Cloud NAT. NEG mendukung beberapa endpoint per NEG, dan beberapa NEG internet per layanan backend. Alamat IP yang digunakan untuk traffic keluar ke klien dapat dikonfigurasi menggunakan gateway Cloud NAT.

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

Load balancers	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 dan dapat di-resolve secara publik atau pribadi, serta 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	Health check terdistribusi Envoy
	INTERNET_IP_PORT	Hanya alamat IP yang dapat dirutekan secara publik dan port opsional. Misalnya, 8.8.8.8:443^2. Alamat IP tidak boleh berupa alamat RFC 1918. Maksimum 256 endpoint per NEG yang diizinkan.

^* Dengan NEG internet regional, Anda harus menentukan port. Anda dapat menentukan port default saat membuat NEG, atau menentukan port setiap kali menambahkan endpoint ke NEG, atau melakukan keduanya. Jika Anda tidak menentukan port saat menambahkan endpoint, port default NEG akan digunakan.

Resolusi DNS untuk endpoint INTERNET_FQDN_PORT regional

Jika domain Anda dapat di-resolve melalui internet, tidak diperlukan konfigurasi lain untuk menyiapkan DNS. Namun, jika me-resolve FQDN pribadi, Anda harus mengonfigurasi Cloud DNS untuk memfasilitasi resolusi DNS. Nama tersebut 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 dalamnya. 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 lain Cloud DNS, 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 502 (Bad Gateway) HTTP. Hal ini berlaku meskipun alamat IP lain dari respons DNS tersedia.

Untuk informasi selengkapnya tentang rentang dan lokasi IP yang digunakan oleh infrastruktur resolver DNS Google, lihat dokumentasi DNS publik Google. Nama yang tidak dapat di-resolve 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 berupa salah satu dari berikut:
  • Dihosting di Cloud DNS
  • Dapat di-resolve menggunakan penerusan DNS dari Cloud DNS ke server DNS lokal
  • Dapat di-resolve menggunakan peering DNS jika Anda mereferensikan zona DNS pribadi di jaringan VPC lain.

Jika server DNS menampilkan beberapa alamat IP, Envoy akan melakukan load balancing traffic di antara alamat IP yang ditampilkan berdasarkan algoritma load balancing yang dikonfigurasi (round robin, least request, dan sebagainya). Daftar endpoint diperbarui secara berkala berdasarkan TTL DNS. Anda dapat mengonfigurasi kebijakan percobaan ulang untuk memaksa Envoy mencoba terhubung ke alamat IP lain jika 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 balancer sebenarnya tidak dilakukan. Load balancer berfungsi sebagai frontend saja, dan mem-proxy traffic ke backend eksternal yang ditentukan. Artinya, Anda tidak dapat menggunakan mode load balancing apa pun, seperti kapasitas, koneksi, atau penggunaan.

  • 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 penggunaan. Semua endpoint dari semua NEG yang dilampirkan ke layanan backend digabungkan ke dalam satu grup. Traffic load balancing di antara kumpulan endpoint ini ditangani menggunakan algoritma load balancing Envoy. Untuk algoritma kebijakan load balancing yang didukung, lihat localityLbPolicy di dokumentasi API layanan backend regional.

• Health check

  • NEG Global. Layanan backend tidak dapat mereferensikan health check.
  • 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 mengetahui daftar lengkapnya, lihat Layanan backend.

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

  Sebaiknya gunakan HTTPS atau HTTP/2 sebagai protokol saat mengonfigurasi layanan backend dengan NEG internet sehingga komunikasi antara load balancer dan backend dienkripsi dan diautentikasi saat melalui 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 keuntungan:

  • Tindakan 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) terkenal.
    • Masa berlaku sertifikat masih ada.
    • 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 akan dilakukan.

  • Ekstensi Server Name Indication (SNI) SSL hanya didukung dengan endpoint INTERNET_FQDN_PORT. FQDN yang dikonfigurasi akan menerima 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 yang dikonfigurasi (FQDN) tidak dapat di-resolve, load balancer akan menampilkan respons 502 (Bad Gateway) HTTP 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 kesehatan bersifat opsional. Pemeriksaan health check untuk load balancer ini berasal dari subnet khusus proxy, lalu diterjemahkan NAT (dengan menggunakan Cloud NAT) ke alamat IP yang direservasi sebelumnya atau alamat IP NAT yang dialokasikan secara otomatis. Untuk mengetahui detailnya, lihat NEG Regional: Menggunakan gateway Cloud NAT.

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

  Poin yang perlu diperhatikan:

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

  • Karena bidang data Envoy menangani pemeriksaan status, Anda tidak dapat menggunakan Konsol Google Cloud, API, atau gcloud CLI untuk memeriksa status status endpoint eksternal ini. Untuk NEG campuran dengan load balancer berbasis Envoy, konsol Google Cloud 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 akan memulai pemeriksaan kesehatan 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 diperlukan setiap proxy Envoy untuk melakukan pemeriksaan kesehatan. Dalam skenario terburuk, traffic jaringan karena pemeriksaan kesehatan meningkat dengan kecepatan (O(n^2)) kuadrat.

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

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

Mengaktifkan backend eksternal untuk menerima permintaan

Konfigurasikan backend eksternal Anda untuk mengizinkan traffic dari Google Cloud.

Prosedur ini bergantung pada cakupan NEG: global atau regional.

NEG Global: Daftar IP keluar Google default yang diizinkan

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, buat kueri data TXT DNS _cloud-eoips.googleusercontent.com dengan 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 kumpulan rentang alamat IP tempat traffic Google Cloud berasal.

Penting: Gateway NAT melakukan terjemahan satu-ke-satu dari rentang subnet khusus proxy ke alamat IP eksternal. Setiap alamat IP eksternal yang ditetapkan NAT hanya tersedia untuk satu proxy Envoy. Alamat IP NAT tidak dibagikan di antara proxy. Alokasi port statis dan dinamis tidak didukung.

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 kumpulan alamat IP eksternal yang telah direservasi 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 Google Cloud tertentu yang dapat mengirim traffic ke backend eksternal ke daftar yang diizinkan.

• Alamat IP yang dialokasikan secara manual

  Gunakan alamat IP yang dialokasikan secara manual hanya jika lingkungan backend eksternal Anda mengharuskan Anda menambahkan alamat IP Google Cloud tertentu ke daftar yang diizinkan. 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.

  Peringatan: Jika Anda menyediakan lebih sedikit alamat IP NAT daripada jumlah proxy Envoy yang ditetapkan, permintaan yang dikirim ke NEG internet dapat menyebabkan error HTTP 5xx. Untuk memastikan Anda mendapatkan informasi saat peristiwa tersebut terjadi, siapkan pemberitahuan untuk metrik nat_allocation_failed. Hubungi dukungan jika Anda memerlukan bantuan untuk menghitung jumlah alamat IP yang harus dialokasikan untuk load balancer di region tertentu.

  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.

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

Penggunaan Cloud NAT dikenai 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, flag --enable-logging dan --log-filter tidak didukung.
• Fitur terkait port seperti alokasi port statis dan dinamis, menetapkan port maksimum dan minimum per VM, serta Pemetaan Independen Endpoint, tidak didukung. Setiap proxy mendapatkan semua 65.536 port.

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 menggunakan header permintaan kustom. Misalnya, Anda dapat menggunakan 16 byte acak kriptografis atau lebih 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 untuk mengharapkan nilai tertentu untuk header Host permintaan HTTP, dan Anda dapat mengonfigurasi load balancer untuk menetapkan 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, perlu diperhatikan bahwa mengubah header Host tidak didukung di peta URL.

    Ada batasan tambahan yang terkait dengan 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 Anda membuat header kustom lain (misalnya, MyHost) agar tidak mengganggu nama header yang dicadangkan.

• Aktifkan IAP dan verifikasi bahwa JWT yang ditandatangani 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 Aplikasi eksternal regional dan Load Balancer Jaringan proxy (internal dan eksternal).

• Mengaktifkan autentikasi origin pribadi, yang memberikan akses jangka panjang ke bucket Amazon Simple Storage Service (Amazon S3) pribadi atau penyimpanan objek lain yang kompatibel kepada Load Balancer Aplikasi eksternal. 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.

Untuk informasi selengkapnya, lihat referensi berikut:

• Logging dan monitoring 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 akan dicatat ke dalam log.

Pemrosesan header dengan backend eksternal

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

Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik

Saat Load Balancer Aplikasi eksternal global atau Load Balancer Aplikasi klasik melakukan proxy permintaan ke backend eksternal, load balancer akan menyesuaikan header HTTP dengan cara berikut:

• Beberapa header digabungkan. Jika ada beberapa instance 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 besar dan kecil yang tepat jika protokol layanan backend adalah HTTP atau HTTPS:

  • Huruf pertama kunci header dan setiap huruf setelah tanda hubung (-) menggunakan huruf besar 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 (petunjuk klien), dikonversi agar cocok 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 menjadi jenis backend lainnya, atau mengubah backend dari jenis backend lainnya menjadi 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 wajar terjadi.

• 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 Endpoint per tabel kuota NEG.

Harga

Traffic keluar ke endpoint NEG internet eksternal dikenai tarif traffic keluar internet untuk jaringan Premium Tier. 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 dikenai biaya per jam yang setara dengan jaringan dengan lebih dari 32 instance VM. Untuk mengetahui detailnya, lihat Harga Cloud NAT.

Untuk mengetahui informasi selengkapnya, lihat Harga Cloud Load Balancing.

Langkah selanjutnya

• Menyiapkan Load Balancer Aplikasi eksternal global dengan internet NEG
• Menyiapkan Load Balancer Aplikasi klasik dengan internet NEG
• 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 internet NEG
• Menyiapkan Load Balancer Jaringan proxy eksternal regional dengan internet NEG