Actualizaciones de configuración para la modernización

En este documento, se describen las actualizaciones de configuración que es posible que debas realizar en tu Cloud Service Mesh administrado antes de modernizar tu malla 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 administrado.

Migra de los secretos de Istio a multicluster_mode

Los secretos de varios clústeres no son compatibles cuando un clúster usa el plano de control TRAFFIC_DIRECTOR. En este documento, se describe cómo puedes modernizarte del uso de secretos de varios clústeres de Istio al uso de multicluster_mode.

Descripción general de los secretos de Istio en comparación con las APIs declarativas

El descubrimiento de extremos de Istio multiclúster de código abierto funciona con istioctl u otras herramientas para crear un Secreto de Kubernetes en un clúster. Este secreto permite que un clúster balancee el tráfico a otro clúster en la malla. Luego, el plano de control ISTIOD lee este secreto y comienza a enrutar el tráfico a ese otro clúster.

Cloud Service Mesh tiene una API declarativa para controlar el tráfico de varios 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 confiable que crearlos de forma manual. Las funciones futuras de Cloud Service Mesh dependerán de la API declarativa, y no podrás usar esas funciones nuevas con secretos de Istio directamente. La API declarativa es la única ruta de acceso admitida.

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

Migra de los secretos de Istio a la API declarativa

Si aprovisionaste Cloud Service Mesh con la administración automática con la API de funciones de flota, no necesitas seguir estas instrucciones. Estos pasos solo se aplican si realizaste la integración con asmcli --managed.

Ten en cuenta que este proceso cambia los secretos que apuntan a un clúster. Durante este proceso, los extremos se quitan y, luego, se vuelven a agregar. Entre los extremos que se quitan y se agregan, el tráfico volverá brevemente al enrutamiento local en lugar de balancear la carga en otros clústeres. Para obtener más información, consulta el problema de GitHub.

Para pasar del uso de secretos de Istio a la API declarativa, sigue estos pasos. Ejecuta estos pasos al mismo tiempo o en rápida sucesión:

Habilita la API declarativa para cada clúster de la flota en el que desees habilitar el descubrimiento de extremos de varios clústeres configurando multicluster_mode=connected. Ten en cuenta que debes configurar multicluster_mode=disconnected de forma explícita si no deseas que el clúster sea detectable.

Usa el siguiente comando para habilitar un clúster para el descubrimiento de extremos de varios clústeres:
```
 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 extremos en un clúster:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Borra los secretos antiguos.

Después de configurar multicluster_mode=connected en tus clústeres, cada clúster tendrá un secreto nuevo generado para todos los demás clústeres que también tengan configurado multicluster_mode=connected. 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
```
A cada secreto también se le aplicará la etiqueta istio.io/owned-by: mesh.googleapis.com.

Una vez que se creen los secretos nuevos, puedes borrar los secretos que se crearon de forma manual con istioctl create-remote-secret:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Una vez que se hayan migrado, verifica las métricas de solicitud para asegurarte de que se enruten como se espera.