Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan grup endpoint jaringan konektivitas hybrid

Cloud Load Balancing mendukung traffic load balancing ke endpoint yang melampaui batas, seperti pusat data lokal dan cloud publik lainnya yang dapat Anda gunakan konektivitas hybrid untuk menjangkaunya. Google Cloud

Strategi hybrid adalah solusi pragmatis bagi Anda untuk beradaptasi dengan perubahan permintaan pasar dan memodernisasi aplikasi secara bertahap. Hal ini dapat berupa deployment hybrid sementara untuk memungkinkan migrasi ke solusi berbasis cloud modern atau perlengkapan permanen infrastruktur IT organisasi Anda.

Menyiapkan load balancing hybrid juga memungkinkan Anda memperoleh manfaat dari kemampuan jaringan Cloud Load Balancing untuk layanan yang berjalan di infrastruktur Anda yang ada di luar Google Cloud.

Load balancing hybrid didukung di load balancer berikut: Google Cloud

Load Balancer Aplikasi Eksternal: Load Balancer Aplikasi eksternal global, Load Balancer Aplikasi klasik, dan Load Balancer Aplikasi eksternal regional
Load Balancer Aplikasi internal: Load Balancer Aplikasi internal lintas region dan Load Balancer Aplikasi internal regional
Load Balancer Jaringan proxy eksternal: Load Balancer Jaringan proxy eksternal global, Load Balancer Jaringan proxy klasik, dan Load Balancer Jaringan proxy eksternal regional
Load Balancer Jaringan proxy internal: Load Balancer Jaringan proxy internal regional dan Load Balancer Jaringan proxy internal lintas region

Layanan lokal dan cloud lainnya diperlakukan seperti backend Cloud Load Balancing lainnya. Perbedaan utamanya adalah Anda menggunakan NEG konektivitas hybrid untuk mengonfigurasi endpoint backend ini. Endpoint harus berupa kombinasi IP:port yang valid dan dapat dijangkau oleh load balancer Anda menggunakan produk konektivitas hybrid seperti Cloud VPN, Cloud Interconnect, atau VM Router appliance.

Kasus penggunaan: Merutekan traffic ke lokasi lokal atau cloud lain

Kasus penggunaan paling sederhana untuk menggunakan NEG hybrid adalah merutekan traffic dari Google Cloud load balancer ke lokasi lokal atau ke lingkungan cloud lain. Klien dapat memulai traffic dari internet publik, dari dalam Google Cloud, atau dari klien lokal.

Klien publik

Anda dapat menggunakan Load Balancer Aplikasi eksternal dengan backend NEG hibrida untuk merutekan traffic dari klien eksternal ke backend di infrastruktur lokal atau di jaringan cloud lain. Anda juga dapat mengaktifkan kemampuan jaringan bernilai tambah berikut untuk layanan Anda di lokal atau di jaringan cloud lainnya:

Dengan Load Balancer Aplikasi eksternal global dan Load Balancer Aplikasi klasik, Anda dapat:
- Gunakan infrastruktur edge global Google untuk menghentikan koneksi pengguna lebih dekat dengan pengguna, sehingga mengurangi latensi.
- Lindungi layanan Anda dengan Google Cloud Armor, produk keamanan WAF/pertahanan DDoS di edge yang tersedia untuk semua layanan yang diakses melalui Application Load Balancer eksternal.
- Aktifkan layanan Anda untuk mengoptimalkan pengiriman menggunakan Cloud CDN. Dengan Cloud CDN, Anda dapat menyimpan konten ke dalam cache di lokasi yang dekat dengan pengguna. Cloud CDN menyediakan kemampuan seperti invalidasi cache dan URL bertanda tangan Cloud CDN.
- Gunakan sertifikat SSL yang dikelola Google. Anda dapat menggunakan kembali sertifikat dan kunci pribadi yang sudah Anda gunakan untuk produk Google Cloud lainnya. Dengan demikian, Anda tidak perlu mengelola sertifikat secara terpisah.
Diagram berikut menunjukkan deployment hybrid dengan Load Balancer Aplikasi eksternal.

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

Dalam diagram ini, traffic dari klien di internet publik memasuki jaringan cloud atau lokal pribadi Anda melalui load balancer Google Cloud , seperti Load Balancer Aplikasi eksternal. Saat traffic mencapai load balancer, Anda dapat menerapkan layanan edge jaringan seperti perlindungan DDoS Cloud Armor atau autentikasi pengguna Identity-Aware Proxy (IAP).

Dengan Load Balancer Aplikasi eksternal regional, Anda dapat merutekan traffic eksternal ke endpoint yang berada dalam Google Cloud region yang sama dengan resource load balancer. Gunakan load balancer ini jika Anda perlu menayangkan konten dari hanya satu geolokasi (misalnya, untuk mematuhi peraturan kepatuhan) atau jika Anda ingin menggunakan Tingkat Layanan Jaringan Standar.

Cara permintaan dirutekan (apakah ke backend Google Cloud atau ke endpoint on-premise/cloud) bergantung pada cara peta URL Anda dikonfigurasi. Bergantung pada peta URL Anda, load balancer memilih layanan backend untuk permintaan tersebut. Jika layanan backend yang dipilih telah dikonfigurasi dengan NEG konektivitas hybrid (hanya digunakan untuk endpoint non-Google Cloud ), load balancer meneruskan traffic di seluruh Cloud VPN, Cloud Interconnect, atau VM Router appliance, ke tujuan eksternal yang diinginkan.

Klien internal (dalam Google Cloud atau lokal)

Anda juga dapat menyiapkan deployment hybrid untuk klien internal ke Google Cloud. Dalam hal ini, traffic klien berasal dari Google Cloud jaringan VPC, jaringan lokal, atau dari cloud lain, dan dirutekan ke endpoint lokal atau di jaringan cloud lain.

Load Balancer Aplikasi internal regional adalah load balancer regional, yang berarti bahwa load balancer ini hanya dapat merutekan traffic ke endpoint dalam region Google Cloud yang sama dengan resource load balancer. Load Balancer Aplikasi internal lintas region adalah load balancer multi-region yang dapat melakukan load balancing traffic ke layanan backend yang didistribusikan secara global.

Diagram berikut menunjukkan deployment hybrid dengan Load Balancer Aplikasi internal regional.

Konektivitas hybrid dengan Load Balancer Aplikasi internal regional. — Konektivitas hybrid dengan Load Balancer Aplikasi internal regional (klik untuk memperbesar).

Kasus penggunaan: Bermigrasi ke Cloud

Memigrasikan layanan yang ada ke cloud memungkinkan Anda membebaskan kapasitas lokal dan mengurangi biaya serta beban pemeliharaan infrastruktur lokal. Anda dapat menyiapkan deployment hybrid untuk sementara yang memungkinkan Anda merutekan traffic ke layanan lokal saat ini dan endpoint layananGoogle Cloud yang sesuai.

Diagram berikut menunjukkan penyiapan ini dengan Load Balancer Aplikasi internal.

Bermigrasi ke Google Cloud. — Migrasikan ke Google Cloud (klik untuk memperbesar).

Jika menggunakan Load Balancer Aplikasi internal untuk menangani klien internal, Anda dapat mengonfigurasi load balancer untuk menggunakan pembagian traffic berbasis bobot guna membagi traffic di kedua layanan. Google Cloud Pembagian traffic memungkinkan Anda memulai dengan mengirim 0% traffic ke layanan Google Cloud dan 100% ke layanan di lokasi. Kemudian, Anda dapat secara bertahap meningkatkan proporsi traffic yang dikirim ke layanan Google Cloud . Pada akhirnya, Anda mengirim 100% traffic ke layanan Google Cloud , dan Anda dapat menghentikan layanan lokal.

Arsitektur hybrid

Bagian ini menjelaskan arsitektur load balancing dan resource yang diperlukan untuk mengonfigurasi deployment load balancing hybrid.

Layanan lokal dan cloud lainnya seperti backend Cloud Load Balancing lainnya. Perbedaan utamanya adalah Anda menggunakan NEG konektivitas hybrid untuk mengonfigurasi endpoint backend ini. Endpoint harus berupa kombinasi IP:port yang valid dan dapat dijangkau klien Anda melalui konektivitas hybrid, seperti Cloud VPN, Cloud Interconnect, atau VM Router appliance.

Diagram berikut menunjukkan Google Cloud resource yang diperlukan untuk mengaktifkan load balancing hybrid untuk Load Balancer Aplikasi eksternal dan Load Balancer Aplikasi internal regional.

HTTP(S) eksternal global

Resource Load Balancer Aplikasi eksternal global untuk konektivitas hybrid. — Resource Load Balancer Aplikasi eksternal global untuk konektivitas hybrid (klik untuk memperbesar).

HTTP(S) eksternal regional

Resource Load Balancer Aplikasi eksternal regional untuk konektivitas hybrid. — Resource Load Balancer Aplikasi eksternal regional untuk konektivitas hybrid (klik untuk memperbesar).

HTTP(S) internal regional

Resource Load Balancer Aplikasi internal regional untuk konektivitas hybrid. — Resource Load Balancer Aplikasi internal regional untuk konektivitas hybrid (klik untuk memperbesar).

Proxy internal regional

Regional versus global

Perutean Cloud Load Balancing bergantung pada cakupan load balancer yang dikonfigurasi:

Load Balancer Aplikasi eksternal dan Load Balancer Jaringan proxy eksternal. Load balancer ini dapat dikonfigurasi untuk perutean global atau regional, bergantung pada tingkat jaringan yang digunakan. Anda membuat backend NEG hybrid load balancer di jaringan dan region yang sama dengan tempat konektivitas hybrid telah dikonfigurasi. Endpoint non-Google Cloud juga harus dikonfigurasi dengan tepat untuk memanfaatkan load balancing berbasis kedekatan.

Load Balancer Aplikasi internal lintas region dan Load Balancer Jaringan proxy internal lintas region. Load balancer ini adalah load balancer multi-region yang dapat melakukan load balancing traffic ke layanan backend yang didistribusikan secara global. Anda membuat backend NEG hybrid load balancer di jaringan dan region yang sama tempat konektivitas hybrid telah dikonfigurasi. Endpoint non-Google Cloud juga harus dikonfigurasi dengan tepat untuk memanfaatkan load balancing berbasis kedekatan.

Load Balancer Aplikasi internal regional dan Load Balancer Jaringan proxy internal regional. Ini adalah load balancer regional. Artinya, load balancer hanya dapat merutekan traffic ke endpoint dalam region yang sama dengan load balancer. Komponen load balancer harus dikonfigurasi di region yang sama dengan tempat konektivitas hybrid telah dikonfigurasi. Secara default, klien yang mengakses load balancer juga harus berada di region yang sama. Namun, jika Anda mengaktifkan akses global, klien dari region mana pun dapat mengakses load balancer.

Misalnya, jika gateway Cloud VPN atau lampiran VLAN Cloud Interconnect dikonfigurasi di REGION_A, resource yang diperlukan oleh load balancer (seperti layanan backend, NEG hybrid, atau aturan penerusan) harus dibuat di region REGION_A. Secara default, klien yang mengakses load balancer juga harus berada di region REGION_A. Namun, jika Anda mengaktifkan akses global, klien dari region mana pun dapat mengakses load balancer.

Persyaratan konektivitas jaringan

Sebelum mengonfigurasi deployment load balancing hybrid, Anda harus menyiapkan resource berikut:

Jaringan VPCGoogle Cloud . Jaringan VPC yang dikonfigurasi di dalam Google Cloud. Ini adalah jaringan VPC yang digunakan untuk mengonfigurasi Cloud Interconnect/Cloud VPN dan Cloud Router. Jaringan ini juga merupakan jaringan yang sama tempat Anda akan membuat resource load balancing (aturan penerusan, proxy target, layanan backend, dll.). Alamat IP dan rentang alamat IP subnet di lokal, cloud lain, dan subnet tidak boleh tumpang-tindih. Google Cloud Jika alamat IP tumpang-tindih, rute subnet akan diprioritaskan daripada konektivitas jarak jauh.
Konektivitas hybrid. Lingkungan Google Cloud dan lokal atau cloud lainnya harus terhubung melalui konektivitas hybrid, menggunakan lampiran VLAN Cloud Interconnect, tunnel Cloud VPN dengan Cloud Router, atau VM Router appliance. Sebaiknya gunakan koneksi dengan ketersediaan tinggi. Cloud Router yang diaktifkan dengan perutean dinamis global mempelajari endpoint tertentu menggunakan BGP dan memprogramnya ke jaringan VPC Google Cloud Anda. Perutean dinamis regional tidak didukung. Rute statis juga tidak didukung.

Cloud Interconnect/Cloud VPN/Router appliance harus dikonfigurasi di jaringan VPC yang sama yang ingin Anda gunakan untuk deployment load balancing hybrid. Cloud Router juga harus mengiklankan rute berikut ke lingkungan lokal Anda:
- Rentang yang digunakan oleh probe health check Google: 35.191.0.0/16 dan 130.211.0.0/22. Hal ini diperlukan untuk Load Balancer Aplikasi eksternal global, Load Balancer Aplikasi klasik, Load Balancer Jaringan proxy eksternal global, dan Load Balancer Jaringan proxy klasik.
- Rentang subnet khusus proxy region: untuk load balancer berbasis Envoy—Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, Load Balancer Aplikasi internal lintas region, Load Balancer Jaringan proxy eksternal regional, Load Balancer Jaringan proxy internal lintas region, dan Load Balancer Jaringan proxy internal regional.
  
  Subnet khusus proxy wilayah iklan juga diperlukan agar health check Envoy terdistribusi berfungsi. Health check Envoy terdistribusi adalah mekanisme health check default untuk NEG konektivitas hibrida zonal (yaitu, endpoint NON_GCP_PRIVATE_IP_PORT) di belakang load balancer berbasis Envoy.
Anda dapat menggunakan jaringan yang sama atau jaringan VPC yang berbeda dalam project yang sama untuk mengonfigurasi jaringan hybrid (Cloud Interconnect atau Cloud VPN) dan load balancer. Perhatikan hal berikut:
- Jika Anda menggunakan jaringan VPC yang berbeda, kedua jaringan harus dihubungkan menggunakan Peering Jaringan VPC atau harus berupa spoke VPC di hub Network Connectivity Center yang sama.
- Jika Anda menggunakan jaringan VPC yang sama, pastikan rentang CIDR subnet jaringan VPC Anda tidak berkonflik dengan rentang CIDR jarak jauh Anda. Jika alamat IP tumpang-tindih, rute subnet diprioritaskan daripada konektivitas jarak jauh.
Endpoint jaringan (IP:Port) di lokal atau di cloud lain. Satu atau beberapa endpoint jaringan IP:Port yang dikonfigurasi dalam lingkungan lokal atau cloud lainnya, yang dapat dirutekan menggunakan Cloud Interconnect, Cloud VPN, atau VM Router appliance. Jika ada beberapa jalur ke endpoint IP, perutean akan mengikuti perilaku yang dijelaskan dalam ringkasan rute VPC dan ringkasan Cloud Router.
Aturan firewall di lokal atau cloud lainnya. Aturan firewall berikut harus dibuat di lingkungan lokal atau cloud lainnya:
- Ingress mengizinkan aturan firewall untuk mengizinkan traffic dari pemeriksaan health check Google ke endpoint Anda. Rentang yang akan diizinkan adalah: 35.191.0.0/16 dan 130.211.0.0/22. Perhatikan bahwa rentang ini juga harus diiklankan oleh Cloud Router ke jaringan lokal Anda. Untuk mengetahui detail selengkapnya, lihat Aturan firewall dan rentang IP pemeriksaan.
- Aturan firewall izinkan masuk untuk mengizinkan traffic yang di-load balance untuk menjangkau endpoint.
- Untuk load balancer berbasis Envoy—Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, Load Balancer Aplikasi internal lintas region, Load Balancer Jaringan proxy eksternal regional, Load Balancer Jaringan proxy internal lintas region, dan Load Balancer Jaringan proxy internal regional, Anda juga perlu membuat aturan firewall untuk mengizinkan traffic dari subnet khusus proxy region tersebut untuk menjangkau endpoint yang berada di lokal atau di lingkungan cloud lain.

Komponen load balancer

Bergantung pada jenis load balancer, Anda dapat menyiapkan deployment load balancing hybrid menggunakan Network Service Tiers Standar atau Premium.

Load balancer hybrid memerlukan konfigurasi khusus hanya untuk layanan backend. Konfigurasi frontend sama dengan load balancer lainnya. Load balancer berbasis Envoy—Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, Load Balancer Aplikasi internal lintas region,Load Balancer Jaringan proxy eksternal regional, Load Balancer Jaringan proxy internal lintas region, dan Load Balancer Jaringan proxy internal regional—memerlukan subnet khusus proxy tambahan untuk menjalankan proxy Envoy atas nama Anda.

Konfigurasi frontend

Tidak diperlukan konfigurasi frontend khusus untuk load balancing hybrid. Aturan penerusan digunakan untuk merutekan traffic menurut alamat IP, port, dan protokol ke proxy target. Kemudian, target proxy menghentikan koneksi dari klien.

Peta URL digunakan oleh load balancer HTTP(S) untuk menyiapkan perutean permintaan berbasis URL ke layanan backend yang sesuai.

Untuk mengetahui detail selengkapnya tentang setiap komponen ini, lihat bagian arsitektur di ringkasan load balancer tertentu:

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 deployment load balancing hybrid, Anda mengonfigurasi load balancer dengan backend yang berada di dalam Google Clouddan di luar Google Cloud.

Backend non-Google Cloud (lokal atau cloud lain)

Tujuan apa pun yang dapat Anda jangkau menggunakan produk konektivitas hybrid Google (baik Cloud VPN maupun Cloud Interconnect atau VM Router appliance), dan yang dapat dijangkau dengan kombinasi IP:Port yang valid, dapat dikonfigurasi sebagai endpoint untuk load balancer.

Konfigurasi backend non-Google Cloud Anda sebagai berikut:
1. Tambahkan setiap kombinasi IP:Portendpoint jaringan non-Google Cloud ke grup endpoint jaringan (NEG) konektivitas hibrida. Pastikan alamat IP dan port ini dapat dijangkau dari Google Cloud dengan menggunakan konektivitas hybrid (baik dengan Cloud VPN atau Cloud Interconnect atau VM Router appliance). Untuk NEG konektivitas hybrid, Anda menetapkan network endpoint type ke NON_GCP_PRIVATE_IP_PORT.
2. Saat membuat NEG, tentukan Google Cloud zona yang meminimalkan jarak geografis antara Google Cloud dan lingkungan cloud lokal atau cloud lainnya. Misalnya, jika Anda menghosting layanan di lingkungan lokal di Frankfurt, Jerman, Anda dapat menentukan zona europe-west3-a Google Cloud saat membuat NEG.
3. Tambahkan NEG konektivitas hybrid ini sebagai backend untuk layanan backend.
  
  NEG dengan konektivitas hybrid hanya boleh menyertakan endpoint non-Google Cloud. Traffic dapat dihentikan jika NEG hibrida menyertakan endpoint untuk resource dalam jaringan VPC Google Cloud , seperti alamat IP aturan penerusan untuk Network Load Balancer passthrough internal. Konfigurasi endpoint Google Cloud seperti yang diarahkan di bagian berikutnya.
Google Cloud backend

Konfigurasi endpoint Google Cloud Anda sebagai berikut:
1. Buat layanan backend terpisah untuk Google Cloud backend.
2. Konfigurasi beberapa backend (baik GCE_VM_IP_PORTNEG zona atau grup instance) dalam region yang sama tempat Anda telah menyiapkan konektivitas hybrid.

Poin tambahan yang perlu dipertimbangkan:

Setiap NEG dengan konektivitas hybrid hanya dapat berisi endpoint jaringan dengan jenis yang sama (NON_GCP_PRIVATE_IP_PORT).
Anda dapat menggunakan satu layanan backend untuk mereferensikan backend berbasisGoogle Cloud(menggunakan NEG zonal dengan endpoint GCE_VM_IP_PORT) dan backend lokal atau cloud lainnya (menggunakan NEG konektivitas hibrida dengan endpoint NON_GCP_PRIVATE_IP_PORT). Kombinasi jenis backend campuran lainnya tidak diizinkan. Cloud Service Mesh tidak mendukung jenis backend campuran dalam satu layanan backend.

Catatan: Untuk deployment GKE, backend NEG campuran hanya didukung dengan NEG mandiri.

Skema load balancing layanan backend harus berupa salah satu dari berikut ini:
- EXTERNAL_MANAGED untuk Load Balancer Aplikasi eksternal global, Load Balancer Aplikasi eksternal regional, Load Balancer Jaringan proxy eksternal global, dan Load Balancer Jaringan proxy eksternal regional
- EXTERNAL untuk Load Balancer Aplikasi klasik dan Load Balancer Jaringan proxy klasik
- INTERNAL_MANAGED untuk Load Balancer Aplikasi internal dan Load Balancer Jaringan proxy internal
INTERNAL_SELF_MANAGED didukung untuk deployment multi-lingkungan Cloud Service Mesh dengan NEG konektivitas hybrid.

Protokol layanan backend harus berupa HTTP, HTTPS, atau HTTP2 untuk Load Balancer Aplikasi, dan TCP atau SSL untuk Load Balancer Jaringan proxy. Untuk daftar protokol layanan backend yang didukung oleh setiap load balancer, lihat Protokol dari load balancer ke backend.
Mode load balancing untuk backend NEG hybrid harus RATE untuk Load Balancer Aplikasi, dan CONNECTION untuk Load Balancer Jaringan proxy. Untuk mengetahui detail tentang mode penyeimbangan, lihat Ringkasan layanan backend.
Untuk menambahkan lebih banyak endpoint jaringan, perbarui backend yang terlampir ke layanan backend Anda.
Jika Anda menggunakan pemeriksaan kesehatan Envoy terdistribusi dengan backend NEG konektivitas hibrida (hanya didukung untuk load balancer berbasis Envoy), pastikan Anda mengonfigurasi endpoint jaringan unik untuk semua NEG yang terpasang ke layanan backend yang sama. Menambahkan endpoint jaringan yang sama ke beberapa NEG akan menghasilkan perilaku yang tidak ditentukan.

Health check terpusat

Health check terpusat, saat menggunakan NEG hybrid, diperlukan untuk Load Balancer Aplikasi eksternal global, Load Balancer Aplikasi klasik, Load Balancer Jaringan proxy eksternal global, dan Load Balancer Jaringan proxy klasik. Load balancer berbasis Envoy lainnya menggunakan health check Envoy terdistribusi seperti yang dijelaskan di bagian berikut.

Untuk endpoint NON_GCP_PRIVATE_IP_PORT di luar Google Cloud, buat aturan firewall di jaringan on-premise dan cloud lainnya. Hubungi administrator jaringan Anda untuk mendapatkan bantuan terkait hal ini. Cloud Router yang digunakan untuk konektivitas hibrida juga harus mengiklankan rentang yang digunakan oleh probe pemeriksaan kondisi Google. Rentang yang akan diiklankan adalah 35.191.0.0/16 dan 130.211.0.0/22.

Untuk jenis backend lain dalam Google Cloud, buat aturan firewall di Google Cloud seperti yang ditunjukkan dalam contoh ini.

Dokumentasi terkait:

Health check Envoy terdistribusi

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

Load Balancer Aplikasi eksternal global, Load Balancer Aplikasi klasik, Load Balancer Jaringan proxy eksternal global , dan Load Balancer Jaringan proxy klasik. Load balancer ini tidak mendukung health check Envoy terdistribusi. Load balancer ini menggunakan mekanisme pemeriksaan kondisi terpusat Google seperti yang dijelaskan di bagian Pemeriksaan kondisi terpusat.

Load Balancer Aplikasi eksternal regional, Load Balancer Aplikasi internal regional, Load Balancer Jaringan proxy eksternal regional, Load Balancer Jaringan proxy internal regional , Load Balancer Jaringan proxy internal lintas region, dan Load Balancer Aplikasi internal lintas region. Load balancer ini menggunakan health check Envoy terdistribusi untuk memeriksa kondisi NEG hibrida. Pemeriksaan health check berasal dari software proxy Envoy itu sendiri. Setiap layanan backend harus dikaitkan dengan health check yang memeriksa responsivitas backend. Pemeriksaan health check berasal dari proxy Envoy di subnet khusus proxy di region. Agar pemeriksaan health check berfungsi dengan benar, Anda harus membuat aturan firewall di lingkungan eksternal yang mengizinkan traffic dari subnet khusus proxy untuk menjangkau backend eksternal Anda.

Untuk endpoint NON_GCP_PRIVATE_IP_PORT di luar Google Cloud, Anda harus membuat aturan firewall ini di jaringan lokal dan cloud lainnya. Hubungi administrator jaringan Anda untuk mendapatkan bantuan terkait hal ini. Cloud Router yang Anda gunakan untuk konektivitas hybrid juga harus mengiklankan rentang subnet khusus proxy di region tersebut.

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

Poin yang perlu diperhatikan:

Health check gRPC tidak didukung.
Pemeriksaan kesehatan dengan protokol PROXY v1 yang diaktifkan tidak didukung.
Jika Anda menggunakan NEG campuran di mana satu layanan backend memiliki kombinasi NEG zonal (endpoint GCE_VM_IP_PORT dalam Google Cloud) dan NEG hybrid (endpoint NON_GCP_PRIVATE_IP_PORT di luar Google Cloud), Anda perlu menyiapkan aturan firewall untuk mengizinkan traffic dari rentang IP pemeriksaan kondisi Google (130.211.0.0/22 dan 35.191.0.0/16) ke endpoint NEG zonal di Google Cloud. Hal ini karena NEG zonal menggunakan sistem pemeriksaan kondisi terpusat Google.
Karena bidang data Envoy menangani pemeriksaan kondisi, Anda tidak dapat menggunakan konsolGoogle Cloud , API, atau gcloud CLI untuk memeriksa status kondisi endpoint eksternal ini. Untuk NEG hybrid dengan load balancer berbasis Envoy, Google Cloud konsol menampilkan status health check sebagai N/A. Hal ini sudah diperkirakan.
Setiap proxy Envoy yang ditetapkan ke subnet khusus proxy di region dalam jaringan VPC memulai health check secara independen. Oleh karena itu, Anda mungkin melihat peningkatan traffic jaringan karena pemeriksaan kondisi. Peningkatan ini bergantung pada jumlah proxy Envoy yang ditetapkan ke jaringan VPC Anda di suatu region, jumlah traffic yang diterima oleh proxy ini, dan jumlah endpoint yang perlu diperiksa kondisinya oleh setiap proxy Envoy. Dalam skenario terburuk, traffic jaringan karena pemeriksaan health check meningkat pada tingkat kuadratik (O(n^2)).
Log health check untuk health check Envoy terdistribusi tidak menyertakan status kesehatan yang mendetail. Untuk mengetahui detail tentang apa yang dicatat, lihat Logging health check. Untuk memecahkan masalah konektivitas lebih lanjut dari proxy Envoy ke endpoint NEG Anda, Anda juga harus memeriksa log load balancer masing-masing.