Halaman ini diterjemahkan oleh Cloud Translation API.

Melakukan migrasi ke jaringan multi-cluster dengan cluster Autopilot dan cluster Standard Google Kubernetes Engine (GKE)

Last reviewed 2022-02-17 UTC

Autopilot Standard

Jaringan multi-cluster adalah alat berharga yang memungkinkan kasus penggunaan seperti ketersediaan tinggi regional, jarak yang terdistribusi secara global dengan pengguna untuk latensi yang lebih rendah, dan isolasi organisasi antar-tim. Google Kubernetes Engine (GKE) menyediakan kemampuan bawaan untuk jaringan multi-cluster yang dapat Anda aktifkan dan gunakan dalam skala besar di seluruh fleet cluster GKE. Fitur ini juga memungkinkan Anda menggabungkan, atau memigrasikan infrastruktur yang di-deploy antara GKE Standard dan Autopilot untuk memenuhi kebutuhan arsitektur setiap aplikasi.

Dengan cluster Autopilot GKE, Google akan mengelola infrastruktur, termasuk bidang kontrol dan node. Jika Anda ingin mengonfigurasi dan mengelola node, GKE menyediakan mode Standard. Untuk mengetahui informasi selengkapnya tentang perbedaan antara mode, lihat Memilih mode operasi cluster.

Halaman ini menunjukkan fitur tersebut melalui beberapa topologi deployment. Anda akan mempelajari cara mengambil aplikasi yang di-deploy dalam satu cluster GKE dan memigrasikannya ke deployment multi-cluster di seluruh cluster GKE Standard dan Autopilot. Anda menggunakan Service multi-cluster GKE untuk traffic east-west dan Gateway multi-cluster untuk mengaktifkan jaringan north-south multi-cluster.

Halaman ini ditujukan untuk arsitek cloud dan tim operasi yang menggunakan, atau berencana menggunakan, GKE untuk men-deploy layanan di beberapa cluster Kubernetes. Sebelum membaca halaman ini, pastikan Anda sudah memahami Kubernetes.

Service Multi-cluster dan Gateway multi-cluster

Kubernetes dapat berjalan menggunakan satu bidang kontrol di berbagai zona cloud untuk memberikan ketahanan dan ketersediaan yang lebih tinggi untuk layanan Anda. GKE setingkat lebih maju dan menyediakan Service multi-cluster (MCS) GKE yang menyediakan mekanisme penemuan dan pemanggilan layanan lintas cluster. Layanan yang menggunakan fitur ini dapat ditemukan dan diakses di seluruh cluster dengan IP virtual, yang sesuai dengan perilaku Service ClusterIP yang dapat diakses dalam cluster. Pendekatan ini memungkinkan Anda mendapatkan manfaat berikut:

Layanan dapat di-load balance di beberapa cluster di region yang sama atau region yang berbeda (traffic east-west).
Opsi ketersediaan tinggi layanan lintas region dapat dicapai.
Workload stateful dan stateless dapat di-deploy dan dikelola di berbagai cluster yang terpisah.
Layanan bersama tersedia di seluruh cluster.

Untuk mempelajari cara men-deploy MCS lebih lanjut, lihat Mengonfigurasi Service multi-cluster.

GKE menyediakan penerapan Kubernetes Gateway API yang menggunakan GKE Gateway Controller. Dengan Gateway, GKE dapat men-deploy load balancer Google Cloud untuk menyediakan perutean traffic masuk (north-south) bagi layanan yang di-deploy di GKE. GKE juga menyediakan Gateway multi-cluster (MCG) yang memperluas pengontrol Gateway GKE untuk menyediakan load balancer yang mengarahkan traffic ke layanan yang di-deploy di cluster GKE yang berbeda.

Diagram berikut menunjukkan bagaimana saat Anda menggabungkan MCS dan MCG, Anda dapat mengelola aspek komplementer deployment layanan dan pemilihan rute traffic dari satu bidang kontrol:

Layanan Multi-cluster memfasilitasi komunikasi antara layanan dalam Gateway cluster dan multi-cluster men-deploy load balancer untuk mengarahkan traffic di berbagai cluster.

Untuk mengetahui informasi selengkapnya, lihat Men-deploy Gateway multi-cluster.

Ringkasan migrasi

Kemampuan jaringan multi-cluster GKE menguntungkan workload dari berbagai profil. Misalnya, Anda mungkin memiliki komponen stateless dengan traffic burst yang ingin Anda pindahkan ke Autopilot karena model biayanya yang lebih efisien.

Atau, Anda mungkin ingin menempatkan frontend aplikasi lebih dekat dengan pengguna. Pendekatan ini memberikan latensi yang lebih rendah dan caching yang meningkatkan performa aplikasi dan pengalaman pengguna. Namun, Anda mungkin memiliki beberapa komponen stateful yang diandalkan aplikasi yang hanya dapat berada di satu lokasi. Konfigurasi ini memerlukan load balancing multi-cluster north-south untuk mengirim traffic klien ke cluster yang benar di lokasi tersebut. Anda juga memerlukan load balancing multi-cluster east-west untuk mengirim traffic antar-cluster untuk mencapai komponen stateful.

Halaman ini menggunakan aplikasi demo microservice cloud Online Boutique untuk menunjukkan pola multi-cluster yang dapat digunakan untuk meningkatkan deployment demo zona tunggal. Anda memulai dengan aplikasi versi zona tunggal. Kemudian, tambahkan elemen ketersediaan dan ketahanan tinggi menggunakan Service multi-cluster dan Gateway multi-cluster, serta mengurangi toil operasional dengan memanfaatkan Autopilot.

Deployment cluster tunggal awal

Dalam diagram berikut, aplikasi Butik Online awalnya di-deploy ke satu cluster mode GKE Standard bernama std-west, dan diekspos menggunakan Service LoadBalancer:

Satu cluster GKE mode Standard yang menjalankan semua layanan yang diekspos menggunakan layanan LoadBalancer eksternal HTTP reguler.

Bermigrasi ke Service multi-cluster

Pada langkah perantara berikutnya, Anda membuat dua cluster tambahan, dan layanan stateless akan di-deploy di region tambahan. Anda membuat dua cluster GKE Autopilot bernama auto-east dan auto-central di dua region terpisah yang berbeda dari std-west Cluster GKE Standard, dan daftarkan cluster ke Google Cloud fleet.

Fleet adalah konsep Google Cloud untuk mengatur cluster dan resource lainnya secara logis, serta memungkinkan Anda menggunakan dan mengelola kemampuan multi-cluster serta menerapkan kebijakan yang konsisten di seluruh sistem Anda.

Anda mengekspor cartservice di cluster std-west di namespace onlineboutique ke cluster fleet baru menggunakan ServiceExport. Anda men-deploy Service frontend Online Boutique di ketiga cluster dan menampilkannya melalui layanan ClusterIP. Kemudian, Anda mengekspor layanan ke fleet menggunakan ServiceExports. Service seperti lapisan middleware Online Boutique (seperti productcatalog, shipping, dan adservice) juga di-deploy ke ketiga cluster.

Pod yang berjalan di cluster mana pun di fleet dapat mengakses Service yang diekspor dengan mengirimkan permintaan ke URI ClusterSet untuk layanan tersebut. Permintaan ini diarahkan ke endpoint yang mendukung layanan.

Service frontend dapat menggunakan layanan middleware (seperti productcatalogservice atau currencyservice) secara lokal di cluster yang sama. Arsitektur ini membantu menjaga permintaan masuk tetap lokal untuk region yang frontend-nya merespons permintaan, dan menghindari biaya traffic jaringan antar-region yang tidak perlu.

Diagram berikut mengilustrasikan dua Service multi-cluster. Service frontend stateless di-deploy ke tiga cluster, dan cartservice backend stateful di-deploy ke satu cluster. Diagram juga menunjukkan bahwa dalam langkah perantara ini, traffic masuk untuk layanan frontend tetap dirutekan ke cluster GKE Standard asli di us-west1 menggunakan Load Balancer Jaringan passthrough eksternal yang dibuat oleh Service LoadBalancer frontend-eksternal:

Service multi cluster berjalan di tiga cluster GKE, tetapi traffic masih diarahkan ke satu cluster menggunakan layanan LoadBalancer eksternal HTTP reguler.

Bermigrasi ke Gateway multi-cluster

Pada langkah terakhir, arahkan traffic masuk untuk Service frontend dari permintaan klien eksternal ke layanan di beberapa cluster dalam fleet menggunakan Gateway multi-cluster.

Cluster keempat bernama config-central ditambahkan ke fleet untuk menghosting dan mengelola konfigurasi untuk resource Gateway dan HTTPRoute yang dibuat sebagai bagian dari konfigurasi ini. Resource HTTPRoute memetakan awalan / ke ServiceImport frontend. Traffic untuk frontend Online Boutique dikirim ke endpoint yang responsif di salah satu region yang tersedia. Pendekatan ini menambahkan elemen ketersediaan tinggi pada arsitektur aplikasi Online Boutique.

Dalam diagram berikut, Gateway multi-cluster men-deploy Load Balancer Cloud Global yang merutekan traffic eksternal ke Service frontend stateless yang di-deploy pada masing-masing dari tiga cluster aplikasi di fleet.

Service multi cluster yang berjalan di tiga cluster GKE dan traffic kini didistribusikan di seluruh layanan frontend di semua cluster menggunakan Gateway eksternal multi-cluster.

Pada status akhir, pola opini ini menunjukkan pengaitan longgar antara bagian stateful (cartservice dan redis-cart) dan bagian stateless dari aplikasi (frontend, emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice , currencyservice, shippingservice, dan adservice). Meskipun berada di luar cakupan halaman ini, pendekatan ini memberi Anda peluang pada masa mendatang untuk menambahkan ketahanan dan ketersediaan tinggi ke lapisan layanan stateful.

Tujuan

Membuat dan mengonfigurasi cluster GKE Standard dan Autopilot.
Men-deploy Online Boutique ke cluster GKE Standard zona.
Mengekspor Services multi-cluster.
Men-deploy manifes ke cluster Standard dan Autopilot.
Mengaktifkan dan mengonfigurasi Gateway multi-cluster.
Menguji perilaku aplikasi multi-region.

Biaya

Dalam dokumen ini, Anda akan menggunakan komponen Google Cloud yang dapat ditagih berikut:

Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda, gunakan kalkulator harga. Pengguna baru Google Cloud mungkin memenuhi syarat untuk mendapatkan uji coba gratis.

Sebelum memulai

Batasan keamanan yang ditentukan oleh organisasi mungkin mencegah Anda menyelesaikan langkah-langkah berikut. Untuk mengetahui informasi pemecahan masalah, lihat Mengembangkan aplikasi di lingkungan Google Cloud yang terbatas.

Sebelum memulai, pastikan Anda memenuhi persyaratan berikut:

Sebaiknya gunakan project baru untuk panduan ini, karena cara termudah untuk melakukan pembersihan adalah dengan menghapus project setelah Anda selesai.
Panduan ini mengasumsikan bahwa Anda memiliki peran Owner IAM untuk project Google Cloud Anda. Untuk setelan produksi atau dunia nyata, praktik terbaiknya adalah menerapkan cakupan izin ke hak istimewa terendah. Untuk mengetahui informasi selengkapnya, lihat Menggunakan IAM dengan aman dan Mengelola identitas dan akses.
Pahami arsitektur aplikasi demo microservice Online Boutique.

Menyiapkan lingkungan

Dalam panduan ini, Anda menggunakan Cloud Shell untuk memasukkan perintah. Cloud Shell memberi Anda akses ke command line di Konsol Google Cloud dan mencakup Google Cloud SDK serta alat lainnya, seperti Google Cloud CLI. Cloud Shell akan muncul sebagai jendela di bagian bawah Konsol Google Cloud. Perlu waktu beberapa menit untuk melakukan inisialisasi, tetapi jendela akan segera muncul.

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
Di Cloud Shell, tentukan variabel lingkungan yang digunakan dalam panduan ini. Ganti PROJECT_ID dengan project ID Anda:
```
export PROJECT=PROJECT_ID
gcloud config set project ${PROJECT}
```

Aktifkan layanan yang diperlukan untuk langkah-langkah di halaman ini:

gcloud services enable \
    gkehub.googleapis.com \
    multiclusteringress.googleapis.com \
    dns.googleapis.com \
    trafficdirector.googleapis.com \
    cloudresourcemanager.googleapis.com \
    multiclusterservicediscovery.googleapis.com \
    container.googleapis.com

gcloud container fleet multi-cluster-services enable

Layanan Multi-cluster mengelola komponen Google Cloud seperti Cloud DNS, aturan firewall, dan Cloud Service Mesh, sehingga API ini juga harus diaktifkan. Untuk informasi selengkapnya, lihat Ringkasan Cloud Service Mesh.

Outputnya mirip dengan contoh berikut:

Operation "operations/acf.p2-822685001869-ee4ebe78-6dd8-465e-b0fd-3b0e5f964bad"
finished successfully.

Waiting for Feature Multi-cluster Services to be created...done.

Verifikasi bahwa Service multi-cluster menampilkan status ACTIVE:

gcloud container fleet multi-cluster-services describe

Outputnya mirip dengan contoh berikut:

createTime: '2021-11-30T21:59:25.245190894Z'
name: projects/PROJECT_ID/locations/global/features/multiclusterservicediscovery
resourceState:
  state: ACTIVE
spec: {}
updateTime: '2021-11-30T21:59:27.459063070Z'

Jika nilai status tidak ACTIVE, lihat detail pemecahan masalah layanan multi-cluster.

Membuat dan mengonfigurasi cluster GKE

Untuk mendemonstrasikan pola multi-cluster dalam panduan ini, Anda harus menggunakan tiga cluster aplikasi di tiga region cloud terpisah, dan satu cluster untuk menghosting konfigurasi untuk resource Gateway. Anda mendaftarkan semua cluster ke fleet yang terkait dengan proyek Anda. Project Google Cloud hanya dapat memiliki satu fleet yang terkait dengannya. Project ini dikenal sebagai project host fleet.

Buat cluster GKE Standard dan Autopilot:

gcloud container clusters create std-west \
    --zone us-west1-a \
    --num-nodes=6 \
    --enable-ip-alias \
    --release-channel regular \
    --workload-pool=${PROJECT}.svc.id.goog \
    --async

gcloud container clusters create-auto auto-east \
    --region us-east1 \
    --release-channel regular \
    --async

gcloud container clusters create-auto auto-central \
    --region us-central1 \
    --release-channel regular \
    --async

gcloud container clusters create config-central \
    --region us-central1 \
    --num-nodes=1 \
    --enable-ip-alias \
    --release-channel regular \
    --workload-pool=${PROJECT}.svc.id.goog \
    --async

Workload Identity Federation untuk GKE diaktifkan secara default di cluster GKE Autopilot sehingga Anda tidak perlu menggunakan flag --workload-pool saat membuat cluster tersebut seperti yang Anda lakukan dengan cluster GKE Standard.

Tunggu hingga STATUS cluster berubah dari PROVISIONING menjadi RUNNING. Proses ini bisa menghabiskan waktu hingga 10 menit. Anda dapat memantau progresnya dengan menggunakan loop smartwatch:

watch -n 20 --difference=permanent "gcloud container clusters list"

Outputnya mirip dengan contoh berikut:

NAME: auto-central
LOCATION: us-central1
MASTER_VERSION: 1.21.5-gke.1802
MASTER_IP: 107.178.213.138
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.21.5-gke.1802
NUM_NODES: 3
STATUS: PROVISIONING

NAME: config-central
LOCATION: us-central1
MASTER_VERSION: 1.21.5-gke.1802
MASTER_IP:
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.21.5-gke.1802
NUM_NODES: 9
STATUS: PROVISIONING

NAME: auto-east
LOCATION: us-east1
MASTER_VERSION: 1.21.5-gke.1802
MASTER_IP: 35.229.88.209
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.21.5-gke.1802
NUM_NODES: 3
STATUS: PROVISIONING

NAME: std-west
LOCATION: us-west1-a
MASTER_VERSION: 1.21.5-gke.1802
MASTER_IP: 35.197.93.113
MACHINE_TYPE: e2-medium
NODE_VERSION: 1.21.5-gke.1802
NUM_NODES: 6
STATUS: PROVISIONING

Setelah semua cluster berada dalam status RUNNING, tekan CTRL-C untuk menginterupsi perintah.
Tambahkan binding kebijakan Identity and Access Management (IAM) yang memberikan peran Network User ke akun layanan MCS project host fleet untuk project-nya sendiri:
```
gcloud projects add-iam-policy-binding ${PROJECT} \
    --member "serviceAccount:${PROJECT}.svc.id.goog[gke-mcs/gke-mcs-importer]" \
    --role "roles/compute.networkViewer"
```
Anda dapat menggunakan Workload Identity Federation untuk GKE guna memberikan akses baca layanan MCS ke konfigurasi jaringan VPC project Anda. Oleh karena itu, akun layanan Importer GKE MCS project yang menghosting fleet tersebut memerlukan peran ini.

Outputnya mirip dengan contoh berikut:
```
- members:
  - serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer]
  role: roles/compute.networkViewer
[...]
```

Daftarkan cluster GKE Standard dan Autopilot ke fleet project Anda. Lihat Mendaftarkan cluster untuk mengetahui detail selengkapnya. Proses ini dapat memerlukan waktu hingga 5 menit:

gcloud container fleet memberships register std-west \
    --gke-cluster us-west1-a/std-west \
    --enable-workload-identity \
    --project=${PROJECT}

gcloud container fleet memberships register auto-east \
    --gke-cluster us-east1/auto-east \
    --enable-workload-identity \
    --project=${PROJECT}

gcloud container fleet memberships register auto-central \
    --gke-cluster us-central1/auto-central \
    --enable-workload-identity \
    --project=${PROJECT}

gcloud container fleet memberships register config-central \
    --gke-cluster us-central1/config-central \
    --enable-workload-identity \
    --project=${PROJECT}

Untuk setiap perintah, output-nya mirip dengan contoh berikut:

Waiting for membership to be created...done.
Created a new membership [projects/PROJECT_ID/locations/global/memberships/std-west] for the cluster [std-west]
Generating the Connect Agent manifest...
Deploying the Connect Agent on cluster [std-west] in namespace [gke-connect]...
Deployed the Connect Agent on cluster [std-west] in namespace [gke-connect].
Finished registering the cluster [std-west] with the Hub.

Hubungkan ke cluster dan buat entri kubeconfig:

gcloud container clusters get-credentials std-west \
    --zone us-west1-a --project $PROJECT

gcloud container clusters get-credentials auto-east \
    --region us-east1 --project $PROJECT

gcloud container clusters get-credentials auto-central \
    --region us-central1 --project $PROJECT

gcloud container clusters get-credentials config-central \
    --region us-central1 --project $PROJECT

Untuk setiap perintah, output-nya mirip dengan contoh berikut:

Fetching cluster endpoint and auth data.
kubeconfig entry generated for std-west.

Ganti nama konteks untuk cluster agar lebih mudah digunakan dalam bagian lain halaman ini:

kubectl config rename-context \
    gke_${PROJECT}_us-west1-a_std-west \
    std-west

kubectl config rename-context \
    gke_${PROJECT}_us-east1_auto-east \
    auto-east

kubectl config rename-context \
    gke_${PROJECT}_us-central1_auto-central \
    auto-central

kubectl config rename-context \
    gke_${PROJECT}_us-central1_config-central \
    config-central

Dalam panduan ini, konteks diberi nama berdasarkan lokasinya. Meskipun Anda dapat memberikan nama alternatif, langkah selanjutnya dalam panduan ini menggunakan nama yang digunakan dalam langkah ini.

Men-deploy Online Boutique di GKE Standard

Pada langkah pertama deployment demonstrasi, Anda akan men-deploy set lengkap layanan aplikasi Online Boutique ke satu cluster GKE Standard Standard std-west di us-west1.

Buat namespace onlineboutique di std-west:

kubectl create namespace onlineboutique --context std-west

Outputnya mirip dengan contoh berikut:

namespace/onlineboutique created

Clone repositori GitHub Online Boutique dan siapkan variabel WORKDIR:

cd ~

git clone --branch release/v0.4.1 \
    https://github.com/GoogleCloudPlatform/microservices-demo.git

cd microservices-demo/release && export WORKDIR=`pwd`

Mendeploy Online Boutique di std-west. Proses ini membuat Deployments dan Services untuk semua microservice Online Boutique, dan mencakup Service jenis LoadBalancer yang mengekspos layanan frontend Online Boutique secara eksternal:
```
cd $WORKDIR

kubectl apply -f kubernetes-manifests.yaml \
    -n onlineboutique --context=std-west
```

Tunggu Service LoadBalancer mendapatkan IP eksternal:

watch -n 20 --difference=permanent \
     "kubectl get svc frontend-external -n onlineboutique --context=std-west"

Pada awalanya, outputnya mirip dengan contoh berikut:

NAME                TYPE           CLUSTER-IP   EXTERNAL-IP   PORT(S)        AGE
frontend-external   LoadBalancer   10.60.5.62   <pending>     80:30359/TCP   43s

Jika Service sudah siap, kolom EXTERNAL-IP akan menampilkan alamat IP publik load balancer.

Setelah Service siap, dapatkan alamat IP eksternal load balancer dan gunakan curl untuk memverifikasi bahwa frontend sudah siap. Jika perintah curl ini menampilkan error, tunggu beberapa saat sebelum Anda mencoba lagi:

  curl $(kubectl get svc frontend-external \
      -n onlineboutique --context=std-west \
      -o=jsonpath="{.status.loadBalancer.ingress[0].ip}") | \
        grep -e Cluster -e Zone -e Pod

Output perintah curl yang berhasil mirip dengan contoh berikut:

<b>Cluster: </b>std-west<br/>
<b>Zone: </b>us-west1-a<br/>
<b>Pod: </b>frontend-b7bddcc97-wdjsk

Anda kini memiliki versi Online Boutique satu zona yang berjalan di us-west1-a. Anda juga dapat menggunakan browser web untuk membuka IP eksternal yang ditetapkan ke Service LoadBalancer frontend-external guna mengakses aplikasi dan mengamati perilakunya. Deployment tunggal awal ini ditampilkan dalam diagram berikut:

Satu cluster GKE mode Standard yang menjalankan semua layanan yang diekspos melalui layanan LoadBalancer eksternal HTTP reguler.

Mengekspor cartservice sebagai Service multi-cluster

Di bagian ini, Anda akan mulai menambahkan elemen ketersediaan tinggi ke aplikasi. Anda mengekspor cartservice backend sebagai Service multi-cluster ke cluster GKE Autopilot.

Buat namespace onlineboutique di cluster yang tersisa:

kubectl create namespace onlineboutique --context auto-east

kubectl create namespace onlineboutique --context auto-central

kubectl create namespace onlineboutique --context config-central

Untuk setiap perintah, output-nya mirip dengan contoh berikut:

namespace/onlineboutique created

Ekspor cartservice dari cluster std-west ke semua cluster lain di ClusterSet. Objek ServiceExport mendaftarkan Service cartservice, dengan Service multi-cluster GKE, untuk diekspor ke semua cluster dalam fleet yang memiliki namespace onlineboutique saat ini. Untuk mengetahui detail selengkapnya, lihat mendaftarkan layanan untuk ekspor.
```
cat <<EOF>> $WORKDIR/cartservice-export.yaml
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
 namespace: onlineboutique
 name: cartservice

EOF

kubectl apply -f $WORKDIR/cartservice-export.yaml \
 -n onlineboutique --context=std-west
```

Menerapkan manifes aplikasi untuk pola multi-cluster

Di bagian ini, Anda akan menerapkan dua manifes pilihan untuk men-deploy pola multi-cluster. Manifes ini berisi bagian yang dipilih dari kubernetes-manifests.yaml yang sebelumnya Anda terapkan ke cluster std-west:

Manifes pertama digunakan untuk frontend Deployment, Service, dan ServiceExport.
Manifes kedua digunakan untuk men-deploy middleware Services (emailservice, checkoutservice, recommendationservice, paymentservice, productcatalogservice, currencyservice, shippingservice, dan adservice) ke semua region yang menjalankan frontend. Dengan menyimpan permintaan secara lokal ke suatu region selama mungkin, Anda akan terhindar dari biaya traffic jaringan antar-region yang tidak perlu.

Pod yang berjalan di cluster mana pun di fleet dapat mengakses Service yang diekspor dengan mengirimkan permintaan ke URI ClusterSet untuk layanan tersebut dalam format SERVICE_NAME.NAMESPACE.svc.clusterset.local. Misalnya, Deployments frontend di ketiga cluster contoh dapat menggunakan cartservice, dalam namespace onlineboutique, dengan membuat permintaan ke cartservice.onlineboutique.svc.clusterset.local.

Oleh karena itu, di setiap manifes, nama host untuk cartservice telah diperbarui menjadi URI ClusterSet-nya. Langkah ini sangat penting. Jika nama host layanan ini tidak diperbarui, Service frontend akan meminta kube-dns untuk cartservice, bukan cartservice.onlineboutique.svc.clusterset.local. Perilaku ini akan menyebabkan error HTTP Status 500 pada cluster tempat versi lokal cartservice tidak tersedia, dan menyebabkan pod frontend menjadi tidak responsif.

Tetapkan variabel lingkungan untuk repositori GitHub yang berisi manifes:

export MANIFEST_REPO_PATH=https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/master/gateway/docs/cluster-migration

Terapkan manifes untuk men-deploy lapisan frontend ke ketiga cluster workload:

kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \
    -n onlineboutique --context=std-west

kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \
    -n onlineboutique --context=auto-east

kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-frontend-manifests.yaml \
    -n onlineboutique --context=auto-central

Terapkan manifes untuk men-deploy lapisan middleware ke ketiga cluster workload:

kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
    -n onlineboutique --context=std-west

kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
    -n onlineboutique --context=auto-east

kubectl apply -f ${MANIFEST_REPO_PATH}/onlineboutique-middleware-manifests.yaml \
    -n onlineboutique --context=auto-central

Anda kini memiliki frontend Deployment, Service, dan ServiceExport yang aktif dalam cluster std-west dan auto-east, danauto-central. Anda juga memiliki layanan middleware Online Boutique yang berjalan secara lokal di setiap cluster. Namun, traffic eksternal masih dirutekan hanya ke Service yang berjalan di cluster awal di us-west1, seperti yang ditunjukkan pada diagram berikut:

Service multi cluster berjalan di tiga cluster GKE, tetapi traffic masih diarahkan ke satu cluster menggunakan layanan LoadBalancer eksternal HTTP reguler.

Mengaktifkan dan mengonfigurasi Gateway multi-cluster

Di bagian ini, Anda akan merutekan traffic ke dan melakukan load balancing pada traffic eksternal ke seluruh frontend pada ketiga cluster. Untuk mencapai konfigurasi ini, gunakan Gateway multi-cluster (MCG). Langkah-langkah untuk menyiapkan MCG ini mengikuti panduan yang dijelaskan secara lebih mendetail di Mengaktifkan Gateway multi-cluster.

Pada langkah-langkah ini, Anda akan menggunakan cluster config-central untuk menghosting konfigurasi untuk resource Gateway.

Konfirmasi bahwa semua cluster telah berhasil mendaftar ke fleet:

gcloud container fleet memberships list --project=$PROJECT

Contoh output berikut menunjukkan bahwa semua cluster berhasil didaftarkan:

NAME: auto-central
EXTERNAL_ID: 21537493-32ea-4a41-990d-02be2c1b319f

NAME: config-central
EXTERNAL_ID: 4369423e-ea7b-482d-a0eb-93b560e67b98

NAME: std-west
EXTERNAL_ID: 7fcb048b-c796-476b-9698-001a00f91ab3

NAME: auto-east
EXTERNAL_ID: aae2d2ff-b861-4a38-bcaf-612f14810012

Instal definisi resource kustom Gateway API di cluster config-central:
```
kubectl --context=config-central kustomize "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v0.5.0" \
    | kubectl apply -f -
```
Langkah ini akan menginstal definisi resource kustom Gateway API, termasuk resource GatewayClass, Gateway, dan HTTPRoute. Definisi resource kustom dikelola oleh Network Special Interest Group Kubernetes. Setelah diinstal, Anda dapat menggunakan GKE Gateway Controller.

Aktifkan Multi Cluster Ingress untuk fleet jika Anda belum melakukannya. Jika fitur ini diaktifkan, pengontrol Gateway multi-cluster juga akan aktif.

gcloud container fleet ingress enable \
    --config-membership=config-central \
    --project=$PROJECT

gcloud container fleet ingress describe --project=$PROJECT

Outputnya mirip dengan contoh berikut:

createTime: '2021-12-08T23:10:52.505888854Z'
name: projects/PROJECT_ID/locations/global/features/multiclusteringress
resourceState:
  state: ACTIVE
spec:
  multiclusteringress:
    configMembership: projects/zl-mcs-expf61cbd13/locations/global/memberships/config-central
state:
  state:
    code: OK
    description: Ready to use
    updateTime: '2021-12-08T23:11:37.994971649Z'
updateTime: '2021-12-08T23:11:38.098244178Z'

Jika nilai status tidak ACTIVE, lihat Pemecahan masalah dan operasi untuk Multi Cluster Ingress.

Pastikan GatewayClasses tersedia di cluster config-central:

kubectl get gatewayclasses --context=config-central

Outputnya mirip dengan contoh berikut:

NAME                                  CONTROLLER                  AGE
gke-l7-global-external-managed        networking.gke.io/gateway   18s
gke-l7-global-external-managed-mc     networking.gke.io/gateway   19s
gke-l7-regional-external-managed      networking.gke.io/gateway   18s
gke-l7-regional-external-managed-mc   networking.gke.io/gateway   19s
gke-l7-gxlb                           networking.gke.io/gateway   74s
gke-l7-gxlb-mc                        networking.gke.io/gateway   16s
gke-l7-rilb                           networking.gke.io/gateway   74s
gke-l7-rilb-mc                        networking.gke.io/gateway   16s

Resource GatewayClass yang berbeda memiliki kemampuan yang berbeda. Untuk mengetahui informasi selengkapnya tentang kapan harus menggunakan jenis yang mana, lihat Kemampuan GatewayClass.

Deploy resource Gateway external-http ke config-central:

cat <<EOF>> $WORKDIR/external-http-gateway.yaml
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: external-http
  namespace: onlineboutique
spec:
  gatewayClassName: gke-l7-global-external-managed-mc
  listeners:
  - protocol: HTTP
    port: 80
    name: http
EOF

kubectl apply -f external-http-gateway.yaml \
    -n onlineboutique --context=config-central

Seperti yang ditunjukkan oleh kolom gatewayClassName, resource ini adalah dari GatewayClass gke-l7-global-external-managed-mc yang mengelola Cloud Load Balancing eksternal Layer 7 dan mengekspos aplikasi multi-cluster

Deploy HTTPRoute bernama public-frontend-route di config-central:
```
cat <<EOF>> $WORKDIR/public-frontend-route.yaml
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
 name: public-frontend-route
 namespace: onlineboutique
spec:
 parentRefs:
 - name: "external-http"
 hostnames:
 - "store.example.com"
 rules:
 - matches:
 - path:
 type: PathPrefix
 value: /
 backendRefs:
 - name: frontend
 group: net.gke.io
 kind: ServiceImport
 port: 80
EOF

kubectl apply -f public-frontend-route.yaml \
 -n onlineboutique --context=config-central
```
Saat Anda men-deploy resource HTTPRoute, resource tersebut membuat resource Cloud Load Balancing Layer 7 eksternal dan mengekspos ServiceImport frontend yang didukung oleh layanan frontend yang berjalan di cluster std-west, auto-east, dan auto-central.

Catatan: Atau, Anda dapat mengganti store.example.com di manifes ini dengan nama host dari domain yang Anda atau tim Anda miliki, dan mengarahkan masing-masing Data DNS ke alamat IP eksternal dari load balancer yang dibuat pada langkah ini. Permintaan yang ditujukan untuk nama host tersebut akan diarahkan ke load balancer ini.

Diagram berikut menunjukkan cara, setelah Gateway multi-cluster di-deploy, traffic dapat dirutekan ke salah satu Service multi-cluster frontend pada salah satu dari tiga cluster aplikasi:
Tunggu load balancer siap dengan alamat IP eksternal yang disediakan sebelum melanjutkan ke langkah berikutnya. Diperlukan waktu hingga 10 menit untuk menetapkan alamat IP. Anda dapat memantau progres menggunakan loop smartwatch. Load balancer tersebut memiliki nama dalam pola seperti gkemcg-onlineboutique-external-http-k09mfhk74gop:
```
watch -n 20 --difference=permanent \
    "gcloud compute forwarding-rules list \
        | grep -A 5 NAME..*external-http"
```
Outputnya mirip dengan contoh berikut:
```
NAME: gkemcg-onlineboutique-external-http-k09mfhk74gop
REGION:
IP_ADDRESS: 34.149.29.176
IP_PROTOCOL: TCP
TARGET: gkemcg-onlineboutique-external-http-k09mfhk74gop
```

Setelah load balancer siap, jalankan perintah berikut di Cloud Shell untuk mengekspor alamat IP eksternal load balancer yang dibuat melalui penerapan external-http-gateway.yaml dan manifes public-frontend-route.yaml:

export EXTERNAL_LB_IP=$(kubectl --context=config-central \
                            -n onlineboutique get gateway external-http \
                            -o=jsonpath='{.status.addresses[0].value}')

Saat Anda mengirim permintaan ke load balancer dengan header yang sesuai, permintaan tersebut akan menampilkan konten HTML yang disajikan oleh layanan frontend. Misalnya, karena Anda mengonfigurasi resource HTTPRoute untuk memetakan nama host store.example.com ke ServiceImport frontend, Anda harus menyediakan header HOST saat Anda membuat permintaan HTTP. Jika contoh curl berikut menampilkan error, tunggu beberapa menit dan coba lagi:
```
curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
 grep -e Cluster -e Zone -e Pod
```
Output perintah curl yang berhasil mirip dengan contoh berikut:
```
Cluster: auto-central 
Zone: us-central1-f 
Pod: frontend-7c7d596ddc-jdh8f
```
Catatan: Jika header yang cocok, seperti yang dikonfigurasi di HTTPRoute, tidak disediakan saat Anda membuat permintaan, klien akan menerima error HTTP status 404. Salah satu dari tiga pod frontend yang berjalan di jalur penayangan dapat merespons permintaan HTTP yang masuk ke load balancer global. Load balancer global dapat merutekan permintaan ke backend responsif yang berada paling dekat dengan tempat asal permintaan.

Menguji perilaku pemilihan rute multi-region aplikasi

Salah satu fitur canggih yang diperoleh dari penggunaan Service multi-cluster dan Gateway multi-cluster adalah permintaan eksternal dirutekan ke cluster yang paling dekat secara geografis.

Untuk menguji perilaku multi-region aplikasi, buat traffic yang berasal dari berbagai region tempat Anda men-deploy cluster. Buat tiga pod kecil, satu di setiap cluster penayangan (std-west, auto-east, dan auto-central), yang dapat Anda gunakan untuk mengirim permintaan HTTP ke endpoint load balancer. Hasilnya memungkinkan Anda melihat Pod frontend mana yang merespons.

Buat pod klien:

kubectl run --context=std-west \
            --image=radial/busyboxplus:curl client-west \
            -- sh -c 'while sleep 3600; do :; done'

kubectl run --context=auto-east \
            --image=radial/busyboxplus:curl client-east \
            -- sh -c 'while sleep 3600; do :; done'

kubectl run --context=auto-central \
            --image=radial/busyboxplus:curl client-central \
            -- sh -c 'while sleep 3600; do :; done'

Setelah pod berjalan, gunakan perintah curl untuk mengirim permintaan ke endpoint load balancer dari Pod klien di cluster std-west dan tinjau responsnya:

kubectl exec -it --context=std-west client-west \
    -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
           grep -e Cluster -e Zone -e Pod

Output perintah curl yang berhasil mirip dengan contoh berikut:

<b>Cluster: </b>std-west<br/>
<b>Zone: </b>us-west1-a<br/>
<b>Pod: </b>frontend-7cf48b79cf-trzc4

Jalankan permintaan curl yang sama dari Pod klien di cluster auto-east, dan lihat responsnya:

kubectl exec -it --context=auto-east client-east \
    -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
           grep -e Cluster -e Zone -e Pod

Output perintah curl yang berhasil mirip dengan contoh berikut:

<b>Cluster: </b>auto-east<br/>
<b>Zone: </b>us-east1-d<br/>
<b>Pod: </b>frontend-6784b6df98-scdws

Karena ini adalah cluster Autopilot, cluster mungkin perlu menyediakan resource tambahan untuk menjadwalkan Pod. Jika Anda melihat output yang mirip dengan contoh berikut, tunggu sebentar dan coba lagi:

 Error from server (BadRequest): pod client-east does not have a host assigned

Jalankan curl dari Pod klien di cluster auto-central dan periksa responsnya:

kubectl exec -it --context=auto-central client-central \
    -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
        grep -e Cluster -e Zone -e Pod

Output perintah curl yang berhasil mirip dengan contoh berikut:

<b>Cluster: </b>auto-central<br/>
<b>Zone: </b>us-central1-b<br/>
<b>Pod: </b>frontend-6784b6df98-x2fv4

Hasil ini mengonfirmasi bahwa traffic dirutekan ke pod yang sesuai di lokasi yang paling dekat dengan asal permintaan.

Menguji ketahanan multi-region aplikasi

Selain pemilihan rute traffic yang efisien, menjalankan layanan Anda di beberapa region akan memberikan ketahanan dalam kasus kegagalan infrastruktur yang jarang terjadi, tetapi masih memungkinkan.

Uji perilaku dengan menghapus Deployments frontend di cluster tertentu, lalu coba lagi perintah curl dari Pod klien di region tersebut. Perhatikan bahwa aplikasi masih tersedia, dan lihat lokasi Pod yang merespons permintaan.

Jalankan perintah curl dari Pod client-west di cluster std-west, dan lihat bahwa hasilnya berasal dari frontend di us-west1:

kubectl exec -it --context=std-west client-west \
    -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP  | \
           grep -e Cluster -e Zone -e Pod

Output perintah curl yang berhasil mirip dengan contoh berikut:

<b>Cluster: </b>std-west<br/>
<b>Zone: </b>us-west1-a<br/>
<b>Pod: </b>frontend-7cf48b79cf-trzc4

Hapus Deployment frontend di cluster std-west:

kubectl delete deploy frontend \
    -n onlineboutique --context=std-west

Outputnya mirip dengan contoh berikut:

deployment.apps "frontend" deleted

Kirim permintaan lain dari Pod client-west di cluster std-west. Anda akan melihat respons dari salah satu Deployments frontend lainnya yang terletak di cluster auto-east atau auto-central:

kubectl exec -it --context=std-west client-west \
    -- curl -H 'HOST: store.example.com' $EXTERNAL_LB_IP | \
           grep -e Cluster -e Zone -e Pod

Output yang mirip dengan contoh berikut menunjukkan lokasi Pod responsif yang merespons permintaan ini:

<b>Cluster: </b>auto-central<br/>
<b>Zone: </b>us-central1-b<br/>
<b>Pod: </b>frontend-6784b6df98-x2fv4

atau

<b>Cluster: </b>auto-east<br/>
<b>Zone: </b>us-east1-d<br/>
<b>Pod: </b>frontend-6784b6df98-scdws

Jalankan perintah beberapa kali untuk melihat hasil yang berbeda-beda.

Dengan deployment demonstrasi ini, Anda telah menambahkan elemen distribusi ketahanan dan geografis ke aplikasi Online Boutique menggunakan Service multi-cluster dan Gateway multi-cluster. Permintaan dirutekan ke region geografis terdekat, dan meskipun layanan frontend atau middleware di suatu region mengalami masalah, pengguna akhir masih dapat menggunakan aplikasi tersebut.

Pembersihan

Agar tidak perlu membayar biaya pada akun Google Cloud Anda untuk resource yang digunakan dalam tutorial ini, hapus project yang berisi resource tersebut, atau simpan project dan hapus setiap resource.

Perhatian: Menghapus project memiliki efek berikut:

Semua hal dalam project akan dihapus. Jika menggunakan project yang sudah ada untuk tugas dalam dokumen ini, saat Anda menghapusnya, pekerjaan lain yang telah Anda lakukan dalam project tersebut juga akan terhapus.
Project ID kustom hilang. Saat membuat project ini, Anda mungkin telah membuat project ID kustom yang ingin digunakan di masa mendatang. Untuk mempertahankan URL yang menggunakan project ID, seperti URL appspot.com, hapus resource yang dipilih di dalam project, bukan menghapus seluruh project.

Jika Anda berencana mempelajari beberapa arsitektur, tutorial atau panduan memulai, dengan menggunakan kembali project dapat membantu Anda agar tidak melampaui batas kuota project.

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Langkah berikutnya

Baca selengkapnya tentang Pengelolaan fleet dan multi-cluster Google Cloud.
Pelajari cara mendaftarkan cluster, termasuk cluster GKE Enterprise, ke fleet Google Cloud.
Pelajari lebih dalam Kubernetes Gateway API dan GKE Gateway.
Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.