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

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

Aprovisionar un plano de control de la malla de servicios de Cloud administrado en GKE

Cloud Service Mesh es una malla de servicios administrados por Google que solo debes habilitar. Google se encarga de la confiabilidad, las actualizaciones, el escalamiento y la seguridad por ti.

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

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
Obtuviste los permisos necesarios para aprovisionar Cloud Service Mesh
Habilitada Workload Identity en tus clústeres.

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 la capacidad suficiente para los componentes requeridos que instalaciones de Cloud Service Mesh administradas en el clúster.
- La implementación de mdp-controller en el espacio de nombres kube-system solicita la CPU: 50 m, memoria: 128 Mi.
- El daemonset istio-cni-node en el espacio de nombres kube-system solicita CPU virtuales: 100 m, memoria: 100 Mi en cada nodo.
Asegúrate de que la máquina cliente desde la que aprovisionas Cloud Service Mesh administrado tenga conectividad de red al servidor de la API.
Tus clústeres deben estar registrados en una flota. Esto se incluye en las instrucciones o puede hacerse por separado antes de la de servicios.
Tu proyecto debe tener habilitada la función de flota de Service Mesh. Este es incluidas en las instrucciones o pueden realizarse por separado.
GKE Autopilot solo es compatible con la versión de GKE 1.21.3+.
Cloud Service Mesh puede usar varios clústeres de GKE en una un entorno de red única de proyecto único o una red única de varios proyectos en un entorno de nube.
- 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 de proyecto único, el proyecto de flota puede ser 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 tu organización de políticas y la configuración existente lo permiten, 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.

Funciones necesarias para instalar Cloud Service Mesh

En la siguiente tabla, se describen los roles necesarios para instalar la malla de servicios en la nube.

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

Limitaciones

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

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

Nota: Aún puedes habilitar funciones opcionales sin usar la API de IstioOperator. consulta Habilita funciones opcionales en Cloud Service Mesh administrado. También puedes usar la herramienta de migración incluida con asmcli para realizar automáticamente convertir otras funciones opcionales de IstioOperator para que sean compatibles plano de control administrado. Si quieres obtener más información, consulta Migra desde IstioOperator.
El uso de Certificate Authority Service (CA Service) requiere configurar Cloud Service Mesh por clúster, y no es compatible cuando se usa la configuración de flota predeterminada en GKE Enterprise.
Para los clústeres de GKE Autopilot, la configuración entre proyectos solo es compatible con GKE 1.23 o una versión posterior.
Para los clústeres de GKE Autopilot, para adaptarte al Límite de recursos de GKE Autopilot, las solicitudes y los límites predeterminados de recursos del proxy están establecidos en 500 m de CPU y 512 MB memoria. Puedes anular los valores predeterminados usando inyección personalizada.
Durante el proceso de aprovisionamiento de un plano de control administrado, aprovisionados en el clúster especificado. Si hay CRD de Istio existentes en el clúster, se reemplazarán
CNI de Istio y Cloud Service Mesh no son compatibles con GKE Sandbox. Por lo tanto, Cloud Service Mesh administrado con la implementación de TRAFFIC_DIRECTOR no admite clústeres con GKE Sandbox habilitado.

Antes de comenzar

Accede a tu cuenta de Google Cloud. Si eres nuevo en Google Cloud, crea una cuenta para evaluar el rendimiento de nuestros productos en situaciones reales. Los clientes nuevos también obtienen $300 en créditos gratuitos para ejecutar, probar y, además, implementar cargas de trabajo.

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

Go to project selector

Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

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

Go to project selector

Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.

Configura gcloud (incluso si usas Cloud Shell).

Autenticar con Google Cloud CLI, donde FLEET_PROJECT_ID es el ID del proyecto host de la flota. En 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 el proyecto host de tu flota.

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

Habilitar mesh.googleapis.com habilita las siguientes APIs:

API	Objetivo	Se puede inhabilitar
`meshconfig.googleapis.com`	Cloud Service Mesh usa la API de configuración de malla para retransmitir datos de configuración de tu malla a Google Cloud. Además, habilitar la API de configuración de malla te permite acceder a las páginas de Cloud Service Mesh en la consola de Google Cloud y usar la autoridad certificadora de Cloud Service Mesh.	No
`meshca.googleapis.com`	Se relaciona con la autoridad certificadora de Cloud Service Mesh que usa Cloud Service Mesh administrado.	No
`container.googleapis.com`	Obligatorio para crear clústeres de Google Kubernetes Engine (GKE).	No.
`gkehub.googleapis.com`	Es obligatorio para administrar la malla como una flota.	No.
`monitoring.googleapis.com`	Se requiere para capturar la telemetría de las cargas de trabajo en malla.	No.
`stackdriver.googleapis.com`	Obligatorio para usar la IU de los servicios.	No.
`opsconfigmonitoring.googleapis.com`	Se requiere para usar la IU de servicios en clústeres fuera de Google Cloud.	No
`connectgateway.googleapis.com`	Es obligatorio para que el plano de control de Cloud Service Mesh administrado pueda acceder a las cargas de trabajo de la malla.	Sí*
`trafficdirector.googleapis.com`	Habilita un plano de control administrado escalable y con alta disponibilidad.	Sí*
`networkservices.googleapis.com`	Habilita un plano de control administrado escalable y con alta disponibilidad.	Sí*
`networksecurity.googleapis.com`	Habilita un plano de control administrado escalable y con alta disponibilidad.	Sí*

Advertencia: Inhabilitar connectgateway.googleapis.com, trafficdirector.googleapis.com, networkservices.googleapis.com o networksecurity.googleapis.com hace que el plano de control de Cloud Service Mesh administrado deje de funcionar. Si la flota no usa Cloud Service Mesh administrado en ningún clúster, se pueden inhabilitar estas APIs.

Configura la malla de servicios de Cloud administrados

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

Configurar para tu flota

Si has habilitado edición Google Kubernetes Engine (GKE) Enterprise, puedes habilitar Cloud Service Mesh administrado como una configuración predeterminada para tu flota Esta significa que cada clúster nuevo de GKE en Google Cloud registrado durante el de la creación tener habilitado Cloud Service Mesh administrado en el clúster. Puedes encontrar más información sobre configuración predeterminada de la flota en Administrar la flota a nivel atributos.

Habilitar Cloud Service Mesh administrado como configuración predeterminada para tu flota y registrar clústeres a la flota durante su creación solo admite CA de Mesh. Si quieres usar Certificate Authority Service te recomendamos que lo habilites por clúster.

Para habilitar los valores predeterminados a nivel de la flota para la malla de servicios de Cloud administrado, completa la los siguientes pasos:

Console

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

Ir a Administrador de funciones
En el panel Malla de servicios, haz clic en Configurar.
Revisa la configuración que heredan todos los clústeres nuevos que crear en la consola de Google Cloud y registrarte en la flota.

Nota: Esta configuración es de GKE y es un requisito previo para usar Cloud Service Mesh.
Para aplicar esta configuración, haz clic en Configurar.
En el cuadro de diálogo Confirmación, haz clic en Confirmar.
Opcional: Sincroniza los clústeres existentes con la configuración predeterminada:
1. En la lista Clústeres de la flota, selecciona los clústeres que deseas 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, luego, en Confirmar en el cuadro de diálogo de confirmación que aparece. Esta operación puede tardar unos minutos en completarse.

gcloud

Para configurar los valores predeterminados a nivel de la flota con Google Cloud CLI, debes establece la siguiente configuración:

Configuración a nivel de la flota

Crea un archivo mesh.yaml que contenga solo 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 en el nivel de la red
- Si el proyecto de tu red difiere del proyecto host de tu flota (por ejemplo, estás usando una VPC compartida), debes permitir las cuentas de servicio de la malla de servicios de Cloud en el proyecto de la flota proyecto de red. Solo debes hacerlo una vez para el proyecto de red.
  
  Otorga permiso a las cuentas de servicio del proyecto de la flota 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
```
Configuración a nivel de clúster
- Cuando esté todo listo para crear clústeres para usarlos con Cloud Service Mesh, crea registrarlos en un solo paso con Google Cloud CLI configuración. Por ejemplo:
```
gcloud container clusters create-auto CLUSTER_NAME \
    --fleet-project FLEET_PROJECT_ID \
    --location=LOCATION
```
  Para obtener el número del proyecto de la flota, ejecuta el comando siguiente comando:
```
gcloud projects list --filter="FLEET_PROJECT_ID" --format="value(PROJECT_ID)"
```
  La marca --location es la zona o región de procesamiento (como us-central1-a o us-central1) para el clúster.
- Si el proyecto de tu clúster difiere del proyecto host de tu flota, debes para permitir que las cuentas de servicio de Cloud Service Mesh del proyecto de la flota accedan al proyecto del clúster y habilita las APIs necesarias en él. Solo debes deberás hacer esto una vez para cada proyecto de clúster.
  
  Otorga permiso a las cuentas de servicio del proyecto de la flota para acceder al 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 de Mesh en el proyecto del clúster:
```
gcloud services enable mesh.googleapis.com \
  --project=CLUSTER_PROJECT_ID
```
  Reemplaza CLUSTER_PROJECT_ID por el identificador único de tu proyecto de clúster. Si creaste el clúster en el mismo proyecto que tu flota, el CLUSTER_PROJECT_ID es el mismo que FLEET_PROJECT_ID

Continuar con Verifica que se haya aprovisionado el plano de control.

Configuración por clúster

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

Habilitar la función de flota de la malla de servicios de Cloud

Habilitar Cloud Service Mesh en el proyecto de la flota. Ten en cuenta que si planeas registrarte en varios clústeres, lo que permite que Cloud Service Mesh se realice a nivel de la flota, por lo que solo tendrás que ejecutar este comando una vez.

gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Registra clústeres en una flota

Registra un clúster de GKE con Workload Identity de la flota. La marca --location es la zona de procesamiento o 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

Salida de ejemplo:

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

Toma nota del MEMBERSHIP_NAME, ya que lo necesitarás cuando habilitar la administración automática.

Si el proyecto de red de tu clúster difiere del proyecto host de tu flota (por ejemplo, si usas una VPC compartida), debes permitir las cuentas de servicio de la malla de servicios de Cloud en el proyecto de la flota proyecto de red. Solo debes hacerlo una vez para el proyecto de red.

Otorga permiso a las cuentas de servicio del proyecto de la flota 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 difiere del proyecto host de tu flota, debes permitir Las cuentas de servicio de la malla de servicios de Cloud en el proyecto de la flota para acceder al clúster y habilita las APIs necesarias en el proyecto del clúster.

Solo debes hacer esto una vez para cada proyecto de clúster. Si anteriormente configuró Cloud Service Mesh administrado para esta combinación de clústeres proyectos de flota, estos cambios ya se aplicaron y no tendrás que ejecutar los siguientes comandos.

Otorga permiso para acceder al clúster a las cuentas de servicio del proyecto de la flota proyecto:
```
 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 de Mesh en el proyecto del clúster:
```
 gcloud services enable mesh.googleapis.com \
     --project=CLUSTER_PROJECT_ID
```

Configura Certificate Authority Service (opcional)

Si la implementación de tu malla de servicios requiere Certificate Authority Service (Servicio de CA), Luego, sigue los pasos que se indican en Configura Certificate Authority Service para la malla de servicios administrados. para habilitarla en tu flota. Asegúrate de completar todos los pasos antes de continuar a la siguiente sección.

Habilitar la administración automática

Ejecuta el siguiente comando para habilitar la administració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 membresía que aparece cuando realizaste la verificación que tu clúster se registró en la flota.
MEMBERSHIP_LOCATION es la ubicación de tu membresía (ya sea una región o global).

Si creaste la membresía recientemente con el comando de esta guía, debería ser la región de tu clúster. Si tienes un clúster zonal, usa el región correspondiente a la zona del clúster. Por ejemplo, si tienes una configuración en us-central1-c y, luego, usa el valor us-central1.

Este valor puede ser global si te registraste antes de mayo de 2023 o si especificó la ubicación global cuando registró la membresía. Puedes verifica la ubicación de tu membresía con gcloud container fleet memberships list --project FLEET_PROJECT_ID.

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:

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

Toma nota del plano de control que se muestra en el campo implementation: ISTIOD o TRAFFIC_DIRECTOR. Consulta Funciones compatibles con Cloud Service Mesh para conocer las diferencias del plano de control y las configuraciones admitidas, la implementación del plano de control.

Configura `kubectl` para que apunte al clúster

Las siguientes secciones implican la ejecución de comandos kubectl en cada uno de tus clústeres. Antes de continuar con las siguientes secciones, ejecuta siguiente comando para cada uno de los clústeres a fin de configurar kubectl de modo que apunte a en el 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 de forma automática con el plano de control. Separar la implementación de la puerta de enlace de entrada y el plano de control te permite administrar con mayor facilidad las puertas de enlace en un entorno de producción. Si el clúster necesita una puerta de enlace de entrada o una de salida, consulta Implementa puertas de enlace. Para habilitar otros funciones opcionales, consulta Habilita funciones opcionales en Cloud Service Mesh.

Plano de datos administrado

Si usas Cloud Service Mesh administrado, Google administra completamente las actualizaciones de tus proxies a menos que la inhabilites.

Con el plano de datos administrado, los proxies de sidecar y las puertas de enlace insertadas se automáticamente junto con el plano de control administrado reiniciar las cargas de trabajo para reinsertar nuevas versiones del proxy. Normalmente, se completa entre 1 y 2 semanas después de que se actualiza el plano de control administrado.

Si se inhabilita, la administración del proxy está controlada por el ciclo de vida natural de los Pods en el clúster y el usuario debe activarlo manualmente para controlar la actualización tasa.

El plano de datos administrado actualiza los proxies expulsando los Pods que se están ejecutando versiones anteriores del proxy. Las expulsiones se realizan gradualmente, respetando el el presupuesto de interrupción de Pods y controlar la frecuencia de cambio.

El plano de datos administrado no administra lo siguiente:

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

Inhabilita el plano de datos administrado (opcional)

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

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

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

Para inhabilitar el plano de datos administrado 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 administrado de un Pod, haz lo siguiente:

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 en curso una semana antes del horario de mantenimiento programado. No se envían las notificaciones de mantenimiento de forma predeterminada. También debes Configura un período de mantenimiento de GKE para poder recibir notificaciones. Cuando esta opción está habilitada, las notificaciones se envían a 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:

Ve a la página Comunicación.

Ve 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 selección para ACTIVAR las notificaciones de mantenimiento.

Cada usuario que desee recibir notificaciones debe habilitarlas por separado. Si quieres para establecer un filtro de correo electrónico para estas notificaciones, el asunto es el siguiente:

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

En el siguiente ejemplo, se muestra el mantenimiento típico de un plano de datos administrado notificación:

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

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}) están programados para actualizarse el ${scheduled_date_human_README} a las ${scheduled_time_human_README}.

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

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

Atentamente,

El equipo de Cloud Service Mesh

(c) 2023 Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043 Te enviamos este anuncio para informarte sobre cambios importantes en tu cuenta o en 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/eficiencia?project=${project_id}.

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

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

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

Habilitar Cloud Service Mesh con la API de la flota habilitará el descubrimiento de extremos para este clúster. Sin embargo, debes puertos de firewall abiertos. Para inhabilitar el descubrimiento de extremos de uno o más clústeres, consulta las instrucciones para inhabilitarla en Descubrimiento de extremos entre clústeres con una API declarativa.

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

Implementar aplicaciones

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

Administrado (TD)

Aplica la etiqueta de inyección predeterminada al espacio de nombres:

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

Administrado (Istiod)

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

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

Si eres un usuario existente con el plano de control administrado de Istiod, haz lo siguiente: Recomendamos que uses la inyección predeterminada, pero la inyección basada en revisiones no es compatible. Sigue estas instrucciones:

Ejecuta el siguiente comando para ubicar los canales de versiones disponibles:
```
kubectl -n istio-system get controlplanerevision
```
El resultado es similar a este:
```
NAME                AGE
asm-managed-rapid   6d7h
```
NOTA: Si dos revisiones del plano de control aparecen en la lista anterior, quita una. No se admite tener varios canales del plano de control en el clúster.

En el resultado, el valor de la columna NAME es la etiqueta de revisión que corresponde al canal de versiones 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

En este punto, configuraste correctamente la malla de servicios administrados de Cloud. Si tienes cargas de trabajo existentes en espacios de nombres etiquetados, y luego, debes reiniciarlas para que proxies insertados.

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

Personaliza la inserción (opcional)

Puedes anular los valores predeterminados y personalizar la configuración de inserción, pero esto puede ocasionar errores de configuración imprevistos y problemas resultantes con un archivo adicional. contenedores. Antes de personalizar la inyección, lee la información después de en el ejemplo sobre las notas sobre parámetros de configuración y recomendaciones particulares.

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. El archivo adicional tratará cualquier configuración definida aquí como una anulación del plantilla de inyección predeterminada.

Por ejemplo, con la siguiente configuración, se personalizan diversos parámetros como disminuir las solicitudes de CPU, agregar una activación de volumen y una Hook preStop:

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

En general, se puede configurar cualquier campo en un Pod. Sin embargo, se debe tener cuidado campos específicos:

Kubernetes requiere que se configure el campo image antes de que se ejecute la inyección. Si bien puedes configurar una imagen específica para anular la predeterminada, te recomendamos establece image en auto, lo que hará que el inyector de sidecar para seleccionar automáticamente la imagen que deseas usar.
Algunos campos de containers dependen de la configuración relacionada. Por ejemplo: debe ser menor o igual que el límite de CPU. Si ninguno de los dos campos configurado, es posible que el Pod no se inicie.
Kubernetes te permite configurar requests y limits para los recursos de tu Pod spec. GKE Autopilot solo considera requests. Para ver más consulta Establece límites de recursos en Autopilot.

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

Para GKE Standard, si se configura sidecar.istio.io/proxyCPU, haz asegúrate de establecer sidecar.istio.io/proxyCPULimit de forma explícita. De lo contrario, el archivo El límite de CPU se establecerá como ilimitado.
En GKE Standard, si se configura sidecar.istio.io/proxyMemory, asegúrate de establecer sidecar.istio.io/proxyMemoryLimit de forma explícita. De lo contrario, el el límite de memoria del archivo adicional se establecerá como ilimitado.
Para GKE Autopilot, configura los recursos requests y limits usar anotaciones podría aprovisionar recursos en exceso. Usa el enfoque de plantillas de imagen que debes evitar. 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"

Migra aplicaciones a Cloud Service Mesh administrado

Para migrar aplicaciones de Cloud Service Mesh en el clúster a Cloud Service Mesh administrado, realiza los siguientes pasos:

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

Administrado (TD)

Aplica la etiqueta de inyección predeterminada al espacio de nombres:

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

Administrado (Istiod)

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

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

Ejecuta el siguiente comando para ubicar los canales de versiones disponibles:
```
kubectl -n istio-system get controlplanerevision
```
El resultado es similar a este:
```
NAME                AGE
asm-managed-rapid   6d7h
```
NOTA: Si dos revisiones del plano de control aparecen en la lista anterior, quita una. No se admite tener varios canales del plano de control en el clúster.

En el resultado, el valor de la columna NAME es la etiqueta de revisión que corresponde al canal de versiones 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 progresiva de las implementaciones en el espacio de nombres:
```
kubectl rollout restart deployment -n NAMESPACE
```
Prueba la aplicación para verificar que las cargas de trabajo funcionen de forma correcta.
Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos anteriores para cada espacio de nombres.
Si implementaste la aplicación en una configuración de varios clústeres, replica la configuración de Istio y Kubernetes en todos los clústeres, a menos que exista el deseo de limitar esa configuración a un subconjunto de clústeres solamente. La configuración que se aplica a un clúster en particular es la fuente de información de ese clúster.

Si sabes con certeza que tu aplicación funciona como se esperaba, puedes eliminar el istiod en el clúster después de cambiar todos los espacios de nombres al control administrado o los conserva como copia de seguridad: istiod reducirá automáticamente la escala para usar menos recursos. Para quitarlos, vaya 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:

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
```
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 revertir el proceso, vuelve a ejecutarlo. el comando de instalación de la malla de servicios de Cloud, que volverá a implementar la puerta de enlace que apunta hacia atrás 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

Desinstala Cloud Service Mesh

El plano de control administrado realiza un ajuste de escala automático a cero cuando ningún espacio de nombres lo usa. Para para conocer los pasos detallados, consulta Desinstala Cloud Service Mesh.

Aprovisionar un plano de control de la malla de servicios de Cloud administrado en GKE

Requisitos previos

Requisitos

Funciones necesarias para instalar Cloud Service Mesh

Limitaciones

Antes de comenzar

Habilitar mesh.googleapis.com habilita las siguientes APIs:

Configura la malla de servicios de Cloud administrados

Configurar para tu flota

Console

gcloud

Configuración por clúster

Habilitar la función de flota de la malla de servicios de Cloud

Registra clústeres en una flota

Configura Certificate Authority Service (opcional)

Habilitar la administración automática

Verifica si se aprovisionó el plano de control

Configura kubectl para que apunte al clúster

Plano de datos administrado

Inhabilita el plano de datos administrado (opcional)

Habilita las notificaciones de mantenimiento

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

Implementar aplicaciones

Administrado (TD)

Administrado (Istiod)

Personaliza la inserción (opcional)

Migra aplicaciones a Cloud Service Mesh administrado

Administrado (TD)

Administrado (Istiod)

Borrar el plano de control anterior

Revertir

Desinstala Cloud Service Mesh

Configura `kubectl` para que apunte al clúster