Cloud Service Mesh e Traffic Director sono ora Cloud Service Mesh. Per saperne di più, consulta la panoramica di Cloud Service Mesh.

Questa pagina è stata tradotta dall'API Cloud Translation.

Migrazione da un controller del servizio di canonicalizzazione in-cluster a uno gestito

Nota: i servizi canonici sono supportati automaticamente in Cloud Service Mesh versione 1.6.8 e successive.

Questa guida descrive i passaggi per eseguire la migrazione da Canonical Service Controller in cluster a Canonical Service Controller gestito.

Il controller del servizio di canonicalizzazione in cluster è stato ritirato e non riceverà più aggiornamenti. Sebbene i deployment esistenti del controller in cluster continueranno a funzionare, consigliamo vivamente di eseguire la migrazione a Canonical Service Controller gestito per garantire la compatibilità con le release future, l'accesso alle funzionalità più recenti e il supporto continuo. Per tutte le installazioni di Cloud Service Mesh con asmcli dalla versione 1.25 verrà eseguito il provisioning con il controller di servizio Canonical gestito.

1. Attiva la funzionalità del parco risorse Cloud Service Mesh

Il controller del servizio Canonical gestito viene installato nell'ambito della funzionalità del parco risorse Cloud Service Mesh, che viene attivata utilizzando il seguente comando:

  gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Sostituisci FLEET_PROJECT_ID con l'ID del tuo progetto Fleet Host. In genere, FLEET_PROJECT_ID ha lo stesso nome del progetto.

Tieni presente che se prevedi di registrare più cluster, l'abilitazione di Cloud Service Mesh avviene a livello di parco risorse, quindi devi eseguire questo comando solo una volta.

Concedi le autorizzazioni agli account di servizio Cloud Service Mesh

Se il progetto del cluster è diverso dal progetto host del parco risorse, devi consentire ai service account Cloud Service Mesh nel progetto del parco risorse di accedere al progetto del cluster.

Devi eseguire questa operazione una sola volta per ogni progetto cluster. Se in precedenza hai configurato Cloud Service Mesh gestito per questa combinazione di progetti di cluster e parchi risorse, queste modifiche sono già state applicate e non devi eseguire i comandi riportati di seguito.

Concedi agli account di servizio nel progetto del parco risorse l'autorizzazione per accedere al progetto del cluster:

  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

Sostituisci CLUSTER_PROJECT_ID con l'ID progetto per il tuo cluster e FLEET_PROJECT_NUMBER con il numero di progetto per il tuo parco.

Per determinare il numero del progetto per il tuo parco risorse, consulta le istruzioni riportate nel documento relativo ai progetti Google Cloud.

2. Disattivare il controller del servizio di canonicalizzazione all'interno del cluster

Il controller del servizio di canonicalizzazione gestito non può funzionare insieme al controller del servizio di canonicalizzazione in cluster. Pertanto, devi disattivare il controller in cluster.

Controlla se è presente un controller in-cluster: verifica se è presente il controller canonical in-cluster.
```
kubectl get deployment canonical-service-controller-manager -n asm-system
```
Elimina il controller in-cluster: se il deployment viene trovato, puoi eliminarlo (e l'intero spazio dei nomi asm-system) eseguendo il seguente comando:
```
kubectl delete namespace asm-system
```

3. Verificare che il controller canonical gestito sia operativo

Il controller del servizio Canonical gestito indica il proprio stato nello stato della funzionalità, quindi puoi verificare che l'installazione funzioni correttamente controllando lo stato della funzionalità:

Controlla lo stato della funzionalità:recupera lo stato della funzionalità utilizzando il seguente comando:
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
Verifica stato:controlla lo stato del cluster e verifica che state.code sia OK.
- Importante: potrebbero essere necessari fino a 15 minuti per la transizione dello stato a OK. Attendi ed esegui di nuovo il comando.
- Procedi al passaggio successivo solo quando state.code è OK.
- Se dopo 15 minuti state.code non diventa OK, consulta Risolvere i problemi del controller dei servizi canonici gestiti per indicazioni sulla risoluzione dei problemi.
Output di esempio:
```
membershipStates:
    projects/<project-number>/locations/<location>/memberships/<membership-name>:
      state:
        code: OK
        description:
          Revision(s) ready for use: istiod-asm-183-2.
```
Verifica che il controller di canonicalizzazione gestito sia funzionale: verifica che il controller di canonicalizzazione gestito funzioni correttamente eseguendo il deployment di un pod con il sidecar iniettato e controlla se il controller crea automaticamente il servizio di canonicalizzazione corrispondente.
1. Crea uno spazio dei nomi con l'iniezione automatica di sidecar abilitata:
```
kubectl create namespace NAMESPACE_NAME
```
  Segui la sezione Abilitazione dell'iniezione automatica di sidecar per attivare l'iniezione automatica di sidecar nel nuovo spazio dei nomi creato.
2. Crea un file YAML denominato simple_pod.yaml con i seguenti contenuti:
```
    apiVersion: v1
    kind: Pod
    metadata:
      name: simple-pod
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80
```
  L'etichetta app determina il nome del servizio canonico. Per ulteriori informazioni, consulta la sezione Definire il servizio canonico.
3. Esegui il deployment del pod con il seguente comando. Sostituisci NOME_SPAZIO_NOMI con il nome dello spazio dei nomi in cui hai attivato l'iniezione automatica di sidecar.
```
kubectl apply -f simple_pod.yaml -n NAMESPACE_NAME
```
4. Verifica che il pod sia stato creato:
```
kubectl get pods -n NAMESPACE_NAME
```
  Output di esempio:
```
NAME                             READY   STATUS    RESTARTS   AGE
simple-pod                       2/2     Running   0          9s
```
  Note: verifica che nella colonna READY sia visualizzato 2/2. Ciò indica che sia il contenitore principale sia il proxy sidecar sono in esecuzione correttamente. Se visualizza un valore diverso, è probabile che l'iniezione automatica di sidecar non sia abilitata per lo spazio dei nomi.
5. Verifica la creazione del servizio canonico: esegui il seguente comando per elencare tutti i servizi canonici nello spazio dei nomi. Verifica che il servizio canonico my-app sia stato creato.
```
kubectl get canonicalservices -n NAMESPACE_NAME
```
  Output di esempio:
```
  NAME          AGE
  my-app        3s
```
6. Pulizia: elimina il pod, il servizio canonico e lo spazio dei nomi:
```
kubectl delete -f simple_pod.yaml -n NAMESPACE_NAME
kubectl delete canonicalservices my-app -n NAMESPACE_NAME
kubectl delete namespace NAMESPACE_NAME
```
Risoluzione dei problemi:
- Se il servizio canonico richiesto non è stato creato, consulta Risolvere i problemi relativi ai servizi canonici in Cloud Service Mesh.
- Se il problema persiste, puoi ripristinare il controller all'interno del cluster. Consulta Ripristinare il controller del servizio di canonicalizzazione in cluster.

Ripristinare il controller del servizio di canonicalizzazione in cluster

Se riscontri problemi con il controller del servizio di canonicalizzazione gestito, puoi reinstallare il controller all'interno del cluster con il seguente comando:

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

Passaggi successivi

Scopri di più su: