Planejar um upgrade

Nesta página, você encontra informações para ajudar a planejar um upgrade do Cloud Service Mesh. Recomendamos que você também consulte as notas de upgrade do Istio.

Sobre upgrades canário

Recomendamos que você faça upgrade do Cloud Service Mesh executando primeiro uma implantação canário do novo plano de controle. Com um upgrade canário, asmcli instala uma nova revisão do plano de controle junto com o plano de controle antigo. Os planos de controle antigo e novo são rotulados com um rótulo revision, que serve como identificador dos planos de controle.

para migrar cargas de trabalho para o novo plano de controle:

  1. Defina o rótulo revision do novo plano de controle em um dos namespaces.

  2. Faça uma reinicialização gradual. A reinicialização reinjeta os proxies sidecar nos pods para que os proxies usem o novo plano de controle.

  3. Monitore o efeito do upgrade nas cargas de trabalho. Se necessário para testar o aplicativo, repita as etapas anteriores.

  4. Depois de testar o aplicativo, será possível migrar todo o tráfego para o novo plano de controle ou reverter para o plano de controle antigo.

Um upgrade canário é muito mais seguro do que um upgrade no local em que o novo plano de controle substitui o plano antigo. Para ver as etapas detalhadas, consulte Mudar para o novo plano de controle.

Personalizar o plano de controle

Se você personalizou a instalação anterior, precisará das mesmas personalizações ao fazer upgrade do Cloud Service Mesh. Se você tiver personalizado a instalação adicionando a sinalização --set values em istioctl install, será necessário adicionar essas configurações a um arquivo YAML IstioOperator, chamado de arquivo de sobreposição. Para especificar o arquivo de sobreposição, use a opção --custom_overlay com o nome de arquivo ao executar asmcli.

O pacote anthos-service-mesh no GitHub contém muitos arquivos de sobreposição. Esses arquivos contêm personalizações comuns da configuração padrão. É possível usar esses arquivos como estão ou fazer outras alterações neles conforme necessário. Alguns dos arquivos são necessários para ativar os recursos opcionais do Cloud Service Mesh. O pacote anthos-service-mesh é transferido por download ao executar asmcli para validar o projeto e o cluster.

Ao instalar o Cloud Service Mesh usando asmcli install, é possível especificar um ou mais arquivos de sobreposição com --option ou --custom_overlay. Caso você não precise fazer mudanças nos arquivos no repositório anthos-service-mesh, use --option e o script buscará o arquivo no GitHub para você. Caso contrário, você pode fazer alterações no arquivo de sobreposição e usar a opção --custom_overlay para passá-la para asmcli.

Escolher uma autoridade de certificação

Se a instalação atual do Cloud Service Mesh usar a autoridade certificadora do Cloud Service Mesh (CA) como autoridade para emitir certificados de TLS mútuo (mTLS), recomendamos que você continue usando a autoridade certificadora do Cloud Service Mesh pelos seguintes motivos:

  • A autoridade de certificação do Cloud Service Mesh é um serviço altamente confiável e escalonável, otimizado para cargas de trabalho escalonadas dinamicamente.
  • Com a autoridade de certificação do Cloud Service Mesh, o Google gerencia a segurança e a disponibilidade do back-end da AC.
  • A autoridade certificadora do Cloud Service Mesh permite contar com uma única raiz de confiança entre os clusters.

Se a instalação atual do Cloud Service Mesh usar a CA do Istio (anteriormente chamada de "Citadel"), será possível alternar para a autoridade de certificação do Cloud Service Mesh ao fazer upgrade, mas você precisará programar o tempo de inatividade. Durante o upgrade, o tráfego mTLS é interrompido até que todas as cargas de trabalho sejam alternadas para o novo plano de controle com a autoridade certificadora do Cloud Service Mesh.

Os certificados da autoridade certificadora do Cloud Service Mesh incluem os seguintes dados sobre os serviços do aplicativo:

  • O ID do projeto do Google Cloud
  • O namespace do GKE
  • O nome da conta de serviço do GKE

Como identificar sua CA

Ao executar asmcli install para fazer upgrade, especifique a CA que asmcli deve ativar no novo plano de controle.

A alteração de CAs causa inatividade quando as cargas de trabalho de implantação são feitas no novo plano de controle. Se não for possível programar o tempo de inatividade, especifique a mesma CA para o novo plano de controle que o plano de controle antigo usa. Se você não tiver certeza de qual CA está ativada na sua malha, execute os seguintes comandos:

  1. Receba uma lista de pods de um dos namespaces:

    kubectl get pods -n NAMESPACE

  2. Substitua POD_NAME pelo nome de um dos pods no seguinte comando:

    kubectl get pod POD_NAME -n NAMESPACE -o yaml | grep CA_ADDR -A 1

    Se a autoridade certificadora do Cloud Service Mesh estiver ativada no namespace, você verá a seguinte saída:

    - name: CA_ADDR
  value: meshca.googleapis.com:443

Preparar a configuração do gateway

O Cloud Service Mesh oferece a opção de implantar e gerenciar gateways como parte da malha de serviço. Um gateway descreve um balanceador de carga operando na borda da malha que recebe conexões HTTP/TCP de entrada ou saída. Os gateways são proxies Envoy que fornecem um controle refinado sobre o tráfego que entra e sai da malha.

O app asmcli não instala o istio-ingressgateway. Recomendamos que você implante e gerencie o plano de controle e os gateways separadamente. Para mais informações, consulte Como instalar e fazer upgrade de gateways.

Fazer upgrade da sua plataforma (opcional)

Como prática recomendada, faça upgrade do Cloud Service Mesh para a versão mais recente compatível que também é compatível com sua plataforma atual. Em seguida, faça upgrade do ambiente para que ele esteja dentro do intervalo de plataformas compatíveis e versões do Kubernetes. Por fim, se necessário, faça upgrade para a versão com suporte mais recente do Cloud Service Mesh.

A seguir