Men-deploy Gateway multi-cluster eksternal

Dokumen ini memandu Anda melalui contoh praktis untuk men-deploy Gateway multi-cluster eksternal guna merutekan traffic internet 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.

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 cluster gke-west-1 dan gke-east-1.
  2. Konfigurasi Service di setiap cluster yang akan diekspor ke fleet Anda (Service multi-cluster).
  3. 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 Menyiapkan lingkungan untuk 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 pengontrol Gateway GKE menggunakan load balancing berbasis container, pengontrol ini tidak menggunakan load balancing ClusterIP atau Kubernetes untuk menjangkau Pod. Traffic dikirim langsung dari load balancer ke alamat IP Pod. Namun, Service masih memainkan peran penting sebagai ID logis untuk pengelompokan Pod.

Multi-cluster Services (MCS) adalah standar API untuk Service yang mencakup cluster dan pengontrol GKE-nya menyediakan penemuan layanan di seluruh cluster GKE. Pengontrol Gateway multi-cluster menggunakan resource API MCS untuk mengelompokkan Pod ke dalam Service yang dapat ditangani di seluruh cluster atau menjangkau 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 berpasangan. 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 dibuat di cluster yang memungkinkan Pod di gke-west-1 dapat diakses dari cluster lain di fleet. ServiceExport dipetakan ke dan menampilkan Service 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. Dengan adanya ServiceImport, Pod client di gke-east-1 dapat menggunakan ClusterIP atau Service headless untuk menjangkau Pod store di gke-west-1. Jika digunakan dengan cara ini, Service multi-cluster akan menyediakan load balancing east-west antar-cluster tanpa memerlukan Layanan LoadBalancer internal. Agar dapat menggunakan Service multi-cluster untuk load balancing cluster-to-cluster, lihat Mengonfigurasi Service multi-cluster.

Service multi-cluster mengekspor Service ke berbagai 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/v1
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 dan store-west-1 Service dan ServiceExport:

    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 dan store-east-1 Service dan ServiceExport:

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

    Output menunjukkan bahwa Service store berisi Pod store di kedua cluster, dan Service store-west-1 serta 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, pastikan ServiceImports yang menyertainya telah otomatis dibuat oleh pengontrol Service 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/v1
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 konvensi penamaan berikut: 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:
      • Pemeriksaan kondisi 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/v1
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 deployment, HTTPRoute ini akan mengonfigurasi perilaku perutean berikut:

    • Permintaan ke /west dirutekan ke Pod store di cluster gke-west-1, karena Pod yang dipilih oleh ServiceExport store-west-1 hanya ada di cluster gke-west-1.
    • Permintaan ke /east dirutekan ke Pod store di cluster gke-east-1, karena Pod yang dipilih oleh ServiceExport store-east-1 hanya ada di cluster gke-east-1.
    • Permintaan ke jalur lain akan diarahkan ke Pod store 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 menggunakan Service yang tumpang-tindih

    Perhatikan bahwa jika semua Pod di cluster tertentu tidak responsif (atau tidak ada), traffic ke Service store hanya akan dikirim ke cluster yang benar-benar memiliki Pod store. Keberadaan ServiceExport dan Service di cluster tertentu tidak menjamin bahwa traffic 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:
      • Pemeriksaan kesehatan store: gkemcg1-store-store-8080-HASH
      • Pemeriksaan kesehatan store-east-1: gkemcg1-store-store-east-1-8080-HASH
      • Pemeriksaan kesehatan store-west-1: gkemcg1-store-store-west-1-8080-HASH
    • 1 aturan perutean di URLmap:
      • Aturan pemilihan rute store.example.com:
      • 1 Host: store.example.com
      • Beberapa matchRules untuk merutekan 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 Gateway dan Multi-cluster Service di kedua cluster

Perhatikan bahwa ini adalah model resource logis, bukan penggambaran alur traffic. 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 Gateway.

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

    Output Anda akan terlihat mirip 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/v1
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 dilayani oleh Pod dari cluster 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. Tindakan ini akan merutekan traffic ke store-west-1 ServiceImport yang hanya memiliki Pod yang berjalan di cluster gke-west-1. Dengan ServiceImport khusus cluster, seperti store-west-1, pemilik aplikasi dapat mengirim traffic ke cluster tertentu secara eksplisit, bukan membiarkan load balancer membuat keputusan.

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

    Output mengonfirmasi bahwa permintaan dilayani oleh Pod dari cluster 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 dilayani oleh Pod dari cluster 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"
}

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

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