Upgrade with Helm

lectura de 7 minutos prueba de página

Follow this guide to upgrade and configure an Istio mesh using Helm. This guide assumes you have already performed an installation with Helm for a previous minor or patch version of Istio.

Los charts de Helm utilizados en esta guía son los mismos que se utilizan al instalar Istio a través de Istioctl, con la excepción del chart gateway.

Istioctl utiliza un chart de gateway diferente al chart de gateway descrito en esta guía.

Prerrequisitos

Realiza cualquier configuración específica de la plataforma necesaria.
Comprueba los Requisitos para Pods y Servicios.
Instala el último cliente de Helm. Las versiones de Helm lanzadas antes de la versión de Istio más antigua actualmente compatible no están probadas, no son compatibles ni se recomiendan.
Configura el repositorio de Helm:

$ helm repo add istio https://istio-release.storage.googleapis.com/charts
$ helm repo update

Upgrade steps

Before upgrading Istio, it is recommended to run the istioctl x precheck command to make sure the upgrade is compatible with your environment.

$ istioctl x precheck
✔ No issues found when checking the cluster. Istio is safe to install or upgrade!
  To get started, check out <https://istio.io/latest/docs/setup/getting-started/>

Canary upgrade (recommended)

You can install a canary version of Istio control plane to validate that the new version is compatible with your existing configuration and data plane using the steps below:

Si actualizas las CRD a través de Helm desde una versión de Istio 1.23 o anterior, puedes encontrar un error como el siguiente

Error: rendered manifests contain a resource that already exists. Unable to continue with update: CustomResourceDefinition "wasmplugins.extensions.istio.io" in namespace "" exists and cannot be imported into the current release: invalid ownership metadata

Puedes resolver esto con una migración única usando los siguientes comandos de kubectl:

$ for crd in $(kubectl get crds -l chart=istio -o name && kubectl get crds -l app.kubernetes.io/part-of=istio -o name)
$ do
$    kubectl label "$crd" "app.kubernetes.io/managed-by=Helm"
$    kubectl annotate "$crd" "meta.helm.sh/release-name=istio-base" # reemplaza con el nombre real de la versión de Helm, si es diferente del predeterminado de la documentación
$    kubectl annotate "$crd" "meta.helm.sh/release-namespace=istio-system" # reemplaza con el namespace real de istio
$ done

Upgrade the Istio base chart to ensure all cluster-wide resources are up-to-date
```
$ helm upgrade istio-base istio/base -n istio-system
```

Install a canary version of the Istio discovery chart by setting the revision value:

$ helm install istiod-canary istio/istiod \
    --set revision=canary \
    -n istio-system

Verify that you have two versions of istiod installed in your cluster:

$ kubectl get pods -l app=istiod -L istio.io/rev -n istio-system
  NAME                            READY   STATUS    RESTARTS   AGE   REV
  istiod-5649c48ddc-dlkh8         1/1     Running   0          71m   default
  istiod-canary-9cc9fd96f-jpc7n   1/1     Running   0          34m   canary

If you are using Istio gateways, install a canary revision of the Gateway chart by setting the revision value:
```
$ helm install istio-ingress-canary istio/gateway \
    --set revision=canary \
    -n istio-ingress
```

Verify that you have two versions of istio-ingress gateway installed in your cluster:

$ kubectl get pods -L istio.io/rev -n istio-ingress
  NAME                                    READY   STATUS    RESTARTS   AGE     REV
  istio-ingress-754f55f7f6-6zg8n          1/1     Running   0          5m22s   default
  istio-ingress-canary-5d649bd644-4m8lp   1/1     Running   0          3m24s   canary

See Upgrading Gateways for in-depth documentation on gateway canary upgrade.

Follow the steps here to test or migrate existing workloads to use the canary control plane.
Once you have verified and migrated your workloads to use the canary control plane, you can uninstall your old control plane:
```
$ helm delete istiod -n istio-system
```
Upgrade the Istio base chart again, this time making the new canary revision the cluster-wide default.
```
$ helm upgrade istio-base istio/base --set defaultRevision=canary -n istio-system
```

Stable revision labels

Reetiquetar manualmente los namespaces al moverlos a una nueva revisión puede ser tedioso y propenso a errores. Las etiquetas de revisión resuelven este problema. Las etiquetas de revisión son identificadores estables que apuntan a revisiones y se pueden usar para evitar reetiquetar namespaces. En lugar de reetiquetar el namespace, un operador de malla puede simplemente cambiar la etiqueta para que apunte a una nueva revisión. Todos los namespaces etiquetados con esa etiqueta se actualizarán al mismo tiempo.

Usage

Considera un cluster con dos revisiones instaladas, 1-26-1 y 1-27-0. El operador del cluster crea una etiqueta de revisión prod-stable, apuntando a la versión más antigua y estable 1-26-1, y una etiqueta de revisión prod-canary apuntando a la revisión más nueva 1-27-0. Ese estado podría alcanzarse a través de los siguientes comandos:

$ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{prod-stable}" --set revision=1-26-1 -n istio-system | kubectl apply -f -
$ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{prod-canary}" --set revision=1-27-0 -n istio-system | kubectl apply -f -

La asignación resultante entre revisiones, etiquetas y namespaces es como se muestra a continuación:

Dos namespaces apuntados a prod-stable y uno apuntado a prod-canary

El operador del cluster puede ver esta asignación además de los namespaces etiquetados a través del comando istioctl tag list:

$ istioctl tag list
TAG         REVISION NAMESPACES
default     1-26-1   ...
prod-canary 1-27-0   ...
prod-stable 1-26-1   ...

Después de que el operador del cluster esté satisfecho con la estabilidad del control plane etiquetado con prod-canary, los namespaces etiquetados istio.io/rev=prod-stable se pueden actualizar con una acción modificando la etiqueta de revisión prod-stable para que apunte a la revisión 1-27-0 más nueva.

$ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{prod-stable}" --set revision=1-27-0 -n istio-system | kubectl apply -f -

Ahora, la asignación actualizada entre revisiones, etiquetas y namespaces es como se muestra a continuación:

Las etiquetas de los namespaces no han cambiado, pero ahora todos los namespaces apuntan a {{< istio_full_version_revision >}}

Reiniciar los workloads inyectadas en los namespaces marcados como prod-stable ahora dará como resultado que esas workloads usen el control plane 1-27-0. Observa que no se requirió ningún reetiquetado de namespace para migrar los workloads a la nueva revisión.

Default tag

La revisión a la que apunta la etiqueta default se considera la revisión predeterminada y tiene un significado semántico adicional. La revisión predeterminada realiza las siguientes funciones:

Inyecta sidecars para el selector de namespace istio-injection=enabled, el selector de objetos sidecar.istio.io/inject=true y los selectores istio.io/rev=default
Valida los recursos de Istio
Roba el bloqueo de líder de las revisiones no predeterminadas y realiza responsabilidades de malla singleton (como actualizar los estados de los recursos)

Para hacer que una revisión 1-27-0 sea la predeterminada, ejecuta:

$ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{default}" --set revision=1-27-0 -n istio-system | kubectl apply -f -

Cuando se utiliza la etiqueta default junto con una instalación de Istio existente sin revisión, se recomienda eliminar la MutatingWebhookConfiguration antigua (normalmente llamada istio-sidecar-injector) para evitar que tanto el control plane antiguo como el más nuevo intenten la inyección.

In place upgrade

You can perform an in place upgrade of Istio in your cluster using the Helm upgrade workflow.

Si actualizas las CRD a través de Helm desde una versión de Istio 1.23 o anterior, puedes encontrar un error como el siguiente

Puedes resolver esto con una migración única usando los siguientes comandos de kubectl:

$ for crd in $(kubectl get crds -l chart=istio -o name && kubectl get crds -l app.kubernetes.io/part-of=istio -o name)
$ do
$    kubectl label "$crd" "app.kubernetes.io/managed-by=Helm"
$    kubectl annotate "$crd" "meta.helm.sh/release-name=istio-base" # reemplaza con el nombre real de la versión de Helm, si es diferente del predeterminado de la documentación
$    kubectl annotate "$crd" "meta.helm.sh/release-namespace=istio-system" # reemplaza con el namespace real de istio
$ done

Upgrade the Istio base chart:

$ helm upgrade istio-base istio/base -n istio-system

Upgrade the Istio discovery chart:

$ helm upgrade istiod istio/istiod -n istio-system

(Optional) Upgrade any gateway charts installed in your cluster:
```
$ helm upgrade istio-ingress istio/gateway -n istio-ingress
```

Uninstall

Please refer to the uninstall section in our Helm install guide.

Ver también

Install with Helm

Instructions to install and configure Istio in a Kubernetes cluster using Helm.

Advanced Helm Chart Customization

Describes how to customize installation configuration options when installing with helm.

Application Requirements

Requirements of applications deployed in an Istio-enabled cluster.

Before you begin

Initial steps before configuring locality load balancing.

Before you begin

Initial steps before installing Istio on multiple clusters.

Canary Upgrades

Upgrade Istio by first running a canary deployment of a new control plane.