Planejar um upgrade

Visualização — asmcli

Esse recurso está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos de serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Nesta página, você encontra informações para ajudar a planejar um upgrade do Anthos 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 Anthos 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.

Em seguida, migre as cargas de trabalho para o novo plano de controle definindo o mesmo rótulo revision nos seus namespaces e executando uma reinicialização gradual. A reinicialização reinjeta os proxies sidecar nos pods para que os proxies usem o novo plano de controle. Com essa abordagem, é possível monitorar o efeito do upgrade em uma pequena porcentagem das cargas de trabalho. 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. Essa abordagem é muito mais segura do que realizar um upgrade no local em que o novo plano de controle substitui o plano antigo.

Para essa visualização inicial, asmcli instala o istio-ingressgateway com um rótulo de revisão por padrão. Isso permite que você faça um upgrade canário do istio-ingressgateway, bem como do plano de controle.

Personalizar o plano de controle

Se você personalizou a instalação anterior, precisará das mesmas personalizações ao migrar ou fazer upgrade para o Anthos 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. Especifique o arquivo de sobreposição usando a opção --custom_overlay com o nome de arquivo ao executar o script.

Atenção: omitir o arquivo de sobreposição resulta em uma instalação bem-sucedida. No entanto, a malha de serviço tem uma configuração diferente da pretendida porque os valores omitidos são redefinidos para os padrões quando o plano de controle e o gateway de entrada são reimplantados.

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 Anthos Service Mesh. O pacote anthos-service-mesh é transferido por download ao executar asmcli para validar o projeto e o cluster.

Ao instalar o Anthos Service Mesh com 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 Anthos Service Mesh usar a autoridade de certificação do Anthos Service Mesh (Mesh CA) como autoridade de certificação (CA) para emitir certificados de TLS mútuo (mTLS), recomendamos que você continue usando a CA da malha pelos seguintes motivos:

• A Mesh CA é um serviço altamente confiável e escalonável, otimizado para cargas de trabalho escalonadas dinamicamente no Google Cloud.
• Com ela, o Google gerencia a segurança e a disponibilidade do back-end da CA.
• Esta autoridade de certificação possibilita confiar em uma única raiz de confiança entre os clusters.

Se a instalação atual do Anthos Service Mesh usar a CA do Istio (anteriormente chamada de "Citadel"), será possível alternar para a CA da malha 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 Mesh CA.

Os certificados do Mesh CA 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

Importante: os certificados emitidos pelo Mesh CA só devem ser usados para permitir a comunicação segura entre serviços dentro da malha de serviço. Não os use para qualquer outra finalidade. Esses certificados são enviados sempre que os serviços tentam se comunicar usando a TLS mútua. Ao usar esses certificados para se comunicar fora da malha de serviço, certifique-se de não expor informações confidenciais inadvertidamente.

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 CA da malha 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 Anthos 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.

Por padrão, 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. Se você precisar do istio-ingressgateway padrão instalado com o plano de controle no cluster, inclua o argumento --option legacy-default-ingressgateway.

A seguir

• Primeiros passos