Anda sedang melihat dokumentasi Service Mesh v1.20 lama.

Versi yang tersedia

Cloud Service Mesh
Arsip 1.20
arsip 1.19
Arsip 1.18

Halaman ini diterjemahkan oleh Cloud Translation API.

Menjalankan layanan terdistribusi pada cluster pribadi GKE menggunakan Cloud Service Mesh

Dokumen ini menunjukkan cara menjalankan layanan terdistribusi pada beberapa Cluster Google Kubernetes Engine (GKE) di Google Cloud menggunakan Cloud Service Mesh. Dokumen ini juga menunjukkan cara mengekspos layanan terdistribusi menggunakan Multi Cluster Ingress dan Cloud Service Mesh. Anda dapat menggunakan dokumen ini untuk mengonfigurasi cluster GKE non-pribadi; dokumen menyoroti konfigurasi yang khusus ditujukan khusus untuk cluster pribadi.

Dokumen ini ditujukan untuk administrator platform dan operator layanan yang telah pengetahuan dasar tentang Kubernetes. Pengetahuan tentang mesh layanan sangat bermanfaat, meskipun tidak wajib. Cloud Service Mesh didasarkan pada Istio open source teknologi baru. Untuk mengetahui informasi selengkapnya tentang mesh layanan dan Istio, lihat istio.io.

Layanan terdistribusi adalah Service Kubernetes yang bertindak sebagai satu sistem logis layanan. Layanan terdistribusi lebih tangguh daripada layanan Kubernetes karena keduanya berjalan di beberapa cluster Kubernetes dalam namespace yang sama. J layanan terdistribusi tetap aktif bahkan jika satu atau beberapa tidak aktif, selama klaster yang sehat itu mampu melayani kriteria yang diinginkan memuat halaman.

Layanan Kubernetes hanya diketahui oleh server Kubernetes API cluster tempatnya berjalan. Jika cluster Kubernetes tidak aktif (misalnya selama periode pemeliharaan), semua Layanan Kubernetes yang berjalan pada cluster tersebut juga akan dihentikan. Menjalankan layanan terdistribusi mempermudah pengelolaan siklus proses cluster karena Anda dapat menurunkan cluster untuk pemeliharaan atau upgrade saat cluster lain traffic layanan. Untuk membuat layanan terdistribusi, mesh layanan fungsi yang disediakan oleh Cloud Service Mesh digunakan untuk menautkan layanan yang berjalan pada beberapa cluster secara bersamaan untuk bertindak sebagai satu layanan logis.

Cluster pribadi GKE memungkinkan Anda mengonfigurasi node dan API server sebagai resource pribadi yang hanya tersedia di Virtual Private Cloud (VPC) jaringan. Menjalankan layanan terdistribusi di GKE pribadi {i>cluster <i}memberi perusahaan layanan yang aman dan andal.

Arsitektur

Tutorial ini menggunakan arsitektur yang ditampilkan dalam diagram berikut:

Arsitektur layanan terdistribusi di cluster pribadi GKE menggunakan Cloud Service Mesh

Dalam diagram sebelumnya, arsitektur mencakup cluster berikut:

Dua cluster (gke-central-priv dan gke-west-priv) bertindak identik Cluster pribadi GKE di dua region berbeda.
Cluster terpisah (ingress-config) bertindak sebagai cluster bidang kontrol yang mengonfigurasi Multi Cluster Ingress.

Dalam tutorial ini, Anda men-deploy Bank of Anthos contoh aplikasi pada dua cluster pribadi GKE (gke-central-priv dan gke-west-priv). Bank of Anthos adalah contoh aplikasi microservice yang terdiri dari beberapa microservice dan SQL {i>database<i} yang menyimulasikan aplikasi perbankan {i>online<i}. Aplikasi ini terdiri atas web yang dapat diakses klien, dan beberapa layanan backend seperti keseimbangan, buku besar, dan layanan rekening yang menyimulasikan sebuah bank.

Aplikasi ini berisi dua database PostgreSQL yang terinstal di Kubernetes sebagai StatefulSets. Satu {i>database<i} digunakan untuk transaksi, sedangkan {i>database<i} lain digunakan untuk akun pengguna. Semua layanan kecuali dua database dijalankan sebagai layanan terdistribusi. Artinya, Pod untuk semua service dapat berjalan di cluster aplikasi (dalam namespace yang sama), dan Cloud Service Mesh adalah dikonfigurasi sehingga setiap layanan muncul sebagai satu layanan logis.

Tujuan

Membuat tiga cluster GKE.
Mengonfigurasi dua cluster GKE sebagai pribadi cluster (gke-central-priv dan gke-west-priv).
Konfigurasikan satu cluster GKE (ingress-config) sebagai cluster konfigurasi pusat. Cluster ini berfungsi sebagai cluster konfigurasi untuk Ingress Multi-Cluster.
Mengonfigurasi jaringan (Gateway NAT, Cloud Router, dan aturan firewall) untuk mengizinkan traffic antar-cluster dan keluar dari dua pribadi Cluster GKE.
Konfigurasikan jaringan yang diizinkan untuk mengizinkan akses layanan API dari Cloud Shell ke dua cluster GKE pribadi.
Men-deploy dan mengonfigurasi Cloud Service Mesh multi-cluster ke keduanya cluster pribadi dalam mode multi-utama. Mode multi-utama men-deploy Bidang kontrol Cloud Service Mesh di kedua cluster.
Deploy aplikasi Bank of Anthos di dua platform pribadi klaster. Semua layanan kecuali database di-deploy secara terdistribusi (Pod yang berjalan di kedua cluster pribadi).
Memantau layanan menggunakan Cloud Service Mesh.
Mengonfigurasi Multi Cluster Ingress di Bank of Anthos frontend layanan. Hal ini memungkinkan klien eksternal (misalnya, web Anda browser) untuk mengakses layanan terdistribusi yang berjalan di sekumpulan server Cluster GKE.

Biaya

Dalam dokumen ini, Anda 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

Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.

Catatan: Jika tidak berencana untuk menyimpan resource yang Anda buat dalam prosedur ini, buatlah project, bukan memilih project yang ada. Setelah menyelesaikan langkah ini, Anda dapat menghapus project, yang menghapus semua resource yang terkait dengan project ini.

Buka pemilih project
Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.
Di konsol Google Cloud, aktifkan Cloud Shell.

Aktifkan Cloud Shell

Di bagian bawah Google Cloud Console, Cloud Shell sesi akan terbuka dan menampilkan perintah command line. Cloud Shell adalah lingkungan shell dengan Google Cloud CLI yang sudah terinstal, dan dengan nilai yang sudah ditetapkan untuk project Anda saat ini. Diperlukan waktu beberapa detik untuk melakukan inisialisasi sesi.

Anda akan menjalankan semua perintah dalam tutorial ini dari Cloud Shell.

Menentukan variabel lingkungan yang digunakan di seluruh tutorial ini. Variabel menentukan nama cluster, region, zona, penentuan alamat IP, dan Versi Cloud Service Mesh yang digunakan dalam tutorial ini.

Ganti YOUR_PROJECT_ID dengan project ID Anda:

export PROJECT_ID=YOUR_PROJECT_ID
gcloud config set project ${PROJECT_ID}

Setel variabel lingkungan yang tersisa:

export CLUSTER_1=gke-west-priv
export CLUSTER_2=gke-central-priv
export CLUSTER_1_ZONE=us-west2-a
export CLUSTER_1_REGION=us-west2
export CLUSTER_1_MASTER_IPV4_CIDR=172.16.0.0/28
export CLUSTER_2_ZONE=us-central1-a
export CLUSTER_2_REGION=us-central1
export CLUSTER_2_MASTER_IPV4_CIDR=172.16.1.0/28
export CLUSTER_INGRESS=gke-ingress
export CLUSTER_INGRESS_ZONE=us-west1-a
export CLUSTER_INGRESS_REGION=us-west1
export CLUSTER_INGRESS_MASTER_IPV4_CIDR=172.16.2.0/28
export WORKLOAD_POOL=${PROJECT_ID}.svc.id.goog
export ASM_VERSION=1.10
export CLOUDSHELL_IP=$(dig +short myip.opendns.com @resolver1.opendns.com)

Menyiapkan lingkungan Anda

Di Cloud Shell, aktifkan API:

gcloud services enable \
  --project=${PROJECT_ID} \
  container.googleapis.com \
  mesh.googleapis.com \
  gkehub.googleapis.com

Aktifkan Armada Mesh Layanan Cloud untuk project Anda:

gcloud container fleet mesh enable --project=${PROJECT_ID}

Menyiapkan jaringan untuk cluster GKE pribadi

Di bagian ini, Anda menyiapkan jaringan untuk {i>cloud<i} Cluster GKE yang Anda gunakan untuk menjalankan layanan terdistribusi.

Node cluster GKE pribadi tidak diberi IP publik alamat IPv6 Semua node dalam cluster GKE pribadi akan diberi alamat IP VPC pribadi (di ruang alamat RFC 1918). Artinya, Pod yang perlu mengakses resource eksternal (di luar jaringan VPC) memerlukan Gateway Cloud NAT. Gateway Cloud NAT adalah gateway NAT regional yang memungkinkan Pod dengan IP internal untuk berkomunikasi ke internet. Dalam tutorial ini, Anda mengonfigurasi gateway Cloud NAT di masing-masing dari dua region. Beberapa cluster dalam satu region dapat menggunakan gateway NAT yang sama.

Di Cloud Shell, buat dan cadangkan dua alamat IP eksternal untuk dua gateway NAT:

gcloud compute addresses create ${CLUSTER_1_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_1_REGION}

gcloud compute addresses create ${CLUSTER_2_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_2_REGION}

Simpan alamat IP dan nama alamat IP dalam variabel:

export NAT_REGION_1_IP_ADDR=$(gcloud compute addresses describe ${CLUSTER_1_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_1_REGION} \
  --format='value(address)')

export NAT_REGION_1_IP_NAME=$(gcloud compute addresses describe ${CLUSTER_1_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_1_REGION} \
  --format='value(name)')

export NAT_REGION_2_IP_ADDR=$(gcloud compute addresses describe ${CLUSTER_2_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_2_REGION} \
  --format='value(address)')

export NAT_REGION_2_IP_NAME=$(gcloud compute addresses describe ${CLUSTER_2_REGION}-nat-ip \
  --project=${PROJECT_ID} \
  --region=${CLUSTER_2_REGION} \
  --format='value(name)')

Membuat gateway Cloud NAT di dua region gateway Cluster GKE:

gcloud compute routers create rtr-${CLUSTER_1_REGION} \
  --network=default \
  --region ${CLUSTER_1_REGION}

gcloud compute routers nats create nat-gw-${CLUSTER_1_REGION} \
  --router=rtr-${CLUSTER_1_REGION} \
  --region ${CLUSTER_1_REGION} \
  --nat-external-ip-pool=${NAT_REGION_1_IP_NAME} \
  --nat-all-subnet-ip-ranges \
  --enable-logging

gcloud compute routers create rtr-${CLUSTER_2_REGION} \
  --network=default \
  --region ${CLUSTER_2_REGION}

gcloud compute routers nats create nat-gw-${CLUSTER_2_REGION} \
  --router=rtr-${CLUSTER_2_REGION} \
  --region ${CLUSTER_2_REGION} \
  --nat-external-ip-pool=${NAT_REGION_2_IP_NAME} \
  --nat-all-subnet-ip-ranges \
  --enable-logging

Membuat aturan firewall yang mengizinkan komunikasi Pod-ke-Pod dan Pod-ke-API komunikasi server. Komunikasi Pod-ke-Pod memungkinkan layanan berkomunikasi satu sama lain di GKE klaster. Komunikasi server Pod-ke-API memungkinkan Cloud Service Mesh cluster GKE kueri bidang kontrol untuk penemuan layanan.

gcloud compute firewall-rules create all-pods-and-master-ipv4-cidrs \
  --project ${PROJECT_ID} \
  --network default \
  --allow all \
  --direction INGRESS \
  --source-ranges 10.0.0.0/8,${CLUSTER_1_MASTER_IPV4_CIDR},${CLUSTER_2_MASTER_IPV4_CIDR},${CLUSTER_INGRESS_MASTER_IPV4_CIDR}

Sekarang jaringan sudah siap. Dalam tutorial ini, Anda menggunakan seluruh Rentang alamat IP 10.0.0.0/8, yang mencakup semua rentang Pod. Sebaiknya Anda membuat aturan {i>firewall<i} yang lebih ketat dalam produksi, berdasarkan pada kondisi dan lainnya.

Membuat cluster GKE pribadi

Di bagian ini, Anda akan membuat dua cluster GKE pribadi tempat aplikasi contoh di-deploy. Di tutorial ini, setelan Node cluster GKE memiliki alamat IP pribadi, dan API memiliki endpoint publik. Namun, akses ke server API dibatasi menggunakan jaringan yang diizinkan.

Di Cloud Shell, buat dua cluster pribadi yang telah mengizinkan jaringan. Mengonfigurasi cluster untuk mengizinkan akses dari rentang CIDR IP Pod (untuk bidang kontrol Mesh Layanan Cloud) dan dari Cloud Shell sehingga Anda dapat mengakses cluster dari terminal Anda.

gcloud container clusters create ${CLUSTER_1} \
  --project ${PROJECT_ID} \
  --zone=${CLUSTER_1_ZONE} \
  --machine-type "e2-standard-4" \
  --num-nodes "3" --min-nodes "3" --max-nodes "5" \
  --enable-ip-alias --enable-autoscaling \
  --workload-pool=${WORKLOAD_POOL} \
  --enable-private-nodes \
  --master-ipv4-cidr=${CLUSTER_1_MASTER_IPV4_CIDR} \
  --enable-master-authorized-networks \
  --master-authorized-networks $NAT_REGION_1_IP_ADDR/32,$NAT_REGION_2_IP_ADDR/32,$CLOUDSHELL_IP/32

gcloud container clusters create ${CLUSTER_2} \
  --project ${PROJECT_ID} \
  --zone=${CLUSTER_2_ZONE} \
  --machine-type "e2-standard-4" \
  --num-nodes "3" --min-nodes "3" --max-nodes "5" \
  --enable-ip-alias --enable-autoscaling \
  --workload-pool=${WORKLOAD_POOL} \
  --enable-private-nodes \
  --master-ipv4-cidr=${CLUSTER_2_MASTER_IPV4_CIDR} \
  --enable-master-authorized-networks \
  --master-authorized-networks $NAT_REGION_1_IP_ADDR/32,$NAT_REGION_2_IP_ADDR/32,$CLOUDSHELL_IP/32

Jaringan yang diotorisasi berisi alamat IP publik di laman gateway Cloud NAT. Karena endpoint server API untuk adalah endpoint publik. Pod yang berjalan di cluster pribadi harus menggunakan Gateway Cloud NAT untuk mengakses endpoint server API publik.

Alamat IP Cloud Shell juga merupakan bagian dari yang memungkinkan Anda mengakses dan mengelola cluster dari di terminal Cloud Shell. IP Cloud Shell yang dapat diakses publik ini bersifat dinamis. Jadi, setiap kali memulai Cloud Shell, Anda mungkin mendapatkan alamat IP publik yang berbeda. Saat Anda mendapatkan alamat IP baru, Anda kehilangan akses ke cluster karena alamat IP baru bukan bagian dari jaringan resmi untuk kedua cluster tersebut.

Jika Anda kehilangan akses ke cluster, update cluster diotorisasi jaringan agar menyertakan alamat IP Cloud Shell baru:

Dapatkan alamat IP publik Cloud Shell yang diperbarui:

export CLOUDSHELL_IP=$(dig +short myip.opendns.com @resolver1.opendns.com)

Update jaringan yang diizinkan untuk kedua cluster:

gcloud container clusters update ${CLUSTER_1} \
  --zone=${CLUSTER_1_ZONE} \
  --enable-master-authorized-networks \
  --master-authorized-networks $NAT_REGION_1_IP_ADDR/32,$NAT_REGION_2_IP_ADDR/32,$CLOUDSHELL_IP/32

gcloud container clusters update ${CLUSTER_2} \
  --zone=${CLUSTER_2_ZONE} \
  --enable-master-authorized-networks \
  --master-authorized-networks $NAT_REGION_1_IP_ADDR/32,$NAT_REGION_2_IP_ADDR/32,$CLOUDSHELL_IP/32

Pastikan semua cluster berjalan:

gcloud container clusters list

Outputnya akan terlihat seperti berikut:

NAME              LOCATION       MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
gke-central-priv  us-central1-a  1.16.15-gke.6000  35.238.99.104  e2-standard-4  1.16.15-gke.6000  3          RUNNING
gke-west-priv     us-west2-a     1.16.15-gke.6000  34.94.188.180  e2-standard-4  1.16.15-gke.6000  3          RUNNING

Hubungkan ke kedua cluster untuk membuat entri di file kubeconfig:
```
touch ~/asm-kubeconfig && export KUBECONFIG=~/asm-kubeconfig
gcloud container clusters get-credentials ${CLUSTER_1} --zone ${CLUSTER_1_ZONE}
gcloud container clusters get-credentials ${CLUSTER_2} --zone ${CLUSTER_2_ZONE}
```
Anda menggunakan file {i>kubeconfig<i} untuk mengotentikasi ke cluster dengan membuat pengguna dan konteks untuk setiap cluster. Setelah Anda membuat entri di kubeconfig, Anda dapat dengan cepat beralih konteks antar-cluster.

Ganti nama konteks cluster agar lebih praktis:

kubectl config rename-context \
gke_${PROJECT_ID}_${CLUSTER_1_ZONE}_${CLUSTER_1} ${CLUSTER_1}

kubectl config rename-context \
gke_${PROJECT_ID}_${CLUSTER_2_ZONE}_${CLUSTER_2} ${CLUSTER_2}

Pastikan kedua konteks cluster telah diganti namanya dan dikonfigurasi dengan benar:
```
kubectl config get-contexts --output="name"
```
Outputnya akan terlihat seperti berikut:
```
gke-central-priv
gke-west-priv
```

Daftarkan cluster Anda ke fleet:

gcloud container fleet memberships register ${CLUSTER_1} --gke-cluster=${CLUSTER_1_ZONE}/${CLUSTER_1} --enable-workload-identity
gcloud container fleet memberships register ${CLUSTER_2} --gke-cluster=${CLUSTER_2_ZONE}/${CLUSTER_2} --enable-workload-identity

Anda kini telah membuat dan mengganti nama GKE pribadi klaster.

Menginstal Cloud Service Mesh

Di bagian ini, Anda akan menginstal Cloud Service Mesh pada kedua Cluster GKE dan konfigurasi cluster tersebut untuk lintas cluster penemuan layanan.

Di Cloud Shell, instal Cloud Service Mesh di kedua cluster menggunakan fleet API:
```
gcloud container fleet mesh update --management automatic --memberships ${CLUSTER_1},${CLUSTER_2}
```
Catatan: Proses ini akan selesai dalam waktu 10 menit.
Setelah Cloud Service Mesh terkelola diaktifkan pada cluster, setel pemantauan mesh yang akan diinstal:
```
watch -g "gcloud container fleet mesh describe | grep 'code: REVISION_READY'"
```

Menginstal gateway masuk Cloud Service Mesh untuk kedua klaster:

kubectl --context=${CLUSTER_1} create namespace asm-ingress
kubectl --context=${CLUSTER_1} label namespace asm-ingress istio-injection=enabled --overwrite
kubectl --context=${CLUSTER_2} create namespace asm-ingress
kubectl --context=${CLUSTER_2} label namespace asm-ingress istio-injection=enabled --overwrite

cat <<'EOF' > asm-ingress.yaml
apiVersion: v1
kind: Service
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  type: LoadBalancer
  selector:
    asm: ingressgateway
  ports:
  - port: 80
    name: http
  - port: 443
    name: https
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  selector:
    matchLabels:
      asm: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        asm: ingressgateway
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: asm-ingressgateway-sds
  namespace: asm-ingress
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: asm-ingressgateway-sds
  namespace: asm-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: asm-ingressgateway-sds
subjects:
- kind: ServiceAccount
  name: default
EOF

kubectl --context=${CLUSTER_1} apply -f asm-ingress.yaml
kubectl --context=${CLUSTER_2} apply -f asm-ingress.yaml

Memastikan gateway masuk Cloud Service Mesh telah di-deploy:
```
kubectl --context=${CLUSTER_1} get pod,service -n asm-ingress
kubectl --context=${CLUSTER_2} get pod,service -n asm-ingress
```
Output untuk kedua cluster akan terlihat seperti berikut:
```
NAME                                        READY   STATUS    RESTARTS   AGE
pod/asm-ingressgateway-5894744dbd-zxlgc   1/1     Running   0          84s

NAME                           TYPE           CLUSTER-IP    EXTERNAL-IP      PORT(S)                      AGE
service/asm-ingressgateway   LoadBalancer   10.16.2.131   34.102.100.138   80:30432/TCP,443:30537/TCP   92s
```
Setelah bidang kontrol Mesh Layanan Cloud dan gateway masuk diinstal untuk kedua cluster, penemuan layanan lintas cluster diaktifkan dengan fleet API. Layanan lintas cluster Discovery memungkinkan kedua cluster menemukan endpoint layanan dari remote . Layanan terdistribusi berjalan pada banyak klaster dalam namespace yang sama.

Untuk kedua bidang kontrol Cloud Service Mesh guna menemukan semua endpoint layanan terdistribusi, Cloud Service Mesh harus memiliki akses ke semua cluster yang menjalankan layanan terdistribusi. Contoh ini menggunakan dua klaster, sehingga kedua cluster harus dapat membuat kueri cluster jarak jauh untuk mendapatkan layanan endpoint. Dengan Cloud Service Mesh terkelola yang diaktifkan dengan fleet API, penemuan endpoint akan dikonfigurasi secara otomatis.

Cluster dan Cloud Service Mesh kini telah dikonfigurasi.

Men-deploy aplikasi Bank of Anthos

Di Cloud Shell, clone repositori GitHub Bank of Anthos:

git clone https://github.com/GoogleCloudPlatform/bank-of-anthos.git ${HOME}/bank-of-anthos

Buat dan beri label namespace bank-of-anthos di kedua cluster. Tujuan label memungkinkan injeksi otomatis proxy Envoy file bantuan di setiap Pod dalam namespace berlabel.

# cluster_1
kubectl create --context=${CLUSTER_1} namespace bank-of-anthos
kubectl label --context=${CLUSTER_1} namespace bank-of-anthos istio-injection=enabled

# cluster_2
kubectl create --context=${CLUSTER_2} namespace bank-of-anthos
kubectl label --context=${CLUSTER_2} namespace bank-of-anthos istio-injection=enabled

Deploy aplikasi Bank of Anthos ke kedua cluster di Namespace bank-of-anthos.

# The following secret is used for user account creation and authentication
kubectl --context=$CLUSTER_1 -n bank-of-anthos apply -f ${HOME}/bank-of-anthos/extras/jwt/jwt-secret.yaml
kubectl --context=$CLUSTER_2 -n bank-of-anthos apply -f ${HOME}/bank-of-anthos/extras/jwt/jwt-secret.yaml

# Deploy all manifests to both clusters
kubectl --context=$CLUSTER_1 -n bank-of-anthos apply -f ${HOME}/bank-of-anthos/kubernetes-manifests
kubectl --context=$CLUSTER_2 -n bank-of-anthos apply -f ${HOME}/bank-of-anthos/kubernetes-manifests

Service Kubernetes harus berada di kedua cluster untuk tiap layanan penemuan. Ketika layanan di salah satu cluster mencoba membuat permintaan, komputer melakukan pencarian DNS untuk nama {i>host <i}untuk mendapatkan alamat IP. Di beberapa GKE, server kube-dns yang berjalan di cluster menangani pencarian ini, sehingga definisi Layanan yang dikonfigurasi diperlukan.

Hapus StatefulSets dari satu cluster sehingga kedua PostgreSQL tersebut {i>database<i} hanya ada di salah satu klaster tersebut:

# Delete the two DB statefulSets from Cluster2
kubectl --context=$CLUSTER_2 -n bank-of-anthos delete statefulset accounts-db
kubectl --context=$CLUSTER_2 -n bank-of-anthos delete statefulset ledger-db

Pastikan semua Pod berjalan di kedua cluster:

Dapatkan Pod dari cluster_1:

kubectl --context=${CLUSTER_1} -n bank-of-anthos get pod

Outputnya akan terlihat seperti berikut:

NAME                                  READY   STATUS    RESTARTS   AGE
accounts-db-0                         2/2     Running   0          9m54s
balancereader-c5d664b4c-xmkrr         2/2     Running   0          9m54s
contacts-7fd8c5fb6-wg9xn              2/2     Running   1          9m53s
frontend-7b7fb9b665-m7cw7             2/2     Running   1          9m53s
ledger-db-0                           2/2     Running   0          9m53s
ledgerwriter-7b5b6db66f-xhbp4         2/2     Running   0          9m53s
loadgenerator-7fb54d57f8-g5lz5        2/2     Running   0          9m52s
transactionhistory-7fdb998c5f-vqh5w   2/2     Running   1          9m52s
userservice-76996974f5-4wlpf          2/2     Running   1          9m52s

Dapatkan Pod dari cluster_2:

kubectl --context=${CLUSTER_2} -n bank-of-anthos get pod

Outputnya akan terlihat seperti berikut:

NAME                                  READY   STATUS    RESTARTS   AGE
balancereader-c5d664b4c-bn2pl         2/2     Running   0          9m54s
contacts-7fd8c5fb6-kv8cp              2/2     Running   0          9m53s
frontend-7b7fb9b665-bdpp4             2/2     Running   0          9m53s
ledgerwriter-7b5b6db66f-297c2         2/2     Running   0          9m52s
loadgenerator-7fb54d57f8-tj44v        2/2     Running   0          9m52s
transactionhistory-7fdb998c5f-xvmtn   2/2     Running   0          9m52s
userservice-76996974f5-mg7t6          2/2     Running   0          9m51s

Men-deploy konfigurasi Cloud Service Mesh ke kedua cluster. Hal ini menghasilkan Gateway di namespace asm-ingress dan VirtualService di namespace bank-of-anthos untuk layanan frontend, yang memungkinkan Anda traffic masuk ke frontend layanan.

Gateways umumnya dimiliki oleh admin platform atau admin jaringan tim. Oleh karena itu, resource Gateway dibuat di Gateway Ingress namespace yang dimiliki oleh admin platform dan dapat digunakan di namespace lainnya melalui entri VirtualService-nya sendiri. Ini adalah 'Gateway Bersama' model transformer.

cat <<'EOF' > asm-vs-gateway.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  selector:
    asm: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: frontend
  namespace: bank-of-anthos
spec:
  hosts:
  - "*"
  gateways:
  - asm-ingress/asm-ingressgateway
  http:
  - route:
    - destination:
        host: frontend
        port:
          number: 80
EOF

kubectl --context=$CLUSTER_1 apply -f asm-vs-gateway.yaml

kubectl --context=$CLUSTER_2 apply -f asm-vs-gateway.yaml

Anda kini telah men-deploy aplikasi Bank of Anthos di dua Cluster GKE. Semua layanan berjalan sebagai layanan terdistribusi, kecuali untuk {i>database<i}.

Memeriksa layanan terdistribusi

Di bagian ini, Anda akan menggunakan alat istioctl untuk memeriksa konfigurasi proxy dari dari {i>proxy<i}. Dengan melakukan hal ini, Anda dapat mengetahui bahwa proxy file bantuan melihat dua Pod untuk setiap service, dengan satu Pod berjalan di setiap cluster.

Di Cloud Shell, periksa daftar Endpoints proxy-config di Pod frontend di cluster_1:

export FRONTEND1=$(kubectl get pod -n bank-of-anthos -l app=frontend \
  --context=${CLUSTER_1} -o jsonpath='{.items[0].metadata.name}')
istioctl proxy-config endpoints \
--context $CLUSTER_1 -n bank-of-anthos $FRONTEND1 | grep bank-of-anthos

Outputnya akan terlihat seperti berikut:

10.12.0.6:5432                   HEALTHY     OK                outbound|5432||accounts-db.bank-of-anthos.svc.cluster.local
10.12.0.7:8080                   HEALTHY     OK                outbound|8080||balancereader.bank-of-anthos.svc.cluster.local
10.12.0.8:8080                   HEALTHY     OK                outbound|8080||transactionhistory.bank-of-anthos.svc.cluster.local
10.12.0.9:8080                   HEALTHY     OK                outbound|8080||userservice.bank-of-anthos.svc.cluster.local
10.12.1.10:8080                  HEALTHY     OK                outbound|8080||ledgerwriter.bank-of-anthos.svc.cluster.local
10.12.1.9:8080                   HEALTHY     OK                outbound|8080||contacts.bank-of-anthos.svc.cluster.local
10.12.2.11:5432                  HEALTHY     OK                outbound|5432||ledger-db.bank-of-anthos.svc.cluster.local
10.12.2.13:8080                  HEALTHY     OK                outbound|80||frontend.bank-of-anthos.svc.cluster.local
10.76.1.10:8080                  HEALTHY     OK                outbound|8080||transactionhistory.bank-of-anthos.svc.cluster.local
10.76.1.8:8080                   HEALTHY     OK                outbound|8080||balancereader.bank-of-anthos.svc.cluster.local
10.76.1.9:8080                   HEALTHY     OK                outbound|80||frontend.bank-of-anthos.svc.cluster.local
10.76.2.10:8080                  HEALTHY     OK                outbound|8080||userservice.bank-of-anthos.svc.cluster.local
10.76.2.8:8080                   HEALTHY     OK                outbound|8080||contacts.bank-of-anthos.svc.cluster.local
10.76.2.9:8080                   HEALTHY     OK                outbound|8080||ledgerwriter.bank-of-anthos.svc.cluster.local

Pada output sebelumnya, setiap layanan terdistribusi memiliki dua IP Endpoint untuk alamat internal dan eksternal. Berikut ini adalah alamat IP Pod, satu untuk setiap cluster.

Akses Bank of Anthos

Untuk mengakses aplikasi Bank of Anthos, Anda dapat menggunakan asm-ingressgateway Alamat IP publik layanan dari kedua cluster.

Dapatkan asm-ingressgateway alamat IP dari kedua cluster:

kubectl --context ${CLUSTER_1} \
--namespace asm-ingress get svc asm-ingressgateway -o jsonpath='{.status.loadBalancer}' | grep "ingress"

kubectl --context ${CLUSTER_2} \
--namespace asm-ingress get svc asm-ingressgateway -o jsonpath='{.status.loadBalancer}' | grep "ingress"

Outputnya akan terlihat seperti berikut.

{"ingress":[{"ip":"35.236.4.18"}]}
{"ingress":[{"ip":"34.68.94.81"}]}

Salin salah satu alamat IP yang akan digunakan pada langkah berikutnya.

Buka tab baru di browser web dan buka salah satu alamat IP dari output sebelumnya. Frontend Bank of Anthos akan ditampilkan, memungkinkan Anda masuk, menyetorkan dana ke akun, dan mentransfer dana ke menggunakan akun layanan. Aplikasi harus berfungsi sepenuhnya.

Memvisualisasikan layanan terdistribusi

Anda dapat memvisualisasikan layanan terdistribusi di Cloud Service Mesh.

Untuk melihat layanan Anda, buka Anthos > Mesh Layanan di Konsol Google Cloud.

Buka Service Mesh

Anda dapat melihat layanan di tampilan Tabel atau dalam tampilan Topologi. Tampilan default adalah tampilan tabel, yang memperlihatkan semua layanan terdistribusi Anda yang berjalan dalam dalam format tabel. Untuk mengubah tampilan, klik tampilan yang ingin ditampilkan.
Pada tampilan Tables, klik frontend distributed service. Bila Anda mengklik layanan satu per satu, Anda akan melihat tampilan terperinci dari beserta layanan terhubung.

Dalam tampilan detail layanan, Anda dapat membuat SLO dan melihat histori linimasa layanan dengan mengklik Tampilkan Linimasa.
Untuk melihat sinyal emas, di panel samping, klik Metrik.
Dalam diagram Permintaan per detik, klik Perincian Menurut, lalu pilih Lokasi.

Hasilnya menampilkan permintaan per detik dari kedua cluster dalam region. Layanan terdistribusi responsif dan kedua endpoint melayani kemacetan.
Untuk melihat topologi mesh layanan Anda, di panel samping, klik Anthos Service Mesh, lalu klik Topology View.
Untuk melihat data tambahan, arahkan kursor mouse ke frontend layanan. Tabel ini menampilkan informasi seperti permintaan per detik ke dan dari frontend ke layanan lain.
Untuk melihat detail selengkapnya, klik Luaskan di layanan frontend. J Layanan dan Beban Kerja ditampilkan. Anda dapat memperluas beban kerja ke dalam dua Deployment, perluas deployment menjadi ReplicaSets, dan perluas ReplicaSets menjadi Pod. Saat Anda memperluas semua elemen, Anda bisa melihat layanan frontend terdistribusi yang pada dasarnya adalah satu Service dan dua Pod.

Mengonfigurasi Ingress Multi Cluster

Di bagian ini, Anda akan membuat Ingress Multi Cluster yang mengirim traffic ke Bank layanan frontend GKE Enterprise yang berjalan di kedua cluster. Anda menggunakan Cloud Load Balancing untuk membuat load balancer yang menggunakan Layanan asm-ingressgateway di kedua cluster sebagai backend. Cluster ingress-config digunakan untuk mengorkestrasi Konfigurasi Multi Cluster Ingress.

Untuk membuat load balancer, gunakan MultiClusterIngress dan satu atau beberapa MultiClusterServices. MultiClusterIngress dan MultiClusterService objek adalah analog multi-cluster untuk Kubernetes Ingress dan Service yang sudah ada resource yang digunakan dalam konteks cluster tunggal.

Aktifkan GKE Enterprise, GKE Fleet yang diperlukan, serta Multi Cluster Ingress API:

gcloud services enable \
  anthos.googleapis.com \
  multiclusterservicediscovery.googleapis.com \
  multiclusteringress.googleapis.com

Buat cluster ingress-config. Anda dapat menggunakan cluster apa pun, tetapi kita sebaiknya buat cluster terpisah untuk tujuan ini.

gcloud container clusters create ${CLUSTER_INGRESS} \
  --zone ${CLUSTER_INGRESS_ZONE} \
  --num-nodes=1 \
  --enable-ip-alias \
  --workload-pool=${WORKLOAD_POOL}

Dapatkan kredensial cluster dan ganti nama konteks demi kemudahan:

gcloud container clusters get-credentials ${CLUSTER_INGRESS} \
  --zone ${CLUSTER_INGRESS_ZONE} --project ${PROJECT_ID}

kubectl config rename-context \
  gke_${PROJECT_ID}_${CLUSTER_INGRESS_ZONE}_${CLUSTER_INGRESS} ${CLUSTER_INGRESS}

Untuk menggunakan Multi Cluster Ingress, daftarkan semua cluster yang berpartisipasi untuk GKE Enterprise Fleet, termasuk cluster konfigurasi:

Daftarkan cluster konfigurasi:

gcloud container fleet memberships register ${CLUSTER_INGRESS} \
  --project=${PROJECT_ID} \
  --gke-cluster=${CLUSTER_INGRESS_ZONE}/${CLUSTER_INGRESS} \
  --enable-workload-identity

Pastikan semua cluster sudah terdaftar di GKE Enterprise Fleet:

gcloud container fleet memberships list

Outputnya akan terlihat seperti berikut:

NAME            EXTERNAL_ID
gke-west        7fe5b7ce-50d0-4e64-a9af-55d37b3dd3fa
gke-central     6f1f6bb2-a3f6-4e9c-be52-6907d9d258cd
gke-ingress     3574ee0f-b7e6-11ea-9787-42010a8a019c

Mengaktifkan fitur Multi Cluster Ingress di cluster ingress-config. Tindakan ini akan membuat MulticlusterService dan MulticlusterIngress CustomResourceDefinitions (CRD) di cluster.
```
gcloud container fleet ingress enable \
  --config-membership=projects/${PROJECT_ID}/locations/global/memberships/${CLUSTER_INGRESS}
```

Pastikan Multi Cluster Ingress telah diaktifkan di cluster ingress-config:

gcloud container fleet ingress describe

Outputnya akan terlihat seperti berikut:

membershipStates:
  projects/986443280307/locations/global/memberships/gke-central-priv:
    state:
      code: OK
      updateTime: '2022-09-29T13:57:02.972748202Z'
  projects/986443280307/locations/global/memberships/gke-ingress:
    state:
      code: OK
      updateTime: '2022-09-29T13:57:02.972744692Z'
  projects/986443280307/locations/global/memberships/gke-west-priv:
    state:
      code: OK
      updateTime: '2022-09-29T13:57:02.972746497Z'

Pastikan kedua CRD di-deploy di cluster ingress-config:

kubectl --context=${CLUSTER_INGRESS} get crd | grep multicluster

Outputnya akan terlihat seperti berikut.

multiclusteringresses.networking.gke.io     2020-10-29T17:32:50Z
multiclusterservices.networking.gke.io      2020-10-29T17:32:50Z

Buat namespace asm-ingress di cluster ingress-config:

kubectl --context ${CLUSTER_INGRESS} create namespace asm-ingress

Buat resource MultiClusterIngress:

cat <<EOF > ${HOME}/mci.yaml
apiVersion: networking.gke.io/v1beta1
kind: MultiClusterIngress
metadata:
  name: asm-ingressgateway-multicluster-ingress
spec:
  template:
    spec:
      backend:
       serviceName: asm-ingressgateway-multicluster-svc
       servicePort: 80
EOF

Buat resource MultiClusterService:

cat <<'EOF' > $HOME/mcs.yaml
apiVersion: networking.gke.io/v1beta1
kind: MultiClusterService
metadata:
  name: asm-ingressgateway-multicluster-svc
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {"80":"gke-ingress-config"}}'
spec:
  template:
    spec:
      selector:
        asm: ingressgateway
      ports:
      - name: frontend
        protocol: TCP
        port: 80 # servicePort defined in Multi Cluster Ingress
  clusters:
  - link: "us-west2-a/gke-west-priv"
  - link: "us-central1-a/gke-central-priv"
EOF

Buat resource BackendConfig untuk health check:

cat <<EOF > $HOME/backendconfig.yaml
apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: gke-ingress-config
spec:
  healthCheck:
    type: HTTP
    port: 15021
    requestPath: /healthz/ready
EOF

Terapkan BackendConfig, MultiClusterService, dan Manifes MultiClusterIngress:

kubectl --context ${CLUSTER_INGRESS} -n asm-ingress apply -f ${HOME}/backendconfig.yaml
kubectl --context ${CLUSTER_INGRESS} -n asm-ingress apply -f ${HOME}/mci.yaml
kubectl --context ${CLUSTER_INGRESS} -n asm-ingress apply -f ${HOME}/mcs.yaml

MultiClusterService yang Anda deploy di Cluster Ingress akan membuat Service "headless" di cluster 1 dan cluster 2. Verifikasi bahwa kolom "headless" Services telah dibuat:

kubectl --context=${CLUSTER_1} -n asm-ingress \
  get services | grep multicluster-svc
kubectl --context=${CLUSTER_2} -n asm-ingress \
  get services | grep multicluster-svc

Outputnya mirip dengan:

mci-frontend-multi-cluster-service-svc-f7rcyqry22iq8nmw   ClusterIP      None          <none>          80/TCP         77s
mci-frontend-multi-cluster-service-svc-f7rcyqry22iq8nmw   ClusterIP      None          <none>          80/TCP         78s

Jalankan perintah berikut dan tunggu hingga Anda mendapatkan Alamat IP Cloud Load Balancing:
```
watch kubectl --context ${CLUSTER_INGRESS} -n asm-ingress get multiclusteringress \
  -o jsonpath="{.items[].status.VIP}"
```
Outputnya akan terlihat seperti berikut:
```
35.35.23.11
```
Catatan: Proses ini akan selesai dalam waktu 5 menit.

Untuk keluar dari perintah watch, tekan Ctrl+C.
Membuka alamat IP Cloud Load Balancing di browser web untuk menuju ke frontend Bank of Anthos:
```
kubectl --context ${CLUSTER_INGRESS} \
  -n asm-ingress get multiclusteringress \
  -o jsonpath="{.items[].status.VIP}"
```
Jika Anda mendapatkan pesan error 404 (atau error 502), tunggu beberapa menit lalu memuat ulang halaman di browser web Anda.

Pembersihan

Untuk menghindari tagihan ke akun Anda, hapus proyek atau hapus klaster.

Menghapus project

Cara termudah untuk menghilangkan penagihan adalah dengan menghapus project yang Anda buat untuk tutorial.

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 berbagai arsitektur, tutorial, atau panduan memulai, menggunakan kembali project dapat membantu agar Anda tidak melampaui batas kuota project.

Di konsol Google Cloud, buka halaman Manage resource.
Buka Manage resource
Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
Pada dialog, ketik project ID, lalu klik Shut down untuk menghapus project.

Menghapus cluster

Di Cloud Shell, batalkan pendaftaran dan hapus cluster blue dan green:

gcloud container fleet memberships unregister ${CLUSTER_1} \
  --project=${PROJECT} \
  --gke-uri=${CLUSTER_1_URI}
gcloud container clusters delete ${CLUSTER_1} \
  --zone ${CLUSTER_1_ZONE} \
  --quiet

gcloud container fleet memberships unregister ${CLUSTER_2} \
  --project=${PROJECT} \
  --gke-uri=${CLUSTER_2_URI}
gcloud container clusters delete ${CLUSTER_2} \
  --zone ${CLUSTER_2_ZONE} \
  --quiet

Hapus resource MuticlusterIngress dari cluster ingress-config:
```
kubectl --context ${CLUSTER_INGRESS} -n istio-system delete -f $HOME/mci.yaml
```
Tindakan ini akan menghapus resource Cloud Load Balancing dari project.

Batalkan pendaftaran dan hapus cluster ingress-config:

gcloud container fleet memberships unregister ${CLUSTER_INGRESS} \
  --project=${PROJECT} \
  --gke-uri=${CLUSTER_INGRESS_URI}
gcloud container clusters delete ${CLUSTER_INGRESS} \
  --zone ${CLUSTER_INGRESS_ZONE} \
  --quiet

Pastikan semua cluster telah dihapus:
```
gcloud container clusters list
```
Outputnya adalah sebagai berikut:
```
<null>
```
Reset file kubeconfig:
```
unset KUBECONFIG
```

Langkah selanjutnya

Pelajari Multi Cluster Ingress lebih lanjut.
Pelajari cara men-deploy Multi Cluster Ingress di berbagai cluster.