Actualizar con Helm
Sigue esta guía para actualizar y configurar una instalación en modo ambient usando Helm. Esta guía asume que ya has realizado una instalación en modo ambient con Helm con una versión anterior de Istio.
Entendiendo las actualizaciones del modo ambient
Todas las actualizaciones de Istio implican la actualización del control plane, el data plane y las CRD de Istio. Debido a que el data plane ambient se divide en dos componentes, el ztunnel y las gateways (que incluyen waypoints), las actualizaciones implican pasos separados para estos componentes. La actualización del control plane y las CRD se trata aquí brevemente, pero es esencialmente idéntica al proceso para actualizar estos componentes en modo sidecar.
Al igual que el modo sidecar, las gateways pueden hacer uso de etiquetas de revisión para permitir un control detallado sobre las actualizaciones (de la gateway), incluidos los waypoints, con controles simples para revertir a una versión anterior del control plane de Istio en cualquier momento. Sin embargo, a diferencia del modo sidecar, el ztunnel se ejecuta como un DaemonSet, un proxy por nodo, lo que significa que las actualizaciones de ztunnel afectan, como mínimo, a un nodo completo a la vez. Si bien esto puede ser aceptable en muchos casos, las aplicaciones with conexiones TCP de larga duración pueden verse interrumpidas. En tales casos, recomendamos usar el acordonamiento y el drenaje de nodos antes de actualizar el ztunnel para un nodo determinado. En aras de la simplicidad, este documento demostrará las actualizaciones in-place del ztunnel, que pueden implicar un breve tiempo de inactividad.
Prerrequisitos
Prepararse para la actualización
Antes de actualizar Istio, recomendamos descargar la nueva versión de istioctl y ejecutar istioctl x precheck para asegurarte de que la actualización sea compatible con tu entorno. La salida debería ser algo como esto:
$ 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/>Ahora, actualiza el repositorio de Helm:
$ helm repo update istioOrganiza tus etiquetas y revisiones
Para actualizar una malla en modo ambient de manera controlada, recomendamos que tus gateways y namespaces usen la etiqueta istio.io/rev para especificar una etiqueta de revisión para controlar qué versiones de gateway y control plane se usarán para administrar el tráfico de tus workloads. Recomendamos dividir tu cluster de producción en múltiples etiquetas para organizar tu actualización. Todos los miembros de una etiqueta determinada se actualizarán simultáneamente, por lo que es aconsejable comenzar la actualización con tus aplicaciones de menor riesgo. No recomendamos hacer referencia a las revisiones directamente a través de etiquetas para las actualizaciones, ya que este proceso puede resultar fácilmente en la actualización accidental de una gran cantidad de proxies y es difícil de segmentar. Para ver qué etiquetas y revisiones estás usando en tu cluster, consulta la sección sobre la actualización de etiquetas.
Elige un nombre de revisión
Las revisiones identifican instancias únicas del control plane de Istio, lo que te permite ejecutar múltiples versiones distintas del control plane simultáneamente en una sola malla.
Se recomienda que las revisiones permanezcan inmutables, es decir, una vez que se instala un control plane con un nombre de revisión en particular, la instalación no debe modificarse y el nombre de la revisión no debe reutilizarse. Las etiquetas, por otro lado, son punteros mutables a las revisiones. Esto permite que un operador de cluster realice actualizaciones del data plane sin la necesidad de ajustar ninguna etiqueta de workload, simplemente moviendo una etiqueta de una revisión a la siguiente. Todos los planos de datos se conectarán solo a un control plane, especificado por la etiqueta istio.io/rev (que apunta a una revisión o una etiqueta), o por la revisión predeterminada si no hay ninguna etiqueta istio.io/rev presente. La actualización de un data plane consiste simplemente en cambiar el control plane al que apunta modificando las etiquetas o editando las etiquetas.
Debido a que las revisiones están destinadas a ser inmutables, recomendamos elegir un nombre de revisión que se corresponda con la versión de Istio que estás instalando, como 1-22-1. Además de elegir un nuevo nombre de revisión, debes anotar tu nombre de revisión actual. Puedes encontrarlo ejecutando:
$ kubectl get mutatingwebhookconfigurations -l 'istio.io/rev,!istio.io/tag' -L istio\.io/rev
$ # Almacena tu revisión y nueva revisión en variables:
$ export REVISION=istio-1-22-1
$ export OLD_REVISION=istio-1-21-2Actualizar el control plane
Componentes base
Las Definiciones de Recursos Personalizados (CRD) de todo el cluster deben actualizarse antes del despliegue de una nueva versión del control plane:
$ helm upgrade istio-base istio/base -n istio-systemcontrol plane istiod
El control plane Istiod gestiona y configura los proxies que enrutan el tráfico dentro de la malla. El siguiente comando instalará una nueva instancia del control plane junto con la actual, pero no introducirá nuevos proxies de gateway o waypoints, ni tomará el control de los existentes.
Si has personalizado tu instalación de istiod, puedes reutilizar el archivo values.yaml de actualizaciones o instalaciones anteriores para mantener la coherencia de tus planos de control.
$ helm upgrade istiod istio/istiod -n istio-system --wait$ helm install istiod-"$REVISION" istio/istiod -n istio-system --set revision="$REVISION" --set profile=ambient --waitAgente de nodo CNI
El agente de nodo CNI de Istio es responsable de detectar los pods agregados a la malla ambient, informar a ztunnel que se deben establecer los puertos de proxy dentro de los pods agregados y configurar la redirección del tráfico dentro del namespace de red del pod. No forma parte del data plane ni del control plane.
El CNI en la versión 1.x es compatible con el control plane en la versión 1.x+1 y 1.x. Esto significa que el control plane debe actualizarse antes que el CNI de Istio, siempre que la diferencia de versión sea de una versión menor.
$ helm upgrade istio-cni istio/cni -n istio-systemActualizar el data plane
DaemonSet de ztunnel
El DaemonSet de ztunnel es el componente de proxy de nodo. El ztunnel en la versión 1.x es compatible con el control plane en la versión 1.x+1 y 1.x. Esto significa que el control plane debe actualizarse antes que ztunnel, siempre que la diferencia de versión sea de una versión menor. Si has personalizado previamente tu instalación de ztunnel, puedes reutilizar el archivo values.yaml de actualizaciones o instalaciones anteriores para mantener la coherencia de tu data plane.
$ helm upgrade ztunnel istio/ztunnel -n istio-system --wait$ helm upgrade ztunnel istio/ztunnel -n istio-system --set revision="$REVISION" --waitActualizar el chart de la gateway desplegado manualmente (opcional)
Las Gateway que se desplegaron manualmente deben actualizarse individualmente usando Helm:
$ helm upgrade istio-ingress istio/gateway -n istio-ingressActualizar waypoints y gateways usando etiquetas
Si has seguido las mejores prácticas, todas tus gateways, workloads y namespaces usan la revisión predeterminada (efectivamente, una etiqueta llamada default), o la etiqueta istio.io/rev con el valor establecido en un nombre de etiqueta. Ahora puedes actualizar todos estos a la nueva versión del data plane de Istio moviendo sus etiquetas para que apunten a la nueva versión, una a la vez. Para listar todas las etiquetas en tu cluster, ejecuta:
$ kubectl get mutatingwebhookconfigurations -l 'istio.io/tag' -L istio\.io/tag,istio\.io/revPara cada etiqueta, puedes actualizar la etiqueta ejecutando el siguiente comando, reemplazando $MYTAG con tu nombre de etiqueta y $REVISION con tu nombre de revisión:
$ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{$MYTAG}" --set revision="$REVISION" -n istio-system | kubectl apply -f -Esto actualizará todos los objetos que hacen referencia a esa etiqueta, excepto aquellos que usan el modo de despliegue manual de la gateway, que se tratan a continuación, y los sidecars, que no se usan en el modo ambient.
Se recomienda que supervises de cerca la salud de las aplicaciones que usan el data plane actualizado antes de actualizar la siguiente etiqueta. Si detectas un problema, puedes revertir una etiqueta, restableciéndola para que apunte al nombre de tu revisión anterior:
$ helm template istiod istio/istiod -s templates/revision-tags.yaml --set revisionTags="{$MYTAG}" --set revision="$OLD_REVISION" -n istio-system | kubectl apply -f -Actualizar las gateways desplegadas manualmente (opcional)
Las Gateway que se desplegaron manualmente deben actualizarse individualmente usando Helm:
$ helm upgrade istio-ingress istio/gateway -n istio-ingressDesinstalar el control plane anterior
Si has actualizado todos los componentes del data plane para usar la nueva revisión del control plane de Istio y estás satisfecho de que no necesitas revertir, puedes eliminar la revisión anterior del control plane ejecutando:
$ helm delete istiod-"$OLD_REVISION" -n istio-system