Versão 1.14

Migração de CA no local

Se sua malha tiver vários clusters com cargas de trabalho que enviam solicitações para cargas de trabalho em outro cluster, siga todas as etapas neste guia para todos os clusters.

Siga as etapas deste guia para os casos de uso a seguir:

  • Migrar um plano de controle do Anthos Service Mesh v1.13 ou posterior no cluster com a CA da malha para o Certificate Authority Service.
  • Migre um plano de controle gerenciado do Anthos Service Mesh em um canal de lançamento que é mapeado para a v1.13 ou posterior com a CA da malha para o Certificate Authority Service.

Limitações

As migrações e upgrades de CA no local só são compatíveis com o Anthos Service Mesh v1.13 ou mais recente. Para migrações gerenciadas do plano de controle, verifique se o canal escolhido é mapeado para a v1.13 ou posterior.

Prerequisites

Antes de seguir as etapas deste guia, verifique se você:

Além disso, verifique se você está usando o Anthos Service Mesh v1.13 ou posterior.

Ferramentas necessárias

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

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

Antes de fazer o download da ferramenta migrate_ca, siga as etapas em Preparar-se para a migração.

Visão geral da migração

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 anterior e as cargas de trabalho que usam a nova CA.

A ferramenta de migração migrate_ca criará um mapa de configuração do Kubernetes para rastrear o status da migração da CA por revisão/canal do Anthos Service Mesh instalado. Esse é um recurso privilegiado instalado no namespace 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 fará backup do mapa de configuração do Istio MeshConfig antes de alterá-lo. Além disso, ela tentará migrar a configuração da CA usando o CRD ProxyConfig sempre que possível.

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

  1. Preparo para a migração.

  2. Inicializar a nova CA.

  3. Adição de TrustedAnchors em toda a malha para todos os clusters da frota.

  4. Migrar a CA.

  5. Fazer uma reversão.

Preparo para a migração

  1. Faça o download da ferramenta bash migrate_ca:

    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
    
  4. Altere o diretório de trabalho para o OUTPUT_DIR especificado na etapa anterior.

    cd OUTPUT_DIR
    
  5. Execute o comando a seguir para garantir que todos os pré-requisitos sejam atendidos:

    ./migrate_ca check-prerequisites
    
  6. Anote a revisão (ASM_REVISION) do plano de controle associado à CA anterior que está sendo migrada. As etapas necessárias dependem do tipo de plano de controle, seja no cluster ou gerenciado.

    No cluster

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

    Grupo

    Consulte o canal já instalado.

  7. Como a migração da CA no local exige que você reinicie as cargas de trabalho, verifique se o Orçamento de interrupção do pod está configurado corretamente, e todos os aplicativos com a CA que precisa ser migrada têm mais de um pod em execução.

  8. Verifique se o cluster já está registrado em uma frota e se a identidade da carga de trabalho está ativada no cluster. Em seguida, anote o ID do projeto da frota como (FLEET_ID) para etapas futuras.

  9. A ferramenta aceita kubeConfig e kubeContext para selecionar o cluster em que as operações são realizadas. Se esses argumentos não forem transmitidos, o contexto/configuração padrão será usado.

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

      gcloud container clusters get-credentials CLUSTER_NAME
      
    • Para mudar o contexto kubectl atual ou transmitir o contexto para a ferramenta, use o seguinte comando:

      kubectl config get-contexts
      kubectl config use-context CLUSTER_NAME
      

Inicializar a nova CA

  1. As etapas necessárias para inicializar a nova CA dependem da nova CA para a qual você está migrando. Execute essas etapas em cada cluster de frota para onde você quer migrar a CA.

    CA da malha

    Chame o subcomando initialize da ferramenta de utilitário.

    Se você estiver especificando configurações personalizadas do Kubernetes, faça o seguinte:

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

    Se esse não for seu caso, faça o seguinte:

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

    Serviço de CA

    a. Siga as etapas necessárias para inicializar o Certificate Authority Service. Anote o CA_POOL.

    b. Chame o subcomando initialize da ferramenta de utilitário:

    Se você estiver especificando configurações personalizadas do Kubernetes, faça o seguinte:

     ./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
    

    Se esse não for seu caso, faça o seguinte:

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

Adição de TrustedAnchors em toda a malha para todos os clusters da frota.

  1. Repita as etapas abaixo para a nova CA e para a CA antiga para todos os clusters que fazem parte da frota.

  2. Faça o download doTrustAnchors da CA:

    CA da malha

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

    Serviço de CA

    Armazene o certificado da CA em um arquivo:

    gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
    
  3. Adição de TrustedAnchors da CA:

    ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
    
  4. Verifique se os trustedAnchors foram recebidos por todas as cargas de trabalho na frota. No argumento de namespaces, transmita todos os namespaces em que as cargas de trabalho são implantadas:

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

    Resposta esperada:

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

Migrar a CA

  1. Migrar a configuração da CA. O comando necessário depende da nova CA para a qual você está migrando.

    CA da malha

    ./migrate_ca migrate-ca --ca mesh_ca
    

    Serviço de CA

    ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
    
  2. Reiniciar todas as cargas de trabalho.

    Para minimizar o risco de inatividade do tráfego TLS, esta etapa precisa afetar o menor número de cargas de trabalho primeiro. Reinicie somente as cargas de trabalho associadas à revisão do plano de controle ASM_REVISION. Por exemplo, se todas as cargas de trabalho no namespace NAMESPACE do Kubernetes estiverem associadas ao mesmo plano de controle do Anthos Service Mesh.

    kubectl rollout restart deployment -n NAMESPACE
    
  3. Verifique se as conexões mTLS funcionam entre as cargas de trabalho no namespace reiniciado e outras cargas de trabalho antes de repetir as etapas 1 e 2 para todos os namespaces e para todos os clusters que fazem parte da frota. Se novas cargas de trabalho estiverem chegando e o tráfego da malha não for interrompido, repita as etapas 1 e 2 para todos os namespaces e clusters que fazem parte da frota. Caso contrário, prossiga para a reversão da configuração mais recente da CA.

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

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

    Resposta esperada:

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

Fazer uma reversão

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

    ./migrate-ca rollback
    
  2. Reiniciar todas as cargas de trabalho. Reinicie apenas as cargas de trabalho associadas à revisão do plano de controle ASM_REVISION. Por exemplo, se todas as cargas de trabalho no namespace NAMESPACES do Kubernetes estiverem associadas ao mesmo plano de controle do Anthos Service Mesh.

    kubectl rollout restart deployment -n NAMESPACES
    
  3. (Opcional) Verifique se a configuração da CA mais antiga está sendo usada por todas as cargas de trabalho.

    ./migrate-ca verify-ca --ca_cert older-root-cert.pem
    
  4. Repita as etapas 1 a 3 para todos os clusters na frota em que as cargas de trabalho usam o plano de controle ASM_REVISION.

Parabéns! Você executou uma migração da CA no local.