Actualiza Anthos Service Mesh en GKE

En esta guía, se explica cómo actualizar Anthos Service Mesh de la versión 1.4.5+ a la versión 1.4.10 en Google Kubernetes Engine. Si quieres actualizar a Anthos Service Mesh 1.5, consulta la versión 1.5 de Actualiza Anthos Service Mesh en GKE.

Precaución: La actualización es una acción perjudicial para tu clúster y debes planificarla según corresponda.

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.

Prepárate para la actualización

En esta sección, se describen los pasos que debes seguir para actualizar Anthos Service Mesh.

1. Revisa las funciones compatibles y esta guía para familiarizarte con las funciones y el proceso de actualización.

2. Revisa las políticas de autorización para ver si deben actualizarse.

3. Si habilitaste las funciones opcionales cuando instalaste la versión anterior de Anthos Service Mesh y agregaste marcas --set values a la línea de comandos de istioctl apply, debes usar las mismas marcas cuando ejecutas istioctl apply para actualizar a 1.4.10.

4. Si habilitaste funciones opcionales cuando instalaste la versión anterior de Anthos Service Mesh, por agregar marcas -f a la línea de comandos istioctl apply con el fin de especificar un archivo YAML, debes especificar el mismo archivo (o un archivo con el mismo contenido) cuando ejecutas istioctl apply para instalar1.4.10.

   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.

5. Programa un tiempo de inactividad. La actualización 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.

Establece valores predeterminados del proyecto y del clúster

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

2. Crea una variable de entorno para el ID del proyecto:

   export PROJECT_ID=YOUR_PROJECT_ID

3. Crea una variable de entorno para el número de proyecto:

   export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} --format="value(projectNumber)")

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

   gcloud config set project ${PROJECT_ID}
   

5. Crea las siguientes variables de entorno:

   • Configura el nombre del clúster:

     export CLUSTER_NAME=YOUR_CLUSTER_NAME

   • Establece CLUSTER_LOCATION en la zona o en la región del clúster:

     export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION

   • Establece el grupo de cargas de trabajo:

     export WORKLOAD_POOL=${PROJECT_ID}.svc.id.goog

   • Establece el ID de la malla:

     export MESH_ID="proj-${PROJECT_NUMBER}"

6. Establece la zona o región predeterminada para Google Cloud CLI.

   • Si tienes un clúster de una sola zona, configura la predeterminada:

     gcloud config set compute/zone ${CLUSTER_LOCATION}

   • Si tienes un clúster regional, configura la región predeterminada:

     gcloud config set compute/region ${CLUSTER_LOCATION}

Configura credenciales y permisos

1. Obtén credenciales de autenticación para interactuar con el clúster:

   gcloud container clusters get-credentials ${CLUSTER_NAME}

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.

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.

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.

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

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

   cd istio-1.4.10-asm.18

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

   export PATH=$PWD/bin:$PATH

Actualiza Anthos Service Mesh

En esta sección, se explica cómo instalar Anthos Service Mesh y habilitar lo siguiente:

• Las funciones predeterminadas compatibles que se muestran en la página Funciones compatibles.
• La autoridad certificada de Anthos Service Mesh (CA de Mesh)
• La canalización de datos de telemetría que potencia los paneles de Anthos Service Mesh en la consola de Google Cloud.

Para obtener información sobre cómo habilitar las características opcionales compatibles, consulta Habilita características opcionales.

Para actualizar Anthos Service Mesh, haz lo siguiente:

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 \
  --set values.global.trustDomain=${WORKLOAD_POOL} \
  --set values.global.sds.token.aud=${WORKLOAD_POOL} \
  --set values.nodeagent.env.GKE_CLUSTER_URL=https://container.googleapis.com/v1/projects/${PROJECT_ID}/locations/${CLUSTER_LOCATION}/clusters/${CLUSTER_NAME} \
  --set values.global.meshID=${MESH_ID} \
  --set values.global.proxy.env.GCP_METADATA="${PROJECT_ID}|${PROJECT_NUMBER}|${CLUSTER_NAME}|${CLUSTER_LOCATION}"

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 de la actualización, 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 \
  --set values.global.trustDomain=${WORKLOAD_POOL} \
  --set values.global.sds.token.aud=${WORKLOAD_POOL} \
  --set values.nodeagent.env.GKE_CLUSTER_URL=https://container.googleapis.com/v1/projects/${PROJECT_ID}/locations/${CLUSTER_LOCATION}/clusters/${CLUSTER_NAME} \
  --set values.global.meshID=${MESH_ID} \
  --set values.global.proxy.env.GCP_METADATA="${PROJECT_ID}|${PROJECT_NUMBER}|${CLUSTER_NAME}|${CLUSTER_LOCATION}" \
  --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

NAME                                     READY   STATUS        RESTARTS   AGE
istio-galley-76d684bf9-jwz65             2/2     Running       0          5m36s
istio-ingressgateway-5bfdf7c586-v6wxx    2/2     Terminating   0          25m
istio-ingressgateway-7b598c5557-b88md    2/2     Running       0          5m44s
istio-nodeagent-bnjg7                    1/1     Running       0          5m16s
istio-nodeagent-cps2j                    1/1     Running       0          5m10s
istio-nodeagent-f4x46                    1/1     Running       0          5m26s
istio-nodeagent-jbl5x                    1/1     Running       0          5m38s
istio-pilot-5dc4bc4dbf-ds5dh             2/2     Running       0          5m30s
istio-pilot-74665549c5-7r6qh             2/2     Terminating   0          25m
istio-sidecar-injector-7ddff4b99-b76l7   1/1     Running       0          5m36s
promsd-6d4d5b7c5c-dgnd7                  2/2     Running       0          5m30s

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

Valida la actualización

Beta

Este producto o función está sujeto a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones específicas del Servicio. Los productos y las funciones que se encuentran en la fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Te recomendamos que uses la herramienta de análisis asmctl para validar la configuración básica del proyecto, el clúster y las cargas de trabajo. Si una prueba asmctl falla, asmctl recomienda soluciones, si es posible. El comando asmctl validate ejecuta pruebas básicas que verifican lo siguiente:

1. Que las API requeridas por Anthos Service Mesh estén habilitadas en el proyecto
2. Que Istio-Ingressgateway esté configurado de forma correcta para que llame a la CA de Mesh
3. El estado general de Istiod e Istio-Ingressgateway

Si ejecutas el comando asmctl validate con la marca opcional --with-testing-workloads, además de las pruebas básicas, asmctl ejecuta pruebas de seguridad que verifican lo siguiente:

1. Que la comunicación mutua de TLS (mTLS) está configurada de forma correcta.
2. Que la CA de Mesh pueda emitir certificados.

Para ejecutar las pruebas de seguridad, asmctl implementa cargas de trabajo en un espacio de nombres de prueba ubicado en tu clúster, ejecuta las pruebas de comunicación de mTLS, muestra los resultados y borra el espacio de nombres de prueba.

Para ejecutar asmctl, sigue estos pasos:

1. Asegúrate de que las credenciales predeterminadas de la aplicación de gcloud estén configuradas:

    gcloud auth application-default login
   

2. Si aún no lo hiciste, obtén las credenciales de autenticación para interactuar con el clúster:

    gcloud container clusters get-credentials ${CLUSTER_NAME}
   

3. Para ejecutar pruebas básicas y de seguridad (en el caso de que istio-1.4.10-asm.18/bin esté en tu PATH), ejecuta este comando:

   asmctl validate --with-testing-workloads
   

   Si se ejecuta de forma correcta, el comando responde con un resultado similar al siguiente:

   [asmctl version 0.3.0]
   Using Kubernetes context: example-project_us-central1-example-cluster
   To change the context, use the --context flag
   Validating enabled APIs
   OK
   Validating ingressgateway configuration
   OK
   Validating istio system
   OK
   Validating sample traffic
   Launching example services...
   Sent traffic to example service http code: 200
   verified mTLS configuration
   OK
   Validating issued certs
   OK
   

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

Actualiza tus políticas de autorización

Si actualizas desde Istio de código abierto 1.4.x o desde una versión anterior de Anthos Service Mesh y tienes políticas de autorización existentes, es posible que debas actualizarlas. Consulta Actualiza tus políticas de autorización para obtener más información.