Migração de CA no local

Nota: este guia descreve como migrar a sua autoridade de certificação (AC) sem migrar cargas de trabalho para um novo plano de controlo (no local) com um tempo de inatividade mínimo através de uma ferramenta baseada em bash. Para migrar da CA do Istio para a CA da malha com uma abordagem baseada em testes canários que envolve uma inatividade mínima ou nula, consulte o artigo Migração baseada em testes canários para a CA da malha.

Se a sua malha tiver vários clusters com cargas de trabalho que enviam pedidos para cargas de trabalho noutro cluster, siga todos os passos neste guia para todos os clusters.

Use os passos neste guia para o seguinte exemplo de utilização:

• Migre um plano de controlo do Cloud Service Mesh v1.13 ou posterior no cluster com a AC da malha para o serviço de autoridade de certificação.
• Migre um plano de controlo do Cloud Service Mesh gerido num canal de lançamento que mapeia para a versão 1.13 ou posterior com a CA da malha para o serviço de autoridade de certificação.

Limitações

As migrações e as atualizações de CA no local só são suportadas a partir do Cloud Service Mesh v1.13 ou posterior. Para migrações do plano de controlo gerido, certifique-se de que o canal escolhido é mapeado para a versão 1.13 ou posterior.

Pré-requisitos

Antes de seguir os passos neste guia, certifique-se de que tem:

• Autorizações de administrador do cluster concedidas
• Configurado gcloud

Além disso, certifique-se de que está atualmente no Cloud Service Mesh v1.13 ou posterior.

Ferramentas necessárias

Durante a migração, executa uma ferramenta fornecida pela Google, migrate_ca. Esta ferramenta tem as seguintes dependências:

• awk
• grep
• jq
• kubectl
• head
• sed
• tr
• yq

Antes de transferir a ferramenta migrate_ca, siga os passos em Prepare-se para a migração.

Vista geral da migração

Durante o processo de migração, a autenticação e a autorização são totalmente funcionais entre cargas de trabalho que usam a AC anterior e cargas de trabalho que usam a nova AC.

A ferramenta de migração migrate_ca cria um mapa de configuração do Kubernetes para acompanhar o estado da migração da AC por revisão/canal do Cloud Service Mesh instalado. Este é um recurso privilegiado instalado no espaço de nomes istio-system.

apiVersion: v1
kind: ConfigMap
metadata:
  Name: asm-ca-migration-<revision>
Data:
  revision:
  start_time:
  state_update_time:
  current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
  old_ca:
  target_ca:

A ferramenta de migração faz uma cópia de segurança do mapa de configuração do Istio MeshConfig antes de o alterar e tenta migrar a configuração da AC através do CRD ProxyConfig quando possível.

Segue-se um resumo da migração da CA:

Nota: tem de executar os passos de migração em cada cluster na sua malha.

1. Prepare-se para a migração.

2. Inicialize a nova AC.

3. Adicione trustAnchors ao nível da malha para todos os clusters na frota.

4. Migre a CA.

5. Faça uma reversão.

Prepare-se para a migração

1. Transfira a migrate_ca ferramenta bash:

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

2. Torne a ferramenta executável:

   chmod +x migrate_ca
   

3. Configure o diretório de trabalho:

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   Nota: se não especificar um diretório de trabalho, é criado um diretório temporário. Tem de o usar como diretório de trabalho para todos os passos subsequentes.

4. Altere o diretório de trabalho para o OUTPUT_DIR especificado no passo anterior

   cd OUTPUT_DIR
   

5. Execute o seguinte comando para garantir que todos os pré-requisitos são cumpridos:

   ./migrate_ca check-prerequisites
   

6. Tome nota da revisão (ASM_REVISION) do plano de controlo associado à AC anterior que está a ser migrada. Os passos necessários dependem do tipo de plano de controlo, seja no cluster ou gerido.

   No cluster

   asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \
    "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")
   

   Gerido

   Consulte o canal já instalado.

7. Uma vez que a migração da AC no local requer o reinício das cargas de trabalho, certifique-se de que o orçamento de interrupção de pods está configurado corretamente e que todas as aplicações cuja AC precisa de ser migrada têm mais do que um pod em execução.

8. Certifique-se de que o cluster já está registado numa frota e que a identidade da carga de trabalho está ativada no cluster. Em seguida, tome nota do ID do projeto da frota como (FLEET_ID) para passos futuros.

9. A ferramenta aceita kubeConfig e kubeContext para selecionar o cluster onde as operações são realizadas. Se estes argumentos não forem transmitidos, são usados o contexto/configuração predefinidos.

   • Para adicionar as credenciais de um cluster do GKE ao kubeConfig, use o seguinte comando:

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • Para alterar o contexto kubectl atual ou transmitir contexto à ferramenta, use o seguinte comando:

     kubectl config get-contexts
     kubectl config use-context CLUSTER_NAME
     

Inicialize a nova CA

1. Os passos necessários para inicializar a nova AC dependem da nova AC para a qual está a migrar. Execute estes passos em todos os clusters da frota onde quer migrar a AC.

   Mesh CA

   Chame o subcomando initialize da ferramenta de utilidade.

   Se estiver a especificar configurações personalizadas do Kubernetes:

    ./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
   

   Caso contrário:

    ./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
    ```
   

   Serviço de AC

   a. Siga os passos necessários para inicializar o serviço de autoridade de certificação. Tome nota do CA_POOL.

   b. Chame o subcomando initialize da ferramenta de utilidade:

   Se estiver a especificar configurações personalizadas do Kubernetes:

    ./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
    --fleet-id FLEET_ID --revision ASM_REVISION
   

   Caso contrário:

     ./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
     --fleet-id FLEET_ID --revision ASM_REVISION
   

Adicione trustAnchors ao nível da malha para todos os clusters na frota

1. Repita os passos abaixo para a nova e a antiga AC para todos os clusters que fazem parte da frota.

2. Transfira os trustAnchors da AC:

   Mesh CA

   ./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pem
   

   Serviço de AC

   Armazene o certificado da CA num ficheiro:

   gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
   

3. Adicione trustAnchors da AC:

   ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
   

4. Verifique se os trustAnchors foram recebidos por todas as cargas de trabalho na frota. No argumento namespaces, transmita todos os espaços de nomes onde as cargas de trabalho estão implementadas:

   ./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Resultado esperado:

   Check the CA cert in namespace nsa-1-24232                                                                                                                               
   a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
   

Migre a AC

1. Migre a configuração da CA. O comando necessário depende da AC para a qual está a migrar.

   Mesh CA

   ./migrate_ca migrate-ca --ca mesh_ca
   

   Serviço de AC

   ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
   

2. Reinicie todas as cargas de trabalho.

   Nota: este passo é opcional se tiver instalado o plano de dados gerido. Isto deve-se ao facto de a Google gerir os tempos de vida dos proxies e realizar automaticamente este passo durante uma atualização gerida.

   Para minimizar o risco de indisponibilidade do tráfego TLS, este passo deve afetar primeiro o menor número de cargas de trabalho. Reinicie apenas as cargas de trabalho associadas à revisão do plano de controlo ASM_REVISION. Por exemplo, se todas as cargas de trabalho no namespace do Kubernetes NAMESPACE estiverem associadas ao mesmo plano de controlo do Cloud Service Mesh.

   kubectl rollout restart deployment -n NAMESPACE
   

3. Verifique se as ligações mTLS funcionam entre as cargas de trabalho no espaço de nomes reiniciado e outras cargas de trabalho antes de repetir os passos 1 e 2 para todos os espaços de nomes e para todos os clusters que fazem parte da frota. Se surgirem cargas de trabalho mais recentes e o tráfego de malha não for interrompido, repita os passos 1 e 2 para todos os espaços de nomes e clusters que fazem parte da frota. Caso contrário, avance para fazer uma reversão para reverter a configuração da AC mais recente.

4. Verifique se a nova configuração da AC está a ser usada por todas as cargas de trabalho:

   ./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Resultado esperado:

   Check the CA configuration in namespace nsb-2-76095
   b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
   

Faça uma reversão

1. Reverta a configuração da AC e remova os trustAnchors recém-configurados:

   ./migrate-ca rollback
   

2. Reinicie todas as cargas de trabalho. Certifique-se de que reinicia apenas as cargas de trabalho associadas à revisão do plano de controlo ASM_REVISION. Por exemplo, se todas as cargas de trabalho no namespace do Kubernetes NAMESPACES estiverem associadas ao mesmo plano de controlo do Cloud Service Mesh.

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Opcional) Verifique se a configuração da AC mais antiga está a ser usada por todas as cargas de trabalho.

   ./migrate-ca verify-ca --ca_cert older-root-cert.pem
   

4. Repita os passos 1 a 3 para todos os clusters na frota onde as cargas de trabalho usam o plano de controlo ASM_REVISION.

Parabéns! Migrou com êxito uma AC no local.