Introdução ao gateway de entrada da Apigee
A partir da versão 1.8, a Apigee híbrida oferece um novo recurso para gerenciar o gateway de entrada da sua instalação híbrida, o gateway de entrada da Apigee. O Anthos Service Mesh não é mais um pré-requisito para a instalação híbrida. Com o gateway de entrada da Apigee, a Apigee deixará de fornecer configurações de roteamento para o Anthos Service Mesh. Após o upgrade, você precisará migrar o tráfego para o novo gateway de entrada da Apigee antes de começar a usar o recurso.
A Apigee usa um pequeno subconjunto de recursos do Anthos Service Mesh para o gateway de entrada. A partir da versão 1.8, a Apigee híbrida inclui um gateway de entrada instalado e atualizado como parte dos upgrades da Apigee híbrida. Portanto, você não precisa adquirir experiência no Anthos Service Mesh para instalar, fazer upgrade e gerenciar a Apigee híbrida. Os problemas relacionados às versões de gateway de entrada e a compatibilidade com as versões da Apigee híbrida são tratados automaticamente.
Veja a seguir dois cenários que podem ser migrados:
- Migração em vários clusters ou multirregiões (recomendado):
Antes de alternar para uma nova Entrada para a Apigee, drene todo o tráfego para outro cluster ou região do cluster que você está migrando. Isso dará tempo para você testar se o novo gateway de entrada da Apigee está funcionando conforme o esperado. Depois, transfira o tráfego de volta para o cluster atualizado.
- Upgrade no local (não recomendado em ambientes de produção):
Durante o upgrade, a Apigee abrirá o novo gateway de entrada com um endereço IP que você especificar. Depois, é possível testar se o novo gateway de entrada da Apigee está funcionando conforme o esperado e, em seguida, transferir o tráfego para a nova entrada. Talvez haja inatividade durante esse upgrade.
Ao fazer upgrade da Apigee híbrida para a versão 1.8, é preciso configurar o gateway de entrada da Apigee no arquivo de substituições. Depois de fazer o upgrade, você controla qual tipo de gateway de entrada seus clusters usarão ao direcionar os registros A ou CNAME no seu registrador para o endereço IP do gateway de entrada da Apigee ou para o Anthos Service Mesh.
Visão geral de como fazer upgrade para a versão 1.8.8
Os procedimentos para fazer upgrade da Apigee híbrida são organizados nas seguintes seções:
- Prepare-se para o upgrade.
- Instalar o ambiente de execução híbrido versão 1.8.8.
- Para o gateway de entrada, escolha uma das seguintes opções:
- (Recomendado) Use o novo gateway de entrada da Apigee e siga as etapas em Alternar tráfego do Anthos Service Mesh para o gateway de entrada da Apigee.
- Continue usando o Anthos Service Mesh no seu gateway de entrada.
Pré-requisitos
Estas instruções de upgrade presumem que você tenha a Apigee híbrida versão 1.7.x ou uma versão anterior do patch da versão 1.8.x instaladas e queira fazer upgrade para a versão 1.8.8. 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.7.
Se você preferir continuar usando o Anthos Service Mesh, garanta que o Anthos Service Mesh seja atualizado para uma versão compatível. Consulte a tabela Plataformas compatíveis para ver as versões compatíveis do Anthos Service Mesh.
Preparar para fazer upgrade para a versão 1.8
Fazer backup da instalação híbrida (recomendado)
- 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órioapigeectl
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%
- Faça uma cópia de backup do seu diretório
$APIGEECTL_HOME/
da versão 1.7. Exemplo:tar -czvf $APIGEECTL_HOME/../apigeectl-v1.7-backup.tar.gz $APIGEECTL_HOME
- Faça o backup do banco de dados do 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 concluiu essa etapa na instalação híbrida da v1.7, verifique se a conta de serviço
dos serviços de ambiente de execução da Apigee tem o Papel do agente do Cloud Trace do Google.
(roles/cloudtrace.agent
).
Para ambientes de produção, ela costuma ser a conta de serviço apigee-runtime
. Em
ambientes de não produção, geralmente é a conta de serviç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:
- 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 ele corresponder ao padrão
apigee-runtime@$ORG_NAME.iam.gserviceaccount.com
, use esse padrão na próxima etapaSem 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 - 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.
Prepare-se para instalar o gateway de entrada da Apigee
Para instalar o gateway de entrada da Apigee como parte do upgrade. Você precisa adicionar a seguinte propriedade
ingressGateways
ao arquivo de modificaçõ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 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 configurações padrão, consulte
ingressGateways[].replicaCountMin
eingressGateways[].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 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.requests.cpu
eingressGateways[].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 da Apigee na sua instalação.
Para mais informações e definições padrão, consulte
ingressGateways[].resources.limits.cpu
eingressGateways[].resources.limits.memory
na referência da propriedade de configuração. - SVC_ANNOTATIONS_KEY e 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 ver anotações obrigatórias e sugeridas.
ConsulteingressGateways[].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
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ção.
ConsulteingressGateways[].svcLoadBalancerIP
na referência da propriedade de configuração.
Faça alterações adicionais no seu arquivo de substituição para ativar ou desativar recursos opcionais da v1.8
Adicione as seguintes propriedades ao arquivo overrides.yaml
para ativar novos recursos na
versão v1.8 híbrida. Esses recursos são opcionais.
- A UDCA com escopo na organização agora está ativada por padrão. O uso de uma única implantação de UDCA para lidar com o tráfego de todos os ambientes
evita a subutilização dos pods do UDCA e aumenta a disponibilidade de recursos do nó para outros componentes da Apigee.
A UDCA no escopo da organização usa uma única conta de serviço para todos os ambientes,
apigee-udca
.Se você estiver usando contas de serviço diferentes para UDCA em diferentes ambientes, use a conta de serviço especificada no nível da organização no arquivo de substituição com
udca:serviceAccountPath
, em vez das contas especificadas no nível do ambiente comenvs:udca:serviceAccountPath
.A Apigee híbrida v 1.8 oferece suporte a UDCA com escopo de ambiente. Para manter o UDCA por ambiente, defina
orgScopedUDCA: false
.Consulte
orgScopedUDCA
na referência das propriedades de configuração. - Ative
validateOrg
para exigir uma validação restrita de que a organização e o ambiente da Apigee estão ativos e trabalham com o projeto do Google Cloud Platform especificado no arquivooverrides
.validateOrg: true
Consulte
validateOrg
na referência das propriedades de configuração.
Instalar o ambiente de execução híbrido 1.8.8
- 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/..
-
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.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 64 bit:
curl -LO ^ https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.8.8/apigeectl_windows_64.zip
- Renomeie o diretório
apigeectl/
atual para um nome de diretório de backup. 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
-
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.7
está localizado:Linux
tar xvzf filename.tar.gz -C ./
Mac OS
tar xvzf filename.tar.gz -C ./
Windows
tar xvzf filename.zip -C ./
-
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.8.8-xxxxxxx_linux_64
. Renomeie esse diretório paraapigeectl
usando o 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
-
Altere para o diretório
apigeectl
:cd ./apigeectl
Esse diretório é o diretório inicial
apigeectl
. É lá que o comando executávelapigeectl
está localizado. - Estas instruções usam a variável de ambiente
$APIGEECTL_HOME
para o diretório no seu sistema de arquivos em que o utilitárioapigeectl
está instalado. Se necessário, mude o diretório para seu diretórioapigeectl
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%
- Verifique a versão de
apigeectl
com o comandoversion
:./apigeectl version
Version: 1.8.8
- Mova para o diretório
hybrid-base-directory/hybrid-files
. O diretóriohybrid-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
- 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 \*
- No diretório
hybrid-files
:-
Atualize os seguintes links simbólicos para
$APIGEECTL_HOME
. Com esses links, você pode executar o comandoapigeectl
recém-instalado no diretóriohybrid-files
:ln -nfs
$APIGEECTL_HOME
/tools toolsln -nfs
$APIGEECTL_HOME
/config configln -nfs
$APIGEECTL_HOME
/templates templatesln -nfs
$APIGEECTL_HOME
/plugins plugins -
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
-
Atualize os seguintes links simbólicos para
- 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
. - Se não houver erros, inicialize o híbrido 1.8.8. Este comando
também instala e configura o gateway de entrada da Apigee:
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
- 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.
Como verificação adicional, execute este comando para verificar o status do ApigeeDataStore:
kubectl describe apigeeds -n apigee
Na saída, procure
State: running
. - 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
- 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 para o processo de confirmação do próximo componente.
- Verifique se você está no diretório
hybrid-files
. - Aplique as modificações para fazer upgrade do Cassandra:
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
- Verifique a conclusão:
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
Passe para a próxima etapa somente quando os pods estiverem prontos.
- 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
- Acesse os componentes do Redis:
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
- 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
- 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
- Ambiente por ambiente: aplique suas modificações em um ambiente por vez e verifique a conclusão. Repita
esta etapa para cada ambiente:
- 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.
- Verifique se você está no diretório
hybrid-files
. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
- Verifique o status:
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
- Verifique se você está no diretório
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.8. Siga a documentação da plataforma se precisar de ajuda.
Migrar o tráfego do Anthos Service Mesh para o gateway de entrada da Apigee
Para alternar o tráfego para o gateway de entrada da Apigee, faça o seguinte:
- Exponha o gateway de entrada da Apigee. Siga os procedimentos em Expor o gateway de entrada da Apigee.
- Teste seu gateway de entrada chamando um proxy. O ideal é testar todos os proxies importantes que você implantou no momento.
- 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
- 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.
- 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".
- Teste novamente e monitore o tráfego de proxy da API.
- Siga as instruções na documentação do Anthos Service Mesh para desinstalar o Anthos Service Mesh do cluster.
Fazer upgrade do Anthos Service Mesh para a versão 1.15
Realize os procedimentos usando a documentação do Anthos Service Mesh adequada para sua plataforma:
As instruções para instalar e configurar o Anthos Service Mesh variam de acordo com a plataforma. As plataformas são divididas nas seguintes categorias:
- GKE: clusters do Google Kubernetes Engine em execução no Google Cloud.
- Fora do Google Cloud: os clusters do Anthos são executados em:
- Clusters do Anthos no VMware (GKE On-Prem)
- Anthos em bare metal
- Clusters do Anthos no AWS
- Amazon EKS
- Outras plataformas do Kubernetes: clusters compatíveis criados e em execução em:
- AKS
- EKS
- OpenShift
GKE
A sequência de upgrade para a versão 1.13.9 do Anthos Service Mesh para sua instalação híbrida é a seguinte:
- prepare-se para o upgrade;
- Instale a nova versão do Anthos Service Mesh.
- Exclua as implantações, os serviços e os webhooks da versão anterior do Anthos Service Mesh da sua instalação atual.
- faça upgrade dos gateways e configure os novos webhooks.
Prepare-se para fazer upgrade do Anthos Service Mesh para a versão 1.13.9
- Veja os requisitos em Fazer upgrade do Anthos Service Mesh, mas ainda não faça o upgrade.
- Antes de instalar a nova versão, determine a revisão atual. Você precisará
dessas informações para excluir as implantações, os serviços e os
webhooks da versão anterior do Anthos Service Mesh da instalação atual. Use o seguinte comando para armazenar a
revisão atual do
istiod
em uma 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
A saída vai ser semelhante a
1.12.9-asm.2
- Crie um novo arquivo
overlay.yaml
ou verifique se ooverlay.yaml
atual 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)%"}'
- Siga as instruções nas seguintes seções da documentação do Anthos Service Mesh:
- faça o download do asmcli;
- conceda permissões de administrador de cluster;
- Valide o projeto e o cluster;
- faça upgrade com recursos opcionais. Pare antes de iniciar a seção "Fazer upgrade dos gateways".
- Alternar para o novo plano de controle:
- Receba o identificador de revisão que está em
istiod
.kubectl get pod -n istio-system -L istio.io/rev
A saída deste comando é semelhante a:
NAME READY STATUS RESTARTS AGE REV istiod-asm-1139-10-67998f4b55-lrzpz 1/1 Running 0 68m asm-1129-0 istiod-asm-1139-10-67998f4b55-r76kr 1/1 Running 0 68m asm-1129-0 istiod-1129-0-1-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1139-10 istiod-1129-0-1-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1139-10
- Atribua o identificador de revisão mais recente a uma variável de ambiente.
Na saída, na coluna
REV
, anote o valor do identificador de revisão da nova versão. Neste exemplo, o valor éasm-1139-10
export UPGRADE_REV="REVISION_LABEL"
- Adicione o identificador de revisão ao namespace
istio-system
e remova o identificadoristio-injection
(se houver) com o comando a seguir.kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
Se vir
"istio-injection not found"
na saída, poderá ignorá-la. Isso significa que o namespace não tinha o identificadoristio-injection
anteriormente. Como a injeção automática falha se um namespace tiver oistio-injection
e o identificador de revisão, todos os comandoskubectl label
na documentação do Anthos Service Mesh incluem a remoção do identificadoristio-injection
- Reinicie os pods para acionar a nova injeção:
kubectl rollout restart deployment -n istio-system
- Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.
- Se você tiver cargas de trabalho em outros namespaces, repita as etapas para identificar o namespace e reiniciar os pods.
- Receba o identificador de revisão que está em
- Exclua as versões anteriores:
- Vá para o diretório onde você instalou
asmcli
. - Armazene o diretório de saída da instalação do Anthos Service Mesh na
variável de ambiente
DIR_PATH
. Esse é o mesmo diretório especificado no procedimento Fazer upgrade com recursos opcionais.export DIR_PATH=OUTPUT_DIR
- Crie um script de shell contendo 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
- Execute o script para excluir as versões anteriores.
- Vá para o diretório onde você instalou
Fora do Google Cloud
Nestas instruções, abordamos o upgrade do Anthos Service Mesh em:
- Clusters do Anthos no VMware (GKE On-Prem)
- Anthos em bare metal
- Clusters do Anthos no AWS
- Amazon EKS
A sequência de upgrade para a versão 1.13.9 do Anthos Service Mesh para sua instalação híbrida é a seguinte:
- prepare-se para o upgrade;
- Instale a nova versão do Anthos Service Mesh.
- Exclua as implantações, os serviços e os webhooks da versão anterior do Anthos Service Mesh da sua instalação atual.
- faça upgrade dos gateways e configure os novos webhooks.
Prepare-se para fazer upgrade do Anthos Service Mesh para a versão 1.13.9
- Veja os requisitos em Fazer upgrade do Anthos Service Mesh, mas ainda não faça o upgrade.
- Antes de instalar a nova versão, determine a revisão atual. Você precisará
dessas informações para excluir as implantações, os serviços e os
webhooks da versão anterior do Anthos Service Mesh da instalação atual. Use o seguinte comando para armazenar a
revisão atual do
istiod
em uma 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
A saída vai ser semelhante a
1.12.9-asm.2
- Crie um novo arquivo
overlay.yaml
ou verifique se ooverlay.yaml
atual 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)%"}'
- Siga as instruções nas seguintes seções da documentação do Anthos Service Mesh:
- faça o download do asmcli;
- conceda permissões de administrador de cluster;
- Valide o projeto e o cluster;
- faça upgrade com recursos opcionais. Pare antes de iniciar a seção "Fazer upgrade dos gateways".
- Alternar para o novo plano de controle:
- Receba o identificador de revisão que está em
istiod
.kubectl get pod -n istio-system -L istio.io/rev
A saída deste comando é semelhante a:
NAME READY STATUS RESTARTS AGE REV istiod-asm-1139-10-67998f4b55-lrzpz 1/1 Running 0 68m asm-1129-0 istiod-asm-1139-10-67998f4b55-r76kr 1/1 Running 0 68m asm-1129-0 istiod-1129-0-1-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1139-10 istiod-1129-0-1-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1139-10
- Atribua o identificador de revisão mais recente a uma variável de ambiente.
Na saída, na coluna
REV
, anote o valor do identificador de revisão da nova versão. Neste exemplo, o valor éasm-1139-10
export UPGRADE_REV="REVISION_LABEL"
- Adicione o identificador de revisão ao namespace
istio-system
e remova o identificadoristio-injection
(se houver) com o comando a seguir.kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
Se vir
"istio-injection not found"
na saída, poderá ignorá-la. Isso significa que o namespace não tinha o identificadoristio-injection
anteriormente. Como a injeção automática falha se um namespace tiver oistio-injection
e o identificador de revisão, todos os comandoskubectl label
na documentação do Anthos Service Mesh incluem a remoção do identificadoristio-injection
- Reinicie os pods para acionar a nova injeção:
kubectl rollout restart deployment -n istio-system
- Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.
- Se você tiver cargas de trabalho em outros namespaces, repita as etapas para identificar o namespace e reiniciar os pods.
- Receba o identificador de revisão que está em
- Exclua as versões anteriores:
- Vá para o diretório onde você instalou
asmcli
. - Armazene o diretório de saída da instalação do Anthos Service Mesh na
variável de ambiente
DIR_PATH
. Esse é o mesmo diretório especificado no procedimento Fazer upgrade com recursos opcionais.export DIR_PATH=OUTPUT_DIR
- Crie um script de shell contendo 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
- Execute o script para excluir as versões anteriores.
- Vá para o diretório onde você instalou
AKS / EKS
Nestas instruções, o processo de upgrade da versão istio-1.13.9-asm.10 do Anthos Service Mesh (Anthos Service Mesh) nos clusters anexados ao Anthos é o mesmo que executar uma nova instalação.
Como preparar a instalação do Anthos Service Mesh
- Antes de instalar a nova versão, determine a revisão atual. Você vai precisar
dessas informações para excluir o webhook de validação e o webhook de mutação
da instalação atual do Anthos Service Mesh. Use o seguinte comando para armazenar a
revisão atual do
istiod
em uma 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
A saída vai ser semelhante a
1.12.9-asm.2
- Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz
- Faça o download do arquivo de assinatura e use OpenSSL para verificar a
assinatura:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF - Extraia o conteúdo do arquivo em qualquer local no sistema. Por
exemplo, para extrair o conteúdo para o diretório de trabalho atual:
tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado
istio-1.13.9-asm.10
, que contém o seguinte:- Exemplos de aplicativos no diretório
samples
. - A ferramenta de linha de comando
istioctl
que você usa para instalar o Anthos Service Mesh está no diretóriobin
. - Os perfis de configuração do Anthos Service Mesh estão no
diretório
manifests/profiles
.
- Exemplos de aplicativos no diretório
- Verifique se você está no diretório raiz da instalação do Anthos Service Mesh:
cd istio-1.13.9-asm.10
-
Para facilitar, adicione as ferramentas ao diretório
/bin
ao seuPATH
:export PATH=$PWD/bin:$PATH
- Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz
- Faça o download do arquivo de assinatura e use OpenSSL para verificar a
assinatura:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF - Extraia o conteúdo do arquivo em qualquer local no sistema. Por
exemplo, para extrair o conteúdo para o diretório de trabalho atual:
tar xzf istio-1.13.9-asm.10-osx.tar.gz
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado
istio-1.13.9-asm.10
, que contém o seguinte:- Exemplos de aplicativos no diretório
samples
. - A ferramenta de linha de comando
istioctl
que você usa para instalar o Anthos Service Mesh está no diretóriobin
. - Os perfis de configuração do Anthos Service Mesh estão no
diretório
manifests/profiles
.
- Exemplos de aplicativos no diretório
- Verifique se você está no diretório raiz da instalação do Anthos Service Mesh:
cd istio-1.13.9-asm.10
-
Para facilitar, adicione as ferramentas ao diretório
/bin
ao seuPATH
:export PATH=$PWD/bin:$PATH
- Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip
- Faça o download do arquivo de assinatura e use OpenSSL para verificar a
assinatura:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig
openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF - Extraia o conteúdo do arquivo em qualquer local no sistema. Por
exemplo, para extrair o conteúdo para o diretório de trabalho atual:
tar xzf istio-1.13.9-asm.10-win.zip
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado
istio-1.13.9-asm.10
, que contém o seguinte:- Exemplos de aplicativos no diretório
samples
. - A ferramenta de linha de comando
istioctl
que você usa para instalar o Anthos Service Mesh está no diretóriobin
. - Os perfis de configuração do Anthos Service Mesh estão no
diretório
manifests\profiles
.
- Exemplos de aplicativos no diretório
- Verifique se você está no diretório raiz da instalação do Anthos Service Mesh:
cd istio-1.13.9-asm.10
- Para facilitar, adicione as ferramentas ao diretório /bin do seu PATH.
set PATH=%CD%\bin:%PATH%
- Agora que o Istio do Anthos Service Mesh está instalado, verifique a versão do
istioctl
:istioctl version
- Crie um namespace chamado istio-system para os componentes do plano de controle:
kubectl create namespace istio-system
Linux
macOS
Windows
Como instalar o Anthos Service Mesh
- Edite seu arquivo
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
- Instale o Anthos Service Mesh com
istioctl
usando o perfilasm-multicloud
:istioctl install \ --set profile=asm-multicloud \ --set revision="asm-1139-10" \ --filename overlay.yaml
A saída será semelhante a esta:
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-1139-10-798ffb964-2ls88 1/1 Running 0 3m21s istiod-asm-1139-10-798ffb964-fnj8c 1/1 Running 1 3m21s
O argumento
--set revision
adiciona um rótulo de revisão no formatoistio.io/rev=asm-1139-10
aistiod
. O rótulo de revisão é usado pelo webhook do injetor automático de sidecar para associar os sidecars injetados a uma revisãoistiod
específica. Para ativar a injeção automática de sidecar para um namespace, você precisa rotulá-lo com uma revisão que corresponda ao rótulo emistiod
. - Verifique se a instalação foi concluída:
kubectl get svc -n istio-system
A saída será semelhante a esta:
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-1139-10 ClusterIP 172.200.63.220 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 3m43s
- Alternar para o novo plano de controle:
- Receba o identificador de revisão que está em
istiod
.kubectl get pod -n istio-system -L istio.io/rev
A saída deste comando é semelhante a:
NAME READY STATUS RESTARTS AGE REV istiod-asm-1139-10-67998f4b55-lrzpz 1/1 Running 0 68m asm-1129-0 istiod-asm-1139-10-67998f4b55-r76kr 1/1 Running 0 68m asm-1129-0 istiod-1129-0-1-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1139-10 istiod-1129-0-1-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1139-10
- Atribua o identificador de revisão mais recente a uma variável de ambiente.
Na saída, na coluna
REV
, anote o valor do identificador de revisão da nova versão. Neste exemplo, o valor éasm-1139-10
export UPGRADE_REV="REVISION_LABEL"
- Adicione o identificador de revisão ao namespace
istio-system
e remova o identificadoristio-injection
(se houver) com o comando a seguir.kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
Se vir
"istio-injection not found"
na saída, poderá ignorá-la. Isso significa que o namespace não tinha o identificadoristio-injection
anteriormente. Como a injeção automática falha se um namespace tiver oistio-injection
e o identificador de revisão, todos os comandoskubectl label
na documentação do Anthos Service Mesh incluem a remoção do identificadoristio-injection
- Reinicie os pods para acionar a nova injeção:
kubectl rollout restart deployment -n istio-system
- Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.
- Se você tiver cargas de trabalho em outros namespaces, repita as etapas para identificar o namespace e reiniciar os pods.
- Receba o identificador de revisão que está em
- Exclua as versões anteriores:
- Vá para o diretório onde você instalou
asmcli
. - Crie um script de shell contendo 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
- Execute o script para excluir as versões anteriores.
- Vá para o diretório onde você instalou
OpenShift
Nestas instruções, o processo de upgrade da versão istio-1.13.9-asm.10 do Anthos Service Mesh (Anthos Service Mesh) nos clusters anexados ao Anthos é o mesmo que executar uma nova instalação.
Como preparar a instalação do Anthos Service Mesh
- Antes de instalar a nova versão, determine a revisão atual. Você vai precisar
dessas informações para excluir o webhook de validação e o webhook de mutação
da instalação atual do Anthos Service Mesh. Use o seguinte comando para armazenar a
revisão atual do
istiod
em uma 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
A saída vai ser semelhante a
1.12.9-asm.2
- Conceda a restrição de contexto de segurança
anyuid
(SCC) ao istio-system com o seguinte comando da CLI do OpenShift (oc
):oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
- Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz
- Faça o download do arquivo de assinatura e use OpenSSL para verificar a
assinatura:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.13.9-asm.10-linux-amd64.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF - Extraia o conteúdo do arquivo em qualquer local no sistema. Por
exemplo, para extrair o conteúdo para o diretório de trabalho atual:
tar xzf istio-1.13.9-asm.10-linux-amd64.tar.gz
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado
istio-1.13.9-asm.10
, que contém o seguinte:- Exemplos de aplicativos no diretório
samples
. - A ferramenta de linha de comando
istioctl
que você usa para instalar o Anthos Service Mesh está no diretóriobin
. - Os perfis de configuração do Anthos Service Mesh estão no
diretório
manifests/profiles
.
- Exemplos de aplicativos no diretório
- Verifique se você está no diretório raiz da instalação do Anthos Service Mesh:
cd istio-1.13.9-asm.10
-
Para facilitar, adicione as ferramentas ao diretório
/bin
ao seuPATH
:export PATH=$PWD/bin:$PATH
- Conceda a restrição de contexto de segurança
anyuid
(SCC) ao istio-system com o seguinte comando da CLI do OpenShift (oc
):oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
- Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz
- Faça o download do arquivo de assinatura e use OpenSSL para verificar a
assinatura:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.13.9-asm.10-osx.tar.gz.1.sig istio-1.13.9-asm.10.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF - Extraia o conteúdo do arquivo em qualquer local no sistema. Por
exemplo, para extrair o conteúdo para o diretório de trabalho atual:
tar xzf istio-1.13.9-asm.10-osx.tar.gz
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado
istio-1.13.9-asm.10
, que contém o seguinte:- Exemplos de aplicativos no diretório
samples
. - A ferramenta de linha de comando
istioctl
que você usa para instalar o Anthos Service Mesh está no diretóriobin
. - Os perfis de configuração do Anthos Service Mesh estão no
diretório
manifests/profiles
.
- Exemplos de aplicativos no diretório
- Verifique se você está no diretório raiz da instalação do Anthos Service Mesh:
cd istio-1.13.9-asm.10
-
Para facilitar, adicione as ferramentas ao diretório
/bin
ao seuPATH
:export PATH=$PWD/bin:$PATH
- Conceda a restrição de contexto de segurança
anyuid
(SCC) ao istio-system com o seguinte comando da CLI do OpenShift (oc
):oc adm policy add-scc-to-group anyuid system:serviceaccounts:istio-system
- Faça o download do arquivo de instalação do Anthos Service Mesh no diretório de trabalho atual:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip
- Faça o download do arquivo de assinatura e use OpenSSL para verificar a
assinatura:
curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.13.9-asm.10-win.zip.1.sig
openssl dgst -verify - -signature istio-1.13.9-asm.10-win.zip.1.sig istio-1.13.9-asm.10.win.zip <<'EOF'
-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw== -----END PUBLIC KEY----- EOF - Extraia o conteúdo do arquivo em qualquer local no sistema. Por
exemplo, para extrair o conteúdo para o diretório de trabalho atual:
tar xzf istio-1.13.9-asm.10-win.zip
O comando cria um diretório de instalação no seu diretório de trabalho atual, chamado
istio-1.13.9-asm.10
, que contém o seguinte:- Exemplos de aplicativos no diretório
samples
. - A ferramenta de linha de comando
istioctl
que você usa para instalar o Anthos Service Mesh está no diretóriobin
. - Os perfis de configuração do Anthos Service Mesh estão no
diretório
manifests\profiles
.
- Exemplos de aplicativos no diretório
- Verifique se você está no diretório raiz da instalação do Anthos Service Mesh:
cd istio-1.13.9-asm.10
- Para facilitar, adicione as ferramentas ao diretório /bin do seu PATH.
set PATH=%CD%\bin:%PATH%
- Agora que o Istio do Anthos Service Mesh está instalado, verifique a versão do
istioctl
:istioctl version
- Crie um namespace chamado istio-system para os componentes do plano de controle:
kubectl create namespace istio-system
Linux
macOS
Windows
Configurar o webhook de validação
Ao instalar o Anthos Service Mesh, você define um rótulo de revisão em istiod
. Você
precisa definir a mesma revisão no webhook de validação.
- Crie um arquivo chamado
istiod-service.yaml
com o conteúdo a seguir.apiVersion: v1 kind: Service metadata: name: istiod namespace: istio-system labels: istio.io/rev: asm-1139-10 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-1139-10 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)%"}'
- Use
kubectl
para aplicar a configuração de validação do webhook:kubectl apply -f istiod-service.yaml
- Verifique se a configuração foi aplicada:
kubectl get svc -n istio-system
A resposta será semelhante a:
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
Como instalar o Anthos Service Mesh
- Edite seu arquivo
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
- Instale o Anthos Service Mesh com
istioctl
usando o perfilasm-multicloud
:istioctl install \ --set profile=asm-multicloud \ --set revision="asm-1139-10" \ --filename overlayfile.yaml
A saída será semelhante a esta:
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-1139-10-798ffb964-2ls88 1/1 Running 0 3m21s istiod-asm-1139-10-798ffb964-fnj8c 1/1 Running 1 3m21s
O argumento
--set revision
adiciona um rótulo de revisão no formatoistio.io/rev=1.6.11-asm.1
aistiod
. O rótulo de revisão é usado pelo webhook do injetor automático de sidecar para associar os sidecars injetados a uma revisãoistiod
específica. Para ativar a injeção automática de sidecar para um namespace, você precisa rotulá-lo com uma revisão que corresponda ao rótulo emistiod
. - Verifique se a instalação foi concluída:
kubectl get svc -n istio-system
A saída será semelhante a esta:
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-1139-10 ClusterIP 172.200.63.220 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 3m43s
- Alternar para o novo plano de controle:
- Receba o identificador de revisão que está em
istiod
.kubectl get pod -n istio-system -L istio.io/rev
A saída deste comando é semelhante a:
NAME READY STATUS RESTARTS AGE REV istiod-asm-1139-10-67998f4b55-lrzpz 1/1 Running 0 68m asm-1129-0 istiod-asm-1139-10-67998f4b55-r76kr 1/1 Running 0 68m asm-1129-0 istiod-1129-0-1-5cd96f88f6-n7tj9 1/1 Running 0 27s asm-1139-10 istiod-1129-0-1-5cd96f88f6-wm68b 1/1 Running 0 27s asm-1139-10
- Atribua o identificador de revisão mais recente a uma variável de ambiente.
Na saída, na coluna
REV
, anote o valor do identificador de revisão da nova versão. Neste exemplo, o valor éasm-1139-10
export UPGRADE_REV="REVISION_LABEL"
- Adicione o identificador de revisão ao namespace
istio-system
e remova o identificadoristio-injection
(se houver) com o comando a seguir.kubectl label namespace istio-system istio.io/rev=$UPGRADE_REV istio-injection- --overwrite
Se vir
"istio-injection not found"
na saída, poderá ignorá-la. Isso significa que o namespace não tinha o identificadoristio-injection
anteriormente. Como a injeção automática falha se um namespace tiver oistio-injection
e o identificador de revisão, todos os comandoskubectl label
na documentação do Anthos Service Mesh incluem a remoção do identificadoristio-injection
- Reinicie os pods para acionar a nova injeção:
kubectl rollout restart deployment -n istio-system
- Teste o aplicativo para verificar se as cargas de trabalho estão funcionando corretamente.
- Se você tiver cargas de trabalho em outros namespaces, repita as etapas para identificar o namespace e reiniciar os pods.
- Receba o identificador de revisão que está em
- Exclua as versões anteriores:
- Vá para o diretório onde você instalou
asmcli
. - Crie um script de shell contendo 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
- Execute o script para excluir as versões anteriores.
- Vá para o diretório onde você instalou
Como reverter um upgrade
Siga estas etapas para reverter um upgrade anterior:
- 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}')
- 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}')
- Altere a variável
APIGEECTL_HOME
para apontar para o diretório que contém a versão original deapigeectl
. Exemplo:export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
- Desfaça as mudanças no arquivo
overrides
:- Remova ou comente
ingressGateways
e todas as propriedades dele. - Defina o valor de
virtualhosts.selector.app
como o valor anterior, por exemplo:virtualhosts: - name: my-env-group selector: app: istio-ingressgateway
- Remova ou comente
ao.args.disableIstioConfigInAPIServer
.
- Remova ou comente
- No diretório raiz da instalação para a qual você quer reverter, execute
apigeectl apply
, verifique o status dos pods e executeapigeectl init
. Use o arquivo de modificações original da versão para a qual você quer reverter:- No diretório de arquivos híbridos, execute
apigeectl apply
:$APIGEECTL_HOME
/apigeectl apply -f ORIGINAL_OVERRIDES_FILEEm 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.7.yaml
. - Verifique o status dos seus pods.
kubectl -n NAMESPACE get pods
Em que NAMESPACE é seu namespace da Apigee híbrida.
- 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. - 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ção 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 resposta será semelhante a esta:
autoScaler: minReplicas: 2 maxReplicas: 10
-
Se você estiver revertendo para a versão híbrida v1.8.4 ou anterior, exclua a implantação do controlador usada
pelo híbrido v1.8.5 e versões mais recentes:
kubectl -n apigee-system delete deploy apigee-controller-manager
- Execute
apigeectl init
:$APIGEECTL_HOME
/apigeectl init -f ORIGINAL_OVERRIDES_FILE
- No diretório de arquivos híbridos, execute
- Exclua a implantação do gerenciador de gateways de entrada da Apigee. Este componente é relevante apenas para as versões da Apigee híbrida 1.8 e mais recentes.
kubectl delete deployment -n NAMESPACE apigee-ingress-gateway-manager
Em que NAMESPACE é seu namespace da Apigee híbrida.