Menyiapkan backend eksternal

Dokumen ini berisi petunjuk untuk mengonfigurasi backend eksternal untuk Traffic Director dengan menggunakan grup endpoint jaringan (NEG) nama domain yang sepenuhnya memenuhi syarat (FQDN) internet. Diasumsikan bahwa Anda memiliki pemahaman tingkat menengah hingga lanjutan terhadap hal-hal berikut:

Panduan penyiapan ini menyediakan petunjuk dasar untuk hal berikut:

  • Mengonfigurasi Traffic Director agar menggunakan NEG internet dan TLS yang tidak diautentikasi untuk traffic keluar
  • Merutekan traffic ke layanan Cloud Run dari mesh layanan Anda

Sebelum memulai

Tinjau ringkasan Traffic Director dengan grup endpoint jaringan internet.

Untuk tujuan panduan ini, contoh konfigurasi mengasumsikan hal berikut:

  • Semua resource Compute Engine yang relevan, seperti proxy tengah, resource Traffic Director, zona Cloud DNS, dan konektivitas hybrid, dilampirkan ke jaringan Virtual Private Cloud (VPC) default.
  • Layanan example.com:443 berjalan di infrastruktur lokal Anda. Domain example.com ditayangkan oleh tiga endpoint, 10.0.0.100, 10.0.0.101, dan 10.0.0.102. Terdapat rute yang memastikan konektivitas dari proxy Envoy ke endpoint jarak jauh ini.

Deployment yang dihasilkan mirip dengan berikut ini.

Contoh penyiapan dengan NEG internet.
Contoh penyiapan dengan NEG internet (klik untuk memperbesar)

Pemilihan rute traffic dengan NEG internet dan TLS dengan SNI

Setelah Anda mengonfigurasi Traffic Director dengan NEG internet menggunakan FQDN dan TLS untuk traffic keluar, contoh deployment akan berperilaku seperti yang ditunjukkan dalam diagram dan deskripsi traffic berikut.

Cara lalu lintas dirutekan pada contoh.
Cara traffic dirutekan pada contoh (klik untuk memperbesar)

Langkah-langkah dalam legenda berikut sesuai dengan penomoran dalam diagram sebelumnya.

Langkah Deskripsi
0 Envoy menerima konfigurasi backend FQDN dari Traffic Director 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 mencegat permintaan tersebut. 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. Perutean permintaan hanya didasarkan pada parameter Lapisan 7, apa pun 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.

Hal 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 dengan ketersediaan tinggi (HA) regional yang sukses, perutean dinamis global diaktifkan. Untuk detail selengkapnya, lihat mode pemilihan rute dinamis.

Menyiapkan konfigurasi Cloud DNS

Gunakan perintah berikut untuk menyiapkan zona pribadi Cloud DNS untuk example.com domain (FQDN) 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

  1. Buat zona pribadi terkelola DNS dan lampirkan ke jaringan default:

    gcloud dns managed-zones create example-zone \
    --description=test \
    --dns-name=example.com \
    --networks=default \
    --visibility=private

  2. 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 Traffic Director dengan FQDN NEG internet

Di bagian ini, Anda akan mengonfigurasi Traffic Director dengan NEG FQDN internet.

Membuat layanan NEG, health check, dan backend

gcloud

  1. Buat NEG internet:

    gcloud compute network-endpoint-groups create on-prem-service-a-neg \
    --global \
    --network-endpoint-type INTERNET_FQDN_PORT

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

  3. Membuat health check global:

    gcloud compute health-checks create http service-a-http-health-check \
    --global

  4. Buat layanan backend global yang disebut 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

  5. 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 merupakan peta aturan perutean, yang menyediakan informasi perutean untuk traffic di mesh Anda.

Peta URL ini berisi aturan yang mengarahkan semua traffic HTTP ke on-prem-service-a.

gcloud

  1. Membuat peta URL:

    gcloud compute url-maps create td-url-map \
    --default-service on-prem-service-a

  2. Buat proxy HTTP target dan kaitkan peta URL dengan proxy target:

    gcloud compute target-http-proxies create td-proxy \
    --url-map td-url-map

  3. 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 permintaan rute 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 yang tidak diautentikasi antara proxy Envoy dan layanan lokal Anda, gunakan petunjuk ini. Petunjuk ini juga menunjukkan cara mengonfigurasi SNI di handshake TLS.

Kebijakan TLS klien menentukan mekanisme autentikasi dan identitas klien saat klien mengirim permintaan keluar ke layanan tertentu. Kebijakan TLS klien dilampirkan ke resource layanan backend menggunakan kolom securitySettings.

gcloud

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

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

  3. Buat health check HTTPS:

    gcloud compute health-checks create https service-a-https-health-check \
    --global

  4. 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 diselesaikan 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 Anda dan mengonfigurasi Traffic Director seperti yang dijelaskan dalam langkah-langkah berikut:

  1. Siapkan data DNS untuk FQDN.
  2. Buat NEG internet baru dengan FQDN.
  3. Buat layanan backend baru dengan NEG internet yang Anda buat di langkah 2 sebagai backend-nya. Kaitkan health check yang sama dengan yang Anda gunakan dengan layanan backend NEG konektivitas hybrid dengan layanan backend baru. Pastikan endpoint jarak jauh yang baru responsif.
  4. Perbarui peta aturan perutean Anda untuk mereferensikan layanan backend baru dengan mengganti backend lama yang menyertakan NEG konektivitas hybrid.
  5. Jika Anda tidak menginginkan periode nonaktif selama migrasi langsung dalam deployment produksi, Anda dapat menggunakan traffic berbasis bobot. Pertama-tama, konfigurasikan layanan backend baru Anda untuk hanya menerima sebagian kecil traffic, misalnya 5%. Gunakan petunjuk untuk menyiapkan pemisahan traffic.
  6. Pastikan endpoint jarak jauh yang baru menayangkan traffic dengan benar.
  7. Jika Anda menggunakan pembagian traffic berbasis bobot, konfigurasikan layanan backend baru untuk menerima 100% traffic. Langkah ini akan menghabiskan layanan backend lama.
  8. Setelah Anda memverifikasi bahwa backend baru menyalurkan traffic tanpa masalah, hapus layanan backend lama.

Pemecahan masalah

Untuk menyelesaikan 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 health check, dan kueri DNS dari klien Envoy menampilkan alamat IP-nya secara konsisten.

Envoy menggunakan mode strict_dns untuk mengelola koneksi. Load balancer ini menyeimbangkan traffic di semua endpoint yang di-resolve dan responsif. Urutan endpoint diselesaikan tidak menjadi masalah dalam mode strict_dns, tetapi Envoy menguras 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 di mana domain example.com di-resolve ke 10.0.0.1, yang merupakan alamat IP aturan penerusan, dan domain altostrat.com di-resolve ke 10.0.0.100, yang merupakan endpoint layanan lokal Anda. Anda ingin mengirim traffic ke domain altostrat.com, yang dikonfigurasi di NEG Anda.

Ada kemungkinan bahwa aplikasi di Compute Engine atau GKE menetapkan header Host HTTP ke example.com (Host: example.com), yang akan diteruskan ke endpoint lokal. Jika Anda menggunakan HTTPS, Envoy menyetel SNI ke altostrat.com selama handshake TLS. Envoy memperoleh SNI dari sumber daya kebijakan TLS klien.

Jika konflik ini menyebabkan masalah dalam pemrosesan atau pemilihan rute permintaan saat sampai di endpoint lokal, sebagai solusinya, Anda dapat menulis ulang header Host menjadi altostrat.com (Host: altostrat.com). Hal ini dapat dilakukan di Traffic Director dengan menggunakan penulisan ulang URL atau pada endpoint jarak jauh jika memiliki kemampuan penulisan ulang header.

Solusi yang tidak terlalu kompleks lainnya 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 jumlah error 5xx yang berlebihan, lakukan hal berikut:

  • Periksa log Envoy untuk membedakan apakah respons berasal dari backend (backend lokal) dan apa alasan error 5xx.
  • Pastikan kueri DNS berhasil, dan tidak ada error SERVFAIL atau NXDOMAIN.
  • Pastikan semua endpoint jarak jauh lulus health check.
  • Jika health check tidak dikonfigurasi, pastikan semua endpoint dapat dijangkau dari Envoy. Periksa aturan firewall dan rute 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 terletak di internet publik menggunakan backend FQDN di Traffic Director. Anda harus terlebih dahulu menetapkan konektivitas internet antara klien Envoy dan layanan eksternal. Jika Anda mendapatkan error 502 saat terhubung ke layanan eksternal, lakukan hal 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 atau NXDOMAIN.
  • 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 masih 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, Cloud Functions, dan App Engine) menggunakan backend FQDN di Traffic Director. Jika proxy Envoy berjalan pada VM Compute Engine yang tidak memiliki alamat IP eksternal atau di cluster GKE pribadi, Anda perlu mengonfigurasi Akses Google Pribadi di subnet agar dapat mengakses Google API dan layanan Google.

Langkah selanjutnya