Plano de control administrado
En este documento, se explican las diferencias arquitectónicas entre la implementación del plano de control ISTIOD en desuso y la implementación del plano de control TRAFFIC_DIRECTOR moderno de Google, y se describen los próximos pasos que debes seguir si tus clústeres aún usan un plano de control en desuso.
Descripción general del plano de control
En las mallas de servicios, el plano de control proporciona administración del tráfico, administración de proxies cuando se usa el proxy de Envoy y otras capacidades de redes.
Cloud Service Mesh con las APIs de Istio en clústeres de GKE proporciona una implementación con asistencia completa de las APIs de Istio.
Las APIs se implementan y admiten a través del plano de control TRAFFIC_DIRECTOR integrado y completamente administrado de Cloud Networking. Anteriormente, se admitían dos implementaciones adicionales del plano de control:
- La implementación obsoleta administrada de
ISTIOD, que ejecuta un plano de control dedicado de un solo clúster. - La implementación obsoleta en el clúster
ISTIOD, que ejecuta componentes del plano de control administrados por el cliente dentro de tu clúster
Características operativas del plano de control de TRAFFIC_DIRECTOR
Cloud Service Mesh con el plano de control TRAFFIC_DIRECTOR usa la infraestructura de redes administrada de Google Clouden lugar de instancias del plano de control por clúster.
Las APIs de Istio (CRDs) y la configuración de xDS que se envía a los sidecars de Envoy siguen siendo compatibles, pero debes esperar las siguientes características operativas:
- Propagación de la configuración de políticas y servicios: Cuando creas servicios nuevos o actualizas las políticas de enrutamiento y seguridad, la configuración del servicio se valida y se propaga en los sistemas de Google Cloud antes de que surta efecto en los sidecars.
Como resultado, la propagación inicial de políticas y servicios lleva más tiempo que con los planos de control en el clúster o
ISTIOD. Para obtener orientación sobre la optimización de los flujos de trabajo de implementación, consulta Propagación de la configuración. - Actualizaciones de extremos y escalamiento de Pods: El plano de control propaga directamente los cambios en los extremos de la carga de trabajo, como los Pods nuevos creados por el ajuste de escala automático horizontal de Pods o los Pods que se reinician con direcciones IP nuevas, sin la latencia asociada a las actualizaciones de políticas. Los Pods existentes que recuperan la configuración existente se inician sin demora.
- Descubrimiento de extremos de varios clústeres: En las mallas de varios clústeres, los clústeres comparten sus extremos directamente a través de Google Cloud en lugar de sincronizarlos punto a punto entre cada combinación de clústeres. Esto garantiza que el estado del extremo entre clústeres converja de forma más rápida y coherente a medida que se escala tu malla.
¿Cómo te afecta esto?
Los próximos pasos dependen de la implementación del plano de control de Cloud Service Mesh que usen tus clústeres:
- Plano de control administrado (implementación de
TRAFFIC_DIRECTOR):- Ya utilizas la arquitectura actual y escalable a nivel global (ya sea que se haya configurado con las APIs de Istio, la API de Gateway o las APIs de Google Cloud).
- No es necesario que realices ninguna acción.
- Plano de control administrado (implementación de
ISTIOD):- Esta implementación está obsoleta.
- Debes tomar medidas para inspeccionar tu flota en busca de bloqueadores de compatibilidad, actualizar tu configuración y completar la modernización del plano de control administrado o desinstalar Cloud Service Mesh administrado.
- Plano de control en el clúster:
- El plano de control en el clúster de GKE está obsoleto.
- Las instalaciones en el clúster no se pueden modernizar de forma local. Debes tomar medidas para migrar del plano de control en el clúster al plano de control administrado en un clúster nuevo o desinstalar Cloud Service Mesh.
Modernización del plano de control para Cloud Service Mesh administrado con la implementación de ISTIOD
Todas las flotas administradas que ejecuten la implementación de ISTIOD en desuso deben completar la modernización a la implementación de TRAFFIC_DIRECTOR antes de la fecha límite de fin de la compatibilidad especificada en el aviso de baja.
Puedes modernizar tu flota con la modernización activada por el cliente (recomendada para el control por clúster y el cambio de tráfico por etapas) o la modernización impulsada por Google (lanzamientos automatizados para flotas aptas).
Para obtener instrucciones paso a paso, consulta Modernización del plano de control administrado.
Verifica la compatibilidad del plano de control
Para evaluar tu flota en función de las funciones admitidas y, así, identificar los bloqueadores de configuración antes de la modernización, consulta lo siguiente:
- Información sobre la compatibilidad de Cloud Service Mesh
- Actualizaciones de configuración para la modernización
Apéndice: Cronograma de lanzamiento y baja del plano de control
La transición de los planos de control de ISTIOD a la implementación del plano de control administrado de TRAFFIC_DIRECTOR siguió esta cronología:
- 23 de mayo de 2024: Anthos Service Mesh y Traffic Director convergieron en Cloud Service Mesh, y se introdujo la implementación del plano de control de
TRAFFIC_DIRECTORpara las APIs de Istio. - 1 de julio de 2024: Las flotas nuevas incorporadas a Cloud Service Mesh administrada comenzaron a recibir la implementación de
TRAFFIC_DIRECTORde forma predeterminada. - 8 de septiembre de 2024: Se completó el aprovisionamiento de la implementación de
ISTIODpara las flotas nuevas en la disponibilidad general (con excepciones temporales para organizaciones específicas en una lista de entidades permitidas). - 28 de septiembre de 2026: Se anuncia la baja formal de la implementación del plano de control de
ISTIODadministrado y del plano de control en el clúster en GKE.