Plano de control administrado para clientes continuos

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

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

Descripción general del plano de control

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

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

Nuevo plano de control administrado

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

Uno de los cambios más significativos en el producto Anthos Service Mesh 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. Aunque las APIs (CRD de Istio) que se usan para GKE son las mismas, la API de xDS que se envía a los sidecars es compatible sin diferencias de comportamiento las diferencias del plano de control dan como resultado algunas características visibles para ti, el usuario final.

• Tiempo de respuesta del cambio de configuración. Las nuevas implementaciones de servicios o los cambios en las políticas de servicio, tardarán un poco más en el plano de control nuevo.
  • La canalización de configuración realiza una confirmación de configuración de dos pases para para mejorar la confiabilidad. El primer pase realiza validaciones para comprobar si la configuración está bien formada. La fase posterior propaga la configuración a nivel global a las implementaciones de tu servicio. Para habilitar el uso de servicios de Google Cloud, como una carga global interzonal o entre regiones de la infraestructura, la verificación de estado centralizada, el ajuste de escala automático impulsado por el tráfico y de límite de frecuencia administrado, la configuración se propaga a estos sistemas y se validan de forma independiente para comprobar su precisión. La configuración también está de forma interna para permitir la confiabilidad del sitio de Google ingeniería para ejecutar operaciones de productos de forma confiable y eficiente durante cualquier emergencia de producción.
  • Estas operaciones proporcionan mayor confiabilidad, pero dan como resultado una configuración de envío que es más lento que la latencia observada por los usuarios actuales de Anthos Malla de servicios.
  • La latencia de cualquier Pod nuevo para recuperar la configuración existente es puede ser un poco mejor con el nuevo plano de control. La lentitud el envío de configuración es para la primera propagación de cualquier servicio nuevo o las políticas nuevas que se envíen para el servicio. Propagación del extremo las latencias son funcionalmente similares.
• La velocidad de los eventos de escalamiento y otros cambios en los extremos. Son al menos tan rápido con el nuevo plano de control. Estos eventos incluyen el inicio o la detención de Pods nuevos debido al ajuste de escala automático horizontal de Pods y Pods que se reiniciaron con nuevas direcciones IP porque se movieron a una dirección en el clúster.
• Escalamiento de la cantidad de extremos Con el nuevo plano de control global, el extremos de la malla se envían directamente desde cada clúster al grupo de control de los clústeres de la malla. Este es un enfoque más simple, rápido y más escalable que el que usa el plano de control administrado anterior. En modelo antiguo del plano de control administrado (plano de control dedicado), cada Istiod debe deben 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, se propagan directamente al plano de control global. Esto da como resultado mejora la confiabilidad y el rendimiento en mallas con grandes cantidades extremos y permite que las mallas escalen a una mayor cantidad de extremos.

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

Cómo te afecta el nuevo plano de control depende de las APIs y del plano de control que que estás usando.

• Si eres usuario de Traffic Director, tu plano de control seguirá siendo el mismo. Tú no necesitas leer el resto de esta guía. Documentación para tu La implementación de la malla de servicios de Cloud se encuentra en Configurar con APIs de Google Cloud.
• Si eres usuario de Anthos Service Mesh, los siguientes pasos del plano de control en tu implementación existente dependen de si usas el control o el plano de control en el clúster.
  • Si usas el plano de control administrado, con algunas excepciones, las flotas se migrarán al nuevo plano de control al que se hace referencia en la Cloud Service Mesh como plano de control administrado (Traffic Director, o TD). Lee la siguiente sección, Plano de control la migración de mallas y flotas existentes. Si Cuando usas una función que no es compatible con Traffic Director implementación del plano de control, permanecerás temporalmente en el modelo plano de control. Deberías seguir leyendo esta guía.
  • Si usas el plano de control en el clúster, este seguirá siendo igual. No es necesario que leas el resto de esta guía.
  • Si no tienes una organización de Google Cloud y usas 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 estás creando flotas nuevas, recibirás la implementación del plano de control de Traffic Director. Tú deberías seguir leyendo esta guía.
  • Recibirás una notificación sobre la fecha en la que las nuevas flotas reciben 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 que usen el plano de control administrado con la implementación de TD. Recibirás una notificación antes de actualizar tus mallas.

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

Deberías recibir una notificación de que un clúster está programado para actualizarse al menos dos semanas antes de la actualización. Las notificaciones están disponibles en tu clúster condiciones de estado de los atributos.

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

Cualquier clúster del plano de control administrado heredado que se haya integrado con el Se registrará automáticamente meshconfig.googleapis.com API en la flota En el proyecto del clúster con la API de membresía de gkehub.googleapis.com. Si tienes alguna automatización que anula el registro de un clúster, debes quitarla antes de o la migración tendrá problemas. Para el producto administrado para funcionar correctamente, debe estar registrado en una flota con la función de malla habilitado.

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

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

• Para habilitar las verificaciones de estado, se crea el daemonset snk en el Espacio de nombres kube-system del clúster y una regla de firewall por clúster crear.
• Habilitar el grupo de extremos de red (NEG) de datos, la anotación cloud.google.com/neg se agrega a todas las instancias de Google Cloud.
• Los recursos nuevos de Google Cloud, Mesh, Routes, backend servicios y la salud de seguridad se crean en la clúster.
• 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 un límite de cuotas. Puedes consultar las cuotas y solicitar más si es necesario.

Verifica la compatibilidad del plano de control

Revisar las diferencias en las funciones admitidas entre el plano de control administrado de desarrollo de software 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 del control de istiod administrado implementación del plano de control comenzará a recibir el plano de control administrado actualizado con la implementación de Google disponible a nivel global: Traffic Director (TD) plano de control en flotas nuevas.

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

Si incorporas una flota nueva a Cloud Service Mesh administrado, que no está en una organización de Google Cloud o en una nueva, Luego, obtendrá el nuevo plano de control administrado con la implementación de TD 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 del lado izquierdo, en Configura la malla de servicios con las APIs de Istio.
• Si eres un cliente continuo de Traffic Director, tu documentación está Configura la malla de servicios con las APIs de Google Cloud.