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

do tipo

Este procedimento abrange o upgrade da versão híbrida 1.8.x da Apigee para a versão híbrida 1.9.4 da Apigee e de versões anteriores da versão híbrida 1.9.x para a versão 1.9.4.

Use os mesmos procedimentos para upgrades de versão secundária (por exemplo, 1.8 para 1.9) e para upgrades de versão de patch (por exemplo, 1.9.0 para 1.9.4).

Se estiver fazendo upgrade da versão híbrida 1.7 ou posterior da Apigee, primeiro você precisará fazer upgrade para a versão híbrida 1.8 antes de fazer upgrade para a versão 1.9.4. Consulte as instruções sobre Como fazer upgrade da Apigee híbrida para a versão 1.8.

A partir da versão 1.9.0, a Apigee híbrida oferece suporte apenas ao gateway de entrada da Apigee como camada de entrada.

Como fazer upgrade para a versão 1.9.4

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

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

Pré-requisitos

  • Estas instruções de upgrade presumem que você tenha a Apigee híbrida versão 1.8.x instalada e queira fazer upgrade para a versão 1.9.4. Se você estiver atualizando de uma versão anterior, consulte as instruções sobre Como fazer upgrade da Apigee híbrida para a versão 1.8.
  • Na versão híbrida 1.8 da Apigee, introduzimos o gateway de entrada da Apigee como uma camada de entrada alternativa para o Anthos Service Mesh. A partir da versão 1.9.0, a Apigee híbrida exige o uso do gateway de entrada da Apigee e não oferece mais suporte ao uso do Anthos Service Mesh para entrada. Se a instalação de que você está fazendo upgrade usa o Anthos Service Mesh, primeiro migre para o gateway de entrada da Apigee antes de fazer upgrade para a versão 1.9.4.

    O gateway de entrada da Apigee usa um pequeno subconjunto de recursos do Anthos Service Mesh para o gateway de entrada. O gerenciamento e o upgrade desses recursos são feitos automaticamente pela Apigee híbrida. Portanto, você não precisa de experiência com o Anthos Service Mesh para instalar, fazer upgrade e gerenciar o gateway de entrada da Apigee híbrida.

    Consulte Como migrar para o gateway de entrada da Apigee na documentação versão híbrida v1.8 para conferir as instruções.

Preparar para fazer upgrade para a versão 1.9

  1. Estas instruções usam a variável de ambiente APIGEECTL_HOME para o diretório no seu sistema de arquivos em que você instalou apigeectl. Se necessário, mude o diretório para seu diretório apigeectl e defina a variável com o seguinte comando:

    Linux

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Mac OS

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Windows

    set APIGEECTL_HOME=%CD%
    echo %APIGEECTL_HOME%
  2. Faça uma cópia de backup do diretório $APIGEECTL_HOME/ da versão 1.8. Exemplo:
    tar -czvf $APIGEECTL_HOME/../apigeectl-v1.8-backup.tar.gz $APIGEECTL_HOME
  3. Faça o backup do banco de dados Cassandra seguindo as instruções em Backup e recuperação do Cassandra.

Adicione o papel Agente do Cloud Trace à conta de serviço do ambiente de execução da Apigee. (Opcional)

Opcional: se você planeja usar o Cloud Trace e ainda não adicionou o papel Cloud Trace Agent à instalação híbrida v1.8, verifique se a conta de serviço de seus serviços de ambiente de execução da Apigee têm o papel de Agente do Cloud Trace do Google Cloud IAM (roles/cloudtrace.agent).

Para ambientes de produção, a conta de serviço do ambiente de execução é apigee-runtime. Para ambientes de não produção, a conta de serviço do ambiente de execução é apigee-non-prod.

Você pode adicionar o papel na IU do Console do Cloud > IAM e Administrador > Contas de serviço ou com os seguintes comandos:

  1. Encontre o endereço de e-mail da conta de serviço com o seguinte comando:

    Produção

    gcloud iam service-accounts list --filter "apigee-runtime"

    Se o endereço de e-mail corresponder ao padrão apigee-runtime@$ORG_NAME.iam.gserviceaccount.com, será possível usar esse padrão na próxima etapa.

    Sem produção

    gcloud iam service-accounts list --filter "apigee-non-prod"

    Se ele corresponder ao padrão apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com, use esse padrão na próxima etapa

  2. Atribua o papel Agente do Cloud Trace à conta de serviço:

    Produção

    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member="serviceAccount:apigee-runtime@$PROJECT_ID.iam.gserviceaccount.com" \
        --role="roles/cloudtrace.agent"

    Sem produção

    gcloud projects add-iam-policy-binding $PROJECT_ID \
        --member="serviceAccount:apigee-non-prod@$PROJECT_ID.iam.gserviceaccount.com" \
        --role="roles/cloudtrace.agent"

    Exemplo

    gcloud projects add-iam-policy-binding hybrid-example-project \
        --member="serviceAccount:apigee-runtime@hybrid-example-project.iam.gserviceaccount.com" \
        --role="roles/cloudtrace.agent"

    Em que: $PROJECT_ID é o nome do projeto do Google Cloud em que a Apigee híbrida está instalada.

Instale o gateway de entrada da Apigee se a instalação usar o Anthos Service Mesh

A partir da versão 1.9, a Apigee híbrida não oferece mais suporte ao uso do Anthos Service Mesh para entrada. Se a instalação híbrida estiver usando o Anthos Service Mesh, será preciso migrar a instalação atual para o gateway de entrada da Apigee antes de instalar a versão híbrida 1.9.

  1. Adicione a propriedade ingressGateways ao arquivo de substituições.

    Sintaxe

      ingressGateways:
      - name: INGRESS_NAME
        replicaCountMin: REPLICAS_MIN
        replicaCountMax: REPLICAS_MAX
        resources:
          requests:
            cpu: CPU_COUNT_REQ
            memory: MEMORY_REQ
          limits:
            cpu: CPU_COUNT_LIMIT
            memory: MEMORY_LIMIT
        svcAnnotations:  # optional. See Known issue 243599452.
          SVC_ANNOTATIONS_KEY: SVC_ANNOTATIONS_VALUE
        svcLoadBalancerIP: SVC_LOAD_BALANCER_IP # optional

    Exemplo

      ingressGateways:
      - name: prod1
        replicaCountMin: 2
        replicaCountMax: 100
        resources:
          requests:
            cpu: 1
            memory: 1Gi
          limits:
            cpu: 2
            memory: 2Gi
        svcAnnotations:  # optional. See Known issue 243599452.
          networking.gke.io/load-balancer-type: "Internal"
        svcLoadBalancerIP: 198.252.0.123 
    • INGRESS_NAME é o nome da implantação de entrada. Pode ser qualquer nome que atenda aos seguintes requisitos:
      • ter um comprimento máximo de 17 caracteres
      • conter apenas caracteres alfanuméricos minúsculos, "-" ou ".";
      • começar com um caractere alfanumérico;
      • terminar com um caractere alfanumérico.
      Consulte ingressGateways[].name na referência da propriedade de configuração.
    • REPLICAS_MIN e REPLICAS_MAX são as contagens mínima e máxima de réplicas para o gateway de entrada da Apigee na sua instalação. Para mais informações e definições padrão, consulte ingressGateways[].replicaCountMin e ingressGateways[].replicaCountMax na referência da propriedade de configuração.
    • CPU_COUNT_REQ e MEMORY_REQ são a solicitação de CPU e memória de cada réplica do gateway de entrada da Apigee na sua instalação.

      Para mais informações e definições padrão, consulte ingressGateways[].resources.requests.cpu e ingressGateways[].resources.requests.memory na referência da propriedade de configuração.

    • CPU_COUNT_LIMIT e MEMORY_LIMIT são os limites máximos de CPU e memória para cada réplica do gateway de entrada da Apigee na sua instalação.

      Para mais informações e definições padrão, consulte ingressGateways[].resources.limits.cpu e ingressGateways[].resources.limits.memory na referência da propriedade de configuração.

    • SVC_ANNOTATIONS_KEY SVC_ANNOTATIONS_VALUE (opcional):

      Esse é um par de chave-valor que fornece anotações para o serviço de entrada padrão. As anotações são usadas pela sua plataforma de nuvem para ajudar a configurar sua instalação híbrida, por exemplo, definindo o tipo de balanceador de carga como interno ou externo. Exemplo:

      ingressGateways:
          svcAnnotations:
            networking.gke.io/load-balancer-type: "Internal"

      As anotações variam de acordo com a plataforma. Consulte a documentação da sua plataforma para conferir anotações obrigatórias e sugeridas.

      Consulte ingressGateways[].svcAnnotations na referência da propriedade de configuração.
    • SVC_LOAD_BALANCER_IP (opcional) permite atribuir um endereço IP estático ao seu balanceador de carga. Nas plataformas compatíveis com a especificação do endereço IP do balanceador de carga, o balanceador de carga será criado com esse endereço IP. Nas plataformas que não permitem especificar o endereço de IP do balanceador de carga, essa propriedade é ignorada.

      Se você não tiver um endereço IP estático alocado para o balanceador de carga, deixe essa propriedade fora do arquivo de substituições.

      Consulte ingressGateways[].svcLoadBalancerIP na referência da propriedade de configuração.
  2. Aplique as alterações para instalar o gateway de entrada da Apigee com os seguintes comandos:
    $APIGEECTL_HOME/apigeectl apply -f overrides/overrides.yaml
  3. Exponha o gateway de entrada da Apigee. Siga os procedimentos em Expor o gateway de entrada da Apigee.
  4. Teste seu gateway de entrada chamando um proxy. O ideal é testar todos os proxies importantes que você implantou no momento.
  5. Para alternar o tráfego, atualize seus registros DNS de modo que eles apontem para o endereço IP do novo gateway de entrada da Apigee. Dependendo do seu provedor de DNS, talvez seja possível transferir gradualmente o tráfego para o novo endpoint. Dica: encontre o IP externo do gateway de entrada da Apigee com o seguinte comando:
    kubectl get svc -n apigee -l app=apigee-ingressgateway

    A saída será semelhante a esta:

    NAME                                        TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                                      AGE
    apigee-ingressgateway-prod-hybrid-37a39bd   LoadBalancer   192.0.2.123   233.252.0.123   15021:32049/TCP,80:31624/TCP,443:30723/TCP   16h
  6. Monitore seus painéis para garantir que todo o tráfego de ambiente de execução esteja funcionando. Só prossiga para a próxima etapa se tudo estiver funcionando como esperado. Verifique se nenhum tráfego está passando pelo antigo gateway de entrada (Anthos Service Mesh), já que a atualização de DNS pode demorar para ser propagada por causa do armazenamento em cache de DNS.
  7. Para impedir que a Apigee forneça a configuração ao Anthos Service Mesh, siga as etapas em Parar de fornecer configuração ao ASM no guia "Como gerenciar o gateway de entrada da Apigee".
  8. Teste novamente e monitore o tráfego de proxy da API.
  9. Siga as instruções na documentação do Anthos Service Mesh para desinstalar o Anthos Service Mesh do cluster.

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

  1. Verifique se você está no diretório base híbrido (o pai do diretório em que o arquivo executável apigeectl está localizado):
    cd $APIGEECTL_HOME/..
  2. Faça o download do pacote de lançamento do seu sistema operacional usando o seguinte comando. Selecione sua plataforma na tabela a seguir:

    Linux

    Linux de 64 bits:

    curl -LO \
      https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.9.4/apigeectl_linux_64.tar.gz

    Mac OS

    Mac 64 bits:

    curl -LO \
      https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.9.4/apigeectl_mac_64.tar.gz

    Windows

    Windows 64 bit:

    curl -LO ^
      https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.9.4/apigeectl_windows_64.zip
  3. Renomeie o diretório apigeectl/ atual para um nome de diretório de backup. Exemplo:

    Linux

    mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.8/

    Mac OS

    mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.8/ 

    Windows

    rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.8 
  4. Extraia o conteúdo do arquivo gzip baixado para seu diretório base híbrido. O diretório base híbrido é aquele em que o diretório renomeado apigeectl-v1.8 está localizado:

    Linux

    tar xvzf filename.tar.gz -C ./

    Mac OS

    tar xvzf filename.tar.gz -C ./

    Windows

    tar xvzf filename.zip -C ./
  5. O conteúdo de tar é, por padrão, expandido em um diretório com a versão e a plataforma no nome. Por exemplo, ./apigeectl_1.9.4-xxxxxxx_linux_64. Renomeie esse diretório para apigeectl usando o seguinte comando:

    Linux

    mv apigeectl_1.9.4-xxxxxxx_linux_64 apigeectl

    Mac OS

    mv apigeectl_1.9.4-xxxxxxx_mac_64 apigeectl

    Windows

    rename apigeectl_1.9.4-xxxxxxx_windows_64 apigeectl
  6. Altere para o diretório apigeectl:
    cd ./apigeectl

    Esse diretório é o diretório inicial apigeectl. É lá que o comando executável apigeectl está localizado.

  7. Estas instruções usam a variável de ambiente $APIGEECTL_HOME para o diretório no seu sistema de arquivos em que o utilitário apigeectl está instalado. Se necessário, mude o diretório para seu diretório apigeectl e defina a variável com o seguinte comando:

    Linux

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Mac OS

    export APIGEECTL_HOME=$PWD
    echo $APIGEECTL_HOME

    Windows

    set APIGEECTL_HOME=%CD%
    echo %APIGEECTL_HOME%
  8. Verifique a versão de apigeectl com o comando version:
    ./apigeectl version
    Version: 1.9.4
  9. Mova para o diretório hybrid-base-directory/hybrid-files. O diretório hybrid-files é onde estão localizados os arquivos de configuração, como os arquivos de substituição, certificados e contas de serviço. Exemplo:
    cd $APIGEECTL_HOME/../hybrid-files
  10. Verifique se kubectl está definido para o contexto correto usando o seguinte comando. O contexto atual precisa ser definido como o cluster em que você está fazendo upgrade da Apigee híbrida.
    kubectl config get-contexts | grep \*
  11. No diretório hybrid-files:
    1. Atualize os seguintes links simbólicos para $APIGEECTL_HOME. Com esses links, você pode executar o comando apigeectl recém-instalado no diretório hybrid-files:
      ln -nfs $APIGEECTL_HOME/tools tools
      ln -nfs $APIGEECTL_HOME/config config
      ln -nfs $APIGEECTL_HOME/templates templates
      ln -nfs $APIGEECTL_HOME/plugins plugins
    2. Para verificar se os links simbólicos foram criados corretamente, execute este comando e certifique-se de que os caminhos do link apontam para os locais corretos:
      ls -l | grep ^l
  12. Faça uma inicialização a seco para verificar se há erros:
    ${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client

    Em que OVERRIDES_FILE é o nome do arquivo de substituições, por exemplo, ./overrides/overrides.yaml.

  13. Se não houver erros, inicialize o híbrido 1.9.4:
    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
  14. Verifique o status da inicialização:
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    Em caso de sucesso, a saída vai ser: All containers ready.

    kubectl describe apigeeds -n apigee

    Na saída, procure State: running.

  15. Verifique se há erros com uma simulação do comando apply usando a sinalização --dry-run:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
  16. Se não houver erros, aplique as substituições. Selecione e siga as instruções para ambientes de produção ou ambientes sem produção, dependendo da sua instalação.

    Produção

    Para ambientes de produção, você precisa fazer upgrade de cada componente híbrido individualmente e verificar o status do componente atualizado antes de seguir para o próximo componente.

    1. Verifique se você está no diretório hybrid-files.
    2. Aplique as modificações para fazer upgrade do Cassandra:
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
    3. Verifique a conclusão:
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

      Passe para a próxima etapa somente quando os pods estiverem prontos.

    4. Aplique as modificações para fazer upgrade dos componentes de telemetria e verificar a conclusão:
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    5. Acesse os componentes do Redis:
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
    6. Aplique as modificações para fazer upgrade dos componentes no nível da organização (MART, Watcher e Apigee Connect) e verifique a conclusão:
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    7. Aplique as modificações para fazer upgrade dos seus ambientes. Você tem duas opções:
      • Ambiente por ambiente: aplique suas modificações em um ambiente por vez e verifique a conclusão. Repita esta etapa para cada ambiente:
        $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
        $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

        Em que ENV_NAME é o nome do ambiente que você está atualizando.

      • Todos os ambientes de uma só vez: aplique suas modificações a todos os ambientes de uma só vez e verifique a conclusão:
        $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
        $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    8. Aplique as modificações para fazer upgrade dos componentes virtualhosts de telemetria e verificar a conclusão:
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    Sem produção

    Na maioria dos ambientes de produção, de demonstração ou experimental, é possível aplicar as substituições a todos os componentes de uma só vez. Se o ambiente de não produção for grande e complexo, ou imita frequentemente um ambiente de produção, use as instruções para fazer upgrade dos ambientes de produção.

    1. Verifique se você está no diretório hybrid-files.
    2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
    3. Verifique o status:
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Instale o 1.9.4-hotfix.1 (em inglês)

Siga estas etapas para instalar a versão hotfix, 1.9.4-hotfix.1:

  1. Antes de realizar estas etapas, você precisa usar a Apigee híbrida versão 1.9.4 ou mais recente. Se você não estiver usando a versão 1.9.4 ou posterior, faça um upgrade para a versão 1.9.4 antes de continuar.
  2. Abra seu arquivo overrides.yaml.
  3. Na estrofe istiod, mude a versão da tag de imagem (se presente) para a versão 1.17.7. Exemplo:
    istiod:
      image:
        url: "gcr.io/apigee-release/hybrid/apigee-asm-istiod"
        tag: "1.17.7-asm.0-distroless"
  4. Dependendo de como você escolheu instalar a Apigee híbrida, talvez apareça uma estrofe ingressGateway ou ingressGateways. Localize a estrofe no arquivo de substituição e mude a versão da tag de imagem (se presente) para a versão 1.17.7. Por exemplo, se você tiver uma estrofe ingressGateway:
    ingressGateway:
      image:
        url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
        tag: "1.17.7-asm.0-distroless"

    ou, se tiver uma estrofe ingressGateways:

    ingressGateways:
      - name: gateway1
        image:
          url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
          tag: "1.17.7-asm.0-distroless"
        ...
      - name: gateway2
        image:
          url: "gcr.io/apigee-release/hybrid/apigee-asm-ingress"
          tag: "1.17.7-asm.0-distroless"
        ...
      
  5. Salve o arquivo.
  6. Execute o seguinte comando para inicializar o componente istiod:
    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  7. Execute o comando a seguir para aplicar alterações aos componentes de entrada da Apigee. Se você tiver mais de uma organização, repita este comando para cada uma delas:
    $APIGEECTL_HOME/apigeectl apply --org -f OVERRIDES_FILE
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  8. Verifique o status dos pods:
    kubectl get pods -n YOUR_APIGEE_NAMESPACE

Fazer upgrade da versão do Kubernetes

Faça upgrade da plataforma do Kubernetes para as versões compatíveis com a versão híbrida 1.9. Siga a documentação da plataforma se precisar de ajuda.

Como reverter um upgrade

Siga estas etapas para reverter um upgrade anterior:

  1. Limpe os jobs concluídos do namespace do ambiente de execução híbrido, em que NAMESPACE é o namespace especificado no arquivo de modificações, se você especificou um namespace. Caso contrário, o namespace padrão é apigee:
    kubectl delete job -n NAMESPACE \
      $(kubectl get job -n NAMESPACE \
      -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  2. Limpe jobs concluídos do namespace apigee-system:
    kubectl delete job -n apigee-system \
      $(kubectl get job -n apigee-system \
      -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  3. Altere a variável APIGEECTL_HOME para apontar para o diretório que contém a versão original de apigeectl. Exemplo:
    export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
  4. No diretório raiz da instalação para a qual você quer reverter, execute apigeectl apply, verifique o status dos pods e execute apigeectl init. Use o arquivo de modificações original da versão para a qual você quer reverter:
    1. No diretório de arquivos híbridos, execute apigeectl apply:
      $APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE

      Em que ORIGINAL_OVERRIDES_FILE é o caminho relativo e o nome do arquivo de substituições para a instalação híbrida da versão anterior, por exemplo, ./overrides/overrides1.8.yaml.

    2. Verifique o status dos seus pods.
      kubectl -n NAMESPACE get pods

      Em que NAMESPACE é seu namespace da Apigee híbrida.

    3. Verifique o status de apigeeds:
      kubectl describe apigeeds -n apigee

      A saída será semelhante a esta:

      Status:
        Cassandra Data Replication:
        Cassandra Pod Ips:
          10.8.2.204
        Cassandra Ready Replicas:  1
        Components:
          Cassandra:
            Last Successfully Released Version:
              Revision:  v1-f8aa9a82b9f69613
              Version:   v1
            Replicas:
              Available:  1
              Ready:      1
              Total:      1
              Updated:    1
            State:        running
        Scaling:
          In Progress:         false
          Operation:
          Requested Replicas:  0
        State:                 running
      

      Siga para a próxima etapa somente quando o pod apigeeds estiver em execução.

    4. Execute o comando a seguir para anotar quais serão os novos valores de contagem da réplica para o processador de mensagens após o upgrade. Se esses valores não corresponderem ao que você definiu anteriormente, altere os valores no arquivo de substituições para corresponder à configuração anterior.
      apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2

      A saída será semelhante a esta:

            autoScaler:
              minReplicas: 2
              maxReplicas: 10
    5. Execute apigeectl init:
      $APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE