Você está vendo a documentação legada do Service Mesh v1.18.

Versões disponíveis

Cloud Service Mesh
1.22 archive
1.21 archive
1.20 archive
1.19 archive
1.18 archive

Esta página foi traduzida pela API Cloud Translation.

Migração com base canário para a CA da malha

Para migrar a CA com tempo de inatividade mínimo e sem migrar planos de controle, consulte Migração de CA no local.

Migração para a autoridade de certificação do Cloud Service Mesh (Mesh CA) de AC do Istio (também conhecida como Citadel) exige a migração do raiz de confiança. Antes do Cloud Service Mesh 1.10, se você quisesse migrar do Istio para Google Kubernetes Engine (GKE) para o Cloud Service Mesh com Mesh CA, era preciso agendar o tempo de inatividade porque o Cloud Service Mesh não conseguiu carregar vários certificados raiz. Portanto, durante a migração, as cargas de trabalho recém-implantadas confiam no novo certificado raiz, enquanto outras confiam no certificado raiz antigo. Não é possível autenticar as cargas de trabalho que usam certificados assinados por diferentes certificados raiz. Isso significa que o tráfego TLS mútuo (mTLS, na sigla em inglês) é interrompido durante a migração. Todo o cluster só é recuperado totalmente quando o plano de controle e todas as cargas de trabalho em todos os namespaces são reimplantados com o certificado da CA da malha. Se sua malha tiver vários clusters com cargas de trabalho que enviam solicitações para cargas de trabalho em outro cluster, todas as cargas de trabalho nesses clusters também precisarão ser atualizadas.

Siga as etapas deste guia para os seguintes casos de uso:

Migre do Istio no GKE para o plano de controle no cluster 1.18.7-asm.26 do Cloud Service Mesh com a CA da malha.
Faça upgrade do Cloud Service Mesh 1.15 or a 1.16 patch release com o Istio CA para o Plano de controle no cluster do Cloud Service Mesh 1.18.7-asm.26 com o Mesh CA.

Limitações

Todos os clusters precisam estar no mesmo projeto do Google Cloud.

Pré-requisitos

Siga as etapas em Instalar ferramentas dependentes e validar o cluster para:

Ferramentas necessárias

Durante a migração, execute uma ferramenta fornecida pelo Google, migrate_ca, para validar o seguinte para cada pod no cluster:

O certificado raiz da CA do Istio e da CA da malha.
O certificado mTLS da carga de trabalho emitido pela Istio CA e pela CA da malha.
Os domínios de confiança configurados pela CA do Istio e pela CA da malha.

Essa ferramenta tem as seguintes dependências:

awk
grep
istioctl Executar o asmcli install faz o download da versão de istioctl que corresponda à versão do Cloud Service Mesh que você está instalando.
jq
kubectl
openssl

Visão geral da migração

Para migrar para a CA da malha, siga o processo de migração baseado em revisão, também conhecido como "upgrade canário". Com uma migração baseada em revisão, uma nova revisão do plano de controle é implantada ao lado do plano de controle existente. Em seguida, mova gradualmente as cargas de trabalho para a nova revisão, o que permite monitorar o efeito da migração durante o processo. Durante o processo de migração, a autenticação e a autorização estão totalmente funcionais entre as cargas de trabalho que usam a CA da malha e as cargas de trabalho que usam a CA do Istio.

Veja a seguir um resumo da migração para a CA da malha:

Distribua a raiz da CA da malha de confiança.
1. Instale uma nova revisão do plano de controle que use a CA do Istio com uma opção que distribuirá a raiz de confiança da CA do Mesh.
2. Migre cargas de trabalho para o novo plano de controle, namespace por namespace e teste o aplicativo. Quando todas as cargas de trabalho forem migradas com sucesso para o novo plano de controle, remova o plano de controle antigo.
Migrar para a CA da malha. Agora que todos os proxies secundários estão configurados com a raiz de confiança antiga e a raiz de confiança da CA da malha, é possível migrar para a CA da malha sem tempo de inatividade. Novamente, você segue o processo de migração baseado em revisão:
1. Instale uma revisão do plano de controle com a CA da malha ativada.
2. Migre cargas de trabalho para a nova revisão do plano de controle, namespace por namespace e teste seu aplicativo. Quando todas as cargas de trabalho forem migradas com sucesso para o novo plano de controle, remova o plano de controle antigo.
3. Remova os secrets de CA no cluster associados à CA antiga e reinicie o novo plano de controle.

Distribuir a raiz de confiança de CA da malha

Antes de migrar para a CA da malha, todos os clusters do GKE na malha precisa ter o Cloud Service Mesh 1.10 ou posterior e todos os clusters precisam ser configurados com uma opção de plano de controle que aciona a raiz de confiança para que a CA da malha seja distribuídos para os proxies de todas as cargas de trabalho no cluster. Quando o processo é concluído, cada proxy é configurado com a raiz de confianças antiga e nova. Com esse esquema, ao migrar para a CA da malha, as cargas de trabalho que usam a CA da malha poderão se autenticar com cargas de trabalho usando a CA antiga.

Instalar uma nova revisão do plano de controle

Instale uma revisão de plano de controle com uma opção que distribui a raiz de confiança da CA da malha.

Siga as etapas em Instalar ferramentas dependentes e validar o cluster para se preparar para usar uma ferramenta fornecida pelo Google, asmcli, para instalar a nova revisão do plano de controle.
Verifique se você tem a versão de asmcli que instala o Cloud Service Mesh 1.11 ou mais recente:
```
./asmcli --version
```

Execute asmcli install. No comando a seguir, substitua os marcadores pelos valores.

 ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --enable_all \
   --ca citadel \
   --ca_cert CA_CERT_FILE_PATH \
   --ca_key CA_KEY_FILE_PATH \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH \
   --option ca-migration-citadel \
   --revision_name REVISION_1 \
   --output_dir DIR_PATH

--fleet_id O ID do projeto host da frota.
--kubeconfig O caminho para o arquivo kubeconfig. É possível especificar um caminho relativo ou completo. A variável de ambiente $PWD não funciona aqui.
--output_dir Inclua essa opção para especificar um diretório em que asmcli faz o download do pacote anthos-service-mesh e extrai o arquivo de instalação, que contém istioctl, amostras e manifestos. Caso contrário, asmcli fará o download dos arquivos para um diretório tmp. É possível especificar um caminho relativo ou um caminho completo. A variável de ambiente $PWD não funciona aqui.
--enable_all Permite que a ferramenta:
- Conceder as permissões necessárias do IAM.
- Ative as APIs do Google necessárias.
- Defina um rótulo no cluster que identifique a malha.
- Registre o cluster na frota se ele ainda não estiver registrado.
-ca citadel Para evitar a inatividade, especifique a CA do Istio. A opção citadel corresponde à CA do Istio. Não mude para a CA da malha neste momento.
--ca_cert: o certificado intermediário.
--ca_key: a chave do certificado intermediário
--root_cert: o certificado raiz.
--cert_chain: a cadeia de certificados.
--option ca-migration-citadel Quando você reimplanta as cargas de trabalho, essa opção aciona a nova raiz de confiança a ser distribuída aos proxies sidecar das cargas de trabalho.
REVISION_1: recomendado. Um rótulo de revisão é um par de chave-valor definido no plano de controle. A chave do rótulo de revisão é sempre istio.io/rev. Por padrão, a ferramenta define o valor do rótulo de revisão com base na versão do Cloud Service Mesh, por exemplo: asm-1187-26. Recomendamos que você inclua essa opção e substitua REVISION_1 por um nome que descreva a instalação, como asm-1187-26-distribute-root. O nome precisa ser um identificador DNS-1035 e conter caracteres alfanuméricos minúsculos ou -, começar com um caractere alfabético e terminar com um caractere alfanumérico (como my-name ou abc-123).

Migrar cargas de trabalho para o novo plano de controle

Para concluir a distribuição da nova raiz de confiança, é necessário rotular seus namespaces com o rótulo de revisão istio.io/rev=<var>REVISION_1</var>-distribute-root e reiniciar suas cargas de trabalho. Ao testar as cargas de trabalho depois de reiniciá-las, execute uma ferramenta para validar se o proxy sidecar está configurado com a raiz de confiança antiga e nova da CA da malha.

Defina o contexto atual para kubectl. No comando a seguir, altere --region para --zone se você tiver um cluster de zona única.
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID \
    --region=CLUSTER_LOCATION
```

Faça o download da ferramenta de validação:

curl https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/master/scripts/ca-migration/migrate_ca > migrate_ca

Defina o bit executável na ferramenta:
```
chmod +x migrate_ca
```
A ferramenta migrate_ca chama istioctl, que depende da versão. A ferramenta asmcli adiciona um link simbólico a istioctl no diretório especificado para --output_dir. Verifique se o diretório está no início do seu caminho. No comando a seguir, substitua ISTIOCTL_PATH pelo diretório que contém istioctl que a ferramenta fez o download.
```
export PATH=ISTIOCTL_PATH:$PATH
which istioctl
echo $PATH
```

Consiga o rótulo de revisão em istiod e o istio-ingressgateway.

kubectl get pod -n istio-system -L istio.io/rev

A resposta será semelhante a:

NAME                                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-5fd454f8ff-t7w9x                            1/1     Running   0          36m   default
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p   1/1     Running   0          18m   asm-195-2-distribute-root
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs   1/1     Running   0          18m   asm-195-2-distribute-root
istiod-68bc495f77-shl2h                                          1/1     Running   0          36m   default
istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c                1/1     Running   0          18m   asm-195-2-distribute-root
istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s                1/1     Running   0          18m   asm-195-2-distribute-root

Na saída, na coluna REV, anote o valor do rótulo de revisão para a nova revisão, que corresponde ao rótulo de revisão especificado quando você executou asmcli install. Neste exemplo, o valor é asm-1187-26-distribute-root.
Você precisa excluir a revisão antiga de istiod quando terminar de mover as cargas de trabalho para a nova revisão. Observe o valor no rótulo da revisão da istiod antiga. A saída de exemplo mostra uma migração do Istio, que está usando a revisão default.

Adicione o rótulo de revisão a um namespace e remova o rótulo istio-injection, se ele existir. No comando a seguir, substitua NAMESPACE pelo namespace a ser rotulado.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite
```
Se vir "istio-injection not found" na saída, poderá ignorá-la. Isso significa que o namespace não tinha o rótulo istio-injection anteriormente. Como o comportamento da injeção automática é indefinido quando um namespace tem o istio-injection e o rótulo de revisão, todos os comandos kubectl label na documentação do Cloud Service Mesh garantem explicitamente que apenas um seja definido.

Reinicie os pods para acionar a nova injeção:

kubectl rollout restart deployment -n NAMESPACE

Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.
Se você tiver cargas de trabalho em outros namespaces, repita as etapas para rotular o namespace e reiniciar os pods.
Valide se os proxies sidecar para todas as cargas de trabalho no cluster estão configurados com os certificados raiz antigos e novos:
```
./migrate_ca check-root-cert
```
Saída esperada:
```
Namespace: foo
httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
```
Se você precisar migrar gateways, siga as etapas em Upgrades Canary (avançado) para instalar novas implantações do gateway. Lembre-se do seguinte:
- Use REVISION_1 como o rótulo de revisão.
- Implante os recursos de gateway no mesmo namespace que o gateway da instalação mais antiga para realizar a migração sem inatividade. Verifique se os recursos de serviço que apontam para o gateway mais antigo também devem incluir as implantações mais novas.
- Não exclua as implantações de gateway mais antigas até ter certeza de que o aplicativo está funcionando corretamente (após a próxima etapa).
Se você achar que seu aplicativo está funcionando conforme esperado, continue com as etapas para concluir a transição para a nova versão de istiod. Se houver um problema com o aplicativo, siga as etapas para reverter.
Concluir a transição
Se o aplicativo estiver funcionando corretamente, remova o plano de controle antigo para concluir a transição para a nova versão.
1. Altere para o diretório em que os arquivos do repositório anthos-service-mesh do GitHub estão localizados.
2. Configure o webhook de validação para usar o novo plano de controle.
  kubectl apply -f asm/istio/istiod-service.yaml
3. Exclua a implantação istio-ingressgateway antiga. O comando executado depende se você está migrando do Istio ou fazendo upgrade de uma versão anterior do Cloud Service Mesh:
  Migrar
  Se você tiver migrado do Istio, o istio-ingressgateway antigo não terá um rótulo de revisão.
  
  kubectl delete deploy/istio-ingressgateway -n istio-system
  
  Fazer upgrade
  Se você fez upgrade de uma versão anterior do Cloud Service Mesh, no comando a seguir, substitua OLD_REVISION pelo rótulo de revisão da versão anterior do istio-ingressgateway.
  
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
4. Exclua a revisão antiga de istiod. O comando usado depende se você está migrando do Istio ou fazendo upgrade de uma versão anterior do Cloud Service Mesh.
  Migrar
  Se você tiver migrado do Istio, o istio-ingressgateway antigo não terá um rótulo de revisão.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  Fazer upgrade
  Se você fez upgrade de uma versão anterior do Cloud Service Mesh, no comando a seguir, verifique se OLD_REVISION corresponde ao rótulo de revisão da versão anterior de istiod.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
5. Remova a versão antiga da configuração de IstioOperator.
  kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
  A saída esperada terá esta aparência:
  istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
Reversão
Se você encontrar um problema ao testar seu aplicativo com a nova versão de istiod, siga estas etapas para reverter para a versão anterior:
1. Exclua as novas implantações de gateway instaladas como parte da etapa 11.
2. Altere o nome do seu namespace para ativar a injeção automática com a versão anterior do istiod. O comando usado depende de você ter usado um rótulo de revisão ou istio-injection=enabled com a versão anterior.
  - Se você usou um rótulo de revisão para a injeção automática, faça o seguinte:
    
    kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
  - Se você usou istio-injection=enabled:
    
    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
  Resposta esperada:
  namespace/NAMESPACE labeled
3. Confirme se o rótulo de revisão no namespace corresponde ao rótulo de revisão na versão anterior de istiod:
  kubectl get ns NAMESPACE --show-labels
4. Reinicie os pods para acionar a nova injeção de modo que os proxies tenham a versão do Istio:
  kubectl rollout restart deployment -n NAMESPACE
5. Remova a nova implantação istio-ingressgateway.
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
6. Remova a nova revisão de istiod.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
7. Remova a nova configuração IstioOperator.
  kubectl delete IstioOperator installed-state-asm-1187-26-distribute-root -n istio-system
  A saída esperada será assim:
  istiooperator.install.istio.io "installed-state-asm-1187-26-distribute-root" deleted

Migrar para a CA da malha

Agora que os proxies secundários de todas as cargas de trabalho estão configurados com a raiz de confiança antiga e a nova raiz de confiança para a CA da malha, as etapas para migrar para a CA da malha são semelhantes às que você fez para distribuir a raiz de confiança da CA da malha:

Instalar um novo plano de controle com a CA da malha ativada

Use asmcli install para instalar uma nova revisão de plano de controle que tenha a CA da malha ativada.

Se você tiver personalizado a instalação anterior, precisará especificar os mesmos arquivos de sobreposição ao executar asmcli install.
Execute asmcli install. No comando a seguir, substitua os marcadores pelos valores.
```
 ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --output_dir DIR_PATH \
   --enable_all \
   --ca mesh_ca \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH
   --option ca-migration-meshca \
  --revision_name REVISION_2 \
  --output_dir DIR_PATH \
  OVERLAYS
```

Migrar cargas de trabalho para o novo plano de controle

Para concluir a instalação, é preciso rotular seus namespaces com o novo rótulo de revisão e reiniciar as cargas de trabalho.

Consiga o rótulo de revisão em istiod e o istio-ingressgateway.

kubectl get pod -n istio-system -L istio.io/rev

A resposta será semelhante a:

NAME                                                                          READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-asm-1187-26-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-1187-26-distribute-root
istio-ingressgateway-asm-1187-26-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-1187-26-distribute-root
istio-ingressgateway-asm-1187-26-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1187-26-meshca-ca-migration
istio-ingressgateway-asm-1187-26-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1187-26-meshca-ca-migration
istiod-asm-1187-26-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-1187-26-distribute-root
istiod-asm-1187-26-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-1187-26-distribute-root
istiod-asm-1187-26-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1187-26-meshca-ca-migration
istiod-asm-1187-26-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1187-26-meshca-ca-migration

Na saída, na coluna REV, anote o valor do rótulo de revisão da nova versão. Neste exemplo, o valor é asm-1187-26-meshca-ca-migration.
Observe também o valor no rótulo de revisão da versão istiod antiga. Você precisará dele para excluir a versão antiga do istiod ao terminar de mover as cargas de trabalho para a nova versão. No exemplo, o valor do rótulo de revisão da revisão anterior é "asm-1187-26-distribute-root".

Adicione o novo rótulo de revisão em um namespace. No comando a seguir, substitua NAMESPACE pelo namespace a ser rotulado.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
```

Reinicie os pods para acionar a nova injeção:

kubectl rollout restart deployment -n NAMESPACE

Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente. Certifique-se de que a comunicação mTLS funcione entre cargas de trabalho no namespace mais antigo e no namespace mais recente.
Se você tiver cargas de trabalho em outros namespaces, repita as etapas para rotular o namespace e reiniciar os pods.
Siga as etapas descritas em Upgrades no local para fazer upgrade das implantações de gateway mais antigas instaladas na etapa 11 da seção anterior para a revisão mais recente. REVISION_2.
Se você achar que seu aplicativo está funcionando conforme esperado, continue com as etapas para concluir a transição para o novo plano de controle. Se houver um problema com o aplicativo, siga as etapas para reverter.
Concluir a transição
Se o aplicativo estiver funcionando corretamente, remova o plano de controle antigo para concluir a transição para a nova versão.
1. Altere para o diretório em que os arquivos do repositório anthos-service-mesh do GitHub estão localizados.
2. Configure o webhook de validação para usar o novo plano de controle.
  kubectl apply -f asm/istio/istiod-service.yaml
3. Exclua a implantação istio-ingressgateway antiga. No comando a seguir, substitua OLD_REVISION pelo rótulo de revisão da versão anterior do istio-ingressgateway.
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
4. Exclua a revisão istiod antiga. No comando a seguir, substitua OLD_REVISION pelo rótulo de revisão da versão anterior de istiod.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
5. Remova a configuração IstioOperator antiga.
  kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
  A saída esperada terá esta aparência:
  istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
Reversão
Se você encontrou um problema ao testar o aplicativo com a nova revisão istiod, siga estas etapas para reverter para a revisão anterior:
1. Siga as etapas emUpgrades no local para fazer downgrade das implantações de gateway com upgrade anteriormenteetapa 6 desta seção a revisão mais antigaREVISION_1 de dados.
2. Rotule seu namespace novamente para ativar a injeção automática com a revisão istiod anterior.
  kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
  Saída esperada:
  namespace/NAMESPACE labeled
3. Confirme se o rótulo de revisão no namespace corresponde ao rótulo de revisão na versão anterior de istiod:
  kubectl get ns NAMESPACE --show-labels
4. Reinicie os pods para acionar a nova injeção de modo que os proxies tenham a versão do Istio:
  kubectl rollout restart deployment -n NAMESPACE
5. Remova a nova implantação istio-ingressgateway.
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
6. Remova a nova versão de istiod. Certifique-se de que o rótulo de revisão no comando a seguir corresponda à sua revisão.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
7. Remova a nova versão da configuração IstioOperator.
  kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
  A saída esperada será assim:
  istiooperator.install.istio.io "installed-state-REVISION_2" deleted

Remover os secrets da CA e reiniciar o novo plano de controle

Preserve os secrets caso seja necessário:

kubectl get secret/cacerts -n istio-system -o yaml > save_file_1
kubectl get secret/istio-ca-secret -n istio-system -o yaml > save_file_2

Remova os secrets da CA no cluster associado à CA antiga:

kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found

Reinicie o plano de controle recém-instalado. Isso garante que a raiz de confiança antiga seja excluída de todas as cargas de trabalho em execução na malha.
```
kubectl rollout restart deployment -n istio-system
```

Migração com base canário para a CA da malha

Limitações

Pré-requisitos

Ferramentas necessárias

Visão geral da migração

Distribuir a raiz de confiança de CA da malha

Instalar uma nova revisão do plano de controle

Migrar cargas de trabalho para o novo plano de controle

Concluir a transição

Migrar

Fazer upgrade

Migrar

Fazer upgrade

Reversão

Migrar para a CA da malha

Instalar um novo plano de controle com a CA da malha ativada

Migrar cargas de trabalho para o novo plano de controle

Concluir a transição

Reversão

Remover os secrets da CA e reiniciar o novo plano de controle