Cette page décrit le fonctionnement des révisions du plan de contrôle et leur utilisation pour les mises à niveau et les rollbacks sécurisés du maillage de services. Jusqu'à la version 1.6.8, le processus d'installation par défaut d'Anthos Service Mesh n'utilisait pas de révisions de plan de contrôle. L'introduction des révisions peut nécessiter des efforts et des modifications de vos procédures d'installation, mais nous vous recommandons vivement de les utiliser, car elles offrent des avantages considérables.
Principes de base du maillage de services
L'installation d'Anthos Service Mesh comprend deux parties principales : tout d'abord, vous installez le plan de contrôle et sa configuration à l'aide de l'outil de ligne de commande Istioctl et les fichiers YAML IstioOperator. Le plan de contrôle (également appelé istiod) consiste en un ensemble de services système chargés de gérer la configuration du réseau maillé. Ensuite, vous déployez un proxy side-car spécial dans votre environnement qui intercepte la communication réseau vers et depuis chaque charge de travail. Les proxys communiquent avec le plan de contrôle pour obtenir leur configuration, ce qui vous permet de diriger et de contrôler le trafic (trafic du plan de données) autour de votre maillage sans modifier vos charges de travail.
Pour déployer les proxys, vous devez utiliser un processus appelé injection side-car automatique (injection automatique) pour exécuter un proxy en tant que conteneur side-car supplémentaire dans chacun de vos pods de charge de travail. Vous n'avez pas besoin de modifier les fichiers manifestes Kubernetes que vous utilisez pour déployer vos charges de travail, mais vous devez ajouter un libellé à vos espaces de noms et redémarrer les pods.
Avant la mise à niveau vers Anthos Service Mesh 1.6, vous avez installé une nouvelle version du plan de contrôle qui a immédiatement remplacé l'ancienne. Cette procédure, appelée mise à niveau sur place, est risquée, car le rollback peut être difficile en cas d'échec. Pour réinjecter les proxys et faire en sorte qu'ils communiquent avec la nouvelle version du plan de contrôle, vous devez redémarrer toutes les charges de travail dans tous vos espaces de noms. Selon le nombre de charges de travail et d'espaces de noms dans votre maillage, l'ensemble du processus de mise à niveau peut prendre une heure ou plus. Les mises à niveau sur place peuvent entraîner des temps d'arrêt et doivent être planifiées dans des intervalles de maintenance.
Comment fonctionne l'injection automatique ?
L'injection automatique utilise une fonctionnalité Kubernetes appelée contrôle d'admission. Un webhook à mutation est enregistré pour surveiller les pods nouvellement créés. Le webhook est configuré avec un sélecteur d'espaces de noms de sorte qu'il ne corresponde qu'aux pods en cours de déploiement dans les espaces de noms portant un libellé particulier. Lorsqu'un pod correspond, le webhook consulte un service d'injection fourni par Istiod pour obtenir une nouvelle configuration mutée pour le pod, qui contient les conteneurs et les volumes nécessaires à l'exécution du side-car.
- La configuration du webhook est créée lors de l'installation. Le webhook est enregistré auprès du serveur d'API Kubernetes.
- Le serveur d'API Kubernetes recherche les déploiements de pods dans les espaces de noms qui correspondent au webhook
namespaceSelector. - Un espace de noms est étiqueté de manière à être mis en correspondance par
namespaceSelector. - Les pods déployés sur l'espace de noms déclenchent le webhook.
- Le service
injectfourni par istiod modifie les spécifications du pod pour injecter le side-car.
Qu'est-ce qu'une révision ?
Le libellé utilisé pour l'injection automatique est semblable à n'importe quel autre libellé Kubernetes défini par l'utilisateur. Un libellé est essentiellement une paire clé-valeur pouvant être utilisée pour illustrer le concept d'ajout de tags. Les libellés sont couramment utilisés pour l'ajout de tags et pour les révisions. Cela inclut par exemple les tags Git, les tags Docker et les révisions Knative.
Jusqu'à Anthos Service Mesh version 1.6.8, la procédure d'installation par défaut comportait une convention faisant appel au libellé istio-injection=enabled pour configurer le sélecteur d'espaces de noms dans le webhook.
Le processus d'installation actuel d'Anthos Service Mesh vous permet d'ajouter un tag au plan de contrôle installé avec une chaîne de révision, à la fois en tant qu'argument revision vers les commandes istioctl et en tant que champ dans l'objet personnalisé IstioOperator. La clé de libellé correspondante pour les espaces de noms est istio.io/rev et la valeur est généralement définie pour indiquer la version du maillage. Par exemple, un plan de contrôle avec la révision asm-173-6 sélectionne les pods des espaces de noms portant l'étiquette istio.io/rev=asm-173-6 et injecte les side-cars.
Pourquoi les révisions sont-elles importantes ?
La possibilité de contrôler le trafic est l'un des principaux avantages de l'utilisation d'un maillage de services. Par exemple, vous pouvez transférer progressivement le trafic vers une nouvelle version d'une application lorsque vous la déployez pour la première fois en production. Si vous rencontrez des problèmes lors de la mise à niveau, vous pouvez revenir au trafic vers la version d'origine, ce qui offre un moyen simple et à faible risque d'effectuer un rollback. Cette procédure est appelée version Canary et réduit considérablement le risque associé aux nouveaux déploiements.
De même, vous pouvez minimiser le risque associé à la mise à niveau du maillage de services proprement dit. Anthos Service Mesh 1.6 et versions ultérieures sont compatibles avec les mises à niveau Canary à l'aide de révisions du plan de contrôle. Lorsque vous installez une nouvelle version du plan de contrôle, vous fournissez une chaîne de révision. Le programme d'installation attribue un libellé à chaque objet du plan de contrôle, y compris le composant istiod Service et Déploiement. La révision fait partie du nom du service, par exemple, istiod-asm-173-6.istio-system.
Avec une mise à niveau Canary, vous déployez une nouvelle révision du plan de contrôle à côté de la version existante. Vous associez ensuite progressivement les proxys au nouveau plan de contrôle en attribuant un libellé à vos espaces de noms avec une révision correspondant à la nouvelle révision du plan de contrôle. En cas de problème, vous pouvez facilement effectuer un rollback en associant les proxys de service à la révision précédente.
Processus de mise à niveau Canary
Les libellés de révision permettent d'effectuer des mises à niveau Canary et de faciliter les rollbacks lors du plan de contrôle.
Les étapes suivantes décrivent le déroulement du processus :
- Commencez avec une installation Anthos Service Mesh ou une installation Istio Open Source existante. Peu importe si les espaces de noms utilisent un libellé de révision ou le libellé
istio-injection=enabled. - Utilisez une chaîne de révision lorsque vous installez la nouvelle version du plan de contrôle. En raison de la chaîne de révision, le nouveau plan de contrôle est installé avec la version existante. La nouvelle installation inclut une nouvelle configuration de webhook avec un
namespaceSelectorconfiguré pour surveiller les espaces de noms avec ce libellé de révision spécifique. - Vous migrez les proxys side-car vers le nouveau plan de contrôle en supprimant l'ancien libellé de l'espace de noms, en ajoutant le nouveau libellé de révision, puis en redémarrant les pods. Si vous utilisez des révisions avec Anthos Service Mesh, vous devez cesser d'utiliser le libellé
istio-injection=enabled. Un plan de contrôle avec une révision ne sélectionne pas les pods des espaces de noms portant le libelléistio-injection, même s'il existe un libellé de révision. Le webhook du nouveau plan de contrôle injecte les side-cars dans les pods. - Testez soigneusement les charges de travail associées au plan de contrôle mis à niveau, puis continuez à déployer la mise à niveau ou effectuez un rollback vers le plan de contrôle d'origine.
Une fois les pods associés au nouveau plan de contrôle, le plan de contrôle et le webhook existants sont toujours installés. L'ancien webhook n'a aucun effet sur les pods des espaces de noms qui ont été migrés vers le nouveau plan de contrôle. Vous pouvez restaurer les pods d'un espace de noms dans le plan de contrôle d'origine en supprimant le nouveau libellé de révision, en ajoutant le libellé d'origine et en redémarrant les pods. Lorsque vous êtes sûr que la mise à niveau est terminée, vous pouvez supprimer l'ancien plan de contrôle.
Pour connaître les étapes détaillées de la mise à niveau à l'aide de révisions, consultez les guides de mise à niveau.
Gros plan sur une configuration de webhook à mutation
La meilleure façon de comprendre le webhook à mutation pour l'injection automatique de side-car est d'inspecter la configuration vous-même. Exécutez la commande suivante :
kubectl -n istio-system get mutatingwebhookconfiguration -l app=sidecar-injector -o yaml
Une configuration distincte doit s'afficher pour chaque plan de contrôle que vous avez installé. Un sélecteur d'espace de noms pour un plan de contrôle basé sur les révisions ressemble à ceci :
namespaceSelector:
matchExpressions:
- key: istio-injection
operator: DoesNotExist
- key: istio.io/rev
operator: In
values:
- asm-173-6
Le sélecteur peut varier en fonction de la version d'Anthos Service Mesh ou d'Istio que vous exécutez. Ce sélecteur fait correspondre les espaces de noms à un libellé de révision spécifique, à condition qu'ils ne possèdent pas également de libellé istio-injection.
Lorsqu'un pod est déployé dans un espace de noms correspondant au sélecteur, sa spécification de pod est envoyée au service d'injecteur pour la mutation. Le service d'injecteur à appeler est spécifié comme suit :
service:
name: istiod-asm-173-6
namespace: istio-system
path: /inject
port: 443
Le service est exposé par istiod sur le port 443 au chemin d'URL inject.
La section rules indique que le webhook doit s'appliquer à la création de pod :
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
resources:
- pods
scope: '*'
Résumé
Même si passer à l'utilisation de libellés de révision sur vos espaces de noms pour permettre l'injection automatique vous demande un certain temps d'adaptation, les avantages en termes de mises à niveau Canary sécurisées qu'offrent les libellés de révision en valent largement la peine.