Installer et mettre à niveau des passerelles avec des API Istio

Remarque :Ce guide n'est compatible qu'avec Cloud Service Mesh avec les API Istio ne sont pas compatibles avec les API Google Cloud. Pour en savoir plus, consultez Présentation de Cloud Service Mesh

Cloud Service Mesh vous permet de déployer et de gérer des passerelles dans le cadre votre maillage de services. Une passerelle décrit un équilibreur de charge fonctionnant en périphérie du réseau maillé et reçoit les connexions HTTP/TCP entrantes ou sortantes. Les passerelles sont sert principalement à gérer le trafic entrant, mais vous pouvez aussi configurer des passerelles 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é pour le trafic quittant le réseau maillé, ce qui vous permet de limiter les services accéder à des réseaux externes, ou pour permettre un contrôle sécurisé du trafic de sortie à votre réseau maillé, par exemple.

• Passerelles d'Ingress: une passerelle d'entrée vous permet de configurer une entrée dédiée pour recevoir les connexions HTTP/TCP entrantes.

• Les passerelles est-ouest: un proxy pour est-ouest pour permettre aux charges de travail de communiquer entre elles au-delà des limites du cluster un réseau maillé multiprimaire 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 plus une topologie dans le même cluster. Consultez Topologies de déploiement de passerelle dans la documentation d'Istio pour en savoir plus sur ces topologies.

Bonnes pratiques pour le déploiement de passerelles

Les bonnes pratiques de déploiement de passerelles varient selon que vous utilisez ou non plan de données géré ou plan de données non géré.

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

1. Activez le paramètre plan de données géré.
2. Ajoutez un libellé de révision gérée à un espace de noms.
3. Déployer et gérer le plan de contrôle et les passerelles séparément.
4. Pour respecter nos bonnes pratiques de sécurité, nous vous recommandons de déployer les passerelles dans un espace de noms différent du plan de contrôle.
5. 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écharge la gestion et la maintenance des instances de passerelle vers Cloud Service Mesh de votre plan de données géré.

Bonnes pratiques pour les plans de données non gérés

1. Déployer et gérer le plan de contrôle et les passerelles séparément.
2. Pour respecter nos bonnes pratiques de sécurité, nous vous recommandons de déployer les passerelles dans un espace de noms différent du plan de contrôle.
3. 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 ou une configuration a changé, les administrateurs mettent à jour les pods de passerelle en les redémarrant. Ce rend l'utilisation d'un déploiement de passerelle identique à l'expérience et exploiter des proxys side-car pour vos services.

Déployer l'exemple de passerelle

Pour aider les utilisateurs avec des outils de déploiement existants, Cloud Service Mesh est compatible avec les mêmes méthodes de déploiement d'une passerelle Istio: IstioOperator, Helm et YAML pour Kubernetes. Chaque méthode produit le même résultat. Même si vous pouvez choisir celle que vous connaissez le mieux, nous vous recommandons d'utiliser la méthode YAML de Kubernetes, car elle permet de modifier plus facilement et vous pouvez stocker des fichiers manifestes hydratés dans un dépôt source.

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

1. 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
   

2. Activez l'espace de noms pour l'injection : Les étapes dépendent de la mise en œuvre du plan de contrôle.

   Géré (TD)

   1. Appliquez l'étiquette d'injection par défaut à l'espace de noms:

   kubectl label namespace GATEWAY_NAMESPACE \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Géré (Istiod)

   Recommandé: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 êtes un utilisateur existant disposant du plan de contrôle Istiod géré: Nous vous recommandons d'utiliser l'injection par défaut, mais celle basée sur les révisions compatibles. Pour ce faire, procédez comme suit:

   1. Exécutez la commande suivante pour localiser les versions 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 figurent dans la liste ci-dessus, supprimez-en une. Il n'est pas possible d'avoir plusieurs canaux de plan de contrôle dans le cluster.

      Dans le résultat, la valeur figurant dans la colonne NAME correspond au libellé de révision qui correspond à la version disponible disponible pour la version de Cloud Service Mesh.

   2. Appliquez le libellé de révision à l'espace de noms.

      kubectl label namespace GATEWAY_NAMESPACE \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

   Dans le cluster

   Recommandé: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 compatible: Pour ce faire, procédez comme suit:

   1. Exécutez la commande suivante pour localiser le libellé 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 le libellé 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
      

3. Copiez les fichiers de configuration des exemples de passerelles à partir du Dépôt anthos-service-mesh.

4. Remplacez votre répertoire par samples. Pour vous assurer d'être dans le répertoire approprié, exécutez la commande ls pour lister le contenu du répertoire et Vérifiez ensuite qu'il existe un répertoire gateways (auquel vous accéderez dans l'étape suivante) et un répertoire online-boutique.

5. Déployez une passerelle d'entrée ou de sortie. Ils se trouvent dans la section samples/gateways/ tel quel ou modifiez-le 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
   

6. 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 la sortie 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 de le dépôt anthos-service-mesh-packages sont fournis à titre indicatif. de ce guide de démarrage rapide. Personnalisez-les en fonction de vos besoins.

Sélecteurs de passerelle

Vous appliquez un Passerelle configuration aux proxys istio-ingressgateway et istio-egressgateway pour gérer le trafic entrant et sortant de votre réseau maillé, le trafic que vous voulez entrer dans le réseau maillé. 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 la 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, Voir 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 l'étiquette istio.io/rev sur le déploiement de la passerelle, ce qui entraînera également un redémarrage progressif.

Plan de contrôle géré

Comme Google gère les mises à niveau du plan de contrôle géré, il vous suffit de redémarrer le déploiement de la passerelle pour que les nouveaux pods sera automatiquement injecté 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

Pour appliquer le même schéma à vos passerelles lorsque le 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 une un redémarrage progressif. La procédure à suivre varie selon que vous devez mettre à jour ou non étiquette de révision sur l'espace de noms et/ou sur le pod de passerelle.

• Si vous avez étiqueté l'espace de noms pour l'injection, définissez l'étiquette istio.io/rev sur l'espace de noms à la nouvelle valeur de révision:

    kubectl label namespace GATEWAY_NAMESPACE \
      istio-injection- istio.io/rev=REVISION \
      --overwrite
  

• Si vous avez activé l'injection uniquement pour le pod de la passerelle, définissez le istio.io/rev sur le déploiement à la nouvelle valeur de révision, comme suit : Fichier YAML Kubernetes:

  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
  

  Remarque: Si image n'est pas automatiquement mis à jour avec l'image du proxy Cloud Service Mesh, le conteneur est introuvable et une erreur s'affiche se produira. Pour en savoir plus, consultez Dépanner les passerelles. étapes.

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

Remarque: Si image n'est pas automatiquement mis à jour avec le véritable maillage de services Cloud l'image du proxy, le conteneur est introuvable et une erreur est renvoyée. Voir Résoudre les problèmes liés aux passerelles pour connaître les étapes suivantes.

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

Remarque :Contrairement aux services d'application déployés dans le maillage, vous ne pouvez pas utiliser le déplacement du trafic Istio pour répartir le trafic entre les versions de la passerelle ; car leur trafic provient directement de clients externes, contrairement à Istio. pas le contrôle. Au lieu de cela, vous pouvez contrôler la distribution du trafic en fonction du nombre d'instances dupliquées de chaque déploiement. Si vous utilisez un autre équilibreur de charge devant Istio, vous pouvez également l'utiliser pour contrôler la répartition du trafic.

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

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 utilisez TRAFFIC_DIRECTOR implémentation du plan de contrôle, puis 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 passerelle de auto

Lorsque vous déployez ou mettez à niveau une passerelle, Cloud Service Mesh insère auto en tant que dans le champ image. Après l'appel au webhook de mutation, Cloud Service Mesh remplace automatiquement cet espace réservé par Image du proxy Cloud Service Mesh. Si l'appel au webhook de mutation échoue, auto est conservé, et le conteneur est introuvable. Il s'agit généralement en raison d'une étiquette d'espace de noms incorrecte. Assurez-vous d'avoir configuré puis de déployer ou de mettre à niveau la passerelle à nouveau.