Vous consultez la documentation de Service Mesh 1.21.

Versions disponibles

Cloud Service Mesh
Archive 1.22
Archive 1.21
Archive 1.20
Archive 1.19
Archive 1.18

Cette page a été traduite par l'API Cloud Translation.

Exécuter des services distribués sur des clusters privés GKE à l'aide de Cloud Service Mesh

Ce document explique comment exécuter des services distribués sur plusieurs Clusters Google Kubernetes Engine (GKE) dans Google Cloud utilisant Cloud Service Mesh Il explique également comment exposer un service distribué à l'aide de Multi Cluster Ingress et Cloud Service Mesh. Vous pouvez utiliser ce document pour configurer des clusters GKE non privés. Ce document met en évidence la configuration destinée exclusivement aux clusters privés.

Ce document est destiné aux administrateurs de plate-forme et aux opérateurs de service qui possèdent des connaissances de base sur Kubernetes. Certaines connaissances du maillage de services sont bénéfiques, même si cela n'est pas obligatoire. Cloud Service Mesh est basé sur le framework Open Source Istio de l'IA générative. Pour en savoir plus sur le maillage de services et Istio, consultez la page istio.io.

Un service distribué est un service Kubernetes qui agit en tant que service logique unique. Les services distribués sont plus résilients que les services Kubernetes, car ils s'exécutent sur plusieurs clusters Kubernetes dans le même espace de noms. Un service distribué reste actif même si un ou plusieurs clusters GKE sont en panne, tant que les clusters sains sont en mesure de diffuser la charge souhaitée.

Les services Kubernetes ne sont connus que du serveur d'API Kubernetes du cluster sur lequel ils s'exécutent. Si le cluster Kubernetes est arrêté (par exemple, lors d'une maintenance planifiée), tous les services Kubernetes exécutés sur ce cluster sont également indisponibles. L'exécution de services distribués facilite la gestion du cycle de vie des clusters, car vous pouvez les arrêter pour des raisons de maintenance ou de mise à niveau, tandis que d'autres clusters gèrent le trafic. Afin de créer un service distribué, la fonctionnalité de maillage de services fournie par Cloud Service Mesh permet de relier les services exécutés sur plusieurs clusters en un seul service logique.

Les clusters privés GKE vous permettent de configurer les nœuds et le serveur d'API en tant que ressources privées disponibles seulement sur le réseau cloud privé virtuel (VPC). L'exécution de services distribués dans des clusters privés GKE offre aux entreprises des services sécurisés et fiables.

Architecture

Ce tutoriel utilise l'architecture illustrée dans le diagramme suivant :

Architecture des services distribués sur des clusters privés GKE à l'aide de Cloud Service Mesh

Dans le schéma précédent, l'architecture comprend les clusters suivants :

Deux clusters (gke-central-priv et gke-west-priv) agissent comme des clusters privés GKE identiques dans deux régions différentes.
Un cluster distinct (ingress-config) sert de cluster de plan de contrôle qui configure l'objet Ingress multicluster.

Dans ce tutoriel, vous allez déployer l'exemple d'application Bank of Anthos sur deux clusters privés GKE (gke-central-priv et gke-west-priv). Bank of Anthos est un exemple d'application de microservices qui consiste en plusieurs microservices et bases de données SQL qui simulent une application de banque en ligne. L'application se compose d'une interface Web à laquelle les clients peuvent accéder, et de plusieurs services de backend, tels que le solde, le registre et les services de compte qui simulent une banque.

L'application comprend deux bases de données PostgreSQL installées dans Kubernetes en tant qu'objets StatefulSet. Une base de données est utilisée pour les transactions, tandis que l'autre est utilisée pour les comptes utilisateur. Tous les services, à l'exception des deux bases de données, s'exécutent en tant que services distribués. Cela signifie que les pods de tous les services s'exécutent dans les deux clusters d'application (dans le même espace de noms) et que Cloud Service Mesh est configuré pour que chaque service apparaisse comme un seul service logique.

Objectifs

Créer trois clusters GKE.
Configurer deux des clusters GKE en tant que clusters privés (gke-central-priv et gke-west-priv).
Configurer un cluster GKE (ingress-config) en tant que cluster de configuration central. Ce cluster agit comme un cluster de configuration pour l'objet Ingress multicluster.
Configurer la mise en réseau (passerelles NAT, Cloud Router et règles de pare-feu) pour autoriser le trafic intercluster et le trafic sortant des deux clusters GKE privés.
Configurer les réseaux autorisés pour qu'ils accordent l'accès au service API depuis Cloud Shell vers les deux clusters privés GKE.
Déployez et configurez Cloud Service Mesh multicluster sur les deux des clusters privés en mode multi-principal. Le mode multiprimaire déploie Plan de contrôle Cloud Service Mesh dans les deux clusters.
Déployer l'application Bank of Anthos sur les deux clusters privés. À l'exception des bases de données, tous les services sont déployés en tant que services distribués (pods s'exécutant sur les deux clusters privés).
Surveiller les services à l'aide de Cloud Service Mesh
Configurez l'objet Ingress multicluster sur les services frontend de Bank of Anthos. Cela permet aux clients externes (par exemple, votre navigateur Web) d'accéder à un service distribué s'exécutant sur un parc de clusters GKE privés.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Avant de commencer

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Make sure that billing is enabled for your Google Cloud project.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

Vous exécuterez toutes les commandes de ce tutoriel depuis Cloud Shell.

Définissez les variables d'environnement utilisées tout au long de ce tutoriel. Les variables définissent les noms de clusters, les régions, les zones, l'adressage IP et les versions de Cloud Service Mesh utilisées dans ce tutoriel.

en remplaçant YOUR_PROJECT_ID par votre ID de projet :

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

Définissez les variables d'environnement restantes :

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)

Préparer votre environnement

Dans Cloud Shell, activez les API :

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

Activez le parc Cloud Service Mesh pour votre projet :

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

Préparer la mise en réseau pour les clusters GKE privés

Dans cette section, vous allez préparer la mise en réseau des clusters GKE privés que vous utilisez pour exécuter des services distribués.

Aucune adresse IP publique n'est attribuée aux nœuds de cluster GKE privés. Tous les nœuds d'un cluster GKE privé se voient attribuer une adresse IP VPC privée (dans l'espace d'adressage RFC 1918). Cela signifie que les pods qui ont besoin d'accéder à des ressources externes (en dehors du réseau VPC) requièrent une passerelle Cloud NAT. Les passerelles Cloud NAT sont des passerelles NAT régionales qui permettent aux pods avec des adresses IP internes de communiquer avec Internet. Dans ce tutoriel, vous allez configurer une passerelle Cloud NAT dans chacune des deux régions. Plusieurs clusters d'une région peuvent utiliser la même passerelle NAT.

Dans Cloud Shell, créez deux adresses IP externes et réservez-les pour les deux passerelles 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}

Stockez l'adresse IP et le nom des adresses IP dans des variables :

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)')

Créez des passerelles Cloud NAT dans les deux régions des clusters GKE privés :

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

Créez une règle de pare-feu qui autorise la communication entre pods et la communication entre pods et serveurs d'API. La communication entre les pods permet aux services distribués de communiquer entre eux sur les clusters GKE. La communication entre les pods et les serveurs d'API permet au plan de contrôle de Cloud Service Mesh d'interroger les clusters GKE pour détecter les services.
```
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}
```

La mise en réseau est maintenant préparée. Dans ce tutoriel, vous utilisez l'intégralité de la plage d'adresses IP 10.0.0.0/8, qui inclut toutes les plages de pods. En production, nous vous recommandons de créer une règle de pare-feu plus stricte, en fonction de vos conditions et de vos exigences.

Créer des clusters GKE privés

Dans cette section, vous allez créer les deux clusters GKE privés dans lesquels l'exemple d'application est déployé. Dans ce tutoriel, les nœuds de cluster GKE privé ont des adresses IP privées, et le serveur d'API dispose d'un point de terminaison public. L'accès au serveur d'API est toutefois limité à l'aide de réseaux autorisés.

Dans Cloud Shell, créez deux clusters privés disposant de réseaux autorisés. Configurez les clusters pour autoriser l'accès à partir de la plage CIDR des adresses IP des pods (pour le plan de contrôle de Cloud Service Mesh) et de Cloud Shell afin de pouvoir accéder aux clusters à partir de votre terminal.

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

Les réseaux autorisés contiennent les adresses IP publiques sur les passerelles Cloud NAT. Étant donné que le point de terminaison du serveur d'API pour un cluster privé est un point de terminaison public, les pods exécutés dans un cluster privé doivent utiliser une passerelle Cloud NAT pour accéder aux points de terminaison du serveur d'API public.

L'adresse IP de Cloud Shell fait également partie des réseaux autorisés, ce qui vous permet d'accéder aux clusters et de les gérer depuis votre terminal Cloud Shell. Les adresses IP publiques de Cloud Shell sont dynamiques. Par conséquent, chaque fois que vous démarrez Cloud Shell, vous pouvez obtenir une adresse IP publique différente. Lorsque vous obtenez une nouvelle adresse IP, vous perdez l'accès aux clusters, car la nouvelle adresse IP ne fait pas partie des réseaux autorisés pour les deux clusters.

Si vous perdez l'accès aux clusters, mettez à jour les réseaux autorisés des clusters pour inclure la nouvelle adresse IP Cloud Shell :

Obtenez l'adresse IP publique Cloud Shell mise à jour :

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

Mettez à jour les réseaux autorisés pour les deux clusters :

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

Vérifiez que tous les clusters sont en cours d'exécution :

gcloud container clusters list

La sortie ressemble à ceci :

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

Connectez-vous aux deux clusters pour générer des entrées dans le fichier 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}
```
Vous utilisez le fichier kubeconfig pour vous authentifier auprès des clusters en créant un utilisateur et un contexte pour chaque cluster. Une fois les entrées générées dans le fichier kubeconfig, vous pouvez rapidement basculer entre différents contextes pour les clusters.

Renommez les contextes de cluster pour plus de commodité :

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}

Vérifiez que les deux contextes de cluster ont été correctement renommés et configurés :
```
kubectl config get-contexts --output="name"
```
La sortie ressemble à ceci :
```
gke-central-priv
gke-west-priv
```

Enregistrez vos clusters dans un parc :

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

Vous avez maintenant créé et renommé vos clusters GKE privés.

Installer Cloud Service Mesh

Dans cette section, vous installez Cloud Service Mesh sur les deux clusters GKE et configurez les clusters pour la détection de services entre clusters.

Dans Cloud Shell, installez Cloud Service Mesh sur les deux clusters à l'aide de fleet API:
```
gcloud container fleet mesh update --management automatic --memberships ${CLUSTER_1},${CLUSTER_2}
```
Remarque :Ce processus devrait prendre 10 minutes.
Une fois que le service Cloud Service Mesh géré est activé sur les clusters, définissez une surveillance pour l'installation du maillage:
```
watch -g "gcloud container fleet mesh describe | grep 'code: REVISION_READY'"
```

Installer des passerelles d'entrée Cloud Service Mesh pour les deux clusters:

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

Vérifiez que les passerelles d'entrée Cloud Service Mesh sont déployées:
```
kubectl --context=${CLUSTER_1} get pod,service -n asm-ingress
kubectl --context=${CLUSTER_2} get pod,service -n asm-ingress
```
Le résultat des deux clusters ressemble à ce qui suit :
```
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
```
Une fois que le plan de contrôle et les passerelles d'entrée de Cloud Service Mesh sont installés pour les deux clusters, la détection de services entre clusters est activée avec l'API Fleet. La détection de services entre clusters permet aux deux clusters de découvrir les points de terminaison de service du cluster distant. Les services distribués s'exécutent sur plusieurs clusters dans le même espace de noms.

Pour que les deux plans de contrôle Cloud Service Mesh puissent détecter tous les points de terminaison d'un service distribué, Cloud Service Mesh doit avoir accès à tous les clusters qui exécutent le service distribué. Cet exemple utilise deux clusters. Par conséquent, les deux clusters doivent pouvoir interroger le cluster distant pour y rechercher des points de terminaison de service. Lorsque Cloud Service Mesh géré est activé avec l'API Fleet, la découverte des points de terminaison est configurée automatiquement.

Les clusters et Cloud Service Mesh sont maintenant configurés.

Déployer l'application Bank of Anthos

Dans Cloud Shell, clonez le dépôt GitHub de Bank of Anthos :

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

Créez et attribuez un libellé à un espace de noms bank-of-anthos dans les deux clusters. Le libellé permet l'injection automatique des proxys side-car Envoy dans chaque pod de l'espace de noms auquel un libellé a été attribué.

# 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

Déployez l'application Bank of Anthos sur les deux clusters de l'espace de noms 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

Les services Kubernetes doivent se trouver dans les deux clusters pour la découverte de services. Lorsqu'un service de l'un des clusters tente d'envoyer une requête, il effectue d'abord une résolution DNS pour le nom d'hôte afin d'obtenir l'adresse IP. Dans GKE, le serveur kube-dns exécuté dans le cluster gère cette recherche. Une définition de service configurée est donc requise.

Supprimez les objets StatefulSets d'un cluster afin que les deux bases de données PostgreSQL n'existent que dans l'un des clusters :

# 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

Assurez-vous que tous les pods s'exécutent dans les deux clusters :

Obtenez les pods depuis cluster_1 :

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

La sortie ressemble à ceci :

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

Obtenez les pods depuis cluster_2 :

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

La sortie ressemble à ceci :

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

Déployez les configurations Cloud Service Mesh sur les deux clusters. Cela crée un Passerelle dans l'espace de noms asm-ingress. VirtualService dans les espaces de noms bank-of-anthos pour le service frontend, ce qui vous permet d'entrer du trafic entrant vers le frontend Google Cloud.

Les Gateways appartiennent généralement aux administrateurs de la plate-forme ou aux administrateurs réseau équipe. Par conséquent, la ressource Gateway est créée dans la passerelle d'entrée. espace de noms appartenant à l'administrateur de la plate-forme et pouvant être utilisé dans d'autres espaces de noms via leurs propres entrées VirtualService. Il s'agit d'un modèle de "passerelle partagée".

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

Vous venez de déployer l'application Bank of Anthos sur deux plates-formes clusters GKE. Tous les services s'exécutent en tant que services distribués, sauf pour la base de données.

Inspecter les services distribués

Dans cette section, vous utilisez l'outil istioctl pour inspecter la configuration proxy de l'un des proxys. Cela vous permet de voir que les proxys side-car voient deux pods pour chaque service, avec un pod en cours d'exécution dans chaque cluster.

Dans Cloud Shell, examinez la liste des points de terminaison de configuration proxy du pod frontend dans 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

La sortie ressemble à ceci :

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

Dans le résultat précédent, chaque service distribué possède deux adresses IP de point de terminaison. Il s'agit des adresses IP des pods, une pour chaque cluster.

Access Bank of Anthos

Pour accéder à l'application Bank of Anthos, vous pouvez utiliser l'adresse IP publique du service asm-ingressgateway à partir de l'un ou l'autre des clusters.

Obtenez les adresses IP asm-ingressgateway des deux clusters :

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"

Le résultat est semblable à ce qui suit.

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

Copiez l'une des adresses IP à utiliser à l'étape suivante.

Ouvrez un nouvel onglet dans un navigateur Web et accédez à l'une des adresses IP du résultat précédent. L'interface de Bank of Anthos doit s'afficher. Elle vous permet de vous connecter, de déposer des fonds sur votre compte et de transférer des fonds vers d'autres comptes. L'application doit être totalement fonctionnelle.

Visualiser les services distribués

Vous pouvez visualiser des services distribués dans Cloud Service Mesh.

Pour afficher vos services, accédez à la page Service Mesh dans la console Google Cloud.

Accéder à Service Mesh

Vous pouvez afficher les services dans une vue Tableau ou dans une vue Topologie. La vue par défaut est la vue Tableau, qui affiche tous les services distribués s'exécutant sous forme de tableau. Pour changer de vue, cliquez sur la vue que vous souhaitez afficher.
Dans la vue Tableaux, cliquez sur frontend distributed service. Lorsque vous cliquez sur un service individuel, vous obtenez une vue détaillée du service et des services connectés.

Dans la vue "Détails du service", vous pouvez créer des SLO et afficher une chronologie historique du service en cliquant sur Afficher la chronologie.
Pour afficher les signaux clés, cliquez sur Métriques dans le panneau latéral.
Dans le graphique Requêtes par seconde, cliquez sur Répartition par, puis sélectionnez Emplacement.

Les résultats affichent les requêtes par seconde des deux clusters dans les deux régions. Le service distribué est opérationnel et les deux points de terminaison diffusent le trafic.
Pour afficher la topologie de votre maillage de services, cliquez sur Anthos Service Mesh dans le panneau latéral, puis sur Vue Topologie.
Pour afficher des données supplémentaires, maintenez le pointeur de la souris sur le service frontend. Cela permet d'afficher des informations telles que le nombre de requêtes par seconde entrant et sortant de l'interface depuis et vers d'autres services.
Pour afficher plus de détails, cliquez sur Développer sur le service frontend. Un service et une charge de travail s'affichent. Vous pouvez étendre davantage la charge de travail à deux déploiements, étendre les déploiements en ReplicaSets et étendre les ReplicaSets en pods. Lorsque vous développez tous les éléments, vous pouvez voir le service distribué frontend, qui est essentiellement un service et deux pods.

Configurer un objet Ingress multicluster

Dans cette section, vous allez créer un objet Ingress multicluster qui envoie du trafic vers les services frontend de Bank of GKE Enterprise exécutés dans les deux clusters. Vous utilisez Cloud Load Balancing pour créer un équilibreur de charge qui utilise les services asm-ingressgateway à la fois en tant que backends. Un cluster ingress-config est utilisé pour orchestrer la configuration de l'objet Ingress multi-cluster.

Pour créer l'équilibreur de charge, vous devez utiliser un MultiClusterIngress et un ou plusieurs MultiClusterServices. Les objets MultiClusterIngress et MultiClusterService sont des ressources multicluster correspondant aux ressources Kubernetes "Ingress" et "Service" qui sont utilisées dans le cadre d'un cluster unique.

Activez les API GKE Enterprise, GKE Fleet et Multi Cluster Ingress requises :

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

Créez le cluster ingress-config. Vous pouvez utiliser n'importe quel cluster, mais nous vous recommandons de créer un cluster distinct à cette fin.

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

Obtenez les identifiants du cluster et renommez le contexte pour plus de commodité :

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}

Pour utiliser un objet Ingress multicluster, enregistrez tous les clusters participants dans le parc GKE Enterprise, y compris le cluster de configuration :

Enregistrez le cluster de configuration :

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

Vérifiez que tous les clusters sont enregistrés dans le parc GKE Enterprise:

gcloud container fleet memberships list

La sortie ressemble à ceci :

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

Activez les fonctionnalités de l'objet Ingress multi-cluster sur le cluster ingress-config. Cela crée les définitions de ressources personnalisées (CRD, CustomResourceDefinitions) MulticlusterService et MulticlusterIngress sur le cluster.
```
gcloud container fleet ingress enable \
  --config-membership=projects/${PROJECT_ID}/locations/global/memberships/${CLUSTER_INGRESS}
```

Vérifiez que l'objet Ingress multicluster est activé sur le cluster ingress-config :

gcloud container fleet ingress describe

La sortie ressemble à ceci :

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'

Vérifiez que les deux CRD sont déployées dans le cluster ingress-config :

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

Le résultat est semblable à ce qui suit.

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

Créez l'espace de noms asm-ingress dans le cluster ingress-config :

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

Créez la ressource 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

Créez la ressource 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

Créez la ressource BackendConfig pour les vérifications d'état :

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

Appliquez les fichiers manifestes BackendConfig, MultiClusterService et 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

Le service MultiClusterService que vous avez déployé dans le cluster Ingress va créer un service Service sans interface graphique dans les clusters 1 et 2. Vérifiez que les services Services sans interface graphique ont été créés :

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

Le résultat est semblable à :

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

Exécutez la commande suivante et attendez d'obtenir une adresse IP Cloud Load Balancing :
```
watch kubectl --context ${CLUSTER_INGRESS} -n asm-ingress get multiclusteringress \
  -o jsonpath="{.items[].status.VIP}"
```
La sortie ressemble à ceci :
```
35.35.23.11
```
Remarque :Ce processus devrait prendre cinq minutes.

Pour quitter la commande watch, appuyez sur Ctrl+C.
Accédez à l'adresse IP de Cloud Load Balancing dans un navigateur Web pour accéder à l'interface de Bank of Anthos :
```
kubectl --context ${CLUSTER_INGRESS} \
  -n asm-ingress get multiclusteringress \
  -o jsonpath="{.items[].status.VIP}"
```
Si vous obtenez une erreur 404 (ou une erreur 502), attendez quelques minutes, puis actualisez la page dans votre navigateur Web.

Effectuer un nettoyage

Pour éviter que des frais ne soient facturés sur votre compte, supprimez le projet ou les clusters.

Supprimer le projet

Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :

Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

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.

Supprimer les clusters

Dans Cloud Shell, annulez l'enregistrement et supprimez les clusters blue et 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

Supprimez la ressource MuticlusterIngress du cluster de configuration d'entrée :
```
kubectl --context ${CLUSTER_INGRESS} -n istio-system delete -f $HOME/mci.yaml
```
Cela supprime les ressources Cloud Load Balancing du projet.

Annuler l'enregistrement et supprimer le 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

Vérifiez que tous les clusters sont supprimés :
```
gcloud container clusters list
```
Le résultat est le suivant :
```
<null>
```
Réinitialisez le fichier kubeconfig :
```
unset KUBECONFIG
```

Étape suivante

En savoir plus sur l'objet Ingress multicluster.
Découvrez comment déployer un objet Ingress multicluster sur plusieurs clusters.