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

Esta página foi traduzida pela API Cloud Translation.

Migrar do controlador de serviço canônico no cluster para o gerenciado

Observação:os serviços canônicos são compatíveis com a versão 1.6.8 do Cloud Service Mesh e versões mais recentes.

Este guia descreve as etapas para migrar do controlador de serviço canônico no cluster para o controlador de serviço canônico gerenciado.

O controlador de serviço canônico no cluster foi descontinuado e não vai receber mais atualizações. Embora as implantações atuais do controlador no cluster continuem a funcionar, recomendamos migrar para o controlador de serviço Canonical gerenciado para garantir a compatibilidade com versões futuras, o acesso aos recursos mais recentes e o suporte contínuo. Todas as instalações do Cloud Service Mesh com o asmcli a partir da versão 1.25 serão provisionadas com o controlador de serviço canônico gerenciado.

1. Ativar o recurso de frota do Cloud Service Mesh

O controlador de serviço canônico gerenciado é instalado como parte do recurso de frota do Cloud Service Mesh, que é ativado usando o seguinte comando:

  gcloud container fleet mesh enable --project FLEET_PROJECT_ID

Substitua FLEET_PROJECT_ID pelo ID do projeto host da frota. Geralmente, o FLEET_PROJECT_ID tem o mesmo nome do projeto.

Se você planeja registrar vários clusters, a ativação do Cloud Service Mesh acontece no nível da frota. Assim, você só precisa executar esse comando uma vez.

Conceder permissões às contas de serviço do Cloud Service Mesh

Se o projeto do cluster for diferente do projeto host da frota, será necessário permitir que as contas de serviço do Cloud Service Mesh no projeto da frota acessem o projeto do cluster.

É necessário fazer isso apenas uma vez para cada projeto de cluster. Se você já configurou o Cloud Service Mesh gerenciado para essa combinação de projetos de cluster e de frota, essas alterações já foram aplicadas e não é necessário executar os comandos a seguir.

Conceda às contas de serviço no projeto da frota permissão para acessar o 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 cluster e FLEET_PROJECT_NUMBER pelo número do projeto da frota.

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

2. Desativar o controlador de serviço canônico no cluster

O controlador de serviço canônico gerenciado não pode funcionar com o controlador de serviço canônico no cluster. Portanto, é necessário desativar o controlador no cluster.

Verificar o controlador no cluster: verifique se o controlador canônico no cluster está presente.
```
kubectl get deployment canonical-service-controller-manager -n asm-system
```
Excluir o controlador no cluster: se a implantação for encontrada, ela poderá ser excluída (e todo o namespace asm-system) executando o seguinte comando:
```
kubectl delete namespace asm-system
```

3. Verificar se o controlador canônico gerenciado está operacional

O controlador de serviço canônico gerenciado informa o status no estado do recurso. Para confirmar se a instalação está funcionando corretamente, verifique o estado do recurso:

Conferir o estado do recurso:extraia o estado do recurso usando o seguinte comando:
```
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
```
Verificar status:verifique o estado do cluster e confirme se o state.code está OK.
- Importante:pode levar até 15 minutos para que o estado mude para OK. Aguarde e execute o comando novamente.
- Só prossiga para a próxima etapa quando o state.code estiver OK.
- Se o state.code não se tornar OK após 15 minutos, consulte Resolver problemas do controlador de serviço canônico gerenciado para ver orientações de soluçã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.
```
Verificar se o controlador canônico gerenciado está funcional:implante um pod com o sidecar injetado e verifique se o controlador cria automaticamente o serviço canônico correspondente.
1. Crie um namespace com a injeção automática de sidecar ativada:
```
kubectl create namespace NAMESPACE_NAME
```
  Siga a seção Como ativar a injeção automática de sidecar para ativar a injeção automática de sidecar no namespace recém-criado.
2. Crie um arquivo YAML chamado simple_pod.yaml com 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
```
  O rótulo app determina o nome do serviço canônico. Para mais informações, consulte Como definir um serviço canônico.
3. Implante o pod com o comando a seguir. Substitua NAMESPACE_NAME pelo nome do namespace em que você 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 mostra 2/2. Isso indica que o contêiner principal e o proxy do sidecar estão sendo executados corretamente. Se um valor diferente aparecer, provavelmente a injeção automática de sidecar não está ativada para o namespace.
5. Verifique a criação de serviço canônico: execute o comando a seguir para listar todos os serviços canônicos no namespace. 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: exclua o pod, o serviço canônico e o namespace:
```
kubectl delete -f simple_pod.yaml -n NAMESPACE_NAME
kubectl delete canonicalservices my-app -n NAMESPACE_NAME
kubectl delete namespace NAMESPACE_NAME
```
Solução de problemas:
- Se o serviço canônico necessário não for criado, consulte Como resolver problemas do serviço canônico no Cloud Service Mesh.
- Se o problema persistir, você poderá reverter para o controlador no cluster. Consulte Reverter para o controlador de serviço canônico no cluster.

Reverter para o controlador de serviço canônico no cluster

Se você tiver problemas com o controlador de serviço canônico gerenciado, reinstale 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

A seguir

Saiba mais sobre: