Todos os produtos
Search
Central de documentação

Alibaba Cloud Service Mesh:Upgrade an ASM instance

Última atualização: Jun 28, 2026

Para garantir a continuidade dos negócios e evitar riscos de segurança e estabilidade decorrentes de instâncias expiradas, o Service Mesh (ASM) oferece suporte a atualizações no local e canary releases para atualizar o plano de controle e o plano de dados.

Pré-requisitos

Uma instância do ASM foi criada.

Conceitos principais

Visualize descrições de atualização no local, canary release, plano de controle e plano de dados

Termo

Descrição

Atualização no local

Permite atualizações faseadas do plano de controle e do plano de dados. Atualize o plano de controle no console do ASM e, em seguida, atualize manualmente os proxies sidecar e os gateways no plano de dados.

Canary release

Execute uma nova versão do plano de controle e migre os serviços incrementalmente. Após verifique o funcionamento correto dos serviços, migre os restantes. Faça rollback se ocorrerem problemas durante a verificação.

Plano de controle

O plano de controle gerencia as políticas e regras do Service Mesh. Responsabilidades principais:

  • Descoberta de serviços: mantém as informações de registro para que os serviços possam se descobrir e se comunicar entre si.

  • Gerenciamento de configuração: fornece uma API unificada para configurar e gerencie regras de tráfego, políticas e definições do Service Mesh.

  • Decisão de política: define e executa políticas de controle de acesso, limitação de taxa, injeção de falhas e roteamento.

  • Gerenciamento de certificados: gerencia certificados e chaves para comunicação criptografada entre serviços.

No ASM, o plano de controle consiste principalmente em componentes do Istio. Por exemplo, o Istio-Pilot implementa a descoberta de serviços e o gerenciamento de tráfego, enquanto o Istio-Citadel gerencia os certificados para comunicação segura.

Plano de dados

O plano de dados consiste em proxies de rede leves implantados como sidecars ao lado dos contêineres de aplicação. Responsabilidades principais:

  • Interceptação de tráfego: intercepta todo o tráfego de rede de entrada e saída de um pod.

  • Roteamento de tráfego: encaminha, balanceia e roteia o tráfego com base nas configurações do plano de controle.

  • Relatório de dados: coleta e relata métricas de comunicação entre serviços, como latência, tráfego e taxas de erro.

  • Execução de políticas: implementa controle de acesso, limitação de taxa e outras políticas.

No ASM, o plano de dados é implementado principalmente com proxies Envoy fornecidos pelo Istio. Os proxies Envoy são implantados próximos aos serviços de aplicação na forma de sidecars e oferecem recursos de proxy de rede de alto desempenho.

Por que atualizar?

O ASM atualiza as versões principais suportadas do Istio aproximadamente a cada três meses. Versões de patch (como 1.19.x.y) são lançadas conforme necessário para novos recursos e correções de vulnerabilidades. Instâncias expiradas apresentam riscos de segurança e estabilidade. Atualize suas instâncias do ASM prontamente. As versões suportadas estão listadas em Mecanismo de versionamento.

Benefícios das atualizações proativas:

  • Redução de riscos de segurança e estabilidade: Cada versão corrige vulnerabilidades conhecidas. Manter instâncias expiradas pode expor seus negócios a riscos de segurança e estabilidade.

  • Suporte de manutenção aprimorado: O ASM não fornece mais patches ou suporte técnico para versões expiradas. A atualização garante a continuidade do suporte.

  • Acesso a novos recursos: O ASM se adapta às novas versões open source do Istio, proporcionando experiências aprimoradas para desenvolvedores e equipes de O&M.

Precauções e instruções para atualizações

Precauções

  • A atualização exige o reinício manual dos pods do plano de dados para reinjetar os sidecars da nova versão. Realize atualizações fora do horário de pico.

  • A atualização manual de um gateway do ASM aciona um reinício gradual.

  • A injeção de sidecar pode ficar brevemente indisponível durante o processo de atualização. Evite atualizar pods nesse período.

  • Durante uma atualização, não execute operações como liberação faseada ou configuração de regras de tráfego.

  • O ASM realiza uma verificação pré-atualização, mas pode não detectar todas as configurações incompatíveis ou operações de API. Revise as precauções de atualização para sua versão de destino antes de prosseguir.

  • Por motivos de segurança, o ASM fornece os seguintes mecanismos:

    • O ASM pode forçar a atualização de instâncias expiradas para a versão suportada mais antiga. Atualize proativamente para evitar atualizações forçadas.

    • Atualizações de patch (por exemplo, v1.18.0.123 para v1.18.0.146) são aplicadas automaticamente sem notificação. As versões do gateway do plano de dados e do proxy sidecar permanecem inalteradas durante atualizações a quente.

Instruções sobre atualizações no local

Atualizações no local suportam apenas atualizações para uma versão adjacente. Não há suporte para atualizações entre versões distantes nem rollbacks.

Instruções sobre canary releases

Uma canary release permite verificar uma nova versão antes de mudar para ela, oferecendo um caminho de atualização mais seguro. Esse método suporta atualizações através de uma versão secundária e rollbacks durante o processo.

Tipo

Descrição

Versões aplicáveis

Instâncias Enterprise Edition ou Ultimate Edition da versão 1.16.4.91 ou posterior.

Cenários

  • Atualização de uma instância através de uma versão secundária. Por exemplo, é possível atualizar uma instância de 1.16.4 para 1.17.2.

  • Atualização de uma instância quando a versão secundária muda. Por exemplo, é possível atualizar uma instância de 1.16.4 para 1.17.2 ou 1.18.0. A atualização pode abranger no máximo uma versão secundária.

Nota

Se apenas a versão asm-patch mudar, recomendamos realizar uma atualização no local.

Formato da versão

A versão de uma instância do ASM segue o formato: <major>.<minor>.<patch>.<asm-patch>[-<sequence>-aliyun]. Exemplo: v1.18.0.158-gc6cf0b9c-aliyun (Enterprise Edition). A lista a seguir descreve os campos do formato:

  • major: a versão principal.

  • minor: a versão secundária.

  • patch: a versão de patch.

  • <major>.<minor>.<patch>: a versão do Istio open source. Exemplo: 1.18.0.

  • asm-patch: a versão de patch lançada pelo ASM com base na versão open source. Por exemplo, no número de versão 1.18.0.158, 158 indica a versão de patch lançada pelo ASM.

  • sequence: o commit do Git para o código da versão.

Instruções sobre rótulos de injeção de Sidecar

Ao ative a canary release, duas versões do plano de controle coexistem. Por exemplo, ao atualizar de 1.17.2.42 para 1.18.0, ambas as versões 1.17.2 e 1.18.0 ficam disponíveis simultaneamente.

Durante uma canary release, adicione um rótulo de injeção a um namespace para especifique qual versão do sidecar injetar. O rótulo padrão istio-injection=enabled injeta a versão atual.

Mapeamento entre versão do sidecar e rótulo do namespace quando duas versões coexistem:

  • Versão atual

    • O sidecar injetado pelo rótulo istio-injection=enabled corresponde à versão atual do ASM e se conecta ao plano de controle da versão atual.

    • Adicione o rótulo istio.io/rev=$revision ao namespace para especifique a versão do sidecar a ser injetada. O formato da variável revision é x-y-z, como 1-17-2.

    • Adicione o rótulo istio.io/rev=stable ao namespace para especifique que a versão do sidecar a ser injetada é a versão atual do ASM.

    Importante

    Não é possível adicionar os rótulos istio-injection e istio.io/rev a um namespace simultaneamente.

    image

  • Versão canary

    Se um serviço de negócio precisar receber a injeção de um sidecar correspondente à versão canary, adicione o rótulo istio.io/rev=$revision ou istio.io/rev=canary ao namespace. O formato de $revision é x-y-z, como 1-18-0. Recomendamos o uso do rótulo istio.io/rev=$revision.

    Para execute uma canary release, consulte Usar canary release para aumentar a estabilidade da atualização.

Caminhos, métodos e processos de atualização

Caminhos de atualização

O exemplo a seguir utiliza uma atualização da v1.16 para a v1.18. Selecione seu caminho de atualização com base no seu ambiente.

Versão inicial

Versão de destino

Método de atualização

1.16.4.93

1.17.2.42

Atualização no local ou canary release

1.17.2.42

1.18.0.158

Atualização no local ou canary release

1.16.4.93

1.18.0.158

Canary release

Métodos de atualização

Processo de atualização

Confirme a versão de destino e o método de atualização, e revise as precauções antes de prosseguir.

image

Procedimento

Atualização no local

  1. Faça login no console do ASM. No painel de navegação à esquerda, escolha Service Mesh > Mesh Management.

  2. Na página Mesh Management, clique em nome da instância do ASM. No painel de navegação à esquerda, escolha ASM Instance > Upgrade Management.

  3. Na página Upgrade Management, clique em aba In-place Upgrades. Clique em Perform Upgrade Precheck. Na caixa de diálogo Note exibida, clique em OK.

  4. Após a aprovação na verificação prévia, clique em Upgrade. Na caixa de diálogo Note, clique em OK.

  5. Na seção Data Plane, localize a coluna Upgrade, selecione o gateway de destino e clique em Upgrade Gateway. Na caixa de diálogo Note, clique em OK.

  6. Reinicie as cargas de trabalho conforme necessário. Reimplantar cargas de trabalho.

Canary release

Usar canary release para aumentar a estabilidade da atualização.

Perguntas frequentes sobre atualizações

Quando uma versão canary é alternada para a versão oficial, o sidecar injetado no serviço implantado anteriormente permanece na versão anterior. Como atualizo o sidecar para a nova versão?

Na página Upgrade Management, clique em aba Canary Upgrade e, em seguida, clique em aba Data plane. Na seção Workload to be upgraded, localize a carga de trabalho de destino e clique em Rolling Upgrade na coluna Actions para acionar uma atualização gradual para a implantação do serviço.

Uma atualização no local afeta o tráfego dos serviços existentes?

Uma atualização no local afeta apenas o plano de controle, não o tráfego no plano de dados.

Quantas vezes uma instância do ASM precisa ser atualizada para atingir a versão de destino?

Atualizações no local suportam apenas versões principais adjacentes. Canary releases suportam atualizações através de uma versão secundária. Calcule o número de atualizações necessárias com base nas suas versões atual e de destino.

Posso selecionar qualquer método de atualização para cada versão de uma instância do ASM?

Instâncias anteriores à 1.16.4.91 suportam apenas atualizações no local. Instâncias da versão 1.16.4.91 ou posterior suportam tanto atualizações no local quanto canary releases.

Após a atualização de uma instância do ASM, para qual versão o cluster ACK correspondente precisa ser atualizado?

Verifique a Compatibilidade de versões do ASM e ACK e atualize o cluster conforme necessário. Atualizar manualmente um cluster.

Documentos relacionados

  • Diagnostique o mesh em busca de problemas como incompatibilidades de versão de componentes, conflitos de porta de serviço e conflitos de serviço virtual. Usar diagnósticos de mesh do ASM.

  • A plataforma AIOps para contêineres fornece diagnóstico de falhas com um clique para nós, pods, Services, Ingress, memória e rede. Usar diagnósticos de cluster.

  • Últimas atualizações de recursos do ASM: Notas de versão.