Maillage de services avec Istio
Objectifs du chapitre et prérequis
Un maillage de services est un mécanisme permettant de mettre en relation un ensemble de services, les relations entre chacun d’eux formant alors un filet (mesh en anglais). De ce point de vue, Kubernetes répond partiellement à ce besoin en proposant les mécanismes de services ou de polices réseau.
Istio est là pour étendre les fonctions qui ne sont actuellement pas prises en compte par Kubernetes :
-
Instrumentation des temps de réponse.
-
Chiffrement des communications.
-
Capture des traces d’appels.
-
Gestion des pannes de communication (retry, timeout, etc.).
Ce chapitre d’introduction à Istio vise à vous présenter le fonctionnement d’Istio et toutes les possibilités offertes par ce mécanisme.
Présentation d’Istio
1. Micro-services et mise en réseau de services
Le développement d’application en micro-services est un canevas de développement classique. Le principe est de découper l’application à développer en plusieurs éléments indépendants et faiblement couplés. La communication entre deux services se passe ensuite à l’aide d’une API (souvent basée sur REST ou gRPC).
L’avantage de ce type d’architecture est de permettre de faire vivre indépendamment chaque brique par des équipes différentes.
Dans une architecture traditionnelle, une application micro-services peut être difficile à maintenir. De ce point de vue, Kubernetes est parfaitement adapté :
-
Facilité pour déployer plusieurs petites briques indépendantes avec les objets Deployment ou StatefulSet.
-
Création de répartiteur de charge avec la notion de service.
-
Publication des briques à l’aide d’Ingress.
-
Restriction des communications entre briques à l’aide d’objets NetworkPolicy.
En revanche, du fait de cette mise en réseau facilitée, émergent de nouvelles questions :
-
Qui a communiqué avec qui ?
-
Combien de temps a pris la communication entre deux services ?
-
Dans quels services l’application a-t-elle passé...
Installation d’Istio
1. Configuration d’external-dns
Lors des précédents chapitres, la brique external-dns a été déployée afin de gérer la création des entrées DNS des objets Ingress. Istio ne fonctionne plus avec ce mécanisme. Il fait appel à un autre mécanisme basé sur les objets Gateway et VirtualService (ce mécanisme sera présenté plus loin).
Afin que la création des entrées DNS se fasse automatiquement, le chart d’external-dns va être modifié. Cette modification se fait à l’aide de l’option sources du chart. Par défaut, cette variable est un tableau contenant les valeurs service et ingress.
Afin de prendre en charge les gateways Istio, la valeur istio-gateway va être ajoutée à cette liste.
Ci-dessous la déclaration reprenant la configuration d’external-dns avec cette modification pour un cluster faisant appel aux services de chez Google :
provider: google
google:
project: "eni-kubernetes"
serviceAccountSecret: "cloud-dns-key"
sources:
- service
- ingress
# add istio gateway as a source of DNS entries
- istio-gateway
Adaptez le champ provider en fonction de l’hébergeur du cluster Kubernetes. N’hésitez pas à consulter le chapitre Exposition des applications sur Internet.
Sauvegardez cette déclaration sous le nom external-dns.yaml et mettez à jour le chart external-dns :
$ helm upgrade --install external-dns bitnami/external-dns \
--namespace kube-system -f external-dns.yaml
2. Dépôt des charts Istio
Istio peut s’installer de plusieurs manières :
-
À l’aide de la commande istioctl.
-
À l’aide de charts Hel.
-
À l’aide d’un opérateur dédié.
Pour la suite, l’installation se fera à l’aide des charts Helm suivants :
-
istio/base : définition des ressources spécifiques Istio.
-
istio/istiod : installation des briques d’Istio.
D’autres composants sont généralement...
Utilisation d’Istio
1. Injection de pods dans le maillage de services
Afin d’intégrer une application dans le service mesh, il existe deux solutions :
-
L’utilisation d’annotations (sur l’espace de noms ou sur le pod).
-
L’utilisation de la commande istioctl.
a. Installation d’istioctl
La commande istioctl est un binaire permettant de réaliser certaines opérations sur le système Istio. L’installation peut se faire à l’aide de la commande arkade suivante :
$ arkade get istioctl
En cas d’absence d’Arkade, son installation se fait à l’aide de la commande suivante :
$ curl -L https://git.io/getLatestIstio | sh -
La commande doit renvoyer des instructions de ce type :
Add /home/yannig/istio-1.13.2/bin to your path; e.g copy paste in
your shell and/or ~/.profile:
export PATH="$PATH:/home/yannig/istio-1.13.2/bin"
Ajoutez la ligne export PATH dans le fichier profile de l’utilisateur (~/.zshrc pour zsh ou ~/.bashrc pour bash). Redémarrez ensuite votre session pour prendre en compte la modification.
b. Injection du sidecar à l’aide d’istioctl
Une fois la modification terminée, l’injection des déclarations se fait à l’aide de la commande istioctl suivie des options suivantes :
-
L’option kube-inject.
-
L’option -f suivie des ressources dans lesquelles injecter la configuration Istio.
Ci-dessous un exemple de lancement pour un fichier de déploiement :
$ istioctl kube-inject -f deployment.yaml
En l’état, la commande ne fait qu’afficher le contenu du fichier avec les modifications ajoutées.
Pour injecter le résultat dans Kubernetes, passez le résultat de la commande à kubectl à l’aide d’un pipe (|).
Au niveau de kubectl, la commande sera lancée avec les options suivantes :
-
Le verbe apply.
-
L’option -f - pour injecter l’entrée en provenance du pipe directement dans Kubernetes.
Ci-dessous la commande complète permettant d’injecter la configuration Istio directement dans Kubernetes :
$ istioctl kube-inject -f deployment.yaml | kubectl apply -f -
c. Injection du sidecar par annotation
Une autre technique est de procéder à l’injection automatique par l’utilisation...
Tableaux de bord
1. Présentation des différentes briques
En plus du chiffrement de bout en bout d’Istio mis en place précédemment, Istio vient accompagné d’un ensemble de briques prêt à l’emploi : Kiali, Grafana et Jaeger.
Le premier centralise les accès vers Grafana et Jaeger et offre des écrans tableaux de bord de visualisation des relations entre pods.
Grafana se branche sur l’instance Prometheus déployée au moment du déploiement d’Istio.
Enfin, Jaeger permet de restituer les captures de trafic réalisées à l’aide de Zipkin entre les différents pods.
2. Interface Kiali
Par défaut, l’application n’est pas exposée sur Internet. L’accès se fait nécessairement à l’aide de l’instruction kubectl et de l’option port-forward.
Ci-dessous la commande complète à utiliser pour accéder au port 20001 du pod de kiali dans l’espace de noms istio-system :
$ kubectl -n istio-system port-forward deploy/kiali 20001
Entrez ensuite l’adresse http://localhost:20001 dans un navigateur afin d’accéder à l’interface de Kiali.
Sur la gauche, les liens présents permettent de naviguer sur les écrans suivants :
-
Overview : vue d’ensemble des services regroupés par espaces...