Aprovisiona un plano de control de Cloud Service Mesh administrado en GKE

Nota: Esta guía solo admite Cloud Service Mesh con las APIs de Istio y no las de Google Cloud. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Cloud Service Mesh es una malla de servicios administrada 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 API de Fleet para configurar Cloud Service Mesh administrado 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
• Habilita Workload Identity en tus clústeres y grupos de nodos.

Requisitos

• Uno o más clústeres con una versión de GKE compatible en una de las regiones admitidas.
• Asegúrate de que tu clúster tenga suficiente capacidad para los componentes necesarios que instala la versión administrada de Cloud Service Mesh en el clúster.
  • La implementación de mdp-controller en el espacio de nombres kube-system solicita CPU: 50 m, memoria: 128 Mi.
  • El daemonset istio-cni-node en el espacio de nombres kube-system solicita CPU: 100 m, memoria: 100 Mi en cada nodo.
• Asegúrate de que la política de la organización constraints/compute.disableInternetNetworkEndpointGroup esté inhabilitada. Si la política está habilitada, es posible que ServiceEntry no funcione.
• Asegúrate de que la máquina cliente desde la que aprovisiones Cloud Service Mesh administrada tenga conectividad de red al servidor de API.
• Tus clústeres deben estar registrados en una flota. Esto se incluye en las instrucciones o se puede realizar por separado antes de la aprovisionación.
• Tu proyecto debe tener habilitada la función de flota de Service Mesh. Esto se incluye en las instrucciones o se puede realizar por separado.

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

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

  • 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 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 Descripción general de las flotas.
  • Para un entorno de varios proyectos, te recomendamos que alojes la flota en un proyecto independiente de los proyectos de clúster. Si tus políticas organizacionales y la configuración existente lo permiten, te recomendamos que uses el proyecto de VPC compartida como el proyecto host de la flota. Para obtener más información, consulta Configura clústeres con VPC compartida.

Roles necesarios para instalar Cloud Service Mesh

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

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

Limitaciones

Precaución: Ten en cuenta las siguientes limitaciones específicas de la flota: - Todos los clústeres de un Cloud Service Mesh en particular deben estar registrados en la misma flota. Los clústeres no se pueden registrar en diferentes flotas. - Todos los clústeres de un proyecto que incluyan un clúster de Cloud Service Mesh deben estar registrados en la misma flota.

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

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

  Nota: Puedes habilitar las 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 convertir automáticamente otras funciones opcionales de IstioOperator a fin de que sean compatibles con el plano de control administrado. Si quieres obtener más información, consulta Migra desde IstioOperator.

• El uso del servicio de la autoridad certificadora (servicio de AC) requiere configurar Cloud Service Mesh por clúster y no es compatible con la configuración predeterminada de la flota en GKE Enterprise.

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

• Para los clústeres de Autopilot de GKE, para adaptarse al límite de recursos de Autopilot de GKE, los requisitos y límites de recursos del proxy predeterminados se establecen en 500 m de CPU y 512 MB de memoria. Puedes anular los valores predeterminados mediante la inyección personalizada.

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

• 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 es compatible con clústeres que tienen habilitada GKE Sandbox.

Antes de comenzar

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

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

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

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

   Go to project selector

5. Make sure that billing is enabled for your Google Cloud project.

6. Configura gcloud (incluso si usas Cloud Shell).
1. Autentica con Google Cloud CLI, en la que FLEET_PROJECT_ID es el ID de tu proyecto de 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
   

2. Actualiza los componentes:

          gcloud components update
   

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

Nota: Algunas APIs obligatorias tienen dependencias transitivas en otras 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 Cloud Service Mesh administrado

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

Configura la función para tu flota

Si habilitaste la edición empresarial de Google Kubernetes Engine (GKE), puedes habilitar Cloud Service Mesh administrado como una configuración predeterminada para tu flota. Esto significa que cada clúster nuevo de GKE en Google Cloud registrado durante la creación del clúster tendrá habilitado Cloud Service Mesh administrado en el clúster. Puedes obtener más información sobre la configuración predeterminada de la flota en Administra funciones a nivel de la flota.

Habilitar Cloud Service Mesh administrado como configuración predeterminada para tu flota y registrar clústeres en la flota durante la creación de clústeres solo es compatible con la CA de malla. Si deseas usar Certificate Authority Service, te recomendamos que lo habilites por clúster.

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

Console

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

   Ir a Administrador de funciones

2. En el panel Malla de servicios, haz clic en Configurar.

3. Revisa la configuración que heredan todos los clústeres nuevos que crees en la consola de Google Cloud y regístralos en la flota.

   Nota: Estos parámetros de configuración de GKE son requisitos previos para usar Cloud Service Mesh.

4. Para aplicar estos parámetros de configuración, haz clic en Configurar.

5. En el cuadro de diálogo Confirmación, haz clic en Confirmar.

6. 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 establecer la siguiente configuración:

• Configuración a nivel de la flota

  • Crea un archivo mesh.yaml que solo contenga la línea única 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 la red

  • Si el proyecto de tu red difiere del proyecto host de la flota (por ejemplo, estás usando una VPC compartida), debes permitir que las cuentas de servicio de Cloud Service Mesh en el proyecto de la flota accedan al proyecto de red. Solo debes hacerlo una vez para el proyecto de red.

    Otorga permiso a las cuentas de servicio del proyecto de flota para acceder al proyecto de red:

    gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
        --member "serviceAccount:[e-mail]" \
        --role roles/anthosservicemesh.serviceAgent
    

• Configuración a nivel del clúster

  • Cuando tengas todo listo para crear clústeres que se usarán con Cloud Service Mesh, créalos y regístralos en un solo paso con Google Cloud CLI 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 procesamiento (como us-central1-a o us-central1) del clúster.

  • Si el proyecto de tu clúster difiere del proyecto host de la flota, debes permitir que las cuentas de servicio de Cloud Service Mesh en el proyecto de la flota accedan al proyecto del clúster y habilitar las APIs requeridas en el proyecto del clúster. Solo debes hacerlo una vez para cada proyecto de clúster.

    Otorga permiso a las cuentas de servicio del proyecto de flota para acceder al proyecto del clúster:

    gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID"  \
        --member "serviceAccount:[e-mail]" \
        --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 tu clúster en el mismo proyecto que tu flota, CLUSTER_PROJECT_ID es igual que FLEET_PROJECT_ID.

Continúa con la sección para verificar si se aprovisionó el plano de control.

Configuración por clúster

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

Habilita la función de flota de Cloud Service Mesh

Habilita Cloud Service Mesh en el proyecto de flota. Ten en cuenta que, si planeas registrar varios clústeres, la habilitación de Cloud Service Mesh ocurre 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

1. Registra un clúster de GKE con la identidad de carga de trabajo de la flota. La marca --location es la zona de procesamiento 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
   

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

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

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

   Otorga permiso a las cuentas de servicio del proyecto de flota para acceder al proyecto de red:

    gcloud projects add-iam-policy-binding "NETWORK_PROJECT_ID"  \
         --member "serviceAccount:[e-mail]" \
         --role roles/anthosservicemesh.serviceAgent
   

4. Si el proyecto de tu clúster difiere del proyecto host de la flota, debes permitir que las cuentas de servicio de Cloud Service Mesh en el proyecto de la flota accedan al proyecto del clúster y habilitar las APIs requeridas en el proyecto del clúster.

   Solo debes hacerlo una vez para cada proyecto de clúster. Si anteriormente configuraste Cloud Service Mesh administrado para esta combinación de proyectos de clúster y de flota, estos cambios ya se aplicaron y no tienes que ejecutar los siguientes comandos.

   Otorga permiso a las cuentas de servicio del proyecto de flota para acceder al proyecto del clúster:

    gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
        --member "serviceAccount:[e-mail]" \
        --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 AC), sigue las instrucciones de Cómo configurar el servicio de la autoridad certificadora para Cloud Service Mesh administrado para habilitarlo en tu flota. Asegúrate de completar todos los pasos antes de continuar con la siguiente sección.

Habilita la administración automática

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

Nota: Puedes aplicar este cambio a varios clústeres a la vez pasando una lista de nombres de membresías separados por comas como el parámetro --memberships.

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

Donde:

• MEMBERSHIP_NAME es el nombre de membresía que aparece cuando verificaste que tu clúster estaba registrado en la flota.

• MEMBERSHIP_LOCATION es la ubicación de tu membresía (una región o global).

  Si creaste la membresía 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 tienes un clúster zonal en us-central1-c, usa el valor us-central1.

  Este valor puede ser global si te registraste antes de mayo de 2023 o si especificaste la ubicación global cuando registraste la membresía. Puedes verificar 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, ya sea ISTIOD o TRAFFIC_DIRECTOR. Consulta Funciones compatibles con Cloud Service Mesh para conocer las diferencias y las configuraciones compatibles del plano de control, y cómo se selecciona la implementación del plano de control.

Configura kubectl para que apunte al clúster

En las siguientes secciones, se incluyen instrucciones para ejecutar comandos kubectl en cada uno de tus clústeres. Antes de continuar con las siguientes secciones, ejecuta el siguiente comando para cada uno de tus clústeres para configurar kubectl para 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 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 tus puertas de enlace en un entorno de producción. Si deseas usar una puerta de enlace de entrada o de salida de Istio, consulta Implementa puertas de enlace. Si deseas usar la API de Kubernetes Gateway, consulta Cómo preparar la puerta de enlace para el entramado. Para habilitar otras funciones opcionales, consulta Habilita funciones opcionales en Cloud Service Mesh.

Plano de datos administrado

Si usas Cloud Service Mesh administrado, Google administra por completo las actualizaciones de tus proxies, a menos que lo inhabilites.

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

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

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

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

El plano de datos administrado no administra lo siguiente:

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

Inhabilita el plano de datos administrado (opcional)

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

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

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

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

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

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

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

Habilita las notificaciones de mantenimiento

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

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

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

   Ve a la página Comunicación

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

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

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

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

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

Estimado usuario de Cloud Service Mesh:

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

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

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

Atentamente,

El equipo de Cloud Service Mesh

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

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

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

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

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

Si habilitas Cloud Service Mesh con la API de la flota, se habilitará el descubrimiento de extremos para este clúster. Sin embargo, debes abrir los puertos del firewall. Para inhabilitar el descubrimiento de extremos para uno o más clústeres, consulta las instrucciones para inhabilitarlo en Detección 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.

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

Implementar aplicaciones

Si tienes más de un clúster en la flota que usa Cloud Service Mesh administrado, asegúrate de que el descubrimiento de extremos o los puertos de firewall estén configurados según lo previsto antes de continuar y, luego, implementar las aplicaciones.

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

Administrado (TD)

1. Aplica la etiqueta de inserción predeterminada al espacio de nombres:

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

Administrada (Istiod)

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

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

Si eres un usuario existente con el plano de control de Istio administrado, te recomendamos que uses la inserción predeterminada, pero también se admite la inserción basada en revisiones. Sigue estas instrucciones:

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

   kubectl -n istio-system get controlplanerevision
   

   El resultado es similar a este:

   NAME                AGE
   asm-managed-rapid   6d7h
   

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

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

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

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

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

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

Personaliza la inserción (opcional)

Puedes anular los valores predeterminados y personalizar la configuración de inserción, pero esto puede generar errores de configuración imprevistos y problemas con los contenedores de conjuntos secundarios. Antes de personalizar la inserción, lee la información después del ejemplo para ver notas sobre parámetros de configuración y recomendaciones específicos.

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

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

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

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

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

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

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

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

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

Migra aplicaciones a Cloud Service Mesh administrado

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

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

Nota: Asegúrate de haber aprovisionado Cloud Service Mesh administrado siguiendo todas las secciones anteriores de esta guía.
1. Reemplaza la etiqueta del espacio de nombres actual. Los pasos dependen de tu implementación del plano de control.

Administrado (TD)

1. Aplica la etiqueta de inserción predeterminada al espacio de nombres:

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

Administrada (Istiod)

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

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

Si eres un usuario existente con el plano de control de Istio administrado, te recomendamos que uses la inserción predeterminada, pero también se admite la inserción basada en revisiones. Sigue estas instrucciones:

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

   kubectl -n istio-system get controlplanerevision
   

   El resultado es similar a este:

   NAME                AGE
   asm-managed-rapid   6d7h
   

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

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

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

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

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

   kubectl rollout restart deployment -n NAMESPACE
   

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

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

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

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

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

Borrar el plano de control anterior

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

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

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

Revertir

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

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

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

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

   kubectl rollout restart deployment -n NAMESPACE
   

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

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

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

Espera el siguiente resultado con éxito:

deployment.apps/istio-ingressgateway rolled back

Desinstala Cloud Service Mesh

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