Mettre à jour Istio sur GKE

Ce guide contient les notes de mise à niveau de toutes les versions ayant des instructions de mise à niveau spécifiques. Aucune action de votre part n'est requise pour les mises à niveau en dehors de celles mentionnées dans ce guide.

Mettre à niveau l'opérateur basé sur Istio 1.6 vers la dernière version de correctif

Assurez-vous que vous utilisez un cluster GKE en cours d'exécution:

  • 1.17.17-gke.3100 ou ultérieure
  • 1.18.16-gke.1600 ou ultérieure
  • 1.19.8-gke.1600 ou ultérieure

Si ce n'est pas le cas, suivez les instructions de mise à niveau pour mettre à niveau votre cluster.

Pour corriger votre image de déploiement istio-operator 1.6, exécutez les commandes suivantes sur un poste de travail configuré pour se connecter au cluster Istio sur GKE.

  1. Sauvegardez la version actuelle de votre image de l'opérateur:

    kubectl -n istio-operator get deployment/istio-operator -o \
    jsonpath={.spec.template.spec.containers..image} > operator-image-backup
    
    more operator-image-backup
    
  2. Identifiez la version vers laquelle vous souhaitez effectuer la mise à jour. Par exemple, si vous souhaitez mettre à niveau Istio sur GKE vers la version 1.6.14-gke.5, exécutez la commande suivante:

    kubectl -n istio-operator set image deployment/istio-operator \
    istio-operator=gcr.io/gke-release/istio/operator:1.6.14-gke.5
    

    Notez que le plan de contrôle et la passerelle istio-ingressgateway seront mis à niveau automatiquement.

  3. Redémarrez vos charges de travail pour injecter à nouveau les nouveaux proxys Envoy.

Si vous rencontrez des problèmes et souhaitez effectuer un rollback, exécutez:

kubectl -n istio-operator set image deployment/istio-operator \
istio-operator=$(cat operator-image-backup)

Mettre à niveau la version 1.4 d'Istio vers la dernière version de correctif

Pour mettre à niveau votre Istio 1.4, exécutez les commandes suivantes sur un poste de travail configuré pour se connecter au cluster Istio sur GKE.

  1. Sauvegardez votre image de déploiement actuelle:

    export ORIGINAL_ISTIO_VERSION=$(kubectl -n  istio-system get deployment/istio-pilot -o \
    jsonpath={.spec.template.spec.containers[0].image} | sed 's/.*://')
    
    echo $ORIGINAL_ISTIO_VERSION
    
  2. Définissez une variable d'environnement sur la version d'Istio que vous souhaitez mettre à niveau. Par exemple, exécutez la commande suivante pour la définir sur 1.4.10-gke.17:

    export ISTIO_VERSION=1.4.10-gke.17
    
  3. Mettez à jour la version de l'image de déploiement du module complémentaire Istio:

    kubectl set image -n istio-system deployment/istio-ingressgateway istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-citadel citadel=gke.gcr.io/istio/citadel:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-galley galley=gke.gcr.io/istio/galley:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-sidecar-injector sidecar-injector-webhook=gke.gcr.io/istio/sidecar_injector:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-pilot discovery=gke.gcr.io/istio/pilot:${ISTIO_VERSION} istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-policy mixer=gke.gcr.io/istio/mixer:${ISTIO_VERSION} istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
    kubectl set image -n istio-system deployment/istio-telemetry mixer=gke.gcr.io/istio/mixer:${ISTIO_VERSION} istio-proxy=gke.gcr.io/istio/proxyv2:${ISTIO_VERSION}
    
  4. Obtenez la carte de configuration de l'injecteur side-car:

    kubectl get configmap -n istio-system istio-sidecar-injector -oyaml > sidecar-injector.yaml
    
  5. Remplacez toute présence de la version d'image d'origine par la version cible d'Istio:

    sed -i -- "s/${ORIGINAL_ISTIO_VERSION}/${ISTIO_VERSION}/g" sidecar-injector.yaml
    
  6. Appliquez la ConfigMap mis à jour:

    kubectl apply -f sidecar-injector.yaml
    
  7. Redémarrez vos charges de travail pour injecter à nouveau les nouveaux proxys Envoy.

Si vous rencontrez des problèmes et souhaitez effectuer un rollback, vous pouvez suivre la même procédure en définissant ISTIO_VERSION sur la version précédente.

Mise à niveau depuis Istio 1.1.3

La version 1.1.3-gke.0 du module complémentaire Istio sur GKE contient des définitions PodDisruptionBudget (PDB) nécessitant que le nombre d'instances dupliquées disponibles soit au moins égal à 1. À partir de la version 1.1.7-gke.0, le module complémentaire ne nécessite plus cette exigence. Toutefois, une fois configurée, cette définition empêche la mise à niveau vers une autre version ne respectant pas le budget d'interruption de pod. Cela signifie que pour pouvoir passer de la version 1.1.3-gke.0 à une version supérieure à la version 1.1.x (par exemple, 1.1.7-gke.0), vous devez d'abord définir la valeur minReplicas de toutes les ressources HorizontalPodAutoscaler sur au moins 2. Sinon, la mise à niveau échoue en raison d'une violation PodDisruptionBudget.

Mise à niveau vers Istio 1.1

Avant de mettre à jour un cluster GKE de la version 1.0.x à 1.1.x, vous devez vous assurer que votre configuration est compatible avec la version 1.1. Les modifications suivantes dans Istio 1.1 sont potentiellement incompatibles avec les versions antérieures et peuvent vous obliger à mettre à jour votre configuration afin d'éviter un dysfonctionnement ou un comportement inattendu. Nous vous recommandons d'exécuter notre script de mise à niveau pour vous aider à vérifier votre configuration.

Ignorer le comportement TLS à l'aide d'annotations

Dans la version 1.0, vous pouvez modifier les règles TLS à l'aide d'annotations. Dans la version 1.1, ces annotations ne fonctionnent pas, et requièrent la configuration d'une stratégie et d'une règle de destination. Pour en savoir plus, consultez la documentation Istio.

Processus de mise à niveau

Remplacez les annotations par une stratégie et une règle de destination, comme décrit dans la documentation Istio. Cette modification n'affecte pas la configuration 1.0. Après avoir effectué la mise à niveau vers la version 1.1, les anciennes annotations n'ont aucun effet. Vous pouvez donc les supprimer ou les conserver.

Remplacement du nom RbacConfig par ClusterRbacConfig

L'objet RbacConfig CRD s'intitule désormais ClusterRbacConfig. Le schéma reste inchangé.

Processus de mise à niveau

Créez une ressource personnalisée ClusterRbacConfig identique pour chaque ressource personnalisée RbacConfig.

Priorité des règles de destination

Lors du routage du side-car vers un service, les règles de destination du service cible qui se trouvent dans le même espace de noms que le side-car ont la priorité, suivies des règles de destination de l'espace de noms du service, puis celles des autres espaces de noms, le cas échéant.

Processus de mise à niveau

Vérifiez vos règles de destination pour savoir si elles possèdent des règles dans plusieurs espaces de noms du même service cible. Si tel est le cas, examinez attentivement les règles afin de voir comment elles se chevauchent et assurez-vous que la priorité appropriée s'applique au comportement souhaité.