Anthos Service Mesh (ASM) est une installation managée d'Istio, un service mesh pour Kubernetes. Suivez notre guide pas à pas pour configurer un ASM multi-cluster avec le control plane managé.

Anthos Service Mesh

Voici un guide pas à pas pour configurer un Anthos Service Mesh (ASM) multi-cluster à l'aide du control plane managé.

Le code associé est disponible ici : https://github.com/caddac/anthos-examples/tree/main/asm

Un service mesh est une couche d'abstraction posée au-dessus de différentes plateformes de calcul – ici, des clusters – pour simplifier la communication entre services, l'observabilité et la sécurité. Il déplace ces responsabilités vers la plateforme et permet ainsi d'avoir des applications plus simples. Dans cet article, nous allons déployer Anthos Service Mesh, qui est une installation managée d'Istio. Istio est un service mesh pour Kubernetes : un outil puissant pour bénéficier d'une visibilité homogène sur l'observabilité et la sécurité entre services. Avec Istio, l'ensemble du trafic inter-services transite par des proxies exécutés en sidecars de vos pods.

Les services s'appuient sur les patterns cohérents et transparents d'Istio pour communiquer entre eux, sans avoir à se soucier de la manière de joindre un autre service, de sécuriser les requêtes entrantes ou de publier des métriques sur le trafic inter-services. Istio prend tout cela en charge. Ces fonctionnalités prennent encore plus d'importance dans une configuration multi-cluster, où la charge opérationnelle est nettement plus élevée.

Recourir à un service mesh comporte aussi quelques inconvénients : complexité de mise en place, surcoût en ressources et coût financier. Istio offre de nombreuses fonctionnalités et plusieurs façons de le configurer, notamment istioctl, IstioOperator et helm. Cependant, Anthos Service Mesh avec control plane managé ne prend en charge ni l'API IstioOperator ni helm.

Dans ce tutoriel, nous allons créer deux clusters GKE et y déployer l'application hello-world d'Istio. Nous installerons ensuite un unique ingress (sur un seul cluster) et nous montrerons que le trafic est réparti entre les 4 pods hello-world répartis sur les deux clusters GKE.

service-mesh

Déployer le terraform

Dans le répertoire asm/infra, mettez à jour les valeurs du fichier var_inputs.auto.tfvars.

Lancez le plan puis l'apply :

$ terraform init

$ terraform apply

Note : si l'apply échoue, relancez-le. Terraform a parfois du mal à enchaîner autant de ressources interdépendantes en une seule passe. Il a fallu trois tentatives pour que toutes les ressources soient créées.

Il se passe beaucoup de choses ici, alors passons-les brièvement en revue.

infra.tf

Ce fichier déploie un nouveau projet GCP et active plusieurs APIs requises [1]. Petite précision : la documentation officielle semble omettre les APIs sts et anthos, pensez donc à les activer.

Il déploie également un VPC, deux sous-réseaux avec des plages secondaires et une règle de pare-feu pour permettre à l'ensemble de communiquer. Enfin, il active la fonctionnalité hub mesh pour le projet.

cluster1.tf et cluster2.tf

Chaque fichier déploie un cluster. Ils ne diffèrent que par le nom des clusters, les régions et les références aux sous-réseaux. Voici deux points à noter sur la configuration. D'abord, nous avons défini le label mesh_id pour que GCP sache à quel mesh appartient chaque cluster. Ensuite, nous avons activé Workload Identity, qui permet aux comptes de service Kubernetes d'agir en tant que comptes de service GCP [2] sans qu'il soit nécessaire de télécharger ni même de créer de clés JSON.

Nous enregistrons le cluster dans la fleet, en utilisant son nom comme membership id.

Enfin, nous installons le control plane managé. Nous utilisons le control-plane automatique (donc managé), mais quelle révision ? Vérifiez le label de révision sur le namespace pour voir quelle révision du control plane est utilisée [5]. Oui, c'est aussi simple que cela !

À ce stade, nous avons deux clusters dans la même fleet, tous deux avec ASM installé via le control plane managé. Nous pouvons donc commencer à installer les composants Istio, mais les clusters ne disposent pas encore du service discovery cross-cluster.

Configurer le service discovery cross-cluster

Nous devons installer les secrets de chaque cluster sur tous les autres clusters de la fleet. Heureusement, un outil en ligne de commande existe pour cela : asmcli. Il ne fonctionne malheureusement pas encore sous macOS ; le plus simple est donc de l'exécuter depuis la cloud console.

Ouvrez la cloud console dans votre projet en accédant à la console GCP et en cliquant sur le bouton de la cloud console.

istio-service-mesh

Une fois la console ouverte en bas de l'écran, exécutez les commandes suivantes :

$ curl https://storage.googleapis.com/csm-artifacts/asm/asmcli\_1.13 > asmcli

$ chmod +x asmcli

_$ ./asmcli create-mesh ${GOOGLE_CLOUD_PROJECT} _

_${GOOGLE_CLOUD_PROJECT}/us-west1/${GOOGLE_CLOUD_PROJECT}-cluster1 _

${GOOGLE_CLOUD_PROJECT}/us-east1/${GOOGLE_CLOUD_PROJECT}-cluster2

istio-kubernetes

Petite précision : si vous utilisez des clusters privés, des étapes supplémentaires sont nécessaires pour activer le service discovery cross-cluster [6][7].

Déployer les applications et les composants Istio

Depuis le répertoire asm/manifests, nous pouvons installer les applications nécessaires pour tester notre mesh. Sur le cluster 1, nous allons installer l'application helloworld ainsi que les composants Istio pour l'ingress.

Commencez par récupérer les contextes des clusters :

export PROJECT_ID=<gcp_project_id>

gcloud container clusters get-credentials ${PROJECT_ID}-cluster1 --region us-west1 --project ${PROJECT_ID}

gcloud container clusters get-credentials ${PROJECT_ID}-cluster2 --region us-east1 --project ${PROJECT_ID}

Installez le cluster 1 en exécutant :

kubectl apply -k manifests/ --context=gke_${PROJECT_ID}_us-west1_${PROJECT_ID}-cluster1

Puis le cluster 2 :

kubectl apply -k manifests/app/ --context=gke_${PROJECT_ID}_us-east1_${PROJECT_ID}-cluster2

service-mesh-istio

Vérifier votre travail

Au bout de quelques minutes, tout devrait être opérationnel et vous pouvez vérifier votre travail.

Vérifiez que tous les pods helloworld tournent sur les deux clusters :

$ export PROJECT_ID=<gcp_project_id>

$ kubectl get pods -n helloworld

--context=gke_${PROJECT_ID}_us-west1_${PROJECT_ID}-cluster1

$ kubectl get pods -n helloworld

--context=gke_${PROJECT_ID}_us-east1_${PROJECT_ID}-cluster2

kubernetes-service-mesh

Vérifiez que le déploiement ingress-gateway tourne bien sur le cluster 1 :

$ kubectl get deploy -n asm-gateways --context=gke_${PROJECT_ID}_us-west1_${PROJECT_ID}-cluster1

istio-mesh

Vérifiez que le service ingress-gateway dispose bien d'une IP externe sur le cluster 1 :

$ kubectl get svc -n asm-gateways --context=gke_${PROJECT_ID}_us-west1_${PROJECT_ID}-cluster1

service-mesh kubernetes

Pour finir, vérifiez que le load balancing cross-cluster fonctionne en interrogeant plusieurs fois l'endpoint public. Vous constaterez que la version et l'identifiant du pod changent à mesure que différents pods sont sollicités. Vous devriez obtenir 4 identifiants de pod distincts et 2 versions différentes.

application-mesh

$ curl /hello

service-mesh-architecture

Personnalisation et consultation des logs

Activer les logs de debug d'envoy

Nous l'avons fait au moment du déploiement de la configuration ASM. Jetez un œil au fichier asm/manifests/gateways/asm-config.yaml. Le ConfigMap déployé configure les proxies envoy pour qu'ils écrivent leurs access logs sur stdout. D'autres options peuvent être activées de la même manière [3].

Logs du control plane

Vous pouvez toujours consulter les logs du control plane lorsque vous utilisez le control plane managé. Ils se trouvent dans Logs Explorer, sous la ressource Istio Control Plane.

Configurer un Anthos Service Mesh multi-cluster avec un control plane managé