Ringkasan grup endpoint jaringan internet

Cloud Load Balancing mendukung traffic proxy ke backend eksternal di luar Cloud de Confiance 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 Cloud de Confiance menjadi frontend. Dengan begitu, Anda dapat melakukan hal berikut:

• Gunakan infrastruktur Edge Google untuk mengakhiri koneksi pengguna Anda.
• Mengarahkan 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 menggunakan backend eksternal 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 Cloud de Confiance by S3NS dan dapat dijangkau di internet. Endpoint di NEG internet.
• Grup endpoint jaringan (NEG) internet: Resource Cloud de Confiance by S3NS 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 internet NEG API.

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 Cloud de Confiance 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 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 yang dapat dirutekan ke internet publik yang dapat digunakan; jika format INTERNET_FQDN_PORT dipilih, FQDN dapat di-resolve 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 Anda. Meskipun tidak diperlukan untuk metode pemilihan rute ini, Cloud NAT didukung.

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

Load balancer	Jenis endpoint	Definisi endpoint	Cakupan	Health check	Validasi sertifikat server
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 diselesaikan oleh Cloud DNS. Maksimum 256 endpoint per NEG yang diizinkan.	Regional	Health check terdistribusi Envoy	Tidak divalidasi. Siapkan TLS yang Diautentikasi Backend untuk melakukan validasi sertifikat.
	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.			Tidak divalidasi. Siapkan TLS yang Diautentikasi Backend untuk melakukan validasi sertifikat.

Resolusi DNS untuk endpoint INTERNET_FQDN_PORT regional

Jika domain Anda dapat di-resolve 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 secara mendetail di Urutan resolusi nama.

Jika Anda menggunakan VPC Bersama, perhatikan persyaratan jaringan tertentu. Anda juga dapat menggunakan fitur lain dari Cloud DNS, 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 load balancing 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 zona 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. Anda dapat menambahkan hingga 256 endpoint per NEG ke layanan backend yang sama.

  NEG regional tidak mendukung mode load balancing, seperti kecepatan, koneksi, atau pemanfaatan. 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 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 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 transit di internet publik.

• Validasi sertifikat server

  Validasi sertifikat server bergantung pada jenis endpoint (INTERNET_FQDN_PORTatau INTERNET_IP_PORT) dan cakupan endpoint: regional atau global.

  • NEG Global. Load balancer memvalidasi sertifikat server untuk INTERNET_FQDN_PORT.

    Saat backend eksternal dibuat menggunakan INTERNET_FQDN_PORT, load balancer akan 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.

  • NEG regional. Load balancer tidak memvalidasi sertifikat server SSL secara default.

    Secara default, validasi sertifikat server tidak dilakukan untuk backend internal atau eksternal regional yang dibuat dengan INTERNET_FQDN_PORT atau INTERNET_IP_PORT. Jika validasi sertifikat server diperlukan, validasi dapat dikonfigurasi dengan TLS yang diautentikasi backend.

• Penanganan ekstensi Indikasi Nama Server (SNI) SSL

  Ekstensi SSL Server Name Indication (SNI) hanya didukung dengan endpoint INTERNET_FQDN_PORT. FQDN yang dikonfigurasi 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 kesehatan 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 menggunakan proses Cloud de Confiance konsol, gcloud CLI, dan API yang sama dengan health check terpusat. Tidak diperlukan konfigurasi lain.

  Poin yang perlu diperhatikan:

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

  • Karena bidang data Envoy menangani health check, Anda tidak dapat menggunakan konsolCloud de Confiance , API, atau gcloud CLI untuk memeriksa status kesehatan endpoint eksternal ini. Untuk NEG hybrid dengan load balancer berbasis Envoy, konsol Cloud de Confiance menampilkan status health check sebagaiN/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 informasi yang dicatat dalam log, 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 Cloud de Confiance.

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 Cloud de Confiance 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. Cloud de Confiance

• 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. Cloud de Confiance 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 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.

Gateway NAT yang dikonfigurasi di subnet khusus proxy tidak mendukung logging dan pemantauan. Artinya, flag --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 Cloud de Confiance 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 Cloud de Confiance. Anda tidak dapat mengubah header ini untuk load balancer ini. Sebagai gantinya, sebaiknya Anda membuat 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:

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

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 lainnya, atau mengubah backend dari jenis backend lainnya 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

Untuk mengetahui informasi tentang tarif traffic keluar internet ke endpoint NEG internet, lihat Harga Tingkat Premium.

Jika Anda mengonfigurasi gateway Cloud NAT untuk memetakan subnet khusus proxy load balancer berbasis Envoy regional, lihat Harga jaringan: Cloud NAT.

Untuk mengetahui informasi lain tentang harga Cloud Load Balancing dan biaya NEG internet regional, lihat Harga jaringan: Cloud Load Balancing.

Langkah berikutnya

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