TLDR
Outre ce que j'ai mentionné dans les commentaires, après une vérification plus détaillée du sujet, je choisirais approche 2 avec un total de Service virtuel pour un microservice spécifique avec déploiement des canaris y miroir .
Approche 1
Comme mentionné dans documentation
Dans les situations où il n'est pas pratique de définir l'ensemble complet de règles ou de politiques de routage pour un hôte particulier dans une seule ressource VirtualService ou DestinationRule, il peut être préférable de spécifier de manière incrémentielle la configuration de l'hôte dans plusieurs ressources. Pilot fusionnera de telles règles de destination et fusionnera de tels services virtuels s'ils sont liés à une passerelle.
Ainsi, en théorie vous pourriez opter pour l'approche numéro 1, mais je dirais qu'il y a trop de configuration avec cela et qu'il y a une meilleure idée pour faire cela.
Disons que vous avez une ancienne application dont le nom est v1.3.1 et une nouvelle application avec le nom v1.4.0 Ainsi, un service virtuel approprié ressemblerait à ce qui suit.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: vs-vervice1
spec:
hosts:
- '*'
http:
- name: "v1.3.1"
route:
- destination:
host: service1.namespace.svc.cluster.local
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: vs-service2
spec:
hosts:
- '*'
http:
- name: "v1.4.0"
route:
- destination:
host: service2.namespace.svc.cluster.local
Approche 2
Sur pratiquer J'opterais pour l'approche numéro 2, par exemple vous pouvez créer 2 versions de votre application, dans l'exemple ci-dessous c'est old y new et ensuite configurer le service virtuel et les règles de destination pour celui-ci.
La question qui se pose ici est : pourquoi ? Parce que c'est plus facile à gérer, du moins pour moi, et qu'il est facile d'utiliser le déploiement canari et la mise en miroir ici, plus d'informations à ce sujet ci-dessous.
Disons que vous avez déployé une nouvelle application, vous ne voulez pas envoyer 1% du trafic entrant ici, en plus vous pouvez utiliser le miroir, ainsi chaque requête qui va vers l'ancien service sera reflétée vers le nouveau service à des fins de test.
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: vs-vervice
spec:
hosts:
- '*'
http:
- name: "old"
route:
- destination:
host: service.namespace.svc.cluster.local
subset: v1
weight: 99
mirror:
host: service.namespace.svc.cluster.local
subset: v2
mirror_percent: 100
- name: "new"
route:
- destination:
host: service.namespace.svc.cluster.local
subset: v2
weight: 1
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews-destination
spec:
host: service.namespace.svc.cluster.local
subsets:
- name: v1
labels:
version: v1 <--- label on old pod
- name: v2
labels:
version: v2 <--- label on new pod
Test d'une nouvelle application
Le client doit évidemment préciser à quelle version majeure il souhaite s'adresser, soit en définissant un en-tête, soit en résolvant un nom de service différent.
En fait, cela dépend de la configuration, si vous utilisez l'option ci-dessus avec l'option new y old alors c'est à cela que sert le déploiement canari, par exemple la distribution pondérée. Vous pouvez spécifier le pourcentage du trafic qui doit être envoyé à la nouvelle version de votre application. Bien sûr, vous pouvez spécifier des en-têtes ou des préfixes dans votre service virtuel afin que les utilisateurs puissent utiliser une version plus ancienne ou plus récente de votre application.
Déploiement de Canary
Comme indiqué aquí
L'un des avantages du projet Istio est qu'il fournit le contrôle nécessaire au déploiement de services canariens. L'idée derrière le déploiement canari (ou rollout) est d'introduire une nouvelle version d'un service en la testant d'abord en utilisant un petit pourcentage du trafic utilisateur, puis si tout va bien, d'augmenter, éventuellement progressivement par incréments, le pourcentage tout en supprimant l'ancienne version. Si quelque chose ne va pas en cours de route, on abandonne et on revient à la version précédente. Dans sa forme la plus simple, le trafic envoyé à la version canari est un pourcentage de demandes choisi au hasard, mais dans des schémas plus sophistiqués, il peut être basé sur la région, l'utilisateur ou d'autres propriétés de la demande.
En fonction de votre niveau d'expertise dans ce domaine, vous vous demanderez peut-être pourquoi la prise en charge du déploiement canari par Istio est même nécessaire, étant donné que des plateformes comme Kubernetes offrent déjà un moyen de procéder au déploiement de versions et au déploiement canari. Problème résolu, non ? Eh bien, pas exactement. Bien que cette méthode de déploiement fonctionne dans des cas simples, elle est très limitée, en particulier dans les environnements en nuage à grande échelle recevant beaucoup de trafic (et surtout des quantités variables), où l'autoscaling est nécessaire.
istio
Avec Istio, l'acheminement du trafic et le déploiement des répliques sont deux fonctions totalement indépendantes. Le nombre de pods mettant en œuvre les services est libre d'augmenter ou de diminuer en fonction de la charge de trafic, de manière totalement orthogonale au contrôle de l'acheminement du trafic de la version. Cela fait de la gestion d'une version canari en présence d'une mise à l'échelle automatique un problème beaucoup plus simple. Les autoscalers peuvent, en fait, répondre aux variations de charge résultant des changements de routage du trafic, mais ils fonctionnent néanmoins de manière indépendante et pas différemment que lorsque les charges changent pour d'autres raisons.
Les règles de routage d'Istio offrent également d'autres avantages importants ; vous pouvez facilement contrôler des pourcentages de trafic à grain fin (par exemple, acheminer 1 % du trafic sans avoir besoin de 100 pods) et vous pouvez contrôler le trafic en utilisant d'autres critères (par exemple, acheminer le trafic pour des utilisateurs spécifiques vers la version canari). Pour illustrer, regardons le déploiement du service helloworld et voyons à quel point le problème devient simple.
Il existe un exemple .
Miroir
La deuxième chose souvent utilisée pour tester une nouvelle version de l'application est la mise en miroir du trafic.
Comme indiqué aquí
Avec Istio, vous pouvez utiliser la mise en miroir du trafic pour dupliquer le trafic vers un autre service. Vous pouvez intégrer une règle de mise en miroir du trafic dans un pipeline de déploiement canari, ce qui vous permet d'analyser le comportement d'un service avant de lui envoyer du trafic en direct.
Si vous recherchez les meilleures pratiques, je vous recommande de commencer par ceci tutoriel sur medium, car c'est très bien expliqué ici.
Comment fonctionne le Traffic Mirroring
La mise en miroir du trafic fonctionne selon les étapes suivantes :
-
Vous déployez une nouvelle version de l'application et mettez en route le trafic trafic.
-
L'ancienne version répond aux demandes comme auparavant mais envoie également une copie asynchrone à la nouvelle version.
-
La nouvelle version traite le trafic mais ne répond pas à l'utilisateur.
-
L'équipe des opérations surveille la nouvelle version et signale tout problème à l'équipe de développement.
![enter image description here]()
Comme l'application traite le trafic en direct, cela permet à l'équipe de découvrir des problèmes qu'elle ne trouverait généralement pas dans un environnement de pré-production. Vous pouvez utiliser des outils de surveillance, tels que Prometheus et Grafana, pour enregistrer et surveiller les résultats de vos tests.
De plus, il existe un exemple avec nginx qui montre parfaitement comment cela doit fonctionner.
Il convient de mentionner que si vous utilisez des API d'écriture, comme la commande ou le paiement, alors le trafic en miroir signifiera écrire plusieurs fois des API comme la commande. Ce sujet est décrit en détail aquí par Christian Posta.
Faites-moi savoir s'il y a quelque chose de plus dont vous voulez discuter.
