Plano de control gestionado para clientes actuales

Este documento está dirigido a los clientes de Anthos Service Mesh que sigan usando el plano de control gestionado o el plano de control en el clúster. En este documento se habla de la implementación del plano de control y de la posible migración del plano de control.

Si ya eres cliente de Traffic Director o eres un cliente nuevo, no es necesario que leas este documento.

Información general sobre el plano de control

En las mallas de servicios, el plano de control proporciona gestión del tráfico, gestión de proxies cuando se usa el proxy Envoy y otras funciones de red.

Anthos Service Mesh ofrecía dos planos de control: un plano de control gestionado y un plano de control en el clúster. Solo se usan proxies de Envoy como plano de datos.

Nuevo plano de control gestionado

El nuevo plano de control gestionado se llama Traffic Director (TD). ¿Qué implica el nuevo plano de control para ti?

Uno de los cambios más significativos del producto Anthos Service Mesh a Cloud Service Mesh es el cambio a un plano de control global multiinquilino.

El plano de control gestionado que se usa en Anthos Service Mesh está dedicado a un solo clúster. Aunque las APIs (CRDs de Istio) que se usan en GKE son las mismas y la configuración de xDS que se envía a los sidecars es compatible sin diferencias de comportamiento, las diferencias del plano de control dan lugar a algunas características que son visibles para ti, el usuario final.

Tiempo de respuesta de los cambios de configuración. Las implementaciones de servicios nuevos o los cambios en las políticas de servicio tardan un poco más con el nuevo plano de control.
- El flujo de configuración realiza una confirmación de configuración de dos fases por motivos de fiabilidad. En la primera pasada, se realizan validaciones para comprobar si la configuración tiene el formato correcto. En la fase posterior, la configuración se propaga de forma global a los despliegues de tu servicio. Para habilitar el uso de Google Cloud servicios, como el balanceo de carga global entre zonas o regiones, la comprobación del estado centralizada, el autoescalado basado en el tráfico y la limitación de la frecuencia gestionada, la configuración se propaga a estos sistemas y se valida de forma independiente para comprobar que es correcta. La configuración también se almacena internamente de forma que permite a los ingenieros de fiabilidad de sitios de Google realizar operaciones de productos de forma fiable y eficiente durante cualquier emergencia de producción.
- Estas operaciones ofrecen una mayor fiabilidad, pero dan como resultado un envío de configuración más lento que la latencia observada por los usuarios actuales de Anthos Service Mesh.
- La latencia de cualquier Pod nuevo para obtener la configuración existente es ligeramente mejor con el nuevo plano de control. El envío lento de la configuración se realiza la primera vez que se propaga un servicio nuevo o cuando se envían políticas nuevas para el servicio. Las latencias de propagación de los endpoints son funcionalmente similares.
Velocidad de escalado de eventos y otros cambios en los endpoints. Estos se gestionan al menos con la misma rapidez con el nuevo plano de control. Estos eventos incluyen el inicio o la detención de nuevos pods debido al autoescalado horizontal de pods, así como el reinicio de pods con nuevas direcciones IP porque se han movido a otro nodo del clúster.
Escalar el número de endpoints. Con el nuevo plano de control global, los endpoints de la malla se envían directamente desde cada clúster al plano de control de todos los clústeres de la malla. Este es un enfoque más sencillo, rápido y escalable que el que usa el plano de control gestionado anterior. En el modelo de plano de control gestionado anterior (plano de control dedicado), cada Istiod debe comunicarse con todos los demás clústeres de la malla para determinar los endpoints disponibles en cada uno de ellos. Con el plano de control global, los endpoints se propagan directamente al plano de control global. Esto se traduce en una mayor fiabilidad y rendimiento en las mallas con un gran número de endpoints, lo que permite que las mallas se adapten a un mayor número de endpoints.

¿Cómo te afecta el nuevo plano de control?

La forma en que te afecta el nuevo plano de control depende de las APIs y del plano de control que utilices.

Si eres usuario de Traffic Director, tu plano de control seguirá siendo el mismo. No es necesario que leas el resto de esta guía. La documentación de tu implementación de Cloud Service Mesh se encuentra en Configurar con APIs deGoogle Cloud .
Si eres usuario de Anthos Service Mesh, los pasos siguientes para el plano de control de tu implementación dependen de si usas el plano de control gestionado o el plano de control en el clúster.
- Si utilizas el plano de control gestionado, con algunas excepciones, tus flotas se migrarán al nuevo plano de control, al que se hace referencia en Cloud Service Mesh como plano de control gestionado (implementación de Traffic Director o TD). Consulta la sección Migración del plano de control de las mallas y las flotas actuales. Si usas una función que no es compatible con la implementación del plano de control de Traffic Director, seguirás usando temporalmente el plano de control anterior. Te recomendamos que sigas leyendo esta guía.
- Si usas el plano de control en clústeres, este no cambia. No es necesario que lea el resto de esta guía.
- Si no tienes una Google Cloud organización y usas el plano de control gestionado en un proyecto sin organización, recibirás el plano de control de TD.
Si eres cliente de Anthos Service Mesh y estás creando flotas, recibirás la implementación del plano de control de Traffic Director. Deberías seguir leyendo esta guía.
- Se te notificará la fecha en la que las flotas nuevas reciban el plano de control de TD.

Migración del plano de control de mallas y flotas

A partir del 22 de julio del 2024, Google actualizará gradualmente los clústeres para que usen el plano de control gestionado con la implementación de TD. Recibirás una notificación antes de que actualicemos tus mallas.

Puedes consultar las funciones de los planos de control de Istiod y Traffic Director en la página que describe las funciones compatibles con las APIs de Istio (plano de control gestionado).

Deberías recibir una notificación de que se va a actualizar un clúster al menos dos semanas antes de la actualización. Las notificaciones están disponibles en las condiciones de estado de las funciones a nivel de clúster.

Usa el siguiente comando de Google Cloud CLI para comprobar la notificación:

gcloud container hub mesh describe --project=[PROJECT_ID]

Verá resultados similares a los siguientes:

membershipStates:
  projects/656460026795/locations/us-central1/memberships/cluster:
    servicemesh:
      conditions:
      - code: MODERNIZATION_SCHEDULED
        details: This cluster has been scheduled for modernization on or after (date ~ at least 2 weeks).
        documentationLink: 
        severity: INFO

Los clústeres del plano de control gestionado antiguos que se hayan incorporado mediante la API meshconfig.googleapis.com se registrarán automáticamente en la flota del proyecto del clúster con la API Membership gkehub.googleapis.com. Si tienes alguna automatización que anule el registro de un clúster, debes eliminarla antes de la migración o esta tendrá problemas. Para que el producto gestionado funcione correctamente, debe registrarse en una flota con la función de malla habilitada.

Ponte en contacto con el equipo de Asistencia si necesitas personalizar tu migración o si tienes alguna pregunta sobre si estás usando funciones no admitidas.

Durante la migración, de forma segura y controlada, se producen los siguientes cambios:

Para habilitar la comprobación del estado, se crea el snk daemonset en el espacio de nombres kube-system del clúster y se crea una regla de cortafuegos por clúster.
Para habilitar la ingestión de grupos de puntos finales de red (NEG), se añade la anotación cloud.google.com/neg a todos los servicios de Kubernetes.
En el clúster se crean Google Cloud recursos nuevos, como Mesh, Routes, servicios de backend y comprobaciones de estado.
Los pods gestionados por las implementaciones de Kubernetes se reinician para volver a conectarse al plano de control de Traffic Director.

Algunos de los nuevos recursos tienen un límite de cuota. Puedes consultar las cuotas y solicitar más si es necesario.

Comprobar la compatibilidad del plano de control

Consulta las diferencias entre las funciones admitidas de las implementaciones del plano de control gestionado para determinar si tu uso actual de Cloud Service Mesh requerirá cambios.

Plano de control de las nuevas mallas

A partir del 1 de julio del 2024, la mayoría de los usuarios actuales de la implementación del plano de control istiod gestionado empezarán a recibir el plano de control gestionado actualizado con la implementación disponible a nivel mundial de Google: el plano de control de Traffic Director (TD) en nuevos clústeres.

Los usuarios cuyo uso actual de Cloud Service Mesh gestionado con la implementación del plano de control istiod no sea compatible con la implementación de Traffic Director sin cambios seguirán usando la implementación istiod hasta el 8 de septiembre del 2024. Si este es el caso de tu organización, habrás recibido un anuncio de servicio.

Si incorporas una nueva flota a Cloud Service Mesh gestionado y esta flota no está en una Google Cloud organización o está en una nueva Google Cloud organización, obtendrás el nuevo plano de control gestionado con la implementación de Traffic Director a partir de la fecha de lanzamiento de Cloud Service Mesh.

Siguientes pasos

Si ya eres cliente de Anthos Service Mesh, encontrarás la documentación en la tabla de contenido de la izquierda, en Configurar la malla de servicios con las APIs de Istio.
Si ya eres cliente de Traffic Director, tu documentación se encuentra en Configurar una malla de servicios con APIs de Google Cloud .