Aprovisiona Cloud Service Mesh administrado con asmcli

Descripción general

Cloud Service Mesh administrado con asmcli es un plano de control administrado y un plano de datos administrado que puedes configurar con facilidad. Google maneja la confiabilidad, las actualizaciones, el escalamiento y la seguridad de manera retrocompatible. En esta guía, se explica cómo configurar o migrar aplicaciones a Cloud Service Mesh administrado en una configuración de uno o varios clústeres con asmcli.

Para obtener información sobre las funciones admitidas y las limitaciones de Cloud Service Mesh administrado, consulta las funciones admitidas de Cloud Service Mesh administrado.

Requisitos previos

Como punto de partida, en esta página se supone que realizaste las siguientes acciones:

Requisitos

  • Uno o más clústeres con una versión de GKE compatible en una de las regiones admitidas.

  • Ten en cuenta que Cloud Service Mesh administrado usa canales de versiones de GKE para equilibrar la estabilidad y la velocidad de actualización. Los nuevos cambios en los componentes integrados en el clúster de Cloud Service Mesh (incluidos CNI, MDPC, proxies y CRD de Istio) se lanzarán primero en los clústeres que se suscriban al canal rápido de GKE. Luego, se promoverán al canal regular de GKE y, finalmente, al canal estable de GKE, una vez que demuestren suficiente estabilidad.

    • Cloud Service Mesh administrado no admite el cambio seguro de los canales de versiones de GKE.
    • Si cambias el canal de versiones de GKE, Cloud Service Mesh actualizará o degradará automáticamente los componentes del clúster (CNI, MDPC, versión del proxy insertado predeterminado y CRD de Istio) para que se alineen con el canal de versiones de GKE actual.

  • Asegúrate de que tu clúster tenga capacidad suficiente para los componentes requeridos que instala Cloud Service Mesh administrado en el clúster.

    • La implementación de mdp-controller en el espacio de nombres kube-system solicita CPU: 50 m y memoria: 128 Mi.
    • El daemonset istio-cni-node en el espacio de nombres kube-system solicita cpu: 100m, memoria: 100Mi en cada nodo.

  • Asegúrate de que la política de la organización constraints/compute.disableInternetNetworkEndpointGroup esté inhabilitada. Si la política está habilitada, es posible que ServiceEntry no funcione.

  • Asegúrate de que la máquina cliente desde la que aprovisiones Cloud Service Mesh administrada tenga conectividad de red al servidor de API.

  • Tus clústeres deben estar registrados en una flota. Este paso se puede hacer por separado antes del aprovisionamiento o como parte de él si pasas las marcas --enable-registration y --fleet-id.

  • Tu proyecto debe tener habilitada la función de flota de Service Mesh. Puedes habilitarlo como parte del aprovisionamiento si pasas --enable-gcp-components o si ejecutas el siguiente comando:

    gcloud container fleet mesh enable --project=FLEET_PROJECT_ID

    en el que FLEET_PROJECT_ID es el ID del proyecto host de la flota.

  • GKE Autopilot solo es compatible con la versión 1.21.3 y versiones posteriores de GKE.

  • Cloud Service Mesh puede usar varios clústeres de GKE en un entorno de una sola red de un solo proyecto o en un entorno de una sola red de varios proyectos.

Roles necesarios para instalar Cloud Service Mesh

En la siguiente tabla, se describen los roles necesarios para instalar Cloud Service Mesh administrado.

Nombre de la función ID de la función Otorga la ubicación Descripción
Administrador de GKE Hub roles/gkehub.admin Proyecto de flota Acceso completo a GKE Hubs y recursos relacionados.
Administrador de Service Usage roles/serviceusage.serviceUsageAdmin Proyecto de flota Puede inspeccionar, habilitar y también inhabilitar estados de servicio, inspeccionar operaciones junto con cuotas de consumo y facturación para un proyecto de consumidor. (Nota 1)
Administrador del servicio de CA beta roles/privateca.admin Proyecto de flota Tiene acceso completo a todos los recursos del Servicio de CA. (Nota 2)

Roles necesarios para ejecutar Cloud Service Mesh

En la siguiente tabla, se describen los roles que requiere la cuenta de servicio para ejecutar Cloud Service Mesh administrado. Si los proyectos de tu red o clúster difieren del proyecto host de la flota, debes otorgar a la cuenta de servicio del proyecto de la flota acceso a estos roles en los otros proyectos.

Nombre de la función ID de la función Otorga la ubicación Descripción
Agente de servicio de Anthos Service Mesh roles/anthosservicemesh.serviceAgent Proyecto de flota
Agente de servicio del plano de control administrado de Mesh (heredado) roles/meshcontrolplane.serviceAgent Proyecto de flota Esta es una función heredada que formaba parte de instalaciones anteriores de Cloud Service Mesh. Si tu instalación tiene este rol de servicio, puedes dejarlo como está. Las instalaciones nuevas no necesitan este rol.

Limitaciones

Te recomendamos que revises la lista de funciones admitidas y limitaciones de Cloud Service Mesh. En particular, ten en cuenta esta información:

  • La API de IstioOperator no es compatible, ya que su propósito principal es controlar los componentes del clúster.

  • En el caso de los clústeres de GKE Autopilot, la configuración entre proyectos solo es compatible con GKE 1.23 o versiones posteriores.

  • En el caso de los clústeres de GKE Autopilot, para adaptarse al límite de recursos de GKE Autopilot, los límites y las solicitudes de recursos del proxy predeterminados se establecen en 500 m de CPU y 512 MB de memoria. Puedes anular los valores predeterminados con la inserción personalizada.

  • En el caso de los clústeres de GKE Autopilot, es posible que aparezcan advertencias para los componentes de Cloud Service Mesh "DaemonSet has no nodes selected" hasta que se escale el NodePool de los clústeres.

  • Durante el proceso de aprovisionamiento de un plano de control administrado, las CRD de Istio se aprovisionan en el clúster especificado. Si hay CRD de Istio existentes en el clúster, se reemplazarán.

  • Istio CNI y Cloud Service Mesh no son compatibles con GKE Sandbox. Por lo tanto, Cloud Service Mesh administrado con la implementación de TRAFFIC_DIRECTOR no admite clústeres con GKE Sandbox habilitado.

  • La herramienta asmcli debe tener acceso al extremo de Google Kubernetes Engine (GKE). Puedes configurar el acceso a través de un servidor"jump", como una VM de Compute Engine dentro de la nube privada virtual (VPC) que otorga acceso específico.

Antes de comenzar

Configura gcloud

Completa los siguientes pasos incluso si usas Cloud Shell.

  1. Autentica con Google Cloud CLI

    gcloud auth login --project PROJECT_ID

    En el ejemplo anterior, PROJECT_ID es el identificador único del proyecto de tu clúster. Ejecuta el siguiente comando para obtener tu PROJECT_ID:

       gcloud projects list --filter="<PROJECT ID>" --format="value(PROJECT_NUMBER)"
   ```

  2. Actualiza los componentes:

    gcloud components update

  3. Configura kubectl para que apunte al clúster.

    gcloud container clusters get-credentials CLUSTER_NAME \
     --zone CLUSTER_LOCATION \
     --project PROJECT_ID

Descarga la herramienta de instalación

  1. Descarga la versión más reciente de la herramienta en el directorio de trabajo actual:

    curl https://storage.googleapis.com/csm-artifacts/asm/asmcli > asmcli

  2. Haz que la herramienta sea ejecutable:

    chmod +x asmcli

Configura cada clúster

Sigue estos pasos para configurar Cloud Service Mesh administrado para cada clúster de tu malla.

Aplica el plano de control administrado

Antes de aplicar el plano de control administrado, debes seleccionar un canal de versiones. Tu canal de Cloud Service Mesh se determina según el canal de tu clúster de GKE en el momento del aprovisionamiento de Cloud Service Mesh administrado. Ten en cuenta que no se admiten varios canales en el mismo clúster al mismo tiempo.

Ejecuta la herramienta de instalación para cada clúster que usará Cloud Service Mesh administrado. Te recomendamos que incluyas las dos opciones siguientes:

  • --enable-registration --fleet_id FLEET_PROJECT_ID Estas dos marcas registran el clúster en una flota, en el que FLEET_ID es el ID del proyecto host de la flota. Si se usa un solo proyecto, el FLEET_PROJECT_ID es el mismo que PROJECT_ID, el proyecto host de la flota y el proyecto del clúster son los mismos. En configuraciones más complejas, como las de varios proyectos, te recomendamos usar un proyecto host de flota independiente.

  • --enable-all. Esta marca habilita los componentes y el registro necesarios.

La herramienta asmcli configura el plano de control administrado directamente con las herramientas y la lógica dentro de la herramienta de la CLI. Usa el conjunto de instrucciones que se muestra a continuación según tu CA preferida.

Autoridades certificadoras

Selecciona una autoridad certificadora para usarla en tu malla.

CA de Mesh

Ejecuta el siguiente comando para instalar el plano de control con las funciones predeterminadas y con la CA de Mesh. Ingresa los valores en los marcadores de posición proporcionados.

  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all

Servicio de CA

  1. Sigue los pasos de la página Configura Certificate Authority Service.
  2. Ejecuta el siguiente comando para instalar el plano de control con las funciones predeterminadas y Certificate Authority Service. Ingresa los valores en los marcadores de posición proporcionados.
  ./asmcli install \
      -p PROJECT_ID \
      -l LOCATION \
      -n CLUSTER_NAME \
      --fleet_id FLEET_PROJECT_ID \
      --managed \
      --verbose \
      --output_dir DIR_PATH \
      --enable-all \
      --ca gcp_cas \
      --ca_pool pool_name

La herramienta descargará todos los archivos para configurar el plano de control administrado en el --output_dir especificado, e instalará la herramienta istioctl y las aplicaciones de muestra. En los pasos de esta guía, se supone que ejecutas istioctl desde la ubicación --output_dir que especificaste cuando ejecutaste asmcli install, con istioctl presente en su subdirectorio <Istio release dir>/bin.

Si vuelves a ejecutar asmcli en el mismo clúster, se reemplaza la configuración del plano de control existente. Asegúrate de especificar las mismas opciones y marcas si quieres establecer la misma configuración.

Verifica si se aprovisionó el plano de control

Después de unos minutos, verifica que el estado del plano de control sea ACTIVE:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

El resultado es similar al siguiente:

membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
      ...
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'

Si el estado no alcanza ACTIVE en unos minutos, consulta Cómo verificar el estado del plano de control administrado para obtener más información sobre posibles errores.

Actualizaciones automáticas

Una vez que se instala el plano de control administrado, Google lo actualizará de forma automática cuando haya actualizaciones o parches nuevos disponibles.

Plano de datos administrado

Si usas Cloud Service Mesh administrado, Google administra por completo las actualizaciones de tus proxies.

Con la función de plano de datos administrado habilitada, los proxies de sidecar y las puertas de enlace insertadas se actualizan de forma activa y automática junto con el plano de control administrado reiniciando las cargas de trabajo para volver a insertar las versiones nuevas del proxy. Este proceso comienza después de que se actualiza el plano de control y, por lo general, se completa en un plazo de 2 semanas después de su inicio.

Ten en cuenta que el plano de datos administrado depende del canal de versiones de GKE. Si cambias el canal de versiones de GKE mientras el plano de datos administrado está habilitado, Cloud Service Mesh administrado actualizará los proxies de todas las cargas de trabajo existentes como una implementación del plano de datos administrado.

Si se inhabilita, la administración del proxy se realiza de forma pasiva, controlada por el ciclo de vida natural de los Pods en el clúster, y el usuario debe activarla de forma manual para controlar la frecuencia de actualización.

El plano de datos administrado actualiza los proxies expulsando los Pods que ejecutan versiones anteriores del proxy. Las expulsiones se realizan de forma gradual, con el fin de respetar el presupuesto de interrupción del pod y controlar la frecuencia de cambio.

El plano de datos administrado no administra lo siguiente:

  • Pods que no se insertaron
  • Pods insertados de forma manual
  • Jobs
  • StatefulSets
  • DaemonSets

Si aprovisionaste Cloud Service Mesh administrado en un clúster anterior, puedes habilitar la administración del plano de datos para todo el clúster:

kubectl annotate --overwrite controlplanerevision -n istio-system \
REVISION_LABEL \
mesh.cloud.google.com/proxy='{"managed":"true"}'

De manera alternativa, puedes habilitar el plano de datos administrado de forma selectiva para una revisión, un espacio de nombres o un Pod específicos del plano de control anotándolo con la misma anotación. Si controlas los componentes individuales de forma selectiva, el orden de prioridad es la revisión del plano de control, luego el espacio de nombres y, por último, el Pod.

El servicio puede tardar hasta diez minutos en estar listo para administrar los proxies del clúster. Ejecuta el siguiente comando para verificar el estado:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

Resultado esperado

membershipStates:
  projects/PROJECT_NUMBER/locations/global/memberships/CLUSTER_NAME:
    servicemesh:
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'

Si el servicio no está listo en un plazo de diez minutos, consulta el estado del plano de datos administrado para continuar.

Inhabilita el plano de datos administrado (opcional)

Si aprovisionas Cloud Service Mesh administrado en un clúster nuevo, puedes inhabilitar el plano de datos administrado por completo o para espacios de nombres o Pods individuales. El plano de datos administrado seguirá inhabilitado para los clústeres existentes en los que se inhabilitó de forma predeterminada o manual.

Para inhabilitar el plano de datos administrado a nivel del clúster y volver a administrar los proxies de sidecar, cambia la anotación:

kubectl annotate --overwrite controlplanerevision -n istio-system \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Para inhabilitar el plano de datos administrado para un espacio de nombres, haz lo siguiente:

kubectl annotate --overwrite namespace NAMESPACE \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Para inhabilitar el plano de datos administrado para un pod, haz lo siguiente:

kubectl annotate --overwrite pod POD_NAME \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Habilita los períodos de mantenimiento para el plano de datos administrado

Si tienes configurado un período de mantenimiento de GKE, las actualizaciones activas comenzarán al inicio del siguiente período de mantenimiento disponible y continuarán sin pausas hasta que se actualicen todos los Pods administrados (por lo general, 12 horas). El período de mantenimiento no se observa para los lanzamientos relacionados con CVE.

Cloud Service Mesh usa la ventana de mantenimiento de GKE para alinearse con GKE.

Habilita las notificaciones de mantenimiento para el plano de datos administrado

Puedes solicitar recibir notificaciones sobre los próximos mantenimientos del plano de datos administrado hasta una semana antes de que se programe el mantenimiento. Las notificaciones de mantenimiento no se envían de forma predeterminada. También debes configurar un período de mantenimiento de GKE antes de recibir notificaciones. Cuando se habilita, las notificaciones se envían al menos dos días antes de la operación de actualización.

Para habilitar las notificaciones de mantenimiento del plano de datos administrado, sigue estos pasos:

  1. Ve a la página Comunicación.

    Ve a la página Comunicación

  2. En la fila Actualización de Cloud Service Mesh, en la columna Correo electrónico, selecciona el botón de selección para activar las notificaciones de mantenimiento.

Cada usuario que deba recibir notificaciones debe habilitar la opción por separado. Si deseas configurar un filtro de correo electrónico para estas notificaciones, el asunto es el siguiente:

Upcoming upgrade for your Cloud Service Mesh cluster "CLUSTER_LOCATION/CLUSTER_NAME"

En el siguiente ejemplo, se muestra una notificación típica de mantenimiento del plano de datos administrado:

Asunto: Próxima actualización del clúster "<location/cluster-name>" de Cloud Service Mesh

Estimado usuario de Cloud Service Mesh:

Se programó la actualización de los componentes de Cloud Service Mesh en tu clúster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) para el ${scheduled_date_human_readable} a las ${scheduled_time_human_readable}.

Puedes consultar las notas de la versión (https://cloud.google.com/service-mesh/docs/release-notes) para obtener información sobre la nueva actualización.

Si se cancela el mantenimiento, recibirás otro correo electrónico.

Atentamente,

El equipo de Cloud Service Mesh

© 2023 Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043 Te enviamos este anuncio para informarte sobre cambios importantes en Google Cloud Platform o tu cuenta. Si quieres inhabilitar las notificaciones sobre el período de mantenimiento, edita tus preferencias de usuario: https://console.cloud.google.com/user-preferences/communication?project=${project_id}

Configura la detección de extremos (solo para instalaciones de varios clústeres)

Si tu malla tiene solo un clúster, omite estos pasos de varios clústeres y continúa con Implementa aplicaciones o Migra aplicaciones.

Antes de continuar, asegúrate de que Cloud Service Mesh esté configurado en cada clúster.

Clústeres públicos

Configura el descubrimiento de extremos entre clústeres públicos

Si operas en clústeres públicos (clústeres no privados), puedes Configurar el descubrimiento de extremos entre clústeres públicos o, de manera más simple, Habilitar el descubrimiento de extremos entre clústeres públicos.

Clústeres privados

Configura el descubrimiento de extremos entre clústeres privados

Cuando usas clústeres privados de GKE, debes configurar el extremo del plano de control del clúster para que sea el extremo público en lugar del extremo privado. Consulta Configura el descubrimiento de extremos entre clústeres privados.

Para ver una aplicación de ejemplo con dos clústeres, consulta Ejemplo de servicio de Hello World.

Implementar aplicaciones

Habilita el espacio de nombres para la inserción. Los pasos dependen de tu implementación del plano de control.

Administrado (TD)

  1. Aplica la etiqueta de inserción predeterminada al espacio de nombres:
kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

Administrada (Istiod)

Recomendación: Ejecuta el siguiente comando para aplicar la etiqueta de inserción predeterminada al espacio de nombres:

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

Si ya eres usuario del plano de control de Istiod administrado, te recomendamos que uses la inserción predeterminada, pero también se admite la inserción basada en revisiones. Sigue estas instrucciones:

  1. Ejecuta el siguiente comando para ubicar los canales de versiones disponibles:

    kubectl -n istio-system get controlplanerevision

    El resultado es similar a este:

    NAME                AGE
asm-managed-rapid   6d7h

    NOTA: Si aparecen dos revisiones del plano de control en la lista anterior, quita una. No se admite tener varios canales del plano de control en el clúster.

    En el resultado, el valor en la columna NAME es la etiqueta de revisión que corresponde al canal de versiones disponible para la versión de Cloud Service Mesh.

  2. Aplica la etiqueta de revisión al espacio de nombres:

    kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

Valida que la etiqueta del espacio de nombres se haya aplicado correctamente con el siguiente comando.

  kubectl get namespace -L istio-injection

Resultado de ejemplo:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

En este punto, configuraste correctamente Cloud Service Mesh administrado. Si tienes cargas de trabajo existentes en espacios de nombres etiquetados, reinícialas para que se inserten los proxies.

Si implementas una aplicación en una configuración de varios clústeres, replica la configuración del plano de control y Kubernetes en todos los clústeres, a menos que planees limitar esa configuración en particular a un subconjunto de clústeres. La configuración que se aplica a un clúster en particular es la fuente de información de ese clúster.

Personaliza la inserción (opcional)

Puedes anular los valores predeterminados y personalizar la configuración de la inserción, pero esto puede generar errores de configuración imprevistos y problemas resultantes con los contenedores sidecar. Antes de personalizar la inserción, lee la información que se encuentra después del ejemplo para obtener notas sobre la configuración y las recomendaciones particulares.

La configuración por pod está disponible para anular estas opciones en pods individuales. Para ello, agrega un contenedor istio-proxy a tu pod. La inserción de sidecar tratará cualquier configuración definida aquí como una anulación de la plantilla de inserción predeterminada.

Por ejemplo, la siguiente configuración personaliza una variedad de parámetros de configuración, como la reducción de las solicitudes de CPU, la adición de una activación de volumen y la adición de un hook preStop:

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  containers:
  - name: hello
    image: alpine
  - name: istio-proxy
    image: auto
    resources:
      requests:
        cpu: "200m"
        memory: "256Mi"
      limits:
        cpu: "200m"
        memory: "256Mi"
    volumeMounts:
    - mountPath: /etc/certs
      name: certs
    lifecycle:
      preStop:
        exec:
          command: ["sleep", "10"]
  volumes:
  - name: certs
    secret:
      secretName: istio-certs

En general, se puede configurar cualquier campo en un pod. Sin embargo, se debe tener cuidado con ciertos campos:

  • Kubernetes requiere que se establezca el campo image antes de que se ejecute la inserción. Si bien puedes establecer una imagen específica para anular la predeterminada, te recomendamos que establezcas image en auto, lo que hará que el inyector de sidecar seleccione automáticamente la imagen que se usará.
  • Algunos campos de containers dependen de parámetros de configuración relacionados. Por ejemplo, debe ser menor o igual que el límite de CPU. Si ambos campos no están configurados correctamente, es posible que el Pod no se inicie.
  • Kubernetes te permite configurar requests y limits para los recursos de tu Pod spec. GKE Autopilot solo considera requests. Para obtener más información, consulta Cómo establecer límites de recursos en Autopilot.

Además, ciertos campos se pueden configurar con anotaciones en el Pod, aunque se recomienda usar el enfoque anterior para personalizar la configuración. Presta especial atención a las siguientes anotaciones:

  • En GKE Standard, si se establece sidecar.istio.io/proxyCPU, asegúrate de establecer sidecar.istio.io/proxyCPULimit de forma explícita. De lo contrario, el límite de CPU del sidecar se establecerá como ilimitado.
  • En el caso de GKE Standard, si se establece sidecar.istio.io/proxyMemory, asegúrate de establecer sidecar.istio.io/proxyMemoryLimit de forma explícita. De lo contrario, el límite de memoria del sidecar se establecerá como ilimitado.
  • En el caso de GKE Autopilot, configurar los recursos requests y limits con anotaciones podría generar un aprovisionamiento excesivo de recursos. Evita usar el enfoque de plantilla de imagen. Consulta Ejemplos de modificaciones de recursos en Autopilot.

Por ejemplo, consulta la siguiente anotación de recursos:

spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/proxyCPU: "200m"
        sidecar.istio.io/proxyCPULimit: "200m"
        sidecar.istio.io/proxyMemory: "256Mi"
        sidecar.istio.io/proxyMemoryLimit: "256Mi"

Verifica las métricas del plano de control

Puedes ver la versión del plano de control y el plano de datos en el Explorador de métricas.

Para verificar que tu configuración funcione según lo previsto, sigue estos pasos:

  1. En la consola de Google Cloud , observa las métricas del plano de control:

    Ir al Explorador de métricas

  2. Elige tu lugar de trabajo y agrega una consulta personalizada con los siguientes parámetros:

    • Tipo de recurso: Contenedor de Kubernetes
    • Métrica: Clientes del proxy
    • Filtro: container_name="cr-REVISION_LABEL"
    • Agrupar por: Etiqueta revision y etiqueta proxy_version
    • Aggregator: sum
    • Período: 1 minuto

    Cuando ejecutas Cloud Service Mesh con un plano de control administrado por Google y en el clúster, puedes distinguir las métricas por su nombre de contenedor. Por ejemplo, las métricas administradas tienen container_name="cr-asm-managed", mientras que las métricas no administradas tienen container_name="discovery". Para mostrar las métricas de ambos, quita el filtro en container_name="cr-asm-managed".

  3. Para verificar la versión del plano de control y del proxy, inspecciona los siguientes campos en el Explorador de métricas:

    • En el campo revisión, se indica la versión del plano de control.
    • El campo proxy_version indica el proxy_version.
    • El campo value indica el número de proxies conectados.

    Para conocer el canal actual para la asignación de versiones de Cloud Service Mesh, consulta Versiones de Cloud Service Mesh por canal.

Migra aplicaciones a Cloud Service Mesh administrado

Prepárate para la migración

Para prepararte para migrar aplicaciones de Cloud Service Mesh en el clúster a Cloud Service Mesh administrado, sigue estos pasos:

  1. Ejecuta la herramienta como se indica en la sección Aplica el plano de control administrado por Google.

  2. Si deseas usar el plano de datos administrado por Google, habilita la administración del plano de datos (opcional):

      kubectl annotate --overwrite controlplanerevision REVISION_TAG \
  mesh.cloud.google.com/proxy='{"managed":"true"}'

Migra aplicaciones

Para migrar aplicaciones de Cloud Service Mesh en el clúster a Cloud Service Mesh administrado, sigue estos pasos:

  1. Reemplaza la etiqueta del espacio de nombres actual. Los pasos dependen de tu implementación del plano de control.

Administrado (TD)

  1. Aplica la etiqueta de inserción predeterminada al espacio de nombres:
kubectl label namespace NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite

Administrada (Istiod)

Recomendación: Ejecuta el siguiente comando para aplicar la etiqueta de inserción predeterminada al espacio de nombres:

  kubectl label namespace NAMESPACE \
      istio.io/rev- istio-injection=enabled --overwrite

Si ya eres usuario del plano de control de Istiod administrado, te recomendamos que uses la inserción predeterminada, pero también se admite la inserción basada en revisiones. Sigue estas instrucciones:

  1. Ejecuta el siguiente comando para ubicar los canales de versiones disponibles:

    kubectl -n istio-system get controlplanerevision

    El resultado es similar a este:

    NAME                AGE
asm-managed-rapid   6d7h

    NOTA: Si aparecen dos revisiones del plano de control en la lista anterior, quita una. No se admite tener varios canales del plano de control en el clúster.

    En el resultado, el valor en la columna NAME es la etiqueta de revisión que corresponde al canal de versiones disponible para la versión de Cloud Service Mesh.

  2. Aplica la etiqueta de revisión al espacio de nombres:

    kubectl label namespace NAMESPACE \
    istio-injection- istio.io/rev=REVISION_LABEL --overwrite

  1. Realiza una actualización progresiva de las implementaciones en el espacio de nombres:

    kubectl rollout restart deployment -n NAMESPACE

  2. Prueba la aplicación para verificar que las cargas de trabajo funcionen de forma correcta.

  3. Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos anteriores para cada espacio de nombres.

  4. Si implementaste la aplicación en una configuración de varios clústeres, replica la configuración de Istio y Kubernetes en todos los clústeres, a menos que exista el deseo de limitar esa configuración a un subconjunto de clústeres solamente. La configuración que se aplica a un clúster en particular es la fuente de información de ese clúster.

Si estás seguro de que tu aplicación funciona como se esperaba, puedes quitar el clúster integrado istiod después de cambiar todos los espacios de nombres al plano de control administrado o mantenerlos como una copia de seguridad; istiod reducirá la escala verticalmente de forma automática para usar menos recursos. Para quitarlo, ve a Borra el plano de control anterior.

Si encuentras problemas, puedes identificarlos y resolverlos mediante la información que aparece en Resuelve problemas del plano de control administrado y, si es necesario, revertir a la versión anterior.

Borrar el plano de control anterior

Después de instalar y confirmar que todos los espacios de nombres usan el plano de control administrado por Google, puedes borrar el plano de control anterior.

kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true

Si usaste istioctl kube-inject en lugar de la inserción automática, o si instalaste puertas de enlace adicionales, verifica las métricas del plano de control y verifica que la cantidad de extremos conectados sea cero.

Revertir

Realiza los siguientes pasos si necesitas revertir a la versión anterior del plano de control:

  1. Actualiza las cargas de trabajo que se insertarán con la versión anterior del plano de control: En el siguiente comando, el valor de revisión asm-191-1 solo se usa como ejemplo. Reemplaza el valor de ejemplo por la etiqueta de revisión de tu plano de control anterior.

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=asm-191-1 --overwrite

  2. Reinicia los Pods para activar la reinserción a fin de que los proxies tengan la versión de Istio:

    kubectl rollout restart deployment -n NAMESPACE

El plano de control administrado escalará de forma automática a cero y no usará ningún recurso cuando no esté en uso. Los webhooks y el aprovisionamiento mutados permanecerán y no afectarán el comportamiento del clúster.

La puerta de enlace ahora está configurada en la revisión asm-managed. Para revertirlo, vuelve a ejecutar el comando de instalación de Cloud Service Mesh, que volverá a implementar la puerta de enlace que apunta al plano de control en el clúster:

kubectl -n istio-system rollout undo deploy istio-ingressgateway

Espera el siguiente resultado con éxito:

deployment.apps/istio-ingressgateway rolled back

Desinstalar

El plano de control administrado se escala automáticamente a cero cuando no hay espacios de nombres que lo usen. Para ver los pasos detallados, consulta Desinstala Cloud Service Mesh.

Soluciona problemas

Para identificar y resolver problemas cuando usas el plano de control administrado, consulta Resuelve problemas del plano de control administrado.

Próximos pasos