Menyiapkan backend eksternal dengan grup endpoint jaringan internet

Dokumen ini memberikan petunjuk konfigurasi backend eksternal Cloud Service Mesh dengan menggunakan internet network endpoint groups (NEG), yang memerlukan nama domain yang sepenuhnya memenuhi syarat. Dokumen ini ditujukan bagi pengguna yang memiliki tingkat pemahaman menengah hingga lanjutan mengenai hal-hal berikut:

Panduan penyiapan ini memberikan petunjuk dasar untuk hal berikut:

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

Sebelum memulai

Tinjau Cloud Service Mesh dengan endpoint jaringan internet grup.

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 lingkungan hybrid konektivitas pribadi, terhubung ke Virtual Private Cloud (VPC) default jaringan.
  • Layanan example.com:443 berjalan di infrastruktur lokal Anda. Domain example.com dilayani oleh tiga endpoint, yaitu 10.0.0.100, 10.0.0.101, dan 10.0.0.102. Terdapat rute yang memastikan konektivitas dari {i>proxy<i} 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 Cloud Service Mesh dengan NEG internet menggunakan FQDN dan TLS untuk lalu lintas keluar, contoh penerapan berperilaku sebagai diilustrasikan dalam diagram dan deskripsi traffic berikut.

Bagaimana lalu lintas dirutekan dalam contoh.
Cara lalu lintas dirutekan dalam contoh (klik untuk memperbesar)

Langkah-langkah dalam legenda berikut sesuai dengan penomoran pada keterangan seperti diagram.

Langkah Deskripsi
0 Envoy menerima konfigurasi backend FQDN dari Cloud Service Mesh melalui xDS.
0 Envoy, yang berjalan di VM, terus-menerus mengkueri DNS untuk FQDN
1 Aplikasi pengguna memulai permintaan.
2 Parameter permintaan.
3 Proxy Envoy mencegat permintaan. Contoh ini mengasumsikan bahwa Anda menggunakan 0.0.0.0 sebagai IP virtual aturan penerusan (VIP). Ketika 0.0.0.0 adalah VIP, Envoy mencegat semua permintaan. Perutean 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 menjalankan proxy permintaan ke endpoint jarak jauh.

Error ini tidak ditampilkan dalam diagram, tetapi jika health check dikonfigurasi, Envoy secara terus-menerus melakukan health check pada endpoint jarak jauh dan permintaan rute hanya ke endpoint yang responsif.

Menyiapkan konektivitas hybrid

Dokumen ini juga mengasumsikan bahwa konektivitas hybrid sudah terbentuk:

  • Konektivitas hybrid antara jaringan VPC dan lokal atau cloud publik pihak ketiga dibangun dengan Cloud VPN atau dan Cloud Interconnect.
  • Aturan dan rute firewall VPC dikonfigurasi dengan benar untuk membangun keterjangkauan dua arah dari Envoy ke layanan pribadi endpoint dan, secara opsional, ke server DNS lokal.
  • Untuk skenario failover HA regional yang sukses, perutean dinamis global mengaktifkan pembuatan versi. Untuk detail selengkapnya, lihat perutean dinamis mode.

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

  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
  1. 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 FQDN internet NEG.

Membuat NEG, health check, dan layanan backend

gcloud

  1. Buat NEG internet:
    gcloud compute network-endpoint-groups create on-prem-service-a-neg \
        --global \
        --network-endpoint-type INTERNET_FQDN_PORT
  1. Tambahkan endpoint FQDN:Port ke internet NEG:
    gcloud compute network-endpoint-groups update on-prem-service-a-neg \
        --global \
        --add-endpoint=fqdn=example.com,port=443
  1. Membuat health check global:
    gcloud compute health-checks create http service-a-http-health-check \
        --global
  1. Membuat layanan backend global yang disebut on-prem-service-a dan mengaitkan health check dengannya:
    gcloud compute backend-services create on-prem-service-a \
        --global \
        --load-balancing-scheme=INTERNAL_SELF_MANAGED \
        --health-checks service-a-http-health-check
  1. Tambahkan NEG bernama on-prem-service-a-neg sebagai backend backend layanan:
    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 aturan perutean {i>map <i}yang menyediakan informasi {i>routing<i} untuk lalu lintas di {i>mesh<i} Anda.

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

gcloud

  1. Buat peta URL:
    gcloud compute url-maps create td-url-map \
        --default-service on-prem-service-a
  1. Membuat proxy HTTP target dan mengaitkan peta URL dengan target {i>proxy<i}:
    gcloud compute target-http-proxies create td-proxy \
        --url-map td-url-map
  1. Buat aturan penerusan global dengan 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 didasarkan pada Parameter HTTP.
    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 Envoy untuk menggunakan proxy dan layanan lokal Anda, gunakan petunjuk ini. Ini juga menunjukkan cara mengkonfigurasi SNI di TLS handshake.

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

gcloud

  1. Membuat dan mengimpor kebijakan TLS klien; mengatur SNI ke FQDN yang 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
  1. Jika Anda mengonfigurasi health check HTTP dengan layanan backend di sebelumnya, lepaskan health check dari layanan backend:
    gcloud compute backend-services update on-prem-service-a \
        --global \
        --no-health-checks
  1. Buat health check HTTPS:
    gcloud compute health-checks create https service-a-https-health-check \
        --global
  1. 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 mengarahkan traffic ke layanan mana pun yang dapat dijangkau melalui FQDN—misalnya, layanan eksternal dan internal DNS yang dapat diselesaikan atau layanan Cloud Run.

Bermigrasi dari IP:Port NEG ke FQDN:Port NEG

NON_GCP_PRIVATE_IP_PORT NEG mengharuskan Anda memprogram endpoint layanan ke NEG sebagai pasangan IP:PORT statis, sedangkan INTERNET_FQDN_NEG memungkinkan endpoint menjadi diselesaikan secara dinamis dengan 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:

  1. Siapkan data DNS untuk FQDN Anda.
  2. Buat NEG internet baru dengan FQDN.
  3. 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 hybrid dengan layanan backend baru. Verifikasi bahwa endpoint jarak jauh yang baru responsif.
  4. Perbarui peta aturan perutean Anda untuk merujuk layanan backend baru dengan mengganti backend lama yang menyertakan NEG konektivitas hybrid.
  5. Jika Anda menginginkan nol periode nonaktif selama migrasi langsung dalam deployment produksi, Anda dapat menggunakan traffic berbasis bobot. Pertama-tama, konfigurasikan backend baru Anda layanan untuk menerima sebagian kecil traffic, misalnya, 5%. Gunakan petunjuk untuk menyiapkan traffic pemisahan.
    1. Pastikan endpoint jarak jauh yang baru menyalurkan traffic dengan benar.
  6. Jika Anda menggunakan pemisahan traffic berbasis bobot, konfigurasikan backend baru untuk menerima 100% traffic. Langkah ini menghabiskan backend lama layanan.
  7. Setelah Anda memverifikasi bahwa backend baru melayani traffic tanpa masalah, hapus layanan backend lama.

Pemecahan masalah

Untuk menyelesaikan masalah deployment, gunakan petunjuk di bagian ini. Jika masalah tidak diselesaikan dengan informasi ini, lihat Memecahkan masalah deployment yang menggunakan Envoy.

Endpoint lokal tidak menerima traffic

Jika endpoint tidak menerima traffic, pastikan endpoint tersebut meneruskan respons memeriksa, dan bahwa kueri DNS dari klien Envoy mengembalikan alamat IP-nya secara konsisten.

Envoy menggunakan mode strict_dns untuk mengelola koneksi. Load balancer ini menyeimbangkan traffic di semua endpoint yang telah diselesaikan yang responsif. Urutan endpoint diselesaikan tidak masalah dalam mode strict_dns, tetapi Envoy menghabiskan traffic ke endpoint yang tidak lagi ada dalam daftar alamat IP yang ditampilkan.

Header host HTTP tidak cocok dengan FQDN saat permintaan mencapai server lokal saya

Perhatikan contoh saat domain example.com di-resolve menjadi 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 lokal Anda. Anda ingin untuk mengirim traffic ke domain altostrat.com, yang dikonfigurasi di NEG Anda.

Mungkin saja aplikasi di Compute Engine atau GKE menetapkan header Host HTTP ke example.com (Host: example.com), yang diteruskan ke endpoint lokal. Jika Anda menggunakan HTTPS, Envoy menetapkan SNI ke altostrat.com selama TLS handshake. Envoy memperoleh SNI dari referensi kebijakan TLS klien.

Jika konflik ini menyebabkan masalah dalam pemrosesan atau perutean permintaan saat terjadi mencapai endpoint lokal. Sebagai solusinya, Anda dapat menulis ulang Host header ke altostrat.com (Host: altostrat.com). Ini dapat dilakukan di Cloud Service Mesh dengan 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 gunakan alamat khusus 0.0.0.0 sebagai alamat penerusan alamat IP aturan.

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 SERVFAIL atau NXDOMAIN error.
  • Pastikan semua endpoint jarak jauh lulus health check.
  • Jika health check tidak dikonfigurasi, pastikan semua endpoint dapat dihubungi dari Envoy. Periksa aturan firewall dan rute Anda pada baik di sisi Google Cloud maupun 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 dengan menggunakan FQDN backend di Cloud Service Mesh. Anda harus menghubungkan internet terlebih dahulu konektivitas antara klien Envoy dan layanan eksternal. Jika Anda mendapatkan error 502 selama koneksi ke layanan eksternal, lakukan hal berikut:

  • Pastikan Anda memiliki rute yang benar, khususnya rute default 0.0.0.0/0, dan aturan firewall dikonfigurasi.
  • Pastikan kueri DNS berhasil, dan tidak ada SERVFAIL atau NXDOMAIN error.
  • Jika proxy Envoy berjalan di VM Compute Engine yang tidak memiliki alamat IP eksternal atau di cluster GKE pribadi, Anda mengonfigurasi Cloud NAT atau cara lain untuk membangun konektivitas internet.

Jika error tetap berlanjut, atau jika Anda mendapatkan error 5xx lainnya, periksa Envoy log untuk mempersempit sumber error.

Tidak dapat menjangkau layanan Serverless dari mesh layanan

Anda dapat mengirim traffic ke 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 dalam cluster GKE pribadi, Anda perlu mengonfigurasi Akses Google Pribadi di subnet agar dapat mengakses Google API dan layanan IT perusahaan mereka.

Langkah selanjutnya