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 vers la dernière version de correctif d'Istio basée sur l'opérateur 1.6

Veuillez vous assurer 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 l'image de votre 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 istio-ingressgateway seront mis à niveau automatiquement.

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

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

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

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

Pour mettre à niveau 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 vers laquelle vous souhaitez effectuer la mise à 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 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 de side-car:

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

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

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

Si vous rencontrez des problèmes et souhaitez effectuer un rollback, suivez la même procédure avec la version précédente ISTIO_VERSION.

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