Plano de control administrado para clientes continuos

Este documento es para ti si eres un cliente continuo de Anthos Service Mesh que usa el plano de control administrado o el plano de control en el clúster. En este documento, se analiza la implementación de tu plano de control y la posible migración de este.

Si eres cliente de Traffic Director o un cliente nuevo, no necesitas leer este documento.

Descripción general del plano de control

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

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

Nuevo plano de control administrado

El nuevo plano de control administrado se denomina implementación de Traffic Director (TD). ¿Qué significa 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 multiusuario.

El plano de control administrado que se usa en Anthos Service Mesh está dedicado a un solo clúster. Si bien las APIs (CRD de Istio) que se usan para 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 generan algunas características que tú, el usuario final, puedes ver.

Tiempo de respuesta del cambio de configuración Las implementaciones de servicios nuevas o los cambios en las políticas de servicio tardan un poco más con el nuevo plano de control.
- La canalización de configuración realiza una confirmación de configuración de dos pases con fines de confiabilidad. El primer pase realiza validaciones para verificar si la configuración está bien formada. En la fase posterior, se propaga la configuración de forma global a las implementaciones de tu servicio. Para habilitar el uso de los servicios de Google Cloud, como el balanceo de cargas global entre zonas o regiones, la verificación de estado centralizada, el ajuste de escala automático basado en el tráfico y el límite de frecuencia administrado, la configuración se propaga a estos sistemas y se valida de forma independiente para verificar su exactitud. La configuración también se almacena de forma interna de manera que la ingeniería de confiabilidad de sitios de Google pueda realizar operaciones de productos de forma confiable y eficiente durante emergencias de producción.
- Estas operaciones proporcionan una mejor confiabilidad, pero generan un envío de configuración más lento que la latencia que observan los usuarios actuales de Anthos Service Mesh.
- La latencia de cualquier Pod nuevo para recuperar la configuración existente se mide como ligeramente mejor con el nuevo plano de control. El envío lento de configuración es para la propagación por primera vez de cualquier servicio nuevo creado o de cualquier política nueva enviada para el servicio. Las latencias de propagación de extremos son funcionalmente similares.
Velocidad de los eventos de escalamiento y otros cambios en los extremos Estos se controlan al menos con la misma rapidez con el nuevo plano de control. Estos eventos incluyen Pods nuevos que se inician o detienen debido al ajuste de escala automático horizontal de Pods, y Pods que se reinician con direcciones IP nuevas porque se movieron a un nodo diferente en el clúster.
Escalamiento de la cantidad de extremos Con el nuevo plano de control global, los extremos 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 simple, más rápido y más escalable que el que usa el plano de control administrado anterior. En el modelo de plano de control administrado (plano de control dedicado) más antiguo, cada Istiod debe comunicarse con todos los demás clústeres de la malla para determinar los extremos disponibles en todos los demás clústeres. Con el plano de control global, los extremos se propagan directamente al plano de control global. Esto da como resultado una mejor confiabilidad y rendimiento en mallas con grandes cantidades de extremos y permite que las mallas se escalen a una mayor cantidad de extremos.

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

El efecto que tiene el nuevo plano de control depende de las APIs y el plano de control que uses.

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 para tu implementación de Cloud Service Mesh se encuentra en Configurar con las APIs de Google Cloud.
Si eres usuario de Anthos Service Mesh, los próximos pasos para el plano de control en tu implementación existente dependen de si usas el plano de control administrado o el plano de control en el clúster.
- Si usas el plano de control administrado, con algunas excepciones, tus flotas existentes se migrarán al nuevo plano de control, al que se hace referencia en Cloud Service Mesh como plano de control administrado (implementación de Traffic Director o TD). Lee la siguiente sección, Migración del plano de control para mallas y flotas existentes. Si estás usando una función que no es compatible con la implementación del plano de control de Traffic Director, permanecerás temporalmente en el plano de control anterior. Debes seguir leyendo esta guía.
- Si usas el plano de control en el clúster, este permanecerá igual. No es necesario que leas el resto de esta guía.
- Si no tienes una organización de Google Cloud y usas el plano de control administrado en un proyecto sin organización, recibirás el plano de control de TD.
Si eres cliente de Anthos Service Mesh y creas flotas nuevas, recibirás la implementación del plano de control de Traffic Director. Debes continuar leyendo esta guía.
- Recibirás una notificación sobre la fecha en la que las flotas nuevas recibirán el plano de control de TD.

Migración del plano de control para mallas y flotas existentes

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

Puedes revisar las capacidades de los planos de control de Istiod y Traffic Director en la página que describe las funciones admitidas con las APIs de Istio (plano de control administrado).

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

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

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

Deberías 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

Todos los clústeres de plano de control administrados heredados que se incorporaron con la API de meshconfig.googleapis.com se registrarán automáticamente en la flota del proyecto del clúster con la API de membresía de gkehub.googleapis.com. Si tienes alguna automatización que cancele el registro de un clúster, debes quitarla antes de la migración, de lo contrario, esta tendrá problemas. Para que el producto administrado funcione correctamente, debe estar registrado en una flota con la función de malla habilitada.

Comunícate con el equipo de asistencia si necesitas personalizar tu migración o si tienes preguntas sobre si estás usando funciones no compatibles.

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

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

Algunos de los recursos nuevos tienen una cuota limitada. Puedes ver las cuotas y solicitar más si es necesario.

Verifica la compatibilidad del plano de control

Revisa las diferencias en las funciones compatibles entre las implementaciones del plano de control administrado para determinar si tu uso actual de Cloud Service Mesh requerirá cambios.

Plano de control para mallas nuevas

A partir del 1 de julio de 2024, la mayoría de los usuarios existentes de la implementación del plano de control istiod administrado comenzarán a recibir el plano de control administrado actualizado con la implementación disponible a nivel mundial de Google: el plano de control de Traffic Director (TD) en flotas nuevas.

Los usuarios cuyo uso existente de Cloud Service Mesh administrado con la implementación del plano de control istiod no sea compatible con la implementación de Traffic Director sin cambios, seguirán recibiendo la implementación de istiod hasta el 8 de septiembre de 2024. Si esto se aplica a tu organización, significa que recibiste un anuncio del servicio.

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

¿Qué sigue?

Si eres un cliente continuo de Anthos Service Mesh, tu documentación se encuentra en el índice de la izquierda, en Configura la malla de servicios con las APIs de Istio.
Si eres un cliente continuo de Traffic Director, tu documentación se encuentra en Configura la malla de servicios con las APIs de Google Cloud.