Istio est un maillage de services indépendant open source qui vous fournit les bases nécessaires pour exécuter avec succès une architecture de microservices distribués. Istio réduit la complexité de la gestion des déploiements de microservices en fournissant un moyen uniforme de sécuriser, connecter et surveiller les microservices. Istio facilite la création d’un réseau de services déployés avec équilibrage de charge, authentification de service à service, surveillance et plus encore, avec peu ou pas de changements de code dans le code de service.
Vous ajoutez le support Istio aux services en déployant un proxy sidecar spécial dans votre environnement qui intercepte toutes les communications réseau entre les microservices, puis configurez et gérez Istio en utilisant sa fonctionnalité de plan de contrôle.
La formation Istio utilisera les dernières versions stables en date du projet.
Résumé
Logiciel : Istio
Durée : 3 jours, 21 heures
Objectifs :
– équilibrer automatiquement la charge pour le trafic HTTP, gRPC, WebSocket et TCP.
– contrôler avec précision le comportement du trafic grâce à des règles de routage riches, des tentatives de reprise, des basculements et des injections de défauts.
– maîtriser la couche de stratégie et une API de configuration enfichable prenant en charge les contrôles d’accès, les limites de débit et les quotas.
– lire les métriques, journaux et traces automatiques pour tout le trafic au sein d’un cluster, y compris les entrées et sorties du cluster.
– configurer la communication sécurisée de service à service dans un cluster avec authentification et autorisation basées sur une identité forte.
– assurer l’extensibilité et répondre à divers besoins de déploiement.
Public : développeurs Web, chefs de projet & informaticiens
Prérequis : avoir suivi les formations Kubernetes & Kubernetes Advanced. Bonne connaissances de base d’un système Unix et du fonctionnement des conteneurs
Méthodes mobilisées : 65% de pratique, 35% de héorie. Support de la formation distribué au format numérique à tous les participants. Le cours alterne les apports théoriques du formateur soutenus par des exemples et des séances de réflexions, et de travail en groupe.
Modalités et délais d’accès : sur inscription préalable au minimum 1 semaine avant le début de la formation selon les disponibilités du formateur.
Modalités d’évaluations : une évaluation du niveau des stagiaires est réalisée avant l’entrée en formation par téléphone ou au moyen d’un questionnaire. À la fin de la session, un questionnaire à choix multiples permet de vérifier l’acquisition correcte des compétences. Évaluation des acquis et de la satisfaction en fin de formation. Une attestation sera remise à chaque stagiaire qui aura suivi la totalité de la formation.
Accessibilité aux personnes en situation de handicap ou présentant des difficultés d’apprentissage : nous pouvons proposer des solutions de compensation de nos prestations en adaptant les moyens pédagogiques, techniques et d’encadrement (les précisions).
Taux de satisfaction 2i2L : 96 % des stagiaires sont satisfaits à l’issue de leur formation.
Tarif : pour une demande de formation interne, nous consulter.
Programme
Jour 1 - Concepts Fondamentaux et Théorie
Cette section pose les bases pour comprendre pourquoi un Service Mesh est nécessaire.
Définitions
– Le Problème du Réseau Microservices : Pourquoi la communication devient complexe.
– Introduction au Service Mesh : La couche d’infrastructure dédiée à la communication service-à-service.
– Sidecar Pattern : Le concept clé d’Istio (Proxies Envoy).
– Plan de Contrôle (Pilot, Citadel, Galley) vs. Plan de Données (Proxies Envoy).
Rappels Kubernetes
– Pods, Services, Deployments : Les primitives de base gérées par le Mesh.
– Ingress vs. Gateway : Différence et rôle de l’Istio Gateway.
– Custom Resource Definitions (CRDs) : Le fonctionnement d’Istio comme extension de l’API Kubernetes.
Helm
– Gestion de paquets pour Kubernetes : Simplifier l’installation d’applications complexes.
– Utilisation des Charts Helm pour l’installation d’Istio.
– Personnalisation et surcharges (values.yaml).
– Le modèle GitOps
– Définition : L’infrastructure et les configurations déclarées dans Git sont la source unique de vérité.
– Outils clés (ArgoCD, Flux) : Lier les configurations Istio à un workflow GitOps.
– Avantage : Assurer la traçabilité et la réversibilité des changements de trafic.
Microservices - 12 facteurs
– Rappel des principes de conception des microservices (ex. : Backing Services, Logs, Admin Processes).
– Comment Istio répond aux facteurs 8 (Concurrency), 10 (Dev/Prod Parity) et 12 (Admin Processes).
Service Mesh
– Fonctionnalités clés : Résilience, Observabilité, Sécurité (mTLS).
– Istio vs. autres (Linkerd, Consul Connect) : Les différences et le positionnement d’Istio.
Anthos (si utilisation de GCP)
– GKE Enterprise (nom actuel d’Anthos) : La plateforme multi-cloud de Google.
– Intégration native d’Istio : Comment Anthos simplifie la gestion et la cohérence des Service Meshes sur différents clusters.
Mise en service et Outils (LAB)
Cette section couvre l’installation des composants et l’introduction aux outils de visualisation.
Installation, pré-requis (LAB)
– Vérification des pré-requis Kubernetes (versions, CNI).
– Installation de l’outil istioctl.
– Utilisation de Helm ou du profil d’installation d’Istio (istioctl install).
– Injection du Sidecar : Automatique (annotation de namespace) vs. Manuelle.
Configuration (LAB)
– Déploiement d’une application de test simple (ex. : helloworld).
– Vérification de l’injection du Proxy Envoy dans le Pod.
– Exposition de l’application via l’Istio Gateway et le VirtualService.
Kiali (LAB)
– Installation et accès à l’interface utilisateur.
– Visualisation du Graphique du service mesh (Service Graph).
– Comprendre le statut de santé des services.
– Observabilité : Accès aux métriques, traces et logs (intégration avec Prometheus/Grafana/Jaeger).
Istioctl
– Commandes essentielles pour le dépannage (istioctl proxy-status, istioctl analyze).
– Utilisation de istioctl experimental dashboard pour un accès rapide aux outils.
Traffic Management (LABS)
Cette section est le cœur pratique, montrant comment Istio gère le trafic.
A/B Routing
– Définition du DestinationRule (règles de sous-ensembles/versions).
– Utilisation du VirtualService pour diriger un pourcentage spécifique du trafic vers une version donnée.
– Objectif : Tests de performance discrets et mise en production progressive.
Blue/Green Deployment
– Définition : Déployer la nouvelle version à côté de l’ancienne, puis basculer 100% du trafic d’un coup.
– Mise en œuvre via l’ajustement du poids dans le VirtualService.
– Avantage : Rollback instantané si la nouvelle version échoue.
Chaos Engineering
– Injection de tolérance aux pannes via le VirtualService.
– Ajout de retards (Delays) et d’erreurs (Faults) ciblés.
– Objectif : Tester la résilience du système en simulant des pannes réelles.
Circuit Breaking
– Configuration des limites de connexion et des tentatives dans le DestinationRule.
– Objectif : Isoler les défaillances pour éviter qu’un service défectueux ne submerge un autre.
– Comprendre la différence entre un Circuit Breaker et un Timeout.
Timeouts
– Définition des délais de réponse dans le VirtualService.
– Objectif : Libérer les ressources plus rapidement en cas de service lent ou bloqué.
Mirroring
– Définition : Envoyer une copie en direct (sans impacter le client) du trafic de production vers un service en pré-production.
– Utilisation : Tester une nouvelle version avec des charges de travail réelles sans risque.
– Considérations : Comment gérer les effets secondaires de l’écriture ou de l’état.
Jour 2 - Sécurité (LABS)
Cette section se concentre sur l’activation des fonctionnalités de sécurité cruciales offertes par Istio pour le trafic de service à service.
Les certificats
– Comprendre les PKI et X.509 : Rappel sur la cryptographie asymétrique et le format des certificats numériques.
– Istio Citadel (ou Istiod) : Définition du composant responsable de la gestion de l’identité des workloads (charges de travail).
– Certificats SPIFFE : Comprendre comment Istio génère et distribue automatiquement des certificats de courte durée pour chaque service/pod, basés sur la spécification SPIFFE.
Authentification
– mTLS (Mutual TLS) : Configuration de l’authentification mutuelle (bidirectionnelle) entre les services via la ressource PeerAuthentication.
– Mode STRICT : Application du mTLS obligatoire pour tout le trafic au sein du mesh.
– JWT Authentication : Configuration de l’authentification des utilisateurs finaux ou des applications externes via des jetons JSON Web Token à l’entrée du mesh.
Authorization
– Ressource AuthorizationPolicy : Définir qui est autorisé à faire quoi.
– Règles de PÉRIMÈTRE : Définir l’accès basé sur l’identité (SPIFFE) ou des attributs (principaux, sources) au niveau du service.
– Règles de REQUÊTE : Définir l’accès basé sur les méthodes HTTP, les chemins (/admin), ou les en-têtes.
Configuration TLS
– TLS Ingress : Configuration de la terminaison TLS sur l’Istio Gateway pour le trafic entrant (externe).
– Secrets Kubernetes : Utilisation des secrets pour stocker les clés privées et les certificats publics utilisés par l’Ingress Gateway.
Rate Limiting
– Objectif : Protéger les services contre les attaques par déni de service (DoS) ou les surcharges.
– Configuration : Mise en place de règles de limitation du taux de requêtes (par seconde, par utilisateur, ou par attribut) via des extensions ou des contrôleurs externes/natifs d’Istio.
Observabilité (LABS)
Cette section couvre les outils intégrés à Istio pour la collecte et la visualisation des données opérationnelles.
– Métriques, Logs, Traces distribuées...
Istio Avancé
Cette section explore des cas d’utilisation complexes et des configurations avancées pour répondre à des besoins spécifiques.
– Ingress/EgressGateways, TLS Originating, Multi-cluster Mesh...
Module Complémentaire
– WebAssembly (Wasm) Extensions, Opérateur Istio...
Jour 3 - Révision
– Revue succincte des éléments clés des deux premières journées
Astuces et Stratégies avec Istio
Optimisation et Performances
– Minimiser l’Overhead du Sidecar (filtrage envoy, optimisation et dimensionnement du control plane
– Utilisation Stratégique du mTLS progressivement, envisager son offload
Dépannage et Debug
– Utiliser istioctl analyze pour la validation préventive et le diagnostic des configurations.
– Inspecter le Proxy Envoy et accès aux endpoints d’administration
– Appliquer la "Règle des Trois C" pour les problèmes de trafic
Bonnes Pratiques de Production
– Gestion des Dépendances Externes (Egress).
– Versioning des Configurations via GitOps (ArgoCD, Flux) pour l’audit et le rollback.
– Isolation par Namespace (AuthorizationPolicy)
– Utilisation de Kiali pour l’Audit et le Suivi.