Aprovisionar Cloud Service Mesh gestionado con asmcli

Información general

Managed Cloud Service Mesh con asmcli es un plano de control gestionado y un plano de datos gestionado que puedes configurar fácilmente. Google se encarga de gestionar la fiabilidad, las mejoras, el escalado y la seguridad de ambos planos de forma retrocompatible. En esta guía se explica cómo configurar o migrar aplicaciones a Cloud Service Mesh gestionado en una configuración de un solo clúster o de varios clústeres con asmcli.

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

Requisitos previos

Para empezar, en esta guía se da por hecho que tienes lo siguiente:

Requisitos

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

  • Ten en cuenta que Cloud Service Mesh gestionado usa canales de versiones de GKE para equilibrar la estabilidad y la velocidad de actualización. Los nuevos cambios en los componentes del clúster de Cloud Service Mesh (incluidos CNI, MDPC, los proxies y los CRDs de Istio) se implementarán primero en los clústeres que se suscriban al canal rápido de GKE. Después, se ascenderán al canal habitual de GKE y, por último, al canal estable de GKE, una vez que demuestren suficiente estabilidad.

    • Managed Cloud Service Mesh no permite cambiar los canales de lanzamiento de GKE de forma segura.
    • Si cambias el canal de lanzamiento de GKE, Cloud Service Mesh actualizará o degradará automáticamente los componentes del clúster (CNI, MDPC, versión del proxy insertado predeterminada y CRDs de Istio) para que se ajusten al canal de lanzamiento de GKE actual.

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

    • El despliegue de mdp-controller en el espacio de nombres kube-system solicita cpu: 50m, memoria: 128Mi.
    • El istio-cni-node daemonset en el espacio de nombres kube-system solicita cpu: 100m y memory: 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 el equipo cliente desde el que aprovisionas Cloud Service Mesh gestionado tenga conectividad de red con el 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 habilitarlo como parte del aprovisionamiento pasando --enable-gcp-components o ejecutando el siguiente comando:

    gcloud container fleet mesh enable --project=FLEET_PROJECT_ID

    donde FLEET_PROJECT_ID es el ID del proyecto host de la flota.

  • Autopilot de GKE solo es compatible con la versión 1.21.3 o posterior de GKE.

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

    • Si unes clústeres que no están en el mismo proyecto, deben registrarse en el mismo proyecto de host de flota y los clústeres deben estar en una configuración de VPC compartida en la misma red.
    • En un entorno multiclúster de un solo proyecto, el proyecto de flota puede ser el mismo que el proyecto de clúster. Para obtener más información sobre las flotas, consulta el artículo Introducción a las flotas.
    • En un entorno de varios proyectos, te recomendamos que alojes la flota en un proyecto independiente de los proyectos de clúster. Si las políticas de tu organización y la configuración actual lo permiten, te recomendamos que uses el proyecto de VPC compartida como proyecto del host de la flota. Para obtener más información, consulta Configurar clústeres con una VPC compartida.
    • Si tu organización usa Controles de Servicio de VPC y estás aprovisionando Cloud Service Mesh en clústeres de GKE con una versión igual o posterior a 1.22.1-gke.10, es posible que tengas que seguir algunos pasos de configuración adicionales:

Roles necesarios para instalar Cloud Service Mesh

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

Nombre del rol ID de rol Conceder ubicación Descripción
Administrador de GKE Hub roles/gkehub.admin Proyecto de flota Acceso completo a GKE Hubs y a los recursos relacionados.
Administrador del uso del servicio roles/serviceusage.serviceUsageAdmin Proyecto de flota Permiso para habilitar, inhabilitar e inspeccionar estados de servicio, además de inspeccionar operaciones y consumir cuotas y facturación en un proyecto de consumidor. (Nota 1)
Administrador del Servicio de Autoridades de Certificación beta roles/privateca.admin Proyecto de flota Acceso completo a todos los recursos del Servicio de Autoridades de Certificación. (Nota 2)

Roles necesarios para ejecutar Cloud Service Mesh

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

Nombre del rol ID de rol Conceder ubicación Descripción
Agente de servicio de Anthos Service Mesh roles/anthosservicemesh.serviceAgent Proyecto de flota
Agente de servicio del plano de control gestionado de la malla (versión antigua) roles/meshcontrolplane.serviceAgent Proyecto de flota Este es un rol antiguo que formaba parte de instalaciones anteriores de Cloud Service Mesh. Si tu instalación tiene este rol de servicio, puedes dejarlo como está. Las nuevas instalaciones no necesitan este rol.

Limitaciones

Te recomendamos que consultes la lista de funciones y limitaciones compatibles con Cloud Service Mesh. En concreto, ten en cuenta lo siguiente:

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

  • En los clústeres de Autopilot de GKE, la configuración entre proyectos solo se admite con GKE 1.23 o versiones posteriores.

  • En los clústeres Autopilot de GKE, para adaptarse al límite de recursos de Autopilot de GKE, las solicitudes y los límites de recursos de proxy predeterminados se definen en 500 m de CPU y 512 MB de memoria. Puede anular los valores predeterminados mediante la inyección personalizada.

  • En los clústeres de Autopilot de GKE, pueden aparecer advertencias sobre los componentes de Cloud Service Mesh "DaemonSet has no nodes selected" (DaemonSet no tiene nodos seleccionados) hasta que se escale el NodePool de los clústeres.

  • Durante el proceso de aprovisionamiento de un plano de control gestionado, los CRDs de Istio se aprovisionan en el clúster especificado. Si hay CRDs de Istio en el clúster, se sobrescribirán.

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

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

Antes de empezar

Configurar gcloud

Sigue estos pasos aunque estés usando Cloud Shell.

  1. Autentícate con Google Cloud CLI:

    gcloud auth login --project PROJECT_ID

    donde 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

Descargar la herramienta de instalación

  1. Descarga la última versión 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

Configurar cada clúster

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

Aplicar el plano de control gestionado

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

Ejecuta la herramienta de instalación en cada clúster que vaya a usar Cloud Service Mesh gestionado. 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, donde FLEET_ID es el ID del proyecto de host de la flota. Si usas un solo proyecto, FLEET_PROJECT_ID es el mismo que PROJECT_ID, y el proyecto de host de la flota y el proyecto de clúster son el mismo. En configuraciones más complejas, como las de varios proyectos, te recomendamos que uses un proyecto de host de flota independiente.

  • --enable-all. Esta marca habilita tanto los componentes obligatorios como el registro.

La herramienta asmcli configura el plano de control gestionado directamente mediante herramientas y lógica dentro de la herramienta de CLI. Sigue las instrucciones que se indican a continuación en función de la autoridad de certificación que prefieras.

Autoridades de certificación

Selecciona una autoridad de certificación que quieras usar en tu malla.

Mesh CA

Ejecuta el siguiente comando para instalar el plano de control con las funciones predeterminadas y la CA de malla. Introduce tus 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 autoridades de certificación

  1. Sigue los pasos que se indican en el artículo Configurar el servicio de autoridad de certificación.
  2. Ejecuta el siguiente comando para instalar el plano de control con las funciones predeterminadas y el servicio de autoridad de certificación. Introduce tus 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 descarga todos los archivos para configurar el plano de control gestionado en el --output_dir especificado, instalar la herramienta istioctl y las aplicaciones de ejemplo. En los pasos de esta guía se presupone que ejecutas istioctl desde la ubicación --output_dir que especificaste al ejecutar asmcli install, con istioctl presente en su subdirectorio <Istio release dir>/bin.

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

Verificar que se ha aprovisionado el plano de control

Al cabo de unos minutos, comprueba que el estado del plano de control sea ACTIVE:

gcloud container fleet mesh describe --project FLEET_PROJECT_ID

La salida es similar a la 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 la sección Comprobar el estado del plano de control gestionado para obtener más información sobre los posibles errores.

Actualizaciones sin interacción

Una vez instalado el plano de control gestionado, Google lo actualizará automáticamente cuando haya nuevas versiones o parches disponibles.

Plano de datos gestionado

Si usas Cloud Service Mesh gestionado, Google gestiona por completo las actualizaciones de tus proxies.

Si la función de plano de datos gestionado está habilitada, los proxies sidecar y las pasarelas insertadas se actualizan de forma activa y automática junto con el plano de control gestionado reiniciando las cargas de trabajo para volver a insertar las nuevas versiones del proxy. Este proceso comienza después de que se haya actualizado el plano de control y suele completarse en un plazo de dos semanas.

Ten en cuenta que el plano de datos gestionado depende del canal de lanzamiento de GKE. Si cambias el canal de lanzamiento de GKE mientras el plano de datos gestionado está habilitado, Cloud Service Mesh gestionado actualizará los proxies de todas las cargas de trabajo como si se tratara de un lanzamiento del plano de datos gestionado.

Si se inhabilita, la gestión del proxy se realiza de forma pasiva, en función del ciclo de vida natural de los pods del clúster, y el usuario debe activarla manualmente para controlar la frecuencia de las actualizaciones.

El plano de datos gestionado actualiza los proxies desalojando los pods que ejecutan versiones anteriores del proxy. Los desalojos se realizan de forma gradual, respetando el presupuesto de interrupción de pods y controlando la tasa de cambio.

El plano de datos gestionado no gestiona lo siguiente:

  • Pods no insertados
  • Pods insertados manualmente
  • Empleo
  • StatefulSets
  • DaemonSets

Si has aprovisionado Cloud Service Mesh gestionado en un clúster antiguo, puedes habilitar la gestión del plano de datos en todo el clúster:

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

También puede habilitar el plano de datos gestionado de forma selectiva para una revisión, un espacio de nombres o un pod específicos del plano de control añadiéndoles la misma anotación. Si controlas los componentes de forma selectiva, el orden de precedencia es el siguiente: revisión del plano de control, espacio de nombres y, por último, pod.

El servicio puede tardar hasta diez minutos en estar listo para gestionar los proxies del clúster. Ejecuta el siguiente comando para comprobar 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 diez minutos, consulta Estado del plano de datos gestionado para ver los pasos siguientes.

Inhabilitar el plano de datos gestionado (opcional)

Si estás aprovisionando Cloud Service Mesh gestionado en un clúster nuevo, puedes inhabilitar el plano de datos gestionado por completo o para namespaces o pods concretos. El plano de datos gestionado seguirá inhabilitado en los clústeres en los que se haya inhabilitado de forma predeterminada o manualmente.

Para inhabilitar el plano de datos gestionado a nivel de clúster y volver a gestionar tú mismo los proxies 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 gestionado de un espacio de nombres, sigue estos pasos:

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

Para inhabilitar el plano de datos gestionado de un pod, sigue estos pasos:

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

Habilitar ventanas de mantenimiento para el plano de datos gestionado

Si tienes configurada una ventana de mantenimiento de GKE, las actualizaciones activas comenzarán al inicio de la siguiente ventana de mantenimiento disponible y continuarán sin interrupción hasta que se hayan actualizado todos los pods gestionados (normalmente, 12 horas). La ventana de mantenimiento no se tiene en cuenta en las implementaciones relacionadas con CVEs.

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

Habilitar las notificaciones de mantenimiento del plano de datos gestionado

Puedes solicitar que se te notifique el mantenimiento del plano de datos gestionado hasta una semana antes de que se programe. Las notificaciones de mantenimiento no se envían de forma predeterminada. También debes configurar una ventana de mantenimiento de GKE para poder recibir notificaciones. Si esta opción está habilitada, 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 gestionado, sigue estos pasos:

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

    Ir 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 radio para ACTIVAR las notificaciones de mantenimiento.

Cada usuario que quiera recibir notificaciones debe habilitarlas por separado. Si quieres configurar un filtro de correo 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 gestionado:

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

Estimado usuario de Cloud Service Mesh:

Los componentes de Cloud Service Mesh de tu clúster ${instance_id} (https://console.cloud.google.com/kubernetes/clusters/details/${instance_id}/details?project=${project_id}) se actualizarán 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 informarte sobre la nueva actualización.

En caso de que se cancele este mantenimiento, recibirás otro correo.

Atentamente,

El equipo de Cloud Service Mesh

(c) 2023 Google LLC 1600 Amphitheater Parkway, Mountain View, CA 94043 Te hemos enviado este anuncio porque queremos informarte de cambios importantes en Google Cloud Platform o en tu cuenta. Puedes inhabilitar las notificaciones de la ventana de mantenimiento modificando tus preferencias de usuario: https://console.cloud.google.com/user-preferences/communication?project=${project_id}

Configurar el descubrimiento de endpoints (solo para instalaciones de varios clústeres)

Si tu malla solo tiene un clúster, sáltate estos pasos y ve a Implementar aplicaciones o Migrar aplicaciones.

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

Clústeres públicos

Configurar el descubrimiento de endpoints entre clústeres públicos

Si trabajas con clústeres públicos (no privados), puedes hacer lo siguiente: Configurar la detección de endpoints entre clústeres públicos o, de forma más sencilla, Habilitar la detección de endpoints entre clústeres públicos.

Clústeres privados

Configurar el descubrimiento de endpoints entre clústeres privados

Cuando uses clústeres privados de GKE, debes configurar el punto final del plano de control del clúster para que sea el punto final público en lugar del privado. Consulta Configurar el descubrimiento de endpoints entre clústeres privados.

Para ver un ejemplo de aplicación con dos clústeres, consulta el ejemplo de servicio HelloWorld.

Desplegar aplicaciones

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

Gestionado (TD)

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

Gestionado (Istiod)

Recomendación: Ejecuta el siguiente comando para aplicar la etiqueta de inyecció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 gestionado: Te recomendamos que utilices la inyección predeterminada, pero también se admite la inyección basada en revisiones. Sigue estas instrucciones:

  1. Ejecuta el siguiente comando para localizar los canales de lanzamiento disponibles:

    kubectl -n istio-system get controlplanerevision

    El resultado debería ser similar al siguiente:

    NAME                AGE
asm-managed-rapid   6d7h

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

    En el resultado, el valor de la columna NAME es la etiqueta de revisión que corresponde al canal de lanzamiento 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 de espacio de nombres se haya aplicado correctamente con el siguiente comando.

  kubectl get namespace -L istio-injection

Ejemplo:

  NAME                 STATUS   AGE     ISTIO-INJECTION
  default              Active   5m9s    enabled

En este punto, has configurado correctamente Cloud Service Mesh gestionado. Si tienes cargas de trabajo en espacios de nombres etiquetados, reinícialas para que se les inserten proxies.

Si implementas una aplicación en una configuración de varios clústeres, replica la configuración de Kubernetes y del plano de control en todos los clústeres, a menos que tengas previsto limitar esa configuración concreta a un subconjunto de clústeres. La configuración aplicada a un clúster concreto es la fuente de información veraz de ese clúster.

Personalizar la inyección (opcional)

Puedes anular los valores predeterminados y personalizar los ajustes de inyección, pero esto puede provocar errores de configuración imprevistos y problemas con los contenedores sidecar. Antes de personalizar la inyección, lee la información que aparece después del ejemplo para consultar notas sobre ajustes y recomendaciones concretos.

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

Por ejemplo, la siguiente configuración personaliza varios ajustes, como reducir las solicitudes de CPU, añadir un montaje de volumen y añadir 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 definir cualquier campo de un pod. Sin embargo, se debe tener cuidado con determinados campos:

  • Kubernetes requiere que se defina el campo image antes de que se ejecute la inyección. Aunque puedes definir una imagen específica para anular la predeterminada, te recomendamos que definas image como auto, lo que hará que el inyector de sidecar seleccione automáticamente la imagen que se va a usar.
  • Algunos campos de containers dependen de ajustes relacionados. Por ejemplo, debe ser inferior o igual al límite de CPU. Si ambos campos no están configurados correctamente, es posible que el pod no se inicie.
  • Kubernetes te permite definir tanto requests como limits para los recursos de tu pod spec. Autopilot de GKE solo tiene en cuenta requests. Para obtener más información, consulta Configurar límites de recursos en Autopilot.

Además, algunos campos se pueden configurar mediante anotaciones en el pod, aunque se recomienda usar el método anterior para personalizar los ajustes. Presta especial atención a las siguientes anotaciones:

  • En GKE Standard, si se define sidecar.istio.io/proxyCPU, asegúrate de definir sidecar.istio.io/proxyCPULimit de forma explícita. De lo contrario, el límite de CPU del sidecar será ilimitado.
  • En GKE Standard, si se define sidecar.istio.io/proxyMemory, asegúrate de definir sidecar.istio.io/proxyMemoryLimit de forma explícita. De lo contrario, el límite de memoria del sidecar será ilimitado.
  • En Autopilot de GKE, configurar requests y limits de recursos mediante anotaciones puede provocar un aprovisionamiento excesivo de recursos. Usa el método de plantilla de imagen para evitarlo. Consulta ejemplos de modificación 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"

Verificar las métricas del plano de control

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

Para verificar que la configuración funciona correctamente, siga estos pasos:

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

    Ir a Explorador de métricas

  2. Elige tu espacio de trabajo y añade una consulta personalizada con los siguientes parámetros:

    • Tipo de recurso: contenedor de Kubernetes
    • Métrica: clientes proxy
    • Filtro: container_name="cr-REVISION_LABEL"
    • Agrupar por: etiqueta revision y etiqueta proxy_version
    • Agregador: suma
    • Periodo: 1 minuto

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

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

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

    Para ver la asignación actual de canales a versiones de Cloud Service Mesh, consulta Versiones de Cloud Service Mesh por canal.

Migrar aplicaciones a Cloud Service Mesh gestionado

Preparar la migración

Para preparar la migración de aplicaciones de Cloud Service Mesh en el clúster a Cloud Service Mesh gestionado, sigue estos pasos:

  1. Ejecuta la herramienta tal como se indica en la sección Aplicar el plano de control gestionado por Google.

  2. (Opcional) Si quieres usar el plano de datos gestionado por Google, habilita la gestión del plano de datos:

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

Migrar aplicaciones

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

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

Gestionado (TD)

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

Gestionado (Istiod)

Recomendación: Ejecuta el siguiente comando para aplicar la etiqueta de inyecció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 gestionado: Te recomendamos que utilices la inyección predeterminada, pero también se admite la inyección basada en revisiones. Sigue estas instrucciones:

  1. Ejecuta el siguiente comando para localizar los canales de lanzamiento disponibles:

    kubectl -n istio-system get controlplanerevision

    El resultado debería ser similar al siguiente:

    NAME                AGE
asm-managed-rapid   6d7h

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

    En el resultado, el valor de la columna NAME es la etiqueta de revisión que corresponde al canal de lanzamiento 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 continua de los despliegues del espacio de nombres:

    kubectl rollout restart deployment -n NAMESPACE

  2. Prueba tu aplicación para verificar que las cargas de trabajo funcionan correctamente.

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

  4. Si has desplegado la aplicación en una configuración de varios clústeres, replica la configuración de Kubernetes e Istio en todos los clústeres, a menos que quieras limitar esa configuración a un subconjunto de clústeres. La configuración aplicada a un clúster concreto es la fuente de información veraz de ese clúster.

Si estás seguro de que tu aplicación funciona correctamente, puedes quitar el istiod del clúster después de cambiar todos los espacios de nombres al plano de control gestionado o mantenerlos como copia de seguridad. istiod se reducirá automáticamente para usar menos recursos. Para quitarlo, ve a la sección Eliminar el plano de control antiguo.

Si tienes algún problema, puedes identificarlo y resolverlo con la información del artículo Resolver problemas del plano de control gestionado. Si es necesario, puedes volver a la versión anterior.

Eliminar el plano de control antiguo

Una vez que hayas instalado el plano de control gestionado por Google y hayas confirmado que todos los espacios de nombres lo usan, puedes eliminar el plano de control antiguo.

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

Si has usado istioctl kube-inject en lugar de la inyección automática o has instalado pasarelas adicionales, comprueba las métricas del plano de control y verifica que el número de endpoints conectados sea cero.

Restaurar

Sigue estos pasos si necesitas volver a la versión anterior del plano de control:

  1. Actualiza las cargas de trabajo para que se les inserte la versión anterior del plano de control. En el siguiente comando, el valor de revisión asm-191-1 se usa solo como ejemplo. Sustituye 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 reinyección y que los proxies tengan la versión anterior:

    kubectl rollout restart deployment -n NAMESPACE

El plano de control gestionado se escalará automáticamente a cero y no usará ningún recurso cuando no se utilice. Los webhooks de mutación y el aprovisionamiento se mantendrán y no afectarán al comportamiento del clúster.

La pasarela se ha configurado con la revisión asm-managed. Para revertir la operación, vuelve a ejecutar el comando de instalación de Cloud Service Mesh, que volverá a implementar la pasarela para que apunte de nuevo al plano de control del clúster:

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

Si la operación se realiza correctamente, se mostrará el siguiente resultado:

deployment.apps/istio-ingressgateway rolled back

Desinstalar

El plano de control gestionado se escala automáticamente a cero cuando ningún espacio de nombres lo utiliza. Para ver los pasos detallados, consulta Desinstalar Cloud Service Mesh.

Solución de problemas

Para identificar y resolver problemas al usar el plano de control gestionado, consulta Resolución de problemas del plano de control gestionado.

Siguientes pasos