Como fazer upgrade da Apigee híbrida para a versão 1.8

Observação: este procedimento abrange o upgrade da Apigee híbrida versão 1.7.x ou de versões anteriores da Apigee híbrida versão 1.8.x para a Apigee híbrida versão 1.8.8.

Use os mesmos procedimentos para upgrades de versão secundária (por exemplo, 1.7 para 1.8) e para upgrades de versão de patch (por exemplo, 1.8.0 para 1.8.8).

Se estiver fazendo upgrade da versão híbrida 1.6 ou posterior da Apigee, primeiro você precisará fazer upgrade para a versão híbrida 1.7 antes de fazer upgrade para a versão 1.8.8. Consulte as instruções sobre Como fazer upgrade da Apigee híbrida para a versão 1.7.

Se você já está na versão v1.8.0 híbrida e quer migrar para o gateway de entrada da Apigee pelo Anthos Service Mesh, consulte Como migrar para o gateway de entrada da Apigee.

Introdução ao gateway de entrada da Apigee

A partir da versão 1.8, a Apigee híbrida oferece um novo recurso para gerenciar o gateway de entrada da sua instalação híbrida, o gateway de entrada da Apigee. O Anthos Service Mesh não é mais um pré-requisito para a instalação híbrida. Com o gateway de entrada da Apigee, a Apigee deixará de fornecer configurações de roteamento para o Anthos Service Mesh. Após o upgrade, você precisará migrar o tráfego para o novo gateway de entrada da Apigee antes de começar a usar o recurso.

A Apigee usa um pequeno subconjunto de recursos do Anthos Service Mesh para o gateway de entrada. A partir da versão 1.8, a Apigee híbrida inclui um gateway de entrada instalado e atualizado como parte dos upgrades da Apigee híbrida. Portanto, você não precisa adquirir experiência no Anthos Service Mesh para instalar, fazer upgrade e gerenciar a Apigee híbrida. Os problemas relacionados às versões de gateway de entrada e a compatibilidade com as versões da Apigee híbrida são tratados automaticamente.

Veja a seguir dois cenários que podem ser migrados:

Migração em vários clusters ou multirregiões (recomendado):
Antes de alternar para uma nova Entrada para a Apigee, drene todo o tráfego para outro cluster ou região do cluster que você está migrando. Isso dará tempo para você testar se o novo gateway de entrada da Apigee está funcionando conforme o esperado. Depois, transfira o tráfego de volta para o cluster atualizado.
Upgrade no local (não recomendado em ambientes de produção):
Durante o upgrade, a Apigee abrirá o novo gateway de entrada com um endereço IP que você especificar. Depois, é possível testar se o novo gateway de entrada da Apigee está funcionando conforme o esperado e, em seguida, transferir o tráfego para a nova entrada. Talvez haja inatividade durante esse upgrade.

Ao fazer upgrade da Apigee híbrida para a versão 1.8, é preciso configurar o gateway de entrada da Apigee no arquivo de substituições. Depois de fazer o upgrade, você controla qual tipo de gateway de entrada seus clusters usarão ao direcionar os registros A ou CNAME no seu registrador para o endereço IP do gateway de entrada da Apigee ou para o Anthos Service Mesh.

Visão geral de como fazer upgrade para a versão 1.8.8

O upgrade para a Apigee híbrida versão 1.8 pode exigir inatividade:

Ao fazer upgrade do controlador da Apigee para a versão 1.8.8, todas as implantações da Apigee passam por uma reinicialização gradual. Para minimizar a inatividade em ambientes híbridos de produção durante uma reinicialização gradual, verifique se você está executando pelo menos dois clusters (na mesma ou diferente região/data center). Divida todo o tráfego de produção para um único cluster. Pegue o cluster que você está prestes a fazer upgrade off-line e continue o processo de upgrade. Repita o processo para cada cluster.

A Apigee recomenda que você faça upgrade de todos os clusters o mais rápido possível para reduzir as chances de impacto na produção. Não há limite de tempo para o upgrade de todos os clusters restantes depois do upgrade do primeiro. No entanto, até que todos os clusters restantes sejam atualizados, as seguintes operações serão afetadas:

O backup e a restauração do Cassandra não funcionam com versões mistas. Por exemplo, um backup da Hybrid 1.7 não pode ser usado para restaurar uma instância do Hybrid 1.8.
O streaming de dados do Cassandra não funcionará entre versões híbridas mistas. Portanto, os clusters do Cassandra não podem ser escalonados horizontalmente.
A expansão e a desativação de regiões serão afetadas porque essas operações dependem do streaming de dados do Cassandra.

Os procedimentos para fazer upgrade da Apigee híbrida são organizados nas seguintes seções:

Prepare-se para o upgrade.
Instalar o ambiente de execução híbrido versão 1.8.8.
Para o gateway de entrada, escolha uma das seguintes opções:
- (Recomendado) Use o novo gateway de entrada da Apigee e siga as etapas em Alternar tráfego do Anthos Service Mesh para o gateway de entrada da Apigee.
- Continue usando o Anthos Service Mesh no seu gateway de entrada.

Pré-requisito

Estas instruções de upgrade presumem que você tenha a Apigee híbrida versão 1.7.x ou uma versão anterior do patch da versão 1.8.x instaladas e queira fazer upgrade para a versão 1.8.8. Se você estiver atualizando de uma versão anterior, consulte as instruções sobre Como fazer upgrade da Apigee híbrida para a versão 1.7.

Se você preferir continuar usando o Anthos Service Mesh, garanta que o Anthos Service Mesh seja atualizado para uma versão compatível. Consulte a tabela Plataformas compatíveis para ver as versões compatíveis do Anthos Service Mesh.

Preparar para fazer upgrade para a versão 1.8

Fazer backup da instalação híbrida (recomendado)

Estas instruções usam a variável de ambiente APIGEECTL_HOME para o diretório no seu sistema de arquivos em que você instalou apigeectl. Se necessário, mude o diretório para seu diretório apigeectl e defina a variável com o seguinte comando:
Linux
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
```
Faça uma cópia de backup do seu diretório $APIGEECTL_HOME/ da versão 1.7. Exemplo:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
```
Faça o backup do banco de dados do Cassandra seguindo as instruções em Backup e recuperação do Cassandra.

Adicione o papel Agente do Cloud Trace à conta de serviço do ambiente de execução da Apigee. (Opcional)

Opcional: se você planeja usar o Cloud Trace e ainda não concluiu essa etapa na instalação híbrida da v1.7, verifique se a conta de serviço dos serviços de ambiente de execução da Apigee tem o Papel do agente do Cloud Trace do Google. (roles/cloudtrace.agent).

Para ambientes de produção, ela costuma ser a conta de serviço apigee-runtime. Em ambientes de não produção, geralmente é a conta de serviço apigee-non-prod.

Você pode adicionar o papel na IU do Console do Cloud > IAM e Administrador > Contas de serviço ou com os seguintes comandos:

Encontre o endereço de e-mail da conta de serviço com o seguinte comando:
Produção
```
gcloud iam service-accounts list --filter "apigee-runtime"
```
Se ele corresponder ao padrão apigee-runtime@$ORG_NAME.iam.gserviceaccount.com, use esse padrão na próxima etapa
Sem produção
```
gcloud iam service-accounts list --filter "apigee-non-prod"
```
Se ele corresponder ao padrão apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com, use esse padrão na próxima etapa

Atribua o papel Agente do Cloud Trace à conta de serviço:

Produção

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Sem produção

gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Exemplo

gcloud projects add-iam-policy-binding hybrid-example-project \
    --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
    --role="roles/cloudtrace.agent"

Em que: $PROJECT_ID é o nome do projeto do Google Cloud em que a Apigee híbrida está instalada.

Observação: se a instalação usar um nome personalizado para a conta de serviço, substitua-o por apigee-runtime ou apigee-non-prod no comando.

Prepare-se para instalar o gateway de entrada da Apigee

Para instalar o gateway de entrada da Apigee como parte do upgrade. Você precisa adicionar a seguinte propriedade ingressGateways ao arquivo de modificações.

Sintaxe

ingressGateways:
- name: INGRESS_NAME
  replicaCountMin: REPLICAS_MIN
  replicaCountMax: REPLICAS_MAX
  resources:
    requests:
      cpu: CPU_COUNT_REQ
      memory: MEMORY_REQ
    limits:
      cpu: CPU_COUNT_LIMIT
      memory: MEMORY_LIMIT
  svcAnnotations:  # optional. See Known issue 243599452.
    SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
  svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

Exemplo

ingressGateways:
- name: prod1
  replicaCountMin: 2
  replicaCountMax: 100
  resources:
    requests:
      cpu: 1
      memory: 1Gi
    limits:
      cpu: 2
      memory: 2Gi

INGRESS_NAME é o nome da implantação de entrada. Pode ser qualquer nome que atenda aos seguintes requisitos:
- ter um comprimento máximo de 17 caracteres
- conter apenas caracteres alfanuméricos minúsculos, "-" ou ".";
- começar com um caractere alfanumérico;
- terminar com um caractere alfanumérico.
Consulte ingressGateways[].name na referência da propriedade de configuração.
REPLICAS_MIN e REPLICAS_MAX são as contagens mínima e máxima de réplicas para o gateway de entrada da Apigee na sua instalação. Para mais informações e configurações padrão, consulte ingressGateways[].replicaCountMin e ingressGateways[].replicaCountMax na referência da propriedade de configuração.
CPU_COUNT_REQ e MEMORY_REQ são a solicitação de CPU e memória para cada réplica do gateway de entrada da Apigee na sua instalação.
Configure essas propriedades somente se você as tiver definido para seu gateway de entrada do Anthos Service Mesh, por exemplo, no arquivo overlay.yaml.

Para mais informações e definições padrão, consulte ingressGateways[].resources.requests.cpu e ingressGateways[].resources.requests.memory na referência da propriedade de configuração.
CPU_COUNT_LIMIT e MEMORY_LIMIT Os limites máximos de CPU e memória para cada réplica do gateway de entrada da Apigee na sua instalação.
Configure essas propriedades somente se você as tiver definido para seu gateway de entrada do Anthos Service Mesh, por exemplo, no arquivo overlay.yaml.

Para mais informações e definições padrão, consulte ingressGateways[].resources.limits.cpu e ingressGateways[].resources.limits.memory na referência da propriedade de configuração.
SVC_ANNOTATIONS_KEY e SVC_ANNOTATIONS_VALUE (opcional):
Observação: o campo ingressGateways[].svcAnnotations em overrides.yaml não está funcionando como esperado. Consulte o problema conhecido 243599452.

Esse é um par de chave-valor que fornece anotações para o serviço de entrada padrão. As anotações são usadas pela sua plataforma de nuvem para ajudar a configurar sua instalação híbrida, por exemplo, definindo o tipo de balanceador de carga como interno ou externo. Exemplo:
```
ingressGateways:
  svcAnnotations:
    networking.gke.io/load-balancer-type: "Internal"
```
As anotações variam de acordo com a plataforma. Consulte a documentação da sua plataforma para ver anotações obrigatórias e sugeridas.

Observação: não é necessário definir Annotations se você estiver criando seu próprio serviço do Kubernetes para a implantação de entrada, conforme documentado em expor entrada da Apigee.
Consulte ingressGateways[].svcAnnotations na referência da propriedade de configuração.
SVC_LOAD_BALANCER_IP (opcional) permite atribuir um endereço IP estático ao seu balanceador de carga. Nas plataformas compatíveis com a especificação do endereço IP do balanceador de carga, o balanceador de carga será criado com esse endereço IP. Nas plataformas que não permitem especificar o IP do balanceador de carga, essa propriedade é ignorada.
Se você não tiver um endereço IP estático alocado para o balanceador de carga, deixe essa propriedade fora do arquivo de substituição.

Atenção: não especifique o mesmo endereço IP do istio-ingressgateway atual. Isso pode causar problemas enquanto esse serviço ainda está no cluster.

Observação: não é necessário definir LoadBalancerIP se você estiver criando seu próprio serviço do Kubernetes para a implantação de entrada, conforme documentado em expor entrada da Apigee.
Consulte ingressGateways[].svcLoadBalancerIP na referência da propriedade de configuração.

Faça alterações adicionais no seu arquivo de substituição para ativar ou desativar recursos opcionais da v1.8

Adicione as seguintes propriedades ao arquivo overrides.yaml para ativar novos recursos na versão v1.8 híbrida. Esses recursos são opcionais.

A UDCA com escopo na organização agora está ativada por padrão. O uso de uma única implantação de UDCA para lidar com o tráfego de todos os ambientes evita a subutilização dos pods do UDCA e aumenta a disponibilidade de recursos do nó para outros componentes da Apigee. A UDCA no escopo da organização usa uma única conta de serviço para todos os ambientes, apigee-udca.
Se você estiver usando contas de serviço diferentes para UDCA em diferentes ambientes, use a conta de serviço especificada no nível da organização no arquivo de substituição com udca:serviceAccountPath, em vez das contas especificadas no nível do ambiente com envs:udca:serviceAccountPath.

A Apigee híbrida v 1.8 oferece suporte a UDCA com escopo de ambiente. Para manter o UDCA por ambiente, defina orgScopedUDCA: false.

Observação: o suporte para UDCA com escopo de ambiente não estará disponível em versões futuras da Apigee híbrida.

Consulte orgScopedUDCA na referência das propriedades de configuração.
Ative validateOrg para exigir uma validação restrita de que a organização e o ambiente da Apigee estão ativos e trabalham com o projeto do Google Cloud Platform especificado no arquivo overrides.
```
validateOrg: true
```
Observação: a Apigee híbrida é compatível com o não uso de validação organizacional estrita. Para desativar o recurso, defina validateOrg: false.

Consulte validateOrg na referência das propriedades de configuração.

Instalar o ambiente de execução híbrido 1.8.8

Verifique se você está no diretório base híbrido (o pai do diretório em que o arquivo executável apigeectl está localizado):
```
cd $APIGEECTL_HOME/..
```

Faça o download do pacote de lançamento do seu sistema operacional usando o seguinte comando. Selecione sua plataforma na tabela a seguir:

Linux

Linux de 64 bits:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_linux_64.tar.gz

Mac OS

Mac 64 bits:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_mac_64.tar.gz

Windows

Windows 64 bit:

curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip

Renomeie o diretório apigeectl/ atual para um nome de diretório de backup. Exemplo:

Linux

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

Mac OS

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

Windows

rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7

Extraia o conteúdo do arquivo gzip baixado para seu diretório base híbrido. O diretório base híbrido é aquele em que o diretório renomeado apigeectl-v1.7 está localizado:
Linux
```
tar xvzf filename.tar.gz -C ./
```
Mac OS
```
tar xvzf filename.tar.gz -C ./
```
Windows
```
tar xvzf filename.zip -C ./
```
O conteúdo de tar é, por padrão, expandido em um diretório com a versão e a plataforma no nome. Por exemplo, ./apigeectl_1.8.8-xxxxxxx_linux_64. Renomeie esse diretório para apigeectl usando o seguinte comando:
Linux
```
mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl
```
Mac OS
```
mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.8.8-xxxxxxx_windows_64 apigeectl
```
Altere para o diretório apigeectl:
```
cd ./apigeectl
```
Esse diretório é o diretório inicial apigeectl. É lá que o comando executável apigeectl está localizado.
Estas instruções usam a variável de ambiente $APIGEECTL_HOME para o diretório no seu sistema de arquivos em que o utilitário apigeectl está instalado. Se necessário, mude o diretório para seu diretório apigeectl e defina a variável com o seguinte comando:
Linux
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
```
```
echo %APIGEECTL_HOME%
```
Verifique a versão de apigeectl com o comando version:
```
./apigeectl version
```
```
Version: 1.8.8
```
Mova para o diretório hybrid-base-directory/hybrid-files. O diretório hybrid-files é onde estão localizados os arquivos de configuração, como os arquivos de substituição, certificados e contas de serviço. Por exemplo:
```
cd $APIGEECTL_HOME/../hybrid-files
```
Verifique se kubectl está definido para o contexto correto usando o seguinte comando. O contexto atual precisa ser definido como o cluster em que você está fazendo upgrade da Apigee híbrida.
```
kubectl config get-contexts | grep \*
```
No diretório hybrid-files:
1. Atualize os seguintes links simbólicos para $APIGEECTL_HOME. Com esses links, você pode executar o comando apigeectl recém-instalado no diretório hybrid-files:
```
ln -nfs $APIGEECTL_HOME/tools tools
ln -nfs $APIGEECTL_HOME/config config
ln -nfs $APIGEECTL_HOME/templates templates
ln -nfs $APIGEECTL_HOME/plugins plugins
```
2. Para verificar se os links simbólicos foram criados corretamente, execute este comando e certifique-se de que os caminhos do link apontam para os locais corretos:
```
ls -l | grep ^l
```
Faça uma inicialização a seco para verificar se há erros:
```
${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client
```
Em que OVERRIDES_FILE é o nome do arquivo de substituições, por exemplo, ./overrides/overrides.yaml.

Dica: é possível substituir OVERRIDES_FILE no exemplo de código acima pelo nome e caminho do arquivo de substituição, e todas as instâncias desta página serão substituídas.
Se não houver erros, inicialize o híbrido 1.8.8. Este comando também instala e configura o gateway de entrada da Apigee:
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
Verifique o status da inicialização:
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
Em caso de sucesso, a saída vai ser: All containers ready.

Problema conhecido: depois de executar init e confirmar que check-ready é bem-sucedido, você pode perceber, se visualizar os pods, que a validação do esquema do Cassandra está em estado de erro. Esse estado é considerado um problema conhecido (nº 245664917) e é inofensivo. Ignore o erro e avance para a próxima etapa: apigeectl apply.

Como verificação adicional, execute este comando para verificar o status do ApigeeDataStore:
```
kubectl describe apigeeds -n apigee
```
Na saída, procure State: running.
Verifique se há erros com uma simulação do comando apply usando a sinalização --dry-run:
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
```
Se não houver erros, aplique as substituições. Selecione e siga as instruções para ambientes de produção ou ambientes sem produção, dependendo da sua instalação.
Durante o processo de upgrade, cada componente realizará uma reinicialização gradual. Portanto, para ambientes de produção, é melhor aplicar o upgrade a um componente por vez.
Produção

Para ambientes de produção, você precisa fazer upgrade de cada componente híbrido individualmente e verificar o status do componente atualizado para o processo de confirmação do próximo componente.
1. Verifique se você está no diretório hybrid-files.
2. Aplique as modificações para fazer upgrade do Cassandra:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
3. Verifique a conclusão:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  Dica: se check-ready falhar, você poderá receber mais informações sobre seus pods com:
  kubectl -n NAMESPACE get pods
  
  Em que NAMESPACE é seu namespace da Apigee híbrida.
  Passe para a próxima etapa somente quando os pods estiverem prontos.
4. Aplique as modificações para fazer upgrade dos componentes de telemetria e verificar a conclusão:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
5. Acesse os componentes do Redis:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
6. Aplique as modificações para fazer upgrade dos componentes no nível da organização (MART, Watcher e Apigee Connect) e verifique a conclusão:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
7. Aplique as modificações para fazer upgrade dos seus ambientes. Você tem duas opções:
  - Ambiente por ambiente: aplique suas modificações em um ambiente por vez e verifique a conclusão. Repita esta etapa para cada ambiente:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    
    Em que ENV_NAME é o nome do ambiente que você está atualizando.
  - Todos os ambientes de uma só vez: aplique suas modificações a todos os ambientes de uma só vez e verifique a conclusão:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
8. Aplique as modificações para fazer upgrade dos componentes virtualhosts de telemetria e verificar a conclusão:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
Sem produção

Na maioria dos ambientes de produção, de demonstração ou experimental, é possível aplicar as substituições a todos os componentes de uma só vez. Se o ambiente de não produção for grande e complexo, ou imita frequentemente um ambiente de produção, use as instruções para fazer upgrade dos ambientes de produção.
1. Verifique se você está no diretório hybrid-files.
2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
3. Verifique o status:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Fazer upgrade da versão do Kubernetes

Faça upgrade da plataforma do Kubernetes para as versões compatíveis com a versão híbrida 1.8. Siga a documentação da plataforma se precisar de ajuda.

Clique para expandir uma lista de plataformas compatíveis

	Versões da Apigee híbrida
Plataformas	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8 ⁽³⁾	1.9	1.10
Anthos (Google Cloud – GKE)	1.19.x 1.20.x 1.21.x	1.20.x 1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.21.x ^{(≤ 1.8.3)} 1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
Anthos (AWS)	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.25⁽¹³⁾	1.12.x 1.13.x 1.25⁽¹³⁾	1.13.x 1.25⁽¹³⁾ 1.26⁽¹³⁾
Anthos (Azure)	1.8.x	1.9.x 1.10.x 1.12.x ^{(≥ 1.7.2)}	1.10.x 1.11.x 1.12.x 1.13.x 1.14.x	1.12.x 1.13.x 1.14.x	1.13.x 1.14.x 1.15.x
Anthos (no local- VMware)⁽¹⁾	1.7.x 1.8.x 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
Anthos (Bare Metal)⁽¹⁾	1.7.x 1.8.2+ 1.9.3+ 1.10.x	1.9.x ⁽⁴⁾ 1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ ^{(≥ 1.7.2)} 1.12.x ⁽⁴⁾ ^{(≥ 1.7.2)}	1.10.x ⁽⁴⁾ 1.11.x ⁽⁴⁾ 1.12.x ⁽⁴⁾ ⁽⁵⁾ 1.13.x ⁽⁵⁾ 1.14.x ⁽⁵⁾ 1.15.x	1.12.x ⁽⁴⁾ 1.13.x 1.14.x 1.15.x	1.13.x 1.14.x 1.15.x 1.16.x
EKS⁽⁷⁾	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
AKS⁽⁷⁾	1.19.x 1.20.x 1.21.x	1.21.x 1.22.x ^{(≥ 1.7.2)} 1.23.x ^{(≥ 1.7.2)}	1.22.x ^{(≤ 1.8.3)} 1.23.x ^{(≤ 1.8.4)} 1.24.x ^{(≥ 1.8.4)} 1.25.x ^{(≥ 1.8.4)}	1.23.x 1.24.x 1.25.x 1.26.x ^{(≥ 1.9.2)}	1.24.x 1.25.x 1.26.x
OpenShift⁽⁷⁾	4.6 4.7 4.8	4.7 4.8	4.8 4.9 4.10	4.10 4.11	4.11 4.12
Rancher Kubernetes Engine (RKE)⁽⁷⁾	N/A	N/A	N/A	1.3.8	v1.26.2+rke2r1
Componentes	1.6 ⁽³⁾	1.7 ⁽³⁾	1.8	1.9	1.10
Anthos Service Mesh (ASM)	1.9.x 1.10.x 1.12.x 1.13.x	1.10.x 1.11.x 1.12.x 1.13.x ^{(≥ 1.7.2)} 1.14.x 1.15.x ^{(≥ 1.7.6)}	1.11.x 1.12.x 1.13.x 1.14.x 1.15.x	1.17.x⁽¹¹⁾	1.17.x⁽¹¹⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager.	1.5.4	1.7.x	1.7.x 1.8.x 1.9.x 1.10.x 1.11.x	1.10.x 1.11.x	1.10.x 1.11.x 1.12.x
Cassandra	3.11.10	3.11.10	3.11.10	3.11.10	3.11.10
⁽¹⁾ Nas versões 1.8, 1.9 e 1.10 do Anthos, siga as instruções nestes documentos para evitar conflitos com `cert-manager`: Anthos 1.8.2+: conflito com `cert-manager` ao fazer upgrade para a versão 1.8.2 ou mais recente. Anthos 1.9: conflito com `cert-manager` ao fazer upgrade para a versão 1.9.0 ou 1.9.1. Anthos 1.10+: instalação conflitante do `cert-manager`. ⁽²⁾ Suporte disponível para a versão híbrida da Apigee 1.7.2 e mais recentes. ⁽³⁾ As datas de EOL oficiais da Apigee híbrida versões 1.8 e anteriores foram atingidas. Os patches mensais regulares não estão mais disponíveis. Essas versões não são mais oficialmente compatíveis, exceto para clientes com exceções explícitas e oficiais para suporte contínuo. Outros clientes precisam fazer o upgrade. ⁽⁴⁾O Anthos em bare metal e o VMWare 1.12 e versões anteriores não são compatíveis. Consulte Política de suporte da versão do Anthos em bare metal e Versões dos clusters do Anthos no VMware. ⁽⁵⁾O Anthos em bare metal e o VMWare requerem o ASM 1.14 ou mais recente. Recomendamos que você faça upgrade para a versão híbrida v1.8 e mude para o gateway de entrada da Apigee, que não requer mais a instalação do ASM no cluster híbrido. ⁽⁶⁾ Suporte disponível para a versão híbrida da Apigee 1.8.4 e mais recentes. ⁽⁷⁾ Clusters anexados não são necessários para a Apigee híbrida v1.8 e mais recentes usando a Apigee ingressgateway. ⁽⁸⁾ Não é compatível com a versão híbrida da Apigee 1.8.4 e versões mais recentes. ⁽⁹⁾ Suporte disponível para a versão híbrida da Apigee 1.7.6 e versões mais recentes. ⁽¹⁰⁾ Não é compatível com a versão híbrida da Apigee 1.8.5 e versões mais recentes. ⁽¹¹⁾ O ASM é instalado automaticamente com a Apigee híbrida 1.9 e mais recentes. ⁽¹²⁾ Suporte disponível para a versão híbrida da Apigee 1.9.2 e versões mais recentes. ⁽¹³⁾ Os números de versão dos clusters do Anthos na AWS (várias nuvens) agora refletem as versões do Kubernetes. Consulte Suporte à versão e ao upgrade do Anthos para ver detalhes da versão e os patches recomendados.

Sobre os clusters anexados

Para a Apigee híbrida versão 1.7.x e anteriores, é necessário usar os clusters anexados do Anthos se você quiser executar a Apigee híbrida em um contexto de várias nuvens no Elastic Kubernetes Service (EKS, Azure Kubernetes Service (AKS) ou outro provedor de serviços de terceiros compatível com Kubernetes. O anexo do cluster permite que o Google meça o uso do Anthos Service Mesh (ASM). O registro de clusters de terceiros é opcional. Só registre se você quiser conferir o cluster anexado no console do Google Cloud. Para mais informações, consulte Anexar clusters do Kubernetes de terceiros ao Google Cloud.

Para a versão híbrida da Apigee 1.8.x, os clusters anexados ao Anthos são obrigatórios se você estiver usando o Anthos Service Mesh no seu gateway de entrada. Se você estiver usando o gateway de entrada da Apigee, os clusters anexados ao Anthos serão opcionais.

Migrar o tráfego do Anthos Service Mesh para o gateway de entrada da Apigee

Para alternar o tráfego para o gateway de entrada da Apigee, faça o seguinte:

Exponha o gateway de entrada da Apigee. Siga os procedimentos em Expor o gateway de entrada da Apigee.
Teste seu gateway de entrada chamando um proxy. O ideal é testar todos os proxies importantes que você implantou no momento.
Para alternar o tráfego, atualize seus registros DNS de modo que eles apontem para o endereço IP do novo gateway de entrada da Apigee. Dependendo do seu provedor de DNS, talvez seja possível transferir gradualmente o tráfego para o novo endpoint.
Dica: encontre o IP externo do gateway de entrada da Apigee com o seguinte comando:
```
kubectl get svc -n apigee -l app=apigee-ingressgateway
```
A saída será semelhante a esta:
```
NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h
```
Monitore seus painéis para garantir que todo o tráfego de ambiente de execução esteja funcionando. Só prossiga para a próxima etapa se tudo estiver funcionando como esperado. Verifique se nenhum tráfego está passando pelo antigo gateway de entrada (Anthos Service Mesh), já que a atualização de DNS pode demorar para ser propagada por causa do armazenamento em cache de DNS.
Para impedir que a Apigee forneça a configuração ao Anthos Service Mesh, siga as etapas em Parar de fornecer configuração ao ASM no guia "Como gerenciar o gateway de entrada da Apigee".
Teste novamente e monitore o tráfego de proxy da API.
Siga as instruções na documentação do Anthos Service Mesh para desinstalar o Anthos Service Mesh do cluster.

Fazer upgrade do Anthos Service Mesh para a versão 1.15

Realize os procedimentos usando a documentação do Anthos Service Mesh adequada para sua plataforma:

As instruções para instalar e configurar o Anthos Service Mesh variam de acordo com a plataforma. As plataformas são divididas nas seguintes categorias:

GKE: clusters do Google Kubernetes Engine em execução no Google Cloud.
Fora do Google Cloud: os clusters do Anthos são executados em:
- Clusters do Anthos no VMware (GKE On-Prem)
- Anthos em bare metal
- Clusters do Anthos no AWS
- Amazon EKS
Outras plataformas do Kubernetes: clusters compatíveis criados e em execução em:
- AKS
- EKS
- OpenShift

GKE

A sequência de upgrade para a versão 1.13.9 do Anthos Service Mesh para sua instalação híbrida é a seguinte:

prepare-se para o upgrade;
Instale a nova versão do Anthos Service Mesh.
Exclua as implantações, os serviços e os webhooks da versão anterior do Anthos Service Mesh da sua instalação atual.
faça upgrade dos gateways e configure os novos webhooks.

Prepare-se para fazer upgrade do Anthos Service Mesh para a versão 1.13.9

Veja os requisitos em Fazer upgrade do Anthos Service Mesh, mas ainda não faça o upgrade.
Antes de instalar a nova versão, determine a revisão atual. Você precisará dessas informações para excluir as implantações, os serviços e os webhooks da versão anterior do Anthos Service Mesh da instalação atual. Use o seguinte comando para armazenar a revisão atual do istiod em uma variável de ambiente:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
A saída vai ser semelhante a 1.12.9-asm.2

Observação:se o comando retornar vários valores, defina o valor de DELETE_REV para a versão mais antiga e siga o procedimento para excluir a versão mais antiga. Depois, repita o processo até que você tenha excluído todas as versões.

Crie um novo arquivo overlay.yaml ou verifique se o overlay.yaml atual contém o seguinte conteúdo:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Siga as instruções nas seguintes seções da documentação do Anthos Service Mesh:
Importante: siga as instruções para fazer upgrade do Anthos Service Mesh com recursos opcionais e inclua seu overlay.yaml.
1. faça o download do asmcli;
2. conceda permissões de administrador de cluster;
3. Valide o projeto e o cluster;
4. faça upgrade com recursos opcionais. Pare antes de iniciar a seção "Fazer upgrade dos gateways".
Alternar para o novo plano de controle:
1. Receba o identificador de revisão que está em istiod.
```
kubectl get pod -n istio-system -L istio.io/rev
```
  A saída deste comando é semelhante a:
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Atribua o identificador de revisão mais recente a uma variável de ambiente.
  Na saída, na coluna REV, anote o valor do identificador de revisão da nova versão. Neste exemplo, o valor é asm-1139-10
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Adicione o identificador de revisão ao namespace istio-system e remova o identificador istio-injection (se houver) com o comando a seguir.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se vir "istio-injection not found" na saída, poderá ignorá-la. Isso significa que o namespace não tinha o identificador istio-injection anteriormente. Como a injeção automática falha se um namespace tiver o istio-injection e o identificador de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do identificador istio-injection
4. Reinicie os pods para acionar a nova injeção:
```
kubectl rollout restart deployment -n istio-system
```
5. Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.
6. Se você tiver cargas de trabalho em outros namespaces, repita as etapas para identificar o namespace e reiniciar os pods.

Exclua as versões anteriores:

Vá para o diretório onde você instalou asmcli.
Armazene o diretório de saída da instalação do Anthos Service Mesh na variável de ambiente DIR_PATH. Esse é o mesmo diretório especificado no procedimento Fazer upgrade com recursos opcionais.
```
export DIR_PATH=OUTPUT_DIR
```

Crie um script de shell contendo os seguintes comandos:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Execute o script para excluir as versões anteriores.

Fora do Google Cloud

Nestas instruções, abordamos o upgrade do Anthos Service Mesh em:

Clusters do Anthos no VMware (GKE On-Prem)
Anthos em bare metal
Clusters do Anthos no AWS
Amazon EKS

A sequência de upgrade para a versão 1.13.9 do Anthos Service Mesh para sua instalação híbrida é a seguinte:

prepare-se para o upgrade;
Instale a nova versão do Anthos Service Mesh.
Exclua as implantações, os serviços e os webhooks da versão anterior do Anthos Service Mesh da sua instalação atual.
faça upgrade dos gateways e configure os novos webhooks.

Prepare-se para fazer upgrade do Anthos Service Mesh para a versão 1.13.9

Veja os requisitos em Fazer upgrade do Anthos Service Mesh, mas ainda não faça o upgrade.
Antes de instalar a nova versão, determine a revisão atual. Você precisará dessas informações para excluir as implantações, os serviços e os webhooks da versão anterior do Anthos Service Mesh da instalação atual. Use o seguinte comando para armazenar a revisão atual do istiod em uma variável de ambiente:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
A saída vai ser semelhante a 1.12.9-asm.2

Observação:se o comando retornar vários valores, defina o valor de DELETE_REV para a versão mais antiga e siga o procedimento para excluir a versão mais antiga. Depois, repita o processo até que você tenha excluído todas as versões.

Crie um novo arquivo overlay.yaml ou verifique se o overlay.yaml atual contém o seguinte conteúdo:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:  
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  values:
    gateways:
      istio-ingressgateway:
        runAsRoot: true

  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Siga as instruções nas seguintes seções da documentação do Anthos Service Mesh:
Importante: siga as instruções para fazer upgrade do Anthos Service Mesh com recursos opcionais e inclua seu overlay.yaml.
1. faça o download do asmcli;
2. conceda permissões de administrador de cluster;
3. Valide o projeto e o cluster;
4. faça upgrade com recursos opcionais. Pare antes de iniciar a seção "Fazer upgrade dos gateways".
Alternar para o novo plano de controle:
1. Receba o identificador de revisão que está em istiod.
```
kubectl get pod -n istio-system -L istio.io/rev
```
  A saída deste comando é semelhante a:
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Atribua o identificador de revisão mais recente a uma variável de ambiente.
  Na saída, na coluna REV, anote o valor do identificador de revisão da nova versão. Neste exemplo, o valor é asm-1139-10
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Adicione o identificador de revisão ao namespace istio-system e remova o identificador istio-injection (se houver) com o comando a seguir.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se vir "istio-injection not found" na saída, poderá ignorá-la. Isso significa que o namespace não tinha o identificador istio-injection anteriormente. Como a injeção automática falha se um namespace tiver o istio-injection e o identificador de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do identificador istio-injection
4. Reinicie os pods para acionar a nova injeção:
```
kubectl rollout restart deployment -n istio-system
```
5. Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.
6. Se você tiver cargas de trabalho em outros namespaces, repita as etapas para identificar o namespace e reiniciar os pods.

Exclua as versões anteriores:

Vá para o diretório onde você instalou asmcli.
Armazene o diretório de saída da instalação do Anthos Service Mesh na variável de ambiente DIR_PATH. Esse é o mesmo diretório especificado no procedimento Fazer upgrade com recursos opcionais.
```
export DIR_PATH=OUTPUT_DIR
```

Crie um script de shell contendo os seguintes comandos:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Execute o script para excluir as versões anteriores.

AKS / EKS

Nestas instruções, o processo de upgrade da versão istio-1.13.9-asm.10 do Anthos Service Mesh (Anthos Service Mesh) nos clusters anexados ao Anthos é o mesmo que executar uma nova instalação.

Como preparar a instalação do Anthos Service Mesh

Antes de instalar a nova versão, determine a revisão atual. Você vai precisar dessas informações para excluir o webhook de validação e o webhook de mutação da instalação atual do Anthos Service Mesh. Use o seguinte comando para armazenar a revisão atual do istiod em uma variável de ambiente:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
A saída vai ser semelhante a 1.12.9-asm.2

Observação: se o comando retornar vários valores, defina o valor de DELETE_REV para a versão mais antiga e siga o procedimento para excluir a versão mais antiga. Depois, repita o processo até que você tenha excluído todas as versões.

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.13.9-asm.10-linux-amd64.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.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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.13.9-asm.10-linux-amd64.tar.gz

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

Exemplos de aplicativos no diretório samples.
A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.

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

cd istio-1.13.9-asm.10

Para facilitar, adicione as ferramentas ao diretório /bin ao seu PATH:

export PATH=$PWD/bin:$PATH

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.13.9-asm.10-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.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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.13.9-asm.10-osx.tar.gz

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

Exemplos de aplicativos no diretório samples.
A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.

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

cd istio-1.13.9-asm.10

Para facilitar, adicione as ferramentas ao diretório /bin ao seu PATH:

export PATH=$PWD/bin:$PATH

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.13.9-asm.10-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.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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.13.9-asm.10-win.zip

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

Exemplos de aplicativos no diretório samples.
A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
Os perfis de configuração do Anthos Service Mesh estão no diretório manifests\profiles.

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

cd istio-1.13.9-asm.10

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

set PATH=%CD%\bin:%PATH%

Agora que o Istio do Anthos Service Mesh está instalado, verifique a versão do istioctl:
```
istioctl version
```
Crie um namespace chamado istio-system para os componentes do plano de controle:
```
kubectl create namespace istio-system
```

Como instalar o Anthos Service Mesh

Edite seu arquivo overlay.yaml ou crie um novo com o seguinte conteúdo:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        service:
          type: LoadBalancer
          ports:
          - name: status-port
            port: 15021
            targetPort: 15021
          - name: http2
            port: 80
            targetPort: 8080
          - name: https
            port: 443
            targetPort: 8443

Instale o Anthos Service Mesh com istioctl usando o perfil asm-multicloud:

istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1139-10" \
    --filename overlay.yaml

A saída será semelhante a esta:

kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s

O argumento --set revision adiciona um rótulo de revisão no formato istio.io/rev=asm-1139-10 a istiod. O rótulo de revisão é usado pelo webhook do injetor automático de sidecar para associar os sidecars injetados a uma revisão istiod específica. Para ativar a injeção automática de sidecar para um namespace, você precisa rotulá-lo com uma revisão que corresponda ao rótulo em istiod.

Verifique se a instalação foi concluída:

kubectl get svc -n istio-system

A saída será semelhante a esta:

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

Alternar para o novo plano de controle:
1. Receba o identificador de revisão que está em istiod.
```
kubectl get pod -n istio-system -L istio.io/rev
```
  A saída deste comando é semelhante a:
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Atribua o identificador de revisão mais recente a uma variável de ambiente.
  Na saída, na coluna REV, anote o valor do identificador de revisão da nova versão. Neste exemplo, o valor é asm-1139-10
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Adicione o identificador de revisão ao namespace istio-system e remova o identificador istio-injection (se houver) com o comando a seguir.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se vir "istio-injection not found" na saída, poderá ignorá-la. Isso significa que o namespace não tinha o identificador istio-injection anteriormente. Como a injeção automática falha se um namespace tiver o istio-injection e o identificador de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do identificador istio-injection
4. Reinicie os pods para acionar a nova injeção:
```
kubectl rollout restart deployment -n istio-system
```
5. Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.
6. Se você tiver cargas de trabalho em outros namespaces, repita as etapas para identificar o namespace e reiniciar os pods.

Exclua as versões anteriores:

Vá para o diretório onde você instalou asmcli.

Crie um script de shell contendo os seguintes comandos:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Execute o script para excluir as versões anteriores.

OpenShift

Nestas instruções, o processo de upgrade da versão istio-1.13.9-asm.10 do Anthos Service Mesh (Anthos Service Mesh) nos clusters anexados ao Anthos é o mesmo que executar uma nova instalação.

Como preparar a instalação do Anthos Service Mesh

Antes de instalar a nova versão, determine a revisão atual. Você vai precisar dessas informações para excluir o webhook de validação e o webhook de mutação da instalação atual do Anthos Service Mesh. Use o seguinte comando para armazenar a revisão atual do istiod em uma variável de ambiente:
```
export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV
```
A saída vai ser semelhante a 1.12.9-asm.2

Observação: se o comando retornar vários valores, defina o valor de DELETE_REV para a versão mais antiga e siga o procedimento para excluir a versão mais antiga. Depois, repita o processo até que você tenha excluído todas as versões.

Linux

Conceda a restrição de contexto de segurança anyuid (SCC) ao istio-system com o seguinte comando da CLI do OpenShift (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

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.13.9-asm.10-linux-amd64.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.13.9-asm.10-linux-amd64.tar.gz.1.sig

openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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.13.9-asm.10-linux-amd64.tar.gz

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

Exemplos de aplicativos no diretório samples.
A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.

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

cd istio-1.13.9-asm.10

Para facilitar, adicione as ferramentas ao diretório /bin ao seu PATH:

export PATH=$PWD/bin:$PATH

Mac OS

Conceda a restrição de contexto de segurança anyuid (SCC) ao istio-system com o seguinte comando da CLI do OpenShift (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

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.13.9-asm.10-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.13.9-asm.10-osx.tar.gz.1.sig

openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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.13.9-asm.10-osx.tar.gz

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

Exemplos de aplicativos no diretório samples.
A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
Os perfis de configuração do Anthos Service Mesh estão no diretório manifests/profiles.

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

cd istio-1.13.9-asm.10

Para facilitar, adicione as ferramentas ao diretório /bin ao seu PATH:

export PATH=$PWD/bin:$PATH

Windows

Conceda a restrição de contexto de segurança anyuid (SCC) ao istio-system com o seguinte comando da CLI do OpenShift (oc):

oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system

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.13.9-asm.10-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.13.9-asm.10-win.zip.1.sig

openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

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.13.9-asm.10-win.zip

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

Exemplos de aplicativos no diretório samples.
A ferramenta de linha de comando istioctl que você usa para instalar o Anthos Service Mesh está no diretório bin.
Os perfis de configuração do Anthos Service Mesh estão no diretório manifests\profiles.

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

cd istio-1.13.9-asm.10

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

set PATH=%CD%\bin:%PATH%

Agora que o Istio do Anthos Service Mesh está instalado, verifique a versão do istioctl:
```
istioctl version
```
Crie um namespace chamado istio-system para os componentes do plano de controle:
```
kubectl create namespace istio-system
```

Configurar o webhook de validação

Ao instalar o Anthos Service Mesh, você define um rótulo de revisão em istiod. Você precisa definir a mesma revisão no webhook de validação.

Crie um arquivo chamado istiod-service.yaml com o conteúdo a seguir.

apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-1139-10
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-1139-10
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'

Use kubectl para aplicar a configuração de validação do webhook:
```
kubectl apply -f istiod-service.yaml
```

Verifique se a configuração foi aplicada:

kubectl get svc -n istio-system

A resposta será semelhante a:

NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s

Como instalar o Anthos Service Mesh

Edite seu arquivo overlay.yaml ou crie um novo com o seguinte conteúdo:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          service:
            type: LoadBalancer
            ports:
            - name: status-port
              port: 15021
              targetPort: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443

Instale o Anthos Service Mesh com istioctl usando o perfil asm-multicloud:

istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1139-10" \
    --filename overlayfile.yaml

A saída será semelhante a esta:

kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1139-10-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1139-10-798ffb964-fnj8c       1/1     Running   1          3m21s

O argumento --set revision adiciona um rótulo de revisão no formato istio.io/rev=1.6.11-asm.1 a istiod. O rótulo de revisão é usado pelo webhook do injetor automático de sidecar para associar os sidecars injetados a uma revisão istiod específica. Para ativar a injeção automática de sidecar para um namespace, você precisa rotulá-lo com uma revisão que corresponda ao rótulo em istiod.

Verifique se a instalação foi concluída:

kubectl get svc -n istio-system

A saída será semelhante a esta:

NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1139-10       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s

Alternar para o novo plano de controle:
1. Receba o identificador de revisão que está em istiod.
```
kubectl get pod -n istio-system -L istio.io/rev
```
  A saída deste comando é semelhante a:
```
    NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-1139-10-67998f4b55-lrzpz    1/1    Running  0         68m  asm-1129-0
    istiod-asm-1139-10-67998f4b55-r76kr    1/1    Running  0         68m  asm-1129-0
    istiod-1129-0-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1139-10
    istiod-1129-0-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1139-10
```
2. Atribua o identificador de revisão mais recente a uma variável de ambiente.
  Na saída, na coluna REV, anote o valor do identificador de revisão da nova versão. Neste exemplo, o valor é asm-1139-10
```
export UPGRADE_REV="REVISION_LABEL"
```
3. Adicione o identificador de revisão ao namespace istio-system e remova o identificador istio-injection (se houver) com o comando a seguir.
```
kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
```
  Se vir "istio-injection not found" na saída, poderá ignorá-la. Isso significa que o namespace não tinha o identificador istio-injection anteriormente. Como a injeção automática falha se um namespace tiver o istio-injection e o identificador de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção do identificador istio-injection
4. Reinicie os pods para acionar a nova injeção:
```
kubectl rollout restart deployment -n istio-system
```
5. Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.
6. Se você tiver cargas de trabalho em outros namespaces, repita as etapas para identificar o namespace e reiniciar os pods.

Exclua as versões anteriores:

Vá para o diretório onde você instalou asmcli.

Crie um script de shell contendo os seguintes comandos:

#!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi

Execute o script para excluir as versões anteriores.

Como reverter um upgrade

Siga estas etapas para reverter um upgrade anterior:

Limpe os jobs concluídos do namespace do ambiente de execução híbrido, em que NAMESPACE é o namespace especificado no arquivo de modificações, se você especificou um namespace. Caso contrário, o namespace padrão é apigee:
```
kubectl delete job -n NAMESPACE \
  $(kubectl get job -n NAMESPACE \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
```

Limpe jobs concluídos do namespace apigee-system:

kubectl delete job -n apigee-system \
  $(kubectl get job -n apigee-system \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')

Altere a variável APIGEECTL_HOME para apontar para o diretório que contém a versão original de apigeectl. Exemplo:
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
Desfaça as mudanças no arquivo overrides:
1. Remova ou comente ingressGateways e todas as propriedades dele.
2. Defina o valor de virtualhosts.selector.app como o valor anterior, por exemplo:
```
virtualhosts:
  - name: my-env-group
    selector:
      app: istio-ingressgateway
```
3. Remova ou comente ao.args.disableIstioConfigInAPIServer.
No diretório raiz da instalação para a qual você quer reverter, execute apigeectl apply, verifique o status dos pods e execute apigeectl init. Use o arquivo de modificações original da versão para a qual você quer reverter:
1. No diretório de arquivos híbridos, execute apigeectl apply:
```
$APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE
```
  Em que ORIGINAL_OVERRIDES_FILE é o caminho relativo e o nome do arquivo de substituições para a instalação híbrida da versão anterior, por exemplo, ./overrides/overrides1.7.yaml.
2. Verifique o status dos seus pods.
```
kubectl -n NAMESPACE get pods
```
  Em que NAMESPACE é seu namespace da Apigee híbrida.
3. Verifique o status de apigeeds:
```
kubectl describe apigeeds -n apigee
```
  A saída será semelhante a esta:
```
Status:
  Cassandra Data Replication:
  Cassandra Pod Ips:
    10.8.2.204
  Cassandra Ready Replicas:  1
  Components:
    Cassandra:
      Last Successfully Released Version:
        Revision:  v1-f8aa9a82b9f69613
        Version:   v1
      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  Scaling:
    In Progress:         false
    Operation:
    Requested Replicas:  0
  State:                 running
```
  Siga para a próxima etapa somente quando o pod apigeeds estiver em execução.
4. Execute o comando a seguir para anotar quais serão os novos valores de contagem da réplica para o processador de mensagens após o upgrade. Se esses valores não corresponderem ao que você definiu anteriormente, altere os valores no arquivo de substituição para corresponder à configuração anterior.
```
apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2
```
  A resposta será semelhante a esta:
```
      autoScaler:
        minReplicas: 2
        maxReplicas: 10
```
5. Se você estiver revertendo para a versão híbrida v1.8.4 ou anterior, exclua a implantação do controlador usada pelo híbrido v1.8.5 e versões mais recentes:
```
kubectl -n apigee-system delete deploy apigee-controller-manager
```
6. Execute apigeectl init:
```
$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
```
Exclua a implantação do gerenciador de gateways de entrada da Apigee. Este componente é relevante apenas para as versões da Apigee híbrida 1.8 e mais recentes.
```
kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager
```
Em que NAMESPACE é seu namespace da Apigee híbrida.

Como fazer upgrade da Apigee híbrida para a versão 1.8

Introdução ao gateway de entrada da Apigee

Visão geral de como fazer upgrade para a versão 1.8.8

Pré-requisito

Preparar para fazer upgrade para a versão 1.8

Fazer backup da instalação híbrida (recomendado)

Linux

Mac OS

Windows

Adicione o papel Agente do Cloud Trace à conta de serviço do ambiente de execução da Apigee. (Opcional)

Produção

Sem produção

Produção

Sem produção

Exemplo

Prepare-se para instalar o gateway de entrada da Apigee

Sintaxe

Exemplo

Faça alterações adicionais no seu arquivo de substituição para ativar ou desativar recursos opcionais da v1.8

Instalar o ambiente de execução híbrido 1.8.8

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Produção

Sem produção

Fazer upgrade da versão do Kubernetes

Clique para expandir uma lista de plataformas compatíveis

Plataformas

Componentes

Sobre os clusters anexados

Migrar o tráfego do Anthos Service Mesh para o gateway de entrada da Apigee

Fazer upgrade do Anthos Service Mesh para a versão 1.15

GKE

Prepare-se para fazer upgrade do Anthos Service Mesh para a versão 1.13.9

Fora do Google Cloud

Prepare-se para fazer upgrade do Anthos Service Mesh para a versão 1.13.9

AKS / EKS

Como preparar a instalação do Anthos Service Mesh

Linux

Mac OS

Windows

Como instalar o Anthos Service Mesh

OpenShift

Como preparar a instalação do Anthos Service Mesh

Linux

Mac OS

Windows

Configurar o webhook de validação

Como instalar o Anthos Service Mesh

Como reverter um upgrade