Se usó la API de Cloud Translation para traducir esta página.
Switch to English

Actualizar a Istio 1.6 con el Operador

A partir de la versión 1.6, el complemento Istio en Google Kubernetes Engine usa el operador de Istio para la instalación y la configuración . El operador de Istio sigue el patrón de operador de Kubernetes. El Operador te permite configurar Istio especificando una definición personalizada de recurso (CRD) de Kubernetes para la instalación de Istio. Luego, el Operador usa un controlador para realizar cambios en la instalación a fin de que coincida con el recurso personalizado.

Cuando actualizas tu clúster a la versión 1.17.9-gke.6300 o una superior, el Operador y el plano de control de Istio 1.6 se instalan junto con el plano de control existente de Istio 1.4.x. La actualización requiere que el usuario realice acciones y siga el proceso de actualización del plano de control dual (denominado “actualizaciones canary” en la documentación de Istio). Con una actualización del plano de control dual, puedes migrar a la versión 1.6 configurando una etiqueta en tus cargas de trabajo para hacer referencia al nuevo plano de control y realizar un reinicio progresivo.

No se lanzará una versión 1.5 del complemento Istio on GKE. La versión 1.6 es la que se lanzará después de la 1.4.10.

  • La actualización del clúster a la versión 1.17 o superior de GKE hace que la puerta de enlace de entrada integrada no esté disponible durante unos 5 minutos durante el proceso de actualización y provoca que se pierdan las modificaciones del usuario en la Implementación de entrada. Recomendamos instalar y administrar puertas de enlace independientes definidas por el usuario para evitar este problema, como se describe en Agrega puertas de enlace.
  • Existe un problema conocido con la actualización de las versiones de GKE 1.16 a 1.17 y 1.18 anteriores a R33. Una solución está disponible en las versiones 1.17.12-gke.1501 o versiones posteriores y 1.18.9-gke.1501 o versiones posteriores. El problema hace que se borren los recursos personalizados que creaste en el espacio de nombres istio-system durante la actualización. Estos recursos se deben volver a crear de forma manual. Asegúrate de actualizar solo a una versión afectada. El problema solo ocurre durante las actualizaciones, por lo que los clústeres nuevos no se ven afectados.

Beneficios del Operador de Istio

El Operador aumenta la configurabilidad de la instalación. En las versiones del complemento anteriores a la 1.6, el administrador del complemento de GKE concilia cualquier cambio en el manifiesto de Istio y evita la mayoría de los tipos de cambios de configuración. El Operador de Istio no tiene esta limitación. Este genera un manifiesto de instalación del plano de control de Istio según el recurso personalizado (CR) de IstioOperator que proporcionas durante la instalación. Tienes el control total de este CR, y nunca se somete a conciliación.

Después de actualizar a Istio 1.6 con el Operador, puedes migrar del complemento de Istio on GKE a la versión de código abierto de Istio.

Actualizar a Istio 1.6 con el operador

Solo tienes que ejecutar estos pasos una vez para cambiar al Operador. Las actualizaciones posteriores siguen el proceso de actualización del plano de control dual.

  1. Selecciona una versión de GKE que incluya Istio 1.6 (1.17.7-gke.81+, .17.8-gke.6+) y actualiza tu clúster.

    Ten en cuenta que el complemento Istio on Google Kubernetes Engine con Istio 1.6 instala dos versiones de la plataforma:

    • La versión del manifiesto estático controlada por el administrador de complementos (que está activa después de que actualices el clúster).

    • La versión 1.6 controlada por el Operador (que está inactiva hasta que se habilita). La versión 1.6 inactiva no se conecta a ningún proxy y consume recursos mínimos del clúster.

    Si la versión de Istio instalada actualmente difiere de la versión indicada en el manifiesto estático de destino, actualizar el clúster también puede realizar una actualización in situ de Istio. Por ejemplo, si tu clúster ejecuta Istio 1.4.6-gke.0, y seleccionas la versión 1.17.7-gke.8, tu plano de control de Istio se actualiza a la versión 1.4.10-gke.0 (o una versión posterior) como parte de la actualización.

  2. Verifica que la versión 1.6 de Istio esté instalada y en ejecución:

    kubectl get pods -n istio-system
    

    Deberías ver un Pod istiod en estado Activo junto con los componentes del plano de control 1.4, por ejemplo:

    NAME                                             READY   STATUS      RESTARTS   AGE
    istio-citadel-78b9b5b589-52cqg                   1/1     Running     0          4m16s
    istio-galley-79bd448645-zxfjm                    1/1     Running     0          4m16s
    istio-ingressgateway-b4f8986c4-dbr6c             1/1     Running     0          4m27s
    istio-pilot-dc558d859-cnrqt                      2/2     Running     1          4m16s
    istio-policy-8664dd6c4-m42xs                     2/2     Running     1          4m15s
    istio-security-post-install-1.4.10-gke.4-255r6   0/1     Completed   0          4m15s
    istio-sidecar-injector-7f85d7f7c4-vt2x9          1/1     Running     0          4m15s
    istio-telemetry-69b6477c5f-4pr6v                 2/2     Running     2          4m15s
    <b>istiod-istio-163-5fccfcf4dd-2p9c8                1/1     Running     0          3m31s</b>
    prometheus-7d9f49d945-4nps2                      2/2     Running     0          3m17s
    promsd-696bcc5b96-ln2s8                          2/2     Running     1          4m15s
    
  3. Asegúrate de que migraste cualquier objeto de configuración de política de seguridad v1alpha1 no admitido. Para obtener más información, consulta las Notas de actualización de Istio.

  4. Inhabilita la validación de configuración en el plano de control 1.4.x:

    1. Edita el recurso ClusterRole de Galley:

      kubectl edit clusterrole -n istio-system istio-galley-istio-system
      
    2. Cambia el valor '*' a get en la siguiente entrada de lista:

      - apiGroups:
        - admissionregistration.k8s.io
        resources:
        - validatingwebhookconfigurations
        verbs:
        - '*' # change this to get
      

      Después de la actualización, el código debería ser similar al siguiente:

      - apiGroups:
        - admissionregistration.k8s.io
        resources:
        - validatingwebhookconfigurations
        verbs:
        - get
      
    3. Borra el recurso ValidatingWebhookConfiguration de Galley:

      kubectl delete ValidatingWebhookConfiguration istio-galley -n istio-system
      

Migra un espacio de nombres a la versión 1.6

Cuando se instala la revisión nueva, los proxies de sidecar existentes no se ven afectados. Para actualizarlos, debes configurarlos a fin de que apunten al nuevo plano de control. Esto se controla durante la incorporación de sidecar en función de la etiqueta del espacio de nombres istio.io/rev.

  1. Busca el número exacto de la versión de Istio 1.6:

    kubectl -n istio-system get pods -lapp=istiod --show-labels

    El resultado del comando es similar al siguiente:

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-istio-163-5fccfcf4dd-2p9c8   1/1     Running   0          22h   app=istiod,istio.io/rev=istio-163,istio=istiod,pod-template-hash=5fccfcf4dd

    En este ejemplo, la versión es istio-163.

  2. Vuelve a etiquetar el espacio de nombres que contiene las cargas de trabajo que quieres trasladar a la versión 1.6. La etiqueta de la versión debe coincidir con la versión del plano de control. En el siguiente comando, reemplaza VERSION por la versión del comando anterior, por ejemplo: istio-163.

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=VERSION --overwrite
  3. Realiza un reinicio progresivo de las cargas de trabajo seleccionadas:

    kubectl rollout restart deployment DEPLOYMENT -n NAMESPACE
  4. Obtén una lista de los Pods del espacio de nombres:

    kubectl get pods -n NAMESPACE
  5. Selecciona uno de los Pods para verificar que se haya inyectado la versión 1.6 del proxy de sidecar a las cargas de trabajo:

    kubectl describe pod -n NAMESPACE YOUR_SELECTED_POD

    El resultado debería mostrar el contenedor del proxy con la versión 1.6, por ejemplo:

    ...
    istio-proxy:
      Container ID:  docker://22f62020ddcc6f8e02d800b5614e02aae2d082ce991c9e3eab9846d9f2cf90f5
      Image:         gcr.io/gke-release/istio/proxyv2:1.6.3-gke.0
    ...
    
  6. Completa la migración de todos los espacios de nombres a la nueva versión de Istio. Repite los pasos 3 a 5 para todos los espacios de nombres de tu carga de trabajo.

Si planeas migrar a Anthos Service Mesh, consulta Da de baja el plano de control anterior.

Para permanecer en el complemento de Istio, realiza los siguientes pasos a fin de migrar las puertas de enlace de entrada a la versión nueva de Istio.

  1. Edita el CR IstioOperator para reemplazar la puerta de enlace de entrada por una de la versión 1.6:

    kubectl edit istiooperators -n istio-system istio-1-6-3-gke-0
    
  2. Cambia la configuración enabled de la puerta de enlace a true:

    ...
    spec:
      components:
        ingressGateways:
        - enabled: false # change this to true
          name: istio-ingressgateway
    
  3. Verifique que el Pod de la puerta de enlace se vuelva a crear con la nueva versión 1.6.

    kubectl get pods -n istio-system -l app=istio-ingressgateway -o yaml | grep image
    

Da de baja el plano de control anterior

Después de que todos los proxies de carga de trabajo usen el plano de control de la versión 1.6, puedes dar de baja el plano de control anterior escalando las réplicas de cada componente anterior a 0.

Sigue estos pasos para reducir la escala vertical de las réplicas:

kubectl scale deploy -n istio-system --replicas=0 \
  istio-citadel istio-galley istio-pilot istio-policy istio-sidecar-injector istio-telemetry prometheus promsd

Los recursos restantes de Istio se pueden dejar en el clúster sin ningún problema.

Si decidiste conservar Istio, ahora puedes editar el CR IstioOperator y actualizar el Operador según tu propia programación. Para obtener más información, consulta la documentación del Operador.

Migra a Anthos Service Mesh

Antes de migrar a Anthos Service Mesh, debes inhabilitar el Operador como se describe a continuación. Después de la migración, aún debes configurar la malla de servicios con el mismo formato de CR IstioOperator que el Operador, pero debes hacerlo con el comando istioctl install cuando quieras cambiar el estado de instalación, en lugar de hacer que el controlador de Operador supervise continuamente el CR IstioOperator en el clúster.

Para migrar a Anthos Service Mesh, usa una secuencia de comandos proporcionada por Google que controla todos los detalles de la preparación de tu proyecto y clúster de Cloud, y, luego, instala Anthos Service Mesh con una versión propia de istioctl install. Si bien recomendamos migrar a Anthos Service Mesh 1.7, puedes migrar a Anthos Service Mesh 1.6 con la versión 1.6 de la secuencia de comandos.

Requisitos

Asegúrate de que tu clúster cumpla con los siguientes requisitos:

  • Su tipo de máquina debe tener, al menos, cuatro CPU virtuales, como e2-standard-4. Si el tipo de máquina del clúster no tiene al menos cuatro CPU virtuales, cámbialo como se describe en Migra cargas de trabajo a diferentes tipos de máquina.

  • La cantidad mínima de nodos depende del tipo de máquina. Anthos Service Mesh requiere al menos ocho CPU virtuales. Si el tipo de máquina tiene cuatro CPU virtuales, el clúster debe tener al menos dos nodos. Si el tipo de máquina tiene ocho CPU virtuales, el clúster solo necesita un nodo. Si necesitas agregar nodos, consulta Cambia el tamaño de un clúster.

  • La secuencia de comandos habilita Workload Identity en tu clúster. Workload Identity es el método recomendado para llamar a las API de Google. Habilitar Workload Identity cambia la forma en que se protegen las llamadas de tus cargas de trabajo a las API de Google, como se describe en Limitaciones de Workload Identity.

  • Para que se los incluya en la malla de servicios, los puertos de servicio deben tener un nombre, y ese nombre debe incluir el protocolo del puerto en la siguiente sintaxis: name: protocol[-suffix], en la que los corchetes indican un sufijo opcional que debe comenzar con un guion. Para obtener más información, consulta Asigna nombres a puertos de servicio.

  • Si instalas Anthos Service Mesh en un clúster privado, debes abrir el puerto 15017 en el firewall para que el webhook se use con la incorporación automática de sidecar y funcione de manera correcta. Para obtener más información, consulta Abre un puerto en un clúster privado.

  • Si creaste un perímetro de servicio en tu organización, es posible que debas agregar el servicio de CA de Mesh al perímetro. Para obtener más información, consulta Agrega la CA de Mesh a un perímetro de servicio.

Planifica la migración

A fin de ayudarte a planificar la migración, revisa Prepara la migración desde Istio.

Inhabilita el Operador

Para evitar que el operador concilie el istio-ingressgateway que instala Anthos Service Mesh, debes inhabilitar el Operador.

Sigue estos pasos para inhabilitar el operador:

  1. Obtén la versión del Operador con el siguiente comando:

    kubectl get istiooperators -n istio-system
    

    El resultado es similar al siguiente:

    NAME                        REVISION     STATUS    AGE
    istio-1-6-11-gke-0          istio-1611   HEALTHY   12h

    En el resultado de muestra, la versión del Operador es istio-1-6-11-gke-0.

  2. Inhabilita el Operador. En el siguiente comando, reemplaza VERSION por la versión del Operador del paso anterior:

    kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"disabled"}}' --type=merge
    

    Este comando impide que el Operador realice cambios en el clúster.

Migra a Anthos Service Mesh

En esta sección, se describe cómo migrar a Anthos Service Mesh con la secuencia de comandos install_asm. Se recomienda que migres a Anthos Service Mesh 1.7, pero se admite la migración a Anthos Service Mesh 1.6.

Migra a 1.7

  1. Instala las herramientas necesarias

  2. Descarga la secuencia de comandos install_asm:

  3. Revisa las opciones y marcas de la secuencia de comandos.

    Si no personalizaste la instalación de Istio y deseas continuar usando Citadel como autoridad certificada (CA), puedes migrar a Anthos Service Mesh con los siguientes argumentos de la secuencia de comandos:

    ./install_asm \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME\
      --cluster_location CLUSTER_LOCATION \
      --mode migrate \
      --ca citadel \
      --enable_apis
    

    Anthos Service Mesh 1.7 también proporciona archivos de superposición disponibles en GitHub para las funciones más comunes, como habilitar la puerta de enlace de salida. Para obtener más información, consulta Habilita funciones opcionales.

  4. Para completar la configuración de Anthos Service Mesh, debes habilitar la inyección automática del archivo adicional y, luego, implementar o volver a implementar las cargas de trabajo.

Migra a 1.6

  1. Instala las herramientas necesarias

  2. Descarga la secuencia de comandos install_asm:

  3. Revisa las opciones y marcas de la secuencia de comandos.

    Si no personalizaste la instalación de Istio y deseas continuar usando Citadel como autoridad certificada (CA), puedes migrar a Anthos Service Mesh con los siguientes argumentos de la secuencia de comandos:

    ./install_asm \
      --project_id PROJECT_ID \
      --cluster_name CLUSTER_NAME\
      --cluster_location CLUSTER_LOCATION \
      --mode migrate \
      --ca citadel \
      --enable_apis
    
  4. Para completar la configuración de Anthos Service Mesh, debes habilitar la inyección automática del archivo adicional y, luego, implementar o volver a implementar las cargas de trabajo.

Después de la migración

Ejecuta el siguiente comando y reemplaza VERSION por la versión del Operador que usaste antes para inhabilitar el Operador:

kubectl patch -n istio-system istiooperator VERSION -p '{"spec":{"profile":"empty"}}'

Este comando vuelve a habilitar el Operador con un perfil empty, lo que hace que quite los recursos que se instalaron antes del clúster. Estos no incluyen las puertas de enlace ni los elementos del plano de control que instaló la secuencia de comandos install_asm.