Ringkasan grup endpoint jaringan internet

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

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

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

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 di 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 dalam hal DNS, health check, jumlah endpoint yang tersedia, dan perilaku perutean traffic.

Bagian berikut ini menjelaskan cara penggunaan backend eksternal dengan Cloud Load Balancing. Jika Anda ingin menggunakan backend eksternal dengan Traffic Director, lihat Traffic Director dengan grup endpoint jaringan internet.

Catatan: Cloud Load Balancing juga mendukung koneksi ke backend di infrastruktur lokal atau di lingkungan cloud lain di luar Google Cloud menggunakan NEG hibrida. Namun, koneksi ke endpoint NEG hibrida menggunakan konektivitas hibrida. Sebaliknya, koneksi ke endpoint NEG internet menggunakan internet sekaligus mempertahankan traffic Anda di backbone berperforma tinggi Google untuk jarak terpanjang yang mungkin, untuk 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 dalam NEG internet.
• origin kustom: Sama seperti backend eksternal. Di CDN, origin adalah istilah standar industri untuk instance backend yang menayangkan konten web.
• internet network endpoint group (NEG): Resource Google Cloud API yang Anda gunakan untuk menentukan backend eksternal.
• endpoint eksternal: Sama seperti 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 untuk layanan backend saja. Konfigurasi frontend sama dengan load balancer lainnya.

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

Eksternal global

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

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

Load Balancer Jaringan proxy 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 mengarahkan traffic berdasarkan alamat IP, port, dan protokol ke proxy target. Proxy target kemudian menghentikan koneksi dari klien. Selain itu, load balancing berbasis Envoy memerlukan subnet khusus proxy.

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

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

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

NEG Internet

NEG internet adalah resource yang digunakan untuk menentukan backend eksternal untuk load balancer. Backend eksternal yang dirujuk oleh NEG internet harus dapat dijangkau melalui internet. Endpoint hanya dapat dijangkau melalui Cloud VPN atau Cloud Interconnect. Jika backend eksternal mereferensikan Google 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. Selain itu, setiap endpoint ini tersedia dalam dua cakupan: global atau regional.

Gunakan tabel berikut untuk meninjau perbedaan antara kedua jenis endpoint dan perilakunya dalam cakupan global dan regional.

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 port opsional yang dapat diselesaikan secara publik. Misalnya, backend.example.com:443^1. 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:443^1. Alamat IP tidak boleh berupa alamat RFC 1918. Hanya satu endpoint per NEG yang diizinkan.
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 port opsional yang dapat diselesaikan secara publik. Misalnya, backend.example.com:443^2. Nama domain harus dapat diselesaikan oleh Cloud DNS atau infrastruktur DNS publik Google. Maksimum 256 endpoint per NEG diizinkan.	Regional	Health check terdistribusi Envoy
	INTERNET_IP_PORT	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 diizinkan.

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

² 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 Anda dapat 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 diselesaikan melalui internet, tidak ada konfigurasi lain yang diperlukan untuk menyiapkan DNS. Namun, jika me-resolve FQDN pribadi, Anda harus mengonfigurasi Cloud DNS untuk memfasilitasi resolusi DNS. Nama harus dihosting di Cloud DNS atau dapat diselesaikan melalui penerusan DNS dari Cloud DNS ke DNS lokal.

Mulailah dengan membuat zona Cloud DNS untuk menghosting data DNS di project Anda. Kemudian, tambahkan catatan DNS ke dalamnya. Untuk mengetahui langkah-langkah konfigurasi tertentu, lihat dokumentasi Cloud DNS.

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

Saat endpoint INTERNET_FQDN_PORT mengarah ke data DNS yang menampilkan beberapa alamat IP, alamat IP akan diselesaikan 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 menampilkan alamat IP yang berbeda berdasarkan lokasi klien, pastikan setiap alamat IP tersebut dapat dijangkau oleh load balancer.

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

Untuk mengetahui informasi selengkapnya tentang rentang dan lokasi IP yang digunakan oleh infrastruktur DNS resolver 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. Dalam kasus server DNS publik, Cloud DNS meneruskan traffic ke server DNS publik.

Jika server DNS menampilkan beberapa alamat IP, load Envoy akan menyeimbangkan traffic di antara alamat IP yang ditampilkan berdasarkan algoritma load balancing yang dikonfigurasi (round robin, permintaan paling sedikit, 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 salah satu gagal.

Layanan backend

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

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

• Layanan backend juga tidak dapat menggunakan jenis backend lain (seperti NEG zona 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 sebenarnya tidak dilakukan. Load balancer berfungsi sebagai frontend saja dan menjadi proxy traffic ke backend eksternal yang ditentukan. Artinya, Anda tidak dapat menggunakan mode load balancing apa pun, seperti kecepatan, koneksi, atau pemakaian.

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

  NEG regional tidak mendukung mode load balancing, seperti tarif, koneksi, atau pemakaian. 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 dalam dokumentasi API layanan backend regional.

• Health check

  • NEG Global. Layanan backend tidak dapat merujuk health check.
  • NEG Regional. Load balancer ini 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 melakukan transit 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:

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

    • Sertifikat ditandatangani oleh certificate authority (CA) terkenal.
    • Sertifikat masih berlaku.
    • Tanda tangan sertifikat valid.
    • FQDN yang dikonfigurasi akan 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 SSL Server Name Indication (SNI) hanya didukung dengan endpoint INTERNET_FQDN_PORT. FQDN yang dikonfigurasi dikirim SNI di salam klien 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 pada 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 menjadi tidak dapat dijangkau atau jika nama host yang dikonfigurasi (FQDN) tidak dapat di-resolve, load balancer akan menampilkan respons 502 (Bad Gateway) HTTP ke kliennya.

• Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, Load Balancer Jaringan proxy eksternal regional, dan Load Balancer Jaringan proxy internal regional. Health check 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 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 Google Cloud Console, gcloud CLI, dan API yang sama dengan health check terpusat. Tidak ada konfigurasi lain yang diperlukan.

  Poin-poin yang perlu diperhatikan:

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

  • Karena bidang data Envoy menangani health check, Anda tidak dapat menggunakan Konsol Google Cloud, API, atau gcloud CLI untuk memeriksa status respons endpoint eksternal ini. Untuk NEG Hybrid 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 health check secara independen. Oleh karena itu, Anda mungkin melihat peningkatan traffic jaringan karena health check. Peningkatan ini bergantung pada jumlah proxy Envoy yang ditetapkan ke jaringan VPC Anda di suatu region, jumlah traffic yang diterima oleh proxy tersebut, dan jumlah endpoint yang diperlukan untuk health check oleh setiap proxy Envoy. Dalam skenario terburuk, traffic jaringan karena health check meningkat pada kecepatan (O(n^2)) kuadrat.

  • Log health check untuk health check Envoy terdistribusi tidak menyertakan status kondisi yang mendetail. Untuk mengetahui detail tentang apa yang dicatat ke dalam log, lihat Logging Health check. Untuk memecahkan masalah konektivitas dari proxy Envoy ke endpoint NEG lebih lanjut, 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

Mengaktifkan backend eksternal untuk menerima permintaan

Traffic dari load balancer yang menggunakan NEG internet regional berasal dari subnet khusus proxy dan kemudian diterjemahkan NAT (dengan menggunakan Cloud NAT) ke alamat IP NAT yang telah dicadangkan atau dialokasikan secara otomatis. Ini mencakup pemeriksaan health check dan permintaan pengguna dari load balancer ke backend.

Mengonfigurasi backend eksternal Anda untuk mengizinkan traffic dari Google Cloud bergantung pada cakupan NEG: global atau regional.

NEG Global: Daftar alamat IP keluar Google default yang diizinkan

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

Sebagai contoh, lihat Mengizinkan backend eksternal menerima traffic dari Google Cloud.

NEG Regional: Gunakan gateway Cloud NAT

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

Penting: Gateway NAT melakukan terjemahan one-to-one 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 dibagi di antara {i>proxy<i}. Alokasi port statis dan dinamis tidak didukung.

Endpoint gateway harus berjenis ENDPOINT_TYPE_MANAGED_PROXY_LB.

Gateway Cloud NAT dapat dikonfigurasi untuk secara otomatis mengalokasikan alamat IP eksternal 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 tidak mengharuskan Anda untuk mengizinkan alamat IP Google Cloud tertentu yang dapat mengirim traffic ke backend eksternal.

• Alamat IP yang dialokasikan secara manual

  Gunakan alamat IP yang dialokasikan secara manual hanya jika lingkungan backend eksternal mengharuskan Anda untuk mengizinkan alamat IP Google Cloud tertentu. 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 alamat IP NAT yang lebih sedikit daripada jumlah proxy Envoy yang ditetapkan, permintaan yang dikirim ke NEG internet dapat menyebabkan error HTTP 5xx. Untuk memastikan bahwa Anda menerima informasi saat peristiwa tersebut terjadi, siapkan pemberitahuan untuk metrik nat_allocation_failed. Hubungi dukungan jika Anda memerlukan bantuan dalam menghitung jumlah alamat IP yang harus dialokasikan untuk load balancer di region tertentu.

  Jika 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 tersebut berbagi gateway NAT yang sama.

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

Ada batasan tertentu untuk gateway NAT yang dikonfigurasi pada 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.
• 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 65536 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 tindakan 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 atau lebih secara kriptografis sebagai kunci bersama.

  Menerapkan 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, perhatikan bahwa memodifikasi header Host tidak didukung dalam peta URL.

    Ada batasan tambahan terkait konfigurasi header Host. Untuk mengetahui detailnya, lihat Membuat header kustom di layanan backend. Untuk contoh khusus, 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 pada peta URL.

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

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

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

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

Log

Permintaan yang di-proxy-kan ke backend eksternal dicatat ke dalam log ke Cloud Logging dengan cara yang sama seperti permintaan untuk backend lain yang dicatat ke dalam log.

Untuk informasi selengkapnya, lihat referensi berikut:

• Logging dan pemantauan Load Balancer Aplikasi Eksternal
• 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, cache ditemukan juga dalam log.

Pemrosesan header dengan backend eksternal

Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik

Saat Load Balancer Aplikasi global atau klasik melakukan proxy permintaan ke backend eksternal, Load Balancer Aplikasi 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 ke dalam satu daftar yang dipisahkan koma untuk satu kunci header. Hanya header yang nilainya dapat direpresentasikan sebagai daftar yang dipisahkan koma yang akan digabungkan. Header lain, seperti Set-Cookie, tidak pernah digabungkan.

• Header menggunakan kapitalisasi yang tepat saat protokol layanan backend adalah HTTP atau HTTPS:

  • Huruf pertama pada kunci header dan setiap huruf setelah tanda hubung (-) menggunakan huruf besar untuk menjaga 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 terkait mengonfigurasi NEG internet sebagai backend.
• Saat Anda mengubah load balancer untuk mengubah backend dari NEG internet ke jenis backend lainnya, atau mengubah backend dari jenis backend lainnya menjadi NEG internet, aplikasi Anda akan mengalami periode nonaktif sementara 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. Ini normal.
• Fitur pengelolaan traffic lanjutan berikut tidak didukung dengan backend NEG internet global:
  • Minta pencerminan
  • Coba lagi kebijakan
  • Kebijakan traffic (termasuk kebijakan lokalitas load balancing, afinitas sesi, dan deteksi pencilan)
• Tinjau bagian Gateway Cloud NAT untuk mengetahui batasan terkait gateway NAT yang dikonfigurasi pada subnet khusus proxy.

Kuota dan batas

Kuota dan batas berikut berlaku untuk NEG internet:

• Anda dapat mengonfigurasi NEG sebanyak mungkin dengan endpoint jaringan eksternal sesuai yang diizinkan oleh kuota grup endpoint jaringan yang ada.

• Jumlah NEG per layanan backend bergantung pada jenis NEG internet (global atau regional):

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

• Jumlah endpoint per NEG juga bergantung pada jenis NEG internet (global atau regional):

  • Untuk NEG global, Anda hanya dapat menambahkan satu endpoint ke NEG internet.
  • Untuk NEG regional, Anda dapat menambahkan hingga 256 endpoint ke NEG internet.

Untuk mengetahui informasi selengkapnya, lihat kuota backend NEG dan Kuota Endpoint per NEG.

Harga

Traffic keluar ke endpoint NEG internet eksternal dikenai biaya dengan tarif traffic keluar internet untuk jaringan Paket 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 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 selanjutnya

• Siapkan Load Balancer Aplikasi eksternal global dengan NEG internet.
• Siapkan Load Balancer Aplikasi klasik dengan NEG internet.
• Siapkan Cloud CDN untuk Load Balancer Aplikasi eksternal dengan backend eksternal.
• Baca Traffic Director dengan ringkasan grup endpoint jaringan internet.