Esta página foi traduzida pela API Cloud Translation.

Atualizar o Apigee Hybrid para a versão 1.15

Este procedimento abrange a atualização da versão 1.14.x do Apigee Hybrid para a versão 1.15.1 do Apigee Hybrid e de versões anteriores do Hybrid 1.15.x para a versão 1.15.1.

Use os mesmos procedimentos para atualizações de versões secundárias (por exemplo, da versão 1.14 para 1.15) e para atualizações de lançamentos de patches (por exemplo, da versão 1.15.0 para 1.15.1).

Se estiver a atualizar a partir da versão 1.13 ou anterior do Apigee Hybrid, tem de atualizar primeiro para a versão 1.14 antes de atualizar para a versão 1.15.1. Consulte as instruções para atualizar o Apigee Hybrid para a versão 1.14.

Alterações do Apigee Hybrid v1.14

Tenha em atenção as seguintes alterações:

Rentabilização híbrida do Apigee: a partir da versão 1.15.1, o Apigee hybrid suporta agora taxas recorrentes, de recarga e de configuração para rentabilização. Para mais informações, consulte o artigo Ativar a rentabilização para o Apigee hybrid.
Carateres universais (*) em basepaths de proxy: a partir da versão 1.15.1, a utilização de carateres universais é agora suportada em basepaths de proxy do Apigee. Para implementar esta alteração, siga o procedimento descrito no Problema conhecido 378686709.
Suporte de conteúdo útil de mensagens grande: a partir da versão 1.15 e também na versão de patch 1.14.2, o Apigee suporta agora conteúdos úteis de mensagens até 30 MB. Para mais informações, consulte:
- Configure o suporte de payload de mensagens grandes no Apigee Hybrid
- runtime.resources.limits.memory na referência da propriedade de configuração.
- runtime.resources.requests.memory na referência da propriedade de configuração.
Verificações de instanciação de classes mais rigorosas: o Apigee Hybrid, a política JavaCallout inclui agora segurança adicional durante a instanciação de classes Java. A medida de segurança melhorada impede a implementação de políticas que tentam direta ou indiretamente ações que requerem autorizações não permitidas.
Na maioria dos casos, as políticas existentes continuam a funcionar como esperado, sem problemas. No entanto, existe a possibilidade de as políticas que dependem de bibliotecas de terceiros ou que têm código personalizado que aciona indiretamente operações que requerem autorizações elevadas serem afetadas.

Importante: esta alteração foi introduzida na versão 1.14.1. Se estiver a fazer a atualização a partir da versão 1.14.0 ou anterior, siga o procedimento em Valide as políticas após a atualização a partir da versão 1.14.0 ou anterior para validar o comportamento das políticas.

Para mais informações acerca das funcionalidades na versão híbrida 1.14, consulte as notas de lançamento do Apigee hybrid v1.14.0.

Pré-requisitos

Antes de atualizar para a versão híbrida 1.15, certifique-se de que a sua instalação cumpre os seguintes requisitos:

Se a sua instalação híbrida estiver a executar uma versão anterior à v1.14, tem de atualizar para a versão 1.14 antes de atualizar para a v1.15. Consulte o artigo Atualizar o Apigee Hybrid para a versão 1.14.
Versão do Helm v3.14.2 ou superior.
kubectl: uma versão suportada do kubectl adequada para a versão da sua plataforma Kubernetes. Consulte o artigo Plataformas e versões suportadas: kubectl.
cert-manager: uma versão suportada do cert-manager. Consulte o artigo Plataformas e versões suportadas: cert-manager. Se necessário, atualize o cert-manager na secção Prepare-se para atualizar para a versão 1.15 abaixo.

Antes de atualizar para a versão 1.15.1: limitações e notas importantes

O Apigee hybrid 1.15.1 apresenta um novo limite de proxies melhorado por ambiente que lhe permite implementar mais proxies e fluxos partilhados num único ambiente. Consulte o artigo Limites: proxies de API para compreender os limites do número de proxies e fluxos partilhados que pode implementar por ambiente. Esta funcionalidade só está disponível em organizações híbridas criadas recentemente e não pode ser aplicada a organizações atualizadas. Para usar esta funcionalidade, faça uma nova instalação do Hybrid 1.15.1 e crie uma nova organização.

Esta funcionalidade está disponível exclusivamente como parte do plano de subscrição de 2024 e está sujeita às autorizações concedidas ao abrigo dessa subscrição. Consulte o artigo Limites de proxy melhorados por ambiente para saber mais acerca desta funcionalidade.
A atualização para a versão 1.15 do Apigee Hybrid pode exigir um período de inatividade.

Quando atualiza o controlador do Apigee para a versão 1.15.1, todas as implementações do Apigee são reiniciadas progressivamente. Para minimizar o tempo de inatividade em ambientes híbridos de produção durante um reinício contínuo, certifique-se de que está a executar, pelo menos, dois clusters (na mesma ou numa região/centro de dados diferente). Desvie todo o tráfego de produção para um único cluster e coloque o cluster que está prestes a atualizar offline. Em seguida, avance com o processo de atualização. Repita o processo para cada cluster.

A Apigee recomenda que, assim que iniciar a atualização, atualize todos os clusters o mais rapidamente possível para reduzir as probabilidades de impacto na produção. Não existe um limite de tempo para a atualização de todos os clusters restantes depois de o primeiro ser atualizado. No entanto, até que todos os clusters restantes sejam atualizados, a cópia de segurança e o restauro do Cassandra não podem funcionar com versões mistas. Por exemplo, não é possível usar uma cópia de segurança do Hybrid 1.14 para restaurar uma instância do Hybrid 1.15.
Não é necessário suspender totalmente as alterações do plano de gestão durante uma atualização. Quaisquer suspensões temporárias necessárias às alterações do plano de gestão são indicadas nas instruções de atualização abaixo.

Atualização para a versão 1.15.1: vista geral

Os procedimentos para atualizar o Apigee hybrid estão organizados nas seguintes secções:

Prepare-se para a atualização.
Instale a versão 1.15.1 do tempo de execução híbrido.

Prepare-se para atualizar para a versão 1.15

Faça uma cópia de segurança da sua instalação híbrida

Estas instruções usam a variável de ambiente APIGEE_HELM_CHARTS_HOME para o diretório no seu sistema de ficheiros onde instalou os gráficos Helm. Se necessário, altere o diretório para este diretório e defina a variável com o seguinte comando:
Linux
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Mac OS
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Windows
```
set APIGEE_HELM_CHARTS_HOME=%CD%
echo %APIGEE_HELM_CHARTS_HOME%
```
Faça uma cópia de segurança do diretório 1.14 $APIGEE_HELM_CHARTS_HOME/. Pode usar qualquer processo de cópia de segurança. Por exemplo, pode criar um ficheiro tar de todo o diretório com:
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.14-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Faça uma cópia de segurança da base de dados Cassandra seguindo as instruções em Cópia de segurança e recuperação do Cassandra.
Importante: a partir da versão 1.14, as restrições incluem as seguintes verificações relacionadas com a cópia de segurança aplicadas durante a atualização do Apigee hybrid.
1. A cópia de segurança tem de estar ativada para suportar o restauro para a versão anterior, se necessário.
2. Tem de fazer uma cópia de segurança nas últimas 24 horas antes da atualização se a cópia de segurança da CSI estiver ativada. Isto minimiza a potencial perda de dados se for necessária uma restauração para a versão anterior.
Para mais informações sobre as verificações de restrições, consulte o artigo Restrições.

Se estiver a usar ficheiros de certificado de serviço (.json) nas suas substituições para autenticar contas de serviço, certifique-se de que os ficheiros de certificado de serviço residem no diretório do gráfico Helm correto. Os gráficos Helm não podem ler ficheiros fora do diretório de cada gráfico.

Este passo não é obrigatório se estiver a usar segredos do Kubernetes ou a Workload Identity Federation para o GKE para autenticar contas de serviço.

A tabela seguinte mostra o destino de cada ficheiro de conta de serviço, consoante o seu tipo de instalação:

Prod

Conta de serviço	Nome do ficheiro predefinido	Diretório do gráfico Helm
`apigee-cassandra`	`PROJECT_ID-apigee-cassandra.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/`
`apigee-logger`	`PROJECT_ID-apigee-logger.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-mart`	`PROJECT_ID-apigee-mart.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-metrics`	`PROJECT_ID-apigee-metrics.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-runtime`	`PROJECT_ID-apigee-runtime.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env`
`apigee-synchronizer`	`PROJECT_ID-apigee-synchronizer.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env/`
`apigee-udca`	`PROJECT_ID-apigee-udca.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-watcher`	`PROJECT_ID-apigee-watcher.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`

Não prod

Faça uma cópia do ficheiro de conta de serviço apigee-non-prod em cada um dos seguintes diretórios:

Conta de serviço	Nome do ficheiro predefinido	Diretórios de gráficos Helm
`apigee-non-prod`	`PROJECT_ID-apigee-non-prod.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/` `$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/` `$APIGEE_HELM_CHARTS_HOME/apigee-org/` `$APIGEE_HELM_CHARTS_HOME/apigee-env/`

Certifique-se de que os ficheiros de chave e certificado TLS (.crt, .key e/ou .pem) residem no diretório $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

Atualize a versão do Kubernetes

Verifique a versão da sua plataforma Kubernetes e, se necessário, atualize-a para uma versão suportada pelo híbrido 1.14 e pelo híbrido 1.15. Siga a documentação da sua plataforma se precisar de ajuda.

Clique para expandir uma lista de plataformas suportadas

Versões suportadas

	1.13	1.14	1.15
GKE no Google Cloud	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x
GKE no AWS	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x	1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x	1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x 1.32.x
GKE no Azure	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x	1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x	1.29.x^{(≥ 1.12.1)(8)} 1.30.x 1.31.x 1.32.x
Google Distributed Cloud (apenas software) no VMware ⁽⁵⁾	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x	1.28.x⁽⁴⁾ 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x
Google Distributed Cloud (apenas software) em bare metal	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x	1.28.x⁽⁴⁾ 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x
EKS	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x 1.32.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x
AKS	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x
OpenShift⁽⁹⁾	4.12 4.13 4.14 4.15 4.16	4.13 4.14 4.15 4.16 4.17	4.16 4.17 4.18
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x 1.30.x	v1.27.x 1.28.x 1.29.x 1.30.x 1.31.x	v1.28.x 1.29.x 1.30.x 1.31.x 1.32.x 1.33.x
VMware Tanzu	v1.26.x	v1.26.x	v1.26.x
Componentes	1.13	1.14	1.15
Cloud Service Mesh	1.19.x⁽³⁾	1.22.x⁽³⁾	1.22.x⁽³⁾
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.15.x⁽¹⁰⁾ 1.16.x⁽¹⁰⁾ 1.17.x⁽¹⁰⁾	1.15.x⁽¹⁰⁾ 1.16.x⁽¹⁰⁾ 1.17.x⁽¹⁰⁾	1.16.x⁽¹⁰⁾ 1.17.x⁽¹⁰⁾
Cassandra	4,0	4,0	4,0
Kubernetes	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x 1.32.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x
kubectl	1.27.x 1.28.x 1.29.x 1.30.x	1.28.x 1.29.x 1.30.x 1.31.x 1.32.x	1.29.x 1.30.x 1.31.x 1.32.x 1.33.x
Leme	3.14.2+	3.14.2+	3.14.2+
Controlador CSI da Secret Store	1.4.6+	1.4.6+	1.4.6+
Vault	1.15.2	1.17.2	1.17.2
⁽¹⁾ No Anthos on-premises (Google Distributed Cloud) versão 1.13, siga estas instruções para evitar conflitos com `cert-manager`: Instalação do cert-manager em conflito ⁽²⁾ As datas oficiais de FdV para as versões 1.12 e anteriores do Apigee Hybrid foram atingidas. Os patches mensais normais já não estão disponíveis. Estas versões já não são oficialmente suportadas, exceto para clientes com exceções explícitas e oficiais para apoio técnico contínuo. Outros clientes têm de fazer a atualização. ⁽³⁾ O Cloud Service Mesh é instalado automaticamente com o Apigee Hybrid 1.9 e mais recente. ⁽⁴⁾ Os números das versões do GKE no AWS refletem agora as versões do Kubernetes. Consulte o artigo GKE Enterprise versão e suporte de atualizações para ver detalhes da versão e patches recomendados. ⁽⁵⁾ O Vault não está certificado no Google Distributed Cloud para VMware. ⁽⁶⁾ Apoio técnico disponível com a versão 1.10.5 e mais recentes do Apigee Hybrid. ⁽⁷⁾ Apoio técnico disponível com a versão 1.11.2 e mais recentes do Apigee Hybrid. ⁽⁸⁾ Apoio técnico disponível com a versão 1.12.1 e mais recentes do Apigee Hybrid. ⁽⁹⁾ O Apigee hybrid é testado e certificado no OpenShift através da versão do Kubernetes incluída em cada versão específica do OCP. ⁽¹⁰⁾ Algumas versões do cert-manager têm um problema em que o servidor TLS do webhook pode não renovar automaticamente o respetivo certificado da AC. Para evitar esta situação, o Apigee recomenda a utilização do seguinte: Híbrida v1.13: use a versão 1.15.5+ do cert-manager. Híbrida v1.14: use as versões 1.15.5+ ou 1.16.3+ do cert-manager. Híbrida v1.15: use as versões do cert-manager 1.16.3+ ou 1.17.2+.

Versões não suportadas

	1.6 ⁽²⁾	1.7 ⁽²⁾	1.8 ⁽²⁾	1,9 ⁽²⁾	1.10 ⁽²⁾	1.11 ⁽²⁾	1,12 ⁽²⁾
GKE no Google Cloud	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 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
GKE no 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 (K8s v1.23.x) 1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x)	1.12.x 1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x)	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
GKE no 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.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
Google Distributed Cloud (apenas software) no 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 (K8s v1.26.x)	1.12.x 1.13.x 1.14.x 1.15.x (K8s v1.26.x)	1.13.x ⁽¹⁾ 1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)(8)}
Google Distributed Cloud (apenas software) em 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 (K8s v1.25.x) 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x⁽⁴⁾^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)(8)}
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.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
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 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
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 4.14^{(≥ 1.10.5)(6)} 4.15^{(≥ 1.10.5)(6)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)(7)} 4.16^{(≥ 1.11.2)(7)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)(8)}
Rancher Kubernetes Engine (RKE)	N/A	N/A	N/A	1.3.8	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)(6)} 1.28.x^{(≥ 1.10.5)(6)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)(7)} 1.29.x^{(≥ 1.11.2)(7)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)}
VMware Tanzu	N/A	N/A	N/A	N/A	N/A	N/A	v1.26.x
Componentes	1.6 ⁽²⁾	1.7 ⁽²⁾	1.8 ⁽²⁾	1.9 ⁽²⁾	1.10 ⁽²⁾	1.11 ⁽²⁾	1,12 ⁽²⁾
Cloud Service Mesh	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⁽³⁾	1.17.x^{(v1.11.0 - v1.11.1)}⁽³⁾ 1.18.x^{(≥ 1.11.2)(7)}⁽³⁾	1.18.x⁽³⁾
JDK	JDK 11	JDK 11	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	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x
Cassandra	3.11	3.11	3.11	3.11	3.11	3.11	4,0
Kubernetes				1.23.x 1.24.x 1.25.x	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x 1.29.x
kubectl					1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x 1.29.x
Leme					3.10+	3.10+	3.14.2+
Controlador CSI da Secret Store						1.3.4+	1.4.1+
Vault						1.13.x	1.15.2
⁽¹⁾ No Anthos on-premises (Google Distributed Cloud) versão 1.13, siga estas instruções para evitar conflitos com `cert-manager`: Instalação do cert-manager em conflito ⁽²⁾ As datas oficiais de FdV para as versões 1.12 e anteriores do Apigee Hybrid foram atingidas. Os patches mensais normais já não estão disponíveis. Estas versões já não são oficialmente suportadas, exceto para clientes com exceções explícitas e oficiais para apoio técnico contínuo. Outros clientes têm de fazer a atualização. ⁽³⁾ O Cloud Service Mesh é instalado automaticamente com o Apigee Hybrid 1.9 e mais recente. ⁽⁴⁾ Os números das versões do GKE no AWS refletem agora as versões do Kubernetes. Consulte o artigo GKE Enterprise versão e suporte de atualizações para ver detalhes da versão e patches recomendados. ⁽⁵⁾ O Vault não está certificado no Google Distributed Cloud para VMware. ⁽⁶⁾ Apoio técnico disponível com a versão 1.10.5 e mais recentes do Apigee Hybrid. ⁽⁷⁾ Apoio técnico disponível com a versão 1.11.2 e mais recentes do Apigee Hybrid. ⁽⁸⁾ Apoio técnico disponível com a versão 1.12.1 e mais recentes do Apigee Hybrid. ⁽⁹⁾ O Apigee hybrid é testado e certificado no OpenShift através da versão do Kubernetes incluída em cada versão específica do OCP. ⁽¹⁰⁾ Algumas versões do cert-manager têm um problema em que o servidor TLS do webhook pode não renovar automaticamente o respetivo certificado da AC. Para evitar esta situação, o Apigee recomenda a utilização do seguinte: Híbrida v1.13: use a versão 1.15.5+ do cert-manager. Híbrida v1.14: use as versões 1.15.5+ ou 1.16.3+ do cert-manager. Híbrida v1.15: use as versões do cert-manager 1.16.3+ ou 1.17.2+.

Remova/atualize CRDs do Istio

Durante a atualização a partir das versões 1.14.1 ou anteriores do Apigee hybrid, a presença de istio.iodefinições de recursos personalizados (CRDs) num cluster do Apigee hybrid pode causar falhas nas sondagens de prontidão nos contentores discovery dos pods apigee-ingressgateway-manager.

Se o gateway.networking.k8s.io/v1 estiver instalado no seu cluster,a atualização do apigee-ingressgateway-manager pode falhar. Por exemplo, o gateway.networking.k8s.io/v1 é normalmente instalado em clusters executados no Google Distributed Cloud (apenas software) no bare metal v1.32 ou posterior.

Existem duas opções para corrigir estes problemas:

Elimine os istio.io CRDs se não estiver a usar o Istio para qualquer finalidade que não seja o Apigee no seu cluster.
Atualize o apigee-ingressgateway-manager clusterrole para adicionar autorizações para istio.io.

Após cada uma das opções acima, tem de reiniciar os seus pods apigee-ingressgateway-manager.

Consulte o problema conhecido 416634326 e o problema conhecido 419856132 para mais informações sobre CRDs e istio.iogateway.networking.k8s.io/v1 no Apigee hybrid.

Determine se tem istio.io CRDs no seu cluster com o seguinte comando:

kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io

O resultado terá um aspeto semelhante ao seguinte se o cluster tiver istio.io CRDs:

kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io
  authorizationpolicies.security.istio.io
  destinationrules.networking.istio.io
  envoyfilters.networking.istio.io
  gateways.networking.istio.io
  peerauthentications.security.istio.io
  proxyconfigs.networking.istio.io
  requestauthentications.security.istio.io
  serviceentries.networking.istio.io
  sidecars.networking.istio.io
  telemetries.telemetry.istio.io
  virtualservices.networking.istio.io
  wasmplugins.extensions.istio.io
  workloadentries.networking.istio.io
  workloadgroups.networking.istio.io

Opcional: guarde os CRDs localmente caso precise de os recriar:
```
kubectl get crd $(cat istio-crd.csv) -o yaml > istio-crd.yaml
```

Elimine CRDs

Liste os CRDs no seu cluster num ficheiro CSV:istio.io

kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io > istio-crd.csv

Opcional: guarde os CRDs localmente caso precise de os recriar:
```
kubectl get crd $(cat istio-crd.csv) -o yaml > istio-crd.yaml
```
Elimine os CRDs istio.io:
Execução de ensaio:
```
kubectl delete crd $(cat istio-crd.csv) --dry-run=client
```
Dica: pode usar --dry-run=client ou --dry-run=server. Consulte as kubectl delete opções para mais informações.

Executar:
```
kubectl delete crd $(cat istio-crd.csv)
```

Atualize clusterrole

Obtenha o clusterrole apigee-ingressgateway-manager atual:

kubectl get clusterrole apigee-ingressgateway-manager-apigee -o yaml > apigee-ingressgateway-manager-apigee-clusterrole.yaml

Copie o clusterrole para uma nova localização:

cp apigee-ingressgateway-manager-apigee-clusterrole.yaml apigee-ingressgateway-manager-apigee-clusterrole-added-istio-permissions.yaml

Adicione as seguintes autorizações adicionais ao final do ficheiro:

- apiGroups:
  - gateway.networking.k8s.io
  resources:
  - gatewayclasses
  - gateways
  - grpcroutes
  - httproutes
  - referencegrants
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.istio.io
  resources:
  - sidecars
  - destinationrules
  - gateways
  - virtualservices
  - envoyfilters
  - workloadentries
  - serviceentries
  - workloadgroups
  - proxyconfigs
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - security.istio.io
  resources:
  - peerauthentications
  - authorizationpolicies
  - requestauthentications
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - telemetry.istio.io
  resources:
  - telemetries
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - extensions.istio.io
  resources:
  - wasmplugins
  verbs:
  - get
  - list
  - watch

Aplique a função:

kubectl -n APIGEE_NAMESPACE apply -f apigee-ingressgateway-manager-apigee-clusterrole-added-istio-permissions.yaml

Depois de concluir as opções acima, tem de reiniciar os auriculares apigee-ingressgateway-manager.

Indique os pods ingress-manager a reinstalar ou recriar:

kubectl get deployments -n APIGEE_NAMESPACE

Exemplo de saída:

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager       1/1     1            1           32d
apigee-ingressgateway-manager   2/2     2            2           32d

Reinicie os auriculares ingress-manager:

kubectl rollout restart deployment -n APIGEE_NAMESPACE apigee-ingressgateway-manager

Após alguns minutos, monitorize os auriculares apigee-ingressgateway-manager:

watch -n 10 kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-ingressgateway-manager

Exemplo de saída:

NAME                                             READY   STATUS    RESTARTS   AGE
apigee-ingressgateway-manager-12345abcde-678wx   3/3     Running   0          10m
apigee-ingressgateway-manager-12345abcde-901yz   3/3     Running   0          10m

Instale o runtime híbrido 1.15.1

Configure o pipeline de recolha de dados.

A partir da versão híbrida 1.14, o novo pipeline de dados de estatísticas e depuração é ativado por predefinição para todas as organizações híbridas do Apigee. Tem de seguir os passos para ativar o acesso do publicador do Analytics para configurar o fluxo de autorização.

Prepare-se para a atualização dos gráficos Helm

Extraia os gráficos Helm do Apigee.

Os gráficos híbridos do Apigee estão alojados no Google Artifact Registry:

oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts

Use o comando pull para copiar todos os gráficos Helm do Apigee hybrid para o seu armazenamento local com o seguinte comando:

export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.15.1
helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar

Atualize o cert-manager, se necessário.
Se precisar de atualizar a versão do cert-manager, instale a nova versão com o seguinte comando:
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.17.4/cert-manager.yaml
```
Consulte o artigo Plataformas e versões suportadas: cert-manager para ver uma lista das versões suportadas.

Nota: algumas versões do cert-manager têm um problema em que o servidor TLS do webhook pode não renovar automaticamente o respetivo certificado da CA. Para evitar esta situação, a Apigee recomenda a utilização das versões 1.16.3+ ou 1.17.2+ do cert-manager.
Se o seu espaço de nomes do Apigee não for apigee, edite o ficheiro apigee-operator/etc/crds/default/kustomization.yaml e substitua o valor namespace pelo seu espaço de nomes do Apigee.
```
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: APIGEE_NAMESPACE
```
Se estiver a usar apigee como espaço de nomes, não precisa de editar o ficheiro.

Instale os CRDs do Apigee atualizados:

Nota: este é o único método suportado para instalar CRDs do Apigee. Não use kubectl apply sem -k, não omita --server-side.

Use a funcionalidade de teste de execução kubectl executando o seguinte comando:

kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run=server

Depois de fazer a validação com o comando de teste, execute o seguinte comando:

kubectl apply -k  apigee-operator/etc/crds/default/ \
  --server-side \
  --force-conflicts \
  --validate=false

Valide a instalação com o comando kubectl get crds:

kubectl get crds | grep apigee

O resultado deve ter um aspeto semelhante ao seguinte:

apigeedatastores.apigee.cloud.google.com                    2024-08-21T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2024-08-21T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2024-08-21T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2024-08-21T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2024-08-21T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2024-08-21T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2024-08-21T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2024-08-21T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2024-08-21T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2024-08-21T14:48:35Z

Verifique as etiquetas nos nós do cluster. Por predefinição, o Apigee agenda pods de dados em nós com a etiqueta cloud.google.com/gke-nodepool=apigee-data e os pods de tempo de execução são agendados em nós com a etiqueta cloud.google.com/gke-nodepool=apigee-runtime. Pode personalizar as etiquetas do conjunto de nós no ficheiro overrides.yaml.

Para mais informações, consulte o artigo Configurar pools de nós dedicados.

Instale os gráficos Helm do Apigee Hybrid

Nota: antes de executar qualquer um dos comandos de instalação/atualização do Helm, use a funcionalidade de teste do Helm adicionando --dry-run no final do comando. Consulte helm -h para ver uma lista dos comandos, das opções e da utilização suportados.

Se não o tiver feito, navegue para o diretório APIGEE_HELM_CHARTS_HOME. Execute os seguintes comandos a partir desse diretório.

Atualize o operador/controlador do Apigee:

Nota: este passo requer autorizações de cluster elevadas. Execute helm -h ou helm upgrade -h para ver detalhes.

Execução de ensaio:

helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Atualize o gráfico:

helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Valide a instalação do operador do Apigee:

helm ls -n APIGEE_NAMESPACE

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee   3          2024-08-21 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.15.1   1.15.1

Verifique se está em funcionamento, verificando a respetiva disponibilidade:

kubectl -n APIGEE_NAMESPACE get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Atualize o repositório de dados do Apigee:

Execução de ensaio:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Atualize o gráfico:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Verifique se o apigeedatastore está em funcionamento verificando o respetivo estado:

kubectl -n APIGEE_NAMESPACE get apigeedatastore default

NAME      STATE       AGE
default   running    2d

Atualize a telemetria do Apigee:

Execução de ensaio:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Atualize o gráfico:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Verifique se está a funcionar corretamente verificando o respetivo estado:

kubectl -n APIGEE_NAMESPACE get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Atualize o Redis do Apigee:

Execução de ensaio:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Atualize o gráfico:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Verifique se está a funcionar corretamente verificando o respetivo estado:

kubectl -n APIGEE_NAMESPACE get apigeeredis default

NAME      STATE     AGE
default   running   2d

Atualize o Apigee Ingress Manager:

Execução de ensaio:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

Atualize o gráfico:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

Verifique se está em funcionamento, verificando a respetiva disponibilidade:

kubectl -n APIGEE_NAMESPACE get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Atualize a organização do Apigee:
Execução de ensaio:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server
```
Atualize o gráfico:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE
```
Verifique se está em funcionamento consultando o estado da organização respetiva:
```
kubectl -n APIGEE_NAMESPACE get apigeeorg
```
```
NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d
```
Nota: se o comando de atualização falhar com o erro Forbidden: state: releasing, os componentes existentes continuam no estado de lançamento. Pode aguardar que a atualização atual seja concluída e, em seguida, tentar novamente. Verifique o estado do lançamento com o seguinte comando:
```
kubectl get org -n APIGEE_NAMESPACE
```
Atualize o ambiente.
Tem de instalar um ambiente de cada vez. Especifique o ambiente com --set env=ENV_NAME.

Execução de ensaio:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
```
- ENV_RELEASE_NAME é um nome usado para monitorizar a instalação e as atualizações do gráfico apigee-env. Este nome tem de ser exclusivo dos outros nomes de lançamentos do Helm na sua instalação. Normalmente, este valor é igual a ENV_NAME. No entanto, se o seu ambiente tiver o mesmo nome que o seu grupo de ambientes, tem de usar nomes de lançamentos diferentes para o ambiente e o grupo de ambientes, por exemplo, dev-env-release e dev-envgroup-release. Para mais informações sobre lançamentos no Helm, consulte Três conceitos importantes na documentação do Helm.
- ENV_NAME é o nome do ambiente que está a atualizar.
- OVERRIDES_FILE é o seu novo ficheiro de substituições para a versão 1.15.1
Atualize o gráfico:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Verifique se está em funcionamento verificando o estado do ambiente respetivo:
```
kubectl -n APIGEE_NAMESPACE get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
```

Nota: se o comando de atualização falhar com o erro Forbidden: state: releasing, os componentes existentes continuam no estado de lançamento. Pode aguardar que a atualização atual seja concluída e, em seguida, tentar novamente. Verifique o estado do lançamento com o seguinte comando:

kubectl get env -n APIGEE_NAMESPACE

Atualize os grupos de ambientes (virtualhosts).
1. Tem de atualizar um grupo de ambientes (virtualhost) de cada vez. Especifique o grupo do ambiente com --set envgroup=ENV_GROUP_NAME. Repita os seguintes comandos para cada grupo de ambientes mencionado no ficheiro overrides.yaml:
  Execução de ensaio:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
```
  ENV_GROUP_RELEASE_NAME é o nome com o qual instalou anteriormente o gráfico apigee-virtualhost. Normalmente, é ENV_GROUP_NAME.
  
  Atualize o gráfico:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  Nota: ENV_GROUP_RELEASE_NAME tem de ser exclusivo no espaço de nomes apigee.
  Por exemplo, se tiver um ambiente denominado prod e um grupo de ambientes denominado prod, defina o valor de ENV_GROUP_RELEASE_NAME para algo único, como prod-envgroup.
2. Verifique o estado do ApigeeRoute (AR).
  A instalação do virtualhosts cria o ApigeeRouteConfig (ARC), que cria internamente o ApigeeRoute (AR) assim que o monitor do Apigee extrai detalhes relacionados com o grupo de ambientes do plano de controlo. Por conseguinte, verifique se o estado do AR correspondente está em execução:
```
kubectl -n APIGEE_NAMESPACE get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n APIGEE_NAMESPACE get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
```
Depois de verificar que todas as instalações foram atualizadas com êxito, elimine a versão apigee-operator mais antiga do espaço de nomes apigee-system.
1. Desinstale a versão operator antiga:
```
helm delete operator -n apigee-system
```
2. Elimine o espaço de nomes apigee-system:
```
kubectl delete namespace apigee-system
```

Atualize operator novamente no seu espaço de nomes do Apigee para reinstalar os recursos com âmbito de cluster eliminados:

helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

Valide as políticas após a atualização da versão 1.14.0 ou anterior

Use este procedimento para validar o comportamento da política JavaCallout após a atualização a partir da versão 1.14.0.

Verifique se os ficheiros JAR Java pedem autorizações desnecessárias.
Após a implementação da política, verifique os registos de tempo de execução para ver se a seguinte mensagem de registo está presente: "Failed to load and initialize class ...". Se observar esta mensagem, sugere que o JAR implementado pediu autorizações desnecessárias. Para resolver este problema, investigue o código Java e atualize o ficheiro JAR.
Investigue e atualize o código Java.
Reveja qualquer código Java (incluindo dependências) para identificar a causa de operações potencialmente não permitidas. Quando o encontrar, modifique o código-fonte conforme necessário.
Teste as políticas com a verificação de segurança ativada.
Num ambiente de não produção, ative a flag de verificação de segurança e volte a implementar as suas políticas com um JAR atualizado. Para definir a flag:
- No ficheiro apigee-env/values.yaml, defina conf_security-secure.constructor.only como true em runtime:cwcAppend:. Por exemplo:
```
# Apigee Runtime
runtime:
  cwcAppend:
    conf_security-secure.constructor.only: true
```
- Atualize o gráfico apigee-env para que a alteração seja aplicada ao ambiente. Por exemplo:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Se a mensagem de registo "Failed to load and initialize class ..." ainda estiver presente, continue a modificar e testar o JAR até que a mensagem de registo deixe de aparecer.
Ative a verificação de segurança no ambiente de produção.
Depois de testar e validar exaustivamente o ficheiro JAR no ambiente de não produção, ative a verificação de segurança no seu ambiente de produção definindo a flag conf_security-secure.constructor.only como true e atualizando o gráfico apigee-env para o ambiente de produção para aplicar a alteração.

Reverter para uma versão anterior

Para reverter para a versão anterior, use a versão mais antiga do gráfico para reverter o processo de atualização na ordem inversa. Comece por apigee-virtualhost e avance até apigee-operator e, em seguida, reverta os CRDs.

Dica: se souber a versão de lançamento mais recente, pode usar o comando helm rollback em vez do comando helm upgrade descrito abaixo.

Reverta todos os gráficos de apigee-virtualhost para apigee-datastore. Os comandos seguintes pressupõem que está a usar os gráficos da versão anterior (v1.14.x).

Execute o seguinte comando para cada grupo de ambientes:

helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f 1.14_OVERRIDES_FILE

Execute o seguinte comando para cada ambiente:

helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f 1.14_OVERRIDES_FILE

Reverta os restantes gráficos, exceto o gráfico apigee-operator.

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade redis apigee-redis/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.14_OVERRIDES_FILE

Crie o espaço de nomes apigee-system.
```
kubectl create namespace apigee-system
```

Corrija a anotação de recursos de volta para o espaço de nomes apigee-system.

kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-namespace='apigee-system'

Se também tiver alterado o nome de lançamento, atualize a anotação com o nome de lançamento operator.
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-name='operator'
```

Instale apigee-operator novamente no espaço de nomes apigee-system.

helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.14_OVERRIDES_FILE

Reverta os CRDs reinstalando os CRDs mais antigos.

kubectl apply -k apigee-operator/etc/crds/default/ \
  --server-side \
  --force-conflicts \
  --validate=false

Limpe a versão apigee-operator do espaço de nomes APIGEE_NAMESPACE para concluir o processo de reversão.
```
helm uninstall operator -n APIGEE_NAMESPACE
```
Alguns recursos com âmbito de cluster, como clusterIssuer, são eliminados quando operator é desinstalado. Reinstale-as com o seguinte comando:
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.14_OVERRIDES_FILE
```

Atualizar o Apigee Hybrid para a versão 1.15

Alterações do Apigee Hybrid v1.14

Pré-requisitos

Antes de atualizar para a versão 1.15.1: limitações e notas importantes

Atualização para a versão 1.15.1: vista geral

Prepare-se para atualizar para a versão 1.15

Faça uma cópia de segurança da sua instalação híbrida

Linux

Mac OS

Windows

Prod

Não prod

Atualize a versão do Kubernetes

Clique para expandir uma lista de plataformas suportadas

Versões suportadas

Componentes

Versões não suportadas

Componentes

Remova/atualize CRDs do Istio

Elimine CRDs

Atualize clusterrole

Instale o runtime híbrido 1.15.1

Configure o pipeline de recolha de dados.

Prepare-se para a atualização dos gráficos Helm

Instale os gráficos Helm do Apigee Hybrid

Valide as políticas após a atualização da versão 1.14.0 ou anterior

Reverter para uma versão anterior