Maîtrisez l'Architecture de Maillage de Services avec Istio

1. Introduction

Découvrez la magie de l'architecture de maillage de services et voyez comment elle suralimente vos systèmes distribués.

Plongez dans Istio, la superstar des maillages de services, et découvrez comment il orchestre à la perfection votre cluster Kubernetes.

2. Qu'est-ce qu'un maillage de services ?

Les applications monolithiques ont évolué vers des services plus petits et indépendants. Cette évolution a gagné en popularité avec l'informatique native du cloud et l'architecture des microservices. Des outils comme Docker et Kubernetes ont accéléré cette tendance.

Les microservices sur des plateformes comme Kubernetes offrent de nombreux avantages, mais introduisent aussi des complexités. Gérer la communication entre ces services distribués nécessite une prise en compte minutieuse de la découverte, du routage, des tentatives automatiques et du basculement.

Les défis supplémentaires incluent la sécurité et l'observabilité.

Ces proxys forment un réseau maillé pour les services, d'où le nom. Le maillage de services contrôle chaque aspect de la communication entre services, permettant ainsi de résoudre les huit illusions de l'informatique distribuée.

4. Istio Dévoilé

Istio, un maillage de services open-source né de la collaboration entre IBM, Google et Lyft, améliore de manière invisible les applications distribuées grâce à la gestion du trafic, à la sécurité et aux informations sur la performance.

Déployé de manière flexible sur site, dans le cloud, dans Kubernetes ou sur des machines virtuelles, Istio brille avec les microservices sur Kubernetes. Bien qu'agnostique quant à la plateforme, il s'intègre parfaitement aux environnements conteneurisés.

Au cœur d'Istio, des proxys Envoy sont déployés en tant que sidecars à côté de chaque microservice :

Ce réseau de proxys forme le plan de données d'Istio, orchestré par le plan de contrôle :

L'adaptabilité d'Istio brille à travers une intégration fluide avec des systèmes externes de journalisation, de télémétrie et de politique.

5. Décryptage des Fondements d'Istio

L'architecture d'Istio est un duo dynamique : le plan de données et le plan de contrôle. Ensemble, ils orchestrent la magie derrière les capacités d'Istio. Plongeons dans les composants de base qui alimentent cette plateforme exceptionnelle.

Préparez-vous à explorer les détails complexes des composants de base d'Istio.

5.1. Le Plan de Données : L'Épicentre d'Envoy

Le plan de données d'Istio est essentiellement une version amplifiée du proxy Envoy. Ce prodige open-source gère les subtilités du réseau, libérant les applications pour qu'elles se concentrent sur leur cœur de métier. Les applications interagissent sans effort, inconscientes de la complexité de l'infrastructure réseau.

Au cœur d'Envoy se trouve un sorcier du réseau opérant aux couches 3 et 4 du modèle OSI. Il gère habilement les connexions grâce à une chaîne de filtres réseau adaptables. Au-delà, le filtre de couche L7 d'Envoy lui permet de gérer le trafic HTTP avec finesse. Et ce n'est pas tout – il excelle aussi avec les protocoles HTTP/2 et gRPC.

Bon nombre des fonctionnalités phares d'Istio sont en réalité des super-pouvoirs hérités des capacités intégrées d'Envoy :

• Contrôle du trafic : Envoy exerce un contrôle précis sur le trafic HTTP, gRPC, WebSocket et TCP, le routant avec précision.
• Résilience du réseau : Des tentatives automatiques, un coupe-circuit et une injection de pannes intégrés assurent une fiabilité réseau inébranlable.
• Sécurité : Protégez vos communications avec des politiques de sécurité robustes, un contrôle d'accès et une limitation du débit.

Le véritable potentiel d'Envoy brille lorsqu'il est associé à Istio. Son extensibilité, propulsée par WebAssembly, change la donne pour l'application de politiques personnalisées et la télémétrie. De plus, l'API Proxy-Wasm d'Istio ouvre la porte à encore plus de personnalisations d'Envoy.

5.2. Le Plan de Contrôle : Le Maestro d'Istiod

Rencontrez istiod, le chef d'orchestre du plan de contrôle d'Istio. Ce maestro transforme les règles de routage de haut niveau et les directives de gestion du trafic en configurations adaptées à Envoy, les distribuant sans effort aux sidecars.

Vous vous souvenez de l'ancienne architecture d'Istio avec ses composants distincts ? Eh bien, pour simplifier les choses, ces composants ont été fusionnés dans l'istiod unifié. Mais rassurez-vous, les fonctionnalités de base restent intactes.

Au cœur d'istiod se trouvent les mêmes codes et API que ses prédécesseurs. Pilot, par exemple, continue d'être le maestro de la découverte de services, traduisant les détails spécifiques à la plateforme en un langage universel compris par les sidecars. Cette flexibilité permet à Istio de s'harmoniser avec des environnements divers comme Kubernetes et les machines virtuelles.

Istiod prend également en charge la sécurité, établissant une authentification robuste entre services et utilisateurs finaux grâce à son système intégré de gestion des identités et des certificats. Appliquez facilement des politiques de sécurité granulaires basées sur l'identité des services. De plus, istiod agit comme une autorité de certification (CA) de confiance, délivrant des certificats pour sécuriser la communication entre les services via le TLS mutuel (MTLS).

6. Fonctionnement d'Istio

Nous avons exploré les fonctionnalités typiques d'un maillage de services et disséqué l'architecture et les composants de base d'Istio. Maintenant, découvrons comment Istio fournit ces fonctionnalités grâce à ses composants de base.

Nous revisiterons les mêmes catégories de fonctionnalités que nous avons explorées précédemment.

6.1. Gestion du Trafic

L'API de gestion du trafic d'Istio offre un contrôle granulaire sur le trafic du maillage de services. Personnalisez les configurations de trafic à l'aide de ces API et définissez les ressources API avec des définitions de ressources personnalisées Kubernetes (CRD). Les principales ressources API pour le routage du trafic sont les services virtuels et les règles de destination :

Un service virtuel dicte comment les requêtes sont acheminées vers un service au sein du maillage Istio. Il comprend une ou plusieurs règles de routage évaluées séquentiellement. Après le routage du service virtuel, les règles de destination sont appliquées pour contrôler le trafic vers une destination, comme le regroupement d'instances de service par version.

6.2. Sécurité

La fondation de la sécurité d'Istio repose sur des identités solides pour chaque service. Les agents Istio, aux côtés de chaque proxy Envoy, collaborent avec istiod pour automatiser la rotation des clés et des certificats :

Istio prend en charge deux types d'authentification : l'authentification pair-à-pair et l'authentification des requêtes. L'authentification pair-à-pair sécurise la communication entre services avec la solution TLS mutuel d'Istio. L'authentification des requêtes gère l'authentification des utilisateurs finaux via la validation de jetons Web JSON (JWT) en utilisant un fournisseur d'authentification personnalisé ou un fournisseur OpenID Connect (OIDC).

Istio applique le contrôle d'accès aux services en appliquant des politiques d'autorisation. Ces politiques régulent le trafic entrant dans le proxy Envoy, permettant un contrôle d'accès au niveau du maillage, de l'espace de noms et du service.

6.3. Observabilité

Istio génère une télémétrie complète, y compris des métriques, des traces distribuées et des journaux d'accès, pour toutes les communications de service au sein du maillage. Cette télémétrie comprend des métriques au niveau des proxys, orientées vers les services et au niveau du plan de contrôle.

Auparavant, Mixer était le composant central de l'architecture de télémétrie d'Istio. Cependant, la télémétrie v2 remplace les fonctionnalités de Mixer par des plugins de proxy Envoy :

Istio crée des traces distribuées via les proxys Envoy et prend en charge divers backends de traçage comme Zipkin, Jaeger, Lightstep et Datadog. Le taux d'échantillonnage de la génération de traces est configurable. De plus, Istio génère des journaux d'accès pour le trafic des services dans des formats personnalisables.

7. Plongez dans Istio

Assez de théorie, voyons Istio en action ! Nous allons installer Istio sur un cluster Kubernetes et utiliser une simple application de microservices pour démontrer sa puissance.

7.1 Installation

Istio peut être installé de différentes manières, mais télécharger et extraire la dernière version pour votre système d'exploitation (comme Windows) est le plus simple. Le package extrait inclut le client istioctl dans le dossier bin. Utilisez istioctl pour installer Istio sur votre cluster Kubernetes :

istioctl install --set profile=demo -y

kubectl label namespace default istio-injection=enabled

Nous utilisons ici kubectl, en supposant que vous ayez un cluster Kubernetes (comme Minikube) et que l'interface de ligne de commande Kubernetes kubectl soit configurée.

7.2 Application Exemple

Imaginez une simple application de commande en ligne pour cette démonstration. Elle se compose de trois microservices qui travaillent ensemble pour exécuter les commandes :

Nous n'entrerons pas dans les détails des microservices, mais ils sont faciles à créer avec Spring Boot et API REST. Il est essentiel de créer des images Docker pour ces microservices afin de les déployer sur Kubernetes.

7.3 Déploiement

Le déploiement de charges de travail conteneurisées sur des clusters Kubernetes comme Minikube est simple. Utilisez des ressources Deployment et Service pour déclarer et accéder à la charge de travail. Généralement, elles sont définies dans un fichier YAML :

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
      - name: order-service
        image: kchandrakant/order-service:v1
        resources:
          requests:
            cpu: 0.1
            memory: 200
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: order-service

kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml

Étant donné que nous avons activé l'injection automatique de proxys sidecar Envoy pour l'espace de noms par défaut, tout est pris en charge. Ou bien, injectez manuellement des proxys sidecar Envoy à l'aide de la commande kube-inject d'istioctl.

7.4 Accéder à l'Application

Istio gère principalement le trafic du maillage. Par défaut, le trafic entrant ou sortant du maillage est bloqué. Istio utilise des passerelles pour gérer le trafic entrant et sortant du maillage, vous donnant un contrôle précis sur ce qui entre ou sort. Istio propose des déploiements de passerelles proxy préconfigurés : istio-ingressgateway et istio-egressgateway.

Créez une Passerelle et un Service Virtuel pour votre application :

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: booking
spec:
  hosts:
  - "*"
  gateways:
  - booking-gateway
  http:
  - match:
    - uri:
        prefix: /api/v1/booking
    route:
    - destination:
        host: booking-service
        port:
          number: 8080

8 Cas d'Utilisation Courants d'Istio

Nous avons déployé une application simple sur Kubernetes avec Istio. Explorons les fonctionnalités puissantes d'Istio et voyons comment elles peuvent améliorer notre application.

8.1 Routage des Requêtes

Imaginez le déploiement de plusieurs versions d'un microservice comme le service d'expédition. Vous souhaitez introduire progressivement de nouvelles fonctionnalités sans impacter tous les utilisateurs. Le routage des requêtes vous permet de le faire en dirigeant une partie du trafic vers la dernière version.

Utilisezles règles de routage de services virtuels pour y parvenir.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: shipping-service
spec:
  hosts:
    - shipping-service
  http:
  - route:
    - destination:
        host: shipping-service
        subset: v1
      weight: 90
    - destination:
        host: shipping-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: shipping-service
spec:
  host: shipping-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Les règles de routage peuvent également filtrer le trafic en fonction des en-têtes ou d'autres attributs. Le champ destination spécifie le service cible pour les requêtes correspondantes.

8.2 Coupe-Circuit

Évitez les pannes en cascade avec des coupe-circuits. Ce modèle détecte les erreurs et arrête temporairement le trafic vers les services défaillants, protégeant ainsi la santé globale de votre application.

La DestinationRule d'Istio vous permet de configurer un comportement de coupe-circuit pour des services comme le service d'inventaire.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

En limitant le nombre maximum de connexions, les requêtes en attente et les requêtes par connexion, vous pouvez gérer efficacement le trafic et éviter les surcharges.

8.3 Activation du TLS Mutuel

Le TLS mutuel assure une communication sécurisée entre services en exigeant que les deux parties s'authentifient mutuellement. Istio active automatiquement le TLS mutuel pour les services utilisant ses proxys.

Bien qu'Istio impose le TLS mutuel entre les services proxys, le trafic en clair peut toujours atteindre les services sans proxy. Utilisez des politiques d'authentification pair-à-pair pour imposer le TLS mutuel dans tout votre maillage.

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

Vous pouvez appliquer le TLS mutuel au niveau du maillage, de l'espace de noms ou du service. Les politiques spécifiques à un service remplacent les paramètres au niveau de l'espace de noms.

8.4 Contrôle d'Accès avec JWT

Les Jetons Web JSON (JWT) sont une norme pour transmettre des informations utilisateur de manière sécurisée. Ils sont largement utilisés pour l'authentification et l'autorisation.

La AuthorizationPolicy d'Istio vous permet de contrôler l'accès aux services comme le service de réservation en fonction des revendications JWT.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: booking-service
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["[email protected]/[email protected]"]

Exigez des JWT valides avec des revendications spécifiques pour un accès autorisé. Istio crée un attribut requestPrincipal à partir des revendications issuer et subject du JWT.

9. Conclusion

Istio simplifie la gestion des défis courants dans les architectures microservices distribuées. Cependant, sa complexité peut ajouter des frais généraux aux déploiements. Comme tout outil, Istio n'est pas une solution magique et nécessite une réflexion approfondie.

9.1. Un Maillage de Services est-il Toujours Nécessaire ?

Bien que les maillages de services offrent des avantages, tenez compte de ces inconvénients :

Les maillages de services offrent des avantages, mais une évaluation attentive de la complexité de votre application est essentielle. Pesez les avantages par rapport à la complexité supplémentaire.

9.2. Alternatives à Istio

Istio est un maillage de services populaire soutenu par des leaders de l'industrie, mais ce n'est pas la seule option. Voici un bref aperçu de Linkerd et Consul.

Linkerd est un maillage de services natif de Kubernetes, open-source et en pleine popularité. Il s'agit d'un projet incubateur du CNCF et fonctionne de manière similaire à Istio, en utilisant des proxys TCP. Le micro-proxy basé sur Rust de Linkerd est appelé Linkerd-proxy.

Linkerd est généralement plus simple qu'Istio en raison de son orientation Kubernetes. Cependant, son ensemble de fonctionnalités ressemble étroitement à celui d'Istio, et son architecture de base est similaire. Linkerd se compose d'une interface utilisateur, d'un plan de données et d'un plan de contrôle.

Consul est un maillage de services open-source de HashiCorp qui s'intègre à d'autres outils d'infrastructure HashiCorp. Le plan de données de Consul prend en charge à la fois les modèles d'intégration par proxy et natifs. Il propose un proxy intégré mais peut également fonctionner avec Envoy.

Consul fonctionne au-delà de Kubernetes, prenant en charge des plateformes comme Nomad. Il utilise des agents sur chaque nœud pour les vérifications de santé et communique avec des serveurs Consul pour le stockage et la réplication des données. Bien qu'offrant des fonctionnalités standard de maillage de services, Consul est plus complexe à déployer et à gérer.

10. Conclusion

Ce tutoriel a exploré les bases de l'architecture de maillage de services et les puissantes capacités d'Istio. Nous avons approfondi la structure, les composants et les applications pratiques d'Istio. À la fin, vous devriez avoir une solide compréhension de l'installation et de l'utilisation d'Istio pour des scénarios courants.