Cambia a una versión inferior de Anthos Service Mesh en GKE

En esta guía, se explica cómo cambiar la categoría de la Anthos Service Mesh de 1.5.10 a 1.4.10 en Google Kubernetes Engine.

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.

    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. Si quiere cambiar a la versión 1.4.10 en un clúster privado, debes agregar una regla de firewall para abrir el puerto 9443 si deseas usar la inserción automática de sidecar. Si no agregas la regla de firewall y la inserción automática de sidecar está habilitada, recibirás un error cuando implementes las cargas de trabajo. Si deseas obtener más detalles sobre cómo agregar una regla de firewall, consulta Agrega reglas de firewall para casos de uso específicos.

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

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. Configura el ID del proyecto predeterminado para Google Cloud CLI:

    gcloud config set project ${PROJECT_ID}
    
  4. 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
  5. 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

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

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

  4. macOS

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

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

  8. Windows

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

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

  12. Asegúrate de estar en el directorio raíz de la instalación de Anthos Service Mesh.
    cd istio-1.4.10-asm.18
  13. Para mayor comodidad, agrega las herramientas que contiene el directorio /bin a tu ruta de acceso (PATH).
    export PATH=$PWD/bin:$PATH

Prepara los archivos de configuración de recursos

Cuando ejecutas istioctl apply command para cambiar a una versión inferior de Anthos Service Mesh, especifica -f istio-operator.yaml en la línea de comandos. Este archivo contiene información sobre su proyecto y clúster que se necesita para habilitar las funciones de seguridad y telemetría de Mesh. Debes descargar el archivo de configuración istio-operator.yaml y otros archivos de configuración de recursos, y configurar la información del proyecto y del clúster.

Para preparar los archivos de configuración de recursos, sigue estos pasos:

  1. Si aún no lo hiciste, instala kpt:

    gcloud components install kpt
    
  2. De forma opcional, crea un directorio nuevo para los archivos de configuración de recursos del paquete de Anthos Service Mesh. Si planeas configurar más de un clúster, puede usar el nombre del clúster como el nombre del directorio.

  3. Cambia al directorio en el que deseas descargar el paquete de Anthos Service Mesh.

  4. Descarga el paquete de Anthos Service Mesh en el directorio de trabajo actual:

    kpt pkg get \
    https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.4-asm .
    

  5. Configura el nombre del clúster:

      kpt cfg set asm cluster-name ${CLUSTER_NAME}

  6. De forma opcional, personaliza los archivos de configuración de recursos con los métodos set kpt. De forma predeterminada, estos métodos set usan los valores predeterminados para gcloud config. Si estableces los valores predeterminados de gcloud config o si deseas cambiar los valores, ejecuta los siguientes métodos set:

    • Configura el ID del proyecto:

      kpt cfg set asm gcloud.core.project ${PROJECT_ID}
    • Establece la zona o región predeterminada:

      kpt cfg set asm gcloud.compute.zone ${CLUSTER_LOCATION}
  7. De forma opcional, puedes registrar los archivos de configuración de recursos en tu propio sistema de control de origen, como Cloud Source Repositories, para realizar un seguimiento de los cambios en los archivos.

Cambia a una versión inferior de Anthos Service Mesh

En esta sección, se explica cómo pasar a una versión anterior de Anthos Service Mesh y habilitar:

  • Las funciones predeterminadas compatibles que se muestran en la página Funciones compatibles.
  • La autoridad certificadora 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 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 \
  -f asm/cluster/istio-operator.yaml

STRICT de mTLS

istioctl manifest apply --set profile=asm \
  -f asm/cluster/istio-operator.yaml \
  --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

Salida de ejemplo:

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 instalación

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:

    Using Kubernetes context: meshci145g-20200219_us-central1-a_meshci145g
    To change the context, use the --context flag
    Validating enabled APIs
    OK
    Validating Node-Agent configuration
    OK
    Validating Istio system
    OK
    Validating issued certs
    OK
    Validating sample traffic
    Launching example services...
    Sent traffic to example service http code: 200
    verified mTLS configuration
    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.

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