Considérations

Avant de commencer, passez en revue les considérations suivantes concernant l'utilisation de passerelles personnalisées.

• Le module complémentaire Istio géré ne gère ni ne synchronise les passerelles personnalisées que vous créez. Vous êtes responsable de la création, de la gestion et de la maintenance de ces ressources.
• Après avoir déployé votre passerelle personnalisée, vérifiez que les journaux du pod opérateur Istio ne contiennent pas d'erreurs de syntaxe en exécutant kubectl logs -n ibm-operators -l name=addon-istio-operator. L'opérateur « Istio » valide et synchronise toutes les modifications que vous apportez aux protocoles d' IstioOperator s personnalisés (IOP).
• Vérifiez également que l'option istio-global-proxy-accessLogFile dans la mappe de configuration (configmap) managed-istio-custom est définie sur "/dev/stdout". Les proxy Envoy impriment des informations d'accès dans leur sortie standard que vous pouvez afficher en exécutant les commandes kubectl logs pour les conteneurs Envoy.

Création d'une passerelle d'entrée personnalisée pour le trafic public

Utilisez un IstioOperator (IOP) pour créer un déploiement de passerelle d'entrée personnalisée et un service d'équilibreur de charge public dans un espace de noms custom-gateways.

1. Installez le module complémentaire Istio.

2. Créez un espace de noms pour la passerelle d'entrée personnalisée.

   kubectl create namespace custom-gateways
   

3. Créez un fichier YAML nommé custom-ingress-iop.yaml pour une ressource IstioOperator (IOP). Pour forcer les pods de la passerelle personnalisée à exécuter une version spécifique d'Istio géré, spécifiez la version dans la zone tag. Pour plus d'informations, voir Contrôle des mises à jour et des versions de passerelle personnalisée.

   apiVersion: install.istio.io/v1alpha1
   kind: IstioOperator
   metadata:
     namespace: ibm-operators
     name: custom-ingressgateway-iop
   spec:
     profile: empty
     hub: icr.io/ext/istio
     # tag: 1.29.5
     components:
       ingressGateways:
         - name: custom-ingressgateway
           label:
             istio: custom-ingressgateway
           namespace: custom-gateways
           enabled: true
           k8s:
             serviceAnnotations:
               service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: public
   

4. Créez la ressource (IOP) IstioOperator dans votre cluster. L'opérateur Istio géré dans l'espace de noms ibm-operators utilise la ressource IOP pour déployer et exposer la passerelle d'entrée dans l'espace de noms custom-gateways avec un service d'équilibreur de charge public.

   kubectl apply -f ./custom-ingress-iop.yaml
   

5. Vérifiez que le déploiement et le service de la passerelle d'entrée sont créés dans l'espace de noms custom-gateways.

   kubectl get deploy,svc -n custom-gateways
   

   Exemple de sortie

   NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
   deployment.apps/custom-ingressgateway   1/1     1            1           4m53s
   NAME                            TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)                                                                                                                                      AGE
   service/custom-ingressgateway   LoadBalancer   172.21.98.120   52.117.68.222   15020:32656/TCP,80:30576/TCP,443:32689/TCP,15029:31885/TCP,15030:30198/TCP,15031:32637/TCP,15032:30869/TCP,31400:30310/TCP,15443:31698/TCP   4m53s
   

6. Dans la sortie pour l'équilibreur de charge service/custom-ingressgateway, notez l'adresse IP (clusters classiques) ou le nom d'hôte (clusters VPC) dans la colonne EXTERNAL-IP.

Vous pouvez maintenant spécifier le nom de cet équilibreur de charge de passerelle d'entrée, custom-ingressgateway, dans une ressource Gateway qui définit le port de votre application gérée par Istio. Ensuite, vous pouvez spécifier le nom de la passerelle Gateway dans une ressource VirtualService qui définit les chemins d'accès aux microservices dans votre maillage de services. Pour un exemple d'utilisation d'une passerelle Gateway et d'un service VirtualService avec votre équilibreur de charge de passerelle personnalisée, essayez l'application exemple BookInfo.

Création d'une passerelle d'entrée personnalisée pour le trafic du réseau privé

Pour créer un déploiement de passerelle d'entrée personnalisée et l'exposer avec un service d'équilibreur de charge privé, appliquez les étapes de la section Création d'une passerelle d'entrée personnalisée pour le trafic public. Lorsque vous créez l'IOP à l'étape 3, spécifiez l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: private au lieu de public.

Notez les points suivants :

• Si votre cluster classique est connecté à des réseaux VLAN privés uniquement, ou si seul le noeud final de service de cloud privé est activé sur votre cluster VPC, un équilibreur de charge privé est créé par défaut lorsque vous appliquez l'IOP.
• Pour les clusters classiques uniquement, vous ne pouvez pas utiliser ibmcloud ks nlb-dns create classic pour créer un enregistrement DNS et le sous-domaine fourni par IBM pour l'adresse IP de l'équilibreur de charge de passerelle personnalisé.

Contrôle des mises à jour et des versions de passerelle personnalisée

Mettez à jour et contrôlez manuellement la version Istio gérée des passerelles d'entrée personnalisées.

IBM Cloud conserve tous vos composants Istio à jour en déployant automatiquement les mises à jour de correctif vers la version la plus récente d'Istio qui est prise en charge par IBM Cloud Kubernetes Service. Par exemple, lorsque la version de correctif 1.29.5 est publiée, tous les pods de passerelle d'entrée sont automatiquement mis à jour vers cette dernière version de correctif. Les versions de correctifs sont complétées à l'aide de la stratégie de mise à jour en continu pour éviter les temps d'indisponibilité de vos applications. Cependant, vous pouvez empêcher les mises à jour automatiques des pods de passerelle personnalisée, par exemple si vous souhaitez tester toute régression potentielle avec la dernière version de correctif.

Pour gérer les mises à jour de vos passerelles d'entrée personnalisées, vous pouvez utiliser la stratégie de déploiement suivante :

1. Créez des IOP de passerelle d'entrée personnalisée. Dans la zone tag, indiquez une version de correctif identique ou antérieure à la version du plan de contrôle. Vous pouvez trouver la version du plan de contrôle en exécutant la istioctl version.
2. Lorsqu'une nouvelle version du correctif est publiée pour le module complémentaire Istio géré, modifiez le fichier YAML IOP pour une passerelle personnalisée afin d'utiliser la dernière version du correctif, puis réappliquez l'IOP dans votre cluster.
3. Une fois les pods de la passerelle personnalisée mis à jour vers le dernier correctif, testez toutes les modifications apportées à la passerelle personnalisée.
4. Lorsque vous êtes satisfait des modifications, modifiez les configurations des autres passerelles personnalisées pour les mettre à jour vers le dernier correctif.

Ne définissez pas la balise sur une version ultérieure à celle du plan de contrôle de votre module complémentaire Istio.

Mettez à jour les pods de votre passerelle personnalisée dès que possible après la publication d'une version. Les passerelles personnalisées qui exécutent des versions antérieures peuvent être exposées à des failles de sécurité.

Personnalisations supplémentaires des passerelles

Les passerelles d'entrée personnalisées peuvent être configurées avec des personnalisations supplémentaires, notamment le déploiement de l'équilibreur de charge de passerelle dans une zone spécifique, la spécification du nombre minimum de répliques de pods de passerelle, la planification des pods de passerelle personnalisés sur les noeuds de périphérie, l'ajout de points d'ancrage de cycle de vie preStop pour les arrêts en douceur et la spécification de l'anti-affinité et de l'affinité des noeuds worker.

Consultez des exemples de ces personnalisations supplémentaires dans le fichier YAML IOP suivant.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: ibm-operators
  name: custom-ingressgateway-iop
spec:
  profile: empty
  hub: icr.io/ext/istio
  # tag: 1.29.5 # Force the gateway to a specific managed Istio version
  components:
    ingressGateways:
      - name: custom-ingressgateway
        label:
          istio: custom-ingressgateway
        namespace: custom-gateways
        enabled: true
        k8s:
          serviceAnnotations:
            service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: public
            service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12" # Deploy the load balancer to a specific zone in your cluster
          hpaSpec: # Specify the minimum number of pod replicas
            minReplicas: 2
          tolerations: # Schedule the custom gateway pods onto edge nodes
          - key: dedicated
            value: edge
          env:
          - name: TERMINATION_DRAIN_DURATION
            value: 30s
          affinity:
            podAntiAffinity:
              preferredDuringSchedulingIgnoredDuringExecution:
              - podAffinityTerm:
                  labelSelector:
                    matchExpressions:
                    - key: app
                      operator: In
                      values:
                      - istio-ingressgateway
                  topologyKey: kubernetes.io/hostname
                weight: 100
            nodeAffinity: # Example node affinities to control the zone or the edge
              preferredDuringSchedulingIgnoredDuringExecution: # Could be requiredDuringSchedulingIgnoredDuringExecution instead
                nodeSelectorTerms:
                - matchExpressions:
                  - key: ibm-cloud.kubernetes.io/zone
                    operator: In
                    values:
                    - "dal12" # Deploy the load balancer to a specific zone in your cluster
              preferredDuringSchedulingIgnoredDuringExecution:
              - preference:
                  matchExpressions:
                  - key: dedicated
                    operator: In
                    values:
                    - edge
                weight: 100

Création d'une passerelle de sortie personnalisée

À partir de la version 1.8 du module complémentaire Istio géré, vous pouvez créer des passerelles de sortie personnalisées. Ces passerelles servent de point de sortie pour tout le trafic sortant des applications du maillage de services vers des destinations externes.

Par exemple, pour créer une passerelle de sortie personnalisée, vous pouvez appliquer le fichier YAML suivant pour un IOP de votre cluster.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: ibm-operators
  name: custom-egressgateway-iop
spec:
  profile: empty
  hub: icr.io/ext/istio
  # tag: 1.29.5 # Force the Gateway to a specific version
  components:
    egressGateways:
      - name: custom-egressgateway
        label:
          istio: custom-egressgateway
        namespace: custom-gateways
        enabled: true

Pour plus d'informations sur la configuration et l'utilisation des passerelles de sortie personnalisées, consultez la documentation open source de l' Istio.

Désactivation des passerelles par défaut

Si vous n'avez pas besoin des déploiements istio-ingressgateway ou istio-egressgateway par défaut après avoir créé des passerelles personnalisées, vous pouvez éventuellement les désactiver.

Si vous souhaitez que vos applications soient accessibles aux clients, assurez-vous qu'au moins un équilibreur de charge de passerelle est activé et configuré pour acheminer le trafic vers vos applications. Si vous désactivez les équilibreurs de charge de passerelle par défaut dans toutes les zones, votre application n'est plus exposée et n'est plus accessible en externe.

1. Editez la ressource de mappe de configuration managed-istio-custom.

   kubectl edit cm managed-istio-custom -n ibm-operators
   

2. Désactivez les passerelles d'entrée par défaut en définissant les zones istio-ingressgateway-public-1|2|3-enabled sur "false".

   istio-ingressgateway-public-1-enabled: "false"
   istio-ingressgateway-public-2-enabled: "false"
   istio-ingressgateway-public-3-enabled: "false"
   

3. Pour désactiver la passerelle de sortie par défaut, ajoutez la zone istio-egressgateway-public-1-enabled: "false".

   istio-egressgateway-public-1-enabled: "false"
   

4. Sauvegardez et fermez le fichier de configuration.

5. Vérifiez que les services de la passerelle par défaut sont supprimés.

   kubectl get svc -n istio-system