Esta página foi traduzida pela API Cloud Translation.

Atualizar o Apigee Hybrid para a versão 1.16

Este procedimento abrange a atualização da versão 1.15.x do Apigee Hybrid para a versão 1.16.0 do Apigee Hybrid.

Alterações do Apigee Hybrid v1.15

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

Perfis de Seccomp: A partir da versão 1.16, O Apigee hybrid oferece agora a capacidade de aplicar perfis de Seccomp aos seus componentes de tempo de execução, melhorando significativamente a postura de segurança da sua implementação. Esta funcionalidade permite que os administradores e as equipas de segurança do Apigee restrinjam as chamadas do sistema que um processo contentorizado pode fazer ao kernel do anfitrião. Ao limitar um contentor apenas às chamadas de sistema necessárias, pode:
- Melhorar a segurança: mitigar o risco de fugas de contentores e elevação de privilégios.
- Aplique o princípio do menor privilégio: certifique-se de que os componentes só têm acesso às chamadas do sistema exatas necessárias para o respetivo funcionamento.
- Cumprir a conformidade: ofereça um controlo essencial para cumprir os rigorosos requisitos de conformidade de segurança.
Para mais informações, consulte o artigo Configure perfis de Seccomp para a segurança de pods.
UDCA na remoção do Apigee hybrid: na versão 1.16> do Apigee hybrid, o componente do agente de recolha de dados unificados (UDCA) foi removido. As responsabilidades de envio de dados de estatísticas, rastreio e estado de implementação para o plano de controlo do Apigee são agora processadas através de um pipeline de dados baseado no Google Cloud Pub/Sub. A utilização do pipeline de dados baseado no Pub/Sub é o mecanismo de recolha de dados predefinido desde a versão 1.14.0 do Apigee hybrid.
Conta de serviço: Na versão 1.16.0, o Apigee Hybrid introduz uma apigee-guardrails conta de serviço do Google IAM.apigee-guardrails Isto é usado pelo gráfico apigee-operator durante a instalação para verificar se todas as APIs necessárias estão ativadas no seu projeto.
Consulte:
Suporte para as versões 1.18 e 1.19 do cert-manager: O Apigee hybrid v1.16 suporta a versão 1.18 e a versão 1.19 do cert-manager. Na versão 1.18 do cert-manager, existe uma alteração ao valor predefinido de Certificate.Spec.PrivateKey.rotationPolicy que pode afetar o tráfego. Se estiver a atualizar a partir de uma versão anterior do Apigee hybrid e estiver a atualizar para a versão 1.18 ou superior do cert-manager, siga o procedimento de atualização do cert-manager neste guia.

Nota: isto não afeta as instalações novas do Apigee hybrid v1.6.

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

Pré-requisitos

Antes de atualizar para a versão híbrida 1.16, 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.15, tem de fazer a atualização para a versão 1.15 antes de atualizar para a v1.16. Consulte o artigo Atualizar o Apigee Hybrid para a versão 1.15.
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 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.16 abaixo.

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

O Apigee hybrid 1.16.0 introduz 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 recém-criadas e não pode ser aplicada a organizações atualizadas. Para usar esta funcionalidade, faça uma nova instalação do Hybrid 1.16.0 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.16 do Apigee Hybrid pode exigir um período de inatividade.

Quando atualizar o controlador do Apigee para a versão 1.16.0, todas as implementações do Apigee são reiniciadas de forma gradual. 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 região ou num 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.15 para restaurar uma instância do Hybrid 1.16.
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.

Vista geral da atualização para a versão 1.16.0

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.16.0 do tempo de execução híbrido.

Prepare-se para atualizar para a versão 1.16

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.15 $APIGEE_HELM_CHARTS_HOME/. Pode usar qualquer processo de cópia de segurança. Por exemplo, pode criar um ficheiro tar de todo o seu diretório com:
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.15-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.
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 plataforma Kubernetes e, se necessário, atualize-a para uma versão suportada pelo híbrido 1.15 e pelo híbrido 1.16. Siga a documentação da sua plataforma se precisar de ajuda.

Clique para expandir uma lista de plataformas suportadas

Versões suportadas

	1.14	1.15	1.16
GKE no 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 no 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 (apenas 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 (apenas 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)	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
Leme	3.14.2 a 3.x.x	3.14.2 a 3.x.x	3.17.0 a 3.x.x
Controlador CSI da Secret Store	1.4.6+	1.4.6+	1.4.6+
Vault	1.17.2	1.17.2	1.17.2
⁽¹⁾ As datas oficiais de FdV para as versões 1.13 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. ⁽³⁾ 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 recente 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íbrido 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+. Híbrido 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 introduz uma alteração à política de rotação de chaves privadas predefinida que pode causar interrupções no tráfego. Consulte o problema conhecido 465834046 para ver uma solução alternativa.

Versões não suportadas

	1.6 ⁽¹⁾	1.7 ⁽¹⁾	1.8 ⁽¹⁾	1.9 ⁽¹⁾	1.10 ⁽¹⁾	1.11 ⁽¹⁾	1.12 ⁽¹⁾	1.13 ⁽¹⁾
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)}	1.27.x 1.28.x 1.29.x 1.30.x
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)}	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 (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)}	1.16.x (K8s v1.27.x) 1.28.x 1.29.x 1.30.x
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)}	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)	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
Leme					3.10+	3.10+	3.14.2 a 3.x.x	3.14.2 a 3.x.x
Controlador CSI da Secret Store						1.3.4+	1.4.1+	1.4.6+
Vault						1.13.x	1.15.2	1.15.2
⁽¹⁾ As datas oficiais de FdV para as versões 1.13 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. ⁽³⁾ 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 recente 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íbrido 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+. Híbrido 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 introduz uma alteração à política de rotação de chaves privadas predefinida que pode causar interrupções no tráfego. Consulte o problema conhecido 465834046 para ver uma solução alternativa.

Extraia os gráficos Helm do Apigee.

Os gráficos do Apigee Hybrid 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.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

Edite `kustomization.yaml` para um espaço de nomes apigee personalizado

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.

Configure 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 atualizar o gráfico apigee-operator.

No procedimento seguinte, selecione o tipo de autenticação da conta de serviço que está a usar.

Valide se consegue executar create-service-account. Se acabou de transferir os gráficos, o ficheiro create-service-account pode não estar num 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 indicar permission denied, tem de tornar o ficheiro executável, por exemplo, com chmod no Linux, MacOS ou UNIX, ou no Explorador do Windows, ou com o comando icacls no Windows. Por exemplo:
```
chmod +x ./apigee-operator/etc/tools/create-service-account
```
Crie a conta de serviço apigee-guardrails:
Segredos do Kubernetes
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Este comando cria a conta de serviço apigee-guardrails e transfere a chave para o diretório service-accounts/.
Ficheiros JSON
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir ./apigee-operator/
```
Este comando cria a conta de serviço apigee-guardrails e transfere a chave para o diretório do gráfico apigee-operator/.
Vault
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Este comando cria a conta de serviço apigee-guardrails e transfere a chave para o diretório service-accounts/.
WIF para o GKE
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Este comando cria a conta de serviço apigee-guardrails e transfere a chave para o diretório apigee-operator/etc/tools/service-accounts/. Não precisa do ficheiro de chave transferido e pode eliminá-lo.
WIF noutras plataformas
```
./apigee-operator/etc/tools/create-service-account \
  --env prod \
  --profile apigee-guardrails \
  --dir service-accounts
```
Este comando cria a conta de serviço apigee-guardrails e transfere a chave para o diretório service-accounts/.

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

Segredos do Kubernetes

Crie o segredo do Kubernetes com o ficheiro 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 o seguinte ao ficheiro overrides.yaml:

guardrails:
  serviceAccountRef: apigee-guardrails-svc-account

Ficheiros JSON

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

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

Vault

Atualize o segredo do Vault secret/data/apigee/orgsakeys para adicionar uma entrada guardrails com o conteúdo do ficheiro 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 as restrições é denominada apigee-operator-guardrails-sa. Adicione o KSA das proteções ao nível do sistema às contas de serviço específicas da organização associadas à função apigee-orgsakeys no Vault.

Obtenha a lista atual de associações de KSAs:

vault read auth/kubernetes/role/apigee-orgsakeys

O resultado deve 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 contas de serviço separados por vírgulas. Adicione apigee-operator-guardrails-sa à lista de nomes. Por exemplo (sem as novas linhas 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 associações para a função apigee-orgsakeys com a lista atualizada de nomes de contas 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 "restrições" ao SecretProviderClass
1. Edite o ficheiro spc-org.yaml.
  Sugestão: se precisar de o recriar, use o modelo em Armazenar chaves de contas de serviço no Hashicorp Vault: criar objetos SecretProviderClass.
2. Em spec.parameters.objects, adicione uma entrada de restrições:
```
      - objectName: "guardrails"
        secretPath: ""
        secretKey: ""
```
  Dica: para ambientes com scripts ou para automatizar esta alteração, pode usar o processador YAML de linha de comandos yq.
  Comando: para adicionar a entrada "guardrails" no local em spc-org.yaml, use o seguinte comando:
```
yq -i '.spec.parameters.objects |= (
    from_yaml + [
        {
            "objectName": "guardrails",
            "secretPath": "",
            "secretKey": ""
        }
    ] | to_yaml
)' spc-org.yaml
```
  Este comando analisa a string YAML incorporada no campo objects, adiciona o novo item à lista e, em seguida, escreve o resultado novamente.
3. Atualize o seu SecretProviderClass:
```
kubectl -n APIGEE_NAMESPACE apply -f spc-org.yaml
```

WIF para o GKE

A conta de serviço do Kubernetes (KSA) para as restrições é denominada apigee-operator-guardrails-sa. Crie a associação para a conta de serviço 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 o seguinte ao ficheiro overrides.yaml:

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

WIF noutras plataformas

A conta de serviço do Kubernetes (KSA) para as restrições é denominada apigee-operator-guardrails-sa. Tem de conceder ao KSA das restrições acesso para se fazer passar pela apigee-guardrails conta de serviço Google (GSA) e configurar as substituições para usar um ficheiro de configuração de credenciais.

Conceda ao KSA acesso para se fazer passar pelo 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

Onde:

PROJECT_ID: o ID do seu projeto do Google Cloud.
PROJECT_NUMBER: o número do projeto do projeto onde criou o Workload Identity Pool.
POOL_ID: o ID do Workload Identity Pool.
APIGEE_NAMESPACE: o espaço de nomes onde o Apigee Hybrid está instalado.

Crie um ficheiro de configuração de credenciais 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 fornecedor do Workload Identity Pool.

Configure apigee-guardrails para usar a federação de identidades da carga de trabalho com um dos seguintes métodos:
WIF: secrets
1. Crie um novo segredo do Kubernetes com o ficheiro de origem das credenciais para cada ficheiro de configuração das credenciais.
  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 segredo:
  guardrails: serviceAccountRef: guardrails-workload-identity-secret
WIF: ficheiros

Mova o ficheiro apigee-guardrails-credential-configuration.json gerado para o diretório do gráfico apigee-operator/.

Adicione o seguinte ao ficheiro 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 ficheiro de origem das 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.

Atualize o cert-manager

O Apigee Hybrid v1.16 suporta as versões 1.16 a 1.19 do cert-manager. Existe uma alteração no cert-manager 1.18 que pode causar um problema com o seu tráfego. Na versão 1.18 do cert-manager, o valor predefinido de Certificate.Spec.PrivateKey.rotationPolicy foi alterado de Never para Always. Para instalações híbridas do Apigee atualizadas, isto pode causar um problema com o seu tráfego. Quando atualizar para a versão híbrida 1.16 a partir de uma versão anterior, tem de editar o seu certificado apigee-ca para compensar esta alteração ou manter a sua versão do cert-manager na versão 1.17.x ou inferior.

Antes de atualizar o cert-manager para a versão 1.18 ou 1.19, use o procedimento dos passos seguintes para editar o seu certificado apigee-ca para definir o valor de Certificate.Spec.PrivateKey.rotationPolicy como Never.

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

Sugestão: se estiver a usar um espaço de nomes do cert-manager personalizado, substitua cert-manager pelo espaço de nomes correto nos comandos seguintes.

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

Procure os valores em spec.privateKey no resultado:

...
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 estiver definido como Always, edite o certificado apigee-ca para definir o valor de rotationPolicy como Never:

Faça primeiro uma execução de ensaio:

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

Aplique 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 está agora definido como Never:

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

O resultado deve ser semelhante ao seguinte:

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

Atualize o cert-manager. O comando seguinte transfere 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 o artigo Plataformas e versões suportadas: cert-manager para ver uma lista das versões suportadas.

Consulte:

Instale o tempo de execução híbrido 1.16.0

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

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 gestor de entrada do Apigee:

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-my-org-my-env      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.16.0
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-my-org-my-env          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-123abc               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 novamente o operator 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

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 com apigee-virtualhost e avance até apigee-operator. 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.

Reverter todos os gráficos de apigee-virtualhost para apigee-datastore. Os seguintes comandos pressupõem que está a usar os gráficos da versão anterior (v1.15.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.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 restantes gráficos, exceto o gráfico 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 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.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 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.15_OVERRIDES_FILE
```

Atualizar o Apigee Hybrid 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.

Alterações do Apigee Hybrid v1.15

Pré-requisitos

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

Vista geral da atualização para a versão 1.16.0

Prepare-se para atualizar para a versão 1.16

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

Linux

Mac OS

Windows

Atualize a versão do Kubernetes

Clique para expandir uma lista de plataformas suportadas

Versões suportadas

Componentes

Versões não suportadas

Componentes

Extraia os gráficos Helm do Apigee.

Edite kustomization.yaml para um espaço de nomes apigee personalizado

Configure a conta de serviço apigee-guardrails

Segredos do Kubernetes

Ficheiros JSON

Vault

WIF para o GKE

WIF noutras plataformas

Segredos do Kubernetes

Ficheiros JSON

Vault

WIF para o GKE

WIF noutras plataformas

Modelo

Exemplo

WIF: secrets

WIF: ficheiros

WIF: Vault

Atualize o cert-manager

Instale o tempo de execução híbrido 1.16.0

Reverter para uma versão anterior

Atualizar o Apigee Hybrid para a versão 1.16

Edite `kustomization.yaml` para um espaço de nomes apigee personalizado

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