Planeie uma atualização

Nota: este guia só suporta a malha de serviços na nuvem com APIs Istio e não suporta Google Cloud APIs. Para mais informações, consulte o artigo Vista geral do Cloud Service Mesh.

Esta página fornece informações para ajudar a planear uma atualização do Cloud Service Mesh. Recomendamos que reveja também as notas de atualização do Istio.

Acerca das atualizações de teste

Recomendamos que atualize o Cloud Service Mesh executando primeiro uma implementação canary do novo plano de controlo. Com uma atualização canary, o asmcliinstala uma nova revisão do plano de controlo juntamente com o plano de controlo antigo. Os planos de controlo antigos e novos estão etiquetados com uma etiqueta revision, que serve como identificador dos planos de controlo.

Para migrar cargas de trabalho para o novo plano de controlo:

1. Defina a etiqueta revision do novo plano de controlo num dos seus espaços de nomes.

2. Faça um reinício progressivo. O reinício injeta novamente os proxies sidecar nos pods para que os proxies usem o novo plano de controlo.

3. Monitorize o efeito da atualização nas cargas de trabalho. Se precisar de testar a sua aplicação, repita os passos anteriores.

4. Depois de testar a sua aplicação, pode migrar todo o tráfego para o novo plano de controlo ou reverter para o plano de controlo antigo.

Uma atualização canary é muito mais segura do que uma atualização no local, em que o novo plano de controlo substitui o antigo. Para ver passos detalhados, consulte o artigo Mude para o novo plano de controlo.

Aviso: as atualizações no local não são suportadas e a realização de uma atualização no local para a versão 1.24 vai causar tempo de inatividade devido a uma alteração interruptiva no fornecedor de certificados de teste. Se fizer uma atualização no local, todas as cargas de trabalho têm de ser reimplementadas após a atualização para estabelecer ligação ao plano de controlo.

Personalize o plano de controlo

Se personalizou a instalação anterior, precisa das mesmas personalizações quando atualizar o Cloud Service Mesh. Se personalizou a instalação adicionando a flag --set values a istioctl install, tem de adicionar essas definições a um ficheiro YAML IstioOperator, denominado ficheiro de sobreposição. Especifica o ficheiro de sobreposição através da opção --custom_overlay com o nome do ficheiro quando executa asmcli.

Atenção: se omitir o ficheiro de sobreposição, a instalação é bem-sucedida. No entanto, a sua malha de serviços tem uma configuração diferente da pretendida, porque os valores omitidos são repostos para os predefinidos quando o plano de controlo é novamente implementado.

O diretório asmcli no GitHub contém muitos ficheiros de sobreposição. Estes ficheiros contêm personalizações comuns à configuração predefinida. Pode usar estes ficheiros tal como estão ou fazer alterações adicionais conforme necessário. Alguns dos ficheiros são necessários para ativar funcionalidades opcionais da malha de serviços na nuvem. O pacote anthos-service-mesh é transferido quando executa asmcli para validar o seu projeto e cluster.

Quando instala o Cloud Service Mesh através do asmcli install, pode especificar um ou mais ficheiros de sobreposição com o --option ou o --custom_overlay. Se não precisar de fazer alterações aos ficheiros no repositório anthos-service-mesh, pode usar --option, e o script obtém o ficheiro do GitHub por si. Caso contrário, pode fazer alterações ao ficheiro de sobreposição e, em seguida, usar a opção --custom_overlay para o transmitir ao asmcli.

Escolha uma autoridade de certificação

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

• A autoridade de certificação do Cloud Service Mesh é um serviço altamente fiável e escalável que está otimizado para cargas de trabalho dimensionadas dinamicamente.
• Com a autoridade de certificação da Cloud Service Mesh, a Google gere a segurança e a disponibilidade do back-end da AC.
• A autoridade de certificação do Cloud Service Mesh permite-lhe confiar numa única raiz de confiança em todos os clusters.

Se a sua instalação atual do Cloud Service Mesh usar a AC do Istio (anteriormente denominada "Citadel"), pode mudar para a autoridade de certificação do Cloud Service Mesh quando fizer a atualização, mas tem de agendar um período de inatividade. Durante a atualização, o tráfego mTLS é interrompido até que todas as cargas de trabalho sejam comutadas para a utilização do novo plano de controlo com a autoridade de certificação do Cloud Service Mesh.

Nota da plataforma: o serviço de AC só é suportado nas seguintes plataformas: clusters do GKE no Google Cloud, Google Distributed Cloud (apenas software) para VMware e Distributed Cloud. Se executar o comando asmcli install e especificar --ca gcp_cas noutras plataformas, a instalação é apresentada como bem-sucedida, mas as suas cargas de trabalho não são iniciadas.

Os certificados da autoridade de certificação do Cloud Service Mesh incluem os seguintes dados acerca dos serviços da sua aplicação:

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

Importante: os certificados emitidos pela autoridade de certificação do Cloud Service Mesh só devem ser usados para ativar a comunicação segura entre serviços na sua malha de serviços e não devem ser usados para qualquer outro fim. Estes certificados são enviados sempre que os serviços tentam comunicar entre si através do TLS mútuo. Certifique-se de que não expõe inadvertidamente informações confidenciais através da utilização destes certificados quando comunica fora da sua malha de serviços.

Identificar a sua AC

Quando executa asmcli install para fazer a atualização, especifica a AC que asmcli deve ativar no novo plano de controlo.

A alteração das ACs provoca indisponibilidade quando implementa cargas de trabalho no novo plano de controlo. Se não conseguir agendar o tempo de inatividade, certifique-se de que especifica a mesma CA para o novo plano de controlo que o plano de controlo antigo usa. Se não tiver a certeza de qual CA está ativada na sua rede de malha, execute os seguintes comandos:

1. Obtenha uma lista de pods de um dos seus espaços de nomes:

   kubectl get pods -n NAMESPACE
   

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

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

   Se a autoridade de certificação do Cloud Service Mesh estiver ativada no espaço de nomes, é apresentado o seguinte resultado:

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

Prepare a configuração do gateway

O Cloud Service Mesh dá-lhe a opção de implementar e gerir gateways como parte da sua malha de serviços. Um gateway descreve um balanceador de carga que opera no limite da malha e recebe ligações HTTP/TCP de entrada ou saída. As gateways são proxies Envoy que lhe oferecem um controlo detalhado sobre o tráfego que entra e sai da malha.

O asmcli não instala o istio-ingressgateway. Recomendamos que implemente e faça a gestão do plano de controlo e das gateways separadamente. Para mais informações, consulte o artigo Instalar e atualizar gateways.

Atualize a sua plataforma (opcional)

Como prática recomendada, deve atualizar o Cloud Service Mesh para a versão suportada mais recente que também seja compatível com a sua plataforma atual. Em seguida, atualize o seu ambiente para que esteja dentro do intervalo de plataformas e versões do Kubernetes suportadas. Por último, se necessário, atualize para a versão suportada mais recente do Cloud Service Mesh.

O que se segue?

• Instale ferramentas dependentes e valide clusters