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

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

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

A Apigee híbrida versão 1.12 apresenta as alterações a seguir que afetam o processo de upgrade. Para ver uma lista completa dos recursos na v1.12, consulte as Notas da versão híbrida v1.12.0.

Cassandra 4.x: a partir da versão 1.12, a Apigee híbrida usa o Cassandra versão 4 ou mais recente.
Importante: devido à alteração no banco de dados, não é possível reverter o componente apigee-datastore atualizado. Portanto, é essencial fazer backup do banco de dados do Cassandra e da instalação híbrida antes de fazer o upgrade. Se for necessário reverter o upgrade, considere os seguintes cenários:
- Cassandra ainda não atualizado: é possível reverter todas as alterações.
- Cassandra atualizado e todos os pods do Cassandra estão íntegros: é possível reverter as alterações em todos os componentes, exceto apigee-datastore. A instalação v1.11.x continuará funcionando com uma instância v1.12 do apigee-datastore que executa o Cassandra v4.
- Cassandra e os pods do Cassandra estão em um estado não íntegro: é preciso desinstalar a versão híbrida v1.12 e restaurar a instalação da v.11 por um backup.
Descontinuação do apigeectl: a partir da versão 1.12, a Apigee híbrida oferece suporte apenas ao Helm para instalação e gerenciamento da instalação híbrida.
Atenção: o apigeectl foi descontinuado em 17 de abril de 2024. A ferramenta apigeectl não é compatível com a Apigee híbrida v1.12. O suporte ao apigeectl para a Apigee híbrida v1.10 e v1.11 terminará em 17 de abril de 2025. Para mais informações, consulte Descontinuação do apigeectl.

Importante: se você gerencia a v1.11 com o apigeectl, é necessário primeiro migrar sua instalação da v1.11 para usar o Helm antes de fazer upgrade para a versão 1.12. Siga as instruções em Migrar a Apigee híbrida do apigeectl para os gráficos do Helm.
Um novo conjunto de métricas para monitorar endpoints de destino e proxies da Apigee já está disponível. Para a versão híbrida v1.12, os recursos monitorados ProxyV2 e TargetV2 não serão mais usados por padrão. Todas as métricas de proxy e destino serão publicadas nos recursos monitorados Proxy e Target.

Para continuar a emitir métricas para recursos monitorados ProxyV2 e TargetV2, defina metrics.disablePrometheusPipeline como true no overrides.yaml.
Se você tiver configurado alertas com base em métricas, confirme o uso das métricas corretas para sua instalação híbrida. Para mais informações, consulte Alertas com base em métricas.

Considerações antes de iniciar um upgrade para a versão 1.12

O upgrade da versão da Apigee híbrida 1.11 para a versão 1.12 inclui um upgrade do banco de dados Cassandra da versão 3.11.x para a versão 4.x. Embora o upgrade do Cassandra seja processado como parte do procedimento de upgrade da Apigee híbrida, planeje-se com as seguintes considerações:

O upgrade da versão do Cassandra acontecerá em segundo plano e ocorrerá em um pod (ou nó do Cassandra) por vez. Portanto, planeje-se considerando uma capacidade reduzida do banco de dados durante o upgrade.
Faça o escalonamento da capacidade do Cassandra e garanta que a utilização do disco esteja próxima ou abaixo de 50% antes de iniciar o upgrade.
Valide e teste os procedimentos de backup e restauração do Cassandra.
Faça backup dos dados do Cassandra na instalação da versão híbrida 1.11 antes de iniciar o upgrade e valide seus backups.
O upgrade de apigee-datastore resultará em um aumento temporário no consumo de CPU devido a tarefas pós-upgrade realizadas pelo Cassandra
Depois de fazer upgrade do componente apigee-datastore (Cassandra), não será possível reverter esse componente para a versão anterior. Há dois cenários para reverter um upgrade para a versão híbrida v1.12 após o upgrade do componente apigee-datastore:
- Se o componente apigee-datastore estiver em bom estado, mas outros componentes exigirem uma reversão, será possível reverter esses outros componentes individualmente.
  Observação: não será possível adicionar regiões ou escalonar nós do Cassandra ao executar componentes de versões híbridas diferentes.
- Se o componente apigee-datastore estiver em mau estado, será necessário fazer a restauração por um backup da v1.11 para uma instalação da v1.11.
  Observação: não é possível combinar versões ao restaurar. É necessário restaurar um backup de uma instalação da v1.11 em uma instalação da v1.11.

Considerações antes de fazer upgrade de uma instalação de região única

Quando você precisa reverter para uma versão anterior da Apigee híbrida, o processo pode exigir inatividade. Portanto, se você for fazer upgrade de uma instalação de região única, crie uma segunda região e, em seguida, faça upgrade de apenas uma região por vez na seguinte sequência:

Adicione uma segunda região à instalação atual usando a mesma versão híbrida. Consulte Implantação multirregional na documentação da versão 1.11.
Faça backup e valide os dados da primeira região antes de iniciar um upgrade. Consulte Visão geral do backup do Cassandra na documentação da versão 1.11.
Faça upgrade da região recém-adicionada para a versão híbrida 1.12.
Mude o tráfego para a nova região e valide-o.
Após a validação, faça upgrade da região mais antiga com a versão híbrida 1.12.
Mude todo o tráfego de volta para a região mais antiga e valide-o.
Desative a nova região.

Considerações antes de fazer upgrade de uma instalação multirregional

A Apigee recomenda a seguinte sequência para fazer upgrade de uma instalação multirregional:

Faça backup e valide os dados de cada região antes de iniciar o upgrade.
Faça upgrade da versão híbrida em uma região e verifique se todos os pods estão em execução para validar o upgrade.
Valide o tráfego na região recém-atualizada.
Só faça upgrade de cada região subsequente depois de validar o tráfego na região anterior.
Caso haja a necessidade de reverter um upgrade em uma implantação multirregional, prepare-se para mudar o tráfego das regiões com falha. Considere adicionar capacidade suficiente na região onde o tráfego será desviado para lidar com o tráfego em ambas as regiões.

Pré-requisitos

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

Uma instalação da Apigee híbrida versão 1.11 gerenciada com o Helm.
- Se você gerencia sua instalação híbrida com o apigeectl, é necessário primeiro migrar seus clusters para o gerenciamento do Helm. Consulte Migrar a Apigee híbrida do apigeectl para o Helm na documentação da versão híbrida v1.11.
- Se sua instalação híbrida executa uma versão anterior à v1.11, é necessário fazer upgrade para a versão 1.11 antes de fazer upgrade para a v1.12. Consulte Como fazer upgrade da Apigee híbrida para a versão 1.11.
Helm v3.10 ou mais recente.
kubectl versão 1.27, 1.28 ou 1.29 (recomendado).
cert-manager versão v1.13.0. Se necessário, faça upgrade do cert-manager na seção Preparação para fazer upgrade para a versão abaixo.

Limitações

Considere as seguintes limitações ao planejar o upgrade da Apigee híbrida versão 1.11 para a versão 1.12. O planejamento pode ajudar a reduzir a inatividade exigida quando é necessária uma reversão ou restauração após o upgrade.

Os backups da versão híbrida 1.12 não podem ser restaurados na versão híbrida 1.11 e vice-versa, devido à incompatibilidade entre as duas versões.
Não é possível escalonar os pods do repositório de dados durante o upgrade para a versão 1.12. Atenda às suas necessidades de escalonamento em todas as regiões antes de começar a fazer upgrade da instalação híbrida.
Em uma instalação híbrida de região única, não é possível reverter o componente do repositório de dados depois que o processo de upgrade do repositório de dados é concluído. Não é possível reverter um repositório de dados do Cassandra 4.x para um repositório de dados do Cassandra 3.x. Isso exigirá a restauração do backup mais recente dos dados do Cassandra 3.x (da instalação da versão híbrida 1.11).
Não é possível excluir ou adicionar uma região durante o upgrade. Em um upgrade multirregional, é necessário concluir o upgrade de todas as regiões antes de adicionar ou excluir regiões.

Como fazer upgrade para a versão 1.12.2

O upgrade para a Apigee híbrida versão 1.12 pode exigir inatividade.

Ao fazer upgrade do controlador da Apigee para a versão 1.12.2, 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.11 não pode ser usado para restaurar uma instância da versão híbrida 1.12.
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.
- Fazer backup do Cassandra.
- Fazer backup dos diretórios da instalação híbrida.
Instale o ambiente de execução híbrido versão 1.12.2.

Preparar para fazer upgrade para a versão 1.12

Fazer backup do Cassandra

Faça backup do banco de dados do Cassandra em todas as regiões aplicáveis e valide os dados na instalação da versão híbrida 1.11 antes de iniciar o upgrade. Consulte Como monitorar backups na documentação da versão 1.11.

Reinicie todos os pods do Cassandra no cluster antes de iniciar o processo de upgrade para que qualquer problema persistente apareça.

Para reiniciar e testar os pods do Cassandra, exclua cada pod individualmente, um pod por vez. Em seguida, confirme se ele volta ao estado em execução e se a sondagem de prontidão é aprovada:

Liste os pods do Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Exemplo:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

Exclua um pod:

kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

Exemplo:

kubectl delete pod -n apigee apigee-cassandra-default-0

Verifique o status listando os pods do Cassandra novamente:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Exemplo:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          16s
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

Aplique o último arquivo de substituição conhecido novamente para garantir que não sejam feitas alterações e use a mesma configuração para fazer upgrade para a versão híbrida 1.12.

Verifique se todos os nós do Cassandra em todas as regiões estão no estado UN (Ativo/Normal). Se algum nó do Cassandra estiver em um estado diferente, resolva o problema antes de iniciar o upgrade.

É possível validar o estado dos nós do Cassandra com os seguintes comandos:

Liste os pods do Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Exemplo:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

Verifique o estado dos nós de cada pod do Cassandra com o comando kubectl nodetool status:

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME nodetool status

Exemplo:

kubectl -n apigee exec -it apigee-cassandra-default-0 nodetool status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.16.2.6    690.17 KiB  256          48.8%             b02089d1-0521-42e1-bbed-900656a58b68  ra-1
UN  10.16.4.6    705.55 KiB  256          51.6%             dc6b7faf-6866-4044-9ac9-1269ebd85dab  ra-1
UN  10.16.11.11  674.36 KiB  256          48.3%             c7906366-6c98-4ff6-a4fd-17c596c33cf7  ra-1
UN  10.16.1.11   697.03 KiB  256          49.8%             ddf221aa-80aa-497d-b73f-67e576ff1a23  ra-1
UN  10.16.5.13   703.64 KiB  256          50.9%             2f01ac42-4b6a-4f9e-a4eb-4734c24def95  ra-1
UN  10.16.8.15   700.42 KiB  256          50.6%             a27f93af-f8a0-4c88-839f-2d653596efc2  ra-1
UN  10.16.11.3   697.03 KiB  256          49.8%             dad221ff-dad1-de33-2cd3-f1.672367e6f  ra-1
UN  10.16.14.16  704.04 KiB  256          50.9%             1feed042-a4b6-24ab-49a1-24d4cef95473  ra-1
UN  10.16.16.1   699.82 KiB  256          50.6%             beef93af-fee0-8e9d-8bbf-efc22d653596  ra-1

Fazer backup dos diretórios 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.11. É 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.11-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.11 e 1.12. 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
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)}
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)}
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)}
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)}
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)}
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)}
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)}
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)}
Rancher Kubernetes Engine (RKE)	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)}
VMware Tanzu	N/A	N/A	v1.26.x
Componentes	1.10	1.11	1.12
Cloud Service Mesh	1.17.x⁽¹⁰⁾	1.18.x⁽¹⁰⁾	1.19.x⁽¹⁰⁾
JDK	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
Cassandra	3.11	3.11	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
kubectl			1.27.x 1.28.x 1.29.x
Helm	3.10+	3.10+	3.14.2+
Driver CSI do Secret Store		1.3.4	1.4.1
Vault		1.13.x	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 ⁽²⁾ Suporte disponível para a Apigee híbrida versão 1.8.4 e mais recentes. ⁽³⁾ 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 Anthos no local (Google Distributed Cloud) nas versões 1.12 e anteriores não tem suporte. Consulte a Política de suporte de versões do Distributed Cloud em Bare Metal e a lista de versões compatíveis do Distributed Cloud on VMware. ⁽⁵⁾O Google Distributed Cloud em bare metal ou VMware requer a Cloud Service Mesh 1.14 ou mais recente. Recomendamos que você faça upgrade para a versão híbrida v1.8 e mude para o gateway de entrada da Apigee, que não requer mais a instalação do Cloud Service Mesh no cluster híbrido. ⁽⁶⁾ Suporte disponível para a versão híbrida da Apigee 1.8.4 e mais recentes. ⁽⁷⁾ Não há suporte na Apigee híbrida 1.8.4 e mais recentes. ⁽⁸⁾ Suporte disponível para a Apigee híbrida versão 1.7.6 e mais recentes. ⁽⁹⁾ Não há suporte na Apigee híbrida 1.8.5 e mais recentes. ⁽¹⁰⁾ O Cloud Service Mesh é instalado automaticamente com a Apigee híbrida 1.9 e mais recentes. ⁽¹¹⁾ Suporte disponível para a Apigee híbrida versão 1.9.2 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.12.2

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.12.2
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.13.0/cert-manager.yaml
```

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                    2023-10-09T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2023-10-09T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2023-10-09T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2023-10-09T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2023-10-09T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2023-10-09T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2023-10-09T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2023-10-09T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2023-10-09T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2023-10-09T14: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.

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 \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE \
  --dry-run

Faça upgrade do gráfico:

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE

Verifique a instalação do operador da Apigee:

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.2   1.12.2

Para saber se ele está funcionando, confira a disponibilidade:

kubectl -n apigee-system 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 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 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 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 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 get apigeeorg

NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d

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.12.2
Faça upgrade do gráfico:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Observação: para instalações migradas, use:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  --force \
  -f OVERRIDES_FILE
```
Para saber se ele está funcionando, confira o estado do respectivo ambiente:
```
kubectl -n apigee get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
```
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: para instalações migradas, use:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  --force \
  -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 get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n apigee get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
```

Como reverter para uma versão anterior

Esta seção é dividida em seções, dependendo do estado do componente apigee-datastore após o upgrade para a Apigee híbrida versão 1.12. Há procedimentos para reversão de uma região única ou multirregião com o componente apigee-datastore em bom estado e procedimentos para recuperação ou restauração de um backup quando o apigee-datastore está em mau estado.

Reversão e recuperação de região única

Como reverter quando o `apigee-datastore` está em bom estado

Este procedimento explica como reverter todos os componentes da Apigee híbrida da v1.12 para a v1.11, exceto o apigee-datastore. O componente apigee-datastore v1.12 é compatível com versões anteriores com componentes da versão híbrida v1.11.

Aviso: não é possível reverter o apigee-datastore. A incompatibilidade de dados entre diferentes versões do banco de dados do Cassandra impede a reversão para a versão anterior.

Para reverter a instalação de região única para a versão 1.11:

Antes de iniciar a reversão, confirme se todos os pods estão no estado em execução:
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

Valide a versão de componentes usando o Helm:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

Por exemplo:

helm -n apigee list
NAME              NAMESPACE   REVISION   UPDATED                                   STATUS     CHART                           APP VERSION
datastore         apigee      2          2024-03-29 17:08:07.917848253 +0000 UTC   deployed   apigee-datastore-1.12.0         1.12.0
ingress-manager   apigee      2          2024-03-29 17:21:02.917333616 +0000 UTC   deployed   apigee-ingress-manager-1.12.0   1.12.0
redis             apigee      2          2024-03-29 17:19:51.143728084 +0000 UTC   deployed   apigee-redis-1.12.0             1.12.0
telemetry         apigee      2          2024-03-29 17:16:09.883885403 +0000 UTC   deployed   apigee-telemetry-1.12.0         1.12.0
myhybridorg       apigee      2          2024-03-29 17:21:50.899855344 +0000 UTC   deployed   apigee-org-1.12.0               1.12.0

Reverta cada componente, exceto o apigee-datastore, com os seguintes comandos:

Crie a seguinte variável de ambiente:
- PREVIOUS_HELM_CHARTS_HOME: o diretório em que os gráficos anteriores do Helm da Apigee híbrida estão instalados. Você está revertendo essa versão.
Reverter os virtualhosts. Repita o comando a seguir para cada grupo de ambientes mencionado no arquivo de substituições.
```
helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
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.
Reverter ambientes Repita o comando a seguir para cada ambiente mencionado no arquivo de substituições.
```
helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
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 1.11 e mais recentes da versão híbrida, geralmente ele é ENV_NAME.

Para saber se ele está funcionando, confira o estado do respectivo ambiente:
```
kubectl -n apigee get apigeeenv
```
```
NAME                  STATE     AGE   GATEWAYTYPE
apigee-org1-dev-xxx   running   2d
```

Reverter organização:

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Para saber se ele está funcionando, confira o estado da respectiva organização:

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

Reverter o Ingress Manager:

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Para saber se ele está funcionando, confira a disponibilidade:

kubectl -n apigee get deployment apigee-ingressgateway-manager

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

Reverter o Redis:

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

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

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Reverter a telemetria da Apigee:

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

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

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Reverter o controlador da Apigee:

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Verifique a instalação do operador da Apigee:

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.2   1.12.2

Para saber se ele está funcionando, confira a disponibilidade:

kubectl -n apigee-system get deploy apigee-controller-manager

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

Reverter as CRDs da Apigee híbrida:

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

Confirme se todos os pods estão no estado em execução ou concluído:
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

Valide a versão de todos os componentes. Todos os componentes precisam estar na versão anterior, exceto o repositório de dados:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

Por exemplo:

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

Como restaurar quando o `apigee-datastore` não está em bom estado

Se o upgrade do componente apigee-datastore não for bem-sucedido, não será possível reverter o apigee-datastore da versão 1.12 para a versão 1.11. Em vez disso, é necessário restaurar de um backup feito de uma instalação da v1.11. Use a sequência abaixo para restaurar a versão anterior.

Se você não tiver uma instalação ativa da Apigee híbrida versão 1.11 (por exemplo, em outra região), crie uma nova instalação da v1.11 usando seus backups de gráficos e arquivos de substituições. Veja as instruções de instalação da Apigee híbrida versão 1.11.
Restaure a região da v1.11 (ou a nova instalação) pelo backup seguindo as instruções em:
- Backups da interface do Cloud Storage (CSI): backup e restauração do CSI do Cassandra.
- Backups de não CSI: como restaurar em uma única região.
Verificar o tráfego para a instalação restaurada
Opcional: para remover a instalação da versão 1.12, siga as instruções em Desinstalar o ambiente de execução híbrido.

Reversão e recuperação multirregionais

Como reverter quando o `apigee-datastore` está em bom estado

Antes de iniciar a reversão, confirme se todos os pods estão no estado em execução:
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

É possível validar o estado dos nós do Cassandra com os seguintes comandos:

Liste os pods do Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Exemplo:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

Verifique o estado dos nós de cada pod do Cassandra com o comando kubectl nodetool status:

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool -u JMX_USER -pw JMX_PASSWORD

Exemplo:

kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens   Owns (effective)   Host ID                                Rack
UN  10.16.2.6    690.17 KiB  256      48.8%              b02089d1-0521-42e1-bbed-900656a58b68   ra-1
UN  10.16.4.6    705.55 KiB  256      51.6%              dc6b7faf-6866-4044-9ac9-1269ebd85dab   ra-1
UN  10.16.11.11  674.36 KiB  256      48.3%              c7906366-6c98-4ff6-a4fd-17c596c33cf7   ra-1
UN  10.16.1.11   697.03 KiB  256      49.8%              ddf221aa-80aa-497d-b73f-67e576ff1a23   ra-1
UN  10.16.5.13   703.64 KiB  256      50.9%              2f01ac42-4b6a-4f9e-a4eb-4734c24def95   ra-1
UN  10.16.8.15   700.42 KiB  256      50.6%              a27f93af-f8a0-4c88-839f-2d653596efc2   ra-1
UN  10.16.11.3   697.03 KiB  256      49.8%              dad221ff-dad1-de33-2cd3-f1.672367e6f   ra-1
UN  10.16.14.16  704.04 KiB  256      50.9%              1feed042-a4b6-24ab-49a1-24d4cef95473   ra-1
UN  10.16.16.1   699.82 KiB  256      50.6%              beef93af-fee0-8e9d-8bbf-efc22d653596   ra-1

Se nem todos os pods do Cassandra estiverem no estado UN, siga as instruções em Remover nós INATIVOS de cluster do Cassandra.

Navegue até o diretório em que os gráficos anteriores do Helm da Apigee híbrida estão instalados

Mude o contexto para a região que foi atualizada

kubectl config use-context UPGRADED_REGION_CONTEXT

Verifique se todos os pods estão no estado em execução:

kubectl get pods -n APIGEE_NAMESPACE

kubectl get pods -n apigee-system

Use o comando helm para garantir que todas as versões foram atualizadas para a versão híbrida 1.12:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

Por exemplo:

helm -n apigee list
NAME             NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore        apigee     2         2024-03-29 17:08:07.917848253 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager  apigee     2         2024-03-29 17:21:02.917333616 +0000 UTC  deployed  apigee-ingress-manager-1.12.0  1.12.0
redis            apigee     2         2024-03-29 17:19:51.143728084 +0000 UTC  deployed  apigee-redis-1.12.0            1.12.0
telemetry        apigee     2         2024-03-29 17:16:09.883885403 +0000 UTC  deployed  apigee-telemetry-1.12.0        1.12.0
myhybridorg      apigee     2         2024-03-29 17:21:50.899855344 +0000 UTC  deployed  apigee-org-1.12.0              1.12.0

Reverta cada componente, exceto o apigee-datastore, com os seguintes comandos:

Crie a seguinte variável de ambiente:
- PREVIOUS_HELM_CHARTS_HOME: o diretório em que os gráficos anteriores do Helm da Apigee híbrida estão instalados. Você está revertendo essa versão.
Reverter os virtualhosts. Repita o comando a seguir para cada grupo de ambientes mencionado no arquivo de substituições.
```
helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
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.
Reverter ambientes Repita o comando a seguir para cada ambiente mencionado no arquivo de substituições.
```
helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
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 1.11 e mais recentes da versão híbrida, geralmente ele é ENV_NAME.

Verifique se cada env está em execução conferindo o estado do respectivo env:
```
kubectl -n apigee get apigeeenv
```
```
NAME                  STATE     AGE   GATEWAYTYPE
apigee-org1-dev-xxx   running   2d
```

Reverter organização:

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Para saber se ele está funcionando, confira o estado da respectiva organização:

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

Reverter o Ingress Manager:

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Para saber se ele está funcionando, confira a disponibilidade:

kubectl -n apigee get deployment apigee-ingressgateway-manager

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

Reverter o Redis:

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

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

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Reverter a telemetria da Apigee:

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

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

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Reverter o controlador da Apigee:

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Verifique a instalação do operador da Apigee:

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.2   1.12.2

Para saber se ele está funcionando, confira a disponibilidade:

kubectl -n apigee-system get deploy apigee-controller-manager

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

Reverter as CRDs da Apigee híbrida:

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

Valide a versão de todos os componentes. Todos os componentes precisam estar na versão anterior, exceto o datastore:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

Por exemplo:

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

Neste ponto, todas as versões, exceto o datastore, foram revertidas para a versão anterior.

Como recuperar uma instalação multirregional para uma versão anterior

Para recuperar a região onde o upgrade falhou em um upgrade multirregional, remova as referências a ela em instalações de várias regiões. Esse método só é possível quando há pelo menos uma região ativa na versão híbrida 1.11. O repositório de dados da v1.12 é compatível com os componentes da v1.11.

Para recuperar as regiões com falha de uma região íntegra, siga estas etapas:

Redirecione o tráfego da API das regiões afetadas para a boa região de trabalho. Planeje a capacidade de acordo com o tráfego desviado de regiões com falha.
Desativar a região afetada. Para cada região afetada, siga as etapas descritas em Desativar uma região híbrida. Aguarde a desativação ser concluída antes de passar para a próxima etapa.
Limpe a região com falha seguindo as instruções em Recuperar uma região após um upgrade com falha.
Recupere a região afetada. Para restaurar, crie uma nova região, conforme descrito em Implantação multirregional no GKE, GKE On-Prem e AKS.

Como restaurar uma instalação multirregional por um backup com o `apigee-datastore` em mau estado

Se o upgrade do componente apigee-datastore não for bem-sucedido, não será possível reverter da versão 1.12 para a versão 1.11. Em vez disso, é necessário restaurar de um backup feito de uma instalação da v1.11. Use a sequência abaixo para restaurar a versão anterior.

Se você não tiver uma instalação ativa da Apigee híbrida versão 1.11 (por exemplo, em outra região), crie uma nova instalação da v1.11 usando seus backups de gráficos e arquivos de substituições. Veja as instruções de instalação da Apigee híbrida versão 1.11.
Restaure a região da v1.11 (ou a nova instalação) pelo backup seguindo as instruções em:
- Backups da interface do Cloud Storage (CSI): backup e restauração do CSI do Cassandra.
- Backups de não CSI: como restaurar em várias regiões.
Verificar o tráfego para a instalação restaurada
Para instalações multirregionais, recrie e restaure a próxima região. Consulte as instruções em Como restaurar de um backup em Como restaurar em várias regiões.
Para remover a instalação da versão 1.12, siga as instruções em Desinstalar o ambiente de execução híbrido.

APÊNDICE: recuperar uma região após um upgrade com falha

Remova um datacenter se o upgrade falhar da versão 1.11 para a 1.12.

Valide o status do cluster do Cassandra em uma região ativa:

Mude o contexto do kubectl para a região a ser removida:
```
kubectl config use-context CONTEXT_OF_LIVE_REGION
```

Liste os pods do Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

Exemplo:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                 READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

Execute em um dos pods do Cassandra:

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

Verifique o status do cluster do Cassandra:

nodetool -u JMX_USER -pw JMX_PASSWORD status

A resposta será semelhante a esta:

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.48.12.16  813.84 KiB  256          100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.14.16  859.89 KiB  256          100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
UN  10.48.0.18   888.95 KiB  256          100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1

Descreva o cluster para verificar se são exibidos apenas IPs de pods do Cassandra da região ativa e todos eles na mesma versão do esquema:

nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

A resposta será semelhante a esta:

nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

Schema versions:
    4bebf2de-0582-31b4-9c5f-e36f60127e1b: [10.48.14.16, 10.48.12.16, 10.48.0.18]

Limpe a replicação de keyspace do Cassandra:

Acesse e exclua o job user-setup. Um novo job user-setup será criado imediatamente.

kubectl get jobs -n APIGEE_NAMESPACE

Exemplo:

kubectl get jobs -n apigee
  NAME                                                           COMPLETIONS   DURATION   AGE
  apigee-cassandra-schema-setup-myhybridorg-8b3e61d          1/1           6m35s      3h5m
  apigee-cassandra-schema-val-myhybridorg-8b3e61d-28499150   1/1           10s        9m22s
 apigee-cassandra-user-setup-myhybridorg-8b3e61d            0/1           21s        21s

kubectl delete jobs USER_SETUP_JOB_NAME -n APIGEE_NAMESPACE

A saída mostrará o novo job sendo iniciado:

kubectl delete jobs apigee-cassandra-user-setup-myhybridorg-8b3e61d -n apigee

  apigee-cassandra-user-setup-myhybridorg-8b3e61d-wl92b         0/1     Init:0/1    0               1s

Valide as configurações de replicação de keyspace do Cassandra criando um contêiner do cliente conforme as instruções em Criar o contêiner do cliente.

Encontre todos os keyspaces. Execute o comando no pod cassandra-client e inicie um cliente cqlsh:

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

Conecte-se ao servidor do Cassandra com ddl user, porque ele tem as permissões necessárias para executar os seguintes comandos:

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

Encontre os keyspaces:

select * from system_schema.keyspaces;

A saída será semelhante a esta, em que dc-1 é controlador de domínio (DC) ativo:

select * from system_schema.keyspaces;

 keyspace_name            | durable_writes | replication
--------------------------+----------------+--------------------------------------------------------------------------------
   kvm_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_schema |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
 quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
 cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   rtc_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                   system |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                   perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   kms_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

Se por algum motivo o job user-setup continuar com erros e a validação falhar, use os comandos a seguir para corrigir a replicação em keyspaces.

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

Conecte-se ao servidor do Cassandra com ddl user, porque ele tem as permissões necessárias para executar os seguintes comandos:

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

Encontre os keyspaces:

select * from system_schema.keyspaces;

Use os nomes dos keyspaces no comando acima e substitua-os nos exemplos a seguir

alter keyspace quota_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kms_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kvm_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace cache_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace perses_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace rtc_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_distributed WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_traces WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};

Confirme se todos os keyspaces estão sendo replicados na região correta com o seguinte comando cqlsh:

select * from system_schema.keyspaces;

Exemplo:

select * from system_schema.keyspaces;

 keyspace_name           | durable_writes | replication
-------------------------+----------------+--------------------------------------------------------------------------------
kvm_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
          system_auth    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_schema    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
rtc_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   system_distributed    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
               system    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
               perses    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_traces    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
kms_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

Nesta etapa, você removeu por completo todas as referências ao DC inativo do cluster do Cassandra.

APÊNDICE: remover nós INATIVOS de cluster do Cassandra

Siga este procedimento quando for reverter uma instalação multirregional e nem todos os pods do Cassandra estiverem no estado Ativo/Normal (UN).

Execute em um dos pods do Cassandra:

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

Verifique o status do cluster do Cassandra:

nodetool -u JMX_USER -pw JMX_PASSWORD status

Verifique se o nó está realmente inativo (DN). Execute no pod do Cassandra em uma região onde o pod do Cassandra não pode ser criado.

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.15 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.21 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.18 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
DN  10.8.4.4     432.42 KiB  256     100.0%            cd672398-5c45-4c88-a424-86d757951e53  rc-1
UN  10.8.19.6    5.8 MiB     256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.21.5    5.74 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

Remova a referência ao nó inativo (DN). Com o exemplo acima, removeremos a referência ao host 10.8.4.4

kubectl exec -it -n apigee apigee-cassandra-default-2 -- /bin/bash
 nodetool -u JMX_USER -pw JMX_PASSWORD removenode HOST_ID

Depois que a referência for removida, encerre o pod. O novo pod do Cassandra será criado e entrará no cluster
```
kubectl delete pod -n POD_NAME
```

Verificar se o novo pod do Cassandra entrou no cluster.

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.16 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.22 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.19 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.8.19.6    5.77 MiB    256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.4.5     246.99 KiB  256     100.0%            0182e675-eec8-4d68-a465-69211b621601  rc-1
UN  10.8.21.5    5.69 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

Depois disso, será possível fazer upgrade ou fazer a reversão das regiões restantes do cluster.

APÊNDICE: solução de problemas: `apigee-datastore` em um estado travado após a reversão

Siga este procedimento se você tiver revertido o apigee-datastore para a versão híbrida 1.11 após o upgrade e ele estiver travado.

Antes de corrigir novamente o estado do controlador do repositório de dados, confirme se ele está no estado releasing e se os pods não estão aparecendo com o estado do cluster do Cassandra.

Valide usando o comando do Helm em que o repositório de dados foi revertido:

helm -n APIGEE_NAMESPACE list

Exemplo:

helm -n apigee list
NAME              NAMESPACE  REVISION  UPDATED                                   STATUS    CHART                              APP VERSION
datastore         apigee     3         2024-04-04 22:15:08.792539892 +0000 UTC   deployed   apigee-datastore-1.11.0           1.11.0
ingress-manager   apigee     1         2024-04-02 22:24:27.564184968 +0000 UTC   deployed   apigee-ingress-manager-1.12.0     1.12.0
redis             apigee     1         2024-04-02 22:23:59.938637491 +0000 UTC   deployed   apigee-redis-1.12.0               1.12.0
telemetry         apigee     1         2024-04-02 22:23:39.458134303 +0000 UTC   deployed   apigee-telemetry-1.12             1.12.0
myhybridorg       apigee     1         2024-04-02 23:36:32.614927914 +0000 UTC   deployed   apigee-org-1.12.0                 1.12.0

Encontre o status dos pods do Cassandra:

kubectl get pods -n APIGEE_NAMESPACE

Exemplo:

kubectl get pods -n apigee
NAME                         READY   STATUS             RESTARTS      AGE
apigee-cassandra-default-0   1/1     Running            0             2h
apigee-cassandra-default-1   1/1     Running            0             2h
apigee-cassandra-default-2   0/1     CrashLoopBackOff   4 (13s ago)   2m13s

Verifique se o controlador apigeeds está travado no estado "em liberação":

kubectl get apigeeds -n APIGEE_NAMESPACE

Exemplo:

kubectl get apigeeds -n apigee
NAME      STATE       AGE
default   releasing   46h

Valide os status dos nós do Cassandra (observe que um nó está no estado DN, que é o nó travado no estado CrashLoopBackOff):

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

Exemplo:

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Defaulted container "apigee-cassandra" out of: apigee-cassandra, apigee-cassandra-ulimit-init (init)
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load       Tokens   Owns (effective)   Host ID                               Rack
UN   10.68.7.28    2.12 MiB   256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3  rc-1
UN   10.68.10.29   2.14 MiB   256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452  rc-1
DN   10.68.6.26    5.77 MiB   256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1

Faça upgrade do repositório de dados usando os gráficos da 1.12.
Observação: o controlador entrará no estado releasing novamente, mas, desta vez, ele criará pods com as imagens da versão híbrida 1.12 que serão geradas e o Cassandra entrará no cluster e se tornará UN (ATIVO/NORMAL).
```
helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/   --install   --namespace APIGEE_NAMESPACE   -f overrides.yaml
```

Verifique se todos os pods estão Running e se o cluster do Cassandra está íntegro novamente.

Verifique se todos os pods estão READY novamente:

kubectl get pods -n APIGEE_NAMESPACE

Exemplo:

kubectl get pods -n apigee
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          29h
apigee-cassandra-default-1   1/1     Running   0          29h
apigee-cassandra-default-2   1/1     Running   0          60m

Validar o status do cluster do Cassandra:

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

Exemplo:

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load      Tokens   Owns (effective)   Host ID                                Rack
UN   10.68.4.15    2.05 MiB  256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
UN   10.68.7.28    3.84 MiB  256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3   rc-1
UN   10.68.10.29   3.91 MiB  256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452   rc-1

Valide o status do controlador apigeeds:

kubectl get apigeeds -n APIGEE_NAMESPACE

Exemplo:

kubectl get apigeeds -n apigee
NAME      STATE     AGE
default   running   2d1h

Neste ponto, você corrigiu o repositório de dados, que precisa estar no estado running.

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

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

Considerações antes de iniciar um upgrade para a versão 1.12

Considerações antes de fazer upgrade de uma instalação de região única

Considerações antes de fazer upgrade de uma instalação multirregional

Pré-requisitos

Limitações

Como fazer upgrade para a versão 1.12.2

Preparar para fazer upgrade para a versão 1.12

Fazer backup do Cassandra

Fazer backup dos diretórios 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.12.2

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

Reversão e recuperação de região única

Como reverter quando o apigee-datastore está em bom estado

Como restaurar quando o apigee-datastore não está em bom estado

Reversão e recuperação multirregionais

Como reverter quando o apigee-datastore está em bom estado

Como recuperar uma instalação multirregional para uma versão anterior

Como restaurar uma instalação multirregional por um backup com o apigee-datastore em mau estado

APÊNDICE: recuperar uma região após um upgrade com falha

APÊNDICE: remover nós INATIVOS de cluster do Cassandra

APÊNDICE: solução de problemas: apigee-datastore em um estado travado após a reversão

Como reverter quando o `apigee-datastore` está em bom estado

Como restaurar quando o `apigee-datastore` não está em bom estado

Como reverter quando o `apigee-datastore` está em bom estado

Como restaurar uma instalação multirregional por um backup com o `apigee-datastore` em mau estado

APÊNDICE: solução de problemas: `apigee-datastore` em um estado travado após a reversão