O Cloud Service Mesh e o Traffic Director são agora o Cloud Service Mesh. Para mais informações, consulte a vista geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

Migração do controlador de serviços canónicos no cluster para o controlador de serviços canónicos gerido

Nota: os serviços canónicos são suportados automaticamente na versão 1.6.8 e superiores do Cloud Service Mesh.

Este guia descreve os passos para migrar do Canonical Service Controller no cluster para o Canonical Service Controller gerido.

O controlador de serviços canónicos no cluster foi descontinuado e vai deixar de receber atualizações. Embora as implementações existentes do controlador no cluster continuem a funcionar, recomendamos vivamente que migre para o controlador de serviços gerido da Canonical para garantir a compatibilidade com lançamentos futuros, o acesso às funcionalidades mais recentes e o apoio técnico contínuo. Todas as instalações do Cloud Service Mesh com o asmcli a partir da versão 1.25 vão ser aprovisionadas com o controlador de serviços canónicos gerido.

1. Ative a funcionalidade de frota do Cloud Service Mesh

O controlador do serviço canónico gerido é instalado como parte da funcionalidade de frota do Cloud Service Mesh, que é ativada através do seguinte comando:

  gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Substitua FLEET_PROJECT_ID pelo ID do seu projeto de anfitrião do Fleet. Geralmente, o FLEET_PROJECT_ID tem o mesmo nome que o projeto.

Tenha em atenção que, se planear registar vários clusters, a ativação do Cloud Service Mesh ocorre ao nível da frota, pelo que só tem de executar este comando uma vez.

Conceda autorizações às contas de serviço da Cloud Service Mesh

Se o projeto do cluster for diferente do projeto anfitrião da frota, tem de permitir que as contas de serviço do Cloud Service Mesh no projeto da frota acedam ao projeto do cluster.

Só tem de fazer isto uma vez para cada projeto de cluster. Se configurou anteriormente o Cloud Service Mesh gerido para esta combinação de projetos de cluster e de frota, estas alterações já foram aplicadas e não tem de executar os seguintes comandos.

Conceda autorização às contas de serviço no projeto da frota para aceder ao projeto do 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

Substitua CLUSTER_PROJECT_ID pelo ID do projeto do seu cluster e FLEET_PROJECT_NUMBER pelo número do projeto da sua frota.

Para determinar o número do projeto da sua frota, consulte as instruções no documento Projetos do Google Cloud.

2. Desative o controlador de serviços canónicos no cluster

O controlador de serviço canónico gerido não pode funcionar juntamente com o controlador de serviço canónico no cluster. Por conseguinte, tem de desativar o controlador no cluster.

Verifique o controlador no cluster: verifique se o controlador canónico no cluster está presente.
```
kubectl get deployment canonical-service-controller-manager -n asm-system
```
Elimine o controlador no cluster: se a implementação for encontrada, pode eliminá-la (e todo o espaço de nomes asm-system) executando o seguinte comando:
```
kubectl delete namespace asm-system
```

3. Verifique se o controlador canónico gerido está operacional

O controlador de serviço canónico gerido comunica o respetivo estado no estado da funcionalidade, pelo que pode confirmar se a instalação está a funcionar corretamente verificando o estado da funcionalidade:

Verifique o estado da funcionalidade: obtenha o estado da funcionalidade através do seguinte comando:
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
Estado da validação: verifique o estado do cluster e confirme que o state.code é OK.
- Importante: a transição do estado para OK pode demorar até 15 minutos. Aguarde e volte a executar o comando.
- Avance para o passo seguinte apenas quando o state.code estiver OK.
- Se o state.code não se tornar OK após 15 minutos, consulte o artigo Resolva problemas do controlador do serviço canónico gerido para obter orientações de resolução de problemas.
Exemplo de saída:
```
membershipStates:
    projects/<project-number>/locations/<location>/memberships/<membership-name>:
      state:
        code: OK
        description:
          Revision(s) ready for use: istiod-asm-183-2.
```
Verifique se o controlador canónico gerido está funcional: verifique se o controlador canónico gerido está a funcionar corretamente implementando um pod com o sidecar injetado e verifique se o controlador cria automaticamente o serviço canónico correspondente.
1. Crie um espaço de nomes com a injeção automática de sidecar ativada:
```
kubectl create namespace NAMESPACE_NAME
```
  Siga a secção Ativar a injeção automática de sidecar para ativar a injeção automática de sidecar no espaço de nomes recém-criado.
2. Crie um ficheiro YAML com o nome simple_pod.yaml e o seguinte conteúdo:
```
    apiVersion: v1
    kind: Pod
    metadata:
      name: simple-pod
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx:latest
        ports:
        - containerPort: 80
```
  A etiqueta app determina o nome do serviço canónico. Para mais informações, consulte o artigo Definir o serviço canónico.
3. Implemente o pod com o seguinte comando. Substitua NAMESPACE_NAME pelo nome do espaço de nomes onde ativou a injeção automática de sidecar.
```
kubectl apply -f simple_pod.yaml -n NAMESPACE_NAME
```
4. Confirme se o pod foi criado:
```
kubectl get pods -n NAMESPACE_NAME
```
  Exemplo de saída:
```
NAME                             READY   STATUS    RESTARTS   AGE
simple-pod                       2/2     Running   0          9s
```
  Note: confirme se a coluna READY apresenta 2/2. Isto indica que o contentor principal e o proxy sidecar estão a ser executados corretamente. Se vir um valor diferente, é provável que a injeção automática de sidecar não esteja ativada para o espaço de nomes.
5. Valide a criação do serviço canónico: execute o seguinte comando para listar todos os serviços canónicos no espaço de nomes. Verifique se o serviço canónico my-app foi criado.
```
kubectl get canonicalservices -n NAMESPACE_NAME
```
  Exemplo de saída:
```
  NAME          AGE
  my-app        3s
```
6. Limpeza: elimine o pod, o serviço canónico e o espaço de nomes:
```
kubectl delete -f simple_pod.yaml -n NAMESPACE_NAME
kubectl delete canonicalservices my-app -n NAMESPACE_NAME
kubectl delete namespace NAMESPACE_NAME
```
Resolução de problemas:
- Se o serviço canónico necessário não for criado, consulte o artigo Resolva problemas de serviços canónicos na Cloud Service Mesh.
- Se o problema persistir, pode reverter para o controlador no cluster. Consulte o artigo Reverta para o controlador de serviço canónico no cluster.

Reverta para o controlador de serviços canónicos no cluster

Se tiver problemas com o controlador de serviço canónico gerido, pode reinstalar o controlador no cluster com o seguinte comando:

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

O que se segue?

Saiba mais acerca do: