Conseils de migration pour les configurations Open Service Mesh (OSM) vers Istio

Article
06/02/2023

Important

Cet article vise à fournir une compréhension élémentaire de l’identification des configurations OSM et de leur conversion en leurs équivalents Istio pour la migration des charges de travail depuis OSM vers Istio. Il ne s’agit en aucun cas d’un guide détaillé exhaustif.

Cet article fournit des conseils pratiques pour mapper les stratégies OSM sur les stratégies Istio afin de faciliter la migration de vos déploiements de microservices en vue de leur gestion par Istio plutôt que par OSM. Nous utilisons l’exemple d’application Bookstore d’OSM comme référence de base pour les utilisateurs OSM actuels. La procédure suivante déploie l’application Bookstore. Les mêmes étapes sont suivies pour expliquer comment appliquer les stratégies de trafic SMI OSM en utilisant l’équivalent Istio.

Si vous n’utilisez pas OSM et que vous débutez avec Istio, commencez par consulter le guide de démarrage d’Istio afin d’apprendre à utiliser le maillage de services Istio pour vos applications. Si vous utilisez OSM, assurez-vous d’être familiarisé avec la procédure de l’exemple d’application Bookstore d’OSM sur la façon dont OSM configure les stratégies de trafic. La procédure suivante ne duplique pas la documentation actuelle et référence des rubriques spécifiques quand cela est pertinent. Vous devez être à l’aise et avoir une bonne connaissance de l’architecture de l’application bookstore avant de continuer.

Prérequis

Un abonnement Azure. Si vous n’avez pas d’abonnement Azure, vous pouvez créer un compte gratuit.
Azure CLI.
Le module complémentaire OSM AKS est désinstallé de votre cluster AKS
Toute application Bookstore d’OSM existante, y compris les espaces de noms, est désinstallée et supprimée de votre cluster
Installer le module complémentaire de maillage de services Istio AKS

Modifications à apporter à l’exemple d’application Bookstore d’OSM

Pour permettre à Istio de gérer l’application bookstore d’OSM, quelques modifications sont nécessaires dans les manifestes existants. Ces modifications concernent les services bookstore et mysql.

Modifications de Bookstore

Dans la procédure Bookstore d’OSM, le service bookstore est déployé avec un autre service bookstore-v2 pour montrer comment OSM assure le déplacement du trafic. Ces services déployés vous permettaient de diviser le trafic client (bookbuyer) entre plusieurs points de terminaison de service. Le premier nouveau concept à comprendre concerne la façon dont Istio gère le « déplacement du trafic ».

L’implémentation OSM du déplacement du trafic est basée sur la spécification SMI Traffic Split. La spécification SMI Traffic Split nécessite l’existence de plusieurs services de niveau supérieur qui sont ajoutés en tant que back-ends avec la métrique de pondération souhaitée pour déplacer les demandes client d’un service à un autre. Istio effectue le déplacement du trafic en utilisant une combinaison d’un service virtuel et d’une règle de destination. Nous vous recommandons vivement de vous familiariser avec les concepts de service virtuel et de règle de destination.

En termes simples, le service virtuel Istio définit des règles de routage pour les clients qui demandent l’hôte (nom du service). Les services virtuels permettent d’associer plusieurs versions d’un déploiement à un seul nom d’hôte de service virtuel à cibler par les clients. Plusieurs déploiements peuvent être étiquetés pour le même service, représentant différentes versions de l’application derrière le même nom d’hôte. Le service virtuel Istio peut ensuite être configuré pour pondérer la demande sur une version spécifique du service. Les versions disponibles du service sont configurées pour utiliser l’attribut subsets dans une règle de destination Istio.

La modification apportée au service bookstore et au déploiement pour Istio supprime la nécessité d’avoir un deuxième service explicite à cibler, ce dont a besoin la division du trafic SMI. Un autre compte de service pour le service bookstore v2 n’est pas non plus nécessaire, car il doit être centralisé sous le service bookstore. La modification du manifeste OSM traffic-access-v1.yaml d’origine apportée à Istio pour les services bookstore v1 et v2 est indiquée dans la section Créer des pods, des services et des comptes de service ci-dessous. Nous montrons comment nous procédons à la division du trafic, connue sous le nom de déplacement du trafic, plus loin dans la procédure :

Modifications MySql

Les modifications apportées au StatefulSet mysql sont uniquement nécessaires dans la configuration du service. Sous la spécification du service, OSM avait besoin des attributs targetPort et appProtocol. Ces attributs ne sont pas nécessaires pour Istio. Le service mis à jour suivant pour mysqldb ressemble à :

apiVersion: v1
kind: Service
metadata:
  name: mysqldb
  labels:
    app: mysqldb
    service: mysqldb
spec:
  ports:
    - port: 3306
      name: tcp
  selector:
    app: mysqldb

Déployer l’application Bookstore modifiée

Comme pour la procédure Bookstore d’OSM, nous commençons par une nouvelle installation de l’application bookstore.

Créer les espaces de noms

kubectl create namespace bookstore
kubectl create namespace bookbuyer
kubectl create namespace bookthief
kubectl create namespace bookwarehouse

Ajouter une étiquette d’espace de noms pour l’injection de side-car Istio

Dans le cas d’OSM, l’utilisation de la commande osm namespace add <namespace> créait les annotations nécessaires à l’espace de noms pour que le contrôleur OSM ajoute l’injection automatique de side-car. Avec Istio, il vous suffit d’étiqueter un espace de noms pour permettre au contrôleur Istio d’injecter automatiquement les proxys side-car Envoy.

kubectl label namespace bookstore istio-injection=enabled
kubectl label namespace bookbuyer istio-injection=enabled
kubectl label namespace bookthief istio-injection=enabled
kubectl label namespace bookwarehouse istio-injection=enabled

Déployer la règle de destination et le service virtuel Istio pour Bookstore

Comme mentionné dans la section Modifications de Bookstore, Istio gère le déplacement du trafic en utilisant un attribut de pondération VirtualService que nous configurons plus loin dans la procédure. Nous déployons le service virtuel et la règle de destination pour le service bookstore. Nous déployons uniquement la version 1 de bookstore même si sa version 2 est déployée. Le service virtuel Istio fournit uniquement une route vers la version 1 de bookstore. OSM déployait un autre service pour l’application bookstore version 2, s’écartant de la façon dont il gère le déplacement du trafic (division du trafic). OSM devait configurer le trafic à diviser entre les demandes client en utilisant une division de trafic (TrafficSplit). Lors de l’utilisation du déplacement du trafic avec Istio, nous pouvons référencer le déplacement vers plusieurs déploiements (versions) d’applications Kubernetes étiquetés pour le même service.

Dans cette procédure pas à pas, le déploiement des deux versions de bookstore (v1 &v2) est déployé en même temps. Seule la version 1 est accessible en raison de la configuration du service virtuel. Il n’est pas nécessaire de déployer un autre service pour la version 2 de bookstore. Nous activerons une route vers celle-ci quand nous mettrons à jour le service virtuel bookstore et fournirons l’attribut de pondération nécessaire pour effectuer le déplacement du trafic.

kubectl apply -f - <<EOF
# Create bookstore virtual service
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookstore-virtualservice
  namespace: bookstore
spec:
  hosts:
  - bookstore
  http:
  - route:
    - destination:
        host: bookstore
        subset: v1
---
# Create bookstore destination rule
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: bookstore-destination
  namespace: bookstore
spec:
  host: bookstore
  subsets:
  - name: v1
    labels:
      app: bookstore
      version: v1
  - name: v2
    labels:
      app: bookstore
      version: v2
EOF

Créer des pods, des services et des comptes de service

Nous utilisons un fichier manifeste unique qui contient les modifications décrites plus haut dans la procédure pour déployer les applications bookbuyer, bookthief, bookstore, bookwarehouse et mysql.

kubectl apply -f - <<EOF
##################################################################################################
# bookbuyer service
##################################################################################################
---
# Create bookbuyer Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookbuyer
  namespace: bookbuyer
---
# Create bookbuyer Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookbuyer
  namespace: bookbuyer
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookbuyer
      version: v1
  template:
    metadata:
      labels:
        app: bookbuyer
        version: v1
    spec:
      serviceAccountName: bookbuyer
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookbuyer
          image: openservicemesh/bookbuyer:latest-main
          imagePullPolicy: Always
          command: ["/bookbuyer"]
          env:
            - name: "BOOKSTORE_NAMESPACE"
              value: bookstore
            - name: "BOOKSTORE_SVC"
              value: bookstore
---
##################################################################################################
# bookthief service
##################################################################################################
---
# Create bookthief ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookthief
  namespace: bookthief
---
# Create bookthief Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookthief
  namespace: bookthief
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookthief
  template:
    metadata:
      labels:
        app: bookthief
        version: v1
    spec:
      serviceAccountName: bookthief
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookthief
          image: openservicemesh/bookthief:latest-main
          imagePullPolicy: Always
          command: ["/bookthief"]
          env:
            - name: "BOOKSTORE_NAMESPACE"
              value: bookstore
            - name: "BOOKSTORE_SVC"
              value: bookstore
            - name: "BOOKTHIEF_EXPECTED_RESPONSE_CODE"
              value: "503"
---
##################################################################################################
# bookstore service version 1 & 2
##################################################################################################
---
# Create bookstore Service
apiVersion: v1
kind: Service
metadata:
  name: bookstore
  namespace: bookstore
  labels:
    app: bookstore
spec:
  ports:
    - port: 14001
      name: bookstore-port
  selector:
    app: bookstore

---
# Create bookstore Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookstore
  namespace: bookstore

---
# Create bookstore-v1 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookstore-v1
  namespace: bookstore
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookstore
      version: v1
  template:
    metadata:
      labels:
        app: bookstore
        version: v1
    spec:
      serviceAccountName: bookstore
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookstore
          image: openservicemesh/bookstore:latest-main
          imagePullPolicy: Always
          ports:
            - containerPort: 14001
              name: web
          command: ["/bookstore"]
          args: ["--port", "14001"]
          env:
            - name: BOOKWAREHOUSE_NAMESPACE
              value: bookwarehouse
            - name: IDENTITY
              value: bookstore-v1

---
# Create bookstore-v2 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookstore-v2
  namespace: bookstore
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookstore
      version: v2
  template:
    metadata:
      labels:
        app: bookstore
        version: v2
    spec:
      serviceAccountName: bookstore
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookstore
          image: openservicemesh/bookstore:latest-main
          imagePullPolicy: Always
          ports:
            - containerPort: 14001
              name: web
          command: ["/bookstore"]
          args: ["--port", "14001"]
          env:
            - name: BOOKWAREHOUSE_NAMESPACE
              value: bookwarehouse
            - name: IDENTITY
              value: bookstore-v2
---
##################################################################################################
# bookwarehouse service
##################################################################################################
---
# Create bookwarehouse Service Account
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
---
# Create bookwarehouse Service
apiVersion: v1
kind: Service
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
  labels:
    app: bookwarehouse
spec:
  ports:
  - port: 14001
    name: bookwarehouse-port
  selector:
    app: bookwarehouse
---
# Create bookwarehouse Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
spec:
  replicas: 1
  selector:
    matchLabels:
      app: bookwarehouse
  template:
    metadata:
      labels:
        app: bookwarehouse
        version: v1
    spec:
      serviceAccountName: bookwarehouse
      nodeSelector:
        kubernetes.io/arch: amd64
        kubernetes.io/os: linux
      containers:
        - name: bookwarehouse
          image: openservicemesh/bookwarehouse:latest-main
          imagePullPolicy: Always
          command: ["/bookwarehouse"]
##################################################################################################
# mysql service
##################################################################################################
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mysql
  namespace: bookwarehouse
---
apiVersion: v1
kind: Service
metadata:
  name: mysqldb
  labels:
    app: mysqldb
    service: mysqldb
spec:
  ports:
    - port: 3306
      name: tcp
  selector:
    app: mysqldb
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
  namespace: bookwarehouse
spec:
  serviceName: mysql
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      serviceAccountName: mysql
      nodeSelector:
        kubernetes.io/os: linux
      containers:
      - image: mysql:5.6
        name: mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: mypassword
        - name: MYSQL_DATABASE
          value: booksdemo
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - mountPath: /mysql-data
          name: data
        readinessProbe:
          tcpSocket:
            port: 3306
          initialDelaySeconds: 15
          periodSeconds: 10
      volumes:
        - name: data
          emptyDir: {}
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 250M
EOF

Pour afficher ces ressources sur votre cluster, exécutez les commandes suivantes :

kubectl get pods,deployments,serviceaccounts -n bookbuyer
kubectl get pods,deployments,serviceaccounts -n bookthief

kubectl get pods,deployments,serviceaccounts,services,endpoints -n bookstore
kubectl get pods,deployments,serviceaccounts,services,endpoints -n bookwarehouse

Afficher les interfaces utilisateur d’application

Comme pour la procédure OSM d’origine, si le dépôt OSM est cloné, vous pouvez utiliser les scripts de transfert de port pour afficher les interfaces utilisateur de chaque application ici. Pour l’instant, nous nous soucions uniquement d’afficher l’interface utilisateur bookbuyer et bookthief.

cp .env.example .env
bash <<EOF
./scripts/port-forward-bookbuyer-ui.sh &
./scripts/port-forward-bookthief-ui.sh &
wait
EOF

Dans un navigateur, ouvrez les URL suivantes :

http://localhost:8080 - bookbuyer

http://localhost:8083 - bookthief

Configurer les stratégies de trafic d’Istio

Pour maintenir la continuité avec la procédure Bookstore d’OSM d’origine en vue de la conversion vers Istio, nous abordons le mode de stratégie de trafic permissif d’OSM. Le mode de stratégie de trafic permissif d’OSM était un concept d’autorisation ou de refus du trafic dans le maillage sans le déploiement d’une règle de contrôle d’accès de trafic SMI spécifique. La configuration du mode de trafic permissif permettait aux utilisateurs d’intégrer des applications dans le maillage, tout en obtenant le chiffrement mTLS, sans nécessiter de règles explicites pour permettre aux applications du maillage de communiquer. La fonctionnalité de mode de trafic permissif avait pour but d’éviter l’interruption des communications de votre application dès qu’OSM la gérait et de laisser du temps pour définir vos règles tout en veillant à ce que les communications de l’application soient chiffrées en mode mTLS. Ce paramètre pouvait être défini sur true ou false via MeshConfig d’OSM.

Istio gère l’application de mTLS différemment. À la différence d’OSM, le mode permissif d’Istio configure automatiquement les proxys side-car pour utiliser mTLS, mais permet au service d’accepter à la fois le trafic en clair et mTLS. L’équivalent de la configuration du mode permissif d’OSM consiste à utiliser les paramètres PeerAuthentication d’Istio. PeerAuthentication peut être effectué de manière précise au niveau de l’espace de noms ou pour l’ensemble du maillage. Pour plus d’informations sur l’application par Istio de mTLS, consultez l’article Istio consacré à la migration Mutual TLS.

Appliquer le mode strict Istio sur les espaces de noms Bookstore

Il est important de se rappeler que, tout comme le mode permissif d’OSM, la configuration PeerAuthentication d’Istio est uniquement liée à l’utilisation de l’application de mTLS. Les stratégies de couche 7 réelles, tout comme celles utilisées dans stratégies HTTPRouteGroups d’OSM, sont gérées au moyen de configurations AuthorizationPolicy d’Istio que vous verrez plus loin dans la procédure.

Nous plaçons les espaces de noms bookbuyer, bookthief, bookstore et bookwarehouse de manière précise en mode strict mTLS d’Istio.

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookbuyer
  namespace: bookbuyer
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookthief
  namespace: bookthief
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookstore
  namespace: bookstore
spec:
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: bookwarehouse
  namespace: bookwarehouse
spec:
  mtls:
    mode: STRICT
EOF

Déployer les stratégies de contrôle d’accès Istio

À l’instar des ressources SMI Traffic Target et SMI Traffic Specs d’OSM pour définir des stratégies de contrôle d’accès et de routage afin de permettre aux applications de communiquer, Istio effectue ces contrôles précis similaires en utilisant des configurations AuthorizationPolicy.

Passons en revue la conversion de la stratégie TrafficTarget de bookstore, qui permet spécifiquement au bookbuyer de communiquer avec lui, avec uniquement certains chemins, en-têtes et méthodes de couche 7. Voici une partie du manifeste traffic-access-v1.yaml.

kind: TrafficTarget
apiVersion: access.smi-spec.io/v1alpha3
metadata:
  name: bookstore
  namespace: bookstore
spec:
  destination:
    kind: ServiceAccount
    name: bookstore
    namespace: bookstore
  rules:
    - kind: HTTPRouteGroup
      name: bookstore-service-routes
      matches:
        - buy-a-book
        - books-bought
  sources:
    - kind: ServiceAccount
      name: bookbuyer
      namespace: bookbuyer
---
apiVersion: specs.smi-spec.io/v1alpha4
kind: HTTPRouteGroup
metadata:
  name: bookstore-service-routes
  namespace: bookstore
spec:
  matches:
    - name: books-bought
      pathRegex: /books-bought
      methods:
        - GET
      headers:
        - "user-agent": ".*-http-client/*.*"
        - "client-app": "bookbuyer"
    - name: buy-a-book
      pathRegex: ".*a-book.*new"
      methods:
        - GET

Comme vous pouvez le remarquer sous la stratégie TrafficTarget, dans la spécification, vous pouvez définir explicitement quel service source peut communiquer avec un service de destination. Nous pouvons voir que nous permettons à la source bookbuyer d’être autorisée à communiquer avec le service bookstore de destination. La conversion de l’autorisation de service à service d’une configuration TrafficTarget OSM en une stratégie AuthorizationPolicy Istio ressemblerait à ceci :

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: bookstore
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer"]

La stratégie AuthorizationPolicy d’Istio montre comment le service de destination de stratégie OSM TrafficTarget est mappé à la correspondance d’étiquette du sélecteur et à l’espace de noms dans lequel réside le service. Le service source apparaît dans la section rules où se trouve un attribut source/principals qui correspond au nom du compte de service pour le service bookbuyer.

En plus de la simple configuration source/destination dans OSM TrafficTarget, OSM lie l’utilisation d’un HTTPRouteGroup pour affiner l’autorisation de couche 7 à laquelle la source a accès. Comme le montre la seule partie du HTTPRouteGroup ci-dessous, il existe deux matches pour le service source autorisé.

apiVersion: specs.smi-spec.io/v1alpha4
kind: HTTPRouteGroup
metadata:
  name: bookstore-service-routes
  namespace: bookstore
spec:
  matches:
    - name: books-bought
      pathRegex: /books-bought
      methods:
        - GET
      headers:
        - "user-agent": ".*-http-client/*.*"
        - "client-app": "bookbuyer"
    - name: buy-a-book
      pathRegex: ".*a-book.*new"
      methods:
        - GET

Il existe un match nommé books-bought qui permet à la source d’accéder au chemin /books-bought en utilisant une méthode GET avec des informations d’en-tête d’hôte user-agent et client-app, et une correspondance buy-a-book qui utilise une expression régulière regex pour un chemin contenant .*a-book.*new en utilisant une méthode GET.

Nous pouvons définir ces configurations HTTPRouteGroup OSM dans la section rules de la configuration AuthorizationPolicy d’Istio illustrée ci-dessous :

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "bookstore"
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer"]
        - source:
            namespaces: ["bookbuyer"]
      to:
        - operation:
            methods: ["GET"]
            paths: ["*/books-bought", "*/buy-a-book/new"]
    - when:
        - key: request.headers[User-Agent]
          values: ["*-http-client/*"]
        - key: request.headers[Client-App]
          values: ["bookbuyer"]

Nous pouvons maintenant déployer le manifeste traffic-access-v1.yaml migré OSM tel que le comprend Istio ci-dessous. Il n’y a pas de AuthorizationPolicy pour bookthief ; ainsi l’interface utilisateur bookthief doit cesser d’incrémenter le compteur books à partir de bookstore v1 :

kubectl apply -f - <<EOF
##################################################################################################
# bookstore policy
##################################################################################################
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "bookstore"
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer"]
        - source:
            namespaces: ["bookbuyer"]
      to:
        - operation:
            methods: ["GET"]
            paths: ["*/books-bought", "*/buy-a-book/new"]
    - when:
        - key: request.headers[User-Agent]
          values: ["*-http-client/*"]
        - key: request.headers[Client-App]
          values: ["bookbuyer"]
---
##################################################################################################
# bookwarehouse policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "bookwarehouse"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: bookwarehouse
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookstore/sa/bookstore"]
        - source:
            namespaces: ["bookstore"]
      to:
        - operation:
            methods: ["POST"]
---
##################################################################################################
# mysql policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "mysql"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: mysql
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookwarehouse/sa/bookwarehouse"]
        - source:
            namespaces: ["bookwarehouse"]
      to:
         - operation:
            ports: ["3306"]
EOF

Autoriser l’application Bookthief à accéder à Bookstore

Il n’y a pas de AuthorizationPolicy qui permet à bookthief de communiquer avec bookstore. Nous pouvons déployer la configuration AuthorizationPolicy suivante pour permettre à bookthief de communiquer avec bookstore. Vous remarquez l’ajout de la règle pour la stratégie bookstore qui rend possible l’autorisation bookthief.

kubectl apply -f - <<EOF
##################################################################################################
# bookstore policy
##################################################################################################
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "bookstore"
  namespace: bookstore
spec:
  selector:
    matchLabels:
      app: bookstore
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookbuyer/sa/bookbuyer", "cluster.local/ns/bookthief/sa/bookthief"]
        - source:
            namespaces: ["bookbuyer", "bookthief"]
      to:
        - operation:
            methods: ["GET"]
            paths: ["*/books-bought", "*/buy-a-book/new"]
    - when:
        - key: request.headers[User-Agent]
          values: ["*-http-client/*"]
        - key: request.headers[Client-App]
          values: ["bookbuyer"]
---
##################################################################################################
# bookwarehouse policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "bookwarehouse"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: bookwarehouse
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookstore/sa/bookstore"]
        - source:
            namespaces: ["bookstore"]
      to:
        - operation:
            methods: ["POST"]
---
##################################################################################################
# mysql policy
##################################################################################################
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "mysql"
  namespace: bookwarehouse
spec:
  selector:
    matchLabels:
      app: mysql
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/bookwarehouse/sa/bookwarehouse"]
        - source:
            namespaces: ["bookwarehouse"]
      to:
         - operation:
            ports: ["3306"]
EOF

L’interface utilisateur bookthief doit maintenant incrémenter le compteur books à partir de bookstore v1.

Configurer le déplacement du trafic entre deux versions de service

Nous allons montrer comment équilibrer le trafic entre deux versions d’un service Kubernetes, opération appelée déplacement du trafic dans Istio. Comme vous l’avez vu dans une section précédente, l’implémentation OSM du déplacement du trafic reposait sur le déploiement de deux services distincts et l’ajout de ces noms de service à la configuration back-end de la stratégie TrafficTarget. Cette architecture de déploiement n’est pas nécessaire pour la façon dont Istio implémente le déplacement du trafic. Avec Istio, nous pouvons créer plusieurs déploiements qui représentent chaque version de l’application de service et déplacer le trafic vers ces versions spécifiques via la configuration virtualservice Istio.

Le virtualservice déployé a uniquement une règle de routage vers la version v1 du service bookstore illustrée ci-dessous :

spec:
  hosts:
    - bookstore
  http:
    - route:
        - destination:
            host: bookstore
            subset: v1

Nous mettons à jour le virtualservice pour déplacer 100 % de la pondération vers la version v2 du service bookstore.

kubectl apply -f - <<EOF
# Create bookstore virtual service
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: bookstore-virtualservice
  namespace: bookstore
spec:
  hosts:
  - bookstore
  http:
  - route:
    - destination:
        host: bookstore
        subset: v1
      weight: 0
    - destination:
        host: bookstore
        subset: v2
      weight: 100
EOF

Vous devez maintenant voir à la fois l’incrémentation de l’interface utilisateur bookbuyer et bookthief pour le service bookstore v2 uniquement. Vous pouvez continuer à expérimenter en changeant l’attribut weigth pour déplacer le trafic entre les deux versions bookstore.

Résumé

Nous espérons que cette procédure pas à pas vous a fourni les conseils nécessaires sur la façon de migrer vos stratégies OSM actuelles vers des stratégies Istio. Prenez le temps de passer en revue les concepts d’Istio et parcourez le guide de démarrage d’Istio pour apprendre à utiliser le maillage de services Istio afin de gérer vos applications.

Share via