Mengonfigurasi Load Balancer Aplikasi klasik untuk Cloud Service Mesh
Ringkasan
Dokumen ini ditujukan untuk Anda jika Anda adalah pengguna Cloud Service Mesh yang sudah ada dan memiliki bidang kontrol terkelola Istiod dan ingin mengonfigurasi Load Balancer Aplikasi klasik sebagai gateway masuk. Load Balancer Aplikasi klasik juga dikenal sebagai Load Balancer Aplikasi eksternal klasik.
Jangan gunakan dokumen ini jika Anda adalah pengguna Cloud Service Mesh baru. Pengguna baru otomatis disiapkan dengan bidang kontrol terkelola Traffic Director. Anda tidak dapat menggunakan konfigurasi yang dijelaskan dalam dokumen ini dengan bidang kontrol terkelola Cloud Service Mesh
Cloud Load Balancing menyediakan banyak kemampuan edge yang dikelola cloud termasuk load balancing anycast global, sertifikat yang dikelola Google Identity and Access Management, Cloud Next Generation Firewall, dan Cloud Intrusion Detection System. Cloud Service Mesh dapat mengintegrasikan kemampuan edge ini dengan lancar dalam model masuk mesh berikut. Gateway cloud mesh layanan menyediakan cara terpadu untuk mengonfigurasi gateway masuk Cloud Service Mesh dengan Cloud Load Balancing secara bersamaan melalui Kubernetes Gateway API.
Dibandingkan dengan panduan pengguna kami sebelumnya, Dari edge ke mesh: Mengekspos aplikasi mesh layanan melalui Traffic masuk GKE, dengan gateway cloud mesh layanan, model ini kini dapat di-deploy melalui satu resource Kubernetes Gateway yang menyederhanakan proses deployment load balancing yang dihosting cloud dan cluster secara bersamaan.
Batasan pratinjau
Untuk rilis Pratinjau fitur ini, batasan berikut berlaku:
- Gateway Multi-cluster tidak didukung.
- Cluster Autopilot tidak didukung.
- Hanya Load Balancer Aplikasi klasik yang didukung. Load Balancer Aplikasi eksternal global (terkadang disebut Load Balancer Lanjutan) dan Load Balancer Aplikasi internal tidak didukung.
- Traffic antara Load Balancer Aplikasi klasik dan gateway masuk Cloud Service Mesh dienkripsi menggunakan TLS. Namun, Load Balancer Aplikasi klasik tidak akan memverifikasi sertifikat yang disediakan oleh gateway masuk Cloud Service Mesh. Batasan ini berlaku untuk semua pengguna Google Cloud Load Balancer HTTP(S).
- Jika
GatewayClassesCloud Service Mesh dihapus dari cluster,GatewayClassestersebut tidak akan diinstal ulang secara otomatis. Namun, hal ini tidak akan memengaruhi kegunaan fitur. - Logika pencocokan rute tidak mengikuti
spesifikasi Gateway API
dan cocok dalam urutan
HTTPRoutesebagai gantinya. Hal ini akan berubah pada versi mendatang untuk mengikuti spesifikasi Gateway API.
Persyaratan
- Cloud Service Mesh terkelola yang diinstal di cluster Google Kubernetes Engine (GKE) yang menjalankan 1.24 atau yang lebih baru. Cluster GKE Enterprise lainnya tidak didukung.
- Hanya versi Kubernetes Gateway API v1beta1.
Prasyarat
Aktifkan API berikut di project Anda:
- compute.googleapis.com
- container.googleapis.com
- certificatemanager.googleapis.com
- serviceusage.googleapis.com
gcloud services enable \ compute.googleapis.com \ container.googleapis.com \ certificatemanager.googleapis.com \ serviceusage.googleapis.com
Men-deploy gateway cloud mesh layanan untuk mesh satu cluster
Bagian ini menunjukkan cara men-deploy resource Kubernetes Gateway yang men-deploy Load Balancer Aplikasi klasik dan gateway masuk Cloud Service Mesh.
Mengaktifkan Gateway API dengan Cloud Service Mesh terkelola
Aktifkan Gateway API di cluster Anda. Cluster GKE harus versi 1.24 atau yang lebih baru.
Instal Cloud Service Mesh terkelola dengan
rapidatauregularsebagai saluran rilisnya.
Men-deploy resource Gateway
Saat men-deploy gateway cloud mesh layanan, resource Kubernetes Gateway digunakan untuk men-deploy Cloud Load Balancing dan gateway masuk Cloud Service Mesh sebagai satu langkah. Perhatikan bahwa resource Kubernetes Gateway berbeda dengan resource Istio Gateway.
Untuk mengetahui informasi selengkapnya tentang perbedaannya, lihat Gateway Kubernetes dan Gateway Istio. Setiap Gateway Kubernetes memiliki GatewayClass yang menunjukkan jenis dan kemampuan bawaannya. Gateway cloud mesh layanan memiliki GatewayClass yang memiliki kemampuan untuk men-deploy Cloud Load Balancing dan gateway masuk Cloud Service Mesh.
Simpan manifes GatewayClass berikut ke file bernama
l7-gateway-class.yaml:apiVersion: gateway.networking.k8s.io/v1beta1 kind: GatewayClass metadata: name: asm-l7-gxlb spec: controllerName: mesh.cloud.google.com/gatewayDeploy GatewayClass di cluster Anda:
kubectl apply -f l7-gateway-class.yamlPastikan GatewayClass ada setelah penginstalan:
kubectl get gatewayclasses.gateway.networking.k8s.ioOutputnya mirip dengan:
NAME CONTROLLER asm-l7-gxlb mesh.cloud.google.com/gateway gke-l7-rilb networking.gke.io/gateway gke-l7-gxlb networking.gke.io/gatewayMungkin perlu waktu beberapa menit agar semua resource di-deploy. Jika Anda tidak melihat output yang diharapkan, pastikan Anda telah memenuhi prasyaratdengan benar.
Anda juga akan melihat GatewayClass berikut:
gke-l7-gxlb networking.gke.io/gatewayIni digunakan untuk men-deploy Load Balancer Aplikasi klasik Google Cloud yang mendasarinya.
Buat Namespace khusus untuk gateway cloud mesh layanan Anda:
kubectl create namespace istio-ingressSimpan manifes Gateway berikut ke file bernama
gateway.yaml:kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: servicemesh-cloud-gw namespace: istio-ingress spec: gatewayClassName: asm-l7-gxlb listeners: - name: http protocol: HTTP port: 80 allowedRoutes: namespaces: from: AllDeploy Gateway di cluster Anda di Namespace istio-ingress:
kubectl apply -f gateway.yamlPastikan objek Kubernetes Gateway API dibuat:
kubectl get gateways.gateway.networking.k8s.io -n istio-ingressOutputnya mirip dengan:
NAME CLASS ADDRESS READY AGE asm-gw-gke-servicemesh-cloud-gw gke-l7-gxlb 34.111.114.64 True 9m40s asm-gw-istio-servicemesh-cloud-gw istio 9m44s servicemesh-cloud-gw asm-l7-gxlb 9m44s
Hal berikut akan terjadi saat objek Kubernetes Gateway API ini di-deploy:
- Load Balancer HTTP(S) eksternal di-deploy dan dikonfigurasi. Mungkin perlu waktu beberapa menit untuk muncul, tetapi saat muncul, Gateway akan menunjukkan alamat IP dan akan dianotasi dengan nama resource load balancer Compute Engine yang dibuat.
- Deployment gateway masuk Cloud Service Mesh dibuat di namespace istio-ingress. Tindakan ini akan membuat instance proxy Envoy yang akan menerima traffic dari load balancer.
- Load balancer akan mengenkripsi dan merutekan semua traffic ke gateway masuk Cloud Service Mesh.
Kini Anda memiliki infrastruktur lengkap yang diperlukan untuk menerima traffic internet ke dalam mesh Anda. Perhatikan bahwa ini adalah deployment Gateway yang paling sederhana. Di bagian berikut, Anda akan menambahkan kebijakan dan kemampuan tambahan yang akan membuatnya siap produksi.
Deployment aplikasi dan pemilihan rute
Untuk menunjukkan kemampuan sepenuhnya, Anda akan men-deploy aplikasi ke Cloud Service Mesh dan menerima traffic internet melalui Gateway Anda untuk tujuan contoh.
Beri label Namespace
defaultuntuk mengaktifkan injeksi sidecar.kubectl label namespace default istio-injection=enabled istio.io/rev- --overwriteSimpan manifes Gateway berikut ke file bernama
whereami.yaml:apiVersion: apps/v1 kind: Deployment metadata: name: whereami-v1 spec: replicas: 2 selector: matchLabels: app: whereami-v1 template: metadata: labels: app: whereami-v1 spec: containers: - name: whereami image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1 ports: - containerPort: 8080 env: - name: METADATA value: "whereami-v1" --- apiVersion: v1 kind: Service metadata: name: whereami-v1 spec: selector: app: whereami-v1 ports: - port: 8080 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: whereami-v2 spec: replicas: 2 selector: matchLabels: app: whereami-v2 template: metadata: labels: app: whereami-v2 spec: containers: - name: whereami image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1 ports: - containerPort: 8080 env: - name: METADATA value: "whereami-v2" --- apiVersion: v1 kind: Service metadata: name: whereami-v2 spec: selector: app: whereami-v2 ports: - port: 8080 targetPort: 8080Manifes ini membuat
Service/whereami-v1,Service/whereami-v2,Deployment/whereami-v1, danDeployment/whereami-v2untuk whereami, aplikasi sederhana yang menampilkan JSON untuk menunjukkan identitas dan lokasinya. Anda akan men-deploy dua versi yang berbeda.Buat Layanan dan Deployment:
kubectl apply -f whereami.yamlSetelah aktif dan berjalan, Anda akan memiliki empat Pod whereami yang berjalan di cluster Anda.
Pastikan keempat Pod berjalan:
kubectl get podsOutputnya mirip dengan:
whereami-v1-7c76d89d55-qg6vs 2/2 Running 0 28s whereami-v1-7c76d89d55-vx9nm 2/2 Running 0 28s whereami-v2-67f6b9c987-p9kqm 2/2 Running 0 27s whereami-v2-67f6b9c987-qhj76 2/2 Running 0 27sSimpan manifes HTTPRoute berikut ke file bernama
http-route.yaml:kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: where-route spec: parentRefs: - kind: Gateway name: servicemesh-cloud-gw namespace: istio-ingress hostnames: - "where.example.com" rules: - matches: - headers: - name: version value: v2 backendRefs: - name: whereami-v2 port: 8080 - backendRefs: - name: whereami-v1 port: 8080Deploy
http-route.yamlke cluster Anda:kubectl apply -f http-route.yamlHTTPRoute ini mereferensikan
servicemesh-cloud-gw, yang berarti HTTPRoute akan mengonfigurasi gateway cloud mesh layanan sehingga mengonfigurasi gateway masuk Cloud Service Mesh yang mendasarinya dengan aturan pemilihan rute ini. HTTPRoute melakukan fungsi yang sama dengan Istio VirtualService, tetapi menggunakan Kubernetes Gateway API untuk melakukannya. Karena Gateway API adalah spesifikasi OSS dengan banyak implementasi yang mendasarinya, API ini adalah API terbaik yang sesuai untuk menentukan pemilihan rute di seluruh kombinasi load balancer yang berbeda (seperti proxy dan load balancer Cloud Service Mesh).Ambil alamat IP dari Gateway sehingga Anda dapat mengirim traffic ke aplikasi Anda:
VIP=$(kubectl get gateways.gateway.networking.k8s.io asm-gw-gke-servicemesh-cloud-gw -o=jsonpath="{.status.addresses[0].value}" -n istio-ingress)Outputnya adalah alamat IP.
echo $VIP 34.111.61.135Kirim traffic ke alamat IP Gateway untuk memvalidasi bahwa penyiapan ini berfungsi dengan benar. Kirim satu permintaan dengan header
version: v2dan satu tanpa header untuk menentukan bahwa pemilihan rute dilakukan dengan benar di dua versi aplikasi.curl ${VIP} -H "host: where.example.com" { "cluster_name": "gke1", "host_header": "where.example.com", "metadata": "whereami-v1", "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal", "pod_name": "whereami-v1-67d9c5d48b-zhr4l", "pod_name_emoji": "⚒", "project_id": "church-243723", "timestamp": "2021-02-08T18:55:01", "zone": "us-central1-a" } curl ${VIP} -H "host: where.example.com" -H "version: v2" { "cluster_name": "gke1", "host_header": "where.example.com", "metadata": "whereami-v2", "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal", "pod_name": "whereami-v2-67d9c5d48b-zhr4l", "pod_name_emoji": "⚒", "project_id": "church-243723", "timestamp": "2021-02-08T18:55:01", "zone": "us-central1-a" }
Deployment gateway produksi
Bagian sebelumnya menunjukkan contoh gateway cloud mesh layanan yang sangat sederhana. Langkah-langkah berikut dibuat berdasarkan contoh sederhana untuk menunjukkan penyiapan siap produksi yang menunjukkan keuntungan mendelegasikan beberapa fungsi pemilihan rute masuk ke load balancer.
Dalam contoh berikut, Anda akan mengambil servicemesh-cloud-gw dari bagian sebelumnya dan akan menambahkan kemampuan berikut untuk membuat Gateway yang lebih aman dan mudah dikelola:
- Deploy Gateway dengan alamat IP statis yang akan dipertahankan meskipun infrastruktur yang mendasarinya berubah.
- Konversi Gateway untuk menerima traffic HTTPS dengan sertifikat yang ditandatangani sendiri.
Buat alamat IP eksternal statis. IP statis berguna karena infrastruktur yang mendasarinya dapat berubah di masa mendatang, tetapi alamat IP dapat dipertahankan.
gcloud compute addresses create whereami-ip \ --global \ --project PROJECT_IDBuat sertifikat yang ditandatangani sendiri untuk domain
where-example-com:openssl genrsa -out key.pem 2048 cat <<EOF >ca.conf [req] default_bits = 2048 req_extensions = extension_requirements distinguished_name = dn_requirements prompt = no [extension_requirements] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @sans_list [dn_requirements] 0.organizationName = example commonName = where.example.com [sans_list] DNS.1 = where.example.com EOFopenssl req -new -key key.pem \ -out csr.pem \ -config ca.confopenssl x509 -req \ -signkey key.pem \ -in csr.pem \ -out cert.pem \ -extfile ca.conf \ -extensions extension_requirements \ -days 365gcloud compute ssl-certificates create where-example-com \ --certificate=cert.pem \ --private-key=key.pem \ --global \ --project PROJECT_IDAda banyak cara untuk membuat sertifikat TLS. Sertifikat dapat dibuat secara manual di command line, dibuat menggunakan sertifikat yang dikelola Google, atau dapat dibuat secara internal oleh sistem infrastruktur kunci publik (PKI) perusahaan Anda. Dalam contoh ini, Anda akan membuat sertifikat yang ditandatangani sendiri secara manual. Meskipun sertifikat yang ditandatangani sendiri biasanya tidak digunakan untuk layanan publik, sertifikat ini menunjukkan konsep ini dengan lebih mudah.
Untuk mengetahui informasi selengkapnya tentang cara membuat sertifikat yang ditandatangani sendiri melalui Secret Kubernetes, lihat Mengamankan Gateway.
Perbarui
gateway.yamldengan manifes berikut:kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: servicemesh-cloud-gw namespace: istio-ingress spec: gatewayClassName: asm-l7-gxlb listeners: - name: http protocol: HTTP port: 80 allowedRoutes: namespaces: from: All - name: https protocol: HTTPS port: 443 allowedRoutes: namespaces: from: All tls: mode: Terminate options: networking.gke.io/pre-shared-certs: where-example-com addresses: - type: NamedAddress value: whereami-ipDeploy ulang Gateway di cluster Anda:
kubectl apply -f gateway.yamlDapatkan alamat IP statis:
VIP=$(gcloud compute addresses describe whereami-ip --global --format="value(address)")Gunakan
curluntuk mengakses domain Gateway. Karena DNS tidak dikonfigurasi untuk domain ini, gunakan opsi --resolve untuk memberi tahu curl agar me-resolve nama domain ke alamat IP Gateway:curl https://where.example.com --resolve where.example.com:443:${VIP} --cacert cert.pem -vSetelah selesai, outputnya akan mirip dengan:
... * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 * ALPN, server accepted to use h2 * Server certificate: * subject: O=example; CN=where.example.com * start date: Apr 19 15:54:50 2021 GMT * expire date: Apr 19 15:54:50 2022 GMT * common name: where.example.com (matched) * issuer: O=example; CN=where.example.com * SSL certificate verify ok. ... { "cluster_name": "gke1", "host_header": "where.example.com", "metadata": "where-v1", "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal", "pod_name": "where-v1-84b47c7f58-tj5mn", "pod_name_emoji": "😍", "project_id": "agmsb-k8s", "timestamp": "2021-04-19T16:30:08", "zone": "us-west1-a" }
Output verbose mencakup TLS handshake yang berhasil, diikuti dengan respons dari aplikasi seperti output berikut. Hal ini membuktikan bahwa TLS dihentikan di Gateway dengan benar dan aplikasi merespons klien dengan aman.
Anda telah berhasil men-deploy arsitektur berikut:
servicemesh-cloud-gw dan GatewayClass asm-l7-gxlb telah mengabstraksi beberapa komponen infrastruktur internal untuk menyederhanakan pengalaman pengguna.
Cloud Load Balancing menghentikan traffic TLS menggunakan sertifikat internal dan juga melakukan health check pada lapisan proxy gateway masuk Cloud Service Mesh. The
whereami-route yang di-deploy di
Deployment Aplikasi & Pemilihan Rute mengonfigurasi proxy gateway masuk
Cloud Service Mesh untuk merutekan traffic ke Layanan yang dihosting mesh yang benar.
Dalam contoh berikut, Anda akan mengambil servicemesh-cloud-gw dari bagian sebelumnya dan akan menambahkan kemampuan berikut untuk membuat Gateway yang lebih aman dan mudah dikelola:
- Deploy Gateway dengan alamat IP statis yang akan dipertahankan meskipun infrastruktur yang mendasarinya berubah.
- Konversi Gateway untuk menerima traffic HTTPS dengan sertifikat yang ditandatangani sendiri.
Buat alamat IP eksternal statis. IP statis berguna karena infrastruktur yang mendasarinya dapat berubah di masa mendatang, tetapi alamat IP dapat dipertahankan.
gcloud compute addresses create whereami-ip \ --global \ --project PROJECT_IDBuat sertifikat yang ditandatangani sendiri untuk domain
where-example-com:openssl genrsa -out key.pem 2048 cat <<EOF >ca.conf [req] default_bits = 2048 req_extensions = extension_requirements distinguished_name = dn_requirements prompt = no [extension_requirements] basicConstraints = CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment subjectAltName = @sans_list [dn_requirements] 0.organizationName = example commonName = where.example.com [sans_list] DNS.1 = where.example.com EOFopenssl req -new -key key.pem \ -out csr.pem \ -config ca.confopenssl x509 -req \ -signkey key.pem \ -in csr.pem \ -out cert.pem \ -extfile ca.conf \ -extensions extension_requirements \ -days 365gcloud compute ssl-certificates create where-example-com \ --certificate=cert.pem \ --private-key=key.pem \ --global \ --project PROJECT_IDAda banyak cara untuk membuat sertifikat TLS. Sertifikat dapat dibuat secara manual di command line, dibuat menggunakan sertifikat yang dikelola Google, atau dapat dibuat secara internal oleh sistem infrastruktur kunci publik (PKI) perusahaan Anda. Dalam contoh ini, Anda akan membuat sertifikat yang ditandatangani sendiri secara manual. Meskipun sertifikat yang ditandatangani sendiri biasanya tidak digunakan untuk layanan publik, sertifikat ini menunjukkan konsep ini dengan lebih mudah.
Untuk mengetahui informasi selengkapnya tentang cara membuat sertifikat yang ditandatangani sendiri melalui Secret Kubernetes, lihat Mengamankan Gateway.
Perbarui
gateway.yamldengan manifes berikut:kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: servicemesh-cloud-gw namespace: istio-ingress spec: gatewayClassName: asm-l7-gxlb listeners: - name: http protocol: HTTP port: 80 allowedRoutes: namespaces: from: All - name: https protocol: HTTPS port: 443 allowedRoutes: namespaces: from: All tls: mode: Terminate options: networking.gke.io/pre-shared-certs: where-example-com addresses: - type: NamedAddress value: whereami-ipDeploy ulang Gateway di cluster Anda:
kubectl apply -f gateway.yamlDapatkan alamat IP statis:
VIP=$(gcloud compute addresses describe whereami-ip --global --format="value(address)")Gunakan
curluntuk mengakses domain Gateway. Karena DNS tidak dikonfigurasi untuk domain ini, gunakan opsi --resolve untuk memberi tahu curl agar me-resolve nama domain ke alamat IP Gateway:curl https://where.example.com --resolve where.example.com:443:${VIP} --cacert cert.pem -vSetelah selesai, outputnya akan mirip dengan:
... * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305 * ALPN, server accepted to use h2 * Server certificate: * subject: O=example; CN=where.example.com * start date: Apr 19 15:54:50 2021 GMT * expire date: Apr 19 15:54:50 2022 GMT * common name: where.example.com (matched) * issuer: O=example; CN=where.example.com * SSL certificate verify ok. ... { "cluster_name": "gke1", "host_header": "where.example.com", "metadata": "where-v1", "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal", "pod_name": "where-v1-84b47c7f58-tj5mn", "pod_name_emoji": "😍", "project_id": "agmsb-k8s", "timestamp": "2021-04-19T16:30:08", "zone": "us-west1-a" }
Output verbose mencakup TLS handshake yang berhasil, diikuti dengan respons dari aplikasi seperti output berikut. Hal ini membuktikan bahwa TLS dihentikan di Gateway dengan benar dan aplikasi merespons klien dengan aman.
Anda telah berhasil men-deploy arsitektur berikut:
servicemesh-cloud-gw dan GatewayClass asm-l7-gxlb telah mengabstraksi beberapa komponen infrastruktur internal untuk menyederhanakan pengalaman pengguna.
Cloud Load Balancing menghentikan traffic TLS menggunakan sertifikat internal dan juga melakukan health check pada lapisan proxy gateway masuk Cloud Service Mesh. The
whereami-route yang di-deploy di
Deployment Aplikasi & Pemilihan Rute mengonfigurasi proxy gateway masuk
Cloud Service Mesh untuk merutekan traffic ke Layanan yang dihosting mesh yang benar.
Langkah berikutnya
- Pelajari lebih lanjut implementasi Google Kubernetes Engine (GKE) dari Kubernetes Gateway API.
- Pelajari cara Mengaktifkan fitur Cloud Service Mesh terkelola opsional.