Cambia a una versión inferior de Anthos Service Mesh local

En esta guía, se explica cómo cambiar Anthos Service Mesh de la versión 1.5.10 a la versión 1.4.10 en GKE on VMware.

Precaución: Cambiar a una versión inferior es una acción perjudicial para tu clúster y debes planificarlo en consecuencia.

La tarea de volver a implementar los componentes del plano de control de Anthos Service Mesh lleva entre 5 y 10 minutos en completarse. Además, debes incorporar proxies de sidecar nuevos en todas tus cargas de trabajo para que se actualicen con la versión actual de Anthos Service Mesh. El tiempo que lleva actualizar los proxies de sidecar depende de muchos factores, como la cantidad de pods, la cantidad de nodos, la configuración de escalamiento de la implementación, los presupuestos de interrupción de pods y otros ajustes de configuración. Una estimación aproximada del tiempo que lleva actualizar los proxies de sidecar es de 100 pods por minuto.

Descripción general del cambio a una versión inferior

En esta sección, se describen los pasos que debes seguir para cambiar Anthos Service Mesh a una versión inferior.

1. Revisa las funciones compatibles y esta guía para familiarizarte con las funciones y el proceso de cambio a una versión inferior.

2. Si habilitaste las funciones opcionales cuando instalaste la versión anterior de Anthos Service Mesh, debes habilitar las mismas funciones cuando cambies a una versión inferior. Para habilitar funciones opcionales, agrega marcas --set values o especifica la marca -f con un archivo YAML cuando ejecutes el comando istioctl apply.

   Precaución: Si se omiten las marcas --set values o -f con el archivo YAML, la instalación se realiza de forma adecuada. Sin embargo, tendrá una configuración diferente a la que esperabas, ya que los valores omitidos se restablecen a sus valores predeterminados cuando se vuelve a implementar Anthos Service Mesh. Debes usar las mismas marcas cuando ejecutes istioctl apply para cambiar a la versión inferior 1.5.10.

   Si estás pasando de la versión anterior de la malla de servicios de Anthos1.5.10 a1.4.10 y habilitaste funciones opcionales en un archivo YAML, debes convertir el archivo YAMLAPI de IstioOperator por elAPI de IstioControlPlane.

3. Programa un tiempo de inactividad. El cambio a una versión inferior puede tomar hasta 1 hora, según la escala del clúster. Ten en cuenta que esto no incluye el tiempo que necesitas volver a implementar las cargas de trabajo para actualizar los proxies de sidecar.

Configura tu entorno

En tu máquina local, instala e inicializa la CLI de Google Cloud.

Nota: Actualizar y quitar componentes con gcloud components se inhabilita si instalas la CLI de gcloud con apt-get o yum. Para administrar la CLI de gcloud en este caso, sigue usando la herramienta de administración de paquetes que usaste durante la instalación para actualizar o quitar los componentes.

Si ya tienes instalada la CLI de gcloud, haz lo siguiente:

1. Autentica con la CLI de gcloud:

   gcloud auth login
   

2. Actualiza los componentes:

   gcloud components update
   

3. Instala kubectl:

   gcloud components install kubectl
   

4. Obtén el ID del proyecto en el que se creó el clúster:

   gcloud

   gcloud projects list

   Consola

   1. En la consola de Google Cloud, ve a la página Panel:

      Ir a la página Panel

   2. Haz clic en la lista desplegable Seleccionar una opción en la parte superior de la página. En la ventana Seleccionar una opción que aparece, elige tu proyecto. El ID del proyecto se muestra en la tarjeta de Información del proyecto del panel del proyecto.

5. Configura el ID del proyecto predeterminado para Google Cloud CLI:

   gcloud config set project PROJECT_ID

Configura credenciales y permisos

1. Asegúrate de tener kubectl para el clúster de usuario de GKE on VMware en el que deseas instalar Anthos Service Mesh. Ten en cuenta que solo puedes instalar Anthos Service Mesh en un clúster de usuario, no en uno de administrador.
2. Otorga permisos de administrador de clúster al usuario actual. Estos permisos se requieren a fin de crear las reglas de control de acceso basado en funciones (RBAC) necesarias para Anthos Service Mesh:

   kubectl create clusterrolebinding cluster-admin-binding \
     --clusterrole=cluster-admin \
     --user="$(gcloud config get-value core/account)"

   Si ves el error "cluster-admin-binding" already exists, puedes ignorarlo sin problemas y continuar con la vinculación del administrador del clúster existente.

Descarga el archivo de instalación

Linux

Descarga el archivo de instalación de Anthos Service Mesh en el directorio de trabajo actual:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-linux.tar.gz

Descarga el archivo de firma y usa openssl para verificar la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-linux.tar.gz.1.sig
openssl dgst -verify - -signature istio-1.4.10-asm.18-linux.tar.gz.1.sig istio-1.4.10-asm.18-linux.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

El resultado esperado es: Verified OK.

Extrae el contenido del archivo a cualquier ubicación en tu sistema de archivos. Por ejemplo, para extraer el contenido en el directorio de trabajo actual, ingresa este comando:

tar xzf istio-1.4.10-asm.18-linux.tar.gz

El comando crea un directorio de instalación en tu directorio de trabajo actual llamado istio-1.4.10-asm.18 que contiene lo siguiente:

• Aplicaciones de muestra en samples
• Las siguientes herramientas del directorio bin:
  • istioctl: Usa istioctl para instalar Anthos Service Mesh.
  • asmctl: Usa asmctl para ayudar a validar la configuración de seguridad después de instalar Anthos Service Mesh. Por el momento, asmctl no es compatible con GKE en VMware.

macOS

Descarga el archivo de instalación de Anthos Service Mesh en el directorio de trabajo actual:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-osx.tar.gz

Descarga el archivo de firma y usa openssl para verificar la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.4.10-asm.18-osx.tar.gz.1.sig istio-1.4.10-asm.18-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

El resultado esperado es: Verified OK.

Extrae el contenido del archivo a cualquier ubicación en tu sistema de archivos. Por ejemplo, para extraer el contenido en el directorio de trabajo actual, ingresa este comando:

tar xzf istio-1.4.10-asm.18-osx.tar.gz

El comando crea un directorio de instalación en tu directorio de trabajo actual llamado istio-1.4.10-asm.18 que contiene lo siguiente:

• Aplicaciones de muestra en samples
• Las siguientes herramientas del directorio bin:
  • istioctl: Usa istioctl para instalar Anthos Service Mesh.
  • asmctl: Usa asmctl para ayudar a validar la configuración de seguridad después de instalar Anthos Service Mesh. Por el momento, asmctl no es compatible con GKE en VMware.

Windows

Descarga el archivo de instalación de Anthos Service Mesh en el directorio de trabajo actual:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-win.zip

Descarga el archivo de firma y usa openssl para verificar la firma:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-win.zip.1.sig
openssl dgst -verify - -signature istio-1.4.10-asm.18-win.zip.1.sig istio-1.4.10-asm.18-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

El resultado esperado es: Verified OK.

Extrae el contenido del archivo a cualquier ubicación en tu sistema de archivos. Por ejemplo, para extraer el contenido en el directorio de trabajo actual, ingresa este comando:

tar xzf istio-1.4.10-asm.18-win.zip

El comando crea un directorio de instalación en tu directorio de trabajo actual llamado istio-1.4.10-asm.18 que contiene lo siguiente:

• Aplicaciones de muestra en samples
• Las siguientes herramientas del directorio bin:
  • istioctl: Usa istioctl para instalar Anthos Service Mesh.
  • asmctl: Usa asmctl para ayudar a validar la configuración de seguridad después de instalar Anthos Service Mesh. Por el momento, asmctl no es compatible con GKE en VMware.

1. Asegúrate de estar en el directorio raíz de la instalación de Anthos Service Mesh.

   cd istio-1.4.10-asm.18

2. Para mayor comodidad, agrega las herramientas que contiene el directorio /bin a tu ruta de acceso (PATH).

   export PATH=$PWD/bin:$PATH

Cambia a una versión inferior de Anthos Service Mesh

En esta sección, se explica cómo cambiar Anthos Service Mesh a una versión anterior y habilitar las funciones predeterminadas compatibles enumeradas en la página Funciones compatibles. Para obtener información sobre cómo habilitar las funciones opcionales compatibles, consulta Habilita funciones opcionales.

Para instalar Anthos Service Mesh, ejecuta este comando:

Elige uno de los siguientes comandos para configurar Anthos Service Mesh en el modo de autenticación PERMISSIVE de mutual TLS (mTLS) o el modo STRICT de mTLS.

PERMISSIVE de mTLS

istioctl manifest apply --set profile=asm-onprem

Precaución: En el modo PERMISSIVE, tus servicios pueden aceptar tráfico de texto simple y tráfico TLS mutuo al mismo tiempo, y enviar tráfico de texto sin formato en forma simultánea de forma predeterminada. Para proteger tu malla de servicios después del cambio, migra tus servicios al modo STRICT mutuo de TLS, como se describe en Migración de TLS mutua.

STRICT de mTLS

istioctl manifest apply --set profile=asm-onprem \
  --set values.global.mtls.enabled=true

Verifica los componentes del plano de control

El cambio a una versión inferior requiere reinstalar los componentes del plano de control, lo que lleva entre 5 y 10 minutos en completarse. Los componentes del plano de control anteriores se finalizan y, luego, se borran a medida que se instalan los componentes nuevos. Para verificar el progreso, observa el valor en la columna AGE de las cargas de trabajo.

kubectl get pod -n istio-system

Resultado de ejemplo

NAME                                      READY   STATUS       RESTARTS   AGE
istio-citadel-64f6d7c7c7-jtmw7            1/1     Running      0          38s
istio-galley-6b4878d445-c4rtt             1/2     Running      0          37s
istio-ingressgateway-7866c5c88f-llp28     0/1     Running      0          37s
istio-ingressgateway-7866c5c88f-m9sck     1/1     Terminating  0          25m
istio-pilot-7f4fdcb89c-r98jl              1/2     Running      0          37s
istio-sidecar-injector-65cbd565b9-q4wm9   1/1     Running      0          37s
promsd-78dfdf7c7d-2bhr6                   2/2     Running      1          37s

En este ejemplo, hay dos instancias de istio-ingressgateway. Se finalizará la instancia con 25m en la columna AGE. Todos los demás componentes están recién instalados.

Actualiza los proxies de sidecar

Todas las cargas de trabajo que se ejecutan en tu clúster antes de instalar Anthos Service Mesh deben tener el proxy de sidecar incorporado o actualizado para que tengan la versión actual de Anthos Service Mesh.

Precaución: A menos que tengas un balanceador de cargas o un router configurado para implementaciones azul-verde, asegúrate de probar reiniciar los Pods en un entorno de etapa de pruebas a fin de verificar que los servicios puedan controlar cualquier posible interrupción del tráfico.

Con la incorporación automática de sidecars, puedes actualizar los sidecars de pods existentes con un reinicio de pods. La forma en la que reinicias los pods dependerá de si se crearon como parte de un objeto Deployment.

1. Si usaste un Deployment, debes reiniciarlo para que reinicie todos los pods con sidecars:

   kubectl rollout restart YOUR_DEPLOYMENT -n YOUR_NAMESPACE

   Si no usaste un Deployment, borra los pods, y se volverán a crear de forma automática con sidecars:

   kubectl delete pod -n YOUR_NAMESPACE --all

2. Verifica que todos los pods en el espacio de nombres tengan sidecars incorporados:

   kubectl get pod -n YOUR_NAMESPACE --all

   En el siguiente resultado de ejemplo del comando anterior, observa que la columna READY indica que hay dos contenedores para cada una de tus cargas de trabajo: el contenedor principal y el contenedor del proxy de sidecar.

   NAME                    READY   STATUS    RESTARTS   AGE
   YOUR_WORKLOAD           2/2     Running   0          20s
   ...