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

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

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

Observe as seguintes mudanças:

apigee-operator no namespace da Apigee: a partir da versão 1.13, apigee-operator é executado no mesmo namespace do Kubernetes que os outros componentes da Apigee híbrida, apigee por padrão. É possível fornecer qualquer nome para o namespace. Em versões anteriores, o apigee-operator precisava ser executado no próprio namespace, apigee-system.
O Anthos (em bare metal ou VMware) agora é o Google Distributed Cloud (para bare metal ou VMware): para mais informações, consulte as informações gerais do produto para o Google Distributed Cloud para bare metal e o Google Distributed Cloud para VMware.

Pré-requisitos

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

Se sua instalação híbrida executa uma versão anterior à v1.12, é necessário fazer upgrade para a versão 1.1 antes de fazer upgrade para a v1.13. Consulte Como fazer upgrade da Apigee híbrida para a versão 1.12.
Helm v3.10 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.13 abaixo.

Como fazer upgrade para a versão 1.13.0

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

Ao fazer upgrade do controlador da Apigee para a versão 1.13.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 fazer upgrade de todos os clusters o mais rápido possível para reduzir as chances de impacto na produção. Não há limite de tempo para o upgrade de todos os clusters restantes depois do upgrade do primeiro. No entanto, até que todos os clusters restantes sejam atualizados, as seguintes operações serão afetadas:

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

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

Prepare-se para o upgrade.
Instale o ambiente de execução híbrido versão 1.13.0.

Preparar para fazer upgrade para a versão 1.13

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

Se você estiver usando arquivos de certificado de serviço (.json) em suas substituições para autenticar contas de serviço, verifique se os arquivos de certificado da conta de serviço estão no diretório de gráfico do Helm correto. Os gráficos do Helm não podem ler arquivos fora de cada diretório de gráfico.

Esta etapa não será necessária se você estiver usando secrets do Kubernetes ou a Identidade da carga de trabalho para autenticar contas de serviço.

A tabela a seguir mostra o destino de cada arquivo da conta de serviço, dependendo do tipo de instalação:

Prod.

Conta de serviço	Nome padrão do arquivo	Diretório do gráfico do 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/`

Sem produção

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

Conta de serviço	Nome padrão do arquivo	Diretórios de gráficos do 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/`

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.12 e 1.13. Siga a documentação da plataforma se precisar de ajuda.

Clique para expandir uma lista de plataformas compatíveis

	1.10 ⁽²⁾	1.11	1.12	1.13
GKE no Google Cloud	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x 1.30.x
GKE na AWS	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x (K8s v1.25.x) 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)} 1.30.x
GKE no Azure	1.13.x 1.14.x 1.26.x⁽⁴⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.26.x⁽⁴⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽⁴⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)} 1.30.x
Google Distributed Cloud (somente software) no VMware ⁽³⁾	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)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)}	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.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)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x^{(≥ 1.12.1)}	1.16.x (K8s v1.27.x) 1.28.x⁽⁴⁾ 1.29.x 1.30.x
EKS	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.26.x 1.27.x 1.28.x 1.29.x
AKS	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	1.26.x 1.27.x 1.28.x 1.29.x
OpenShift	4.11 4.12 4.14^{(≥ 1.10.5)} 4.15^{(≥ 1.10.5)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)} 4.16^{(≥ 1.11.2)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)}	4.12 4.13 4.14 4.15 4.16
Rancher Kubernetes Engine (RKE)(7)	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x 1.30.x
VMware Tanzu	N/A	N/A	v1.26.x	v1.26.x
Componentes	1.10	1.11	1.12	1.13
Cloud Service Mesh	1.17.x⁽³⁾	1.17.x^{(v1.11.0 - v1.11.1)}⁽³⁾ 1.18.x^{(≥ 1.11.2)}⁽³⁾	1.18.x⁽³⁾	1.19.x⁽³⁾
JDK	JDK 11	JDK 11	JDK 11	JDK 11
cert-manager.	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.13.x 1.14.x 1.15.x
Cassandra	3.11	3.11	4.0	4.0
Kubernetes	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+	3.14.2+
Driver CSI do Secret Store		1.3.4	1.4.1	1.4.1
Vault		1.13.x	1.15.2	1.15.2
⁽¹⁾ No Anthos local (Google Distributed Cloud) versão 1.13, siga estas instruções para evitar conflitos com o `cert-manager`: Instalação conflitante do cert-manager ⁽²⁾ As datas de EOL oficiais da Apigee híbrida versões 1.10 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. ⁽⁴⁾ Agora os números de versão do GKE na AWS refletem as versões do Kubernetes. Consulte Suporte a versões e upgrades do GKE Enterprise para conferir detalhes da versão e os patches recomendados. ⁽³⁾ 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.

Sobre os clusters anexados

Para a Apigee híbrida versão 1.7.x e anteriores, é necessário usar os clusters anexados do GKE quando você quer executar a Apigee híbrida em um contexto multicloud no Elastic Kubernetes Service (EKS), no Azure Kubernetes Service (AKS) ou em outro provedor de serviços de terceiros do Kubernetes com suporte. O anexo do cluster permite que o Google meça o uso do Cloud Service Mesh.

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

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

Preparar-se para o upgrade de gráficos do Helm

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

Faça upgrade do cert-manager, se necessário.
Se você precisar fazer upgrade da 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.15.1/cert-manager.yaml
```
Consulte Plataformas e versões compatíveis: cert-manager para conferir uma lista de versões compatíveis.
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

Migre apigee-operator do namespace apigee-system para APIGEE_NAMESPACE.

Anotar o clusterIssuer com o novo namespace.

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

Se você estiver mudando o nome da versão de apigee-operator, anote clusterIssuer com o novo nome da versão.

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

Atualize as réplicas da sua implantação atual do operador da Apigee no namespace apigee-system para 0 (zero) para evitar a reconciliação dos dois controladores.
```
kubectl scale deployment apigee-controller-manager -n apigee-system --replicas=0
```

Atualize as réplicas da sua implantação atual do operador da Apigee no namespace apigee-system para 0 (zero) para evitar a reconciliação dos dois controladores.

kubectl delete mutatingwebhookconfiguration apigee-mutating-webhook-configuration
kubectl delete validatingwebhookconfiguration apigee-validating-webhook-configuration

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.

Instalar os gráficos do Helm da Apigee híbrida

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

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

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

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

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

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
```
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-org1-xxxxx          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
```
- ENV_RELEASE_NAME é o nome com que você instalou anteriormente o gráfico apigee-env. Na versão híbrida v1.10, geralmente é apigee-env-ENV_NAME. Na versão híbrida v1.11 e mais recentes, geralmente é ENV_NAME.
- ENV_NAME é o nome do ambiente que você está fazendo upgrade.
- OVERRIDES_FILE é o novo arquivo de substituição para a v.1.13.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-org1-dev-xxx            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
```
  ENV_GROUP_RELEASE_NAME é o nome com que você instalou anteriormente o gráfico apigee-virtualhost. Na versão híbrida v1.10, geralmente é apigee-virtualhost-ENV_GROUP_NAME. Na versão 1.11 e mais recentes da versão híbrida, geralmente ele é 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-xxxxxx                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.

Devido à mudança no namespace para apigee-operator, você precisa executar mais etapas para excluir os hooks de validação e mutação. Dessa forma, quando você instalar o apigee-operator novamente no namespace apigee-system, ele será recriado para apontar para o endpoint correto do Apigee Operator.

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.

Atualize as réplicas da implantação do Apigee Operator no Apigee para 0 (zero) para evitar que os dois controladores conciliem os recursos personalizados e evitem conflitos ao reverter a implantação no namespace apigee-system.

kubectl scale deployment apigee-controller-manager -n APIGEE_NAMESPACE --replicas=0

kubectl delete mutatingwebhookconfiguration \
  apigee-mutating-webhook-configuration-APIGEE_NAMESPACE

kubectl delete validatingwebhookconfiguration \
  apigee-validating-webhook-configuration-APIGEE_NAMESPACE

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.12.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.12_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.12_OVERRIDES_FILE

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

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

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

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

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

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f 1.12_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 cluseterIssuer 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.12_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.12_OVERRIDES_FILE
```

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

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

Pré-requisitos

Como fazer upgrade para a versão 1.13.0

Preparar para fazer upgrade para a versão 1.13

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

Linux

Mac OS

Windows

Prod.

Sem produção

Fazer upgrade da versão do Kubernetes

Clique para expandir uma lista de plataformas compatíveis

Componentes

Sobre os clusters anexados

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

Preparar-se para o upgrade de gráficos do Helm

Instalar os gráficos do Helm da Apigee híbrida

Como reverter para uma versão anterior