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

Version 1.12 

Versões com suporte:

• v1.12 (mais recente)
• v1.11
• v1.10
• Lista de versões com suporte

Versões sem suporte:

• v1.9
• v1.8
• v1.7
• v1.6
• v1.5
• v1.4
• v1.3
• v1.2
• v1.1

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

Observação: consulte as notas da versão 1.12.0-hotfix.1 indicando que o hotfix é uma mudança aos modelos de gráficos do Helm e não uma mudança nas imagens.

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:

1. 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.
2. 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.
3. Faça upgrade da região recém-adicionada para a versão híbrida 1.12.
4. Mude o tráfego para a nova região e valide-o.
5. Após a validação, faça upgrade da região mais antiga com a versão híbrida 1.12.
6. Mude todo o tráfego de volta para a região mais antiga e valide-o.
7. 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:

1. Faça backup e valide os dados de cada região antes de iniciar o upgrade.
2. 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.
3. Valide o tráfego na região recém-atualizada.
4. Só faça upgrade de cada região subsequente depois de validar o tráfego na região anterior.
5. 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.1

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

Observação: as alterações do plano de gerenciamento não precisam ser suspensas durante um upgrade. Todas as suspensões necessárias às alterações do plano de gerenciamento estão incluídas nas instruções de upgrade.

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

1. Prepare-se para o upgrade.
   • Fazer backup do Cassandra.
   • Fazer backup dos diretórios da instalação híbrida.
2. Instale o ambiente de execução híbrido versão 1.12.1.

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:

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

  2. Exclua um pod:

     kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

     Exemplo:

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

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

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

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

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

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

3. Faça o backup do banco de dados Cassandra seguindo as instruções em Backup e recuperação do Cassandra.
4. 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/

5. 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 ^(3)	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^(12) 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.14.x (K8s v1.25.x) 1.26.x^(12) 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x^(12) 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
GKE no Azure	1.13.x 1.14.x 1.26.x^(12) 1.27.x^(≥ 1.10.5) 1.28.x^(≥ 1.10.5)	1.14.x 1.26.x^(12) 1.27.x 1.28.x^(≥ 1.11.2) 1.29.x^(≥ 1.11.2)	1.26.x^(12) 1.27.x 1.28.x 1.29.x^(≥ 1.12.1)
Google Distributed Cloud (somente software) no VMware ^(1) ^(13)	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^(12) 1.29.x^(≥ 1.12.1)
Google Distributed Cloud (somente software) em bare metal ^(1)	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^(12)^(≥ 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^(12)^(≥ 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^(12) 1.29.x^(≥ 1.12.1)
EKS^(7)	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^(7)	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^(7)	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^(10)	1.18.x^(10)	1.19.x^(10)
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
^(1) 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 ^(2) Suporte disponível para a Apigee híbrida versão 1.8.4 e mais recentes. ^(3) 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. ^(4)As versões 1.12 e anteriores do Anthos no local (Google Distributed Cloud) não têm suporte. Consulte a Política de suporte da versão do Distributed Cloud em bare metal e a lista de versões compatíveis do Distributed Cloud no VMware. ^(5)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. ^(6) Suporte disponível para a versão híbrida da Apigee 1.8.4 e mais recentes. ^(7) Não compatível com a Apigee híbrida versão 1.8.4 e mais recentes. ^(8) Suporte disponível para a Apigee híbrida versão 1.12.1 e mais recentes. ^(9) Não há suporte na Apigee híbrida 1.8.5 e mais recentes. ^(10) O Cloud Service Mesh é instalado automaticamente com a Apigee híbrida 1.9 e mais recentes. ^(11) Suporte disponível para a Apigee híbrida versão 1.9.2 e mais recentes. ^(12) 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. ^(13) O Vault não é certificado em Google Distributed Cloud for VMware. ^(14) Suporte disponível para a Apigee híbrida versão 1.10.5 e mais recentes. ^(15) Suporte disponível para a Apigee híbrida versão 1.11.2 e mais recentes. ^(16) 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.

Observação: no momento, as instalações híbridas não são compatíveis com clusters do Autopilot.

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

Observação: não crie novos ambientes durante o processo de upgrade.

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

Para este procedimento de upgrade, presumimos que você esteja usando o mesmo namespace e contas de serviço para a instalação atualizada. Se você estiver fazendo alguma alteração na configuração, não se esqueça de refletir essas alterações no arquivo de modificações antes de instalar os gráficos do Helm.

Observação: consulte as notas da versão 1.12.0-hotfix.1 indicando que o hotfix é uma mudança aos modelos de gráficos do Helm e não uma mudança nas imagens.

1. Faça a seguinte mudança no arquivo overrides.yaml para ativar o gráfico apigee-operator usando a tag correta, 1.12.1-hotfix.1:

   ao:
     image:
       url: "gcr.io/apigee-release/hybrid/apigee-operators"
       tag: "1.12.1-hotfix.1"
   

   Consulte as notas da versão da Apigee 1.12.1-hotfix.1.

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

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

4. Instale os CRDs atualizados da Apigee:
   Observação: a partir desta etapa, todos os comandos serão executados no diretório raiz do repositório do gráfico.
   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.
   Observação: essa etapa requer permissões elevadas de cluster.

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

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

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

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

1. Caso contrário, acesse o diretório APIGEE_HELM_CHARTS_HOME. Execute os comandos a seguir nesse diretório.
2. 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
   

   Observação: para instalações migradas, use:

   helm upgrade operator apigee-operator/ \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --force \
     -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.1   1.12.1

   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

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

   Observação: para instalações migradas, use:

   helm upgrade datastore apigee-datastore/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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

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

   Observação: para instalações migradas, use:

   helm upgrade telemetry apigee-telemetry/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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

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

   Observação: para instalações migradas, use:

   helm upgrade redis apigee-redis/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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

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

   Observação: para instalações migradas, use:

   helm upgrade ingress-manager apigee-ingress-manager/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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

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

   Observação: para instalações migradas, use:

   helm upgrade ORG_NAME apigee-org/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -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

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

   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

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

Parabéns! Você fez upgrade para a versão híbrida 1.12.1 da Apigee Para testar o upgrade, chame um proxy na nova instalação. Por exemplo, consulte a Etapa 10: implantar um proxy de API no guia de instalação da Apigee híbrida 1.12.

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:

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

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

3. Reverta cada componente, exceto o apigee-datastore, com os seguintes comandos:
   1. 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.
   2. 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.

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

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

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

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

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

   8. 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.1   1.12.1

      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

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

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

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

1. 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.
2. 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.
3. Verificar o tráfego para a instalação restaurada
4. 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

Observação:> use esse método de reversão para reverter de uma região híbrida atualizada para a versão híbrida anterior. Esse método visa fazer a recuperação de um upgrade com falha quando todas as regiões ainda não foram atualizadas.

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.

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

2. 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 processo de upgrade.

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

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

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

3. Navegue até o diretório em que os gráficos anteriores do Helm da Apigee híbrida estão instalados
4. Mude o contexto para a região que foi atualizada

   kubectl config use-context UPGRADED_REGION_CONTEXT
       

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

   kubectl get pods -n APIGEE_NAMESPACE

   kubectl get pods -n apigee-system

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

7. Reverta cada componente, exceto o apigee-datastore, com os seguintes comandos:
   1. 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.
   2. 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.

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

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

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

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

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

   8. 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.1   1.12.1

      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

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

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

Importante: no momento, o repositório de dados do Cassandra é parcialmente atualizado. Recomendamos tentar fazer upgrade novamente resolvendo todos os problemas encontrados durante o upgrade anterior e repetindo o processo. Se não for viável tentar outro upgrade, a recomendação é recuperar o repositório de dados usando as instruções em Como recuperar uma instalação multirregional para uma 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:

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

3. Limpe a região com falha seguindo as instruções em Recuperar uma região após um upgrade com falha.
4. 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.

Dica: para minimizar a inatividade em instalações multirregionais, a Apigee recomenda recriar e restaurar uma região por vez.

1. 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.
2. 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.
3. Verificar o tráfego para a instalação restaurada
4. 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.
5. 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.

1. Valide o status do cluster do Cassandra em uma região ativa:
   1. Mude o contexto do kubectl para a região a ser removida:

      kubectl config use-context CONTEXT_OF_LIVE_REGION

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

   3. Execute em um dos pods do Cassandra:

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

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

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

2. Limpe a replicação de keyspace do Cassandra:
   1. 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
        

   2. 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.
   3. 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)
      

   4. 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.
      Cuidado: use os comandos a seguir com muito cuidado.

      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'};

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

1. Execute em um dos pods do Cassandra:

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

2. Verifique o status do cluster do Cassandra:

   nodetool -u JMX_USER -pw JMX_PASSWORD status

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

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

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

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

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

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

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

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

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

3. Verifique se todos os pods estão Running e se o cluster do Cassandra está íntegro novamente.
   1. 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

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

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