Dokumen ini memandu Anda melalui contoh praktis untuk men-deploy Gateway multi-cluster internal guna merutekan traffic dalam jaringan VPC Anda ke aplikasi yang berjalan di dua cluster GKE yang berbeda.
Gateway multi-cluster menyediakan cara yang efektif untuk mengelola traffic layanan yang di-deploy di beberapa cluster GKE. Dengan menggunakan infrastruktur penyeimbangan beban global Google, Anda dapat membuat satu titik entri untuk aplikasi Anda, yang menyederhanakan pengelolaan dan meningkatkan keandalan.Dalam tutorial ini, Anda akan menggunakan aplikasi store contoh untuk mensimulasikan skenario dunia nyata dengan layanan belanja online dimiliki dan dioperasikan oleh tim terpisah serta di-deploy di seluruh fleet cluster GKE bersama.
Sebelum memulai
Gateway Multi-cluster memerlukan beberapa persiapan lingkungan sebelum dapat di-deploy. Sebelum melanjutkan, ikuti langkah-langkah di bagian Menyiapkan lingkungan untuk Gateway multi-cluster:
Deploy cluster GKE
Daftarkan cluster Anda ke fleet (jika belum terdaftar).
Aktifkan Service multi-cluster dan pengontrol Gateway multi-cluster.
Terakhir, tinjau batasan dan masalah umum GKE Gateway Controller sebelum Anda menggunakan controller di lingkungan Anda.
Men-deploy Gateway multi-cluster internal di seluruh region
Anda dapat men-deploy Gateway multi-cluster yang menyediakan load balancing Lapisan 7 internal di seluruh cluster GKE di beberapa region. Gateway ini menggunakan GatewayClass gke-l7-cross-regional-internal-managed-mc. GatewayClass ini menyediakan Load Balancer Aplikasi internal lintas region yang dikelola oleh Google Cloud dan yang mengaktifkan VIP internal yang dapat diakses oleh klien dalam jaringan VPC Anda. Gateway ini dapat diekspos oleh frontend di wilayah pilihan Anda, cukup dengan menggunakan Gateway untuk meminta alamat di wilayah tersebut. VIP internal dapat berupa satu alamat IP, atau dapat berupa alamat IP di beberapa region, dengan satu alamat IP per region yang ditentukan di Gateway. Traffic diarahkan ke cluster GKE backend responsif terdekat yang dapat melayani permintaan.
Prasyarat
Siapkan project dan shell dengan mengonfigurasi lingkungan
gcloudmenggunakan project ID Anda:export PROJECT_ID="YOUR_PROJECT_ID" gcloud config set project ${PROJECT_ID}Buat cluster GKE di region yang berbeda.
Contoh ini menggunakan dua cluster,
gke-west-1dius-west1dangke-east-1dius-east1. Pastikan Gateway API diaktifkan (--gateway-api=standard) dan cluster didaftarkan ke fleet.gcloud container clusters create gke-west-1 \ --location=us-west1-a \ --workload-pool=${PROJECT_ID}.svc.id.goog \ --project=${PROJECT_ID} \ --enable-fleet \ --gateway-api=standard gcloud container clusters create gke-east-1 \ --location=us-east1-c \ --workload-pool=${PROJECT_ID}.svc.id.goog \ --project=${PROJECT_ID} \ --enable-fleet \ --gateway-api=standardGanti nama konteks untuk akses yang lebih mudah:
gcloud container clusters get-credentials gke-west-1 \ --location=us-west1-a \ --project=${PROJECT_ID} gcloud container clusters get-credentials gke-east-1 \ --location=us-east1-c \ --project=${PROJECT_ID} kubectl config rename-context gke_${PROJECT_ID}_us-west1-a_gke-west-1 gke-west1 kubectl config rename-context gke_${PROJECT_ID}_us-east1-c_gke-east-1 gke-east1Aktifkan Layanan Multi-Cluster (MCS) dan Multi-Cluster Ingress (MCI/Gateway):
gcloud container fleet multi-cluster-services enable --project=${PROJECT_ID} # Set the config membership to one of your clusters (e.g., gke-west-1) # This cluster will be the source of truth for multi-cluster Gateway and Route resources. gcloud container fleet ingress enable \ --config-membership=projects/${PROJECT_ID}/locations/us-west1/memberships/gke-west-1 \ --project=${PROJECT_ID}Konfigurasi subnet khusus proxy. Subnet khusus proxy diperlukan di setiap region tempat cluster GKE Anda berada dan tempat load balancer akan beroperasi. Load Balancer Aplikasi internal lintas region mengharuskan tujuan subnet ini ditetapkan ke
GLOBAL_MANAGED_PROXY.# Proxy-only subnet for us-west1 gcloud compute networks subnets create us-west1-proxy-only-subnet \ --purpose=GLOBAL_MANAGED_PROXY \ --role=ACTIVE \ --region=us-west1 \ --network=default \ --range=10.129.0.0/23 # Choose an appropriate unused CIDR range # Proxy-only subnet for us-east1 gcloud compute networks subnets create us-east1-proxy-only-subnet \ --purpose=GLOBAL_MANAGED_PROXY \ --role=ACTIVE \ --region=us-east1 \ --network=default \ --range=10.130.0.0/23 # Choose an appropriate unused CIDR rangeJika Anda tidak menggunakan jaringan default, ganti
defaultdengan nama jaringan VPC Anda. Pastikan rentang CIDR unik dan tidak tumpang-tindih.Deploy aplikasi demo Anda, seperti
store, ke kedua cluster. Contoh filestore.yamldarigke-networking-recipesmembuat namespace dan deploymentstore.kubectl apply --context gke-west1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml kubectl apply --context gke-east1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yamlEkspor Layanan dari setiap cluster dengan membuat resource
ServiceKubernetes dan resourceServiceExportdi setiap cluster, yang membuat layanan dapat ditemukan di seluruh fleet. Contoh berikut mengekspor layananstoregenerik dan layanan khusus wilayah (store-west-1,store-east-1) dari setiap cluster, semuanya dalam namespacestore.Berlaku untuk
gke-west1:cat << EOF | kubectl apply --context gke-west1 -f - apiVersion: v1 kind: Service metadata: name: store namespace: store spec: selector: app: store ports: - port: 8080 targetPort: 8080 --- kind: ServiceExport apiVersion: net.gke.io/v1 metadata: name: store namespace: store --- apiVersion: v1 kind: Service metadata: name: store-west-1 # Specific to this cluster namespace: store spec: selector: app: store ports: - port: 8080 targetPort: 8080 --- kind: ServiceExport apiVersion: net.gke.io/v1 metadata: name: store-west-1 # Exporting the region-specific service namespace: store EOFBerlaku untuk
gke-east1:cat << EOF | kubectl apply --context gke-east1 -f - apiVersion: v1 kind: Service metadata: name: store namespace: store spec: selector: app: store ports: - port: 8080 targetPort: 8080 --- kind: ServiceExport apiVersion: net.gke.io/v1 metadata: name: store namespace: store --- apiVersion: v1 kind: Service metadata: name: store-east-1 # Specific to this cluster namespace: store spec: selector: app: store ports: - port: 8080 targetPort: 8080 --- kind: ServiceExport apiVersion: net.gke.io/v1 metadata: name: store-east-1 # Exporting the region-specific service namespace: store EOFPeriksa ServiceImport: Pastikan resource
ServiceImportdibuat di setiap cluster dalam namespacestore. Mungkin diperlukan waktu beberapa menit untuk membuatnya.bash kubectl get serviceimports --context gke-west1 -n store kubectl get serviceimports --context gke-east1 -n storeAnda akan melihatstore,store-west-1, danstore-east-1yang tercantum (atau entri yang relevan berdasarkan propagasi).
Mengonfigurasi Gateway multi-region internal
Tentukan resource Gateway yang mereferensikan GatewayClass gke-l7-cross-regional-internal-managed-mc. Anda menerapkan manifes ini ke cluster konfigurasi yang ditetapkan, seperti gke-west-1.
Kolom spec.addresses memungkinkan Anda meminta alamat IP sementara di wilayah tertentu atau menggunakan alamat IP statis yang telah dialokasikan sebelumnya.
Untuk menggunakan alamat IP sementara, simpan manifes
Gatewayberikut sebagaicross-regional-gateway.yaml:# cross-regional-gateway.yaml kind: Gateway apiVersion: gateway.networking.k8s.io/v1 metadata: name: internal-cross-region-gateway namespace: store # Namespace for the Gateway resource spec: gatewayClassName: gke-l7-cross-regional-internal-managed-mc addresses: # Addresses across regions. Address value is allowed to be empty or matching # the region name. - type: networking.gke.io/ephemeral-ipv4-address/us-west1 value: "us-west1" - type: networking.gke.io/ephemeral-ipv4-address/us-east1 value: "us-east1" listeners: - name: http protocol: HTTP port: 80 allowedRoutes: kinds: - kind: HTTPRoute # Only allow HTTPRoute to attachDaftar berikut menentukan beberapa kolom dalam file YAML sebelumnya:
metadata.namespace: namespace tempat resource Gateway dibuat, misalnya,store.spec.gatewayClassName: nama GatewayClass. Harus berupagke-l7-cross-regional-internal-managed-mc.spec.listeners.allowedRoutes.kinds: jenis objek Rute yang dapat dilampirkan, misalnya,HTTPRoute.spec.addresses:type: networking.gke.io/ephemeral-ipv4-address/REGION: meminta alamat IP sementara.value: menentukan region untuk alamat, misalnya,"us-west1"atau"us-east1".
Terapkan manifes ke cluster konfigurasi Anda, misalnya,
gke-west1:kubectl apply --context gke-west1 -f cross-regional-gateway.yaml
Melampirkan HTTPRoute ke Gateway
Tentukan resource HTTPRoute untuk mengelola perutean traffic dan terapkan ke cluster konfigurasi Anda.
Simpan manifes
HTTPRouteberikut sebagaistore-route.yaml:# store-route.yaml kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1 metadata: name: store-route namespace: store labels: gateway: cross-regional-internal spec: parentRefs: - name: internal-cross-region-gateway namespace: store # Namespace where the Gateway is deployed hostnames: - "store.example.internal" # Hostname clients will use rules: - matches: # Rule for traffic to /west - path: type: PathPrefix value: /west backendRefs: - group: net.gke.io # Indicates a multi-cluster ServiceImport kind: ServiceImport name: store-west-1 # Targets the ServiceImport for the west cluster port: 8080 - matches: # Rule for traffic to /east - path: type: PathPrefix value: /east backendRefs: - group: net.gke.io kind: ServiceImport name: store-east-1 # Targets the ServiceImport for the east cluster port: 8080 - backendRefs: # Default rule for other paths (e.g., /) - group: net.gke.io kind: ServiceImport name: store # Targets the generic 'store' ServiceImport (any region) port: 8080Daftar berikut menentukan beberapa kolom dalam file YAML sebelumnya:
spec.parentRefs: melampirkan rute ini keinternal-cross-region-gatewaydi namespacestore.spec.hostnames: merepresentasikan nama host yang digunakan klien untuk mengakses layanan.spec.rules: menentukan logika perutean. Contoh ini menggunakan perutean berbasis jalur:- Traffic
/westdirutekan kestore-west-1ServiceImport. - Traffic
/eastdirutekan kestore-east-1ServiceImport. - Semua traffic lainnya, seperti
/, akan masuk ke ServiceImportstoregenerik.
- Traffic
backendRefs:group: net.gke.iodankind: ServiceImportmenargetkan layanan multi-cluster.
Terapkan manifes
HTTPRouteke cluster konfigurasi Anda:kubectl apply --context gke-west1 -f store-route.yaml
Memverifikasi status Gateway dan Rute
Periksa status Gateway:
kubectl get gateway internal-cross-region-gateway -n store -o yaml --context gke-west1Cari kondisi dengan status
type:Programmedand: "True". You should see IP addresses assigned in thestatus.addressesfield, corresponding to the regions you specified (e.g., one forus-west1and one forus-east1`).Periksa status HTTPRoute:
kubectl get httproute store-route -n store -o yaml --context gke-west1Cari kondisi di
status.parents[].conditionsdengantype: Accepted(atauResolvedRefs) danstatus: "True".
Mengonfirmasi traffic
Setelah menetapkan alamat IP ke Gateway, Anda dapat menguji traffic dari VM klien yang berada dalam jaringan VPC Anda dan di salah satu region, atau di region yang dapat terhubung ke alamat IP Gateway.
Ambil alamat IP Gateway.
Perintah berikut mencoba mengurai output JSON. Anda mungkin perlu menyesuaikan
jsonpathberdasarkan struktur yang tepat.kubectl get gateway cross-region-gateway -n store --context gke-west1 -o=jsonpath="{.status.addresses[*].value}".Output perintah ini harus menyertakan VIP, seperti
VIP1_WEST, atauVIP2_EAST.Kirim permintaan pengujian: Dari VM klien di VPC Anda:
# Assuming VIP_WEST is an IP in us-west1 and VIP_EAST is an IP in us-east1 # Traffic to /west should ideally be served by gke-west-1 curl -H "host: store.example.internal" http://VIP_WEST/west curl -H "host: store.example.internal" http://VIP_EAST/west # Still targets store-west-1 due to path # Traffic to /east should ideally be served by gke-east-1 curl -H "host: store.example.internal" http://VIP_WEST/east # Still targets store-east-1 due to path curl -H "host: store.example.internal" http://VIP_EAST/east # Traffic to / (default) could be served by either cluster curl -H "host: store.example.internal" http://VIP_WEST/ curl -H "host: store.example.internal" http://VIP_EAST/Respons harus menyertakan detail dari aplikasi
storeyang menunjukkan pod backend mana yang melayani permintaan, seperticluster_nameatauzone.
Menggunakan Alamat IP Statis
Daripada alamat IP sementara, Anda dapat menggunakan alamat IP internal statis yang telah dialokasikan sebelumnya.
Buat alamat IP statis di region yang ingin Anda gunakan:
gcloud compute addresses create cross-region-gw-ip-west --region us-west1 --subnet default --project=${PROJECT_ID} gcloud compute addresses create cross-region-gw-ip-east --region us-east1 --subnet default --project=${PROJECT_ID}Jika Anda tidak menggunakan subnet default, ganti
defaultdengan nama subnet yang memiliki alamat IP yang ingin Anda alokasikan. Subnet ini adalah subnet reguler, bukan subnet khusus proxy.Perbarui manifes Gateway dengan mengubah bagian
spec.addressesdalam filecross-regional-gateway.yamlAnda:# cross-regional-gateway-static-ip.yaml kind: Gateway apiVersion: gateway.networking.k8s.io/v1 metadata: name: internal-cross-region-gateway # Or a new name if deploying alongside namespace: store spec: gatewayClassName: gke-l7-cross-regional-internal-managed-mc addresses: - type: networking.gke.io/named-address-with-region # Use for named static IP value: "regions/us-west1/addresses/cross-region-gw-ip-west" - type: networking.gke.io/named-address-with-region value: "regions/us-east1/addresses/cross-region-gw-ip-east" listeners: - name: http protocol: HTTP port: 80 allowedRoutes: kinds: - kind: HTTPRouteTerapkan manifes Gateway yang telah diupdate.
kubectl apply --context gke-west1 -f cross-regional-gateway.yaml
Pertimbangan khusus untuk subnet non-default
Perhatikan pertimbangan berikut saat Anda menggunakan subnet non-default:
Jaringan VPC yang sama: semua resource yang dibuat pengguna—seperti alamat IP statis, subnet khusus proxy, dan cluster GKE—harus berada dalam jaringan VPC yang sama.
Subnet alamat: saat Anda membuat alamat IP statis untuk Gateway, alamat tersebut dialokasikan dari subnet reguler di region yang ditentukan.
Penamaan subnet cluster: Setiap region harus memiliki subnet yang memiliki nama yang sama dengan subnet tempat cluster konfigurasi MCG berada.
- Misalnya, jika cluster
gke-west-1config Anda berada diprojects/YOUR_PROJECT/regions/us-west1/subnetworks/my-custom-subnet, maka region yang Anda minta alamatnya juga harus memiliki subnetmy-custom-subnet. Jika Anda meminta alamat di regionus-east1danus-centra1, subnet bernamamy-custom-subnetjuga harus ada di region tersebut.
- Misalnya, jika cluster
Pembersihan
Setelah menyelesaikan latihan dalam dokumen ini, ikuti langkah-langkah berikut untuk menghapus resource dan mencegah timbulnya biaya yang tidak diinginkan pada akun Anda:
Batalkan pendaftaran cluster dari fleet jika tidak perlu didaftarkan untuk tujuan lain.
Nonaktifkan fitur
multiclusterservicediscovery:gcloud container fleet multi-cluster-services disableNonaktifkan Multi Cluster Ingress:
gcloud container fleet ingress disableNonaktifkan API:
gcloud services disable \ multiclusterservicediscovery.googleapis.com \ multiclusteringress.googleapis.com \ trafficdirector.googleapis.com \ --project=PROJECT_ID
Pemecahan masalah
Subnet khusus proxy untuk Gateway internal tidak ada
Jika peristiwa berikut muncul di Gateway internal, berarti subnet khusus proxy tidak ada untuk region tersebut. Untuk mengatasi masalah ini, deploy subnet khusus proxy.
generic::invalid_argument: error ensuring load balancer: Insert: Invalid value for field 'resource.target': 'regions/us-west1/targetHttpProxies/gkegw-x5vt-default-internal-http-2jzr7e3xclhj'. A reserved and active subnetwork is required in the same region and VPC as the forwarding rule.
Tidak ada upstream yang sehat
Gejala:
Masalah berikut dapat terjadi saat Anda membuat Gateway, tetapi tidak dapat mengakses layanan backend (kode respons 503):
no healthy upstream
Alasan:
Pesan error ini menunjukkan bahwa pemeriksa health check tidak dapat menemukan layanan backend yang sehat. Mungkin saja layanan backend Anda dalam kondisi baik, tetapi Anda mungkin perlu menyesuaikan health check.
Solusi:
Untuk mengatasi masalah ini, sesuaikan health check Anda berdasarkan persyaratan aplikasi Anda (misalnya, /health) menggunakan HealthCheckPolicy.
Langkah berikutnya
- Pelajari Pengontrol gateway lebih lanjut.