Actualizar Istio on GKE

Esta guía contiene notas de actualización para las versiones que tengan instrucciones de actualización específicas. No debes hacer nada para las actualizaciones que no se mencionan en esta guía.

Actualiza el operador basado en la versión 1.6 de Istio a la versión más reciente del parche

Asegúrate de usar un clúster de GKE en ejecución:

  • 1.17.17-gke.3100 o posterior.
  • 1.18.16-gke.1600 o posterior.
  • 1.19.8-gke.1600 o posterior.

Si no es así, sigue las instrucciones de actualización para actualizar el clúster.

A fin de aplicar un parche a tu imagen de implementación de istio-operator 1.6, ejecuta los siguientes comandos en una estación de trabajo configurada para conectarse al clúster de Istio on GKE.

  1. Crea una copia de seguridad de la versión actual de la imagen del operador:

    kubectl -n istio-operator get deployment/istio-operator -o \
    jsonpath={.spec.template.spec.containers..image} > operator-image-backup
    
    more operator-image-backup
    
  2. Identifica la versión a la que deseas actualizar. Por ejemplo, si deseas actualizar Istio on GKE a 1.6.14-gke.5, ejecuta el siguiente comando:

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

    Ten en cuenta que el plano de control y la istio-ingressgateway se actualizarán de forma automática.

  3. Reinicia tus cargas de trabajo para volver a incorporar los nuevos proxies de Envoy.

Si tienes problemas y deseas revertir, ejecuta lo siguiente:

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

Actualiza 1.4 Istio a la versión más reciente del parche

A fin de actualizar tu Istio 1.4, ejecuta los siguientes comandos en una estación de trabajo configurada para conectarse al clúster de Istio on GKE.

  1. Crea una copia de seguridad de tu imagen de implementación actual con el siguiente comando:

    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. Configura una variable de entorno en la versión de Istio a la que deseas actualizar, por ejemplo, ejecuta el siguiente comando para configurarla en 1.4.10-gke.17:

    export ISTIO_VERSION=1.4.10-gke.17
    
  3. Actualiza la versión de la imagen de implementación del complemento de 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. Obtén el mapa de configuración del inyector de sidecar:

    kubectl get configmap -n istio-system istio-sidecar-injector -oyaml > sidecar-injector.yaml
    
  5. Reemplaza toda la presencia de la versión original de la imagen por la versión de Istio de destino:

    sed -i -- "s/${ORIGINAL_ISTIO_VERSION}/${ISTIO_VERSION}/g" sidecar-injector.yaml
    
  6. Aplica el mapa de configuración actualizado:

    kubectl apply -f sidecar-injector.yaml
    
  7. Reinicia tus cargas de trabajo para volver a incorporar los nuevos proxies de Envoy.

Si tienes problemas y deseas revertirlos, puedes ejecutar los mismos pasos con ISTIO_VERSION configurado en la versión anterior.

Actualiza desde Istio 1.1.3

La versión 1.1.3-gke.0 del complemento de Istio on GKE tiene definiciones PodDisruptionBudget (PDB) que requieren la cantidad mínima de réplicas disponibles para ser al menos 1. A partir de la versión 1.1.7-gke.0, el complemento ya no tiene este requisito. Sin embargo, una vez que se instala este PDB, se evita actualizar a cualquier otra versión si se infringe el PDB. Esto significa que para actualizar de 1.1.3-gke.0 a cualquier versión posterior 1.1.x (como 1.1.7-gke.0), primero es necesario aumentar elminReplicas Valor para todos los IstioHorizontalPodAutoscaler recursos a al menos 2; de lo contrario, la actualización fallará debido aPodDisruptionBudget incumplimiento.

Actualiza a Istio 1.1

Antes de actualizar un clúster de GKE de 1.0.x a 1.1.x, debes asegurarte de que tu configuración sea compatible con 1.1. Los siguientes cambios en Istio 1.1 son potencialmente incompatibles con versiones anteriores y podría requerir que actualices tu configuración para evitar fallas o comportamientos inesperados. Te recomendamos que ejecutes nuestra secuencia de comandos de actualización para ayudarte a verificar la configuración.

Anulación del comportamiento de TLS mediante anotaciones

En la versión 1.0, modificas la política de TLS a través de anotaciones. En la versión 1.1, estas anotaciones no funcionan y requieren que configures una política y DestinationRule. Consulta el documento de Istio para obtener más información.

Proceso de actualización

Reemplaza las anotaciones por una Política y DestinationRule, según los documentos de Istio. Este cambio no afecta tu configuración de 1.0. Después de actualizar a 1.1, las anotaciones anteriores no tendrán ningún efecto, por lo que puedes borrar las anotaciones anteriores o dejarlas en su lugar.

Cambio de nombre de RbacConfig a ClusterRbacConfig

El nombre de la CRD de RbacConfig se cambió por ClusterRbacConfig. El esquema no cambia.

Proceso de actualización

Crea un CR de ClusterRbacConfig idéntico para cada CR de RbacConfig.

Prioridad de la regla de destino

Durante el enrutamiento de archivo adicional a un servicio, las reglas de destino para el servicio de destino en el mismo espacio de nombres que el archivo adicional tienen prioridad, seguidas de las reglas de destino en el espacio de nombres del servicio y, por último, seguidas de las reglas de destino en otros espacios de nombres, si corresponde.

Proceso de actualización

Verifica las DestinationRules a fin de ver si tienen reglas en varios espacios de nombres para el mismo servicio de destino. Si es así, examina las reglas con atención para ver cómo se superponen y asegúrate de que se aplique la prioridad correcta para el comportamiento deseado.