Esta página foi traduzida pela API Cloud Translation.

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

Este procedimento abrange o upgrade da Apigee híbrida versão 1.15.x para a versão 1.16.0.

Mudanças em relação à Apigee híbrida v1.15

Observe as seguintes mudanças:

Perfis Seccomp: a partir da versão 1.16, a Apigee híbrida oferece a capacidade de aplicar perfis Seccomp aos componentes de ambiente de execução, melhorando significativamente a postura de segurança da sua implantação. Com esse recurso, os administradores do Apigee e as equipes de segurança podem restringir as chamadas de sistema que um processo em contêiner pode fazer ao kernel do host. Ao limitar um contêiner apenas às syscalls necessárias, você pode:
- Melhorar a segurança: reduzir o risco de invasões de contêineres e escalonamento de privilégios.
- Aplique o princípio de privilégio mínimo: garanta que os componentes tenham acesso apenas às chamadas de sistema exatas necessárias para a operação deles.
- Atender à conformidade: ofereça um controle essencial para atender a requisitos rigorosos de conformidade de segurança.
Para mais informações, consulte Configurar perfis do Seccomp para segurança de pods.
Remoção da UDCA na Apigee híbrida: Na versão 1.16 da Apigee híbrida, o componente Agente Universal de Coleta de Dados (UDCA) foi removido. As responsabilidades de enviar dados de análise, rastreamento e status de implantação para o plano de controle do Apigee agora são processadas usando um pipeline de dados baseado no Google Cloud Pub/Sub. O uso do pipeline de dados baseado no Pub/Sub é o mecanismo de coleta de dados padrão desde a versão 1.14.0 da Apigee híbrida.
Conta de serviço apigee-guardrails: na v1.16.0, a Apigee híbrida apresenta uma conta de serviço do Google IAM apigee-guardrails. Usado pelo gráfico apigee-operator durante a instalação para verificar se todas as APIs necessárias estão ativadas no projeto.
Veja estes tópicos:
Suporte às versões 1.18 e 1.19 do cert-manager: A Apigee híbrida v1.16 oferece suporte às versões 1.18 e 1.19 do cert-manager. Na versão 1.18 do cert-manager, há uma mudança no valor padrão de Certificate.Spec.PrivateKey.rotationPolicy que pode afetar o tráfego. Se você estiver fazendo upgrade de uma versão anterior da Apigee híbrida para a versão 1.18 ou mais recente do cert-manager, siga o procedimento Fazer upgrade do cert-manager neste guia.

Observação:isso não afeta novas instalações da Apigee híbrida v1.6.

Para mais informações sobre os recursos da versão 1.16 do Hybrid, consulte as notas da versão 1.16.0 do Apigee Hybrid.

Pré-requisitos

Antes de fazer upgrade para a versão híbrida 1.16, verifique se a instalação atende aos seguintes requisitos:

Se sua instalação híbrida executa uma versão anterior à v1.15, é necessário fazer upgrade para a versão 1.15 antes de fazer upgrade para a v1.16. Consulte Como fazer upgrade da Apigee híbrida para a versão 1.15.
Helm v3.14.2 ou mais recente.
kubectl: uma versão compatível de kubectl adequada para a versão da plataforma Kubernetes. Consulte Plataformas e versões compatíveis: kubectl.
cert-manager: uma versão compatível do cert-manager. Consulte Plataformas e versões compatíveis: cert-manager. Se necessário, faça upgrade do cert-manager na seção Preparação para fazer upgrade para a versão 1.16 abaixo.

Antes de fazer upgrade para a versão 1.16.0: limitações e observações importantes

A Apigee híbrida 1.16.0 apresenta um novo limite de proxy por ambiente aprimorado que permite implantar mais proxies e fluxos compartilhados em um único ambiente. Consulte Limites: proxies de API para entender os limites do número de proxies e fluxos compartilhados que podem ser implantados por ambiente. Esse recurso está disponível apenas em organizações híbridas recém-criadas e não pode ser aplicado a organizações atualizadas. Para usar esse recurso, faça uma nova instalação da híbrida 1.16.0 e crie uma organização.

Esse recurso está disponível exclusivamente como parte do plano de assinatura de 2024, e está sujeito aos direitos concedidos nessa assinatura. Consulte Limites aprimorados de proxy por ambiente para saber mais sobre esse recurso.
O upgrade para a Apigee híbrida versão 1.16 pode exigir inatividade.

Ao fazer upgrade do controlador da Apigee para a versão 1.16.0, 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, depois de iniciar o upgrade, 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, o backup e a restauração do Cassandra não funcionarão com versões mistas. Por exemplo, um backup da versão híbrida 1.15 não pode ser usado para restaurar uma instância da versão híbrida 1.16.
As mudanças no plano de gerenciamento não precisam ser totalmente suspensas durante um upgrade. Todas as suspensões temporárias necessárias para as mudanças no plano de gerenciamento estão nas instruções de upgrade abaixo.

Como fazer upgrade para a versão 1.16.0

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

Preparar para fazer upgrade para a versão 1.16

Faça o backup da 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 arquivos em que você instalou os gráficos do Helm. Se necessário, mude o diretório para seu 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 backup do diretório $APIGEE_HELM_CHARTS_HOME/ da versão 1.15. É possível usar qualquer processo de backup. Por exemplo, você pode criar um arquivo tar de todo o diretório com:
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.15-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Faça o backup do banco de dados Cassandra seguindo as instruções em Backup e recuperação do Cassandra.
Verifique se o certificado TLS e os arquivos de chave (.crt, .key e/ou .pem) estão no diretório $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

Fazer upgrade da versão do Kubernetes

Verifique a versão da plataforma do Kubernetes e, se necessário, faça upgrade para uma versão compatível com as versões híbridas 1.15 e 1.16. Siga a documentação da plataforma se precisar de ajuda.

Clique para expandir uma lista de plataformas compatíveis

Versões compatíveis

	1.14	1.15	1.16
GKE em Google Cloud	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	1.31.x 1.32.x 1.33.x
GKE na AWS	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	1.31.x 1.32.x 1.33.x
GKE no Azure	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	1.31.x 1.32.x 1.33.x
Google Distributed Cloud (somente software) no VMware ⁽³⁾	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	1.31.x 1.32.x 1.33.x
Google Distributed Cloud (somente software) em bare metal	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	1.31.x 1.32.x 1.33.x
EKS	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	1.31.x 1.32.x 1.33.x
AKS	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	1.31.x 1.32.x 1.33.x
OpenShift⁽⁷⁾	4.13 4.14 4.15 4.16 4.17	4.16 4.17 4.18	4.18 4.19 4.20
Rancher Kubernetes Engine (RKE)(7)	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	1.31.x 1.32.x 1.33.x
VMware Tanzu	v1.26.x	v1.26.x	v1.26.x
Componentes	1.14	1.15	1.16
Cloud Service Mesh	1.22.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.16.x⁽⁸⁾ 1.17.x⁽⁸⁾	1.16.x⁽⁸⁾ 1.17.x⁽⁸⁾ 1.18.x⁽⁹⁾ 1.19.x⁽⁹⁾
Cassandra	4.0	4.0	4.0
Kubernetes	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	1.30.x 1.31.x 1.32.x 1.33.x
kubectl	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	1.30.x 1.31.x 1.32.x 1.33.x
Helm	3.14.2 a 3.x.x	3.14.2 a 3.x.x	3.17.0 a 3.x.x
Driver CSI do Secret Store	1.4.6+	1.4.6+	1.4.6+
Vault	1.17.2	1.17.2	1.17.2
⁽¹⁾ As datas de EOL oficiais da Apigee híbrida versões 1.13 e anteriores foram atingidas. Os patches mensais regulares não estão mais disponíveis. Essas versões não têm mais suporte oficial, exceto para clientes com exceções explícitas e oficiais para suporte contínuo. Outros clientes precisam fazer o upgrade. ⁽²⁾ O Cloud Service Mesh é instalado automaticamente com a Apigee híbrida 1.9 e mais recentes. ⁽³⁾ O Vault não é certificado em Google Distributed Cloud for VMware. ⁽⁴⁾ Suporte disponível para a Apigee híbrida versão 1.10.5 e mais recentes. ⁽⁵⁾ Suporte disponível para a Apigee híbrida versão 1.11.2 e mais recentes. ⁽⁶⁾ Suporte disponível para a Apigee híbrida versão 1.12.1 e mais recentes. ⁽⁷⁾ A Apigee híbrida é testada e certificada no OpenShift usando a 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 não consegue renovar automaticamente o certificado da CA. Para evitar isso, a Apigee recomenda usar: Hybrid v1.13:use a versão 1.15.5+ do cert-manager. Hybrid v1.14:use as versões 1.15.5+ ou 1.16.3+ do cert-manager. Apigee híbrida v1.15:use as versões 1.16.3+ ou 1.17.2+ do cert-manager. Hybrid v1.16:use as versões 1.16.3+, 1.17.2+, 1.18.0+ ou 1.19.0+ do cert-manager. Consulte o problema conhecido 465834046 para as versões 1.18 e 1.19 do cert-manager. ⁽⁹⁾ A versão 1.18 do cert-manager apresenta uma mudança na política padrão de rotação de chaves privadas que pode causar interrupções no tráfego. Consulte o problema conhecido 465834046 para uma solução alternativa.

Versões incompatíveis

	1.6 ⁽¹⁾	1.7 ⁽¹⁾	1.8 ⁽¹⁾	1.9 ⁽¹⁾	1.10 ⁽¹⁾	1.11 ⁽¹⁾	1.12 ⁽¹⁾	1.13 ⁽¹⁾
GKE em 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)}	1.27.x 1.28.x 1.29.x 1.30.x
GKE na 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)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x
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)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)(8)} 1.30.x
Google Distributed Cloud (somente 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)}	1.16.x (K8s v1.27.x) 1.28.x 1.29.x 1.30.x
Google Distributed Cloud (somente 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)}	1.16.x (K8s v1.27.x) 1.28.x 1.29.x 1.30.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.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)}	1.27.x 1.28.x 1.29.x 1.30.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 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)}	1.27.x 1.28.x 1.29.x 1.30.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 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)}	4.12 4.13 4.14 4.15 4.16
Rancher Kubernetes Engine (RKE)(7)	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)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x 1.30.x
VMware Tanzu	N/A	N/A	N/A	N/A	N/A	N/A	v1.26.x	v1.26.x
Componentes	1.6 ⁽¹⁾	1.7 ⁽¹⁾	1.8 ⁽¹⁾	1.9 ⁽¹⁾	1.10 ⁽¹⁾	1.11 ⁽¹⁾	1.12 ⁽¹⁾	1.13 ⁽¹⁾
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⁽²⁾	1.19.x⁽²⁾
JDK	JDK 11	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	1.15.x⁽⁸⁾ 1.16.x⁽⁸⁾ 1.17.x⁽⁸⁾
Cassandra	3.11	3.11	3.11	3.11	3.11	3.11	4.0	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	1.27.x 1.28.x 1.29.x 1.30.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	1.27.x 1.28.x 1.29.x 1.30.x
Helm					3.10+	3.10+	3.14.2 a 3.x.x	3.14.2 a 3.x.x
Driver CSI do Secret Store						1.3.4+	1.4.1+	1.4.6+
Vault						1.13.x	1.15.2	1.15.2
⁽¹⁾ As datas de EOL oficiais da Apigee híbrida versões 1.13 e anteriores foram atingidas. Os patches mensais regulares não estão mais disponíveis. Essas versões não têm mais suporte oficial, exceto para clientes com exceções explícitas e oficiais para suporte contínuo. Outros clientes precisam fazer o upgrade. ⁽²⁾ O Cloud Service Mesh é instalado automaticamente com a Apigee híbrida 1.9 e mais recentes. ⁽³⁾ O Vault não é certificado em Google Distributed Cloud for VMware. ⁽⁴⁾ Suporte disponível para a Apigee híbrida versão 1.10.5 e mais recentes. ⁽⁵⁾ Suporte disponível para a Apigee híbrida versão 1.11.2 e mais recentes. ⁽⁶⁾ Suporte disponível para a Apigee híbrida versão 1.12.1 e mais recentes. ⁽⁷⁾ A Apigee híbrida é testada e certificada no OpenShift usando a 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 não consegue renovar automaticamente o certificado da CA. Para evitar isso, a Apigee recomenda usar: Hybrid v1.13:use a versão 1.15.5+ do cert-manager. Hybrid v1.14:use as versões 1.15.5+ ou 1.16.3+ do cert-manager. Apigee híbrida v1.15:use as versões 1.16.3+ ou 1.17.2+ do cert-manager. Hybrid v1.16:use as versões 1.16.3+, 1.17.2+, 1.18.0+ ou 1.19.0+ do cert-manager. Consulte o problema conhecido 465834046 para as versões 1.18 e 1.19 do cert-manager. ⁽⁹⁾ A versão 1.18 do cert-manager apresenta uma mudança na política padrão de rotação de chaves privadas que pode causar interrupções no tráfego. Consulte o problema conhecido 465834046 para uma solução alternativa.

Extraia os gráficos do Apigee Helm.

Os gráficos da Apigee híbrida são hospedados no Google Artifact Registry:

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

Usando o comando pull, copie todos os gráficos da Apigee híbrida do Helm para o armazenamento local com o seguinte comando:

export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.16.0
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

Editar `kustomization.yaml` para um namespace personalizado da Apigee

Se o namespace da Apigee não for apigee, edite o arquivo apigee-operator/etc/crds/default/kustomization.yaml e substitua o valor namespace pelo namespace da Apigee.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: APIGEE_NAMESPACE

Se você estiver usando apigee como namespace, não será necessário editar o arquivo.

Instale os CRDs atualizados da Apigee:

Observação: esse é o único método compatível para instalar CRDs da Apigee. Não use kubectl apply sem -k, não omita --server-side.

Use o recurso de simulaçã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 validar com o comando de simulação, execute o seguinte:

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

A resposta será semelhante a esta:

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 os identificadores nos nós do cluster. Por padrão, a Apigee programa pods de dados em nós com o rótulo cloud.google.com/gke-nodepool=apigee-data e os pods de ambiente de execução são programados em nós com o rótulo cloud.google.com/gke-nodepool=apigee-runtime. É possível personalizar os rótulos do pool de nós no arquivo overrides.yaml.

Para mais informações, consulte Como configurar pools de nós dedicados.

Configurar a conta de serviço `apigee-guardrails`

A partir da versão híbrida 1.16, a conta de serviço apigee-guardrails é necessária para fazer upgrade do gráfico apigee-operator.

No procedimento a seguir, selecione o tipo de autenticação de conta de serviço que você está usando.

Verifique se é possível executar create-service-account. Se você acabou de fazer o download dos gráficos, o arquivo create-service-account pode não estar em um modo executável. No diretório APIGEE_HELM_CHARTS_HOME, execute o seguinte comando:
```
./apigee-operator/etc/tools/create-service-account --help
```
Se a saída informar permission denied, será necessário tornar o arquivo executável, por exemplo, com chmod no Linux, MacOS ou UNIX ou no Windows Explorer ou com o comando icacls no Windows. Exemplo:
```
chmod +x ./apigee-operator/etc/tools/create-service-account
```
Crie a conta de serviço apigee-guardrails:
Secrets do Kubernetes
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Esse comando cria a conta de serviço apigee-guardrails e faz o download da chave para o diretório service-accounts/.
Arquivos JSON
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir ./apigee-operator/
```
Esse comando cria a conta de serviço apigee-guardrails e faz o download da chave para o diretório de gráficos apigee-operator/.
Vault
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Esse comando cria a conta de serviço apigee-guardrails e faz o download da chave para o diretório service-accounts/.
WIF para GKE
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Esse comando cria a conta de serviço apigee-guardrails e faz o download da chave para o diretório apigee-operator/etc/tools/service-accounts/. Você não precisa do arquivo de chave baixado e pode excluí-lo.
WIF em outras plataformas
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Esse comando cria a conta de serviço apigee-guardrails e faz o download da chave para o diretório service-accounts/.

Configure a autenticação para a conta de serviço apigee-guardrails:

Secrets do Kubernetes

Crie o secret do Kubernetes usando o arquivo de chave da conta de serviço apigee-guardrails no diretório service-accounts/:

kubectl create secret generic apigee-guardrails-svc-account \
    --from-file="client_secret.json=$APIGEE_HELM_CHARTS_HOME/service-accounts/$PROJECT_ID-apigee-guardrails.json" \
    -n $APIGEE_NAMESPACE

Adicione a instrução a seguir ao seu arquivo overrides.yaml:

guardrails:
  serviceAccountRef: apigee-guardrails-svc-account

Arquivos JSON

Adicione o seguinte ao arquivo overrides.yaml, usando o caminho para o arquivo de chave da conta de serviço apigee-guardrails no diretório apigee-operator/:

guardrails:
  serviceAccountPath: $PROJECT_ID-apigee-guardrails.json

Vault

Atualize o secret do Vault secret/data/apigee/orgsakeys para adicionar uma entrada guardrails com o conteúdo do arquivo de chave da conta de serviço apigee-guardrails.
```
vault kv patch secret/apigee/orgsakeys guardrails="$(cat ./service-accounts/hybrid115-apigee-guardrails.json)"
```

A conta de serviço do Kubernetes (KSA) para os guardrails é chamada de apigee-operator-guardrails-sa. Adicione o KSA do Guardrails às contas de serviço específicas da organização vinculadas à função apigee-orgsakeys no Vault.

Confira a lista atual de vinculações de KSA:

vault read auth/kubernetes/role/apigee-orgsakeys

A saída precisa estar no seguinte formato:

Key                                         Value
---                                         -----
alias_name_source                           serviceaccount_uid
bound_service_account_names                 BOUND_SERVICE_ACCOUNT_NAMES
bound_service_account_namespace_selector    n/a
bound_service_account_namespaces            APIGEE_NAMESPACE

Na saída, BOUND_SERVICE_ACCOUNT_NAMES é uma lista de nomes de conta de serviço separados por vírgulas. Adicione apigee-operator-guardrails-sa à lista de nomes. Por exemplo (sem as quebras de linha adicionadas para facilitar a leitura):

apigee-manager,apigee-cassandra-default,apigee-cassandra-backup-sa,
apigee-cassandra-restore-sa,apigee-cassandra-schema-setup-myhybrido
rg-5b044c1,apigee-cassandra-schema-val-myhybridorg-5b044c1,apigee-c
assandra-user-setup-myhybridorg-5b044c1,apigee-mart-myhybridorg-5b0
44c1,apigee-mint-task-scheduler-myhybridorg-5b044c1,apigee-connect-
agent-myhybridorg-5b044c1,apigee-watcher-myhybridorg-5b044c1,apigee
-metrics-apigee-telemetry,apigee-open-telemetry,apigee-synchronizer
-myhybridorg-dev-ee52aca,apigee-runtime-telemetry-collector-apigee-
telemetry,apigee-logger-apigee-e-myhybrridorg-dev-ee52aca,apigee-sy
nchronizer-myhybridog-prod-2d0221c,apigee-runtime-myhybridorg-prod-
2d0221c,apigee-operator-guardrails-sa

Atualize as vinculações para a função apigee-orgsakeys com a lista atualizada de nomes de conta de serviço:

vault write auth/kubernetes/role/apigee-orgsakeys \
  bound_service_account_names=UPDATED_BOUND_SERVICE_ACCOUNT_NAMES \
  bound_service_account_namespaces=APIGEE_NAMESPACE \
  policies=apigee-orgsakeys-auth \
  ttl=1m

Adicione "proteções" ao SecretProviderClass
1. Edite o arquivo spc-org.yaml.
  Dica:se você precisar recriar, use o modelo em Como armazenar chaves de conta de serviço no Hashicorp Vault: criar objetos SecretProviderClass.
2. Em spec.parameters.objects, adicione uma entrada de proteções:
```
      - objectName: "guardrails"
        secretPath: ""
        secretKey: ""
```
  Dica:para ambientes com scripts ou para automatizar essa mudança, use o processador YAML de linha de comando yq.
  Comando:para adicionar a entrada "guardrails" a spc-org.yaml no lugar, use o seguinte comando:
```
yq -i '.spec.parameters.objects |= (
    from_yaml + [
        {
            "objectName": "guardrails",
            "secretPath": "",
            "secretKey": ""
        }
    ] | to_yaml
)' spc-org.yaml
```
  Esse comando analisa a string YAML incorporada no campo objects, adiciona o novo item à lista e grava o resultado de volta.
3. Atualize seu SecretProviderClass:
```
kubectl -n APIGEE_NAMESPACE apply -f spc-org.yaml
```

WIF para GKE

A conta de serviço do Kubernetes (KSA) para os guardrails é chamada de apigee-operator-guardrails-sa. Crie a vinculação para a conta de serviço do Google (GSA) apigee-guardrails com o seguinte comando:

gcloud iam service-accounts add-iam-policy-binding apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:$PROJECT_ID.svc.id.goog[$APIGEE_NAMESPACE/apigee-operator-guardrails-sa]" \
    --project $PROJECT_ID

Adicione a instrução a seguir ao seu arquivo overrides.yaml:

guardrails:
  gsa: apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com

WIF em outras plataformas

A conta de serviço do Kubernetes (KSA) para os guardrails é chamada de apigee-operator-guardrails-sa. Você precisa conceder à KSA de proteção acesso para representar a conta de serviço do Google (GSA) apigee-guardrails e configurar substituições para usar um arquivo de configuração de credenciais.

Conceda à KSA acesso para representar a GSA com o seguinte comando:

Modelo

gcloud iam service-accounts add-iam-policy-binding \
  apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
  --member="principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/system:serviceaccount:APIGEE_NAMESPACE:apigee-operator-guardrails-sa" \
  --role=roles/iam.workloadIdentityUser

Exemplo

gcloud iam service-accounts add-iam-policy-binding \
  apigee-guardrails@my-project.iam.gserviceaccount.com \
  --member="principal://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/my-pool/subject/system:serviceaccount:apigee:apigee-operator-guardrails-sa" \
  --role=roles/iam.workloadIdentityUser

Em que:

PROJECT_ID: é seu ID do projeto no Google Cloud.
PROJECT_NUMBER: o número do projeto em que você criou o pool de identidades da carga de trabalho.
POOL_ID: o ID do pool de identidade da carga de trabalho.
APIGEE_NAMESPACE: o namespace em que a Apigee híbrida está instalada.

Crie um arquivo de configuração de credencial para a conta de serviço apigee-guardrails:

gcloud iam workload-identity-pools create-cred-config \
  projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/providers/WORKLOAD_PROVIDER_ID \
  --service-account=apigee-guardrails@$PROJECT_ID.iam.gserviceaccount.com \
  --credential-source-file=/var/run/service-account/token \
  --credential-source-type=text \
  --output-file=apigee-guardrails-credential-configuration.json

Em que WORKLOAD_PROVIDER_ID é o ID do provedor do pool de identidades da carga de trabalho.

Configure o apigee-guardrails para usar a federação de identidade da carga de trabalho com um dos seguintes métodos:
WIF: secrets
1. Crie um novo secret do Kubernetes usando o arquivo de origem da credencial para cada arquivo de configuração de credencial.
  kubectl create secret -n APIGEE_NAMESPACE generic guardrails-workload-identity-secret --from-file="client_secret.json=./apigee-guardrails-credential-configuration.json"
2. Substitua o valor de serviceAccountRef pelo novo secret:
  guardrails: serviceAccountRef: guardrails-workload-identity-secret
WIF: arquivos

Mova o arquivo apigee-guardrails-credential-configuration.json gerado para o diretório de gráficos apigee-operator/.

Adicione a instrução a seguir ao seu arquivo overrides.yaml:
```
guardrails:
  serviceAccountPath: apigee-guardrails-credential-configuration.json
```
WIF: Vault

Atualize a chave da conta de serviço para guardrails no Vault com o arquivo de origem de credenciais correspondente:
```
SAKEY=$(cat .apigee-guardrails-credential-configuration.json); kubectl -n APIGEE_NAMESPACE exec vault-0 -- vault kv patch secret/apigee/orgsakeys guardrails="$SAKEY"
```
Consulte Storing service account keys in Hashicorp Vault para mais informações.

Fazer upgrade do cert-manager

A Apigee híbrida v1.16 é compatível com as versões 1.16 a 1.19 do cert-manager. Há uma mudança no cert-manager 1.18 que pode causar um problema com seu tráfego. Na versão 1.18 do cert-manager, o valor padrão de Certificate.Spec.PrivateKey.rotationPolicy foi mudado de Never para Always. Para instalações atualizadas da Apigee híbrida, isso pode causar um problema com o tráfego. Ao fazer upgrade para a versão híbrida 1.16 de uma versão anterior, edite o certificado apigee-ca para compensar essa mudança ou mantenha a versão do cert-manager na versão 1.17.x ou anterior.

Antes de fazer upgrade do cert-manager para a versão 1.18 ou 1.19, siga as etapas abaixo para editar o certificado apigee-ca e definir o valor de Certificate.Spec.PrivateKey.rotationPolicy como Never.

Verifique o conteúdo do certificado apigee-ca para conferir se rotationPolicy está definido:

Dica:se você estiver usando um namespace personalizado do cert-manager, substitua cert-manager pelo namespace correto nos comandos a seguir.

kubectl get certificate apigee-ca -n cert-manager -o yaml

Procure os valores em spec.privateKey na saída:

...
spec:
  commonName: apigee-hybrid
  duration: 87600h
  isCA: true
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: apigee-root-certificate-issuer
  privateKey:
    algorithm: ECDSA
    # Note: rotationPolicy would appear here if it is set.
    size: 256
  secretName: apigee-ca
...

Se rotationPolicy não estiver definido ou se estiver definido como Always, edite o certificado apigee-ca para definir o valor de rotationPolicy como Never:

Faça primeiro uma simulação:

kubectl patch Certificate \
  --dry-run=server \
  -n cert-manager \
  --type=json \
  -p='[{"op": "replace", "path": "/spec/privateKey/rotationPolicy", "value": "Never"}]' \
  -o=yaml \
  apigee-ca

Adicione um patch ao certificado:

kubectl patch Certificate \
  -n cert-manager \
  --type=json \
  -p='[{"op": "replace", "path": "/spec/privateKey/rotationPolicy", "value": "Never"}]' \
  -o=yaml \
  apigee-ca

Verifique se o valor de rotationPolicy agora está definido como Never:

kubectl get certificate apigee-ca -n cert-manager -o yaml

A saída será parecida com esta:

...
spec:
  commonName: apigee-hybrid
  duration: 87600h
  isCA: true
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: apigee-root-certificate-issuer
  privateKey:
    algorithm: ECDSA
    rotationPolicy: Never
    size: 256
  secretName: apigee-ca
...

Faça upgrade do cert-manager. O comando a seguir faz o download e instala o cert-manager v1.19.2:
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.19.2/cert-manager.yaml
```
Consulte Plataformas e versões compatíveis: cert-manager para conferir uma lista de versões compatíveis.

Veja estes tópicos:

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

Observação:antes de executar qualquer um dos comandos de upgrade/instalação do Helm, use o recurso de simulação do Helm adicionando --dry-run ao final do comando. Consulte helm -h para listar comandos, opções e uso compatíveis.

Caso contrário, acesse o diretório APIGEE_HELM_CHARTS_HOME. Execute os comandos a seguir nesse diretório.

Faça upgrade do operador/controlador da Apigee:

Observação: esta etapa requer permissões de cluster elevadas. Execute helm -h ou helm upgrade -h para ver detalhes.

Simulação:

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

Faça upgrade do gráfico:

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

Verifique a instalação do operador da 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.16.0   1.16.0

Para saber se ele está funcionando, confira a 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

Faça upgrade do repositório de dados da Apigee:

Simulação:

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

Faça upgrade do gráfico:

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

Para saber se o apigeedatastore está em execução, confira o estado dele:

kubectl -n APIGEE_NAMESPACE get apigeedatastore default

NAME      STATE       AGE
default   running    2d

Faça upgrade da telemetria da Apigee:

Simulação:

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

Faça upgrade do gráfico:

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

Para saber se ele está funcionando, confira o estado dele:

kubectl -n APIGEE_NAMESPACE get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Faça o upgrade do Apigee Redis:

Simulação:

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

Faça upgrade do gráfico:

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

Para saber se ele está funcionando, confira o estado dele:

kubectl -n APIGEE_NAMESPACE get apigeeredis default

NAME      STATE     AGE
default   running   2d

Faça upgrade do gerenciador de entrada da Apigee:

Simulação:

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

Faça upgrade do gráfico:

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

Para saber se ele está funcionando, confira a 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

Faça upgrade da organização da Apigee:
Simulação:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server
```
Faça upgrade do gráfico:
```
helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE
```
Para saber se ele está funcionando, confira o estado da respectiva organização:
```
kubectl -n APIGEE_NAMESPACE get apigeeorg
```
```
NAME                      STATE     AGE
apigee-my-org-my-env      running   2d
```
Observação: se o comando de upgrade falhar com o erro Forbidden: state: releasing, os componentes existentes ainda estão em status de lançamento. Aguarde a conclusão da atualização atual e tente novamente. Verifique o status da versão com o seguinte comando:
```
kubectl get org -n APIGEE_NAMESPACE
```
Faça upgrade do ambiente.
É preciso instalar um ambiente de cada vez. Especifique o ambiente com --set env=ENV_NAME.

Simulação:
```
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 acompanhar a instalação e os upgrades do gráfico apigee-env. Ele precisa ser diferente dos outros nomes de versão do Helm na sua instalação. Normalmente, é o mesmo que ENV_NAME. No entanto, se o ambiente tiver o mesmo nome do grupo de ambientes, use nomes de lançamento diferentes para o ambiente e o grupo de ambientes, por exemplo, dev-env-release e dev-envgroup-release. Para mais informações sobre versões no Helm, consulte Três grandes conceitos na documentação do Helm.
- ENV_NAME é o nome do ambiente que você está fazendo upgrade.
- OVERRIDES_FILE é o novo arquivo de substituição para a v.1.16.0
Faça upgrade do gráfico:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Para saber se ele está funcionando, confira o estado do respectivo ambiente:
```
kubectl -n APIGEE_NAMESPACE get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-my-org-my-env          running     2d
```

Observação: se o comando de upgrade falhar com o erro Forbidden: state: releasing, os componentes existentes ainda estão com status de lançamento. Aguarde a conclusão da atualização atual e tente novamente. Verifique o status da versão com o seguinte comando:

kubectl get env -n APIGEE_NAMESPACE

Faça upgrade dos grupos de ambiente (virtualhosts).
1. É necessário fazer upgrade de um grupo de ambiente (virtualhost) por vez. Especifique o grupo de ambientes com --set envgroup=ENV_GROUP_NAME: Repita os seguintes comandos para cada grupo de ambientes mencionado no arquivo overrides.yaml:
  Simulação:
```
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 que você instalou anteriormente o gráfico apigee-virtualhost. Ele geralmente é ENV_GROUP_NAME.
  
  Faça upgrade do gráfico:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  Observação: ENV_GROUP_RELEASE_NAME precisa ser exclusivo no namespace apigee.
  Por exemplo, se você tiver um ambiente chamado prod e um grupo de ambientes chamado prod, defina o valor de ENV_GROUP_RELEASE_NAME como algo exclusivo, como prod-envgroup.
2. Verifique o estado da ApigeeRoute (AR).
  A instalação de virtualhosts cria a ApigeeRouteConfig (ARC), que gera internamente a ApigeeRoute (AR) depois que o inspetor da Apigee extrai detalhes relacionados ao grupo de ambientes do plano de controle. Portanto, verifique se o estado de RA 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-123abc               running   2d
```
Depois de verificar se todas as instalações foram atualizadas, exclua a versão mais antiga do apigee-operator do namespace apigee-system.
1. Desinstale a versão antiga do operator:
```
helm delete operator -n apigee-system
```
2. Exclua o namespace apigee-system:
```
kubectl delete namespace apigee-system
```

Faça upgrade de operator novamente no namespace da Apigee para reinstalar os recursos excluídos com escopo de cluster:

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

Como 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 upgrade na ordem inversa. Comece com apigee-virtualhost, volte para apigee-operator e depois reverta as CRDs.

Dica: se você souber a versão da última versão de lançamento, use 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 a seguir pressupõem que você está usando os gráficos da versão anterior (v1.15.x).

Execute o seguinte comando para cada grupo de ambiente:

helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f 1.15_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.15_OVERRIDES_FILE

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

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

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

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

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

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

Crie o namespace apigee-system:
```
kubectl create namespace apigee-system
```

Corrija a anotação de recurso de volta ao namespace apigee-system.

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

Se você também tiver mudado o nome da versão, atualize a anotação com o nome da versão operator.
```
kubectl annotate --overwrite clusterIssuer apigee-ca-issuer meta.helm.sh/release-name='operator'
```

Instale apigee-operator novamente no namespace apigee-system.

helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.15_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 namespace APIGEE_NAMESPACE para concluir o processo de reversão.
```
helm uninstall operator -n APIGEE_NAMESPACE
```
Alguns recursos do escopo do cluster, como clusterIssuer, são excluídos quando o operator é desinstalado. Reinstale-os com o seguinte comando:
```
helm upgrade operator apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f 1.15_OVERRIDES_FILE
```

Como fazer upgrade da Apigee híbrida para a versão 1.16 Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Mudanças em relação à Apigee híbrida v1.15

Pré-requisitos

Antes de fazer upgrade para a versão 1.16.0: limitações e observações importantes

Como fazer upgrade para a versão 1.16.0

Preparar para fazer upgrade para a versão 1.16

Faça o backup da instalação híbrida

Linux

Mac OS

Windows

Fazer upgrade da versão do Kubernetes

Clique para expandir uma lista de plataformas compatíveis

Versões compatíveis

Componentes

Versões incompatíveis

Componentes

Extraia os gráficos do Apigee Helm.

Editar kustomization.yaml para um namespace personalizado da Apigee

Configurar a conta de serviço apigee-guardrails

Secrets do Kubernetes

Arquivos JSON

Vault

WIF para GKE

WIF em outras plataformas

Secrets do Kubernetes

Arquivos JSON

Vault

WIF para GKE

WIF em outras plataformas

Modelo

Exemplo

WIF: secrets

WIF: arquivos

WIF: Vault

Fazer upgrade do cert-manager

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

Como reverter para uma versão anterior

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

Editar `kustomization.yaml` para um namespace personalizado da Apigee

Configurar a conta de serviço `apigee-guardrails`