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

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

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

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:

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

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.

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

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

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

  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:

    Simulação:

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

    Faça upgrade do gráfico:

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

    Verifique a instalação do operador da Apigee:

    helm ls -n apigee-system
    
    NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
    operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.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
    

    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
    

    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
    

    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
    

    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
    

    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
    

    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
      
    2. Verifique o estado da ApigeeRoute (AR).

      A instalação de virtualhosts cria a ApigeeRouteConfig (ARC), que gera internamente a ApigeeRoute (AR) depois que o inspetor da Apigee extrai detalhes relacionados ao grupo de ambientes do plano de controle. Portanto, verifique se o estado de RA correspondente está em execução:

      kubectl -n apigee get arc
      
      NAME                                STATE   AGE
      apigee-org1-dev-egroup                       2d
      kubectl -n apigee get ar
      
      NAME                                        STATE     AGE
      apigee-org1-dev-egroup-xxxxxx                running   2d

Como reverter para uma versão anterior

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

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

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

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

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

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.

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.

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