Aprovisiona Anthos Service Mesh administrado con asmcli

Descripción general

Anthos Service Mesh administrado con asmcli es un plano de control administrado y un plano de datos administrado que solo debes configurar. 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 Anthos Service Mesh administrado en una configuración de uno o varios clústeres con asmcli.

Nota: Recomendamos la opción de la API de la función de flota para configurar Anthos Service Mesh administrado, pero también puedes usar esta guía para configurar Anthos Service Mesh administrado mediante la herramienta asmcli.

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

Requisitos previos

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

• Un proyecto de Cloud
• Una cuenta de facturación de Cloud
• Obtener los permisos necesarios para aprovisionar Anthos Service Mesh administrado
• La herramienta de instalación de asmcli, kpt y otras herramientas especificadas en Instala las herramientas necesarias

Para un aprovisionamiento más rápido, tus clústeres deben tener Workload Identity habilitado. Si Workload Identity no está habilitada, el aprovisionamiento lo habilitará automáticamente.

Requisitos

• Uno o más clústeres con una versión de GKE compatible en una de las regiones admitidas.
• Asegúrate de que tu clúster tenga suficiente capacidad para los componentes necesarios que administra Anthos Service Mesh y instala en el clúster.
  • La implementación mdp-controller en el espacio de nombres kube-system solicita CPU: 50 m, memoria: 128 Mi.
  • El daemonset istio-cni-node en el espacio de nombres kube-system solicita CPU: 100 m, memoria: 100 Mi en cada nodo.
• Asegúrate de que la máquina cliente desde la que aprovisionas Anthos Service Mesh administrado tenga conectividad de red al servidor de la API.
• Tus clústeres deben estar registrados en una flota. Este paso se puede realizar por separado antes del aprovisionamiento o como parte del aprovisionamiento pasando las marcas --enable-registration y --fleet-id.

• Tu proyecto debe tener habilitada la función de flota de Service Mesh. Puedes habilitarla como parte del aprovisionamiento si pasas --enable-gcp-components o 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 o posterior de GKE.

• La CNI de Istio es obligatoria y se instala de forma predeterminada cuando se aprovisiona Anthos Service Mesh administrado.

• Anthos Service Mesh administrado 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.

  • Si unes clústeres que no están en el mismo proyecto, deben estar registrados en el mismo proyecto host de la flota y los clústeres deben estar en la configuración de una VPC compartida en la misma red.
  • Para un entorno de varios clústeres en un proyecto único, el proyecto de la flota puede ser el mismo que el proyecto del clúster. Para obtener más información sobre las flotas, consulta Descripción general de las flotas.
  • Para un entorno de varios proyectos, te recomendamos que alojes la flota en un proyecto separado de los proyectos del clúster. Si las políticas de la organización y la configuración existente lo permiten, te recomendamos que uses el proyecto de VPC compartida como el proyecto host de la flota. Para obtener más información, consulta Configura clústeres con VPC compartida.
  • Si tu organización usa Controles del servicio de VPC y aprovisionas Anthos Service Mesh administrado en clústeres de GKE, también debes seguir los pasos que se indican en Controles del servicio de VPC para Anthos Service Mesh.

Limitaciones

Precaución: Ten en cuenta las siguientes limitaciones específicas de la flota: - Todos los clústeres de Anthos Service Mesh para una malla deben estar registrados en la misma flota en todo momento para poder usar Anthos Service Mesh. Los otros clústeres del proyecto de un clúster de Anthos Service Mesh no se deben registrar en una flota diferente.

Te recomendamos que revises la lista de funciones admitidas y limitaciones de Anthos Service Mesh administrado. 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.

  Nota: Puedes habilitar las funciones opcionales sin usar la API de IstioOperator. Consulta Habilita funciones opcionales en Anthos Service Mesh administrado. También puedes usar la herramienta de migración incluida en asmcli para convertir de forma automática otras funciones opcionales de IstioOperator de modo que sean compatibles con el plano de control administrado. Si quieres obtener más información, consulta Migra desde IstioOperator.

• No se admiten las migraciones de Anthos Service Mesh administrado con asmcli a Anthos Service Mesh con la API de flota. Del mismo modo, no se admite la configuración de Anthos Service Mesh administrado con la API de flota de --management manual a --management automatic.

• Para los clústeres de GKE Autopilot, la configuración entre proyectos solo es compatible con GKE 1.23 o una versión posterior.

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

• Las funciones reales disponibles para Anthos Service Mesh administrado dependen del canal de versiones. Para obtener más información, revisa la lista completa de funciones y limitaciones admitidas de Anthos Service Mesh.

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

• La CNI de Istio no es compatible con GKE Sandbox. Por lo tanto, Anthos Service Mesh administrado en Autopilot no funciona con GKE Sandbox, ya que se requiere CNI administrado de Istio.

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

Antes de comenzar

Advertencia: Las herramientas de GitOps (como el Sincronizador de configuración, CD de Argo, Terraform y Jenkins) pueden interferir en los procesos de instalación, migración o actualización de Anthos Service Mesh. Para obtener mejores resultados, inhabilita las herramientas de GitOps antes de instalar, migrar o actualizar Anthos Service Mesh.

Configura gcloud

Sigue estos pasos incluso si usas Cloud Shell.

1. Autentica con Google Cloud CLI

   gcloud auth login --project PROJECT_ID
   

2. Actualiza los componentes:

   gcloud components update
   

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

   Nota: Usa --region en lugar de --zone, si el clúster es un clúster regional.

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

Descarga la herramienta de instalación

Importante: La herramienta asmcli solo es compatible con los sistemas operativos Linux.

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 a fin de configurar Anthos Service Mesh administrado para cada clúster de tu malla.

Aplica el plano de control administrado

Nota: De manera alternativa, puedes usar la API de flota y gcloud en lugar de asmcli a fin de configurar Anthos Service Mesh administrado. Para obtener más información, consulta Configura Anthos Service Mesh administrado con la API de flota.

Antes de aplicar el plano de control administrado, debes seleccionar un canal de versiones.

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

Advertencia: Las siguientes opciones son obligatorias. Para obtener una lista completa de las opciones, consulta la página de referencia de asmcli.

• --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 usas 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 la de varios proyectos, 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.

Advertencia: Para que Anthos Service Mesh funcione correctamente, implementarás un DaemonSet istio-cni-node en tus nodos con permisos elevados de control de acceso basado en roles (RBAC), como la capacidad de modificar todas las implementaciones y crear mapas de configuración. Estos permisos son necesarios para que istio-cni-node administre el ciclo de vida y la configuración del Pod.

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. Reemplaza RELEASE_CHANNEL por el canal adecuado: regular, stable o rapid.

  ./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. Reemplaza RELEASE_CHANNEL por el canal adecuado: regular, stable o rapid.

Nota: Cuando se usa Certificate Authority Service como parte de una malla de varios clústeres de MCP, todos los clústeres deben tener su respectiva cadena de grupos de CA subordinada al mismo grupo de CA raíz. De lo contrario, todos deberán usar el mismo grupo de CA.

  ./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 llega a ACTIVE en unos minutos, consulta Verifica el estado del plano de control administrado para obtener más información sobre posibles errores.

Actualizaciones automáticas

Una vez que se instale el plano de control administrado, Google lo actualizará automáticamente cuando haya nuevas versiones o parches disponibles.

Plano de datos administrado

Si usas Anthos Service Mesh administrado, Google administra por completo las actualizaciones de tus proxies, a menos que lo inhabilites a nivel del espacio de nombres, la carga de trabajo o la revisión.

Con el plano de datos administrado, los proxies de sidecar y las puertas de enlace insertadas se actualizan de forma automática junto con el plano de control administrado mediante el reinicio de las cargas de trabajo para volver a insertar versiones nuevas del proxy. Por lo general, esto se completa entre 1 y 2 semanas después de que se actualiza el plano de control administrado.

Si se inhabilita, el ciclo de vida natural de los Pods del clúster impulsa la administración de proxies y el usuario la debe activar manualmente para controlar la frecuencia de actualización.

El plano de datos administrado actualiza los proxies mediante la expulsión de Pods que ejecutan versiones anteriores del proxy. Las expulsiones se realizan de forma gradual, respetando el presupuesto de interrupción del Pod y controlando la tasa de cambio.

Nota: Si el clúster tiene un período de mantenimiento de GKE definido, las expulsiones de Pods comenzarán al comienzo del siguiente período de mantenimiento disponible y continuarán sin pausa hasta que se actualicen todos los Pods administrados (por lo general, 12 horas). No se observa el período de mantenimiento para los lanzamientos relacionados con CVE.

El plano de datos administrado no administra lo siguiente:

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

Si aprovisionaste Anthos Service Mesh administrado en un clúster más antiguo, 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"}'

Como alternativa, puedes habilitar el plano de datos administrado de forma selectiva para una revisión de plano de control, un espacio de nombres o un pod específicos anotándolo con la misma anotación. Si controlas los componentes individuales de forma selectiva, el orden de prioridad es revisión del plano de control, espacio de nombres y, luego, 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 Anthos Service Mesh administrado en un clúster nuevo, puedes inhabilitar el plano de datos administrado por completo o para Pods o espacios de nombres 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 \
REVISION_LABEL \
  mesh.cloud.google.com/proxy='{"managed":"false"}'

Si deseas 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 de un Pod, sigue estos pasos:

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

Habilita las notificaciones de mantenimiento

Puedes solicitar que se te notifique sobre el próximo mantenimiento del plano de datos administrado hasta una semana antes de la programación de mantenimiento. Las notificaciones de mantenimiento no se envían de forma predeterminada. También debes configurar un período de mantenimiento de GKE para poder 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, haz lo siguiente:

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

   Ve a la página Comunicación

2. En la fila Actualización de Anthos 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 por correo electrónico para estas notificaciones, el asunto es el siguiente:

Upcoming upgrade for your Anthos 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 de tu clúster de ASM “<location/cluster-name>”

Estimado usuario de Anthos Service Mesh:

Los componentes de Anthos Service Mesh de tu clúster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) están programados para actualizarse el ${scheduled_date_human_Read} a las ${scheduled_time_human_ read}.

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

Si se cancela este mantenimiento, te enviaremos otro correo electrónico.

Saludos,

El equipo de Anthos Service Mesh

(c) 2022 Google LLC, 1600 Amphitheater Parkway, Mountain View, CA 94043 Te enviamos este anuncio para informarte sobre cambios importantes relacionados con tu cuenta o Google Cloud Platform. Para 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)

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

Antes de continuar, ya debes haber configurado Anthos Service Mesh administrado en cada clúster como se describe en los pasos anteriores. No es necesario indicar que un clúster es uno principal; este es el comportamiento predeterminado.

Además, asegúrate de haber descargado asmcli (solo si deseas verificar la configuración con la aplicación de ejemplo) y estableciste las variables del proyecto y del clúster.

Nota: Para obtener más información sobre el descubrimiento de extremos, consulta Descubrimiento de extremos con varios planos de control.

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 forma más sencilla, 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.

Nota: En el ejemplo de servicio HelloWorld, se usa Docker Hub. En un clúster privado, el entorno de ejecución del contenedor puede extraer imágenes de contenedor de Artifact Registry de forma predeterminada. El entorno de ejecución del contenedor no puede extraer imágenes de ningún otro registro de imágenes de contenedor en Internet. Puedes descargar la imagen y enviarla a Artifact Registry o usar Cloud NAT a fin de proporcionar acceso a Internet saliente para ciertos nodos privados. Para obtener más información, consulta Migra contenedores externos y Crea un clúster privado.

Implementar aplicaciones

Para implementar aplicaciones, usa la etiqueta correspondiente al canal que configuraste durante la instalación o istio-injection=enabled si usas etiquetas de inyección predeterminadas.

Etiqueta de inyección predeterminada

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

Nota: Puedes ignorar cualquier error label "istio.io/rev" not found.

Etiqueta de revisión

Antes de implementar aplicaciones, quita las etiquetas istio-injection anteriores de sus espacios de nombres y configura la etiqueta istio.io/rev=REVISION_LABEL en su lugar.

Para cambiarla a una etiqueta de revisión específica, haz clic en REVISION_LABEL y reemplázala por la etiqueta aplicable: asm-managed-rapid para Rápido, asm-managed para Regular o asm-managed-stable para Estable.

La etiqueta de revisión corresponde a un canal de versiones:

Etiqueta de revisión	Canal
asm-managed	Normal
asm-managed-rapid	Rápido
asm-managed-stable	Estable

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

Nota: Puedes ignorar cualquier error label "istio-injection" not found.

En este punto, configuraste con éxito Anthos Service Mesh. Si tienes cargas de trabajo existentes en espacios de nombres etiquetados, reinícialas para que se inserten proxies.

Ya estás listo para implementar tus aplicaciones, o puedes implementar la aplicación de muestra de Bookinfo.

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)

Precaución: Anular y personalizar la configuración de inserción puede generar errores de configuración imprevistos y problemas relacionados con los contenedores de sidecar.

La configuración por Pod está disponible para anular estas opciones en Pods individuales. Para ello, se debe agregar un contenedor istio-proxy al Pod. La inserción de sidecar tratará cualquier configuración definida aquí como una anulación a la plantilla de inyección predeterminada.

Por ejemplo, en la siguiente configuración, se personalizan diferentes opciones de configuración, como reducir las solicitudes de CPU, agregar una activación de volumen y 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"
      limites:
        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 deben tener cuidado con los siguientes campos:

• Kubernetes requiere que se configure el campo image antes de que se ejecute la inserción. Si bien puedes configurar una imagen específica para anular la predeterminada, se recomienda establecer 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 la configuración relacionada. Por ejemplo, la solicitud de CPU debe ser inferior al 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 PodSpec. GKE Autopilot solo considera requests. Para obtener más información, consulta Establece límites de recursos en Autopilot.

Además, algunos campos se pueden configurar mediante anotaciones en el Pod, aunque se recomienda usar el enfoque anterior para personalizar la configuración. Se debe tener mucho cuidado con algunas anotaciones:

• Para GKE Standard, si se configura sidecar.istio.io/proxyCPU, asegúrate de configurar sidecar.istio.io/proxyCPULimit de forma explícita. De lo contrario, el límite de CPU del archivo adicional se establecerá como ilimitado.
• Para GKE Standard, si sidecar.istio.io/proxyMemory está configurado, asegúrate de configurar sidecar.istio.io/proxyMemoryLimit de forma explícita. De lo contrario, el límite de memoria del archivo adicional se establecerá como ilimitado.
• Para GKE Autopilot, la configuración de los recursos requests y limits con anotaciones podría aprovisionar en exceso los recursos. Evita usar el enfoque de plantillas de imágenes. Consulta Ejemplos de modificación de recursos en Autopilot.

Por ejemplo, consulta la siguiente configuración de 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 de forma correcta, sigue estos pasos:

1. En la consola de Google Cloud, visualiza 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
   • Agregador: suma
   • Período: 1 minuto

   Cuando ejecutas Anthos 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.

   A fin de conocer el canal actual para la asignación de versiones de Anthos Service Mesh, consulta Versiones de Anthos Service Mesh por canal.

Migra aplicaciones a Anthos Service Mesh administrado

Advertencia: Durante el proceso de migración, las CRD de Istio correspondientes al canal seleccionado se instalan en el clúster especificado. Si hay CRD de Istio existentes en el clúster, se reemplazarán.

Prepárate para la migración

Sigue estos pasos a fin de prepararte para migrar aplicaciones de Anthos Service Mesh en el clúster a Anthos Service Mesh administrado:

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"}'
   

Migrar aplicaciones

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

1. Reemplaza la etiqueta del espacio de nombres actual. Los pasos necesarios dependen de si deseas usar etiquetas de inserción predeterminadas (por ejemplo, istio-injection enabled) o la etiqueta de revisión.

   Etiqueta de inyección predeterminada

   1. Ejecuta el siguiente comando para mover la etiqueta predeterminada a la revisión administrada:

      istioctl tag set default --revision REVISION_LABEL
      

   2. Ejecuta el siguiente comando para etiquetar el espacio de nombres con istio-injection=enabled, si aún no lo era:

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

   Etiqueta de revisión

   Si usaste la etiqueta istio.io/rev=REVISION_LABEL, ejecuta el siguiente comando:

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

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

   kubectl rollout restart deployment -n NAMESPACE
   

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

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

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

6. Para verificar que las métricas aparezcan como se espera, sigue los pasos en Verifica las métricas del plano de control.

Si estás seguro de que tu aplicación funciona como se espera, puedes quitar el istiod en el clúster 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 automáticamente 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 Anthos 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 realiza un ajuste de escala automático a cero cuando no hay espacios de nombres que lo usen. Para obtener pasos detallados, consulta Desinstala Anthos 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

• Obtén información sobre los canales de versiones.
• Migra desde IstioOperator.
• Migra una puerta de enlace al plano de control administrado.
• Obtén información para habilitar las funciones opcionales administradas de Anthos Service Mesh, como las siguientes:
  • Registros de acceso de Envoy
  • Seguimiento
  • Imágenes sin distro
  • Autenticación de usuario final