Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Installer et mettre à niveau des passerelles avec les API Istio

Cloud Service Mesh vous permet de déployer et de gérer des passerelles avec votre maillage de services. Une passerelle décrit un équilibreur de charge qui fonctionne à la périphérie du maillage et reçoit des connexions HTTP/TCP entrantes ou sortantes. Les passerelles sont principalement utilisées pour gérer le trafic entrant, mais vous pouvez également les configurer pour gérer d'autres types de trafic.

Passerelles de sortie : une passerelle de sortie vous permet de configurer un nœud de sortie dédié au trafic quittant le maillage. Vous pouvez ainsi limiter les services qui peuvent ou doivent accéder aux réseaux externes, ou activer un contrôle sécurisé du trafic sortant pour renforcer la sécurité de votre maillage, par exemple.
Passerelles d'Ingress : une passerelle d'entrée vous permet de configurer un nœud d'entrée dédié pour recevoir les connexions HTTP/TCP entrantes.
Passerelles est-ouest : proxy pour le trafic est-ouest permettant aux charges de travail de service de communiquer au-delà des limites des clusters dans un maillage à plusieurs instances principales sur différents réseaux. Par défaut, cette passerelle est publique sur Internet.

Cette page décrit les bonnes pratiques pour déployer et mettre à niveau les proxys de passerelle, ainsi que des exemples de configuration de vos propres proxys de passerelle istio-ingressgateway et istio-egressgateway.

Vous pouvez déployer des passerelles de différentes manières et utiliser plusieurs topologies dans le même cluster. Pour en savoir plus sur ces topologies, consultez Topologies de déploiement de passerelle dans la documentation Istio.

Bonnes pratiques pour le déploiement de passerelles

Les bonnes pratiques pour déployer des passerelles dépendent de l'utilisation du plan de données géré ou du plan de données non géré.

Bonnes pratiques pour le plan de données géré

Activez le plan de données géré.
Ajoutez un libellé de révision gérée à un espace de noms.
Déployer et gérer le plan de contrôle et les passerelles séparément.
Pour respecter nos bonnes pratiques de sécurité, déployez les passerelles dans un espace de noms différent du plan de contrôle.
Injectez de la configuration proxy pour les passerelles à l'aide de l'injection side-car automatique (injection automatique) comme vous l'utilisez pour injecter les proxys side-car pour vos services.

Ces bonnes pratiques :

assurent que vos passerelles gérées sont automatiquement à jour avec les dernières améliorations et les dernières mises à jour de sécurité ;
déchargent la gestion et la maintenance des instances de passerelle vers le plan de données géré par Cloud Service Mesh.

Bonnes pratiques pour le plan de données non géré

Déployer et gérer le plan de contrôle et les passerelles séparément.
Pour respecter nos bonnes pratiques de sécurité, déployez les passerelles dans un espace de noms différent du plan de contrôle.
Injectez de la configuration proxy pour les passerelles à l'aide de l'injection side-car automatique (injection automatique) comme vous l'utilisez pour injecter les proxys side-car pour vos services.

Ces bonnes pratiques :

Laissez les administrateurs de vos espaces de noms gérer les passerelles sans avoir à élever les privilèges pour l'ensemble du cluster.
Laissez vos administrateurs utiliser les mêmes outils ou mécanismes de déploiement que ceux utilisés pour gérer les applications Kubernetes afin de déployer et de gérer des passerelles.
donnent aux administrateurs un contrôle total sur le déploiement de la passerelle et simplifiez les opérations. Lorsqu'une nouvelle mise à niveau est disponible ou qu'une configuration est modifiée, les administrateurs mettent à jour les pods de passerelle en les redémarrant. Cela permet d'exploiter un déploiement de passerelle de la même manière que des proxys side-car pour vos services.

Déployer un exemple de passerelle

Pour aider les utilisateurs disposant d'outils de déploiement existants, Cloud Service Mesh est compatible avec les mêmes méthodes de déploiement d'une passerelle qu'Istio : IstioOperator, Helm et Kubernetes YAML. Chaque méthode produit le même résultat. Bien que vous puissiez choisir la méthode qui vous est la plus familière, nous vous recommandons d'utiliser la méthode Kubernetes YAML, car elle est plus facile à modifier et vous pouvez stocker les fichiers manifestes hydratés dans le contrôle des sources.

Les étapes suivantes expliquent comment déployer un exemple de passerelle.

Créez un espace de noms pour la passerelle si vous n'en possédez pas déjà un. Remplacez GATEWAY_NAMESPACE par le nom de votre espace de noms.
```
kubectl create namespace GATEWAY_NAMESPACE
```
Activez l'espace de noms pour l'injection : Les étapes dépendent de votre mise en œuvre du plan de contrôle.
Plan de contrôle géré (TD)
1. Appliquez les étiquettes d'injection par défaut à l'espace de noms.
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Plan de contrôle géré (Istiod)
Attention : L'implémentation de Cloud Service Mesh géré à l'aide du plan de contrôle ISTIOD est obsolète. Vous devez moderniser tous les parcs ISTIOD gérés vers l'implémentation du plan de contrôle TRAFFIC_DIRECTOR.

Recommandation : Exécutez la commande suivante pour appliquer l'étiquette d'injection par défaut à l'espace de noms :
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Si vous utilisez déjà le plan de contrôle Istiod géré : nous vous recommandons d'utiliser l'injection par défaut, mais l'injection basée sur les révisions est acceptée. Suivez les instructions suivantes :
1. Exécutez la commande suivante pour localiser les canaux de publication disponibles :
  
  kubectl -n istio-system get controlplanerevision
  
  Le résultat ressemble à ce qui suit :
  
  NAME AGE asm-managed-rapid 6d7h
  
  REMARQUE : Si deux révisions du plan de contrôle apparaissent dans la liste ci-dessus, supprimez-en une. Il n'est pas possible d'avoir plusieurs canaux de plan de contrôle dans un même cluster.
  
  Dans le résultat, la valeur de la colonne NAME est l'étiquette de révision qui correspond au canal de publication disponible pour la version de Cloud Service Mesh.
2. Appliquez l'étiquette de révision à l'espace de noms :
  
  kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Dans le cluster
Attention : Le plan de contrôle ISTIOD pour Cloud Service Mesh dans un cluster sur GKE sur Google Cloud est obsolète. Cloud Service Mesh avec un plan de contrôle intégré au cluster sur Google Distributed Cloud (logiciel uniquement) reste compatible, comme décrit dans Plates-formes compatibles.

Recommandation : Exécutez la commande suivante pour appliquer l'étiquette d'injection par défaut à l'espace de noms :
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
Nous vous recommandons d'utiliser l'injection par défaut, mais l'injection basée sur les révisions est acceptée : Suivez les instructions ci-dessous :
1. Exécutez la commande suivante pour localiser l'étiquette de révision sur istiod :
  
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. Appliquez l'étiquette de révision à l'espace de noms. Dans la commande suivante, REVISION_LABEL correspond à la valeur du libellé de révision istiod que vous avez notée à l'étape précédente.
  
  kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
Copiez les fichiers de configuration des passerelles exemples à partir du dépôt anthos-service-mesh.
Remplacez votre répertoire par le répertoire samples. Pour vous assurer que vous êtes dans le bon répertoire, exécutez la commande ls pour lister le contenu du répertoire, puis vérifiez qu'il existe un répertoire gateways (auquel vous accéderez à l'étape suivante) et un répertoire online-boutique.
Déployez une passerelle d'entrée ou de sortie. Ils se trouvent dans le répertoire samples/gateways/. Vous pouvez les utiliser tels quels ou les modifier si nécessaire.
Entrée
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
Sortie
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway

Après avoir créé le déploiement, vérifiez que les nouveaux services fonctionnent correctement :

kubectl get pod,service -n GATEWAY_NAMESPACE

Vérifiez que le résultat ressemble à ce qui suit :

NAME                                      READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

Gérez les ressources de passerelle comme n'importe quelle autre application Kubernetes. Les exemples du dépôt anthos-service-mesh-packages sont destinés à servir de guide et de démarrage rapide. Personnalisez-les selon vos besoins.

Sélecteurs de passerelle

Vous appliquez une configuration Gateway aux proxys istio-ingressgateway et istio-egressgateway pour gérer le trafic entrant et sortant de votre maillage, ce qui vous permet de spécifier le trafic que vous souhaitez faire entrer ou sortir du maillage. Les libellés des pods d'un déploiement de passerelle sont utilisés par les ressources de configuration de passerelle. Il est donc important que le sélecteur de passerelle corresponde à ces libellés.

Par exemple, dans les déploiements précédents, l'étiquette istio=ingressgateway est définie sur les pods de passerelle. Pour appliquer une configuration de passerelle à ces déploiements, vous devez sélectionner le même libellé :

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

Pour obtenir un exemple de configuration de passerelle et de service virtuel, consultez frontend.yaml dans l'exemple d'application Boutique en ligne.

Mettre à niveau les passerelles

Mises à niveau sur place

Dans la plupart des cas d'utilisation, vous devez mettre à niveau vos passerelles en suivant le modèle de mise à niveau sur place. Comme les passerelles utilisent l'injection de pods, les nouveaux pods de passerelle créés sont automatiquement injectés avec la dernière configuration, qui inclut la version.

Si vous souhaitez modifier la révision du plan de contrôle utilisée par la passerelle, vous pouvez définir le libellé istio.io/rev sur le déploiement de la passerelle, ce qui déclenchera également un redémarrage progressif.

Plan de contrôle géré

Étant donné que Google gère les mises à niveau du plan de contrôle pour le plan de contrôle géré, vous pouvez simplement redémarrer le déploiement de la passerelle pour que les nouveaux pods soient automatiquement injectés avec la dernière configuration et la dernière version.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Plan de contrôle au sein du cluster

Attention : Le plan de contrôle ISTIOD pour Cloud Service Mesh dans un cluster sur GKE sur Google Cloud est obsolète. Cloud Service Mesh avec un plan de contrôle intégré au cluster sur Google Distributed Cloud (logiciel uniquement) reste compatible, comme décrit dans Plates-formes compatibles.

Pour appliquer le même schéma à vos passerelles lorsque vous disposez du plan de contrôle dans le cluster, vous devez modifier la révision du plan de contrôle utilisée par la passerelle. Définissez l'étiquette istio.io/rev sur le déploiement de la passerelle, ce qui déclenchera un redémarrage progressif. Les étapes requises varient selon que vous devez mettre à jour le libellé de révision sur l'espace de noms et/ou le pod de passerelle.

Si vous avez ajouté un libellé à l'espace de noms pour l'injection, définissez le libellé istio.io/rev sur l'espace de noms avec la nouvelle valeur de révision :
```
  kubectl label namespace GATEWAY_NAMESPACE \
    istio-injection- istio.io/rev=REVISION \
    --overwrite
```

Si vous n'avez activé l'injection que pour le pod de passerelle, définissez le libellé istio.io/rev sur le déploiement sur la nouvelle valeur de révision, comme dans le fichier YAML Kubernetes suivant :

cat <<EOF > gateway-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Cloud Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
EOF

kubectl apply -f gateway-deployment.yaml

Mises à niveau Canary (avancées)

Si vous utilisez le plan de contrôle au sein du cluster et que vous souhaitez contrôler plus lentement le déploiement d'une nouvelle révision de plan de contrôle, vous pouvez suivre le modèle de mise à niveau Canary. Vous pouvez exécuter plusieurs versions d'un déploiement de passerelle et vous assurer que tout fonctionne comme prévu avec un sous-ensemble de votre trafic. Par exemple, si vous souhaitez déployer une nouvelle révision, Canary, créez une copie du déploiement de votre passerelle en définissant le libellé istio.io/rev=REVISION sur la nouvelle révision et un nouveau nom, par exemple istio-ingressgateway-canary :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

Lorsque ce déploiement est créé, vous disposez de deux versions de la passerelle, toutes deux sélectionnées par le même service :

kubectl get endpoints -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

Si vous êtes certain que vos applications fonctionnent comme prévu, exécutez la commande suivante pour passer à la nouvelle version en supprimant le déploiement avec l'ancien ensemble de libellés istio.io/rev :

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

Si vous avez rencontré un problème lors du test de votre application avec la nouvelle version de la passerelle, exécutez cette commande pour revenir à l'ancienne version en supprimant le déploiement avec le nouvel ensemble de libellés istio.io/rev :

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE

Configuration avancée

Déployer des passerelles qui mettent fin au trafic TLS

Pour en savoir plus, consultez Configurer la terminaison TLS dans la passerelle d'entrée.

Configurer la version TLS minimale de la passerelle

Pour Cloud Service Mesh, la version TLS minimale par défaut pour les serveurs de passerelle est 1.2. Vous pouvez configurer la version TLS minimale à l'aide du champ minProtocolVersion. Pour en savoir plus, consultez ServerTLSSettings.

Fonctionnalités non compatibles

Si vous disposez d'une implémentation du plan de contrôle TRAFFIC_DIRECTOR, les champs ou valeurs suivants dans Gateway ne sont pas acceptés :

ServerTLSSettings.TLSmode avec la valeur AUTO_PASSTHROUGH
ServerTLSSettings.verifyCertificateSpki
ServerTLSSettings.verifyCertificateHash

Résoudre les problèmes liés aux passerelles

Échec de la mise à jour de l'image de la passerelle à partir de `auto`

Lorsque vous déployez ou mettez à niveau une passerelle, Cloud Service Mesh insère auto en tant qu'espace réservé dans le champ image. Après l'appel à un webhook de mutation, Cloud Service Mesh remplace automatiquement cet espace réservé par l'image de proxy Cloud Service Mesh réelle. Si l'appel au webhook de mutation échoue, le code de substitution auto reste en place et le conteneur n'est pas trouvé. Cela est généralement dû à un libellé d'espace de noms incorrect. Assurez-vous d'avoir configuré le bon espace de noms, puis déployez ou mettez à niveau à nouveau la passerelle.