Cloud Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la información general sobre Cloud Service Mesh.

Esta página se ha traducido con Cloud Translation API.

Aprovisionar un plano de control de Cloud Service Mesh gestionado en GKE

Cloud Service Mesh es una malla de servicios gestionada por Google que solo tienes que habilitar. Google se encarga de gestionar la fiabilidad, las mejoras, el escalado y la seguridad de ambos planos.

En esta página se muestra cómo usar la API fleet para configurar Cloud Service Mesh gestionado con las APIs de Istio.

Requisitos previos

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

Un proyecto de Cloud
Una cuenta de facturación de Cloud
Ha obtenido los permisos necesarios para aprovisionar Cloud Service Mesh
Habilitar Workload Identity en tus clústeres y grupos de nodos.

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. Esto se incluye en las instrucciones si aún no se ha registrado antes de la provisión.
Tu proyecto debe tener habilitada la función de flota de Service Mesh. Esto se incluye en las instrucciones si aún no lo has habilitado.
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.

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.

Nota: Puedes habilitar funciones opcionales sin usar la API IstioOperator. Consulta Habilitar funciones opcionales en la malla de servicios de Cloud gestionada. También puedes usar la herramienta de migración incluida en asmcli para convertir automáticamente otras funciones opcionales de IstioOperator y que sean compatibles con el plano de control gestionado. Para obtener más información, consulta el artículo Migrar desde IstioOperator.
Para usar el Servicio de Autoridades de Certificación, debes configurar Cloud Service Mesh por clúster. No se admite cuando se usa la configuración predeterminada de la flota en GKE Enterprise.
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.

Antes de empezar

Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

Configura gcloud (aunque uses Cloud Shell).

Autentica con Google Cloud CLI, donde FLEET_PROJECT_ID es el ID de tu proyecto host de flota. Por lo general, el FLEET_PROJECT_ID se crea de forma predeterminada y tiene el mismo nombre que el proyecto.
```
       gcloud auth login --project FLEET_PROJECT_ID
```
Actualiza los componentes:
```
       gcloud components update
```

Habilita las APIs necesarias en tu proyecto host de la flota.

  gcloud services enable mesh.googleapis.com \
      --project=FLEET_PROJECT_ID

Si habilitas mesh.googleapis.com, se habilitarán las siguientes APIs:

API	Finalidad	Se puede inhabilitar
`meshconfig.googleapis.com`	Cloud Service Mesh usa la API Mesh Configuration para reenviar datos de configuración de tu malla a Google Cloud. Además, si habilitas la API Mesh Configuration, podrás acceder a las páginas de Cloud Service Mesh en la Google Cloud consola y usar la autoridad de certificación de Cloud Service Mesh.	No
`meshca.googleapis.com`	Relacionado con la autoridad de certificación de Cloud Service Mesh que usa Cloud Service Mesh gestionado.	No
`container.googleapis.com`	Obligatorio para crear clústeres de Google Kubernetes Engine (GKE).	No
`gkehub.googleapis.com`	Se requiere para gestionar la malla como una flota.	No
`monitoring.googleapis.com`	Obligatorio para recoger telemetría de cargas de trabajo de malla.	No
`stackdriver.googleapis.com`	Es necesario para usar la interfaz de usuario de los Servicios.	No
`opsconfigmonitoring.googleapis.com`	Es necesario para usar la interfaz de usuario de Servicios en clústeresGoogle Cloud desactivados.	No
`connectgateway.googleapis.com`	Es necesario para que el plano de control de Cloud Service Mesh gestionado pueda acceder a las cargas de trabajo de la malla.	Sí*
`trafficdirector.googleapis.com`	Habilita un plano de control gestionado de alta disponibilidad y escalable.	Sí*
`networkservices.googleapis.com`	Habilita un plano de control gestionado de alta disponibilidad y escalable.	Sí*
`networksecurity.googleapis.com`	Habilita un plano de control gestionado de alta disponibilidad y escalable.	Sí*

Advertencia: Si inhabilitas connectgateway.googleapis.com, trafficdirector.googleapis.com, networkservices.googleapis.com o networksecurity.googleapis.com, el plano de control gestionado de Cloud Service Mesh dejará de funcionar. Si la flota no usa Cloud Service Mesh gestionado en ningún clúster, estas APIs se pueden inhabilitar.

Configurar Cloud Service Mesh gestionado

Los pasos necesarios para aprovisionar Cloud Service Mesh gestionado mediante la API de flota dependen de si prefieres habilitarlo de forma predeterminada para los nuevos clústeres de la flota o por clúster.

Configurar para tu flota

Debes tener habilitada la edición Enterprise de Google Kubernetes Engine (GKE) para habilitar Cloud Service Mesh gestionado como configuración predeterminada de tu flota. Esto significa que todos los clústeres de GKE en Google Cloud que se registren durante la creación del clúster tendrán habilitado Cloud Service Mesh gestionado en el clúster. Puedes consultar más información sobre la configuración predeterminada de la flota en el artículo Gestionar funciones a nivel de flota.

Si habilitas Cloud Service Mesh gestionado como configuración predeterminada de tu flota y registras clústeres en la flota durante la creación de clústeres, solo se admitirá Mesh CA. Si quieres usar el servicio de autoridad de certificación, te recomendamos que lo habilites por clúster.

Para habilitar los valores predeterminados a nivel de flota en Cloud Service Mesh gestionado, sigue estos pasos:

Consola

En la Google Cloud consola, ve a la página Gestor de funciones.

Ir a Gestor de funciones
En el panel Service Mesh, haz clic en Configurar.
Revisa los ajustes que heredan todos los clústeres nuevos que crees en la Google Cloud consola y registres en la flota.

Nota: Estos ajustes de GKE son requisitos previos para usar Cloud Service Mesh.
Para aplicar estos ajustes, haz clic en Configurar.
En el cuadro de diálogo de confirmación, haz clic en Confirmar.
Opcional: Sincroniza los clústeres con la configuración predeterminada:
1. En la lista Clusters in the fleet (Clusters de la flota), selecciona los clusters que quieras sincronizar. Solo puedes seleccionar clústeres que tengan instalado Cloud Service Mesh.
2. Haz clic en Sincronizar con la configuración de la flota y, en el cuadro de diálogo de confirmación que aparece, haz clic en Confirmar. Esta operación puede tardar unos minutos en completarse.

gcloud

Para configurar los valores predeterminados a nivel de flota mediante la CLI de Google Cloud, debes establecer los siguientes ajustes:

Configuración a nivel de flota

Crea un archivo mesh.yaml que solo contenga la línea management: automatic:
```
echo "management: automatic" > mesh.yaml
```

Habilita Cloud Service Mesh para tu flota:

gcloud container fleet mesh enable --project FLEET_PROJECT_ID \
    --fleet-default-member-config mesh.yaml

Si ves el siguiente error, debes habilitar GKE Enterprise.

ERROR: (gcloud.container.fleet.mesh.enable) FAILED_PRECONDITION: The
[anthos.googleapis.com] service is required for this operation and is not
enabled for the project [PROJECT_NUMBER]. Please use the Google Developers
Console to enable it.: failed precondition

Configuración a nivel de red
- Si el proyecto de tu red es diferente del proyecto del host de tu flota (por ejemplo, si usas una VPC compartida), debes permitir que las cuentas de servicio de Cloud Service Mesh del proyecto de la flota accedan al proyecto de la red. Solo tienes que hacerlo una vez por proyecto de red.
  
  Concede a las cuentas de servicio del proyecto de flota permiso para acceder al proyecto de red:
```
gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent
```
Ajustes a nivel de clúster
- Cuando quieras crear clústeres para usarlos con Cloud Service Mesh, créalos y regístralos en un solo paso con la CLI de Google Cloud para usar la configuración predeterminada. Por ejemplo:
```
gcloud container clusters create-auto CLUSTER_NAME \
    --fleet-project FLEET_PROJECT_ID \
    --location=LOCATION
```
  Para obtener el número de proyecto de tu proyecto de flota, ejecuta el siguiente comando:
```
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
```
  La marca --location es la zona o región de proceso (por ejemplo, us-central1-a o us-central1) del clúster.
- Si el proyecto de tu clúster es diferente del proyecto host de tu flota, debes permitir que las cuentas de servicio de Cloud Service Mesh del proyecto de la flota accedan al proyecto del clúster y habilitar las APIs necesarias en el proyecto del clúster. Solo tienes que hacerlo una vez por cada proyecto de clúster.
  
  Concede a las cuentas de servicio del proyecto de flota permiso para acceder al proyecto de clúster:
```
gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent
```
  Habilita la API Mesh en el proyecto del clúster:
```
gcloud services enable mesh.googleapis.com \
  --project=CLUSTER_PROJECT_ID
```
  Sustituye CLUSTER_PROJECT_ID por el identificador único de tu proyecto de clúster. Si has creado el clúster en el mismo proyecto que la flota, el CLUSTER_PROJECT_ID es el mismo que el FLEET_PROJECT_ID.

Ve a Verificar que se ha aprovisionado el plano de control.

Configurar por clúster

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

Habilitar la función de flota de Cloud Service Mesh

Habilita la función mesh en el proyecto de flota. Ten en cuenta que, si tienes previsto registrar varios clústeres, la función de flota de Cloud Service Mesh se habilita a nivel de flota, por lo que solo tienes que ejecutar este comando una vez.

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Registrar clústeres en una flota

Registra un clúster de GKE con la identidad de cargas de trabajo de la flota. La marca --location es la zona de computación o la región (como us-central1-a o us-central1) del clúster.
```
gcloud container clusters update CLUSTER_NAME \
  --location CLUSTER_LOCATION \
  --fleet-project FLEET_PROJECT_ID
```

Verifica que tu clúster esté registrado:

gcloud container fleet memberships list --project FLEET_PROJECT_ID

Ejemplo:

NAME                 EXTERNAL_ID                           LOCATION
cluster-1            1d8e255d-2b55-4df9-8793-0435461a2cbc  us-central1

Apunta el MEMBERSHIP_NAME, ya que lo necesitarás cuando habilites la gestión automática.

Si el proyecto de la red de tu clúster es diferente del proyecto del host de tu flota (por ejemplo, si usas una VPC compartida), debes permitir que las cuentas de servicio de Cloud Service Mesh del proyecto de la flota accedan al proyecto de la red. Solo tienes que hacerlo una vez por proyecto de red.

Concede a las cuentas de servicio del proyecto de flota permiso para acceder al proyecto de red:
```
 gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
      --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
      --role roles/anthosservicemesh.serviceAgent
```
Si el proyecto de tu clúster es diferente del proyecto host de tu flota, debes permitir que las cuentas de servicio de Cloud Service Mesh del proyecto de la flota accedan al proyecto del clúster y habilitar las APIs necesarias en el proyecto del clúster.

Solo tienes que hacerlo una vez por cada proyecto de clúster. Si ya ha configurado Cloud Service Mesh gestionado para esta combinación de proyectos de clúster y de flota, estos cambios ya se han aplicado y no tiene que ejecutar los siguientes comandos.

Concede permiso a las cuentas de servicio del proyecto de la flota para acceder al proyecto del clúster:
```
 gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
     --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
     --role roles/anthosservicemesh.serviceAgent
```
Habilita la API Mesh en el proyecto del clúster:
```
 gcloud services enable mesh.googleapis.com \
     --project=CLUSTER_PROJECT_ID
```

Configurar el Servicio de Autoridades de Certificación (opcional)

Si tu implementación de malla de servicios requiere el Servicio de Autoridades de Certificación (Servicio de AC), sigue las instrucciones de Configurar el Servicio de Autoridades de Certificación para Cloud Service Mesh gestionado para habilitarlo en tu flota. Asegúrate de completar todos los pasos antes de pasar a la siguiente sección.

Habilitar la gestión automática

Ejecuta el siguiente comando para habilitar la gestión automática:

  gcloud container fleet mesh update \
     --management automatic \
     --memberships MEMBERSHIP_NAME \
     --project FLEET_PROJECT_ID \
     --location MEMBERSHIP_LOCATION

donde:

MEMBERSHIP_NAME es el nombre de la pertenencia que aparece cuando has verificado que tu clúster se ha registrado en la flota.
MEMBERSHIP_LOCATION es la ubicación de tu suscripción (una región o global).

Si has creado la pertenencia recientemente con el comando de esta guía, esta debería ser la región de tu clúster. Si tienes un clúster zonal, usa la región correspondiente a la zona del clúster. Por ejemplo, si tiene un clúster zonal en us-central1-c, use el valor us-central1.

Este valor puede ser global si te registraste antes de mayo del 2023 o si especificaste la ubicación global al registrar la suscripción. Puedes consultar la ubicación de tu suscripción con gcloud container fleet memberships list --project FLEET_PROJECT_ID.

Compatibilidad con Terraform

Cloud Service Mesh admite el aprovisionamiento mediante Terraform a través del módulo de pertenencia a la función GKE Hub.

Para obtener instrucciones detalladas, consulta el tutorial sobre cómo aprovisionar una malla de servicios gestionada.

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:

...
membershipSpecs:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/746296320118/locations/us-central1/memberships/demo-cluster-1:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        state: ACTIVE
        implementation: ISTIOD | TRAFFIC_DIRECTOR
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed.'
...

Anota el plano de control que se muestra en el campo implementation, ya sea ISTIOD o TRAFFIC_DIRECTOR. Consulta las funciones compatibles con Cloud Service Mesh para ver las diferencias del plano de control y las configuraciones admitidas, así como para saber cómo se selecciona la implementación del plano de control.

Configurar `kubectl` para que apunte al clúster

En las siguientes secciones se explica cómo ejecutar comandos kubectl en cada uno de tus clústeres. Antes de continuar con las siguientes secciones, ejecuta el siguiente comando en cada uno de tus clústeres para configurar kubectl de forma que apunte al clúster.

gcloud container clusters get-credentials CLUSTER_NAME \
      --location CLUSTER_LOCATION \
      --project CLUSTER_PROJECT_ID

Ten en cuenta que una puerta de enlace de entrada no se implementa automáticamente con el plano de control. Desacoplar el despliegue de la pasarela de entrada y del plano de control te permite gestionar tus pasarelas en un entorno de producción. Si quieres usar una pasarela de entrada o de salida de Istio, consulta Implementar pasarelas. Si quiere usar la API de Kubernetes Gateway, consulte Preparar Gateway para Mesh. Para habilitar otras funciones opcionales, consulta Habilitar funciones opcionales en Cloud Service Mesh.

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

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:

Ve a la página Comunicación.

Ir a la página Comunicación
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.

Si habilitas Cloud Service Mesh con la API Fleet, se habilitará el descubrimiento de endpoints para este clúster. Sin embargo, debes abrir los puertos del cortafuegos. Para inhabilitar el descubrimiento de endpoints en uno o varios clústeres, consulta las instrucciones para inhabilitarlo en Descubrimiento de endpoints entre clústeres con la API declarativa.

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)

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:

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.

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"

Migrar aplicaciones a Cloud Service Mesh gestionado

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

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

Gestionado (TD)

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

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.

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

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

Realiza una actualización continua de los despliegues del espacio de nombres:
```
kubectl rollout restart deployment -n NAMESPACE
```
Prueba tu aplicación para verificar que las cargas de trabajo funcionan correctamente.
Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos anteriores para cada espacio de nombres.
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:

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
```
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 Cloud Service Mesh

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.

Aprovisionar un plano de control de Cloud Service Mesh gestionado en GKE

Requisitos previos

Requisitos

Roles necesarios para instalar Cloud Service Mesh

Roles necesarios para ejecutar Cloud Service Mesh

Limitaciones

Antes de empezar

Si habilitas mesh.googleapis.com, se habilitarán las siguientes APIs:

Configurar Cloud Service Mesh gestionado

Configurar para tu flota

Consola

gcloud

Configurar por clúster

Habilitar la función de flota de Cloud Service Mesh

Registrar clústeres en una flota

Configurar el Servicio de Autoridades de Certificación (opcional)

Habilitar la gestión automática

Compatibilidad con Terraform

Verificar que se ha aprovisionado el plano de control

Configurar kubectl para que apunte al clúster

Plano de datos gestionado

Inhabilitar el plano de datos gestionado (opcional)

Habilitar ventanas de mantenimiento para el plano de datos gestionado

Habilitar las notificaciones de mantenimiento del plano de datos gestionado

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

Desplegar aplicaciones

Gestionado (TD)

Gestionado (Istiod)

Personalizar la inyección (opcional)

Migrar aplicaciones a Cloud Service Mesh gestionado

Gestionado (TD)

Gestionado (Istiod)

Eliminar el plano de control antiguo

Restaurar

Desinstalar Cloud Service Mesh

Configurar `kubectl` para que apunte al clúster