Atualizar o Apigee Hybrid para a versão 1.8

<0x

Use os mesmos procedimentos para atualizações de versões secundárias (por exemplo, da versão 1.7 para a 1.8) e para atualizações de lançamentos de patches (por exemplo, da versão 1.8.0 para a 1.8.8).

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

Se já estiver a usar o híbrido v1.8.0 e quiser migrar para o gateway de entrada do Apigee a partir do Anthos Service Mesh, consulte o artigo Migrar para o gateway de entrada do Apigee.

Apresentamos o gateway de entrada do Apigee

A partir da versão 1.8, o Apigee hybrid oferece uma nova funcionalidade para gerir o gateway de entrada para a sua instalação híbrida, o gateway de entrada do Apigee. O Anthos Service Mesh já não é um pré-requisito para a instalação híbrida. Com o gateway de entrada do Apigee, o Apigee deixa de fornecer a configuração de encaminhamento ao Anthos Service Mesh. Após a atualização, tem de migrar o tráfego para o novo gateway de entrada do Apigee antes de poder começar a usar a funcionalidade.

O Apigee usa um pequeno subconjunto de funcionalidades do Anthos Service Mesh para o gateway de entrada. A partir da versão híbrida 1.8, o Apigee Hybrid inclui um gateway de entrada que é instalado e atualizado como parte das atualizações do Apigee Hybrid. Por conseguinte, não precisa de desenvolver conhecimentos sobre o Anthos Service Mesh para instalar, atualizar e gerir o Apigee hybrid. Os problemas relacionados com as versões do gateway de entrada e a compatibilidade com as versões do Apigee hybrid são processados automaticamente.

Seguem-se dois cenários de migração:

  • Migração multicluster ou multirregião (recomendada):

    Antes de mudar para um novo Ingress para o Apigee, desvie todo o tráfego para outro cluster ou região do cluster que está a migrar. Isto dá-lhe tempo para testar se o novo gateway de entrada do Apigee está a funcionar como esperado. Em seguida, transfira o tráfego novamente para o cluster atualizado.

  • Atualização no local (não recomendado em ambientes de produção):

    Durante a atualização, o Apigee apresenta o novo gateway de entrada com um endereço IP especificado por si. Em seguida, pode testar se o novo gateway de entrada do Apigee está a funcionar como esperado e, depois, transferir o tráfego para a nova entrada. Pode haver indisponibilidade durante esta atualização.

Quando atualizar o Apigee hybrid para a versão 1.8, tem de configurar o gateway de entrada do Apigee no ficheiro de substituições. Após a atualização, controla o tipo de gateway de entrada que os seus clusters vão usar direcionando os registos A ou CNAME no seu registador para o endereço IP do gateway de entrada do Apigee ou do Anthos Service Mesh.

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

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

  1. Prepare-se para a atualização.
  2. Instale a versão 1.8.8 do tempo de execução híbrido.
  3. Para o gateway de entrada, escolha uma das seguintes opções:

Pré-requisito

Estas instruções de atualização pressupõem que tem a versão 1.7.x do Apigee hybrid ou uma versão de patch anterior da versão 1.8.x instalada e quer atualizá-la para a versão 1.8.8. Se estiver a fazer a atualização a partir de uma versão anterior, consulte as instruções para atualizar o Apigee hybrid para a versão 1.7.

Se preferir continuar a usar o Anthos Service Mesh, tem de garantir que o Anthos Service Mesh é atualizado para uma versão suportada. Consulte a tabela Plataformas suportadas para ver as versões suportadas do Anthos Service Mesh.

Prepare-se para atualizar para a versão 1.8

  1. Estas instruções usam a variável de ambiente APIGEECTL_HOME para o diretório no seu sistema de ficheiros onde instalou o apigeectl. Se necessário, altere o diretório para o 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 segurança do diretório $APIGEECTL_HOME/ da versão 1.7. Por exemplo: 
    tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
  3. Faça uma cópia de segurança da sua base de dados Cassandra seguindo as instruções em Cópia de segurança e recuperação do Cassandra

Adicione a função Agente do Cloud Trace à conta de serviço do tempo de execução do Apigee. (Opcional)

Opcional: se planeia usar o Cloud Trace e ainda não tiver executado este passo na sua instalação híbrida v1.7, certifique-se de que a sua conta de serviço para os serviços de tempo de execução do Apigee tem a função Google Agente do Cloud Trace. (roles/cloudtrace.agent).

Para ambientes de produção, trata-se normalmente da apigee-runtimeconta de serviço. Para ambientes que não sejam de produção, trata-se normalmente da apigee-non-prod conta de serviço.

Pode adicionar a função na IU Cloud Console > IAM & Admin > Contas de serviço ou com os seguintes comandos:

  1. Obtenha o endereço de email da sua conta de serviço com o seguinte comando:

    Produção 

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

    Se corresponder ao padrão apigee-runtime@$ORG_NAME.iam.gserviceaccount.com, pode usar esse padrão no passo seguinte.

    Não produção 

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

    Se corresponder ao padrão apigee-non-prod@$ORG_NAME.iam.gserviceaccount.com, pode usar esse padrão no passo seguinte.

  2. Atribua a função 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"

    Não 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"

    Onde: $PROJECT_ID é o nome do projeto do Google Cloud onde o Apigee Hybrid está instalado.

Prepare-se para instalar o gateway de entrada do Apigee

Para instalar o gateway de entrada do Apigee como parte da atualização. Tem de adicionar a propriedade ingressGateways seguinte ao ficheiro 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
  • INGRESS_NAME é o nome da implementação de entrada. Pode ser qualquer nome que cumpra os seguintes requisitos:
    • Ter um comprimento máximo de 17 carateres
    • Contêm apenas carateres alfanuméricos minúsculos, "-" ou "."
    • Começar com um caráter alfanumérico
    • Terminar com um caráter alfanumérico

    Consulte ingressGateways[].name na referência da propriedade de configuração

  • REPLICAS_MIN e REPLICAS_MAX são as quantidades mínimas e máximas de réplicas para o gateway de entrada do Apigee na sua instalação. Para mais informações e definições predefinidas, consulte ingressGateways[].replicaCountMin e ingressGateways[].replicaCountMax na referência da propriedade de configuração.
  • CPU_COUNT_REQ e MEMORY_REQ são o pedido de CPU e memória para cada réplica do gateway de entrada do Apigee na sua instalação.

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

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

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

  • SVC_ANNOTATIONS_KEY e SVC_ANNOTATIONS_VALUE (opcional):

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

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

    As anotações variam de plataforma para plataforma. Consulte a documentação da plataforma para ver as anotações obrigatórias e sugeridas.

    Consulte ingressGateways[].svcAnnotations na referência da propriedade de configuração.
  • SVC_LOAD_BALANCER_IP (opcional) Permite-lhe atribuir um endereço IP estático ao seu equilibrador de carga. Em plataformas que suportam a especificação do endereço IP do balanceador de carga, o balanceador de carga é criado com este endereço IP. Nas plataformas que não permitem especificar o endereço IP do balanceador de carga, esta propriedade é ignorada.

    Se não tiver um endereço IP estático atribuído ao seu equilibrador de carga, exclua esta propriedade do ficheiro de substituições.

    Consulte ingressGateways[].svcLoadBalancerIP na referência da propriedade de configuração.

Faça alterações adicionais ao ficheiro de substituições para ativar ou desativar funcionalidades opcionais da versão 1.8

Adicione as seguintes propriedades ao seu ficheiro overrides.yaml para ativar novas funcionalidades no formato híbrido v1.8. Estas funcionalidades são opcionais.

  • A UDCA ao nível da organização está agora ativada por predefinição. A utilização de uma única implementação de UDCA para processar o tráfego de todos os ambientes evita a subutilização de pods de UDCA e aumenta a disponibilidade de recursos de nós para outros componentes do Apigee. A UDCA ao nível da organização usa uma única conta de serviço para todos os ambientes, apigee-udca.

    Se estiver a usar contas de serviço diferentes para a UDCA em ambientes diferentes, tenha em atenção que vai usar a conta de serviço especificada ao nível da organização no seu ficheiro de substituições com udca:serviceAccountPath, em vez das especificadas ao nível do ambiente com envs:udca:serviceAccountPath.

    O Apigee Hybrid v 1.8 suporta UDCA ao nível do ambiente. Para manter o UDCA por ambiente, defina orgScopedUDCA: false.

    Consulte orgScopedUDCA na referência de propriedades de configuração.

  • Ative validateOrg para exigir uma validação rigorosa de que a organização e o ambiente do Apigee estão ativos e funcionam com o projeto da Google Cloud Platform especificado no seu ficheiro overrides. 
    validateOrg: true

    Consulte validateOrg na referência de propriedades de configuração.

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

  1. Certifique-se de que está no diretório base híbrido (o diretório principal do diretório onde se encontra o ficheiro executável apigeectl): 
    cd $APIGEECTL_HOME/..

  2. Transfira o pacote de lançamento para o seu sistema operativo através do seguinte comando. Certifique-se de que seleciona a sua plataforma na tabela seguinte:

    Linux

    Linux de 64 bits:

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

    Mac OS

    Mac 64 bits:

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

    Windows

    Windows de 64 bits:

    curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip
  3. Mude o nome do diretório apigeectl/ atual para um nome de diretório de cópia de segurança. Por exemplo:

    Linux 

    mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

    Mac OS 

    mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.7/

    Windows 

    rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.7

  4. Extraia o conteúdo do ficheiro gzip transferido para o diretório de base híbrido. O diretório base híbrido é o diretório onde se encontra o diretório apigeectl-v1.7 com o nome alterado:

    Linux 

    tar xvzf filename.tar.gz -C ./

    Mac OS 

    tar xvzf filename.tar.gz -C ./

    Windows 

    tar xvzf filename.zip -C ./

  5. Por predefinição, o conteúdo do TAR é expandido para um diretório com a versão e a plataforma no respetivo nome. Por exemplo: ./apigeectl_1.8.8-xxxxxxx_linux_64. Mude o nome desse diretório para apigeectl através do seguinte comando:

    Linux 

    mv apigeectl_1.8.8-xxxxxxx_linux_64 apigeectl

    Mac OS 

    mv apigeectl_1.8.8-xxxxxxx_mac_64 apigeectl

    Windows 

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

    Este diretório é o apigeectldiretório inicial. É onde se encontra o comando executável apigeectl.

  7. Estas instruções usam a variável de ambiente $APIGEECTL_HOME para o diretório no seu sistema de ficheiros onde o utilitário apigeectl está instalado. Se necessário, altere o diretório para o 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. Valide a versão do apigeectl com o comando version: 
    ./apigeectl version
     
    Version: 1.8.8
  9. Mova-se para o diretório hybrid-base-directory/hybrid-files. O diretório hybrid-files é onde se encontram os ficheiros de configuração, como o ficheiro de substituições, os certificados e as contas de serviço. Por exemplo: 
    cd $APIGEECTL_HOME/../hybrid-files
  10. Verifique se kubectl está definido para o contexto correto através do seguinte comando. O contexto atual deve ser definido para o cluster no qual está a atualizar o Apigee Hybrid. 
    kubectl config get-contexts | grep \*
  11. No diretório hybrid-files:
    1. Atualize os seguintes links simbólicos para $APIGEECTL_HOME. Estes links permitem-lhe executar o comando apigeectl recém-instalado a partir do 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 o seguinte comando e certifique-se de que os caminhos dos links apontam para as localizações corretas: 
      ls -l | grep ^l
  12. Faça uma inicialização de teste para verificar se existem erros: 
    ${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client

    Onde OVERRIDES_FILE é o nome do ficheiro de substituições, por exemplo, ./overrides/overrides.yaml.

  13. Se não houver erros, inicialize a versão híbrida 1.8.8. Este comando também instala e configura o gateway de entrada do Apigee: 
    $APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
  14. Verifique o estado de inicialização: 
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    Se for bem-sucedido, o resultado indica: All containers ready.

    Como verificação adicional, também pode executar este comando para verificar o estado do ApigeeDataStore:

    kubectl describe apigeeds -n apigee

    No resultado, procure State: running.

  15. Verifique se existem erros com uma execução de teste do comando apply através do sinalizador --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 de não produção, consoante a sua instalação.

    Produção

    Para ambientes de produção, deve atualizar cada componente híbrido individualmente e verificar o estado do componente atualizado antes de avançar para o componente seguinte.

    1. Certifique-se de que está no diretório hybrid-files.
    2. Aplique as substituições para atualizar o Cassandra: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
    3. Conclusão da verificação: 
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

      Avance para o passo seguinte apenas quando os pods estiverem prontos.

    4. Aplique as substituições para atualizar os componentes de telemetria e verifique a conclusão: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
       
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    5. Apresente os componentes do Redis: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
    6. Aplique as substituições para atualizar os componentes ao 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 substituições para atualizar os seus ambientes. Tem 2 opções:
      • Ambiente por ambiente: aplique as substituições a um ambiente de cada vez e verifique a conclusão. Repita este passo 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 está a atualizar.

      • Todos os ambientes ao mesmo tempo: aplique as substituiçõ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 substituições para atualizar os componentes virtualhosts e verifique a conclusão: 
      $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
       
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

    Não prod

    Na maioria dos ambientes de não produção, demonstração ou experimentais, pode aplicar as substituições a todos os componentes de uma só vez. Se o seu ambiente de não produção for grande e complexo ou imitar de perto um ambiente de produção, é recomendável usar as instruções para atualizar ambientes de produção.

    1. Certifique-se de que está no diretório hybrid-files.
    2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
    3. Verifique o estado: 
      $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Atualize a versão do Kubernetes

Atualize a sua plataforma Kubernetes para as versões suportadas pelo Hybrid 1.8. Siga a documentação da sua plataforma se precisar de ajuda.

Mude o tráfego do Anthos Service Mesh para o gateway de entrada do Apigee

Para mudar o tráfego para o gateway de entrada do Apigee:

  1. Exponha a gateway de entrada do Apigee. Siga os procedimentos em Exponha o gateway de entrada do Apigee.
  2. Teste o novo gateway de entrada chamando um proxy. Idealmente, teste todos os proxies cruciais que tem atualmente implementados.
  3. Para mudar o tráfego, atualize os seus registos de DNS para direcionarem para o endereço IP do novo gateway de entrada do Apigee. Consoante o seu fornecedor de DNS, pode conseguir mudar gradualmente o tráfego para o novo ponto final. Dica: pode encontrar o endereço IP externo do gateway de entrada do Apigee com o seguinte comando: 
    kubectl get svc -n apigee -l app=apigee-ingressgateway

    O resultado deve ter um aspeto semelhante ao seguinte: 

    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
  4. Certifique-se de que todo o tráfego de tempo de execução está a funcionar monitorizando os painéis de controlo. Só avance para o passo seguinte se tudo estiver a funcionar conforme esperado. Certifique-se de que não passa tráfego pelo gateway de entrada antigo (Anthos Service Mesh), uma vez que a atualização de DNS pode demorar a propagar-se devido ao armazenamento em cache de DNS.
  5. Para impedir que o Apigee forneça configuração ao Anthos Service Mesh, siga os passos em Pare de fornecer configuração ao ASM no guia de gestão do gateway de entrada do Apigee.
  6. Teste novamente e monitorize o tráfego de proxy da API.
  7. Siga as instruções na documentação do Anthos Service Mesh para desinstalar o Anthos Service Mesh do cluster.

Atualize o Anthos Service Mesh para a versão 1.15

Execute os procedimentos através da documentação do Anthos Service Mesh adequada à sua plataforma:

As instruções para instalar e configurar o Anthos Service Mesh são diferentes consoante a sua plataforma. As plataformas estão divididas nas seguintes categorias:

  • GKE: clusters do Google Kubernetes Engine em execução no Google Cloud.
  • Fora do Google Cloud: clusters do Anthos em execução em:
    • Clusters do Anthos no VMware (GKE On-Prem)
    • Anthos em bare metal
    • Clusters do Anthos no AWS
    • Amazon EKS
  • Outras plataformas Kubernetes: clusters em conformidade criados e executados em:
    • AKS
    • EKS
    • OpenShift

GKE

A sequência para atualizar para a versão 1.17.8 do Anthos Service Mesh para a sua instalação híbrida é a seguinte:

  1. Prepare-se para a atualização.
  2. Instale a nova versão do Anthos Service Mesh.
  3. Elimine as implementações, os serviços e os webhooks da versão anterior do Anthos Service Mesh da sua instalação atual.
  4. Atualize as suas gateways e configure os novos webhooks.

Prepare-se para atualizar o Anthos Service Mesh para a versão 1.17.8

  1. Reveja os requisitos em Atualize o Anthos Service Mesh, mas não faça a atualização ainda.
  2. Antes de instalar a nova versão, determine a revisão atual. Precisa destas informações para eliminar as implementações, os serviços e os webhooks da versão anterior do Anthos Service Mesh da sua instalação atual. Use o seguinte comando para armazenar a revisão istiod atual numa variável de ambiente: 
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV

    O resultado deve ter um aspeto semelhante a 1.16

  3. Crie um novo ficheiro overlay.yaml ou verifique se o ficheiro overlay.yaml existente contém o seguinte conteúdo: 
    apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  4. Siga as instruções nas secções seguintes da documentação do Anthos Service Mesh:
    1. Transferir asmcli
    2. Conceda autorizações de administrador do cluster
    3. Valide o projeto e o cluster
    4. Atualize com funcionalidades opcionais. Pare antes de iniciar a "Secção de atualização de gateways".
  5. Mude para o novo plano de controlo:
    1. Obtenha a etiqueta de revisão que está em istiod: 
      kubectl get pod -n istio-system -L istio.io/rev

      O resultado do comando é semelhante ao seguinte. 

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
    2. Atribua a etiqueta de revisão mais recente a uma variável de ambiente.

      Na saída, na coluna REV, tome nota do valor da etiqueta de revisão para a nova versão. Neste exemplo, o valor é asm-1178-1 

      export UPGRADE_REV="REVISION_LABEL"
    3. Adicione a etiqueta de revisão ao espaço de nomes istio-system e remova a etiqueta istio-injection (se existir) com o seguinte comando. 
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      Se vir "istio-injection not found" no resultado, pode ignorá-lo. Isto significa que o espaço de nomes não tinha anteriormente a etiqueta istio-injection. Uma vez que a injeção automática falha se um espaço de nomes tiver a etiqueta istio-injection e a etiqueta de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção da etiqueta istio-injection.

    4. Reinicie os pods para acionar a reinjeção. 
      kubectl rollout restart deployment -n istio-system
    5. Teste a sua aplicação para verificar se as cargas de trabalho estão a funcionar corretamente.
    6. Se tiver cargas de trabalho noutros espaços de nomes, repita os passos para etiquetar o espaço de nomes e reiniciar os pods.
  6. Elimine as versões anteriores:
    1. Navegue para o diretório onde instalou o asmcli.
    2. Armazene o diretório de saída da instalação do Anthos Service Mesh na variável de ambiente DIR_PATH. Este é o mesmo diretório que especificou no procedimento Atualizar com funcionalidades opcionais. 
      export DIR_PATH=OUTPUT_DIR
    3. Crie um script de shell com os seguintes comandos: 
      #!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi
    4. Execute o script para eliminar as versões anteriores.

Fora do Google Cloud

Estas instruções abrangem a atualização do Anthos Service Mesh nos seguintes sistemas:

  • Clusters do Anthos no VMware (GKE On-Prem)
  • Anthos em bare metal
  • Clusters do Anthos no AWS
  • Amazon EKS

A sequência para atualizar para a versão 1.17.8 do Anthos Service Mesh para a sua instalação híbrida é a seguinte:

  1. Prepare-se para a atualização.
  2. Instale a nova versão do Anthos Service Mesh.
  3. Elimine as implementações, os serviços e os webhooks da versão anterior do Anthos Service Mesh da sua instalação atual.
  4. Atualize as suas gateways e configure os novos webhooks.

Prepare-se para atualizar o Anthos Service Mesh para a versão 1.17.8

  1. Reveja os requisitos em Atualize o Anthos Service Mesh, mas não faça a atualização ainda.
  2. Antes de instalar a nova versão, determine a revisão atual. Precisa destas informações para eliminar as implementações, os serviços e os webhooks da versão anterior do Anthos Service Mesh da sua instalação atual. Use o seguinte comando para armazenar a revisão istiod atual numa variável de ambiente: 
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV

    O resultado deve ter um aspeto semelhante a 1.16

  3. Crie um novo ficheiro overlay.yaml ou verifique se o ficheiro overlay.yaml existente contém o seguinte conteúdo: 
    apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:  
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        nodeSelector:
          # default node selector, if different or not using node selectors, change accordingly.
          cloud.google.com/gke-nodepool: apigee-runtime
        resources:
          requests:
            cpu: 1000m
        service:
          type: LoadBalancer
          loadBalancerIP: STATIC_IP # If you do not have a reserved static IP, leave this out.
          ports:
            - name: http-status-port
              port: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  values:
    gateways:
      istio-ingressgateway:
        runAsRoot: true

  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  4. Siga as instruções nas secções seguintes da documentação do Anthos Service Mesh:
    1. Transferir asmcli
    2. Conceda autorizações de administrador do cluster
    3. Valide o projeto e o cluster
    4. Atualize com funcionalidades opcionais. Pare antes de iniciar a "Secção de atualização de gateways".
  5. Mude para o novo plano de controlo:
    1. Obtenha a etiqueta de revisão que está em istiod: 
      kubectl get pod -n istio-system -L istio.io/rev

      O resultado do comando é semelhante ao seguinte. 

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
    2. Atribua a etiqueta de revisão mais recente a uma variável de ambiente.

      Na saída, na coluna REV, tome nota do valor da etiqueta de revisão para a nova versão. Neste exemplo, o valor é asm-1178-1 

      export UPGRADE_REV="REVISION_LABEL"
    3. Adicione a etiqueta de revisão ao espaço de nomes istio-system e remova a etiqueta istio-injection (se existir) com o seguinte comando. 
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      Se vir "istio-injection not found" no resultado, pode ignorá-lo. Isto significa que o espaço de nomes não tinha anteriormente a etiqueta istio-injection. Uma vez que a injeção automática falha se um espaço de nomes tiver a etiqueta istio-injection e a etiqueta de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção da etiqueta istio-injection.

    4. Reinicie os pods para acionar a reinjeção. 
      kubectl rollout restart deployment -n istio-system
    5. Teste a sua aplicação para verificar se as cargas de trabalho estão a funcionar corretamente.
    6. Se tiver cargas de trabalho noutros espaços de nomes, repita os passos para etiquetar o espaço de nomes e reiniciar os pods.
  6. Elimine as versões anteriores:
    1. Navegue para o diretório onde instalou o asmcli.
    2. Armazene o diretório de saída da instalação do Anthos Service Mesh na variável de ambiente DIR_PATH. Este é o mesmo diretório que especificou no procedimento Atualizar com funcionalidades opcionais. 
      export DIR_PATH=OUTPUT_DIR
    3. Crie um script de shell com os seguintes comandos: 
      #!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl apply -f ${DIR_PATH}/asm/istio/istiod-service.yaml
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi
    4. Execute o script para eliminar as versões anteriores.

AKS / EKS

Nestas instruções, o processo de atualização da versão 1.17.8-asm.4-distroless do Anthos Service Mesh (Anthos Service Mesh) em clusters anexados do Anthos é igual ao de uma instalação nova.

A preparar a instalação do Anthos Service Mesh

  1. Antes de instalar a nova versão, determine a revisão atual. Precisa destas informações para eliminar o webhook de validação e o webhook de mutação da sua instalação atual do Anthos Service Mesh. Use o seguinte comando para armazenar a revisão istiod atual numa variável de ambiente: 
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV

    O resultado deve ter um aspeto semelhante a 1.16

    2. Linux

  2. Transfira o ficheiro de instalação do Anthos Service Mesh para o diretório de trabalho atual: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz
  3. Transfira o ficheiro de assinatura e use o OpenSSL para validar a assinatura: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig
     
    openssl dgst -verify /dev/stdin -signature 1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF
  4. Extraia o conteúdo do ficheiro para qualquer localização no seu sistema de ficheiros. Por exemplo, para extrair os conteúdos para o diretório de trabalho atual: 
    tar xzf 1.17.8-asm.4-distroless-linux-amd64.tar.gz

    O comando cria um diretório de instalação no seu diretório de trabalho atual denominado 1.17.8-asm.4-distroless que contém:

    • Exemplos de aplicações no diretório samples.
    • A ferramenta de linha de comandos istioctl que usa para instalar o Anthos Service Mesh está no diretório bin.
    • Os perfis de configuração do Anthos Service Mesh encontram-se no diretório manifests/profiles.
  5. Certifique-se de que está no diretório raiz da instalação do Anthos Service Mesh: 
    cd 1.17.8-asm.4-distroless
  6. Para maior comodidade, adicione as ferramentas no diretório /bin ao seu PATH: 
    export PATH=$PWD/bin:$PATH

    7. Mac OS

  7. Transfira o ficheiro de instalação do Anthos Service Mesh para o diretório de trabalho atual: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz
  8. Transfira o ficheiro de assinatura e use o OpenSSL para validar a assinatura: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz.1.sig
     
    openssl dgst -sha256 -verify /dev/stdin -signature 1.17.8-asm.4-distroless-osx.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF
  9. Extraia o conteúdo do ficheiro para qualquer localização no seu sistema de ficheiros. Por exemplo, para extrair os conteúdos para o diretório de trabalho atual: 
    tar xzf 1.17.8-asm.4-distroless-osx.tar.gz

    O comando cria um diretório de instalação no seu diretório de trabalho atual denominado 1.17.8-asm.4-distroless que contém:

    • Exemplos de aplicações no diretório samples.
    • A ferramenta de linha de comandos istioctl que usa para instalar o Anthos Service Mesh está no diretório bin.
    • Os perfis de configuração do Anthos Service Mesh encontram-se no diretório manifests/profiles.
  10. Certifique-se de que está no diretório raiz da instalação do Anthos Service Mesh: 
    cd 1.17.8-asm.4-distroless
  11. Para maior comodidade, adicione as ferramentas no diretório /bin ao seu PATH: 
    export PATH=$PWD/bin:$PATH

    12. Windows

  12. Transfira o ficheiro de instalação do Anthos Service Mesh para o diretório de trabalho atual: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip
  13. Transfira o ficheiro de assinatura e use o OpenSSL para validar a assinatura: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip.1.sig
     
    openssl dgst -verify - -signature 1.17.8-asm.4-distroless-win.zip.1.sig 1.17.8-asm.4-distroless.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF
  14. Extraia o conteúdo do ficheiro para qualquer localização no seu sistema de ficheiros. Por exemplo, para extrair os conteúdos para o diretório de trabalho atual: 
    tar xzf 1.17.8-asm.4-distroless-win.zip

    O comando cria um diretório de instalação no seu diretório de trabalho atual denominado 1.17.8-asm.4-distroless que contém:

    • Exemplos de aplicações no diretório samples.
    • A ferramenta de linha de comandos istioctl que usa para instalar o Anthos Service Mesh está no diretório bin.
    • Os perfis de configuração do Anthos Service Mesh encontram-se no diretório manifests\profiles.
  15. Certifique-se de que está no diretório raiz da instalação do Anthos Service Mesh: 
    cd 1.17.8-asm.4-distroless
  16. Para maior comodidade, adicione as ferramentas no diretório \bin ao seu PATH: 
    set PATH=%CD%\bin:%PATH%
    17.
  17. Agora que o Anthos Service Mesh Istio está instalado, verifique a versão do istioctl: 
    istioctl version
  18. Crie um espaço de nomes denominado istio-system para os componentes do plano de controlo: 
    kubectl create namespace istio-system

Instalar o Anthos Service Mesh

  1. Edite o ficheiro overlay.yaml ou crie um novo com o seguinte conteúdo: 
    apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
    - name: istio-ingressgateway
      enabled: true
      k8s:
        service:
          type: LoadBalancer
          ports:
          - name: status-port
            port: 15021
            targetPort: 15021
          - name: http2
            port: 80
            targetPort: 8080
          - name: https
            port: 443
            targetPort: 8443
  2. Instale o Anthos Service Mesh com istioctl usando o perfil asm-multicloud: 
    istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1178-1" \
    --filename overlay.yaml

    O resultado deve ter um aspeto semelhante ao seguinte: 

    kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1178-1-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1178-1-798ffb964-fnj8c       1/1     Running   1          3m21s

    O argumento --set revision adiciona uma etiqueta de revisão no formato istio.io/rev=asm-1178-1 a istiod. A etiqueta de revisão é usada pelo webhook do injetor de contentores auxiliares automático para associar contentores auxiliares injetados a uma revisão específica.istiod Para ativar a injeção automática de sidecar para um espaço de nomes, tem de etiquetá-lo com uma revisão que corresponda à etiqueta em istiod.

  3. Confirme se a instalação foi concluída: 
    kubectl get svc -n istio-system

    O resultado deve ter um aspeto semelhante ao seguinte: 

    NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1178-1       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s
  4. Mude para o novo plano de controlo:
    1. Obtenha a etiqueta de revisão que está em istiod: 
      kubectl get pod -n istio-system -L istio.io/rev

      O resultado do comando é semelhante ao seguinte. 

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
    2. Atribua a etiqueta de revisão mais recente a uma variável de ambiente.

      Na saída, na coluna REV, tome nota do valor da etiqueta de revisão para a nova versão. Neste exemplo, o valor é asm-1178-1 

      export UPGRADE_REV="REVISION_LABEL"
    3. Adicione a etiqueta de revisão ao espaço de nomes istio-system e remova a etiqueta istio-injection (se existir) com o seguinte comando. 
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      Se vir "istio-injection not found" no resultado, pode ignorá-lo. Isto significa que o espaço de nomes não tinha anteriormente a etiqueta istio-injection. Uma vez que a injeção automática falha se um espaço de nomes tiver a etiqueta istio-injection e a etiqueta de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção da etiqueta istio-injection.

    4. Reinicie os pods para acionar a reinjeção. 
      kubectl rollout restart deployment -n istio-system
    5. Teste a sua aplicação para verificar se as cargas de trabalho estão a funcionar corretamente.
    6. Se tiver cargas de trabalho noutros espaços de nomes, repita os passos para etiquetar o espaço de nomes e reiniciar os pods.
  5. Elimine as versões anteriores:
    1. Navegue para o diretório onde instalou o asmcli.
    2. Crie um script de shell com os seguintes comandos: 
      #!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi
    3. Execute o script para eliminar as versões anteriores.

OpenShift

Nestas instruções, o processo de atualização da versão 1.17.8-asm.4-distroless do Anthos Service Mesh (Anthos Service Mesh) em clusters anexados do Anthos é igual ao de uma instalação nova.

A preparar a instalação do Anthos Service Mesh

  1. Antes de instalar a nova versão, determine a revisão atual. Precisa destas informações para eliminar o webhook de validação e o webhook de mutação da sua instalação atual do Anthos Service Mesh. Use o seguinte comando para armazenar a revisão istiod atual numa variável de ambiente: 
    export DELETE_REV=$(kubectl get deploy -n istio-system -l app=istiod -o jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}')
echo $DELETE_REV

    O resultado deve ter um aspeto semelhante a 1.16

    2. Linux

  2. Conceda a restrição de contexto de segurança (SCC) anyuid ao istio-system com o seguinte comando da CLI do OpenShift (oc): 
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  3. Transfira o ficheiro de instalação do Anthos Service Mesh para o diretório de trabalho atual: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz
  4. Transfira o ficheiro de assinatura e use o OpenSSL para validar a assinatura: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig
     
    openssl dgst -verify /dev/stdin -signature 1.17.8-asm.4-distroless-linux-amd64.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF
  5. Extraia o conteúdo do ficheiro para qualquer localização no seu sistema de ficheiros. Por exemplo, para extrair os conteúdos para o diretório de trabalho atual: 
    tar xzf 1.17.8-asm.4-distroless-linux-amd64.tar.gz

    O comando cria um diretório de instalação no seu diretório de trabalho atual denominado 1.17.8-asm.4-distroless que contém:

    • Exemplos de aplicações no diretório samples.
    • A ferramenta de linha de comandos istioctl que usa para instalar o Anthos Service Mesh está no diretório bin.
    • Os perfis de configuração do Anthos Service Mesh encontram-se no diretório manifests/profiles.
  6. Certifique-se de que está no diretório raiz da instalação do Anthos Service Mesh: 
    cd 1.17.8-asm.4-distroless
  7. Para maior comodidade, adicione as ferramentas no diretório /bin ao seu PATH: 
    export PATH=$PWD/bin:$PATH

    8. Mac OS

  8. Conceda a restrição de contexto de segurança (SCC) anyuid ao istio-system com o seguinte comando da CLI do OpenShift (oc): 
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  9. Transfira o ficheiro de instalação do Anthos Service Mesh para o diretório de trabalho atual: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz
  10. Transfira o ficheiro de assinatura e use o OpenSSL para validar a assinatura: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-osx.tar.gz.1.sig
     
    openssl dgst -sha256 -verify /dev/stdin -signature 1.17.8-asm.4-distroless-osx.tar.gz.1.sig 1.17.8-asm.4-distroless.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF
  11. Extraia o conteúdo do ficheiro para qualquer localização no seu sistema de ficheiros. Por exemplo, para extrair os conteúdos para o diretório de trabalho atual: 
    tar xzf 1.17.8-asm.4-distroless-osx.tar.gz

    O comando cria um diretório de instalação no seu diretório de trabalho atual denominado 1.17.8-asm.4-distroless que contém:

    • Exemplos de aplicações no diretório samples.
    • A ferramenta de linha de comandos istioctl que usa para instalar o Anthos Service Mesh está no diretório bin.
    • Os perfis de configuração do Anthos Service Mesh encontram-se no diretório manifests/profiles.
  12. Certifique-se de que está no diretório raiz da instalação do Anthos Service Mesh: 
    cd 1.17.8-asm.4-distroless
  13. Para maior comodidade, adicione as ferramentas no diretório /bin ao seu PATH: 
    export PATH=$PWD/bin:$PATH

    14. Windows

  14. Conceda a restrição de contexto de segurança (SCC) anyuid ao istio-system com o seguinte comando da CLI do OpenShift (oc): 
    oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
  15. Transfira o ficheiro de instalação do Anthos Service Mesh para o diretório de trabalho atual: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip
  16. Transfira o ficheiro de assinatura e use o OpenSSL para validar a assinatura: 
    curl -LO https://storage.googleapis.com/gke-release/asm/1.17.8-asm.4-distroless-win.zip.1.sig
     
    openssl dgst -verify - -signature 1.17.8-asm.4-distroless-win.zip.1.sig 1.17.8-asm.4-distroless.win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF
  17. Extraia o conteúdo do ficheiro para qualquer localização no seu sistema de ficheiros. Por exemplo, para extrair os conteúdos para o diretório de trabalho atual: 
    tar xzf 1.17.8-asm.4-distroless-win.zip

    O comando cria um diretório de instalação no seu diretório de trabalho atual denominado 1.17.8-asm.4-distroless que contém:

    • Exemplos de aplicações no diretório samples.
    • A ferramenta de linha de comandos istioctl que usa para instalar o Anthos Service Mesh está no diretório bin.
    • Os perfis de configuração do Anthos Service Mesh encontram-se no diretório manifests\profiles.
  18. Certifique-se de que está no diretório raiz da instalação do Anthos Service Mesh: 
    cd 1.17.8-asm.4-distroless
  19. Para maior comodidade, adicione as ferramentas no diretório \bin ao seu PATH: 
    set PATH=%CD%\bin:%PATH%
    20.
  20. Agora que o Anthos Service Mesh Istio está instalado, verifique a versão do istioctl: 
    istioctl version
  21. Crie um espaço de nomes denominado istio-system para os componentes do plano de controlo: 
    kubectl create namespace istio-system

Configure o webhook de validação

Quando instala o Anthos Service Mesh, define uma etiqueta de revisão em istiod. Tem de definir a mesma revisão no webhook de validação.

  1. Crie um ficheiro denominado istiod-service.yaml com o seguinte conteúdo: 
    apiVersion: v1
kind: Service
metadata:
  name: istiod
  namespace: istio-system
  labels:
    istio.io/rev: asm-1178-1
    app: istiod
    istio: pilot
    release: istio
spec:
  ports:
    - port: 15010
      name: grpc-xds # plaintext
      protocol: TCP
    - port: 15012
      name: https-dns # mTLS with k8s-signed cert
      protocol: TCP
    - port: 443
      name: https-webhook # validation and injection
      targetPort: 15017
      protocol: TCP
    - port: 15014
      name: http-monitoring # prometheus stats
      protocol: TCP
  selector:
    app: istiod
    istio.io/rev: asm-1178-1
  meshConfig:
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  2. Use kubectl para aplicar a configuração do webhook de validação: 
    kubectl apply -f istiod-service.yaml
  3. Verifique se a configuração foi aplicada: 
    kubectl get svc -n istio-system

    A resposta deve ser semelhante à seguinte: 

    NAME     TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                                 AGE
istiod   ClusterIP   172.200.18.133   <none>        15010/TCP,15012/TCP,443/TCP,15014/TCP   22s

Instalar o Anthos Service Mesh

  1. Edite o ficheiro overlay.yaml ou crie um novo com o seguinte conteúdo: 
    apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    accessLogFile: /dev/stdout
    enableTracing: true
    accessLogFormat:
      '{"start_time":"%START_TIME%","remote_address":"%DOWNSTREAM_DIRECT_REMOTE_ADDRESS%","user_agent":"%REQ(USER-AGENT)%","host":"%REQ(:AUTHORITY)%","request":"%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%","request_time":"%DURATION%","status":"%RESPONSE_CODE%","status_details":"%RESPONSE_CODE_DETAILS%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","upstream_address":"%UPSTREAM_HOST%","upstream_response_flags":"%RESPONSE_FLAGS%","upstream_response_time":"%RESPONSE_DURATION%","upstream_service_time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","upstream_cluster":"%UPSTREAM_CLUSTER%","x_forwarded_for":"%REQ(X-FORWARDED-FOR)%","request_method":"%REQ(:METHOD)%","request_path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","request_protocol":"%PROTOCOL%","tls_protocol":"%DOWNSTREAM_TLS_VERSION%","request_id":"%REQ(X-REQUEST-ID)%","sni_host":"%REQUESTED_SERVER_NAME%","apigee_dynamic_data":"%DYNAMIC_METADATA(envoy.lua)%"}'
  components:
    ingressGateways:
      - name: istio-ingressgateway
        enabled: true
        k8s:
          service:
            type: LoadBalancer
            ports:
            - name: status-port
              port: 15021
              targetPort: 15021
            - name: http2
              port: 80
              targetPort: 8080
            - name: https
              port: 443
              targetPort: 8443
  2. Instale o Anthos Service Mesh com istioctl usando o perfil asm-multicloud: 
    istioctl install \
    --set profile=asm-multicloud \
    --set revision="asm-1178-1" \
    --filename overlayfile.yaml

    O resultado deve ter um aspeto semelhante ao seguinte: 

    kubectl get pods -n istio-system
NAME                                   READY   STATUS    RESTARTS   AGE
istio-ingressgateway-88b6fd976-flgp2   1/1     Running   0          3m13s
istio-ingressgateway-88b6fd976-p5dl9   1/1     Running   0          2m57s
istiod-asm-1178-1-798ffb964-2ls88       1/1     Running   0          3m21s
istiod-asm-1178-1-798ffb964-fnj8c       1/1     Running   1          3m21s

    O argumento --set revision adiciona uma etiqueta de revisão no formato istio.io/rev=1.6.11-asm.1 a istiod. A etiqueta de revisão é usada pelo webhook do injetor de contentores auxiliares automático para associar contentores auxiliares injetados a uma revisão específica.istiod Para ativar a injeção automática de sidecar para um espaço de nomes, tem de etiquetá-lo com uma revisão que corresponda à etiqueta em istiod.

  3. Confirme se a instalação foi concluída: 
    kubectl get svc -n istio-system

    O resultado deve ter um aspeto semelhante ao seguinte: 

    NAME                   TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                                                                      AGE
istio-ingressgateway   LoadBalancer   172.200.48.52    34.74.177.168   15021:30479/TCP,80:30030/TCP,443:32200/TCP,15012:32297/TCP,15443:30244/TCP   3m35s
istiod                 ClusterIP      172.200.18.133   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        4m46s
istiod-asm-1178-1       ClusterIP      172.200.63.220   <none>          15010/TCP,15012/TCP,443/TCP,15014/TCP                                        3m43s
  4. Mude para o novo plano de controlo:
    1. Obtenha a etiqueta de revisão que está em istiod: 
      kubectl get pod -n istio-system -L istio.io/rev

      O resultado do comando é semelhante ao seguinte. 

          NAME                                  READY  STATUS  RESTARTS   AGE  REV
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-lrzpz    1/1    Running  0         68m  1.16.7-asm
    istiod-asm-Cloud Service Mesh 1.17.8-asm.4-67998f4b55-r76kr    1/1    Running  0         68m  1.16.7-asm
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-n7tj9      1/1    Running  0         27s  asm-1178-1
    istiod-Cloud Service Mesh 1.16.7-asm.1-1-5cd96f88f6-wm68b      1/1    Running  0         27s  asm-1178-1
    2. Atribua a etiqueta de revisão mais recente a uma variável de ambiente.

      Na saída, na coluna REV, tome nota do valor da etiqueta de revisão para a nova versão. Neste exemplo, o valor é asm-1178-1 

      export UPGRADE_REV="REVISION_LABEL"
    3. Adicione a etiqueta de revisão ao espaço de nomes istio-system e remova a etiqueta istio-injection (se existir) com o seguinte comando. 
      kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite

      Se vir "istio-injection not found" no resultado, pode ignorá-lo. Isto significa que o espaço de nomes não tinha anteriormente a etiqueta istio-injection. Uma vez que a injeção automática falha se um espaço de nomes tiver a etiqueta istio-injection e a etiqueta de revisão, todos os comandos kubectl label na documentação do Anthos Service Mesh incluem a remoção da etiqueta istio-injection.

    4. Reinicie os pods para acionar a reinjeção. 
      kubectl rollout restart deployment -n istio-system
    5. Teste a sua aplicação para verificar se as cargas de trabalho estão a funcionar corretamente.
    6. Se tiver cargas de trabalho noutros espaços de nomes, repita os passos para etiquetar o espaço de nomes e reiniciar os pods.
  5. Elimine as versões anteriores:
    1. Navegue para o diretório onde instalou o asmcli.
    2. Crie um script de shell com os seguintes comandos: 
      #!/bin/bash

set -ex

if [[ "${DELETE_REV}" != "${UPGRADE_REV}" ]]; then
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete deploy -l app=istio-ingressgateway-connectors,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete ValidatingWebhookConfiguration -l app=istiod,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete MutatingWebhookConfiguration -l app=sidecar-injector,istio.io/rev=${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-${DELETE_REV} -n istio-system --ignore-not-found=true
  kubectl delete IstioOperator installed-state-${DELETE_REV} -n istio-system --ignore-not-found=true
fi
    3. Execute o script para eliminar as versões anteriores.

Reverter uma atualização

Siga estes passos para reverter uma atualização anterior:

  1. Limpe as tarefas concluídas para o espaço de nomes de tempo de execução híbrido, em que NAMESPACE é o espaço de nomes especificado no ficheiro de substituições, se tiver especificado um espaço de nomes. Caso contrário, o espaço de nomes predefinido é apigee: 
    kubectl delete job -n NAMESPACE \
  $(kubectl get job -n NAMESPACE \
  -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  2. Limpe as tarefas concluídas para o espaço de nomes 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 anterior de apigeectl. Por exemplo: 
    export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
  4. Anule as alterações ao ficheiro overrides:
    1. Remova ou comente ingressGateways e todas as respetivas propriedades.
    2. Defina o valor de virtualhosts.selector.app para o valor anterior, por exemplo: 
      virtualhosts:
  - name: my-env-group
    selector:
      app: istio-ingressgateway
    3. Remova ou comente ao.args.disableIstioConfigInAPIServer.
  5. No diretório raiz da instalação para a qual quer reverter, execute o comando apigeectl apply, verifique o estado dos seus pods e, em seguida, execute o comando apigeectl init. Certifique-se de que usa o ficheiro de substituições original para a versão para a qual quer reverter:
    1. No diretório hybrid-files, execute apigeectl apply: 
      $APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE

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

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

      Onde NAMESPACE é o seu espaço de nomes híbrido do Apigee.

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

      O resultado deve ter um aspeto semelhante ao seguinte: 

      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

      Avance para o passo seguinte apenas quando o apigeeds pod estiver em execução.

    4. Execute o seguinte comando para tomar nota dos novos valores de contagem de réplicas do processador de mensagens após a atualização.Se estes valores não corresponderem aos que definiu anteriormente, altere os valores no ficheiro de substituições para corresponderem à 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

      O resultado deve ter um aspeto semelhante ao seguinte: 

            autoScaler:
        minReplicas: 2
        maxReplicas: 10
    5. Se estiver a reverter para o híbrido v1.8.4 ou anterior, elimine a implementação do controlador usada pelo híbrido v1.8.5 e mais recente: 
      kubectl -n apigee-system delete deploy apigee-controller-manager
    6. Corrida apigeectl init: 
      $APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE
  6. Elimine a implementação do gestor de gateway de entrada do Apigee. Este componente só é relevante para as versões híbridas do Apigee 1.8 e mais recentes. 
    kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager

    Onde NAMESPACE é o seu espaço de nomes híbrido do Apigee.