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

Este procedimento abrange o upgrade da versão híbrida 1.8.x da Apigee para a versão híbrida 1.9.4 da Apigee e de versões anteriores da versão híbrida 1.9.x para a versão 1.9.4.

Use os mesmos procedimentos para upgrades de versão secundária (por exemplo, 1.8 para 1.9) e para upgrades de versão de patch (por exemplo, 1.9.0 para 1.9.4).

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

A partir da versão 1.9.0, a Apigee híbrida oferece suporte apenas ao gateway de entrada da Apigee como camada de entrada.

Como fazer upgrade para a versão 1.9.4

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

Ao fazer upgrade do controlador da Apigee para a versão 1.9.4, 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.8 não pode ser usado para restaurar uma instância do Hybrid 1.9.
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.
Instale o ambiente de execução híbrido versão 1.9.4.

Pré-requisitos

Estas instruções de upgrade presumem que você tenha a Apigee híbrida versão 1.8.x instalada e queira fazer upgrade para a versão 1.9.4. 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.8.
Na versão híbrida 1.8 da Apigee, introduzimos o gateway de entrada da Apigee como uma camada de entrada alternativa para o Anthos Service Mesh. A partir da versão 1.9.0, a Apigee híbrida exige o uso do gateway de entrada da Apigee e não oferece mais suporte ao uso do Anthos Service Mesh para entrada. Se a instalação de que você está fazendo upgrade usa o Anthos Service Mesh, primeiro migre para o gateway de entrada da Apigee antes de fazer upgrade para a versão 1.9.4.
O gateway de entrada da Apigee usa um pequeno subconjunto de recursos do Anthos Service Mesh para o gateway de entrada. O gerenciamento e o upgrade desses recursos são feitos automaticamente pela Apigee híbrida. Portanto, você não precisa de experiência com o Anthos Service Mesh para instalar, fazer upgrade e gerenciar o gateway de entrada da Apigee híbrida.

Consulte Como migrar para o gateway de entrada da Apigee na documentação versão híbrida v1.8 para conferir as instruções.

Preparar para fazer upgrade para a versão 1.9

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 Mac OS Windows
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
```
set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
```
Faça uma cópia de backup do diretório $APIGEECTL_HOME/ da versão 1.8. Exemplo:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.8-backup.tar.gz $APIGEECTL_HOME
```
Faça o backup do banco de dados 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 adicionou o papel Cloud Trace Agent à instalação híbrida v1.8, verifique se a conta de serviço de seus serviços de ambiente de execução da Apigee têm o papel de Agente do Cloud Trace do Google Cloud IAM (roles/cloudtrace.agent).

Para ambientes de produção, a conta de serviço do ambiente de execução é apigee-runtime. Para ambientes de não produção, a conta de serviço do ambiente de execuçã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 Sem produção
```
gcloud iam service-accounts list --filter "apigee-runtime"
```
Se o endereço de e-mail corresponder ao padrão apigee-runtime@$ORG_NAME.iam.gserviceaccount.com, será possível usar esse padrão na próxima etapa.
```
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 Sem produção Exemplo

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

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

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.

Instale o gateway de entrada da Apigee se a instalação usar o Anthos Service Mesh

A partir da versão 1.9, a Apigee híbrida não oferece mais suporte ao uso do Anthos Service Mesh para entrada. Se a instalação híbrida estiver usando o Anthos Service Mesh, será preciso migrar a instalação atual para o gateway de entrada da Apigee antes de instalar a versão híbrida 1.9.

Adicione a propriedade ingressGateways ao arquivo de substituições.
SintaxeExemplo
```
  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
```
```
  ingressGateways:
  - name: prod1
    replicaCountMin: 2
    replicaCountMax: 100
    resources:
      requests:
        cpu: 1
        memory: 1Gi
      limits:
        cpu: 2
        memory: 2Gi
    svcAnnotations:  # optional. See Known issue 243599452.
      networking.gke.io/load-balancer-type: "Internal"
    svcLoadBalancerIP: 198.252.0.123 
```
- 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 definiçõ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 de cada réplica do gateway de entrada da Apigee na sua instalação.
  Configure essas propriedades se você as tiver definido anteriormente 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 são 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 se você as tiver definido anteriormente 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 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 conferir 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 implantação de entrada, conforme documentado em Expor o gateway de 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 endereço de 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ções.
  
  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 será necessário definir LoadBalancerIP se você estiver criando seu próprio serviço do Kubernetes para implantação de entrada, conforme documentado em Expor o gateway de entrada da Apigee.
  Consulte ingressGateways[].svcLoadBalancerIP na referência da propriedade de configuração.
Aplique as alterações para instalar o gateway de entrada da Apigee com os seguintes comandos:
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml
```
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.

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

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 Mac OS Windows

Linux de 64 bits:

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

Mac 64 bits:

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

Windows 64 bit:

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

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

Linux Mac OS Windows

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.8/

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.8/

rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.8

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.8 está localizado:
Linux Mac OS Windows
```
tar xvzf filename.tar.gz -C ./
```
```
tar xvzf filename.tar.gz -C ./
```
```
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.9.4-xxxxxxx_linux_64. Renomeie esse diretório para apigeectl usando o seguinte comando:
Linux Mac OS Windows
```
mv apigeectl_1.9.4-xxxxxxx_linux_64 apigeectl
```
```
mv apigeectl_1.9.4-xxxxxxx_mac_64 apigeectl
```
```
rename apigeectl_1.9.4-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 Mac OS Windows
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
```
set APIGEECTL_HOME=%CD%
```
```
echo %APIGEECTL_HOME%
```
Verifique a versão de apigeectl com o comando version:
```
./apigeectl version
```
```
Version: 1.9.4
```
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.9.4:
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
Observação: apigeectl instala e configura o gateway de entrada da Apigee quando você executa apigeectl init.
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.
```
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.
ProduçãoSem produção
Para ambientes de produção, você precisa fazer upgrade de cada componente híbrido individualmente e verificar o status do componente atualizado antes de seguir para o 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
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

Instalar `1.9.4-hotfix.1`

Siga estas etapas para instalar a versão hotfix, 1.9.4-hotfix.1:

Antes de realizar estas etapas, você precisa usar a Apigee híbrida versão 1.9.4 ou mais recente. Se você não estiver usando a versão 1.9.4 ou posterior, faça um upgrade para a versão 1.9.4 antes de continuar.
Abra seu arquivo overrides.yaml.

Na estrofe istiod, mude a versão da tag de imagem (se presente) para a versão 1.17.7. Exemplo:

istiod:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-asm-istiod"
    tag: "1.17.7-asm.0-distroless"

Dependendo de como você escolheu instalar a Apigee híbrida, talvez apareça uma estrofe ingressGateway ou ingressGateways. Localize a estrofe no arquivo de substituição e mude a versão da tag de imagem (se presente) para a versão 1.17.7. Por exemplo, se você tiver uma estrofe ingressGateway:

ingressGateway:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
    tag: "1.17.7-asm.0-distroless"

ou, se tiver uma estrofe ingressGateways:

ingressGateways:
  - name: gateway1
    image:
      url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
      tag: "1.17.7-asm.0-distroless"
    ...
  - name: gateway2
    image:
      url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
      tag: "1.17.7-asm.0-distroless"
    ...

Salve o arquivo.

Execute o seguinte comando para inicializar o componente istiod:

$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE

$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Execute o comando a seguir para aplicar alterações aos componentes de entrada da Apigee. Se você tiver mais de uma organização, repita este comando para cada uma delas:
```
$APIGEECTL_HOME/apigeectl apply --org -f OVERRIDES_FILE
```
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```

Verifique o status dos pods:

kubectl get pods -n YOUR_APIGEE_NAMESPACE

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.9. 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.

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. Por exemplo:
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```
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.8.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ções 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 saída será semelhante a esta:
```
      autoScaler:
        minReplicas: 2
        maxReplicas: 10
```
5. Execute apigeectl init:
```
$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
```