Como fazer downgrade do Anthos Service Mesh no GKE

Neste guia, explicamos como fazer downgrade do Anthos Service Mesh de 1.5.10 para 1.4.10 no Google Kubernetes Engine.

Cuidado: o downgrade é uma ação que causa interrupção no cluster, e você precisa se planejar adequadamente.

A reimplantação dos componentes do plano de controle do Anthos Service Mesh leva cerca de 5 a 10 minutos para ser concluída. Além disso, é necessário injetar novos proxies sidecar em todas as cargas de trabalho para que eles sejam atualizados com a versão atual do Anthos Service Mesh. O tempo necessário para atualizar os proxies sidecar depende de muitos fatores, como o número de pods, o número de nós, as configurações de escalonamento da implantação, os orçamentos de interrupção dos pods e outras definições de configuração. Uma estimativa aproximada do tempo necessário para atualizar os proxies sidecar é de 100 pods por minuto.

Visão geral do downgrade

Nesta seção, descrevemos as etapas necessárias para fazer downgrade do Anthos Service Mesh.

1. Veja os Recursos compatíveis e este guia para conhecer os recursos e o processo de downgrade.

2. Se você ativou recursos opcionais ao instalar a versão anterior do Anthos Service Mesh, precisa ativar os mesmos recursos quando fizer o downgrade. Para ativar recursos opcionais, adicione sinalizações --set values ou especifique a sinalização -f com um arquivo YAML ao executar o comando istioctl apply.

   Cuidado: omitir as sinalizações --set values ou -f com o arquivo YAML faz com que a instalação seja bem-sucedida. No entanto, ela tem uma configuração diferente da que você pretendia, porque os valores omitidos são redefinidos para os padrões quando o Anthos Service Mesh é reimplantado. É necessário usar as mesmas sinalizações ao executar istioctl apply para fazer downgrade para 1.5.10.

   Se você estiver fazendo downgrade do Anthos Service Mesh1.5.10 à 1.4.10 e, além disso, tiver ativado os recursos opcionais em um arquivo YAML, precisa converter o YAML da API IstioOperator para o API IstioControlPlane.

3. Se você estiver fazendo downgrade novamente para 1.4.10 em um cluster particular, será necessário adicionar uma regra de firewall para abrir a porta 9443 se quiser usar a injeção automática de sidecar. Se você não adicionar a regra de firewall e a injeção automática de sidecar estiver ativada, receberá um erro ao implantar as cargas de trabalho. Saiba mais sobre como adicionar uma regra de firewall em Como adicionar regras de firewall para casos de uso específicos.

4. Programar um tempo de inatividade. O downgrade pode levar até uma hora, dependendo da escala do cluster. Isso não inclui o tempo necessário para reimplantar cargas de trabalho a fim de atualizar proxies secundários.

Como configurar padrões de projeto e cluster

1. Acesse o ID do projeto em que o cluster foi criado:

   gcloud

   gcloud projects list

   Console

   1. No console do Google Cloud, abra a página Painel.

      Ir para a página "Painel"

   2. Clique na lista suspensa Selecionar de na parte superior da página. Na janela Selecionar de exibida, selecione seu projeto. O ID do projeto é exibido no card Informações do projeto do Painel.

2. Crie uma variável de ambiente para o ID do projeto:

   export PROJECT_ID=YOUR_PROJECT_ID

3. Defina o ID do projeto padrão para a Google Cloud CLI:

   gcloud config set project ${PROJECT_ID}
   

4. Crie as variáveis de ambiente a seguir:

   • Defina o nome do cluster:

     export CLUSTER_NAME=YOUR_CLUSTER_NAME

   • Defina CLUSTER_LOCATION como a zona ou a região do cluster:

     export CLUSTER_LOCATION=YOUR_ZONE_OR_REGION

5. Defina a zona ou a região padrão da Google Cloud CLI.

   • Se você tiver um cluster de zona única, defina a zona padrão:

     gcloud config set compute/zone ${CLUSTER_LOCATION}

   • Se você tiver um cluster regional, defina a região padrão:

     gcloud config set compute/region ${CLUSTER_LOCATION}

Como configurar credenciais e permissões

1. Receba credenciais de autenticação para interagir com o cluster:

   gcloud container clusters get-credentials ${CLUSTER_NAME}

2. Conceda permissões de administrador de cluster ao usuário atual. Você precisa dessas permissões para criar as regras necessárias de controle de acesso baseado em papéis (RBAC, na sigla em inglês) para o Anthos Service Mesh:

   kubectl create clusterrolebinding cluster-admin-binding \
     --clusterrole=cluster-admin \
     --user="$(gcloud config get-value core/account)"

   Se você vir o erro "cluster-admin-binding" already exists, poderá ignorá-lo com segurança e continuar com o cluster-admin-binding atual.

Como fazer o download do arquivo de instalação

Linux

Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-linux.tar.gz

Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-linux.tar.gz.1.sig
openssl dgst -verify - -signature istio-1.4.10-asm.18-linux.tar.gz.1.sig istio-1.4.10-asm.18-linux.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

A saída esperada é Verified OK.

Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:

tar xzf istio-1.4.10-asm.18-linux.tar.gz

O comando cria um diretório de instalação no seu diretório de trabalho atual chamado istio-1.4.10-asm.18, que contém:

• aplicativos de amostra em samples;
• As seguintes ferramentas no diretório bin:
  • istioctl: use istioctl para instalar o Anthos Service Mesh.
  • asmctl: use asmctl para ajudar a validar sua configuração de segurança depois de instalar o Anthos Service Mesh. No momento, asmctl não é compatível com o GKE no VMware.

Mac OS

Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-osx.tar.gz

Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.4.10-asm.18-osx.tar.gz.1.sig istio-1.4.10-asm.18-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

A saída esperada é Verified OK.

Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:

tar xzf istio-1.4.10-asm.18-osx.tar.gz

O comando cria um diretório de instalação no seu diretório de trabalho atual chamado istio-1.4.10-asm.18, que contém:

• aplicativos de amostra em samples;
• As seguintes ferramentas no diretório bin:
  • istioctl: use istioctl para instalar o Anthos Service Mesh.
  • asmctl: use asmctl para ajudar a validar sua configuração de segurança depois de instalar o Anthos Service Mesh. No momento, asmctl não é compatível com o GKE no VMware.

Windows

Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-win.zip

Faça o download do arquivo de assinatura e use openssl para verificar a assinatura:

curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.4.10-asm.18-win.zip.1.sig
openssl dgst -verify - -signature istio-1.4.10-asm.18-win.zip.1.sig istio-1.4.10-asm.18-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

A saída esperada é Verified OK.

Extraia o conteúdo do arquivo em qualquer local no sistema. Por exemplo, para extrair o conteúdo para o diretório de trabalho atual:

tar xzf istio-1.4.10-asm.18-win.zip

O comando cria um diretório de instalação no seu diretório de trabalho atual chamado istio-1.4.10-asm.18, que contém:

• aplicativos de amostra em samples;
• As seguintes ferramentas no diretório bin:
  • istioctl: use istioctl para instalar o Anthos Service Mesh.
  • asmctl: use asmctl para ajudar a validar sua configuração de segurança depois de instalar o Anthos Service Mesh. No momento, asmctl não é compatível com o GKE no VMware.

1. Verifique se você está no diretório raiz da instalação do Anthos Service Mesh.

   cd istio-1.4.10-asm.18

2. Para facilitar, adicione as ferramentas ao diretório /bin/bin do seu PATH.

   export PATH=$PWD/bin:$PATH

Como preparar arquivos de configuração de recursos

Ao executar istioctl apply command para fazer downgrade do Anthos Service Mesh, especifique -f istio-operator.yaml na linha de comando. Este arquivo contém informações sobre seu projeto e cluster que são necessários para ativar os recursos de segurança e telemetria do Mesh. Faça o download do istio-operator.yaml e de outros arquivos de configuração de recursos e defina as informações do cluster e do projeto.

Para preparar os arquivos de configuração de recursos, siga estas etapas:

1. Instale kpt, caso ainda não tenha feito isso:

   gcloud components install kpt
   

2. Opcionalmente, crie um novo diretório para os arquivos de configuração de recursos do pacote do Anthos Service Mesh. Se você planeja configurar mais de um cluster, convém usar o nome do cluster como o nome do diretório.

3. Altere para o diretório em que você quer fazer o download do pacote do Anthos Service Mesh.

4. Faça o download do pacote do Anthos Service Mesh no diretório de trabalho atual:

   kpt pkg get \
   https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.4-asm .
   

5. Defina o nome do cluster:

     kpt cfg set asm cluster-name ${CLUSTER_NAME}

6. Como opção, personalize os arquivos de configuração do recurso usando os setters kpt. Por padrão, esses setters usam os padrões para gcloud config. Se você definir os padrões gcloud config ou se quiser alterar os valores, execute os seguintes setters:

   • Defina o ID do projeto:

     kpt cfg set asm gcloud.core.project ${PROJECT_ID}

   • Defina a zona ou a região padrão:

     kpt cfg set asm gcloud.compute.zone ${CLUSTER_LOCATION}

7. Se preferir, insira os arquivos de configuração de recursos no seu próprio sistema de controle de origem, como o Cloud Source Repositories, para rastrear as alterações nos arquivos.

Como fazer downgrade do Anthos Service Mesh

Nesta seção, explicamos como fazer downgrade do Anthos Service Mesh e como ativá-lo:

• Os recursos Padrão compatíveis listados na página Recursos compatíveis.
• Autoridade de certificação do Anthos Service Mesh (Mesh CA, na sigla em inglês).
• O pipeline de dados de telemetria que alimenta os painéis do Anthos Service Mesh no Console do Google Cloud.

Para informações sobre como ativar os recursos Opcionais compatíveis, consulte Como ativar recursos opcionais.

Para instalar o Anthos Service Mesh:

Escolha um dos comandos a seguir para configurar o Anthos Service Mesh no modo de autenticação TLS mútua (mTLS) PERMISSIVE ou no modo mTLS STRICT.

PERMISSIVE mTLS

istioctl manifest apply --set profile=asm \
  -f asm/cluster/istio-operator.yaml

Cuidado: no modo PERMISSIVE, seus serviços podem aceitar o tráfego de texto simples e o tráfego TLS mútua ao mesmo tempo e enviar tráfego intra-mesh de texto simples por padrão. Para proteger sua malha de serviço após o downgrade, migre os serviços para o modo TLS mútua STRICT, conforme descrito em Migração de TLS mútua.

STRICT mTLS

istioctl manifest apply --set profile=asm \
  -f asm/cluster/istio-operator.yaml \
  --set values.global.mtls.enabled=true

Verificar os componentes do plano de controle

O downgrade requer a reinstalação dos componentes do plano de controle, o que leva cerca de 5 a 10 minutos para ser concluído. Os antigos componentes do plano de controle são encerrados e, em seguida, excluídos, à medida que os novos componentes são instalados. É possível verificar o progresso observando o valor na coluna AGE das cargas de trabalho.

kubectl get pod -n istio-system

Exemplo de saída:

NAME                                     READY   STATUS        RESTARTS   AGE
istio-galley-76d684bf9-jwz65             2/2     Running       0          5m36s
istio-ingressgateway-5bfdf7c586-v6wxx    2/2     Terminating   0          25m
istio-ingressgateway-7b598c5557-b88md    2/2     Running       0          5m44s
istio-nodeagent-bnjg7                    1/1     Running       0          5m16s
istio-nodeagent-cps2j                    1/1     Running       0          5m10s
istio-nodeagent-f4x46                    1/1     Running       0          5m26s
istio-nodeagent-jbl5x                    1/1     Running       0          5m38s
istio-pilot-5dc4bc4dbf-ds5dh             2/2     Running       0          5m30s
istio-pilot-74665549c5-7r6qh             2/2     Terminating   0          25m
istio-sidecar-injector-7ddff4b99-b76l7   1/1     Running       0          5m36s
promsd-6d4d5b7c5c-dgnd7                  2/2     Running       0          5m30s

Neste exemplo, há duas instâncias de istio-ingressgateway e istio-pilot. As instâncias com 25m na coluna AGE estão sendo encerradas. Os demais componentes foram instalados recentemente.

Como validar a instalação

Beta

Este produto ou recurso está sujeito aos "Termos das ofertas pré-GA" na seção "Termos de Serviço gerais" dos Termos específicos do serviço. Os produtos e 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.

Recomendamos que você use a ferramenta de análise asmctl para validar a configuração básica do projeto, do cluster e das cargas de trabalho. Se um teste asmctl falhar, asmctl recomenda soluções, se possível. O comando asmctl validate executa testes básicos que verificam:

1. que as APIs exigidas pelo Anthos Service Mesh estão ativadas no projeto;
2. que o Istio-Ingressgateway está configurado corretamente para chamar a CA do Mesh;
3. a integridade geral do Istiod e do Istio-Ingressgateway.

Se você executar o comando asmctl validate com a sinalização opcional --with-testing-workloads, além dos testes básicos, o asmctl executará testes de segurança que verificam:

1. se a comunicação TLS mútua (mTLS) está configurada corretamente;
2. se a CA do Mesh pode emitir certificados.

Para executar os testes de segurança, o asmctl implanta cargas de trabalho no cluster em um namespace de teste, executa os testes de comunicação mTLS, gera os resultados e exclui o namespace de teste.

Para executar asmctl:

1. Verifique se o Application Default Credentials da gcloud está configurado:

    gcloud auth application-default login
   

2. Receba credenciais de autenticação para interagir com o cluster, caso ainda não tenha feito isso:

    gcloud container clusters get-credentials ${CLUSTER_NAME}
   

3. Para executar os testes básicos e de segurança, supondo que istio-1.4.10-asm.18/bin esteja no seu PATH:

   asmctl validate --with-testing-workloads
   

   Se for bem-sucedido, o comando responderá com uma saída semelhante à seguinte:

   Using Kubernetes context: meshci145g-20200219_us-central1-a_meshci145g
   To change the context, use the --context flag
   Validating enabled APIs
   OK
   Validating Node-Agent configuration
   OK
   Validating Istio system
   OK
   Validating issued certs
   OK
   Validating sample traffic
   Launching example services...
   Sent traffic to example service http code: 200
   verified mTLS configuration
   OK

Como atualizar proxies sidecar

As cargas de trabalho em execução no cluster antes do downgrade do Anthos Service Mesh precisam ter o proxy sidecar injetado ou atualizado para que tenham a versão atual do Anthos Service Mesh.

Cuidado: a menos que você tenha um balanceador de carga ou um roteador configurado para implantações azul-verde, teste a reinicialização dos pods em um ambiente de preparação para verificar se seus serviços podem lidar com qualquer possível interrupção de tráfego.

Com a injeção automática de sidecar, é possível reiniciar os pods para atualizar os sidecars deles. A maneira como você reinicia os pods depende se eles foram criados como parte de uma implantação.

1. Se você usou uma implantação, reinicie-a. Isso reinicia todos os pods com sidecars:

   kubectl rollout restart YOUR_DEPLOYMENT -n YOUR_NAMESPACE

   Se você não usou uma implantação, exclua os pods. Eles serão recriados automaticamente com os sidecars:

   kubectl delete pod -n YOUR_NAMESPACE --all

2. Confira se todos os pods no namespace têm sidecars injetados:

   kubectl get pod -n YOUR_NAMESPACE --all

   Neste exemplo de saída do comando anterior, observe que a coluna READY indica que há dois contêineres para cada uma das cargas de trabalho: o principal e o contêiner do proxy sidecar.

   NAME                    READY   STATUS    RESTARTS   AGE
   YOUR_WORKLOAD           2/2     Running   0          20s
   ...