Atualizar o Apigee Hybrid para a versão 1.12

Está a ver a versão 1.12 da documentação do Apigee híbrido. This version is end of life. You should upgrade to a newer version. Para mais informações, consulte Versões suportadas.

Version 1.12 

   Versões suportadas:

• v1.15 (mais recente)                        
• v1.14                        
• v1.13                         
• Lista de versões suportadas

   Versões não suportadas:

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

Este procedimento abrange a atualização da versão 1.11.x do Apigee Hybrid para a versão 1.12.4 do Apigee Hybrid e das versões anteriores do Hybrid 1.12.x para a versão 1.12.4.

Use os mesmos procedimentos para atualizações de versões secundárias (por exemplo, da versão 1.11 para a 1.12) e para atualizações de lançamentos de patches (por exemplo, da versão 1.12.0 para a 1.12.4).

Se estiver a atualizar a partir da versão 1.10 ou anterior do Apigee hybrid, tem de atualizar primeiro para a versão 1.11 antes de atualizar para a versão 1.12.4. Consulte as instruções para atualizar o Apigee Hybrid para a versão 1.11.

Alterações do Apigee Hybrid v1.11

A versão 1.12 do Apigee Hybrid introduz as seguintes alterações que afetam o processo de atualização. Para ver uma lista completa das funcionalidades na versão 1.12, consulte as notas de lançamento da versão 1.12.0 híbrida.

• Cassandra 4.x: a partir da versão 1.12, o Apigee hybrid usa a versão 4 ou superior do Cassandra.
  Importante: devido à alteração da base de dados, não pode reverter o componente apigee-datastore atualizado. Por conseguinte, é fundamental que faça uma cópia de segurança da base de dados do Cassandra e da instalação híbrida antes de fazer a atualização. Se precisar de reverter a atualização, considere os seguintes cenários:

  • Cassandra ainda não atualizado: pode reverter todas as alterações.
  • Cassandra atualizado e todos os pods do Cassandra estão em bom estado: pode reverter as alterações a todos os componentes, exceto apigee-datastore. A sua instalação da versão 1.11.x vai continuar a funcionar com uma instância da versão 1.12 do apigee-datastore que executa o Cassandra v4.
  • O Cassandra foi atualizado e os pods do Cassandra estão num estado não saudável: tem de desinstalar o Hybrid v1.12 e restaurar a instalação da versão 1.11 a partir de uma cópia de segurança.
• Descontinuação do apigeectl: a partir da versão 1.12, o Apigee Hybrid só suporta o Helm para instalar e gerir a sua instalação híbrida.
  Atenção: apigeectl foi descontinuado a 17 de abril de 2024. A ferramenta apigeectl não é suportada para o Apigee hybrid v1.12. O suporte para apigeectl para o Apigee hybrid v1.10 e v1.11 termina a 17 de abril de 2025. Para mais informações, consulte o artigo Descontinuação do apigeectl.
  Importante: se estiver a gerir a versão 1.11 com o apigeectl, primeiro tem de migrar a instalação da versão 1.11 para usar o Helm antes de atualizar para a versão 1.12. Siga as instruções em Migre o Apigee hybrid para gráficos Helm a partir de apigeectl.

• Está agora disponível um novo conjunto de métricas para monitorizar proxies do Apigee e pontos finais de destino. Para a versão híbrida 1.12, os recursos monitorizados ProxyV2 e TargetV2 vão deixar de ser usados por predefinição. Todas as métricas de proxy e de destino são publicadas nos recursos monitorizados Proxy e Target.

  Para continuar a emitir métricas para os recursos monitorizados ProxyV2 e TargetV2, defina metrics.disablePrometheusPipeline como true no overrides.yaml.

  Se tiver alertas baseados em métricas configurados, confirme a utilização das métricas corretas para a sua instalação híbrida. Para mais informações, consulte o artigo Alertas baseadas em métricas.

• Verificações de instanciação de classes mais rigorosas: a partir da versão 1.12.4, o Apigee hybrid, a política JavaCallout inclui agora segurança adicional durante a instanciação de classes Java. A medida de segurança melhorada impede a implementação de políticas que tentam direta ou indiretamente ações que requerem autorizações não permitidas.

  Na maioria dos casos, as políticas existentes continuam a funcionar como esperado, sem problemas. No entanto, existe a possibilidade de as políticas que dependem de bibliotecas de terceiros ou que têm código personalizado que aciona indiretamente operações que requerem autorizações elevadas serem afetadas.

  Importante: para testar a instalação, siga o procedimento em Valide as políticas após a atualização para a versão 1.12.4 para validar o comportamento das políticas.

Considerações antes de iniciar uma atualização para a versão 1.12

Considerações sobre o Cassandra

A atualização da versão 1.11 do Apigee Hybrid para a versão 1.12 inclui uma atualização da base de dados Cassandra da versão 3.11.x para a versão 4.x. Embora a atualização do Cassandra seja processada como parte do procedimento de atualização do Apigee hybrid, planeie as seguintes considerações:

• A atualização da versão do Cassandra ocorre em segundo plano e é realizada num pod (ou num nó do Cassandra) de cada vez. Por isso, planeie uma capacidade reduzida da base de dados durante a atualização.
• Aumente a capacidade do Cassandra e certifique-se de que a utilização do disco está perto ou abaixo de 50% antes de começar a atualização.
• Valide e teste os procedimentos de restauro e cópia de segurança do Cassandra.
• Faça uma cópia de segurança dos dados do Cassandra na instalação híbrida da versão 1.11 antes de começar a atualização e valide as cópias de segurança.
• A atualização do apigee-datastore vai resultar num aumento temporário do consumo da CPU devido às tarefas pós-atualização realizadas pelo Cassandra
• Depois de atualizar o componente apigee-datastore (Cassandra), não pode reverter esse componente para a versão anterior. Existem dois cenários para reverter uma atualização para a versão híbrida 1.12 depois de atualizar o componente apigee-datastore:
  • Se o componente apigee-datastore estiver em bom estado, mas outros componentes requererem uma reversão, pode reverter esses outros componentes individualmente.
    Nota: não pode adicionar regiões nem dimensionar nós do Cassandra enquanto executa componentes de diferentes versões híbridas.
  • Se o componente apigee-datastore estiver num estado incorreto, tem de restaurar a partir de uma cópia de segurança da versão 1.11 para uma instalação da versão 1.11.
    Nota: não pode misturar versões quando restaura. Tem de restaurar uma cópia de segurança feita numa instalação v1.11 numa instalação v1.11.

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

Se precisar de reverter para uma versão anterior do Apigee hybrid, o processo pode exigir tempo de inatividade. Por conseguinte, se estiver a atualizar uma instalação de uma única região, é recomendável criar uma segunda região e, em seguida, atualizar apenas uma região de cada vez na seguinte sequência:

1. Adicione uma segunda região à sua instalação existente através da mesma versão híbrida. Consulte a Implementação em várias regiões na documentação da versão 1.11.
2. Crie uma cópia de segurança e valide os dados da primeira região antes de iniciar uma atualização. Consulte a vista geral da cópia de segurança do Cassandra na documentação da versão 1.11.
3. Atualize a região adicionada recentemente para o híbrido 1.12.
4. Mude o tráfego para a nova região e valide o tráfego.
5. Após a validação, atualize a região mais antiga com a versão híbrida 1.12.
6. Mude todo o tráfego novamente para a região mais antiga e valide o tráfego.
7. Desativar a nova região.

Considerações antes de atualizar uma instalação multirregião

O Apigee recomenda a seguinte sequência para atualizar uma instalação em várias regiões:

1. Faça uma cópia de segurança e valide os dados de cada região antes de iniciar a atualização.
2. Atualize a versão híbrida numa região e certifique-se de que todos os pods estão em execução para validar a atualização.
3. Valide o tráfego na região recentemente atualizada.
4. Atualize cada região subsequente apenas depois de validar o tráfego na região anterior.
5. No caso de uma potencial necessidade de reverter uma atualização numa implementação multirregional, prepare-se para desviar o tráfego das regiões com falhas. Considere adicionar capacidade suficiente na região para onde o tráfego vai ser desviado para processar o tráfego de ambas as regiões.

Pré-requisitos

Antes de atualizar para a versão híbrida 1.12, certifique-se de que a sua instalação cumpre os seguintes requisitos:

• Uma instalação do Apigee Hybrid versão 1.11 gerida com o Helm.
  • Se estiver a gerir a sua instalação híbrida com o apigeectl, tem de migrar primeiro os seus clusters para a gestão do Helm. Consulte o artigo Migre o Apigee Hybrid para o Helm a partir da versão apigeectl na documentação do Hybrid v1.11.
  • Se a sua instalação híbrida estiver a executar uma versão anterior à v1.11, tem de fazer a atualização para a versão 1.11 antes de atualizar para a v1.12. Consulte o artigo Atualizar o Apigee Hybrid para a versão 1.11.
• Versão do Helm v3.14.2 ou superior.
• kubectl versão 1.27, 1.28 ou 1.29 (recomendado).
• Versão v1.13.0 do cert-manager. Se necessário, atualize o cert-manager na secção Prepare-se para atualizar para a versão abaixo.

Limitações

Tenha em atenção as seguintes limitações ao planear a atualização da versão 1.11 do Apigee hybrid para a versão 1.12. O planeamento pode ajudar a reduzir a necessidade de tempo de inatividade se precisar de reverter ou restaurar após a atualização.

• Não é possível restaurar cópias de segurança do Hybrid 1.12 no Hybrid 1.11 e vice-versa devido à incompatibilidade entre as duas versões.
• Não pode dimensionar os pods da base de dados durante a atualização para a versão 1.12. Satisfaça as suas necessidades de escalabilidade em todas as regiões antes de começar a atualizar a instalação híbrida.
• Numa instalação híbrida de região única, não pode reverter o componente da base de dados assim que o processo de atualização da base de dados estiver concluído. Não é possível reverter um arquivo de dados do Cassandra 4.x para um arquivo de dados do Cassandra 3.x. Isto requer o restauro a partir da cópia de segurança mais recente dos dados do Cassandra 3.x (da instalação da versão 1.11 híbrida).
• A eliminação ou a adição de uma região não é suportada durante a atualização. Numa atualização de várias regiões, tem de concluir a atualização de todas as regiões antes de poder adicionar ou eliminar regiões.

Atualização para a versão 1.12.4: vista geral

A atualização para a versão 1.12 do Apigee Hybrid pode exigir tempo de inatividade.

Quando atualizar o controlador do Apigee para a versão 1.12.4, todas as implementações do Apigee são reiniciadas progressivamente. Para minimizar o tempo de inatividade em ambientes híbridos de produção durante um reinício contínuo, certifique-se de que está a executar, pelo menos, dois clusters (na mesma região ou num centro de dados diferente). Desvie todo o tráfego de produção para um único cluster e coloque o cluster que está prestes a atualizar offline. Em seguida, avance com o processo de atualização. Repita o processo para cada cluster.

A Apigee recomenda que atualize todos os clusters assim que possível para reduzir as probabilidades de impacto na produção. Não existe um limite de tempo para quando todos os clusters restantes têm de ser atualizados depois de o primeiro ser atualizado. No entanto, até que todos os clusters restantes sejam atualizados, as seguintes operações são afetadas:

• A cópia de segurança e o restauro do Cassandra não podem funcionar com versões misturadas. Por exemplo, não é possível usar uma cópia de segurança do Hybrid 1.11 para restaurar uma instância do Hybrid 1.12.
• O streaming de dados do Cassandra não funciona entre versões híbridas misturadas. Por conseguinte, os seus clusters do Cassandra não podem ser dimensionados horizontalmente.
• A expansão e a desativação de regiões vão ser afetadas, porque estas operações dependem do streaming de dados do Cassandra.

Nota: não é necessário suspender as alterações do plano de gestão durante uma atualização. Todas as suspensões necessárias às alterações do plano de gestão estão incluídas nas instruções de atualização.

Os procedimentos para atualizar o Apigee hybrid estão organizados nas seguintes secções:

1. Prepare-se para a atualização.
   • Faça uma cópia de segurança do Cassandra.
   • Faça uma cópia de segurança dos diretórios de instalação híbrida.
2. Instale a versão 1.12.4 do tempo de execução híbrido.

Prepare-se para atualizar para a versão 1.12

Cópia de segurança do Cassandra

• Faça uma cópia de segurança da base de dados Cassandra em todas as regiões aplicáveis e valide os dados na instalação da versão 1.11 híbrida antes de iniciar a atualização. Consulte a secção Monitorizar cópias de segurança na documentação da versão 1.11.
• Reinicie todos os pods do Cassandra no cluster antes de iniciar o processo de atualização para que quaisquer problemas persistentes possam surgir.

  Para reiniciar e testar os pods do Cassandra, elimine cada pod individualmente, um de cada vez, e, em seguida, valide se regressa a um estado de execução e se a sondagem de prontidão é aprovada:

  1. Apresente os pods do Cassandra:

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

     Por 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. Elimine um pod:

     kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

     Por exemplo:

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

  3. Verifique o estado listando novamente os pods do Cassandra:

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

     Por 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 novamente o último ficheiro de substituição conhecido para garantir que não foram feitas alterações ao mesmo, para que possa usar a mesma configuração para atualizar para a versão híbrida 1.12.
• Certifique-se de que todos os nós do Cassandra em todas as regiões estão no estado UN (Up / Normal). Se algum nó do Cassandra estiver num estado diferente, resolva esse problema primeiro antes de iniciar a atualização.

  Pode validar o estado dos seus nós do Cassandra com os seguintes comandos:

  1. Apresente os pods do Cassandra:

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

     Por 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

     Por 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

Faça uma cópia de segurança dos diretórios de 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 ficheiros onde instalou os gráficos Helm. Se necessário, altere o diretório para este diretório e defina a variável com o seguinte comando:

   Linux

   export APIGEE_HELM_CHARTS_HOME=$PWD
   echo $APIGEE_HELM_CHARTS_HOME

   Mac OS

   export APIGEE_HELM_CHARTS_HOME=$PWD
   echo $APIGEE_HELM_CHARTS_HOME

   Windows

   set APIGEE_HELM_CHARTS_HOME=%CD%
   echo %APIGEE_HELM_CHARTS_HOME%

2. Faça uma cópia de segurança do diretório 1.11 $APIGEE_HELM_CHARTS_HOME/. Pode usar qualquer processo de cópia de segurança. Por exemplo, pode criar um ficheiro 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 uma cópia de segurança da base de dados Cassandra seguindo as instruções em Cópia de segurança e recuperação do Cassandra.
4. Se estiver a usar ficheiros de certificado de serviço (.json) nas suas substituições para autenticar contas de serviço, certifique-se de que os ficheiros de certificado de serviço residem no diretório do gráfico Helm correto. Os gráficos Helm não podem ler ficheiros fora do diretório de cada gráfico.

   Este passo não é obrigatório se estiver a usar segredos do Kubernetes ou a identidade de carga de trabalho para autenticar contas de serviço.

   A tabela seguinte mostra o destino de cada ficheiro de conta de serviço, consoante o seu tipo de instalação:

   Prod

   Conta de serviço	Nome do ficheiro predefinido	Diretório do gráfico 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/

   Não prod

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

   Conta de serviço	Nome do ficheiro predefinido	Diretórios de gráficos 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. Certifique-se de que os ficheiros de chave e certificado TLS (.crt, .key e/ou .pem) residem no diretório $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

Atualize a versão do Kubernetes

Verifique a versão da plataforma Kubernetes e, se necessário, atualize-a para uma versão suportada pelo híbrido 1.11 e pelo híbrido 1.12. Siga a documentação da sua plataforma se precisar de ajuda.

Clique para expandir uma lista de plataformas suportadas

	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 no 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 (apenas 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 (apenas 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
Leme	3.10+	3.10+	3.14.2+
Controlador CSI da Secret Store		1.3.4	1.4.1
Vault		1.13.x	1.15.2
^(1) No Anthos on-premises (Google Distributed Cloud) versão 1.13, siga estas instruções para evitar conflitos com cert-manager: Instalação do cert-manager em conflito ^(2) Apoio técnico disponível com a versão 1.7.2 e mais recentes do Apigee Hybrid. ^(3) As datas oficiais de FdV para as versões 1.10 e anteriores do Apigee Hybrid foram atingidas. Os patches mensais normais já não estão disponíveis. Estas versões já não são oficialmente suportadas, exceto para clientes com exceções explícitas e oficiais para apoio técnico contínuo. Outros clientes têm de fazer a atualização. ^(4)As versões 1.12 e anteriores do Anthos on-premises (Google Distributed Cloud) estão fora do âmbito do apoio técnico. Consulte a Política de apoio técnico de versões do Distributed Cloud on bare metal e a lista de versões suportadas do Distributed Cloud on VMware. ^(5)O Google Distributed Cloud em hardware sem sistema operativo ou VMware requer o Cloud Service Mesh 1.14 ou posterior. Recomendamos que atualize para o híbrido v1.8 e mude para o gateway de entrada do Apigee, que já não requer a instalação do Cloud Service Mesh no cluster híbrido. ^(6) Apoio técnico disponível com a versão 1.8.4 e mais recentes do Apigee Hybrid. ^(7) Não suportado com a versão 1.8.4 e mais recentes do Apigee Hybrid. ^(8) Apoio técnico disponível com o Apigee Hybrid versão 1.7.6 e mais recente. ^(9) Não suportado com a versão 1.8.5 e mais recentes do Apigee Hybrid. ^(10) O Cloud Service Mesh é instalado automaticamente com o Apigee hybrid 1.9 e mais recente. ^(11) Apoio técnico disponível com a versão 1.9.2 e mais recentes do Apigee Hybrid. ^(12) Os números das versões do GKE no AWS refletem agora as versões do Kubernetes. Consulte o artigo GKE Enterprise versão e suporte de atualizações para ver detalhes da versão e patches recomendados. ^(13) O Vault não está certificado no Google Distributed Cloud para VMware. ^(14) Apoio técnico disponível com a versão 1.10.5 e mais recente do Apigee Hybrid. ^(15) Apoio técnico disponível com a versão 1.11.2 e mais recentes do Apigee Hybrid. ^(16) Apoio técnico disponível com a versão 1.12.1 e mais recentes do Apigee Hybrid.

Acerca dos clusters associados

Para o Apigee hybrid versões 1.7.x e anteriores, tem de usar clusters anexados do GKE se quiser executar o Apigee hybrid num contexto de várias nuvens no Elastic Kubernetes Service (EKS), no Azure Kubernetes Service (AKS) ou noutro fornecedor de serviços Kubernetes de terceiros suportado. A associação de clusters permite à Google medir a utilização da Cloud Service Mesh.

Para a versão 1.8.x do Apigee hybrid, são necessários clusters anexados do GKE se estiver a usar o Cloud Service Mesh para o gateway de entrada. Se estiver a usar o gateway de entrada do Apigee, os clusters anexados são opcionais.

Nota: atualmente, as instalações híbridas não são suportadas em clusters do Autopilot.

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

Atenção: não crie novos ambientes durante o processo de atualização.

Prepare-se para a atualização dos gráficos Helm

Este procedimento de atualização pressupõe que está a usar o mesmo espaço de nomes e contas de serviço para a instalação atualizada. Se estiver a fazer alterações à configuração, certifique-se de que reflete essas alterações no ficheiro de substituições antes de instalar os gráficos Helm.

1. Extraia os gráficos Helm do Apigee.

   Os gráficos do Apigee Hybrid estão alojados no Google Artifact Registry:

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

   Usando o comando pull, copie todos os gráficos Helm do Apigee hybrid para o seu armazenamento local com o seguinte comando:

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

2. Atualize o cert-manager, se necessário.

   Se precisar de atualizar a 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
   

3. Instale os CRDs do Apigee atualizados:
   Nota: a partir deste passo, todos os comandos devem ser executados no diretório raiz do repositório do gráfico.
   Nota: este é o único método suportado para instalar CRDs do Apigee. Não use kubectl apply sem -k, não omita --server-side.
   Nota: este passo requer autorizações de cluster elevadas.

   1. Use a funcionalidade de teste de execução kubectl executando o seguinte comando:

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

   2. Depois de fazer a validação com o comando de teste, execute o seguinte comando:

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

   3. Valide a instalação com o comando kubectl get crds:

      kubectl get crds | grep apigee

      O resultado deve ter um aspeto semelhante ao seguinte:

      apigeedatastores.apigee.cloud.google.com                    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
      

4. Verifique as etiquetas nos nós do cluster. Por predefinição, o Apigee agenda pods de dados em nós com a etiqueta cloud.google.com/gke-nodepool=apigee-data e os pods de tempo de execução são agendados em nós com a etiqueta cloud.google.com/gke-nodepool=apigee-runtime. Pode personalizar as etiquetas do conjunto de nós no ficheiro overrides.yaml.

   Para mais informações, consulte o artigo Configurar pools de nós dedicados.

Instale os gráficos Helm do Apigee Hybrid

Nota: antes de executar qualquer um dos comandos de instalação/atualização do Helm, use a funcionalidade de teste do Helm adicionando --dry-run no final do comando. Consulte helm -h para ver uma lista dos comandos, das opções e da utilização suportados.

1. Se não o tiver feito, navegue para o diretório APIGEE_HELM_CHARTS_HOME. Execute os seguintes comandos a partir desse diretório.
2. Atualize o operador/controlador do Apigee:
   Nota: este passo requer autorizações de cluster elevadas. Execute helm -h ou helm upgrade -h para ver os detalhes

   Execução de ensaio:

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

   Atualize o gráfico:

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

   Nota: para instalações migradas do apigeectl para o Helm, use:

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

   Valide a instalação do operador do 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.4   1.12.4

   Verifique se está em funcionamento, verificando a respetiva 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. Atualize o repositório de dados do Apigee:

   Execução de ensaio:

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

   Atualize o gráfico:

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

   Nota: para instalações migradas do apigeectl para o Helm, use:

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

   Verifique se o serviço apigeedatastore está em funcionamento verificando o respetivo estado:

   kubectl -n apigee get apigeedatastore default
   

   NAME      STATE       AGE
   default   running    2d

4. Atualize a telemetria do Apigee:

   Execução de ensaio:

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

   Atualize o gráfico:

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

   Nota: para instalações migradas do apigeectl para o Helm, use:

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

   Verifique se está a funcionar corretamente, verificando o respetivo estado:

   kubectl -n apigee get apigeetelemetry apigee-telemetry
   

   NAME               STATE     AGE
   apigee-telemetry   running   2d

5. Atualize o Redis do Apigee:

   Execução de ensaio:

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

   Atualize o gráfico:

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

   Nota: para instalações migradas do apigeectl para o Helm, use:

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

   Verifique se está a funcionar corretamente, verificando o respetivo estado:

   kubectl -n apigee get apigeeredis default
   

   NAME      STATE     AGE
   default   running   2d

6. Atualize o Apigee Ingress Manager:

   Execução de ensaio:

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

   Atualize o gráfico:

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

   Nota: para instalações migradas do apigeectl para o Helm, use:

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

   Verifique se está em funcionamento, verificando a respetiva 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. Atualize a organização do Apigee:

   Execução de ensaio:

   helm upgrade ORG_NAME apigee-org/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     -f OVERRIDES_FILE \
     --dry-run
   

   Atualize o gráfico:

   helm upgrade ORG_NAME apigee-org/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     -f OVERRIDES_FILE
   

   Nota: para instalações migradas do apigeectl para o Helm, use:

   helm upgrade ORG_NAME apigee-org/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --force \
     -f OVERRIDES_FILE
   

   Verifique se está em funcionamento consultando o estado da organização respetiva:

   kubectl -n apigee get apigeeorg
   

   NAME                      STATE     AGE
   apigee-org1-xxxxx          running   2d

8. Atualize o ambiente.

   Tem de instalar um ambiente de cada vez. Especifique o ambiente com --set env=ENV_NAME:

   Execução de ensaio:

   helm upgrade ENV_RELEASE_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --set env=ENV_NAME \
     -f OVERRIDES_FILE \
     --dry-run
   

   • ENV_RELEASE_NAME é o nome com o qual instalou anteriormente o gráfico apigee-env. No híbrido v1.10, normalmente é apigee-env-ENV_NAME. No Hybrid v1.11 e mais recente, normalmente, é ENV_NAME.
   • ENV_NAME é o nome do ambiente que está a atualizar.
   • OVERRIDES_FILE é o seu novo ficheiro de substituições para a versão 1.12.4

   Atualize o gráfico:

   helm upgrade ENV_RELEASE_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --set env=ENV_NAME \
     -f OVERRIDES_FILE
   

   Nota: para instalações migradas do apigeectl para o Helm, use:

   helm upgrade ENV_RELEASE_NAME apigee-env/ \
     --install \
     --namespace APIGEE_NAMESPACE \
     --set env=ENV_NAME \
     --force \
     -f OVERRIDES_FILE
   

   Verifique se está em funcionamento consultando o estado do ambiente respetivo:

   kubectl -n apigee get apigeeenv
   

   NAME                          STATE       AGE   GATEWAYTYPE
   apigee-org1-dev-xxx            running     2d

9. Atualize os grupos de ambientes (virtualhosts).
   1. Tem de atualizar um grupo de ambientes (virtualhost) de cada vez. Especifique o grupo do ambiente com --set envgroup=ENV_GROUP_NAME. Repita os seguintes comandos para cada grupo de ambiente mencionado no ficheiro overrides.yaml:

      Execução de ensaio:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --set envgroup=ENV_GROUP_NAME \
        -f OVERRIDES_FILE \
        --dry-run
      

      ENV_GROUP_RELEASE_NAME é o nome com o qual instalou anteriormente o gráfico apigee-virtualhost. No híbrido v1.10, normalmente é apigee-virtualhost-ENV_GROUP_NAME. No Hybrid v1.11 e mais recente, é normalmente ENV_GROUP_NAME.

      Atualize o gráfico:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --set envgroup=ENV_GROUP_NAME \
        -f OVERRIDES_FILE
      

      Nota: para instalações migradas do apigeectl para o Helm, use:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
        --install \
        --namespace APIGEE_NAMESPACE \
        --set envgroup=ENV_GROUP_NAME \
        --force \
        -f OVERRIDES_FILE
      

      Nota: ENV_GROUP_RELEASE_NAME tem de ser exclusivo no espaço de nomes apigee.

      Por exemplo, se tiver um ambiente denominado prod e um grupo de ambientes denominado prod, defina o valor de ENV_GROUP_RELEASE_NAME para algo único, como prod-envgroup.

   2. Verifique o estado do ApigeeRoute (AR).

      A instalação do virtualhosts cria o ApigeeRouteConfig (ARC), que cria internamente o ApigeeRoute (AR) assim que o monitor do Apigee extrai os detalhes relacionados com o grupo de ambientes do plano de controlo. Por conseguinte, verifique se o estado do AR correspondente está em execução:

      kubectl -n apigee 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

Valide as políticas após a atualização para a versão 1.12.4

Use este procedimento para validar o comportamento da política JavaCallout após a atualização da versão 1.12.3 ou anterior para a versão 1.12.4 ou posterior.

1. Verifique se os ficheiros JAR Java pedem autorizações desnecessárias.

   Após a implementação da política, verifique os registos de tempo de execução para ver se a seguinte mensagem de registo está presente: "Failed to load and initialize class ...". Se observar esta mensagem, sugere que o JAR implementado pediu autorizações desnecessárias. Para resolver este problema, investigue o código Java e atualize o ficheiro JAR.

2. Investigue e atualize o código Java.

   Reveja qualquer código Java (incluindo dependências) para identificar a causa de operações potencialmente não permitidas. Quando o encontrar, modifique o código-fonte conforme necessário.

3. Teste as políticas com a verificação de segurança ativada.

   Num ambiente de não produção, ative a flag de verificação de segurança e volte a implementar as suas políticas com um JAR atualizado. Para definir a flag:

   • No ficheiro apigee-env/values.yaml, defina conf_security-secure.constructor.only como true em runtime:cwcAppend:. Por exemplo:

     # Apigee Runtime
     runtime:
       cwcAppend:
         conf_security-secure.constructor.only: true

   • Atualize o gráfico apigee-env para que a alteração seja aplicada ao ambiente. Por exemplo:

     helm upgrade ENV_RELEASE_NAME apigee-env/ \
       --install \
       --namespace APIGEE_NAMESPACE \
       --set env=ENV_NAME \
       -f OVERRIDES_FILE

     ENV_RELEASE_NAME é um nome usado para monitorizar a instalação e as atualizações do gráfico apigee-env. Este nome tem de ser exclusivo dos outros nomes de lançamentos do Helm na sua instalação. Normalmente, este valor é igual a ENV_NAME. No entanto, se o seu ambiente tiver o mesmo nome que o seu grupo de ambientes, tem de usar nomes de lançamentos diferentes para o ambiente e o grupo de ambientes, por exemplo, dev-env-release e dev-envgroup-release. Para mais informações sobre lançamentos no Helm, consulte o artigo Três grandes conceitos class="external" na documentação do Helm.

   Se a mensagem de registo "Failed to load and initialize class ..." ainda estiver presente, continue a modificar e testar o JAR até que a mensagem de registo deixe de aparecer.

4. Ative a verificação de segurança no ambiente de produção.

   Depois de testar e validar exaustivamente o ficheiro JAR no ambiente de não produção, ative a verificação de segurança no seu ambiente de produção definindo a flag conf_security-secure.constructor.only como true e atualizando o gráfico apigee-env para o ambiente de produção para aplicar a alteração.

Parabéns! Atualizou para a versão 1.12.4 do Apigee Hybrid. Para testar a atualização, chame um proxy contra a nova instalação. Para ver um exemplo, consulte o Passo 10: implemente um proxy de API no guia de instalação 1.12 do Apigee hybrid.

Reverter para uma versão anterior

Esta secção está dividida em secções consoante o estado do componente apigee-datastore após a atualização para a versão 1.12 do Apigee hybrid. Existem procedimentos para reversão de região única ou várias regiões com o componente apigee-datastore num bom estado e procedimentos para recuperação ou restauro a partir de uma cópia de segurança quando o componente apigee-datastore está num mau estado.

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

Reverter quando apigee-datastore estiver em bom estado

Este procedimento explica como reverter todos os componentes híbridos do Apigee da versão 1.12 para a versão 1.11 exceto apigee-datastore. O componente v1.12 apigee-datastore é retrocompatível com componentes híbridos v1.11.

Aviso: não é possível reverter a versão apigee-datastore. A incompatibilidade de dados entre diferentes versões da base de dados 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, valide se todos os pods estão em estado de execução:

   kubectl get pods -n APIGEE_NAMESPACE

   kubectl get pods -n apigee-system

2. Valide a versão dos componentes com 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 apigee-datastore com os seguintes comandos:
   1. Crie a seguinte variável de ambiente:
      • PREVIOUS_HELM_CHARTS_HOME: o diretório onde os gráficos Helm do Apigee Hybrid anteriores estão instalados. Esta é a versão para a qual está a reverter.
   2. Reverta os anfitriões virtuais. Repita o seguinte comando para cada grupo de ambientes mencionado no ficheiro 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 o qual instalou anteriormente o gráfico apigee-virtualhost. No híbrido v1.10, normalmente é apigee-virtualhost-ENV_GROUP_NAME. No Hybrid v1.11 e mais recente, é normalmente ENV_GROUP_NAME.

   3. Reverter ambientes Repita o seguinte comando para cada ambiente mencionado no ficheiro 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 o qual instalou anteriormente o gráfico apigee-env. No híbrido v1.10, normalmente é apigee-env-ENV_NAME. No Hybrid v1.11 e mais recente, é normalmente ENV_NAME.

      Verifique se está em funcionamento consultando o estado do ambiente respetivo:

      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
      

      Verifique se está em funcionamento consultando o estado da organização respetiva:

      kubectl -n apigee get apigeeorg
      

      NAME                STATE     AGE
      apigee-org1-xxxxx   running   2d

   5. Reverta o Ingress Manager:

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

      Verifique se está em funcionamento, verificando a respetiva 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. Reverta o Redis:

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

      Verifique se está a funcionar corretamente, verificando o respetivo estado:

      kubectl -n apigee get apigeeredis default
      

      NAME      STATE     AGE
      default   running   2d

   7. Reverta a telemetria do Apigee:

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

      Verifique se está a funcionar corretamente, verificando o respetivo estado:

      kubectl -n apigee get apigeetelemetry apigee-telemetry
      

      NAME               STATE     AGE
      apigee-telemetry   running   2d

   8. Reverta o Apigee Controller:

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

      Valide a instalação do operador do 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.4   1.12.4

      Verifique se está em funcionamento, verificando a respetiva 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. Reverta os CRDs do Apigee Hybrid:

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

4. Valide se todos os pods estão em estado de 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 devem estar na versão anterior, exceto o arquivo 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

Restaurar quando apigee-datastore não está num bom estado

Se a atualização do componente apigee-datastore não tiver sido bem-sucedida, não pode reverter apigee-datastore da versão 1.12 para a versão 1.11. Em alternativa, tem de restaurar a partir de uma cópia de segurança feita de uma instalação da versão 1.11. Use a seguinte sequência para restaurar a versão anterior.

1. Se não tiver uma instalação ativa da versão 1.11 do Apigee Hybrid (por exemplo, noutra região), crie uma nova instalação da versão 1.11 com os ficheiros de substituições e gráficos dos quais fez uma cópia de segurança. Consulte as instruções de instalação da versão 1.11 do Apigee Hybrid.
2. Restaure a região v1.11 (ou a nova instalação) a partir da cópia de segurança seguindo as instruções em:
   • Cópias de segurança da interface de armazenamento na nuvem (CSI): Cassandra Cópia de segurança e restauro da CSI.
   • Cópias de segurança não CSI: restauração numa única região.
3. Valide o tráfego para a instalação restaurada
4. Opcional: remova a instalação da versão 1.12 seguindo as instruções em Desinstale o tempo de execução híbrido.

Reversão e recuperação multirregionais

Reverter quando apigee-datastore estiver em bom estado

Nota:> use este método de reversão para reverter de uma região híbrida atualizada para a versão híbrida anterior. Este método destina-se a recuperar de uma atualização com falha quando nem todas as regiões foram atualizadas.

Este procedimento explica como reverter todos os componentes híbridos do Apigee da versão 1.12 para a versão 1.11 exceto apigee-datastore. O componente v1.12 apigee-datastore é retrocompatível com componentes híbridos v1.11.

1. Antes de iniciar a reversão, valide se todos os pods estão em estado de execução:

   kubectl get pods -n APIGEE_NAMESPACE

   kubectl get pods -n apigee-system

2. Certifique-se de que todos os nós do Cassandra em todas as regiões estão no estado UN (Up / Normal). Se algum nó do Cassandra estiver num estado diferente, resolva esse problema primeiro antes de iniciar o processo de atualização.

   Pode validar o estado dos seus nós do Cassandra com os seguintes comandos:

   1. Apresente os pods do Cassandra:

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

      Por 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

      Por 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 Remova nós INATIVOS do cluster do Cassandra.

3. Navegue para o diretório onde os gráficos Helm do Apigee Hybrid anteriores estão instalados
4. Altere o contexto para a região que foi atualizada

   kubectl config use-context UPGRADED_REGION_CONTEXT
       

5. Valide se todos os pods estão em estado de execução:

   kubectl get pods -n APIGEE_NAMESPACE

   kubectl get pods -n apigee-system

6. Use o comando helm para se certificar de 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 apigee-datastore com os seguintes comandos:
   1. Crie a seguinte variável de ambiente:
      • PREVIOUS_HELM_CHARTS_HOME: o diretório onde os gráficos Helm do Apigee Hybrid anteriores estão instalados. Esta é a versão para a qual está a reverter.
   2. Reverta os anfitriões virtuais. Repita o seguinte comando para cada grupo de ambientes mencionado no ficheiro 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 o qual instalou anteriormente o gráfico apigee-virtualhost. No híbrido v1.10, normalmente é apigee-virtualhost-ENV_GROUP_NAME. No Hybrid v1.11 e mais recente, é normalmente ENV_GROUP_NAME.

   3. Reverter ambientes Repita o seguinte comando para cada ambiente mencionado no ficheiro 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 o qual instalou anteriormente o gráfico apigee-env. No híbrido v1.10, normalmente é apigee-env-ENV_NAME. No Hybrid v1.11 e mais recente, é normalmente ENV_NAME.

      Verifique se cada ambiente está em funcionamento verificando o estado do ambiente respetivo:

      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
      

      Verifique se está em funcionamento consultando o estado da organização respetiva:

      kubectl -n apigee get apigeeorg
      

      NAME                STATE     AGE
      apigee-org1-xxxxx   running   2d

   5. Reverta o Ingress Manager:

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

      Verifique se está em funcionamento, verificando a respetiva 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. Reverta o Redis:

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

      Verifique se está a funcionar corretamente, verificando o respetivo estado:

      kubectl -n apigee get apigeeredis default
      

      NAME      STATE     AGE
      default   running   2d

   7. Reverta a telemetria do Apigee:

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

      Verifique se está a funcionar corretamente, verificando o respetivo estado:

      kubectl -n apigee get apigeetelemetry apigee-telemetry
      

      NAME               STATE     AGE
      apigee-telemetry   running   2d

   8. Reverta o Apigee Controller:

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

      Valide a instalação do operador do 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.4   1.12.4

      Verifique se está em funcionamento, verificando a respetiva 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. Reverta os CRDs do Apigee Hybrid:

      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 devem estar na versão anterior, exceto 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 momento, todas as versões, exceto a datastore, foram revertidas para a versão anterior.

Importante: atualmente, o arquivo de dados do Cassandra está parcialmente atualizado. Recomendamos que tente atualizar novamente resolvendo os problemas encontrados durante a atualização anterior e repetindo o processo. Se não for possível tentar outra atualização, recomendamos que recupere o arquivo de dados através das instruções em Recuperar uma instalação de várias regiões para uma versão anterior.

Recuperar uma instalação em várias regiões para uma versão anterior

Recupere a região onde a atualização falhou numa atualização de várias regiões removendo as referências à mesma de instalações de várias regiões. Este método só é possível quando existe, pelo menos, 1 região em direto no Hybrid 1.11. O arquivo de dados v1.12 é compatível com os componentes v1.11.

Para recuperar regiões com falhas a partir de uma região em bom estado, siga estes passos:

1. Redirecione o tráfego da API das regiões afetadas para a região com bom funcionamento. Planeie a capacidade em conformidade para suportar o tráfego desviado das regiões com falhas.
2. Desativar a região afetada. Para cada região afetada, siga os passos descritos no artigo Desative uma região híbrida. Aguarde a conclusão da desativação antes de avançar para o passo seguinte.

3. Limpe a região com falhas seguindo as instruções em Recupere uma região de uma atualização com falhas.
4. Recupere a região afetada. Para recuperar, crie uma nova região, conforme descrito no artigo Implementação multirregional no GKE, GKE On-Prem e AKS.

Restaurar uma instalação multirregional a partir de uma cópia de segurança com apigee-datastore num estado incorreto

Se a atualização do componente apigee-datastore não tiver sido bem-sucedida, não pode reverter da versão 1.12 para a versão 1.11. Em alternativa, tem de restaurar a partir de uma cópia de segurança feita de uma instalação da versão 1.11. Use a seguinte sequência para restaurar a versão anterior.

Dica: para minimizar o tempo de inatividade em instalações de várias regiões, o Apigee recomenda a reconstrução e o restauro de uma região de cada vez.

1. Se não tiver uma instalação ativa da versão 1.11 do Apigee Hybrid (por exemplo, noutra região), crie uma nova instalação da versão 1.11 com os ficheiros de substituições e gráficos dos quais fez uma cópia de segurança. Consulte as instruções de instalação da versão 1.11 do Apigee Hybrid.
2. Restaure a região v1.11 (ou a nova instalação) a partir da cópia de segurança seguindo as instruções em:
   • Cópias de segurança da interface de armazenamento na nuvem (CSI): Cassandra Cópia de segurança e restauro da CSI.
   • Cópias de segurança não CSI: Restaurar em várias regiões.
3. Valide o tráfego para a instalação restaurada
4. Para instalações multirregionais, recompile e restaure a região seguinte. Consulte as instruções em Restaurar a partir de uma cópia de segurança em Restaurar em várias regiões.
5. Remova a instalação da versão 1.12 seguindo as instruções em Desinstale o tempo de execução híbrido.

ANEXO: recupere uma região de uma atualização com falha

Remova um centro de dados se a atualização de 1.11 para 1.12 falhar.

1. Valide o estado do cluster do Cassandra a partir de uma região ativa:
   1. Mude o contexto do kubectl para a região a remover:

      kubectl config use-context CONTEXT_OF_LIVE_REGION

   2. Apresente os pods do Cassandra:

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

      Por 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 o comando em um dos pods do Cassandra:

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

   4. Verifique o estado do cluster Cassandra:

      nodetool -u JMX_USER -pw JMX_PASSWORD status

      O resultado deve ter um aspeto semelhante ao seguinte:

      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ó vê IPs de pods do Cassandra da região em direto e se todos estão na mesma versão do esquema:

      nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

      O resultado deve ter um aspeto semelhante ao seguinte:

      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 do espaço de chaves do Cassandra:
   1. Obtenha a tarefa user-setup e elimine-a. É criado imediatamente um novo trabalho do user-setup.

      kubectl get jobs -n APIGEE_NAMESPACE

      Por 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

      O resultado deve mostrar o início da nova tarefa:

      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 definições de replicação do espaço de chaves do Cassandra criando um contentor de cliente seguindo as instruções em Crie o contentor de cliente.
   3. Obtenha todos os espaços de chaves. Executar no pod cassandra-client e, em seguida, iniciar um cliente cqlsh:

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

      Estabeleça ligação ao servidor Cassandra com ddl user, uma vez que tem as autorizações necessárias para executar os seguintes comandos:

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

      Obtenha os espaços de chaves:

      select * from system_schema.keyspaces;

      O resultado deve ter o seguinte aspeto, em que dc-1 é o DC em direto:

      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, a tarefa user-setup continuar a apresentar erros e a validação falhar, use os seguintes comandos para corrigir a replicação nos espaços de chaves.
      Atenção: use os seguintes comandos com extremo cuidado.

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

      Estabeleça ligação ao servidor Cassandra com ddl user, uma vez que tem as autorizações necessárias para executar os seguintes comandos:

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

      Obtenha os espaços de chaves:

      select * from system_schema.keyspaces;

      Use os nomes do espaço de chaves do comando acima e substitua-os nos exemplos seguintes

      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. Valide se todos os espaços de chaves estão a ser replicados na região certa com o seguinte comando cqlsh:

      select * from system_schema.keyspaces;

      Por 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 fase, removeu completamente todas as referências ao DC inativo do cluster do Cassandra.

ANEXO: remova nós DOWN do cluster do Cassandra

Use este procedimento quando estiver a reverter uma instalação em várias regiões e nem todos os pods do Cassandra estiverem no estado Up / Normal (UN).

1. Execute o comando em um dos pods do Cassandra:

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

2. Verifique o estado do cluster Cassandra:

   nodetool -u JMX_USER -pw JMX_PASSWORD status

3. Valide se o nó está realmente inativo (DN). Execute o comando exec no pod do Cassandra numa região onde o pod do Cassandra não consegue ser iniciado.

   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ó de desativação (DN). No exemplo acima, vamos remover a referência ao anfitrião 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 de remover a referência, termine o pod. O novo pod do Cassandra deve ser apresentado e juntar-se ao cluster

   kubectl delete pod -n POD_NAME

6. Valide se o novo pod do Cassandra aderiu ao 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

Neste ponto, pode avançar com a atualização ou a reversão das restantes regiões do cluster.

APÊNDICE: resolução de problemas: apigee-datastore num estado bloqueado após a reversão

Use este procedimento quando tiver revertido o apigee-datastore para a versão híbrida 1.11 após a atualização e este estiver num estado bloqueado.

1. Antes de corrigir novamente o estado do controlador do arquivo de dados, valide se está no estado releasing e se os pods não estão a ser apresentados juntamente com o estado do cluster do Cassandra.
   1. Valide através do comando Helm que o arquivo de dados foi revertido:

      helm -n APIGEE_NAMESPACE list

      Por 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. Obtenha o estado dos pods do Cassandra:

      kubectl get pods -n APIGEE_NAMESPACE

      Por 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. Valide se o comando apigeeds está bloqueado no estado de libertação:

      kubectl get apigeeds -n APIGEE_NAMESPACE

      Por exemplo:

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

   4. Valide o estado dos nós do Cassandra (tenha em atenção que um nó está num estado DN, que é o nó bloqueado no estado CrashLoopBackOff):

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

      Por 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. Atualize o arquivo de dados através dos gráficos 1.12.
   Nota: o controlador vai entrar novamente no estado releasing, mas, desta vez, vai criar pods com as imagens para o Hybrid 1.12, que vão aparecer, e o Cassandra vai juntar-se ao cluster e tornar-se UN (UP/NORMAL).

   helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/   --install   --namespace APIGEE_NAMESPACE   -f overrides.yaml

3. Valide se todos os pods estão Running e se o cluster do Cassandra está novamente em bom estado.
   1. Valide novamente todos os pods:READY

      kubectl get pods -n APIGEE_NAMESPACE

      Por 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. Valide o estado do cluster do Cassandra:

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

      Por 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 estado do comando apigeeds:

      kubectl get apigeeds -n APIGEE_NAMESPACE

      Por exemplo:

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

Neste momento, corrigiu o arquivo de dados e este deve estar no estado running.