Actualizaciones de configuración para la modernización

En este documento, se describen las actualizaciones de configuración que debes realizar en tus clústeres de Cloud Service Mesh administrados si las verificaciones de compatibilidad las marcan antes de modernizar el plano de control ISTIOD obsoleto al plano de control TRAFFIC_DIRECTOR antes de la fecha límite de finalización de la asistencia.

A continuación, se muestra una lista de las posibles actualizaciones de configuración necesarias para preparar tu clúster para la modernización. Consulta cada sección para obtener instrucciones de actualización:

Para obtener más información sobre el flujo de trabajo de modernización, consulta la página Modernización del plano de control administrado.

Migra de los Secrets de Istio a multicluster_mode

Los secretos de varios clústeres no se admiten cuando un clúster usa el plano de control de TRAFFIC_DIRECTOR. En este documento, se describe cómo puedes modernizar el uso de secretos de varios clústeres de Istio para usar multicluster_mode.

Descripción general de los secretos de Istio en comparación con la API declarativa

El descubrimiento de extremos de Istio de código abierto para varios clústeres funciona con istioctl o con otras herramientas para crear un Secret de Kubernetes en un clúster. Este Secret permite que un clúster balancee las cargas del tráfico a otro clúster de la malla. Luego, el plano de control de ISTIOD lee este Secret y comienza a enrutar el tráfico a ese otro clúster.

Cloud Service Mesh tiene una API declarativa para controlar el tráfico de varios clústeres en lugar de crear secretos de Istio directamente. Esta API trata los secretos de Istio como un detalle de implementación y es más confiable que crear secretos de Istio de forma manual. Las funciones futuras de Cloud Service Mesh dependerán de la API declarativa, y no podrás usar esas funciones nuevas con los Secrets de Istio directamente. La API declarativa es la única ruta de acceso admitida en el futuro.

Si usas Secrets de Istio, migra a la API declarativa lo antes posible. Ten en cuenta que el parámetro de configuración multicluster_mode indica a cada clúster que dirija el tráfico a todos los demás clústeres de la malla. El uso de Secrets permite una configuración más flexible, ya que te permite configurar para cada clúster a qué otro clúster debe dirigir el tráfico en la malla. Para obtener una lista completa de las diferencias entre las funciones compatibles de la API declarativa y los secretos de Istio, consulta Funciones compatibles con las APIs de Istio.

Migra de los secretos de Istio a la API declarativa

Si aprovisionaste Cloud Service Mesh con la administración automática con la API de funciones de la flota, no necesitas seguir estas instrucciones. Estos pasos solo se aplican si realizaste la incorporación con asmcli --managed.

Ten en cuenta que este proceso cambia los secretos que apuntan a un clúster. Durante este proceso, los extremos se quitan y, luego, se vuelven a agregar. Entre la eliminación y la adición de los extremos, el tráfico volverá brevemente al enrutamiento local en lugar de balancear las cargas a otros clústeres. Para obtener más información, consulta el problema de GitHub.

Para pasar de usar secretos de Istio a la API declarativa, sigue estos pasos. Ejecuta estos pasos al mismo tiempo o en una sucesión rápida:

  1. Habilita la API declarativa para cada clúster de la flota en el que quieras habilitar el descubrimiento de extremos de varios clústeres configurando multicluster_mode=connected. Ten en cuenta que debes configurar de forma explícita multicluster_mode=disconnected si no quieres que se pueda descubrir el clúster.

    Usa el siguiente comando para habilitar un clúster para el descubrimiento de extremos de varios clústeres:

     kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'

    Usa el siguiente comando para inhabilitar la detección de extremos en un clúster:

     kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'

  2. Borra los secretos antiguos.

    Después de configurar multicluster_mode=connected en tus clústeres, cada clúster tendrá un secreto nuevo generado para cada uno de los demás clústeres que también tengan configurado multicluster_mode=connected. El Secret se coloca en el espacio de nombres istio-system y tiene el siguiente formato:

    istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS

    Cada secreto también tendrá aplicada la etiqueta istio.io/owned-by: mesh.googleapis.com.

    Una vez que se creen los Secrets nuevos, puedes borrar los Secrets creados de forma manual con istioctl create-remote-secret:

    kubectl delete secret SECRET_NAME -n istio-system

Una vez que se haya completado la migración, verifica las métricas de solicitudes para asegurarte de que se enruten como se espera.

Habilita la federación de identidades para cargas de trabajo para GKE

La federación de identidades para cargas de trabajo es el método seguro recomendado para las cargas de trabajo de Google Kubernetes Engine. Esto permite el acceso a los servicios de Google Cloud , como Compute Engine, BigQuery y las APIs de aprendizaje automático. La federación de identidades para cargas de trabajo no requiere configuración manual ni métodos menos seguros, como los archivos de claves de la cuenta de servicio, porque usa políticas de IAM. Para obtener más detalles sobre la federación de identidades para cargas de trabajo, consulta Cómo funciona la federación de identidades para cargas de trabajo para GKE.

En la siguiente sección, se describe cómo habilitar la federación de identidades para cargas de trabajo.

Habilita la federación de identidades para cargas de trabajo en los clústeres

  1. Verifica que la federación de identidades para cargas de trabajo esté habilitada en tu clúster. Para ello, asegúrate de que el clúster de GKE tenga configurado un conjunto de grupos de Workload Identity Federation, lo que es esencial para la validación de credenciales de IAM.

    Usa el siguiente comando para verificar el grupo de identidades para cargas de trabajo establecido para un clúster:

    gcloud container clusters describe CLUSTER_NAME \
  --format="value(workloadIdentityConfig.workloadPool)"

    Reemplaza CLUSTER_NAME por el nombre de tu clúster de GKE. Si aún no especificaste una zona o región predeterminada para gcloud, es posible que también debas especificar una marca --region o --zone cuando ejecutes este comando.

  2. Si el resultado está vacío, sigue las instrucciones que se indican en Actualiza un clúster existente para habilitar Workload Identity en clústeres de GKE existentes.

Habilita la federación de identidades para cargas de trabajo en grupos de nodos

Después de habilitar la federación de identidades para cargas de trabajo en un clúster, se deben configurar los grupos de nodos para usar el servidor de metadatos de GKE.

  1. Enumera todos los grupos de nodos de un clúster de Standard. Ejecuta el comando gcloud container node-pools list:

    gcloud container node-pools list --cluster CLUSTER_NAME

    Reemplaza CLUSTER_NAME por el nombre de tu clúster de GKE. Si aún no especificaste una zona o región predeterminada para gcloud, es posible que también debas especificar una marca --region o --zone cuando ejecutes este comando.

  2. Verifica que cada grupo de nodos use el servidor de metadatos de GKE:

    gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"

    Reemplaza lo siguiente:

    • NODEPOOL_NAME por el nombre de tu grupo de nodos.
    • CLUSTER_NAME por el nombre de tu clúster de GKE.

  3. Si el resultado no contiene GKE_METADATA, actualiza el grupo de nodos con la guía Actualiza un grupo de nodos existente.

Habilita la interfaz de red de contenedor (CNI) administrada

En esta sección, se explica cómo habilitar la CNI administrada para Cloud Service Mesh en Google Kubernetes Engine.

Descripción general de la CNI administrada

La interfaz de red de contenedor (CNI) administrada es una implementación administrada por Google de la CNI de Istio. El complemento de CNI optimiza las redes de Pods configurando reglas de iptables. Esto permite el redireccionamiento del tráfico entre las aplicaciones y los proxies de Envoy, lo que elimina la necesidad de permisos con privilegios para el contenedor de inicialización necesario para administrar iptables.

El complemento de CNI de Istio reemplaza el contenedor istio-init. Anteriormente, el contenedor istio-init era responsable de configurar el entorno de red del Pod para habilitar la intercepción de tráfico para el sidecar de Istio. El complemento de CNI realiza la misma función de redireccionamiento de red, pero con el beneficio adicional de reducir la necesidad de privilegios elevados, lo que mejora la seguridad.

Por lo tanto, para mejorar la seguridad y la confiabilidad, y simplificar la administración y la solución de problemas, se requiere la CNI administrada en todas las implementaciones de Cloud Service Mesh administrado.

Impacto en los contenedores de inicio

Los contenedores init son contenedores especializados que se ejecutan antes que los contenedores de la aplicación para realizar tareas de configuración. Las tareas de configuración pueden incluir tareas como descargar archivos de configuración, comunicarse con servicios externos o realizar la inicialización previa a la aplicación. Los contenedores de inicialización que dependen del acceso a la red pueden tener problemas cuando se habilita la CNI administrada en el clúster.

El proceso de configuración de Pods con CNI administrada es el siguiente:

  1. El complemento de CNI configura las interfaces de red de los Pods, asigna las IPs de los Pods y redirecciona el tráfico al proxy de sidecar de Istio, que aún no se inició.
  2. Todos los contenedores de inicialización se ejecutan y completan.
  3. El proxy de sidecar de Istio se inicia junto con los contenedores de la aplicación.

Por lo tanto, si un contenedor de inicialización intenta establecer conexiones de red salientes o conectarse a servicios dentro de la malla, es posible que se descarten o se enruten de forma incorrecta las solicitudes de red de los contenedores de inicialización. Esto se debe a que el proxy de sidecar de Istio, que administra el tráfico de red del Pod, no se está ejecutando cuando se realizan las solicitudes. Para obtener más detalles, consulta la documentación de Istio CNI.

Habilita la CNI administrada para tu clúster

Sigue los pasos de esta sección para habilitar la CNI administrada en tu clúster.

  1. Quita las dependencias de red de tu contenedor de inicialización. Considera las siguientes alternativas:

    • Modifica la lógica o los contenedores de la aplicación: Puedes modificar tus servicios para quitar la dependencia de los contenedores de inicio que requieren solicitudes de red o realizan operaciones de red dentro de los contenedores de tu aplicación, después de que se haya iniciado el proxy de sidecar.
    • Usa ConfigMaps o Secrets de Kubernetes: Almacena los datos de configuración recuperados por la solicitud de red en ConfigMaps o Secrets de Kubernetes y móntalos en los contenedores de tu aplicación. Para conocer soluciones alternativas, consulta la documentación de Istio.

  2. Habilita la CNI administrada en tu clúster:

    1. Realiza los siguientes cambios de configuración:

      1. Ejecuta el siguiente comando para ubicar el controlPlaneRevision.

        kubectl get controlplanerevision -n istio-system

      2. En tu recurso personalizado (CR) ControlPlaneRevision (CPR), establece la etiqueta mesh.cloud.google.com/managed-cni-enabled en true.

        kubectl label controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/managed-cni-enabled=true \
    --overwrite

        Reemplaza CPR_NAME por el valor de la columna NAME del resultado del paso anterior.

      3. En el ConfigMap asm-options, establece el valor de ASM_OPTS como CNI=on.

        kubectl patch configmap asm-options -n istio-system \
    -p '{"data":{"ASM_OPTS":"CNI=on"}}'

      4. En tu recurso personalizado (CR) ControlPlaneRevision (CPR), establece la anotación mesh.cloud.google.com/force-reprovision en true. Esta acción activa el reinicio del plano de control.

        kubectl annotate controlplanerevision CPR_NAME \
    -n istio-system mesh.cloud.google.com/force-reprovision=true \
    --overwrite

    2. Verifica el estado de la función. Recupera el estado de la función con el siguiente comando:

      gcloud container fleet mesh describe --project FLEET_PROJECT_ID

      Reemplaza FLEET_PROJECT_ID por el ID del proyecto host de tu flota. Por lo general, el FLEET_PROJECT_ID tiene el mismo nombre que el proyecto.

      • Verifica que la condición MANAGED_CNI_NOT_ENABLED se quite de servicemesh.conditions.
      • Ten en cuenta que el estado puede tardar entre 15 y 20 minutos en actualizarse. Espera unos minutos y vuelve a ejecutar el comando.

    3. Una vez que el controlPlaneManagement.state esté Active en el estado de la función del clúster, reinicia los Pods.

Abandona el uso de objetos binarios no estándares en Sidecar

En esta sección, se sugieren formas de hacer que tus implementaciones sean compatibles con la imagen de proxy de Envoy sin distribución.

Imágenes de sidecar de proxy de Envoy sin distribución

Cloud Service Mesh usa dos tipos de imágenes de proxy de Envoy de sidecar según la configuración del plano de control: la imagen de proxy default (que contiene varios objetos binarios de depuración) y la imagen de proxy distroless.

Para los clústeres con el plano de control administrado de TRAFFIC_DIRECTOR, haz lo siguiente:

  • Clústeres incorporados directamente: Usa imágenes de distroless de forma predeterminada.
  • Clústeres migrados desde CSM-ISTIOD: Usa imágenes de default de forma predeterminada. Puedes habilitar de forma explícita las imágenes de distroless para mejorar tu postura de seguridad.

Para habilitar las imágenes de distroless en un clúster migrado desde CSM-ISTIOD, puedes configurarlo de forma global con defaultConfig.image.imageType: distroless en tu MeshConfig o por carga de trabajo con la anotación de pod sidecar.istio.io/proxyImageType: distroless.

Las imágenes base sin distribución son imágenes de contenedor mínimas que priorizan la seguridad y la optimización de recursos, ya que solo incluyen componentes esenciales. La superficie de ataque se reduce para ayudar a prevenir vulnerabilidades. Para obtener más información, consulta la documentación sobre la imagen de proxy sin distribución.

Compatibilidad binaria

Como práctica recomendada, debes restringir el contenido de un entorno de ejecución de un contenedor solo a los paquetes necesarios. Este enfoque mejora la seguridad y la relación entre las señales y el ruido de los analizadores de vulnerabilidades y riesgos comunes (CVE). La imagen de archivo de complemento sin distribución tiene un conjunto mínimo de dependencias, sin todos los ejecutables, las bibliotecas y las herramientas de depuración no esenciales. Por lo tanto, no es posible ejecutar un comando de shell ni usar curl, ping ni otras utilidades de depuración, como kubectl exec, dentro del contenedor.

Haz que los clústeres sean compatibles con las imágenes sin distribución

  • Quita las referencias a cualquier objeto binario no compatible (como bash o curl) de tu configuración. En particular, dentro de los sondeos de preparación, inicio y funcionamiento, y los hooks de PostStart y PreStop del ciclo de vida dentro de los contenedores istio-proxy, istio-init o istio-validation.
  • Considera alternativas como holdApplicationUntilProxyStarts para ciertos casos de uso.
  • Para la depuración, puedes usar contenedores efímeros para conectarte a un Pod de carga de trabajo en ejecución. Luego, puedes inspeccionarlo y ejecutar comandos personalizados. Para ver un ejemplo, consulta Recopila registros de {service_mesh_name}.

Si no encuentras una solución para tu caso de uso específico, comunícate con el equipo de asistencia de Google Cloud en Obtén asistencia.

Migra a la puerta de enlace de entrada de Istio

En esta sección, se muestra cómo migrar a la puerta de enlace de entrada de Istio. Existen dos métodos para migrar a la puerta de enlace de entrada de Istio:

  1. Migración por fases con división del tráfico

    Este método prioriza minimizar la interrupción en la que enviarás tráfico de forma incremental a la nueva puerta de enlace de Istio, lo que te permitirá supervisar su rendimiento en un pequeño porcentaje de solicitudes y revertirlo rápidamente si es necesario. Ten en cuenta que configurar la división del tráfico de la capa 7 puede ser difícil para algunas aplicaciones, por lo que debes administrar ambos sistemas de puerta de enlace de forma simultánea durante la transición. Consulta Migración por fases con división del tráfico para conocer los pasos.

  2. Migración directa

    Este método implica volver a enrutar de forma simultánea todo el tráfico a la nueva puerta de enlace de Istio una vez que hayas realizado las pruebas de forma exhaustiva. La ventaja de este enfoque es la separación completa de la infraestructura de la puerta de enlace anterior, lo que permite una configuración adaptable de la puerta de enlace nueva sin las restricciones de la configuración existente. Sin embargo, existe un mayor riesgo de tiempo de inactividad en caso de que surjan problemas inesperados con la puerta de enlace nueva durante la transición. Consulta Migración directa para conocer los pasos.

En los siguientes ejemplos de migración, se supone que tienes un servicio HTTP (httpbin) que se ejecuta en el espacio de nombres de la aplicación (predeterminado) y que se expone de forma externa con la API de Gateway de Kubernetes. Los parámetros de configuración relevantes son los siguientes:

  • Puerta de enlace: k8-api-gateway (en el espacio de nombres istio-ingress): Se configuró para escuchar el tráfico HTTP en el puerto 80 para cualquier nombre de host que termine con .example.com.
  • HTTPRoute: httpbin-route (en el espacio de nombres default): dirige cualquier solicitud HTTP con el nombre de host httpbin.example.com y una ruta de acceso que comience con /get al servicio httpbin dentro del espacio de nombres default.
  • Se puede acceder a la aplicación httpbin con la IP externa 34.57.246.68.

Diagrama de la puerta de enlace básica

Migración por fases con división del tráfico

Aprovisiona una nueva puerta de enlace de entrada de Istio

  1. Implementa una nueva puerta de enlace de entrada siguiendo los pasos de la sección Implementa una puerta de enlace de muestra y personaliza las configuraciones de muestra según tus requisitos. Las muestras en el repositorio anthos-service-mesh están diseñadas para implementar un servicio loadBalancer istio-ingressgateway y los Pods ingress-gateway correspondientes.

    Ejemplo de recurso de puerta de enlace (istio-ingressgateway.yaml)

     apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

  2. Aplica la configuración de puerta de enlace para administrar el tráfico:

    kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE

    Asegúrate de que el campo "spec.selector" de tu recurso Gateway coincida con las etiquetas de tus Pods de ingress-gateway. Por ejemplo, si los Pods de ingress-gateway tienen la etiqueta istio=ingressgateway, la configuración de la puerta de enlace también debe seleccionar esta etiqueta istio=ingressgateway.

Configura el enrutamiento inicial para la nueva puerta de enlace

  1. Define las reglas de enrutamiento iniciales para tu aplicación con un VirtualService de Istio.

    Ejemplo de VirtualService (my-app-vs-new.yaml):

    apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

  2. Aplica el VirtualService:

    kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

Acceder al servicio de backend (httpbin) a través de la puerta de enlace de entrada de Istio recién implementada

  1. Establece la variable de entorno Ingress Host en la dirección IP externa asociada con el balanceador de cargas istio-ingressgateway implementado recientemente:

    export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

  2. Verifica que se pueda acceder a la aplicación (httpbin) con la nueva puerta de enlace:

    curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"

    El resultado es similar al siguiente:

    HTTP/1.1 200 OK

Flujo de solicitud con la nueva puerta de enlace de entrada de Istio

Modifica el Ingress existente para la división del tráfico

Después de confirmar que la configuración de la nueva puerta de enlace (p. ej., istio-api-gateway) se realizó correctamente, puedes comenzar a enrutar una parte de tu tráfico a través de ella. Para ello, actualiza tu HTTPRoute actual para dirigir un pequeño porcentaje del tráfico a la nueva puerta de enlace, mientras que la mayor parte sigue usando la puerta de enlace existente (k8-api-gateway).

  1. Abre el recurso HTTPRoute para editarlo:

    kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

  2. Agrega una nueva referencia de backend que apunte al servicio de balanceador de cargas de la nueva puerta de enlace de Ingress con un peso inicial del 10% y actualiza el peso del backend de la puerta de enlace anterior.

    apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: MY_APP_NAMESPACE  # your application's namespace
spec:
  parentRefs:
  - name: k8-api-gateway
    namespace: istio-ingress
  hostnames: ["httpbin.example.com"]
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /get
    backendRefs:
    - name: httpbin
      port: 8000
      weight: 90
    - name: istio-ingressgateway # Newly deployed load balancer service
      namespace: GATEWAY_NAMESPACE
      port: 80
      weight: 10

  3. Otorga permiso para hacer referencia entre espacios de nombres con ReferenceGrant.

    Para permitir que tu HTTPRoute en el espacio de nombres de la aplicación (predeterminado) acceda al servicio loadbalancer en el espacio de nombres de la puerta de enlace (istio-ingress), es posible que debas crear un otorgamiento de referencia. Este recurso funciona como un control de seguridad, ya que define de forma explícita qué referencias entre espacios de nombres se permiten.

    En el siguiente istio-ingress-grant.yaml, se describe un otorgamiento de referencia de ejemplo:

    apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: istio-ingressgateway-grant
  namespace: istio-ingress # Namespace of the referenced resource
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: MY_APP_NAMESPACE # Namespace of the referencing resource
  to:
  - group: ""               # Core Kubernetes API group for Services
    kind: Service
    name: istio-ingressgateway # Loadbalancer Service of the new ingress gateway

  4. Aplica el otorgamiento de referencia:

    kubectl apply -f istio-ingress-grant.yaml -n GATEWAY_NAMESPACE

  5. Verifica las solicitudes a la dirección IP externa existente (p. ej., 34.57.246.68) no fallen. En el siguiente check-traffic-flow.sh, se describe una secuencia de comandos para verificar los errores de solicitud:

    # Update the following values based on your application setup
external_ip="34.57.246.68" # Replace with existing external IP
url="http://$external_ip/get"
host_name="httpbin.example.com"

# Counter for successful requests
success_count=0

# Loop 50 times
for i in {1..50}; do
  # Perform the curl request and capture the status code
  status_code=$(curl -s -HHost:"$host_name" -o /dev/null -w "%{http_code}" "$url")
  # Check if the request was successful (status code 200)
  if [ "$status_code" -eq 200 ]; then
    ((success_count++))  # Increment the success counter
  else
    echo "Request $i: Failed with status code $status_code"
  fi
done

# After the loop, check if all requests were successful
if [ "$success_count" -eq 50 ]; then
  echo "All 50 requests were successful!"
else
  echo "Some requests failed.  Successful requests: $success_count"
fi

  6. Ejecuta la secuencia de comandos para confirmar que no falle ninguna solicitud, sin importar la ruta del tráfico:

    chmod +x check-traffic-flow.sh
./check-traffic-flow.sh

Flujo de solicitudes con división del tráfico entre la puerta de enlace existente y la nueva puerta de enlace de entrada de Istio

Aumenta lentamente el porcentaje de tráfico

Si no se observan fallas en las solicitudes para la dirección IP externa existente (por ejemplo, 34.57.246.68), cambia de forma gradual más tráfico a la nueva puerta de enlace de entrada de Istio ajustando los pesos del backend en tu HTTPRoute. Aumenta el peso de istio-ingressgateway y disminuye el peso de la puerta de enlace anterior en incrementos pequeños, como 10%, 20%, etcétera.

Usa el siguiente comando para actualizar tu HTTPRoute existente:

kubectl edit httproute httpbin-route -n MY_APP_NAMESPACE

Migración completa del tráfico y eliminación de la puerta de enlace anterior

  1. Cuando la nueva puerta de enlace de entrada de Istio demuestre un rendimiento estable y un manejo correcto de las solicitudes, cambia todo el tráfico a ella. Actualiza tu HTTPRoute para establecer el peso del backend de la puerta de enlace anterior en 0 y el de la nueva en 100.

  2. Una vez que el tráfico se enrute por completo a la nueva puerta de enlace, actualiza los registros DNS externos para el nombre de host de tu aplicación (por ejemplo, httpbin.example.com) para que apunten a la dirección IP externa del servicio del balanceador de cargas creado en Aprovisiona una nueva puerta de enlace de entrada de Istio.

  3. Por último, borra la puerta de enlace anterior y sus recursos asociados:

    kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

Migración directa

Aprovisiona una nueva puerta de enlace de entrada de Istio

  1. Implementa una nueva puerta de enlace de entrada siguiendo los pasos de la sección Implementa una puerta de enlace de muestra y personaliza las configuraciones de muestra según tus requisitos. Las muestras en el repositorio anthos-service-mesh están diseñadas para implementar un servicio loadBalancer istio-ingressgateway y los Pods ingress-gateway correspondientes.

    Ejemplo de recurso de puerta de enlace (istio-ingressgateway.yaml)

     apiVersion: networking.istio.io/v1beta1
 kind: Gateway
 metadata:
   name: istio-api-gateway
   namespace: GATEWAY_NAMESPACE
 spec:
   selector:
     istio: ingressgateway  # The selector should match the ingress-gateway pod labels.
   servers:
   - port:
       number: 80
       name: http
       protocol: HTTP
     hosts:   # or specific hostnames if needed
     - "httpbin.example.com"

  2. Aplica la configuración de puerta de enlace para administrar el tráfico:

    kubectl apply -f istio-ingressgateway.yaml -n GATEWAY_NAMESPACE

    Asegúrate de que el campo "spec.selector" de tu recurso Gateway coincida con las etiquetas de tus Pods de ingress-gateway. Por ejemplo, si los Pods de ingress-gateway tienen la etiqueta istio=ingressgateway, la configuración de la puerta de enlace también debe seleccionar esta etiqueta istio=ingressgateway.

Configura el enrutamiento inicial para la nueva puerta de enlace

  1. Define las reglas de enrutamiento iniciales para tu aplicación con un VirtualService de Istio.

    Ejemplo de VirtualService (my-app-vs-new.yaml):

    apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-vs
  namespace: APPLICATION_NAMESPACE
spec:
    gateways:
    - istio-ingress/istio-api-gateway  # Replace with <gateway-namespace/gateway-name>
    hosts:
    - httpbin.example.com
    http:
    - match:
      - uri:
          prefix: /get
      route:
      - destination:
          host: httpbin
          port:
            number: 8000

  2. Aplica el VirtualService:

    kubectl apply -f my-app-vs-new.yaml -n MY_APP_NAMESPACE

Acceder al servicio de backend (httpbin) a través de la puerta de enlace de entrada de Istio recién implementada

  1. Establece la variable de entorno Ingress Host en la dirección IP externa asociada con el balanceador de cargas istio-ingressgateway implementado recientemente:

    export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')

  2. Verifica que se pueda acceder a la aplicación (httpbin) con la nueva puerta de enlace:

    curl -s -I -HHost:httpbin.example.com "http://$INGRESS_HOST/get"

    El resultado es similar al siguiente:

    HTTP/1.1 200 OK

Flujo de solicitud con la nueva puerta de enlace de entrada de Istio

Prueba y supervisa la nueva puerta de enlace

  1. Prueba todas las reglas de enrutamiento, valida la configuración de TLS, las políticas de seguridad y otras funciones. Realiza pruebas de carga para verificar que la nueva puerta de enlace pueda controlar el tráfico esperado.

  2. Una vez que la puerta de enlace nueva se haya probado por completo, actualiza los registros DNS externos para el nombre de host de tu aplicación (por ejemplo, httpbin.example.com) para que apunten a la dirección IP externa del servicio del balanceador de cargas creado en Aprovisiona una puerta de enlace de entrada de Istio nueva.

  3. Supervisa las métricas clave, como la tasa de éxito de las solicitudes, la latencia, las tasas de error y el uso de recursos de los Pods de tu aplicación para verificar la estabilidad con la nueva puerta de enlace de entrada de Istio. Una vez que sea estable, puedes borrar la puerta de enlace anterior y sus recursos asociados

    kubectl delete gateway OLD_GATEWAY -n GATEWAY_NAMESPACE
kubectl delete service OLD_GATEWAY_SERVICE -n GATEWAY_NAMESPACE

Consideraciones importantes: Asegúrate de que los certificados y las configuraciones de TLS estén configurados correctamente en la nueva puerta de enlace de entrada de Istio si tu aplicación requiere HTTPS. Consulta Configura la finalización de TLS en la puerta de enlace de entrada para obtener más detalles.

Corrige varios planos de control

Anteriormente, Cloud Service Mesh admitía la incorporación con asmcli (obsoleto), que no bloqueaba el aprovisionamiento de varios planos de control. Cloud Service Mesh ahora aplica la práctica recomendada de implementar solo un canal por clúster que coincida con el canal del clúster y no admite el uso de varios canales implementados en el mismo clúster.

Si deseas realizar implementaciones de versiones canary en versiones nuevas de la malla en el canal rápido antes de que estén disponibles en el canal estable o regular, debes usar dos clústeres diferentes, en los que cada uno tenga un canal independiente. Ten en cuenta que los canales se controlan con el canal del clúster de GKE y que la malla no tiene un canal independiente asociado.

Para verificar si tienes varios canales, busca la condición de estado UNSUPPORTED_MULTIPLE_CONTROL_PLANES en tu membresía. Si no aparece esta advertencia, no te verás afectado y puedes omitir la lectura de esta sección.

  1. Ejecuta el siguiente comando para verificar si tu clúster tiene varios canales del plano de control:

    gcloud container fleet mesh describe

    El resultado es similar al siguiente:

    ...
projects/.../locations/global/memberships/my-membership:
    servicemesh:
      conditions:
      - code: UNSUPPORTED_MULTIPLE_CONTROL_PLANES
        details: 'Using multiple control planes is not supported. Please remove a control plane from your cluster.'
        documentationLink: https://cloud.google.com/service-mesh/v1.30/docs/migrate/modernization-configuration-updates#multiple_control_planes
        severity: WARNING
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed-stable'
        implementation: ISTIOD
        state: ACTIVE
...

  2. Si apareció la condición UNSUPPORTED_MULTIPLE_CONTROL_PLANES, determina qué canales existen para tu clúster:

    kubectl get controlplanerevisions -n istio-system

    El resultado es similar al siguiente:

    NAME                 RECONCILED   STALLED   AGE
asm-managed-stable   True         False     97d
asm-managed          True         False     97d
asm-managed-rapid    True         False     97d

    En este ejemplo, se aprovisionaron los tres canales:

    • asm-managed-stable -> STABLE
    • asm-managed -> REGULAR
    • asm-managed-rapid -> RAPID

    Si solo aparece 1 resultado, significa que solo se aprovisionó un canal en tu clúster y puedes omitir el resto de estos pasos.

    Si aparecen 2 o más resultados, sigue el resto de estos pasos para quitar los canales excedentes.

Consolida las cargas de trabajo en un solo canal

Antes de quitar canales adicionales, debes asegurarte de que tus cargas de trabajo solo usen un canal.

  1. Busca todas las etiquetas que usas en tu clúster:

    kubectl get namespaces -l istio.io/rev=RELEASE_CHANNEL

    Según el resultado del comando anterior, reemplaza RELEASE_CHANNEL por asm-managed-stable, asm-managed o asm-managed-rapid. Repite este paso para cada canal aprovisionado.

    El resultado es similar al siguiente:

    NAME      STATUS   AGE
default   Active   110d

    Ten en cuenta que, en este ejemplo, el espacio de nombres predeterminado se inserta con el canal regular.

    Si todas tus cargas de trabajo ya usan el mismo canal, puedes omitir este paso y quitar los canales adicionales. De lo contrario, continúa en esta sección.

  2. Cambia las etiquetas para que solo se use un canal:

    • En algunos casos, los Pods también se pueden insertar directamente con la etiqueta sidecar.istio.io/inject. Asegúrate de revisarlos también para ese uso.
    • Puedes ignorar las etiquetas de istio-injection=enabled en este paso. Los espacios de nombres con esa etiqueta cambiarán automáticamente para que coincidan con el canal que quede en el clúster.
    • Cuando selecciones un canal para conservar, intenta seleccionar el mismo que el de tu clúster de GKE. Si este canal no existe, selecciona cualquiera de los canales activos.
    • No importa el canal que selecciones. El canal del clúster de GKE determina qué versión de la malla obtienes, no el canal de la malla.
    • Verifica la configuración de meshconfig entre los canales activos que estén en uso para asegurarte de que no haya diferencias entre ellos. Cada canal usa un ConfigMap independiente para la configuración, por lo que consolidar dos canales en uno debería garantizar un comportamiento coherente entre ambos canales. kubectl get configmap istio-asm-managed{-rapid | -stable} -n istio-system -o yaml
    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite

    Reemplaza NAMESPACE por el nombre de tu espacio de nombres.

    La práctica recomendada es usar istio-injection=enabled. Sin embargo, si no quieres usar esa etiqueta, también puedes usar istio.io/rev=RELEASE_CHANNEL.

    Una vez que hayas cambiado la etiqueta de un espacio de nombres o un Pod, debes reiniciar todas las cargas de trabajo para que se inserten en el plano de control correcto.

Quita los canales adicionales

Una vez que hayas verificado que todas tus cargas de trabajo se ejecutan en un solo canal, puedes quitar los canales adicionales que no se usen. Si se aprovisionaron los tres canales de versiones, recuerda ejecutar los siguientes comandos para cada canal.

  1. Borra el recurso ControlPlaneRevision adicional:

    kubectl delete controlplanerevision RELEASE_CHANNEL -n istio-system

    Reemplaza RELEASE_CHANNEL por asm-managed-stable, asm-managed o asm-managed-rapid.

  2. Borra MutatingWebhookConfiguration:

    kubectl delete mutatingwebhookconfiguration istiod-RELEASE_CHANNEL

  3. Borra el ConfigMap meshconfig:

    kubectl delete configmap istio-RELEASE_CHANNEL

Habilita la administración automática

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

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

    Reemplaza lo siguiente:

    • MEMBERSHIP_NAME es el nombre de membresía que aparece cuando verificaste que tu clúster estaba registrado en la flota.
    • PROJECT_ID es el ID del proyecto de tu proyecto.
    • MEMBERSHIP_LOCATION es la ubicación de tu membresía (una región o global). Puedes verificar la ubicación de tu membresía con gcloud container fleet memberships list --project PROJECT_ID.

  2. Verifica que la administración automática esté habilitada:

    gcloud container fleet mesh describe

    El resultado es similar al siguiente:

    ...
membershipSpecs:
  projects/.../locations/us-central1/memberships/my-member:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/.../locations/us-central1/memberships/my-member:
    servicemesh:
      conditions:
      - code: VPCSC_GA_SUPPORTED
        details: This control plane supports VPC-SC GA.
        documentationLink: http://cloud.google.com/service-mesh/v1.30/docs/managed/vpc-sc
        severity: INFO
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        implementation: TRAFFIC_DIRECTOR
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: |-
        Revision ready for use: asm-managed.
        All Canonical Services have been reconciled successfully.
...

Moderniza las configuraciones del compresor EnvoyFilter

Si usas el filtro envoy.extensions.filters.http.compressor.v3.Compressor, varios campos de nivel superior dejaron de estar disponibles en Envoy y se movieron a response_direction_config.common_config y request_direction_config.common_config.

Para obtener información sobre cómo actualizar tus recursos EnvoyFilter al formato moderno y compatible, consulta la guía Moderniza las configuraciones del compresor EnvoyFilter.

Habilita una política de la organización obligatoria

Cloud Service Mesh requiere que se habiliten políticas específicas para funcionar correctamente.

Políticas obligatorias

compute.disableInternetNetworkEndpointGroup

Cloud Service Mesh requiere la capacidad de crear grupos de extremos de red (NEG) de Internet. Estos NEG son componentes esenciales para enrutar el tráfico a servicios fuera de Google Cloud.

La restricción constraints/compute.disableInternetNetworkEndpointGroup puede impedir la creación de estos NEG de Internet necesarios.

Si esta política de la organización se aplica en tu proyecto, carpeta u organización, impedirá que Cloud Service Mesh funcione correctamente con el plano de control de Traffic Director. Esto impedirá la migración a esta configuración de Cloud Service Mesh o su funcionamiento correcto.

Si Enforced se establece en true, se inhabilita la creación de NEG de Internet.

¿Cómo puedo saber si me afecta?

Puedes verificar la política vigente para tu proyecto con la consola de Google Cloud o Google Cloud CLI. Las instrucciones para ver las políticas de la organización se encuentran en la sección Visualiza las políticas de la organización de la documentación oficial.

Por ejemplo, puedes usar este comando de Google Cloud CLI:

gcloud resource-manager org-policies describe constraints/compute.disableInternetNetworkEndpointGroup --project YOUR_PROJECT_ID --effective

Si la política muestra el valor enforced: true, significa que te afecta.

constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy:
  enforced: true

Si la política muestra un valor diferente o está vacía, no te verás afectado.

constraint: constraints/compute.disableInternetNetworkEndpointGroup
booleanPolicy: {}

Cómo resolver el problema

Si se aplica la política, deberás inhabilitar esta restricción (establecida en false) a nivel de la organización, la carpeta o el proyecto.

Puedes encontrar instrucciones detalladas para modificar las políticas de la organización, incluidas las restricciones booleanas como esta, en la guía Crea y administra políticas de la organización. Por lo general, necesitarás el rol de roles/orgpolicy.policyAdmin para realizar estos cambios.

Permisos de VPC compartida

Cuando usas Cloud Service Mesh administrado con una VPC compartida en la que tus clústeres residen en un proyecto de servicio y la red de VPC está en un proyecto host, se requieren permisos adicionales para el agente de servicio de Cloud Service Mesh en el proyecto de la flota.

Como parte de la migración a un plano de control de TRAFFIC_DIRECTOR, Cloud Service Mesh requiere permisos para administrar las reglas de firewall en el proyecto host y garantizar que las verificaciones de estado y la funcionalidad de la red sean correctas. Esto no era necesario para el plano de control de ISTIOD anterior.

¿Cómo puedo saber si me afecta?

Te verás afectado en los siguientes casos:

  1. Tus clústeres de GKE están en un proyecto de servicio.
  2. Estos clústeres usan una red de VPC compartida alojada en un proyecto diferente (el proyecto host de VPC).
  3. El agente de servicio de Cloud Service Mesh del proyecto de flota no tiene permiso para administrar las reglas de firewall en el proyecto host de la VPC.

Es posible que veas un mensaje de advertencia con el código SHARED_VPC_MISSING_PERMISSIONS en el estado de la función de la flota. Para obtener más detalles sobre cómo comprender y resolver este problema, incluidas las opciones administradas por el sistema y por el usuario, consulta Información sobre las verificaciones de estado.

Falta la configuración del plano de control

Las prácticas recomendadas de Cloud Service Mesh para administrar una malla de servicios usan la API de Fleet de Google Kubernetes Engine para establecer el campo Management en AUTOMATIC. Esto proporciona una administración completamente automática de muchas funciones de la malla, como los webhooks y el plano de control. Además, configura el clúster para que reciba automáticamente actualizaciones y funciones nuevas a medida que se lanzan. Algunos métodos de instalación heredados no configuraron Cloud Service Mesh de esta manera, y debes seguir algunos pasos manuales para aplicarlos.

¿Cómo puedo saber si me afecta?

Verifica si tienes un ControlPlaneRevision en tu clúster:

kubectl get controlplanerevisions -n istio-system

Si ya tienes un ControlPlaneRevision en tu clúster, esta guía no se aplica a tu caso. Si no tienes un ControlPlaneRevision, usa esta guía para modernizar tus clústeres.

Si recibes la advertencia MISSING_CONTROL_PLANE_CONFIG y no quieres usar Cloud Service Mesh, inhabilita Cloud Service Mesh.

Pasos para la modernización

Sigue estos pasos para determinar qué se debe hacer para que tu configuración se alinee con los estándares actuales.

gcloud container fleet mesh describe --project PROJECT_ID

Sigue estos pasos según el resultado:

Salida Paso que se debe realizar
API [gkehub.googleapis.com] not enabled on project [my-project]. Would you like to enable and retry (this will take a few minutes)? (y/N)? Responde y y vuelve a intentarlo.
ERROR: (gcloud.container.fleet.mesh.describe) Service Mesh Feature for project [my-project] is not enabled Continúa con el paso 1. Habilita la función de malla.
... resourceState: state: ACTIVE ... Continúa con el paso 2. Registra tu clúster en la flota.

1. Habilita la función de malla

Para habilitar la función de malla, puedes usar el siguiente comando. Esto permite que Cloud Service Mesh se ejecute en tu proyecto. Para obtener más detalles y conocer los posibles efectos secundarios, consulta Aprovisiona malla de servicios.

gcloud container fleet mesh enable --project PROJECT_ID

Después de habilitar la función de malla, continúa con el paso 2. Registra tu clúster en la flota.

2. Registra tu clúster en la flota

Verifica si tu clúster ya está registrado en la flota:

gcloud container fleet memberships list --project PROJECT_ID

Si tu clúster no aparece en la lista, sigue estas instrucciones para registrarlo: Registra un clúster en la flota.

Registrar un clúster en tu flota permitirá que ese clúster administre funciones, como Cloud Service Mesh, a través de la flota.

3. Determina tu canal de malla

Cloud Service Mesh depende del canal de Google Kubernetes Engine de tu clúster, en lugar de un canal de malla independiente. En el pasado, Cloud Service Mesh admitía la elección de uno o más canales de malla (diferentes del canal del clúster de Google Kubernetes Engine). Es posible que aún tengas referencias a estos canales en tu configuración de malla.

Primero, determina qué canales usas. Si usas varios canales, sigue las instrucciones que se indican en Corrige varios planos de control para reducir el uso a un solo canal.

Para determinar qué canal de malla usas, verifica las etiquetas en tus espacios de nombres. Ten en cuenta que también es posible que debas verificar las cargas de trabajo si agregaste etiquetas de inserción específicamente en las cargas de trabajo. Con el siguiente comando, se verifican todas las cargas de trabajo del clúster y se filtra el resultado para mostrar los planos de control y las etiquetas de inserción que se usan en esas cargas de trabajo.

kubectl get namespaces,pods,deployments,statefulsets,daemonsets --all-namespaces --show-labels | grep -E "istio.io/rev|istio-injection"

Si creaste manualmente etiquetas o webhooks personalizados, también debes verificarlos.

El resultado es similar al siguiente:

namespace/default                                 Active   153d   istio-injection=enabled,istio.io/rev=asm-managed,kubernetes.io/metadata.name=default
namespace/payments                                Active   42d    istio.io/rev=asm-managed-stable,kubernetes.io/metadata.name=payments
default    pod/frontend-847f569874-v9kjz          2/2      Running  0   2m     app=frontend,istio.io/rev=asm-managed,pod-template-hash=847f569874
payments   pod/checkout-0                         2/2      Running  0   5d     app=checkout,istio.io/rev=asm-managed-stable,controller-revision-hash=5c68b9487
default    deployment.apps/frontend               1/1      1        1   153d   app=frontend,istio.io/rev=asm-managed
payments   statefulset.apps/checkout              1/1      1        1   42d    app=checkout,istio.io/rev=asm-managed-stable

Toma nota de los valores presentes para istio.io/rev={channel}. Los nombres coinciden con los canales de esta manera. Si hay varios canales en uso, sigue las instrucciones que se indican en Corrige varios planos de control para reducir a un solo canal:

Valor Canal
asm-managed-stable Estable
asm-managed Normal
asm-managed-rapid Rápido

Si tu canal de malla coincide con el canal de tu clúster de Google Kubernetes Engine, ve al paso 5.

4. Crea un recurso ControlPlaneRevision para tu canal de malla

Si tu canal de malla coincide con el canal de tu clúster de Google Kubernetes Engine, puedes omitir este paso. Si habilitas la administración automática del plano de control, se creará automáticamente este recurso ControlPlaneRevision si tu canal coincide con el del clúster.

Crea un recurso ControlPlaneRevision para el canal de malla que usas:

Estable

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed-stable
  namespace: istio-system
spec:
  type: managed_service
  channel: stable
EOF

Normal

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed
  namespace: istio-system
spec:
  type: managed_service
  channel: regular
EOF

Rápido

kubectl create ns istio-system
cat <<EOF | kubectl apply -f -
apiVersion: mesh.cloud.google.com/v1beta1
kind: ControlPlaneRevision
metadata:
  name: asm-managed-rapid
  namespace: istio-system
spec:
  type: managed_service
  channel: rapid
EOF

5. Habilita la administración automática

Para inhabilitar el descubrimiento de extremos de varios clústeres, sigue las instrucciones de "Inhabilitar" en API declarativa de descubrimiento de extremos antes de habilitar la administración automática del plano de control.

Para inhabilitar el plano de datos administrado, sigue las instrucciones que se indican en Inhabilita el plano de datos administrado.

Para habilitar la administración automática, ejecuta el siguiente comando. Esto permitirá que Cloud Service Mesh administrado por la flota administre la configuración del plano de control de tu clúster.

gcloud container fleet mesh update --management automatic --memberships MY_CLUSTER_MEMBERSHIP --project PROJECT_ID

Reemplaza MY_CLUSTER_MEMBERSHIP por el nombre de la membresía de tu clúster.

6. Verifique la instalación

Ejecuta el comando siguiente:

gcloud container fleet mesh describe --project PROJECT_ID

El resultado es similar al siguiente:

createTime: '2025-02-24T22:10:10.826263363Z'
etag: XjjRZB3-ZsueoaKihEBUupYhMDUjvoSyUHTVD2YgR6k
membershipSpecs:
  projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
    mesh:
      management: MANAGEMENT_AUTOMATIC # See item 1 below
membershipStates:
  projects/1234567890/locations/us-central1/memberships/my-cluster-membership:
    servicemesh:
      conditions: [] # See item 2 below
      controlPlaneManagement: # See item 3 below
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed'
        implementation: TRAFFIC_DIRECTOR
        state: ACTIVE
      dataPlaneManagement: # See item 4 below
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: |-
        Revision ready for use: asm-managed.
        All Canonical Services have been reconciled successfully.
      updateTime: '2025-06-17T23:39:05.267540058Z'
name: projects/my-project/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
spec: {}
updateTime: '2025-02-25T04:12:16.280672401Z'
  1. En membershipSpecs, cada membresía de tu flota tiene una especificación independiente. Asegúrate de que cada miembro tenga la administración configurada correctamente en MANAGEMENT_AUTOMATIC.
  2. Cada membresía tiene una lista de condiciones de estado asociadas. Asegúrate de que no haya errores ni advertencias aquí y sigue los vínculos a la documentación que se proporcionan para resolver cualquier problema.
  3. controlPlaneManagement contiene el estado de tu plano de control. Asegúrate de que el plano de control esté en el estado ACTIVE.
  4. dataPlaneManagement contiene el estado del plano de datos. Se recomienda habilitar esta opción.