Argo Rollouts 1.10 RC: Foco em Confiabilidade e Eficiência Operacional
Aprofundamento CEVIU
Aprofundamento
O release candidate 1.10 do Argo Rollouts chega reforçando a confiabilidade e eficiência operacional em ambientes Kubernetes. A reconciliação de rollouts agora é mais consistente, respondendo de forma previsível a ações manuais como pausar ou abortar um deploy. Para análise de Jobs, o sistema detecta falhas de inicialização como Inconclusivas, evitando que rollouts problemáticos avancem.
Houve também uma melhora substancial na estabilidade do Istio, corrigindo problemas de timing que causavam erros de tráfego durante canaries e rollbacks. Para equipes que operam clusters maiores, o controlador do Argo Rollouts usa menos memória e CPU. A versão adiciona suporte para Microsoft Teams (via Workflows) e Nats.io como canais de notificação, expandindo as opções de observabilidade.
O que mudou
Esta versão 1.10 do Argo Rollouts alinha-se com o projeto irmão Argo CD em algumas frentes importantes. O suporte a novos canais de notificação, como o Microsoft Teams via Workflows Connector, é um exemplo direto. Esta funcionalidade, que substitui o antigo Office 365 Connectors, já havia sido introduzida no Argo CD v3.4 Release Candidate, anunciado em 20 de março de 2026. Agora, o Argo Rollouts também se beneficia dessa integração, garantindo que ambos os projetos usem a mesma engine de notificação, simplificando a gestão e manutenção para equipes que utilizam a suíte Argo.
Outras melhorias de alinhamento incluem a adoção do pnpm para o dashboard UI, assim como o Argo CD já fez, e a implementação de um bot de cherry-pick para backports automáticos, otimizando o fluxo de trabalho e reduzindo o esforço manual para manter a compatibilidade entre as versões.
Por que isso importa
Para engenheiros de plataforma e times de DevOps, o Argo Rollouts 1.10 RC é crucial. As melhorias na confiabilidade da reconciliação de rollouts e na detecção de falhas em Jobs diretamente impactam a segurança e a estabilidade das entregas contínuas. Menos erros e um comportamento mais previsível dos deploys significam menos incidentes em produção e ciclos de feedback mais rápidos.
A otimização de recursos do controlador e o suporte a Traefik v3 refletem a necessidade de eficiência e modernização da infraestrutura. A expansão dos plugins de roteamento de tráfego, com recursos como ping-pong services e traffic mirroring, oferece mais flexibilidade e controle avançado sobre as estratégias de lançamento, permitindo deploys com zero downtime para aplicações complexas e testes mais realistas sem impactar usuários. Tudo isso contribui para um ambiente operacional mais robusto e ágil.
Linha do tempo
Argo CD 3.3 traz exclusões mais seguras e otimizações para GitOps
Argo CD v3.4 Release Candidate Anunciado: suporte para Microsoft Teams Workflows
Crossplane v2.2 Lançado: Mais Capacidade, Confiabilidade e Observabilidade
Argo CD v3.5 Release Candidate introduz suporte a ApplicationSet na UI e melhorias de segurança
Argo CD 3.5 eleva nível de segurança em GitOps com mTLS e validação de commits
Amazon EKS introduz rollback de versão do Kubernetes para atualizações mais seguras
Argo Rollouts 1.10 RC: Foco em Confiabilidade e Eficiência Operacional
Perguntas frequentes
O que são os ping-pong services e por que são importantes?
Ping-pong services são um recurso que permite rollouts com zero downtime para conexões de longa duração, como gRPC ou conexões de banco de dados. Eles garantem que a transição entre versões de uma aplicação aconteça sem interrupções para os usuários finais, mesmo para serviços que não toleram interrupções no meio da requisição.
Como o Argo Rollouts 1.10 melhora a segurança na análise de Jobs?
A versão 1.10 corrige uma falha onde Jobs de análise que nem chegavam a iniciar eram erroneamente reportados como bem-sucedidos. Agora, esses casos são corretamente marcados como Inconclusivos, impedindo que rollouts defeituosos continuem e melhorando a confiabilidade das análises automáticas.
Quais são as implicações da atualização para Traefik v3?
O Argo Rollouts 1.10 assume Traefik v3 por padrão. Usuários que ainda utilizam Traefik v2 devem configurar explicitamente o controlador para usar a versão da API antiga, ou o Rollouts não conseguirá se comunicar com os recursos do Traefik. Esta é uma mudança importante a ser observada durante o upgrade.
Como o consumo de recursos do controlador foi otimizado?
O controlador agora gasta menos memória e CPU, especialmente em grandes clusters. Isso ocorre porque ele não monitora objetos Kubernetes desnecessários e lê objetos do seu cache interno de forma mais eficiente. Esta otimização impacta diretamente nos custos e na escalabilidade operacional.
Fontes
- blog.argoproj.iofonte original
- Categoria
- CEVIU DevOps
- Publicado
- 22 de julho de 2026
- Editoria
- CEVIU DevOps

