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 et l’API Gateway de Kubernetes vise à vous présenter leur fonctionnement et toutes les possibilités offertes par ces mécanismes.

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...

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 Helm ;
à 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.22.3/bin to your path; e.g copy paste in  
your shell and/or ~/.profile:  
export PATH="$PATH:/home/yannig/istio-1.22.3/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...

API Gateway

1. Origine du besoin

Istio n’est pas le seul mécanisme permettant de faire du maillage de services. En effet, il existe plusieurs implémentations de ce mécanisme :

Linkerd : maillage de services similaire à Istio basé sur un proxy spécifique ;
Consul Connect : fonctionne comme une extension de l’outil Consul de Hashicorp ;
AWS App Mesh : utilise le proxy Envoy (le même qu’Istio) dans le contexte AWS. Il permet une intégration poussée avec les services Amazon.

Dans les faits, cette énumération est loin d’être exhaustive sans oublier que le mécanisme Ingress de Kubernetes pourrait lui aussi faire partie de cette liste.

2. Principe de fonctionnement

Partant de ce constat, la communauté Kubernetes a proposé une couche d’abstraction à l’aide du savoir-faire présent sur ces différentes implémentations.

Tout comme pour Istio, l’API Gateway introduit des nouveaux types basés sur des objets CRD (Custom Resource Definition). Ces objets sont ensuite gérés directement par Istio. On retrouve notamment les objets suivants :

les objets Gateway : il s’agit d’une fusion entre les objets Gateway d’Istio ainsi que les pods associés aux Gateway d’Istio (Deployment et Service) ;
les objets HTTPRoute et TCPRoute : remplacent l’objet Virtual Service d’Istio.

À noter que cette norme n’implémente pas pour l’instant toutes les capacités d’Istio.

3. Installation de l’API Gateway

La première étape va être de récupérer les objets CRD de l’API Gateway afin de les injecter dans le cluster courant. Ces opérations se font à l’aide de la commande kubectl suivie de l’option kustomize ainsi que la référence vers la release GitHub du projet (github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.1.0).

Cette commande génère les ressources YAML associées aux objets CRD et les renvoie sur la sortie courante. Le plus simple est alors de les récupérer et de les réinjecter dans l’API de Kubernetes à l’aide de la commande kubectl apply suivie des options -f -.

Ci-dessous les instructions complètes permettant de réaliser...

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...

Maillage de services