Menyiapkan backend eksternal dengan grup endpoint jaringan internet
Dokumen ini memberikan petunjuk untuk mengonfigurasi backend eksternal untuk Cloud Service Mesh menggunakan grup endpoint jaringan internet (NEG), yang memerlukan nama domain yang sepenuhnya memenuhi syarat. Dokumen ini ditujukan bagi pengguna yang memiliki tingkat pemahaman menengah hingga lanjut tentang hal berikut:
Panduan penyiapan ini memberi Anda petunjuk dasar untuk hal berikut:
- Mengonfigurasi Cloud Service Mesh untuk menggunakan NEG internet dan TLS yang tidak diautentikasi untuk traffic keluar
- Me-rutekan traffic ke layanan Cloud Run dari mesh layanan Anda
Sebelum memulai
Tinjau ringkasan Cloud Service Mesh dengan grup endpoint jaringan internet.
Untuk tujuan panduan ini, contoh konfigurasi mengasumsikan hal berikut:
- Semua resource Compute Engine yang relevan, seperti proxy tengah, resource Cloud Service Mesh, zona Cloud DNS, dan konektivitas hybrid, dilampirkan ke jaringan Virtual Private Cloud (VPC) default.
- Layanan
example.com:443
berjalan di infrastruktur lokal Anda. Domainexample.com
ditayangkan oleh tiga endpoint,10.0.0.100
,10.0.0.101
, dan10.0.0.102
. Ada rute yang memastikan konektivitas dari proxy Envoy ke endpoint jarak jauh ini.
Deployment yang dihasilkan mirip dengan berikut ini.
Pemilihan rute traffic dengan NEG internet dan TLS dengan SNI
Setelah Anda mengonfigurasi Cloud Service Mesh dengan NEG internet menggunakan FQDN dan TLS untuk traffic keluar, contoh deployment akan berperilaku seperti yang diilustrasikan dalam diagram dan deskripsi traffic berikut.
Langkah-langkah dalam legenda berikut sesuai dengan penomoran dalam diagram sebelumnya.
Langkah | Deskripsi |
---|---|
0 | Envoy menerima konfigurasi backend FQDN dari Cloud Service Mesh melalui xDS. |
0 | Envoy, yang berjalan di VM, terus mengkueri DNS untuk FQDN yang dikonfigurasi. |
1 | Aplikasi pengguna memulai permintaan. |
2 | Parameter permintaan. |
3 | Proxy Envoy akan mencegat permintaan. Contoh ini mengasumsikan bahwa Anda menggunakan 0.0.0.0 sebagai alamat IP virtual (VIP) aturan penerusan. Jika 0.0.0.0 adalah VIP, Envoy akan mencegat semua
permintaan. Pemilihan rute permintaan hanya didasarkan pada parameter Lapisan 7,
terlepas dari alamat IP tujuan dalam permintaan asli
yang dihasilkan oleh aplikasi. |
4 | Envoy memilih endpoint jarak jauh yang sehat dan melakukan handshake TLS dengan SNI yang diperoleh dari kebijakan TLS klien. |
5 | Envoy melakukan proxy permintaan ke endpoint jarak jauh. |
Ini tidak ditampilkan dalam diagram, tetapi jika health check dikonfigurasi, Envoy akan terus melakukan health check pada endpoint jarak jauh dan merutekan permintaan hanya ke endpoint yang responsif.
Menyiapkan konektivitas hybrid
Dokumen ini juga mengasumsikan bahwa konektivitas hybrid sudah dibuat:
- Konektivitas hybrid antara jaringan VPC dan layanan lokal atau cloud publik pihak ketiga dibuat dengan Cloud VPN atau Cloud Interconnect.
- Aturan dan rute firewall VPC dikonfigurasi dengan benar untuk menetapkan keterjangkauan dua arah dari Envoy ke endpoint layanan pribadi dan, secara opsional, ke server DNS lokal.
- Untuk skenario failover HA regional yang berhasil, perutean dinamis global diaktifkan. Untuk mengetahui detail selengkapnya, lihat mode pemilihan rute dinamis.
Menyiapkan konfigurasi Cloud DNS
Gunakan perintah berikut untuk menyiapkan zona pribadi Cloud DNS untuk domain (FQDN) example.com
yang memiliki data A
yang mengarah ke endpoint 10.0.0.100
, 10.0.0.101
, 10.0.0.102
, dan 10.0.0.103
.
gcloud
- Buat zona pribadi yang dikelola DNS dan lampirkan ke jaringan default:
gcloud dns managed-zones create example-zone \ --description=test \ --dns-name=example.com \ --networks=default \ --visibility=private
- Tambahkan data DNS ke zona pribadi:
gcloud dns record-sets transaction start \ --zone=example-zone gcloud dns record-sets transaction add 10.0.0.100 10.0.0.101 10.0.0.102 10.0.0.103 \ --name=example.com \ --ttl=300 \ --type=A \ --zone=example-zone gcloud dns record-sets transaction execute \ --zone=example-zone
Mengonfigurasi Cloud Service Mesh dengan NEG FQDN internet
Di bagian ini, Anda akan mengonfigurasi Cloud Service Mesh dengan NEG FQDN internet.
Membuat NEG, health check, dan layanan backend
gcloud
- Buat NEG internet:
gcloud compute network-endpoint-groups create on-prem-service-a-neg \ --global \ --network-endpoint-type INTERNET_FQDN_PORT
- Tambahkan endpoint
FQDN:Port
ke NEG internet:
gcloud compute network-endpoint-groups update on-prem-service-a-neg \ --global \ --add-endpoint=fqdn=example.com,port=443
- Membuat health check global:
gcloud compute health-checks create http service-a-http-health-check \ --global
- Buat layanan backend global bernama
on-prem-service-a
dan kaitkan health check dengan layanan tersebut:
gcloud compute backend-services create on-prem-service-a \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --health-checks service-a-http-health-check
- Tambahkan NEG yang disebut
on-prem-service-a-neg
sebagai backend layanan backend:
gcloud compute backend-services add-backend on-prem-service-a \ --global \ --global-network-endpoint-group \ --network-endpoint-group on-prem-service-a-neg
Membuat peta aturan perutean
Peta URL, proxy HTTP target, dan aturan penerusan membentuk peta aturan perutean, yang memberikan informasi perutean untuk traffic di mesh Anda.
Peta URL ini berisi aturan yang merutekan semua traffic HTTP ke
on-prem-service-a
.
gcloud
- Buat peta URL:
gcloud compute url-maps create td-url-map \ --default-service on-prem-service-a
- Buat proxy HTTP target dan kaitkan peta URL dengan proxy target:
gcloud compute target-http-proxies create td-proxy \ --url-map td-url-map
- Buat aturan penerusan global menggunakan alamat IP
0.0.0.0
. Ini adalah alamat IP khusus yang menyebabkan bidang data Anda mengabaikan alamat IP tujuan dan merutekan permintaan hanya berdasarkan parameter HTTP permintaan.
gcloud compute forwarding-rules create td-forwarding-rule \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --address=0.0.0.0 \ --target-http-proxy=td-proxy \ --ports=443 \ --network=default
Mengonfigurasi TLS dan HTTPS yang tidak diautentikasi
Secara opsional, jika Anda ingin mengonfigurasi HTTPS tanpa autentikasi antara proxy Envoy dan layanan lokal, gunakan petunjuk ini. Petunjuk ini juga menunjukkan cara mengonfigurasi SNI dalam TLS handshake.
Kebijakan TLS klien menentukan identitas klien dan mekanisme autentikasi
saat klien mengirimkan permintaan keluar ke layanan tertentu. Kebijakan TLS klien
disertakan ke resource layanan backend menggunakan kolom
securitySettings
.
gcloud
- Buat dan impor kebijakan TLS klien; tetapkan SNI ke FQDN yang Anda konfigurasikan di NEG:
cat << EOF > client_unauthenticated_tls_policy.yaml name: "client_unauthenticated_tls_policy" sni: "example.com" EOF gcloud beta network-security client-tls-policies import client_unauthenticated_tls_policy \ --source=client_unauthenticated_tls_policy.yaml \ --location=global
- Jika Anda mengonfigurasi health check
HTTP
dengan layanan backend di bagian sebelumnya, lepaskan health check dari layanan backend:
gcloud compute backend-services update on-prem-service-a \ --global \ --no-health-checks
- Buat health check
HTTPS
:
gcloud compute health-checks create https service-a-https-health-check \ --global
- Lampirkan kebijakan TLS klien ke layanan backend yang Anda buat sebelumnya; tindakan ini akan menerapkan HTTPS yang tidak diautentikasi pada semua permintaan keluar dari klien ke layanan backend ini:
gcloud compute backend-services export on-prem-service-a \ --global \ --destination=on-prem-service-a.yaml cat << EOF >> on-prem-service-a.yaml securitySettings: clientTlsPolicy: projects/${PROJECT_ID}/locations/global/clientTlsPolicies/client_unauthenticated_tls_policy healthChecks: - projects/${PROJECT_ID}/global/healthChecks/service-a-https-health-check EOF gcloud compute backend-services import on-prem-service-a \ --global \ --source=on-prem-service-a.yaml
Anda dapat menggunakan NEG FQDN internet untuk merutekan traffic ke layanan apa pun yang dapat dijangkau melalui FQDN—misalnya, layanan eksternal dan internal yang dapat di-resolve DNS atau layanan Cloud Run.
Bermigrasi dari NEG IP:Port
ke NEG FQDN:Port
NEG NON_GCP_PRIVATE_IP_PORT
mengharuskan Anda memprogram endpoint layanan ke dalam
NEG sebagai pasangan IP:PORT
statis, sedangkan INTERNET_FQDN_NEG
memungkinkan endpoint
di-resolve secara dinamis menggunakan DNS. Anda dapat bermigrasi ke NEG internet dengan
menyiapkan data DNS untuk endpoint layanan lokal dan mengonfigurasi
Cloud Service Mesh seperti yang dijelaskan dalam langkah-langkah berikut:
- Siapkan data DNS untuk FQDN Anda.
- Buat NEG internet baru dengan FQDN.
- Buat layanan backend baru dengan NEG internet yang Anda buat pada langkah 2 sebagai backend-nya. Kaitkan health check yang sama dengan yang Anda gunakan dengan layanan backend NEG konektivitas campuran dengan layanan backend baru. Verifikasi bahwa endpoint jarak jauh baru responsif.
- Perbarui peta aturan pemilihan rute untuk mereferensikan layanan backend baru dengan mengganti backend lama yang menyertakan NEG konektivitas campuran.
- Jika ingin tidak ada periode nonaktif selama migrasi langsung dalam deployment produksi,
Anda dapat menggunakan traffic berbasis bobot. Awalnya, konfigurasikan layanan backend baru Anda
agar hanya menerima sebagian kecil traffic, misalnya, 5%. Gunakan
petunjuk untuk menyiapkan pemisahan
traffic.
- Pastikan endpoint jarak jauh baru menayangkan traffic dengan benar.
- Jika Anda menggunakan pembagian traffic berbasis berat, konfigurasikan layanan backend baru untuk menerima 100% traffic. Langkah ini menghabiskan layanan backend lama.
- Setelah Anda memverifikasi bahwa backend baru menayangkan traffic tanpa masalah, hapus layanan backend lama.
Pemecahan masalah
Untuk mengatasi masalah deployment, gunakan petunjuk di bagian ini. Jika masalah Anda tidak terselesaikan dengan informasi ini, lihat Memecahkan masalah deployment yang menggunakan Envoy.
Endpoint lokal tidak menerima traffic
Jika endpoint tidak menerima traffic, pastikan endpoint tersebut lulus pemeriksaan kondisi, dan kueri DNS dari klien Envoy menampilkan alamat IP-nya secara konsisten.
Envoy menggunakan mode strict_dns
untuk mengelola koneksi. Load balancer ini melakukan load balancing traffic
di semua endpoint yang di-resolve dan responsif. Urutan resolusi endpoint tidak penting dalam mode strict_dns
, tetapi Envoy menghabiskan traffic ke endpoint apa pun yang tidak lagi ada dalam daftar alamat IP yang ditampilkan.
Header host HTTP tidak cocok dengan FQDN saat permintaan mencapai server lokal saya
Pertimbangkan contoh saat domain example.com
me-resolve ke 10.0.0.1
,
yang merupakan alamat IP aturan penerusan, dan domain altostrat.com
me-resolve ke 10.0.0.100
, yang merupakan endpoint layanan on-premise Anda. Anda ingin mengirim traffic ke domain altostrat.com
, yang dikonfigurasi di NEG.
Aplikasi di Compute Engine atau GKE mungkin menetapkan header Host
HTTP ke example.com
(Host:
example.com
), yang akan diteruskan ke endpoint lokal. Jika Anda menggunakan HTTPS, Envoy akan menetapkan SNI ke altostrat.com
selama TLS handshake.
Envoy mendapatkan SNI dari resource kebijakan TLS klien.
Jika konflik ini menyebabkan masalah dalam memproses atau merutekan permintaan saat
mencapai endpoint on-premise, sebagai solusinya, Anda dapat menulis ulang header Host
ke altostrat.com
(Host: altostrat.com
). Hal ini dapat dilakukan di
Cloud Service Mesh menggunakan penulisan ulang URL atau di endpoint jarak jauh jika
memiliki kemampuan penulisan ulang header.
Solusi lain yang tidak terlalu rumit adalah menetapkan header Host
ke altostrat.com
(Host: altostrat.com
) dan menggunakan alamat khusus 0.0.0.0
sebagai alamat IP
aturan penerusan.
Envoy menampilkan banyak error 5xx
Jika Envy menampilkan error 5xx dalam jumlah yang berlebihan, lakukan tindakan berikut:
- Periksa log Envoy untuk membedakan apakah respons berasal dari backend (backend on-premise) dan apa alasan error 5xx.
- Pastikan kueri DNS berhasil, dan tidak ada error
SERVFAIL
atauNXDOMAIN
. - Pastikan semua endpoint jarak jauh lulus pemeriksaan kesehatan.
- Jika health check tidak dikonfigurasi, pastikan semua endpoint dapat dijangkau dari Envoy. Periksa aturan dan rute firewall Anda di sisi Google Cloud serta di sisi lokal.
Tidak dapat menjangkau layanan eksternal melalui internet publik dari mesh layanan
Anda dapat mengirim traffic ke layanan yang berada di internet publik menggunakan backend FQDN di Cloud Service Mesh. Anda harus terlebih dahulu membuat konektivitas internet
antara klien Envoy dan layanan eksternal. Jika Anda mendapatkan
error 502
selama koneksi ke layanan eksternal, lakukan tindakan berikut:
- Pastikan Anda memiliki rute yang benar, khususnya rute default
0.0.0.0/0
, dan aturan firewall yang dikonfigurasi. - Pastikan kueri DNS berhasil, dan tidak ada error
SERVFAIL
atauNXDOMAIN
. - Jika proxy Envoy berjalan di VM Compute Engine yang tidak memiliki alamat IP eksternal atau di cluster GKE pribadi, Anda harus mengonfigurasi Cloud NAT atau cara lain untuk membuat konektivitas internet keluar.
Jika error berlanjut, atau jika Anda mendapatkan error 5xx lainnya, periksa log Envoy untuk mempersempit sumber error.
Tidak dapat menjangkau layanan Serverless dari mesh layanan
Anda dapat mengirim traffic ke layanan Serverless (Cloud Run, fungsi Cloud Run, dan App Engine) menggunakan backend FQDN di Cloud Service Mesh. Jika proxy Envoy berjalan di VM Compute Engine yang tidak memiliki alamat IP eksternal atau di cluster GKE pribadi, Anda harus mengonfigurasi Akses Google Pribadi di subnet agar dapat mengakses Google API dan layanan Google.
Langkah selanjutnya
- Untuk mempelajari kebijakan TLS klien lebih lanjut, lihat keamanan layanan Cloud Service Mesh dan Network Security API.