Men-deploy Gateway multi-cluster internal

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.

Contoh ini menunjukkan cara menyiapkan perutean berbasis jalur untuk mengarahkan traffic ke cluster yang berbeda.

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:

  1. Deploy cluster GKE

  2. Daftarkan cluster Anda ke fleet (jika belum terdaftar).

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

  1. Siapkan project dan shell dengan mengonfigurasi lingkungan gcloud menggunakan project ID Anda:

    export PROJECT_ID="YOUR_PROJECT_ID"
    gcloud config set project ${PROJECT_ID}
    
  2. Buat cluster GKE di region yang berbeda.

    Contoh ini menggunakan dua cluster, gke-west-1 di us-west1 dan gke-east-1 di us-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=standard
    

    Ganti 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-east1
    
  3. Aktifkan 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}
    
  4. 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 range
    

    Jika Anda tidak menggunakan jaringan default, ganti default dengan nama jaringan VPC Anda. Pastikan rentang CIDR unik dan tidak tumpang-tindih.

  5. Deploy aplikasi demo Anda, seperti store, ke kedua cluster. Contoh file store.yaml dari gke-networking-recipes membuat namespace dan deployment store.

    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.yaml
    
  6. Ekspor Layanan dari setiap cluster dengan membuat resource Service Kubernetes dan resource ServiceExport di setiap cluster, yang membuat layanan dapat ditemukan di seluruh fleet. Contoh berikut mengekspor layanan store generik dan layanan khusus wilayah (store-west-1, store-east-1) dari setiap cluster, semuanya dalam namespace store.

    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
    EOF
    

    Berlaku 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
    EOF
    
  7. Periksa ServiceImport: Pastikan resource ServiceImport dibuat di setiap cluster dalam namespace store. Mungkin diperlukan waktu beberapa menit untuk membuatnya. bash kubectl get serviceimports --context gke-west1 -n store kubectl get serviceimports --context gke-east1 -n store Anda akan melihat store, store-west-1, dan store-east-1 yang 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.

  1. Untuk menggunakan alamat IP sementara, simpan manifes Gateway berikut sebagai cross-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 attach
    

    Daftar berikut menentukan beberapa kolom dalam file YAML sebelumnya:

    • metadata.namespace: namespace tempat resource Gateway dibuat, misalnya, store.
    • spec.gatewayClassName: nama GatewayClass. Harus berupa gke-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".
  2. 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.

  1. Simpan manifes HTTPRoute berikut sebagai store-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: 8080
    

    Daftar berikut menentukan beberapa kolom dalam file YAML sebelumnya:

    • spec.parentRefs: melampirkan rute ini ke internal-cross-region-gateway di namespace store.
    • spec.hostnames: merepresentasikan nama host yang digunakan klien untuk mengakses layanan.
    • spec.rules: menentukan logika perutean. Contoh ini menggunakan perutean berbasis jalur:
      • Traffic /west dirutekan ke store-west-1 ServiceImport.
      • Traffic /east dirutekan ke store-east-1 ServiceImport.
      • Semua traffic lainnya, seperti /, akan masuk ke ServiceImport store generik.
    • backendRefs:
      • group: net.gke.io dan kind: ServiceImport menargetkan layanan multi-cluster.
  2. Terapkan manifes HTTPRoute ke cluster konfigurasi Anda:

    kubectl apply --context gke-west1 -f store-route.yaml
    

Memverifikasi status Gateway dan Rute

  1. Periksa status Gateway:

    kubectl get gateway internal-cross-region-gateway -n store -o yaml --context gke-west1
    

    Cari 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`).

  2. Periksa status HTTPRoute:

    kubectl get httproute store-route -n store -o yaml --context gke-west1
    

    Cari kondisi di status.parents[].conditions dengan type: Accepted (atau ResolvedRefs) dan status: "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.

  1. Ambil alamat IP Gateway.

    Perintah berikut mencoba mengurai output JSON. Anda mungkin perlu menyesuaikan jsonpath berdasarkan 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, atau VIP2_EAST.

  2. 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 store yang menunjukkan pod backend mana yang melayani permintaan, seperti cluster_name atau zone.

Menggunakan Alamat IP Statis

Daripada alamat IP sementara, Anda dapat menggunakan alamat IP internal statis yang telah dialokasikan sebelumnya.

  1. 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 default dengan nama subnet yang memiliki alamat IP yang ingin Anda alokasikan. Subnet ini adalah subnet reguler, bukan subnet khusus proxy.

  2. Perbarui manifes Gateway dengan mengubah bagian spec.addresses dalam file cross-regional-gateway.yaml Anda:

    # 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: HTTPRoute
    
  3. Terapkan 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-1 config Anda berada di projects/YOUR_PROJECT/regions/us-west1/subnetworks/my-custom-subnet, maka region yang Anda minta alamatnya juga harus memiliki subnet my-custom-subnet. Jika Anda meminta alamat di region us-east1 dan us-centra1, subnet bernama my-custom-subnet juga harus ada di region tersebut.

Pembersihan

Setelah menyelesaikan latihan dalam dokumen ini, ikuti langkah-langkah berikut untuk menghapus resource dan mencegah timbulnya biaya yang tidak diinginkan pada akun Anda:

  1. Hapus cluster.

  2. Batalkan pendaftaran cluster dari fleet jika tidak perlu didaftarkan untuk tujuan lain.

  3. Nonaktifkan fitur multiclusterservicediscovery:

    gcloud container fleet multi-cluster-services disable
    
  4. Nonaktifkan Multi Cluster Ingress:

    gcloud container fleet ingress disable
    
  5. Nonaktifkan 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