Ringkasan grup endpoint jaringan internet

Cloud Load Balancing mendukung traffic proxy ke backend eksternal di luar Trusted Cloud by S3NS. 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 Trusted 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.

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 Trusted Cloud by S3NS dan dapat dijangkau di internet. Endpoint di NEG internet.
  • Grup endpoint jaringan (NEG) internet: Resource API yang Anda gunakan untuk menentukan backend eksternal. Trusted Cloud by S3NS
  • 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 Trusted Cloud resource yang diperlukan untuk menyiapkan load balancer dengan backend eksternal.

Eksternal regional

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

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

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

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 Trusted Cloud resource yang diperlukan untuk menyiapkan Load Balancer Aplikasi internal regional dengan backend eksternal.

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

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

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 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:

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

Nama domain harus dapat di-resolve oleh 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.

* Dengan NEG internet regional, Anda harus menentukan port. Anda dapat menentukan port default saat membuat NEG, atau Anda dapat 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 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 regional

NEG internet regional mendukung resolusi nama domain menggunakan Cloud DNS.

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 regional. Anda dapat menambahkan hingga 50 NEG internet ke layanan backend yang sama.

  • Jumlah endpoint per NEG

    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

  • 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 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 Trusted 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 konsolTrusted Cloud , API, atau gcloud CLI untuk memeriksa status kondisi endpoint eksternal ini. Untuk NEG hybrid dengan load balancer berbasis Envoy, Trusted 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.

Aktifkan backend eksternal untuk menerima permintaan

Konfigurasi backend eksternal Anda untuk mengizinkan traffic dari Trusted 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 Trusted 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. Trusted 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. Trusted 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 Trusted 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 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 Trusted 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.

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:

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