: Remarque : Ce guide n'est compatible qu'avec les API Cloud Service Mesh avec Istio et n'est pas compatible avec les API Google Cloud. Pour en savoir plus, consultez la page Présentation de Cloud Service Mesh . Cette page s'applique aux implémentations de plan de contrôle dans le cluster et ISTIOD gérées.
Cette page ne s'applique pas à l'implémentation du plan de contrôle TRAFFIC_DIRECTOR, qui est un plan de contrôle global mutualisé sans révisions individuelles.
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.
Principes fondamentaux de l'installation d'un maillage de services
De manière générale, l'installation de Cloud Service Mesh comprend deux phases principales:
Utilisez d'abord l'outil asmcli pour installer un plan de contrôle dans le cluster ou configurer le plan de contrôle géré .
Le plan de contrôle consiste en un ensemble de services système chargés de gérer la configuration du maillage.
Ensuite, vous déployez un proxy side-car spécial dans votre environnement afin d'intercepter les communications 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é l'injection side-car automatique (ou injection automatique)
Utilisez les révisions pour mettre à jour votre réseau en toute sécurité
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.
Remarque : Un autre type de mise à niveau consiste en une mise à niveau sur place , dans laquelle vous effectuez une mise à niveau en installant une nouvelle version du plan de contrôle. La nouvelle version du plan de contrôle remplace immédiatement l'ancienne. Les mises à niveau sur place sont risquées, 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. À l'aide des révisions du plan de contrôle dans une mise à niveau Canary, vous installez un nouveau plan de contrôle indépendant, et la configuration associée, parallèlement au plan de contrôle existant.
Le programme d'installation attribue une chaîne appelée "révision" pour identifier le nouveau plan de contrôle. Dans un premier temps, les proxys sidecar continuent de recevoir la configuration de la version précédente du plan de contrôle. Associez progressivement les charges de travail au nouveau plan de contrôle en étiquetant leurs espaces de noms ou pods avec la nouvelle révision du plan de contrôle. Une fois que vous avez étiqueté un espace de noms ou des pods avec la nouvelle révision, vous redémarrez les pods de la charge de travail afin que les nouveaux side-cars soient automatiquement injectés et qu'ils reçoivent leur configuration du nouveau plan de contrôle. En cas de problèmes, vous pouvez facilement effectuer un rollback en associant les charges de travail au plan de contrôle d'origine.
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 le plan de contrôle 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.
Une configuration de 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 inject fourni par le plan de contrôle modifie les spécifications du pod pour injecter automatiquement 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. Une étiquette est essentiellement une paire clé-valeur qui peut être utilisée pour accepter le concept de l'étiquetage. Les étiquettes sont largement utilisées pour l'ajout de tags et pour les révisions. Par exemple, des balises Git, des balises Docker et des révisions Knative .
Le processus d'installation actuel de Cloud Service Mesh vous permet d'ajouter une étiquette au plan de contrôle installé avec une chaîne de révision. Le programme d'installation attribue un libellé de révision à chaque objet du plan de contrôle. La clé dans la paire clé/valeur est istio.io/rev, mais la valeur de l'étiquette de révision diffère pour le plan de contrôle géré et les plans de contrôle au sein du cluster.
Pour les plans de contrôle au sein du cluster, le service et le déploiement istiod ont généralement un libellé de révision semblable à istio.io/rev=, où istiod-.istio-system.
Pour le plan de contrôle géré, l'étiquette de révision correspond à un canal de publication :
Libellé de révision
Canal
istio.io/rev=asm-managedStandard
istio.io/rev=asm-managed-rapidVersion précoce
istio.io/rev=asm-managed-stableStable
En outre, vous avez la possibilité d'utiliser les étiquettes d'injection par défaut (par exemple, istio-injection=enabled).
Pour activer l'injection automatique, vous ajoutez à vos espaces de noms un libellé de révision correspondant au libellé de révision sur le plan de contrôle. Par exemple, un plan de contrôle avec la révision istio.io/rev= sélectionne les pods des espaces de noms portant le libellé istio.io/rev= et injecte les side-cars.
Processus de mise à niveau Canary
Les libellés de révision permettent d'effectuer des mises à niveau Canary et de faciliter les rollbacks du plan de contrôle au sein du cluster. Le contrôle géré utilise un processus semblable, mais votre cluster est automatiquement mis à niveau vers la dernière version au sein de ce canal.
Les étapes suivantes décrivent le déroulement du processus :
Commencez par une installation Cloud Service Mesh ou 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 namespaceSelector configuré 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 Cloud 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 le guide de mise à niveau .
Gros plan sur une configuration de webhook à mutation
Pour mieux comprendre le webhook à mutation utilisé pour l'injection side-car automatique, inspectez vous-même la configuration. 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:
-
Le sélecteur peut varier en fonction de la version de Cloud 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-
namespace: istio-system
path: /inject
port: 443
Remarque :Pour le maillage de services Cloud géré, le service géré par Google est spécifié par url: au lieu de service:. Le service est exposé par le plan de contrôle 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: '*'
Étapes suivantes
