Actualizaciones de configuración para la modernización

En este documento se describen las actualizaciones de configuración que puede que tengas que hacer en tu malla de servicios de Cloud gestionada antes de modernizarla al plano de control TRAFFIC_DIRECTOR desde el plano de control ISTIOD.

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

Migrar de secretos de Istio a multicluster_mode

No se admiten secretos de varios clústeres cuando un clúster usa el plano de control TRAFFIC_DIRECTOR. En este documento se describe cómo puedes modernizar tu configuración para pasar de usar secretos de varios clústeres de Istio a usar multicluster_mode.

Comparación entre los secretos de Istio y la API declarativa

El descubrimiento de endpoints multiclúster de Istio de código abierto funciona mediante el uso de istioctl u otras herramientas para crear un secreto de Kubernetes en un clúster. Este secreto permite que un clúster balancee la carga del tráfico a otro clúster de la malla. El plano de control de ISTIOD lee este secreto y empieza a enrutar el tráfico a ese otro clúster.

Cloud Service Mesh tiene una API declarativa para controlar el tráfico entre 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 fiable que crear secretos de Istio manualmente. Las futuras funciones de Cloud Service Mesh dependerán de la API declarativa y no podrás usar esas nuevas funciones directamente con los secretos de Istio. La API declarativa es la única forma de seguir adelante.

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

Migrar de secretos de Istio a la API declarativa

Si has aprovisionado Cloud Service Mesh mediante la gestión automática con la API de la función de flota, no es necesario que sigas estas instrucciones. Estos pasos solo se aplican si has completado el proceso de incorporación con asmcli --managed.

Ten en cuenta que este proceso cambia los secretos que apuntan a un clúster. Durante este proceso, los endpoints se quitan y, a continuación, se vuelven a añadir. Entre el momento en que se quitan los endpoints y el momento en que se añaden, el tráfico volverá brevemente al enrutamiento local en lugar de al balanceo de carga 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. Sigue estos pasos al mismo tiempo o uno tras otro:

Habilita la API declarativa en cada clúster de la flota en la que quieras habilitar la detección de endpoints multiclúster configurando multicluster_mode=connected. Ten en cuenta que debes definir explícitamente multicluster_mode=disconnected si no quieres que se pueda detectar el clúster.

Usa el siguiente comando para habilitar la detección de endpoints multiclúster en un clúster:
```
 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 endpoints en un clúster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Elimina secretos antiguos.

Después de configurar multicluster_mode=connected en tus clústeres, cada clúster tendrá un nuevo secreto generado para cada clúster que también tenga multicluster_mode=connected configurado. El secreto se coloca en el espacio de nombres istio-system y tiene el siguiente formato:
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
También se aplicará la etiqueta istio.io/owned-by: mesh.googleapis.com a cada secreto.

Una vez que se hayan creado los nuevos secretos, puedes eliminar manualmente los secretos creados con istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Una vez que se haya migrado, comprueba las métricas de solicitudes para asegurarte de que se enrutan como se espera.