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.
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
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:
Receba uma lista de pods de um dos namespaces:
kubectl get pods -n NAMESPACE
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
.