Cloud Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la información general sobre Cloud Service Mesh.

Esta página se ha traducido con Cloud Translation API.

Migrar de un controlador de servicio canónico en el clúster a un controlador de servicio canónico gestionado

Nota: Los servicios canónicos se admiten automáticamente en Cloud Service Mesh versión 1.6.8 y posteriores.

En esta guía se describen los pasos para migrar de Canonical Service Controller en el clúster a Managed Canonical Service Controller.

El controlador del servicio canónico en el clúster ha quedado obsoleto y ya no recibirá actualizaciones. Aunque las implementaciones actuales del controlador en el clúster seguirán funcionando, te recomendamos que migres al controlador de servicio de Canonical gestionado para asegurarte de que es compatible con las próximas versiones, acceder a las funciones más recientes y seguir recibiendo asistencia. Todas las instalaciones de Cloud Service Mesh con asmcli a partir de la versión 1.25 se aprovisionarán con el controlador de servicio canónico gestionado.

1. Habilitar la función de flota de Cloud Service Mesh

El controlador del servicio canónico gestionado se instala como parte de la función de flota de Cloud Service Mesh, que se habilita con el siguiente comando:

  gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Sustituye FLEET_PROJECT_ID por el ID de tu proyecto de Fleet Host. Por lo general, el valor de FLEET_PROJECT_ID tiene el mismo nombre que el proyecto.

Ten en cuenta que, si tienes previsto registrar varios clústeres, Cloud Service Mesh se habilita a nivel de flota, por lo que solo tienes que ejecutar este comando una vez.

Conceder permisos a las cuentas de servicio de Cloud Service Mesh

Si el proyecto de tu clúster es diferente del proyecto de host de tu flota, debes permitir que las cuentas de servicio de Cloud Service Mesh del proyecto de la flota accedan al proyecto del clúster.

Solo tienes que hacerlo una vez por cada proyecto de clúster. Si ya has configurado Cloud Service Mesh gestionado para esta combinación de proyectos de clúster y de flota, estos cambios ya se han aplicado y no tienes que ejecutar los siguientes comandos.

Concede permiso a las cuentas de servicio del proyecto de la flota para acceder al proyecto del clúster:

  gcloud projects add-iam-policy-binding "CLUSTER_PROJECT_ID" \
    --member "serviceAccount:service-FLEET_PROJECT_NUMBER@gcp-sa-servicemesh.iam.gserviceaccount.com" \
    --role roles/anthosservicemesh.serviceAgent

Sustituye CLUSTER_PROJECT_ID por el ID del proyecto de tu clúster y FLEET_PROJECT_NUMBER por el número del proyecto de tu flota.

Para determinar el número de proyecto de tu flota, consulta las instrucciones del documento Proyectos de Google Cloud.

2. Inhabilitar el controlador del servicio canónico en el clúster

El controlador del servicio canónico gestionado no puede funcionar junto con el controlador del servicio canónico en el clúster. Por lo tanto, debes inhabilitar el controlador del clúster.

Comprobar el controlador In-Cluster: comprueba si está presente el controlador canónico In-Cluster.
```
kubectl get deployment canonical-service-controller-manager -n asm-system
```
Elimina el controlador In-Cluster: si se encuentra la implementación, puedes eliminarla (y todo el espacio de nombres asm-system) ejecutando el siguiente comando:
```
kubectl delete namespace asm-system
```

3. Verificar que el controlador canónico gestionado funciona

El controlador de servicio canónico gestionado informa de su estado en featureState, por lo que puedes confirmar que la instalación funciona correctamente comprobando el estado de la función:

Comprobar el estado de la función: recupera el estado de la función con el siguiente comando:
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
Verificar estado: comprueba el estado de tu clúster y verifica que state.code sea OK.
- Importante: El estado puede tardar hasta 15 minutos en cambiar a OK. Espera y vuelve a ejecutar el comando.
- Ve al siguiente paso solo cuando el state.code sea OK.
- Si el state.code no se convierte en OK después de 15 minutos, consulta la sección Resolver problemas del controlador de servicio canónico gestionado para obtener ayuda.
Ejemplo:
```
membershipStates:
    projects/<project-number>/locations/<location>/memberships/<membership-name>:
      state:
        code: OK
        description:
          Revision(s) ready for use: istiod-asm-183-2.
```
Comprobar que el controlador canónico gestionado funciona: verifica que el controlador canónico gestionado funciona correctamente desplegando un pod con un sidecar insertado y comprueba si el controlador crea automáticamente el servicio canónico correspondiente.
1. Crea un espacio de nombres con la inyección automática de sidecar habilitada:
```
kubectl create namespace NAMESPACE_NAME
```
  Sigue los pasos de la sección Habilitar la inyección automática de sidecars para habilitar la inyección automática de sidecars en el espacio de nombres recién creado.
2. Crea un archivo YAML llamado simple_pod.yaml con el siguiente contenido:
```
    apiVersion: v1
    kind: Pod
    metadata:
      name: simple-pod
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80
```
  La etiqueta app determina el nombre del servicio canónico. Para obtener más información, consulta el artículo Definir un servicio canónico.
3. Despliega el pod con el siguiente comando. Sustituye NAMESPACE_NAME por el nombre del espacio de nombres en el que has habilitado la inyección automática de sidecar.
```
kubectl apply -f simple_pod.yaml -n NAMESPACE_NAME
```
4. Confirma que se ha creado el pod:
```
kubectl get pods -n NAMESPACE_NAME
```
  Ejemplo:
```
NAME                             READY   STATUS    RESTARTS   AGE
simple-pod                       2/2     Running   0          9s
```
  Note: comprueba que en la columna ESTADO se muestre 2/2. Esto indica que tanto el contenedor principal como el proxy sidecar se están ejecutando correctamente. Si ves un valor diferente, es probable que la inyección automática de sidecar no esté habilitada en el espacio de nombres.
5. Verificar la creación del servicio canónico: ejecuta el siguiente comando para enumerar todos los servicios canónicos del espacio de nombres. Verifica que se haya creado el servicio canónico my-app.
```
kubectl get canonicalservices -n NAMESPACE_NAME
```
  Ejemplo:
```
  NAME          AGE
  my-app        3s
```
6. Limpieza: elimina el pod, el servicio canónico y el espacio de nombres:
```
kubectl delete -f simple_pod.yaml -n NAMESPACE_NAME
kubectl delete canonicalservices my-app -n NAMESPACE_NAME
kubectl delete namespace NAMESPACE_NAME
```
Solución de problemas:
- Si no se crea el servicio canónico necesario, consulta el artículo Solucionar problemas de servicios canónicos en Cloud Service Mesh.
- Si el problema persiste, puedes volver al controlador del clúster. Consulta Volver al controlador del servicio canónico en el clúster.

Volver al controlador del servicio canónico en el clúster

Si tienes problemas con el controlador del servicio canónico gestionado, puedes volver a instalar el controlador en el clúster con el siguiente comando:

  kubectl apply -f \
  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/release-1.25/asm/canonical-service/controller.yaml

Siguientes pasos

Puedes informarte sobre lo siguiente: