Men-deploy Gateway multi-cluster

Halaman ini menjelaskan cara men-deploy Kubernetes Resource gateway untuk pemuatan menyeimbangkan traffic masuk di beberapa cluster (atau fleet) Google Kubernetes Engine (GKE). Sebelum men-deploy Gateway multi-cluster, lihat Mengaktifkan Gateway multi-cluster untuk mempersiapkan lingkungan Anda.

Untuk men-deploy Gateway guna melakukan load balancing terhadap traffic masuk ke satu GKE lihat Men-deploy Gateway.

Gateway Multi-cluster

Gateway multi-cluster adalah resource Gateway yang melakukan load balancing pada traffic di beberapa cluster Kubernetes. Di GKE, gke-l7-global-external-managed-mc, gke-l7-regional-external-managed-mc, gke-l7-rilb-mc, dan gke-l7-gxlb-mc GatewayClasses men-deploy Gateway multi-cluster yang menyediakan pemilihan rute HTTP, traffic pemisahan, pencerminan traffic, failover berbasis kondisi kesehatan, dan lainnya di berbagai Cluster GKE, Namespace Kubernetes, dan di berbagai region. Gateway Multi-cluster menjadikan pengelolaan jaringan aplikasi di banyak cluster dan tim mudah, aman, dan skalabel bagi administrator infrastruktur.

Gateway multi-cluster adalah resource Gateway yang melakukan load balancing pada traffic di berbagai cluster Kubernetes.

Halaman ini memperkenalkan tiga contoh untuk mengajari Anda cara men-deploy multi-cluster Gateway menggunakan GKE Pengontrol gateway:

  • Contoh 1: Gateway multi-cluster eksternal yang menyediakan load balancing di dua cluster GKE untuk traffic internet.
  • Contoh 2: Pemisahan traffic dan traffic berwarna biru-hijau pencerminan di dua cluster GKE untuk traffic VPC internal.
  • Contoh 3: Gateway berbasis kapasitas untuk melakukan load balancing permintaan ke backend yang berbeda berdasarkan kapasitas maksimalnya.

Masing-masing contoh akan menggunakan aplikasi store dan site yang sama untuk membuat model skenario dunia nyata di mana layanan belanja {i>online<i} dan situs web dimiliki dan dioperasikan oleh tim terpisah dan ditempatkan di seluruh fleet cluster GKE bersama. Masing-masing contoh menyoroti topologi dan kasus penggunaan yang berbeda yang diaktifkan oleh Gateway multi-cluster.

Gateway Multi-cluster memerlukan beberapa persiapan lingkungan sebelum dapat di-deploy. Sebelum melanjutkan, ikuti langkah-langkah di bagian Mengaktifkan Gateway multi-cluster:

  1. Deploy cluster GKE

  2. Daftarkan cluster Anda ke fleet.

  3. Aktifkan Service multi-cluster dan pengontrol Gateway multi-cluster.

Terakhir, tinjau pengontrol Gateway GKE batasan dan masalah umum sebelum menggunakannya di lingkungan Anda.

Gateway eksternal, multi-cluster, multi-region

Dalam tutorial ini, Anda akan membuat Gateway multi-cluster eksternal yang menyalurkan traffic eksternal di seluruh aplikasi yang berjalan di dua cluster GKE.

store.example.com di-deploy di dua cluster GKE dan diekspos ke internet menggunakan Gateway multi-cluster

Pada langkah berikut, Anda akan:

  1. Deploy aplikasi store contoh ke gke-west-1 dan gke-east-1 cluster.
  2. Konfigurasikan Layanan pada setiap cluster yang akan diekspor ke dalam fleet Anda (Layanan multi-cluster).
  3. Men-deploy Gateway multi-cluster eksternal dan HTTPRoute ke cluster konfigurasi Anda (gke-west-1).

Setelah aplikasi dan resource Gateway di-deploy, Anda dapat mengontrol traffic di kedua cluster GKE menggunakan perutean berbasis jalur:

  • Permintaan ke /west dirutekan ke Pod store di cluster gke-west-1.
  • Permintaan ke /east dirutekan ke Pod store di cluster gke-east-1.
  • Permintaan ke jalur lain akan diarahkan ke salah satu cluster, sesuai dengan kondisi, kapasitas, dan jaraknya dengan klien yang meminta.

Men-deploy aplikasi demo

  1. Buat Deployment dan Namespace store di ketiga cluster yang di-deploy di Mengaktifkan Gateway multi-cluster:

    kubectl apply --context gke-west-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml
kubectl apply --context gke-west-2 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml
kubectl apply --context gke-east-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml

    Solusi ini akan men-deploy resource berikut ke setiap cluster:

    namespace/store created
deployment.apps/store created

    Semua contoh di halaman ini menggunakan aplikasi yang di-deploy pada langkah ini. Pastikan aplikasi di-deploy di ketiga cluster sebelum mencoba salah satu langkah lainnya. Contoh ini hanya menggunakan cluster gke-west-1 dan gke-east-1, dan gke-west-2 digunakan dalam contoh lain.

Service Multi-cluster

Service adalah cara Pod diekspos kepada klien. Karena GKE Pengontrol gateway menggunakan load balancing berbasis container, dan tidak menggunakan ClusterIP atau Kubernetes load balancing untuk mencapai Pod. Traffic dikirim langsung dari load balancer ke alamat IP Pod. Namun, Layanan masih memainkan peran penting sebagai infrastruktur ID untuk pengelompokan Pod.

Layanan Multi-cluster (MCS) adalah standar API untuk Layanan yang mencakup cluster dan GKE menyediakan penemuan layanan di seluruh cluster GKE. Pengontrol Gateway multi-cluster menggunakan resource MCS API untuk mengelompokkan Pod ke dalam Layanan yang dapat dialamatkan di seluruh atau mencakup beberapa cluster.

API Service multi-cluster menentukan resource kustom berikut:

  • ServiceExports dipetakan ke Service Kubernetes, yang mengekspor endpoint Service tersebut ke semua cluster yang terdaftar di fleet. Jika Service memiliki ServiceExport yang sesuai, berarti Service tersebut dapat ditangani oleh Gateway multi-cluster.
  • ServiceImports secara otomatis dibuat oleh pengontrol Service multi-cluster. ServiceExport dan ServiceImport tersedia dalam pasangan. Jika ServiceExport ada di fleet, ServiceImport yang sesuai akan dibuat agar Service yang dipetakan ke ServiceExport dapat diakses dari berbagai cluster.

Pengeksporan Service berfungsi dengan cara berikut. Service penyimpanan ada di gke-west-1 yang memilih grup Pod di cluster tersebut. ServiceExport adalah dibuat di cluster agar Pod di gke-west-1 dapat diakses dibandingkan klaster lain dalam armada itu. ServiceExport akan memetakan ke dan mengekspos Layanan yang memiliki nama dan Namespace yang sama dengan resource ServiceExport.

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

Diagram berikut menunjukkan hal yang terjadi setelah ServiceExport di-deploy. Jika ada pasangan ServiceExport dan Service, pengontrol Service multi-cluster akan men-deploy ServiceImport yang sesuai ke setiap cluster GKE di fleet. ServiceImport adalah representasi lokal dari Service store di setiap cluster. Tindakan ini memungkinkan Pod client di gke-east-1 untuk menggunakan ClusterIP atau Layanan headless untuk mencapai Pod store di gke-west-1. Saat digunakan dengan cara ini Layanan multi-cluster menyediakan load balancing timur-barat antar cluster tanpa yang memerlukan Layanan LoadBalancer internal. Untuk menggunakan Layanan multi-cluster untuk load balancing cluster-ke-cluster, lihat Mengonfigurasi Layanan multi-cluster.

Layanan Multi-cluster mengekspor Layanan di seluruh cluster yang memungkinkan komunikasi cluster ke cluster

Gateway multi-cluster juga menggunakan ServiceImports, tetapi tidak untuk load balancing cluster-ke-cluster. Sebagai gantinya, Gateway menggunakan ServiceImports sebagai ID logis untuk Service yang ada di cluster lain atau yang tersebar di beberapa cluster. HTTPRoute berikut merujuk ke ServiceImport, bukan resource Service. Dengan mereferensikan ServiceImport, tindakan ini menunjukkan bahwa traffic meneruskan ke grup Pod backend yang berjalan di satu atau beberapa cluster.

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store-route
  namespace: store
  labels:
    gateway: multi-cluster-gateway
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: external-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store
      port: 8080

Diagram berikut menunjukkan cara HTTPRoute merutekan traffic store.example.com ke Pod store di gke-west-1 dan gke-east-1. Load balancer memperlakukannya sebagai satu kumpulan backend. Jika Pod dari salah satu cluster menjadi tidak responsif, tidak dapat dijangkau, atau tidak memiliki kapasitas traffic, beban traffic akan diseimbangkan dengan Pod lainnya di cluster lain. Cluster baru dapat ditambahkan atau dihapus dengan Service store dan ServiceExport. Tindakan ini akan menambahkan atau menghapus Pod backend secara transparan tanpa perubahan konfigurasi pemilihan rute eksplisit.

Resource MCS

Mengekspor Service

Di tahap ini, aplikasi berjalan di kedua cluster. Selanjutnya, Anda akan mengekspos dan mengekspor aplikasi dengan men-deploy Service dan ServiceExport ke setiap cluster.

  1. Terapkan manifes berikut ke cluster gke-west-1 untuk membuat store Anda dan store-west-1 Services and ServiceExports:

    cat << EOF | kubectl apply --context gke-west-1 -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
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-west-1
  namespace: store
EOF

  2. Terapkan manifes berikut ke cluster gke-east-1 untuk membuat store Anda dan store-east-1 Services and ServiceExports:

    cat << EOF | kubectl apply --context gke-east-1 -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
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-east-1
  namespace: store
EOF

  3. Pastikan bahwa ServiceExport yang benar telah dibuat di cluster.

    kubectl get serviceexports --context CLUSTER_NAME --namespace store

    Ganti CLUSTER_NAME dengan gke-west-1 dan gke-east-1. Output akan terlihat seperti berikut:

    # gke-west-1
NAME           AGE
store          2m40s
store-west-1   2m40s

# gke-east-1
NAME           AGE
store          2m25s
store-east-1   2m25s

    Hal ini menunjukkan bahwa Service store berisi Pod store di kedua cluster sementara Service store-west-1 dan store-east-1 hanya berisi Pod store di cluster masing-masing. Service yang tumpang-tindih ini digunakan untuk menargetkan Pod di beberapa cluster atau subset Pod di satu cluster.

  4. Setelah beberapa menit, verifikasi bahwa ServiceImports yang menyertainya telah otomatis dibuat oleh pengontrol Layanan multi-cluster di semua cluster di fleet.

    kubectl get serviceimports --context CLUSTER_NAME --namespace store

    Ganti CLUSTER_NAME dengan gke-west-1 dan gke-east-1. Output akan terlihat seperti berikut:

    # gke-west-1
NAME           TYPE           IP                  AGE
store          ClusterSetIP   ["10.112.31.15"]    6m54s
store-east-1   ClusterSetIP   ["10.112.26.235"]   5m49s
store-west-1   ClusterSetIP   ["10.112.16.112"]   6m54s

# gke-east-1
NAME           TYPE           IP                  AGE
store          ClusterSetIP   ["10.72.28.226"]    5d10h
store-east-1   ClusterSetIP   ["10.72.19.177"]    5d10h
store-west-1   ClusterSetIP   ["10.72.28.68"]     4h32m

    Hal ini menunjukkan bahwa ketiga Service dapat diakses dari kedua cluster di fleet. Namun, karena hanya ada satu cluster konfigurasi aktif per fleet, Anda hanya dapat men-deploy Gateway dan HTTPRoute yang mereferensikan ServiceImport ini di gke-west-1. Saat HTTPRoute di cluster konfigurasi merujuk ServiceImport ini sebagai backend, Gateway dapat meneruskan traffic ke Service ini, terlepas dari cluster tempat traffic tersebut diekspor.

Men-deploy Gateway dan HTTPRoute

Setelah aplikasi di-deploy, Anda dapat mengonfigurasi Gateway menggunakan GatewayClass gke-l7-global-external-managed-mc. Gateway ini membuat Load Balancer Aplikasi eksternal yang dikonfigurasi untuk mendistribusikan traffic di seluruh cluster target Anda.

  1. Terapkan manifes Gateway berikut ke cluster konfigurasi, gke-west-1 dalam contoh ini:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-http
  namespace: store
spec:
  gatewayClassName: gke-l7-global-external-managed-mc
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
EOF

    Konfigurasi Gateway ini men-deploy resource Load Balancer Aplikasi eksternal dengan hal-hal berikut konvensi penamaan: gkemcg1-NAMESPACE-GATEWAY_NAME-HASH.

    Resource default yang dibuat dengan konfigurasi ini adalah:

    • 1 load balancer: gkemcg1-store-external-http-HASH
    • 1 alamat IP publik: gkemcg1-store-external-http-HASH
    • 1 aturan penerusan: gkemcg1-store-external-http-HASH
    • 2 layanan backend:
      • Layanan backend 404 default: gkemcg1-store-gw-serve404-HASH
      • Layanan backend 500 default: gkemcg1-store-gw-serve500-HASH
    • 1 Health check:
      • Health check 404 default: gkemcg1-store-gw-serve404-HASH
    • 0 aturan pemilihan rute (URLmap kosong)

    Pada tahap ini, setiap permintaan ke GATEWAY_IP:80 akan menghasilkan halaman default yang menampilkan pesan berikut: fault filter abort.

  2. Terapkan manifes HTTPRoute berikut ke cluster konfigurasi, gke-west-1 dalam contoh ini:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: public-store-route
  namespace: store
  labels:
    gateway: external-http
spec:
  hostnames:
  - "store.example.com"
  parentRefs:
  - name: external-http
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /west
    backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store-west-1
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /east
    backendRefs:
      - group: net.gke.io
        kind: ServiceImport
        name: store-east-1
        port: 8080
  - backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store
      port: 8080
EOF

    Pada tahap ini, setiap permintaan ke GATEWAY_IP:80 akan menghasilkan halaman default yang menampilkan pesan berikut: fault filter abort.

    Setelah di-deploy, HTTPRoute ini akan mengonfigurasi perilaku perutean berikut:

    • Permintaan ke /west dirutekan ke store Pod di cluster gke-west-1, karena Pod yang dipilih oleh ServiceExport store-west-1 hanya ada di Gugus gke-west-1.
    • Permintaan ke /east dirutekan ke store Pod di cluster gke-east-1, karena Pod yang dipilih oleh ServiceExport store-east-1 hanya ada di Gugus gke-east-1.
    • Permintaan ke jalur lain dirutekan ke store Pod di salah satu cluster, sesuai dengan kondisi, kapasitas, dan jaraknya dengan klien yang meminta.
    • Permintaan ke GATEWAY_IP:80 akan menghasilkan halaman default yang menampilkan pesan berikut: fault filter abort.

    HTTPRoute memungkinkan perutean ke subset cluster yang berbeda dengan menggunakan Layanan yang tumpang tindih

    Perlu diperhatikan bahwa jika semua Pod di cluster tertentu tidak responsif (atau tidak ada) traffic ke Layanan store hanya akan dikirim ke cluster yang memiliki store Pod. Keberadaan ServiceExport dan Service di cluster tertentu tidak menjamin bahwa traffic akan dikirim ke cluster tersebut. Pod harus ada dan merespons dengan jelas health check load balancer. Jika tidak, load balancer hanya akan mengirimkan traffic ke Pod store yang responsif di cluster lain.

    Resource baru dibuat dengan konfigurasi ini:

    • 3 layanan backend:
      • Layanan backend store: gkemcg1-store-store-8080-HASH
      • Layanan backend store-east-1: gkemcg1-store-store-east-1-8080-HASH
      • Layanan backend store-west-1: gkemcg1-store-store-west-1-8080-HASH
    • 3 Health check:
      • Health check store: gkemcg1-store-store-8080-HASH
      • Health check store-east-1: gkemcg1-store-store-east-1-8080-HASH
      • Health check store-west-1: gkemcg1-store-store-west-1-8080-HASH
    • 1 aturan pemilihan rute di URLmap:
      • Aturan pemilihan rute store.example.com:
      • 1 Host: store.example.com
      • Beberapa matchRules untuk dirutekan ke layanan backend baru

Diagram berikut menunjukkan resource yang telah Anda deploy di kedua cluster. Karena gke-west-1 adalah cluster konfigurasi Gateway, cluster ini adalah cluster tempat Gateway, HTTPRoute, dan ServiceImport dipantau oleh pengontrol Gateway. Setiap cluster memiliki ServiceImport store dan ServiceImport lain yang khusus untuk cluster tersebut. Kedua titik berada di Pod yang sama. Kondisi ini memungkinkan HTTPRoute untuk menentukan secara tepat lokasi traffic yang seharusnya, yaitu ke Pod store di cluster tertentu atau ke Pod store di semua cluster.

Ini adalah model resource Layanan Gateway dan Multi-cluster di keduanya cluster

Perhatikan bahwa ini adalah model resource logis, bukan penggambaran traffic alur kerja. Jalur traffic mengarah langsung dari load balancer ke Pod backend dan tidak memiliki hubungan langsung dengan cluster mana pun yang merupakan cluster konfigurasi.

Memvalidasi deployment

Kini, Anda dapat mengeluarkan permintaan ke Gateway multi-cluster kami dan mendistribusikan traffic di kedua cluster GKE.

  1. Validasi bahwa Gateway dan HTTPRoute telah berhasil di-deploy dengan memeriksa status dan peristiwa {i>Gateway<i}.

    kubectl describe gateways.gateway.networking.k8s.io external-http --context gke-west-1 --namespace store

    Output Anda akan terlihat seperti berikut:

    Name:         external-http
Namespace:    store
Labels:       <none>
Annotations:  networking.gke.io/addresses: /projects/PROJECT_NUMBER/global/addresses/gkemcg1-store-external-http-laup24msshu4
              networking.gke.io/backend-services:
                /projects/PROJECT_NUMBER/global/backendServices/gkemcg1-store-gw-serve404-80-n65xmts4xvw2, /projects/PROJECT_NUMBER/global/backendServices/gke...
              networking.gke.io/firewalls: /projects/PROJECT_NUMBER/global/firewalls/gkemcg1-l7-default-global
              networking.gke.io/forwarding-rules: /projects/PROJECT_NUMBER/global/forwardingRules/gkemcg1-store-external-http-a5et3e3itxsv
              networking.gke.io/health-checks:
                /projects/PROJECT_NUMBER/global/healthChecks/gkemcg1-store-gw-serve404-80-n65xmts4xvw2, /projects/PROJECT_NUMBER/global/healthChecks/gkemcg1-s...
              networking.gke.io/last-reconcile-time: 2023-10-12T17:54:24Z
              networking.gke.io/ssl-certificates: 
              networking.gke.io/target-http-proxies: /projects/PROJECT_NUMBER/global/targetHttpProxies/gkemcg1-store-external-http-94oqhkftu5yz
              networking.gke.io/target-https-proxies: 
              networking.gke.io/url-maps: /projects/PROJECT_NUMBER/global/urlMaps/gkemcg1-store-external-http-94oqhkftu5yz
API Version:  gateway.networking.k8s.io/v1beta1
Kind:         Gateway
Metadata:
  Creation Timestamp:  2023-10-12T06:59:32Z
  Finalizers:
    gateway.finalizer.networking.gke.io
  Generation:        1
  Resource Version:  467057
  UID:               1dcb188e-2917-404f-9945-5f3c2e907b4c
Spec:
  Gateway Class Name:  gke-l7-global-external-managed-mc
  Listeners:
    Allowed Routes:
      Kinds:
        Group:  gateway.networking.k8s.io
        Kind:   HTTPRoute
      Namespaces:
        From:  Same
    Name:      http
    Port:      80
    Protocol:  HTTP
Status:
  Addresses:
    Type:   IPAddress
    Value:  34.36.127.249
  Conditions:
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:               The OSS Gateway API has deprecated this condition, do not depend on it.
    Observed Generation:   1
    Reason:                Scheduled
    Status:                True
    Type:                  Scheduled
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:               
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:               
    Observed Generation:   1
    Reason:                Programmed
    Status:                True
    Type:                  Programmed
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:               The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
    Observed Generation:   1
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Listeners:
    Attached Routes:  1
    Conditions:
      Last Transition Time:  2023-10-12T07:00:41Z
      Message:               
      Observed Generation:   1
      Reason:                Programmed
      Status:                True
      Type:                  Programmed
      Last Transition Time:  2023-10-12T07:00:41Z
      Message:               The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
      Observed Generation:   1
      Reason:                Ready
      Status:                True
      Type:                  Ready
    Name:                    http
    Supported Kinds:
      Group:  gateway.networking.k8s.io
      Kind:   HTTPRoute
Events:
  Type    Reason  Age                    From                   Message
  ----    ------  ----                   ----                   -------
  Normal  UPDATE  35m (x4 over 10h)      mc-gateway-controller  store/external-http
  Normal  SYNC    4m22s (x216 over 10h)  mc-gateway-controller  SYNC on store/external-http was a success

  2. Setelah Gateway berhasil di-deploy, ambil alamat IP eksternal dari Gateway external-http.

    kubectl get gateways.gateway.networking.k8s.io external-http -o=jsonpath="{.status.addresses[0].value}" --context gke-west-1 --namespace store

    Ganti VIP di langkah berikut dengan alamat IP yang Anda terima sebagai output.

  3. Mengirim traffic ke jalur root domain. Load balancing ini menyeimbangkan traffic ke ServiceImport store yang ada di seluruh cluster gke-west-1 dan gke-east-1. Load balancer mengirimkan traffic ke region terdekat dan Anda mungkin tidak melihat respons dari region lain.

    curl -H "host: store.example.com" http://VIP

    Output mengonfirmasi bahwa permintaan disalurkan oleh Pod dari gke-east-1 :

    {
  "cluster_name": "gke-east-1",
  "zone": "us-east1-b",
  "host_header": "store.example.com",
  "node_name": "gke-gke-east-1-default-pool-7aa30992-t2lp.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-dg22z",
  "pod_name_emoji": "⏭",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:32:51"
}

  4. Selanjutnya, kirim traffic ke jalur /west. Hal ini mengarahkan traffic ke store-west-1 ServiceImport yang hanya memiliki Pod yang berjalan di gke-west-1 . ServiceImport khusus cluster, seperti store-west-1, mengaktifkan agar pemilik aplikasi secara eksplisit mengirim traffic ke cluster tertentu, bukan daripada membiarkan load balancer membuat keputusan.

    curl -H "host: store.example.com" http://VIP/west

    Output mengonfirmasi bahwa permintaan disalurkan oleh Pod dari gke-west-1 :

    {
  "cluster_name": "gke-west-1", 
  "zone": "us-west1-a", 
  "host_header": "store.example.com",
  "node_name": "gke-gke-west-1-default-pool-65059399-2f41.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-d25m5",
  "pod_name_emoji": "🍾",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:39:15",
}

  5. Terakhir, kirim traffic ke jalur /east.

    curl -H "host: store.example.com" http://VIP/east

    Output mengonfirmasi bahwa permintaan disalurkan oleh Pod dari gke-east-1 :

    {
  "cluster_name": "gke-east-1",
  "zone": "us-east1-b",
  "host_header": "store.example.com",
  "node_name": "gke-gke-east-1-default-pool-7aa30992-7j7z.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-hz6mw",
  "pod_name_emoji": "🧜🏾",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:40:48"
}

Pemilihan rute multi-cluster blue-green dengan Gateway

gke-l7-global-external-managed-*, gke-l7-regional-external-managed-*, dan gke-l7-rilb-* GatewayClass memiliki banyak kemampuan pemilihan rute traffic lanjutan termasuk pemisahan traffic, pencocokan header, manipulasi header, traffic pencerminan, dan banyak lagi. Dalam contoh ini, Anda akan menunjukkan cara menggunakan pemisahan traffic untuk mengontrol proporsi traffic di dua platform secara eksplisit Cluster GKE.

Contoh ini memberikan beberapa langkah realistis yang harus diambil pemilik layanan agar dapat memindahkan atau memperluas aplikasi mereka ke cluster GKE baru. Tujuan blue-green deployment adalah untuk mengurangi risiko melalui beberapa langkah validasi yang mengonfirmasi bahwa cluster baru beroperasi dengan benar. Contoh ini memuat empat tahap deployment:

  1. 100%-Canary berbasis header: Gunakan pemilihan rute header HTTP untuk hanya mengirim traffic pengujian atau sintetis ke cluster baru.
  2. 100%-Menduplikasi traffic: Menduplikasi traffic pengguna ke cluster canary. Tahap ini akan menguji kapasitas cluster canary dengan menyalin 100% traffic pengguna ke cluster ini.
  3. 90%-10%: Pemisahan traffic Canary sebesar 10% untuk perlahan-lahan mengekspos cluster baru ke traffic langsung.
  4. 0%-100%: Migrasi sistem sepenuhnya ke cluster baru dengan opsi untuk beralih kembali jika setiap error teramati.

Pemisahan traffic blue-green di dua cluster GKE

Contoh ini mirip dengan contoh sebelumnya, tetapi contoh ini men-deploy Gateway multi-cluster internal. Tindakan ini akan men-deploy Load Balancer Aplikasi internal yang hanya dapat diakses secara pribadi dari dalam VPC. Anda akan menggunakan cluster dan juga aplikasi yang sama seperti yang di-deploy di langkah sebelumnya, kecuali jika Anda men-deploy-nya melalui Gateway yang berbeda.

Prasyarat

Contoh berikut dibuat berdasarkan beberapa langkah dalam Men-deploy Gateway multi-cluster eksternal. Pastikan Anda telah melakukan langkah-langkah berikut sebelum melanjutkan contoh ini:

  1. Mengaktifkan Gateway multi-cluster

  2. Men-deploy aplikasi demo

    Contoh ini menggunakan cluster gke-west-1 dan gke-west-2 yang sudah Anda siap. Cluster ini berada di region yang sama karena gke-l7-rilb-mc GatewayClass bersifat regional dan hanya mendukung backend cluster di region yang sama.

  3. Deploy Service dan ServiceExport yang diperlukan di setiap cluster. Jika Anda men-deploy Services and ServiceExports dari contoh sebelumnya, maka Anda sudah menerapkan beberapa di antaranya.

    kubectl apply --context gke-west-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store-west-1-service.yaml
kubectl apply --context gke-west-2 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store-west-2-service.yaml

    Contoh ini men-deploy serangkaian resource yang serupa ke setiap cluster:

    service/store created
serviceexport.net.gke.io/store created
service/store-west-2 created
serviceexport.net.gke.io/store-west-2 created

Mengonfigurasi subnet khusus proxy

Jika Anda belum melakukannya, konfigurasi subnet khusus proxy untuk setiap region tempat Anda men-deploy Gateway internal. Subnet ini digunakan untuk menyediakan alamat IP internal ke proxy load balancer dan harus dikonfigurasi dengan --purpose yang ditetapkan ke REGIONAL_MANAGED_PROXY saja.

Anda harus membuat subnet khusus proxy sebelum membuat Gateway yang mengelola Load Balancer Aplikasi internal. Setiap region jaringan Virtual Private Cloud (VPC) tempat Anda menggunakan Load Balancer Aplikasi internal harus memiliki subnet khusus proxy.

Perintah gcloud compute networks subnets create membuat subnet khusus proxy.

gcloud compute networks subnets create SUBNET_NAME \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=REGION \
    --network=VPC_NETWORK_NAME \
    --range=CIDR_RANGE

Ganti kode berikut:

  • SUBNET_NAME: nama subnet khusus proxy.
  • REGION: region subnet khusus proxy.
  • VPC_NETWORK_NAME: nama jaringan VPC yang berisi subnet.
  • CIDR_RANGE: rentang alamat IP utama subnet. Anda harus menggunakan subnet mask dengan ukuran maksimal /26 agar ada minimal 64 alamat IP yang tersedia untuk proxy di region tersebut. Subnet mask yang direkomendasikan adalah /23.

Men-deploy Gateway

Gateway berikut dibuat dari GatewayClass gke-l7-rilb-mc. Ini adalah Gateway internal regional yang hanya dapat menargetkan cluster GKE region yang sama.

  1. Terapkan manifes Gateway berikut ke cluster konfigurasi, gke-west-1 dalam contoh ini:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-http
  namespace: store
spec:
  gatewayClassName: gke-l7-rilb-mc
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
EOF

  2. Validasi bahwa Gateway berhasil muncul. Anda dapat memfilter hanya peristiwa dari Gateway ini dengan perintah berikut:

    kubectl get events --field-selector involvedObject.kind=Gateway,involvedObject.name=internal-http --context=gke-west-1 --namespace store

    Deployment Gateway berhasil jika output-nya terlihat seperti berikut:

    LAST SEEN   TYPE     REASON   OBJECT                  MESSAGE
5m18s       Normal   ADD      gateway/internal-http   store/internal-http
3m44s       Normal   UPDATE   gateway/internal-http   store/internal-http
3m9s        Normal   SYNC     gateway/internal-http   SYNC on store/internal-http was a success

Canary berbasis header

Canary berbasis header memungkinkan pemilik layanan mencocokkan traffic pengujian sintetis yang tidak berasal dari pengguna sebenarnya. Ini adalah cara mudah untuk memvalidasi bahwa jaringan dasar aplikasi berfungsi tanpa mengekspos pengguna secara langsung.

  1. Terapkan manifes HTTPRoute berikut ke cluster konfigurasi, gke-west-1 dalam contoh ini:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-store-route
  namespace: store
  labels:
    gateway: internal-http
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: internal-http
  hostnames:
  - "store.example.internal"
  rules:
  # Matches for env=canary and sends it to store-west-2 ServiceImport
  - matches:
    - headers:
      - name: env
        value: canary
    backendRefs:
      - group: net.gke.io
        kind: ServiceImport
        name: store-west-2
        port: 8080
  # All other traffic goes to store-west-1 ServiceImport
  - backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store-west-1
      port: 8080
EOF

    Setelah di-deploy, HTTPRoute ini akan mengonfigurasi perilaku perutean berikut:

    • Permintaan internal ke store.example.internal tanpa Header HTTP env: canary dirutekan ke Pod store di gke-west-1 {i>cluster <i}(mengelompokkan)
    • Permintaan internal ke store.example.internal dengan env: canary Header HTTP dirutekan ke Pod store di cluster gke-west-2

    HTTPRoute memungkinkan perutean ke cluster yang berbeda berdasarkan jaringan header

    Validasi bahwa HTTPRoute berfungsi baik dengan mengirimkan traffic ke alamat IP Gateway.

  2. Ambil alamat IP internal dari internal-http.

    kubectl get gateways.gateway.networking.k8s.io internal-http -o=jsonpath="{.status.addresses[0].value}" --context gke-west-1 --namespace store

    Ganti VIP di langkah berikut dengan alamat IP yang Anda terima sebagai output.

  3. Kirim permintaan ke Gateway menggunakan header HTTP env: canary. Tindakan ini akan mengonfirmasi bahwa traffic dirutekan ke gke-west-2. Gunakan klien pribadi di VPC yang sama dengan cluster GKE untuk mengonfirmasi bahwa permintaan dirutekan dengan benar. Perintah berikut harus dijalankan di komputer yang memiliki akses pribadi ke alamat IP Gateway. Jika tidak, perintah tersebut tidak akan berfungsi.

    curl -H "host: store.example.internal" -H "env: canary" http://VIP

    Output tersebut mengonfirmasi bahwa permintaan dilayani oleh Pod dari cluster gke-west-2:

    {
    "cluster_name": "gke-west-2", 
    "host_header": "store.example.internal",
    "node_name": "gke-gke-west-2-default-pool-4cde1f72-m82p.c.agmsb-k8s.internal",
    "pod_name": "store-5f5b954888-9kdb5",
    "pod_name_emoji": "😂",
    "project_id": "agmsb-k8s",
    "timestamp": "2021-05-31T01:21:55",
    "zone": "us-west1-a"
}

Duplikasi traffic

Tahap ini mengirimkan traffic ke cluster yang diinginkan, tetapi juga mencerminkan traffic tersebut pada gugus canary.

Penggunaan duplikasi akan berguna dalam menentukan pengaruh beban traffic terhadap performa aplikasi tanpa memengaruhi respons terhadap klien Anda dengan cara apa pun. Tindakan ini mungkin tidak diperlukan untuk semua jenis peluncuran, tetapi dapat berguna saat meluncurkan perubahan besar yang dapat memengaruhi performa atau beban.

  1. Terapkan manifes HTTPRoute berikut ke cluster konfigurasi, gke-west-1 dalam contoh ini:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-store-route
  namespace: store
  labels:
    gateway: internal-http
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: internal-http
  hostnames:
  - "store.example.internal"
  rules:
  # Sends all traffic to store-west-1 ServiceImport
  - backendRefs:
    - name: store-west-1
      group: net.gke.io
      kind: ServiceImport
      port: 8080
    # Also mirrors all traffic to store-west-2 ServiceImport
    filters:
    - type: RequestMirror
      requestMirror:
        backendRef:
          group: net.gke.io
          kind: ServiceImport
          name: store-west-2
          port: 8080
EOF

  2. Dengan menggunakan klien pribadi Anda, kirim permintaan ke Gateway internal-http. Gunakan jalur /mirror agar Anda dapat mengidentifikasi permintaan ini secara unik dalam log aplikasi di langkah selanjutnya.

    curl -H "host: store.example.internal" http://VIP/mirror

  3. Output tersebut mengonfirmasi bahwa klien menerima respons dari Pod di Cluster gke-west-1:

    {
    "cluster_name": "gke-west-1", 
    "host_header": "store.example.internal",
    "node_name": "gke-gke-west-1-default-pool-65059399-ssfq.c.agmsb-k8s.internal",
    "pod_name": "store-5f5b954888-brg5w",
    "pod_name_emoji": "🎖",
    "project_id": "agmsb-k8s",
    "timestamp": "2021-05-31T01:24:51",
    "zone": "us-west1-a"
}

    Tindakan ini memastikan bahwa cluster utama merespons traffic. Anda tetap harus mengonfirmasi bahwa cluster tempat Anda bermigrasi menerima traffic yang diduplikasi.

  4. Periksa log aplikasi untuk Pod store di cluster gke-west-2. Tujuan log akan mengonfirmasi bahwa Pod menerima traffic yang diduplikasi dari beban dengan load balancer Jaringan Passthrough Eksternal Regional.

    kubectl logs deployment/store --context gke-west-2 -n store | grep /mirror

  5. Output ini mengonfirmasi bahwa Pod di cluster gke-west-2 juga menerima permintaan yang sama, namun respons mereka terhadap permintaan ini tidak dikirimkan kembali kepada klien. Alamat IP yang terlihat di log adalah alamat dari beban menggunakan alamat IP internal balancer yang berkomunikasi dengan Pod Anda.

    Found 2 pods, using pod/store-5c65bdf74f-vpqbs
[2023-10-12 21:05:20,805] INFO in _internal: 192.168.21.3 - - [12/Oct/2023 21:05:20] "GET /mirror HTTP/1.1" 200 -
[2023-10-12 21:05:27,158] INFO in _internal: 192.168.21.3 - - [12/Oct/2023 21:05:27] "GET /mirror HTTP/1.1" 200 -
[2023-10-12 21:05:27,805] INFO in _internal: 192.168.21.3 - - [12/Oct/2023 21:05:27] "GET /mirror HTTP/1.1" 200 -

Pembagian traffic

Pemisahan traffic adalah salah satu metode paling umum untuk meluncurkan kode baru atau men-deploy ke lingkungan baru dengan aman. Pemilik layanan menetapkan persentase eksplisit traffic yang dikirim ke backend canary, dan ini biasanya merupakan jumlah yang sangat kecil dari keseluruhan traffic, sehingga keberhasilan peluncuran dapat ditentukan dari jumlah risiko yang dapat diterima terhadap permintaan pengguna yang sebenarnya.

Denagn melakukan pemisahan traffic dengan sebagian kecil traffic, pemilik layanan dapat memeriksa kondisi aplikasi beserta responsnya. Jika semua sinyal terlihat baik-baik saja, sinyal tersebut dapat diproses sepenuhnya.

  1. Terapkan manifes HTTPRoute berikut ke cluster konfigurasi, gke-west-1 dalam contoh ini:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-store-route
  namespace: store
  labels:
    gateway: internal-http
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: internal-http
  hostnames:
  - "store.example.internal"
  rules:
  - backendRefs:
    # 90% of traffic to store-west-1 ServiceImport
    - name: store-west-1
      group: net.gke.io
      kind: ServiceImport
      port: 8080
      weight: 90
    # 10% of traffic to store-west-2 ServiceImport
    - name: store-west-2
      group: net.gke.io
      kind: ServiceImport
      port: 8080
      weight: 10
EOF

  2. Dengan menggunakan klien pribadi Anda, kirim permintaan curl berkelanjutan ke Gateway internal- http.

    while true; do curl -H "host: store.example.internal" -s VIP | grep "cluster_name"; sleep 1; done

    Output akan serupa dengan ini, yang menunjukkan bahwa pemisahan traffic 90/10 sedang berlangsung.

    "cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-2",
"cluster_name": "gke-west-1",
"cluster_name": "gke-west-1",
...

Migrasi sistem traffic

Tahap terakhir dari migrasi blue-green adalah menutup sempurna cluster dan menghapus cluster lama. Jika pemilik layanan benar-benar melakukan orientasi cluster kedua ke cluster yang sudah ada, langkah terakhir ini akan berbeda karena langkah terakhir merupakan traffic yang mengarah ke kedua cluster tersebut. Dalam skenario tersebut, satu ServiceImport store direkomendasikan, yaitu yang memiliki Pod dari cluster gke-west-1 dan gke-west-2. Dengan cara ini, load balancer dapat membuat keputusan terkait arah tujuan traffic untuk aplikasi aktif-aktif, berdasarkan kedekatan, kondisi, dan kapasitas.

  1. Terapkan manifes HTTPRoute berikut ke cluster konfigurasi, gke-west-1 dalam contoh ini:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-store-route
  namespace: store
  labels:
    gateway: internal-http
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: internal-http
  hostnames:
  - "store.example.internal"
  rules:
    - backendRefs:
      # No traffic to the store-west-1 ServiceImport
      - name: store-west-1
        group: net.gke.io
        kind: ServiceImport
        port: 8080
        weight: 0
      # All traffic to the store-west-2 ServiceImport
      - name: store-west-2
        group: net.gke.io
        kind: ServiceImport
        port: 8080
        weight: 100
EOF

  2. Dengan menggunakan klien pribadi Anda, kirim permintaan curl berkelanjutan ke Gateway internal- http.

    while true; do curl -H "host: store.example.internal" -s VIP | grep "cluster_name"; sleep 1; done

    Output-nya akan serupa dengan ini, yang menunjukkan bahwa semua traffic sekarang berjalan ke gke-west-2.

    "cluster_name": "gke-west-2",
"cluster_name": "gke-west-2",
"cluster_name": "gke-west-2",
"cluster_name": "gke-west-2",
...

Langkah terakhir ini menyelesaikan migrasi lengkap aplikasi blue-green dari satu cluster GKE ke cluster GKE lainnya.

Men-deploy load balancing berbasis kapasitas

Latihan di bagian ini menunjukkan konsep load balancing dan kapasitas Service secara global dengan men-deploy aplikasi di dua cluster GKE di region berbeda. Traffic yang dihasilkan dikirim di berbagai tingkat permintaan per detik (RPS) untuk menunjukkan cara menyeimbangkan traffic di seluruh cluster dan region.

Diagram berikut menunjukkan topologi yang akan Anda deploy dan bagaimana traffic melakukan overflow antara cluster dan region ketika traffic telah melebihi kapasitas Service:

Traffic yang melakukan overflow dari satu cluster ke cluster lain

Untuk mempelajari pengelolaan traffic lebih lanjut, baca artikel Pengelolaan traffic GKE.

Menyiapkan lingkungan Anda

  1. Ikuti Mengaktifkan Gateway multi-cluster untuk mempersiapkan lingkungan Anda.

  2. Pastikan resource GatewayClass sudah diinstal di cluster konfigurasi:

    kubectl get gatewayclasses --context=gke-west-1

    Output-nya mirip dengan berikut ini:

    NAME                                  CONTROLLER                  ACCEPTED   AGE
gke-l7-global-external-managed        networking.gke.io/gateway   True       16h
gke-l7-global-external-managed-mc     networking.gke.io/gateway   True       14h
gke-l7-gxlb                           networking.gke.io/gateway   True       16h
gke-l7-gxlb-mc                        networking.gke.io/gateway   True       14h
gke-l7-regional-external-managed      networking.gke.io/gateway   True       16h
gke-l7-regional-external-managed-mc   networking.gke.io/gateway   True       14h
gke-l7-rilb                           networking.gke.io/gateway   True       16h
gke-l7-rilb-mc                        networking.gke.io/gateway   True       14h

Men-deploy aplikasi

Deploy contoh server aplikasi web ke kedua cluster:

kubectl apply --context gke-west-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-traffic-deploy.yaml
kubectl apply --context gke-east-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/store-traffic-deploy.yaml

Output-nya mirip dengan berikut ini:

namespace/store created
deployment.apps/store created

Men-deploy Service, Gateway, dan HTTPRoute

  1. Terapkan manifes Service berikut ke gke-west-1 dan gke-east-1 {i>cluster <i}(klaster):

    cat << EOF | kubectl apply --context gke-west-1 -f -
apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: traffic-test
  annotations:
    networking.gke.io/max-rate-per-endpoint: "10"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: traffic-test
EOF

    cat << EOF | kubectl apply --context gke-east-1 -f -
apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: traffic-test
  annotations:
    networking.gke.io/max-rate-per-endpoint: "10"
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: http
  selector:
    app: store
  type: ClusterIP
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: traffic-test
EOF

    Layanan dianotasi dengan max-rate-per-endpoint yang ditetapkan ke 10 permintaan per detik. Dengan 2 replika per cluster, setiap Layanan memiliki kapasitas 20 RPS dan menyediakan hingga 224 vCPU per cluster.

    Untuk mengetahui informasi selengkapnya tentang cara memilih tingkat kapasitas Service untuk Service Anda, lihat Menentukan kapasitas Service.

  2. Terapkan manifes Gateway berikut ke cluster konfigurasi, gke-west-1 dalam contoh ini:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store
  namespace: traffic-test
spec:
  gatewayClassName: gke-l7-global-external-managed-mc
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
EOF

    Manifes menjelaskan Gateway eksternal multi-cluster yang men-deploy Load Balancer Aplikasi eksternal dengan alamat IP yang dapat diakses publik.

  3. Terapkan manifes HTTPRoute berikut ke cluster konfigurasi, gke-west-1 dalam contoh ini:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: store
  namespace: traffic-test
  labels:
    gateway: store
spec:
  parentRefs:
  - kind: Gateway
    namespace: traffic-test
    name: store
  rules:
  - backendRefs:
    - name: store
      group: net.gke.io
      kind: ServiceImport
      port: 8080
EOF

    Manifes menjelaskan HTTPRoute yang mengonfigurasi Gateway dengan aturan perutean yang mengarahkan semua traffic ke ServiceImport penyimpanan. Tujuan store ServiceImport mengelompokkan Pod Service store di kedua cluster dan memungkinkan load balancer tersebut untuk ditangani oleh load balancer sebagai Layanan tunggal.

    Anda dapat memeriksa peristiwa {i>Gateway<i} setelah beberapa menit untuk melihat apakah sudah selesai di-deploy:

    kubectl describe gateway store -n traffic-test --context gke-west-1

    Outputnya mirip dengan hal berikut ini:

    ...
Status:
  Addresses:
    Type:   IPAddress
    Value:  34.102.159.147
  Conditions:
    Last Transition Time:  2023-10-12T21:40:59Z
    Message:               The OSS Gateway API has deprecated this condition, do not depend on it.
    Observed Generation:   1
    Reason:                Scheduled
    Status:                True
    Type:                  Scheduled
    Last Transition Time:  2023-10-12T21:40:59Z
    Message:               
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Last Transition Time:  2023-10-12T21:40:59Z
    Message:               
    Observed Generation:   1
    Reason:                Programmed
    Status:                True
    Type:                  Programmed
    Last Transition Time:  2023-10-12T21:40:59Z
    Message:               The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
    Observed Generation:   1
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Listeners:
    Attached Routes:  1
    Conditions:
      Last Transition Time:  2023-10-12T21:40:59Z
      Message:               
      Observed Generation:   1
      Reason:                Programmed
      Status:                True
      Type:                  Programmed
      Last Transition Time:  2023-10-12T21:40:59Z
      Message:               The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
      Observed Generation:   1
      Reason:                Ready
      Status:                True
      Type:                  Ready
    Name:                    http
    Supported Kinds:
      Group:  gateway.networking.k8s.io
      Kind:   HTTPRoute
Events:
  Type    Reason  Age                  From                   Message
  ----    ------  ----                 ----                   -------
  Normal  ADD     12m                  mc-gateway-controller  traffic-test/store
  Normal  SYNC    6m43s                mc-gateway-controller  traffic-test/store
  Normal  UPDATE  5m40s (x4 over 12m)  mc-gateway-controller  traffic-test/store
  Normal  SYNC    118s (x6 over 10m)   mc-gateway-controller  SYNC on traffic-test/store was a success

    Output ini menunjukkan bahwa Gateway berhasil di-deploy. Mungkin masih perlu waktu beberapa menit hingga traffic mulai diteruskan setelah Gateway di-deploy. Catat alamat IP di output ini karena akan digunakan pada langkah berikut.

Mengonfirmasi traffic

Pastikan traffic meneruskan ke aplikasi dengan menguji alamat IP Gateway menggunakan perintah curl:

curl GATEWAY_IP_ADDRESS

Output-nya mirip dengan berikut ini:

{
  "cluster_name": "gke-west-1",
  "host_header": "34.117.182.69",
  "pod_name": "store-54785664b5-mxstv",
  "pod_name_emoji": "👳🏿",
  "project_id": "project",
  "timestamp": "2021-11-01T14:06:38",
  "zone": "us-west1-a"
}

Output ini menampilkan metadata Pod yang menunjukkan region tempat permintaan disalurkan.

Memverifikasi traffic menggunakan pengujian beban

Untuk memastikan bahwa load balancer berfungsi, Anda dapat men-deploy generator traffic di cluster gke-west-1. Generator traffic akan menghasilkan traffic di berbagai level beban untuk menunjukkan kapasitas dan kemampuan tambahan dari load balancer. Langkah-langkah berikut menunjukkan tiga tingkat beban:

  • 10 RPS, yang berada di bawah kapasitas untuk Service penyimpanan di gke-west-1.
  • 30 RPS, yang melebihi kapasitas untuk Service penyimpanan gke-west-1 dan menyebabkan traffic mengalami overflow ke gke-east-1.
  • 60 RPS, yang melebihi kapasitas untuk Service di kedua cluster.

Mengonfigurasi dasbor

  1. Dapatkan nama URLmap dasar untuk Gateway Anda:

    kubectl get gateway store -n traffic-test --context=gke-west-1 -o=jsonpath="{.metadata.annotations.networking\.gke\.io/url-maps}"

    Output-nya mirip dengan berikut ini:

    /projects/PROJECT_NUMBER/global/urlMaps/gkemcg1-traffic-test-store-armvfyupay1t

  2. Di Konsol Google Cloud, buka halaman Metrics Explorer.

    Buka Metrics Explorer

  3. Di bagian Pilih metrik, klik KODE: MQL.

  4. Masukkan kueri berikut untuk mengamati metrik traffic untuk Service penyimpanan di kedua cluster Anda:

    fetch https_lb_rule
| metric 'loadbalancing.googleapis.com/https/backend_request_count'
| filter (resource.url_map_name == 'GATEWAY_URL_MAP')
| align rate(1m)
| every 1m
| group_by [resource.backend_scope],
    [value_backend_request_count_aggregate:
        aggregate(value.backend_request_count)]

    Ganti GATEWAY_URL_MAP dengan nama peta URL dari langkah sebelumnya.

  5. Klik Jalankan kueri. Tunggu minimal 5 menit setelah men-deploy generator beban di bagian berikutnya agar metrik ditampilkan dalam diagram.

Menguji dengan 10 RPS

  1. Deploy Pod ke cluster gke-west-1 Anda:

    kubectl run --context gke-west-1 -i --tty --rm loadgen  \
    --image=cyrilbkr/httperf  \
    --restart=Never  \
    -- /bin/sh -c 'httperf  \
    --server=GATEWAY_IP_ADDRESS  \
    --hog --uri="/zone" --port 80  --wsess=100000,1,1 --rate 10'

    Ganti GATEWAY_IP_ADDRESS dengan alamat IP Gateway dari langkah sebelumnya.

    Output-nya mirip dengan yang berikut ini, dan menunjukkan bahwa generator traffic sedang mengirimkan traffic:

    If you don't see a command prompt, try pressing enter.

    Generator beban terus mengirimkan 10 RPS ke Gateway. Meskipun traffic berasal dari dalam region Google Cloud, load balancer memperlakukannya sebagai traffic klien yang berasal dari Pantai Barat AS. Untuk menyimulasikan keberagaman klien yang realistis, generator beban akan mengirimkan setiap permintaan HTTP sebagai koneksi TCP baru, yang berarti traffic didistribusikan di seluruh Pod backend secara lebih merata.

    Generator memerlukan waktu hingga 5 menit agar dapat menghasilkan traffic untuk dasbor.

  2. Lihat dasbor Metrics Explorer Anda. Dua baris muncul, yang menunjukkan jumlah traffic yang di-load balancing ke setiap cluster:

    Grafik yang menampilkan beban traffic yang di-load balancing ke cluster

    Anda akan melihat bahwa us-west1-a menerima traffic sekitar 10 RPS, sedangkan us-east1-b tidak menerima traffic apa pun. Karena generator traffic berjalan di us-west1, semua traffic dikirim ke Service di cluster gke-west-1.

  3. Hentikan generator beban menggunakan Ctrl+C, lalu hapus pod:

    kubectl delete pod loadgen --context gke-west-1

Menguji dengan 30 RPS

  1. Deploy generator beban lagi, tetapi kali ini dikonfigurasi untuk mengirim 30 RPS:

    kubectl run --context gke-west-1 -i --tty --rm loadgen  \
    --image=cyrilbkr/httperf  \
    --restart=Never  \
    -- /bin/sh -c 'httperf  \
    --server=GATEWAY_IP_ADDRESS  \
    --hog --uri="/zone" --port 80  --wsess=100000,1,1 --rate 30'

    Generator memerlukan waktu hingga 5 menit agar dapat menghasilkan traffic untuk dasbor.

  2. Melihat dasbor Cloud Ops Anda.

    Grafik yang menampilkan traffic yang mengalami overflow hingga ke gke-east-1

    Anda akan melihat bahwa sekitar 20 RPS dikirim ke us-west1-a dan 10 RPS ke us-east1-b. Hal ini menunjukkan bahwa Service di gke-west-1 telah digunakan sepenuhnya dan mengalami overflow 10 RPS traffic ke Service di gke-east-1.

  3. Hentikan generator beban menggunakan Ctrl+C, lalu hapus Pod:

    kubectl delete pod loadgen --context gke-west-1

Menguji dengan 60 RPS

  1. Deploy generator beban yang dikonfigurasi untuk mengirim 60 RPS:

    kubectl run --context gke-west-1 -i --tty --rm loadgen  \
    --image=cyrilbkr/httperf  \
    --restart=Never  \
    -- /bin/sh -c 'httperf  \
    --server=GATEWAY_IP_ADDRESS  \
    --hog --uri="/zone" --port 80  --wsess=100000,1,1 --rate 60'

  2. Tunggu 5 menit, lalu lihat dasbor Cloud Ops Anda. Sekarang, dasbor seharusnya sudah menunjukkan bahwa kedua cluster menerima sekitar 30 RPS. Karena semua Service digunakan berlebihan secara global, tidak ada spillover traffic dan Service akan menyerap semua traffic semaksimal mungkin.

    Grafik yang menunjukkan Service yang digunakan berlebihan

  3. Hentikan generator beban menggunakan Ctrl+C, lalu hapus Pod:

    kubectl delete pod loadgen --context gke-west-1

Pembersihan

Setelah menyelesaikan latihan di halaman ini, ikuti 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

Menggunakan Gateway multi-cluster dengan VPC Bersama

Gateway multi-cluster juga dapat di-deploy di lingkungan VPC Bersama, dengan topologi yang berbeda, tergantung pada kasus penggunaannya.

Tabel berikut menjelaskan topologi Gateway multi-cluster yang didukung dalam lingkungan VPC Bersama:

Skenario Project host fleet Cluster konfigurasi Cluster workload
1 Project host VPC Bersama Project host VPC Bersama Project host VPC Bersama
2 Project layanan VPC Bersama Project layanan VPC bersama
(Sama seperti project layanan fleet)		 Project layanan VPC bersama
(Sama seperti project layanan fleet)

Untuk membuat Gateway multi-cluster di lingkungan VPC Bersama, gunakan langkah-langkah berikut:

  1. Ikuti langkah-langkah untuk menyiapkan Layanan multi-cluster dengan VPC Bersama

  2. Membuat dan mengekspor layanan ke cluster konfigurasi

  3. Jika Anda berencana menggunakan Gateway internal multi-cluster, buat subnet khusus proxy

  4. Membuat multi-cluster eksternal Anda atau internal Gateway dan HTTPRoutes

Setelah selesai dengan langkah-langkah ini, Anda dapat memvalidasi deployment, tergantung tentang topologi Anda.

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 responsif

Gejala:

Masalah berikut mungkin terjadi saat Anda membuat {i>Gateway<i} tetapi tidak dapat mengakses layanan backend (kode respons 503):

no healthy upstream

Alasan:

Pesan error ini menunjukkan bahwa prober health check tidak dapat menemukan respons yang responsif dan layanan backend. Mungkin saja layanan backend Anda responsif tetapi Anda mungkin perlu menyesuaikan health check.

Solusi:

Untuk mengatasi masalah ini, sesuaikan health check Anda berdasarkan persyaratan (misalnya, /health) menggunakan HealthCheckPolicy.

Langkah selanjutnya