Quem usa GPU costuma cair em um trade-off ruim: um cluster Kubernetes por time significa pagar por um control plane por equipe, enquanto um único cluster compartilhado entrega isolamento fraco. Em ambos os casos, o Kubernetes distribui GPUs como placas inteiras, então um pod que precisa de 4 GB de uma GPU de 80 GB ainda bloqueia a placa toda. O post apresenta uma saída combinando dois projetos open source. O Kamaji executa o control plane Kubernetes de cada tenant como pods dentro de um único cluster de gerenciamento. O HAMi permite que pods solicitem uma fatia da GPU (memória em MB, compute em %) e agrupa vários pods na mesma placa. O autor montou tudo em uma única máquina, sem GPU física, usando o mock device plugin do HAMi para simular as placas. O resultado foram dois clusters de tenant totalmente isolados, cada um agendando workloads com GPU fracionada via HAMi, com os oito testes passando. O texto detalha versões, comandos, erros encontrados e correções, em cinco etapas: cluster de gerenciamento com cert-manager e MetalLB, instalação do Kamaji, criação dos Tenant Control Planes, ingresso de um worker node com kubeadm e instalação do HAMi com GPUs simuladas no tenant.
CEVIU News
As melhores notícias de tecnologia, curadas diariamente para quem vive tech.
1108 notícias encontradas
O GitHub lançou o Actions Runner Controller 0.15.0. A versão passa a enviar requisições de patch menores e move a agregação do status dos runners para as métricas, o que reduz o número de atualizações na API do Kubernetes.
Um delete em cascata grande pode fazer uma migração de schema de rotina virar indisponibilidade: a migração mantém locks enquanto espera, e as novas queries se acumulam na fila atrás dela. Uma alternativa é usar soft deletes seguidos de uma limpeza em segundo plano com limites, o que mantém as transações menores. O texto, publicado no blog da PlanetScale, ainda aponta outros problemas, como foreign keys sem índice e logical replication.
As chaves privadas de oito certificados intermediários da eMudhra, amplamente confiáveis, foram comprometidas em 19 de outubro. Com isso, atacantes podem forjar certificados para qualquer domínio. A Cloudflare já aplicou correções em seus produtos de CDN, Zero Trust e Tunnel. Para continuarem protegidos, os clientes precisam atualizar o Cloudflare One Client e o app 1.1.1.1 para versões específicas.
A Grafana Labs anunciou atualizações do Grafana Cloud que abrangem operações com IA, controle de custos e contexto de full-stack. O Assistant Watchers atingiu general availability, clientes do Adaptive Telemetry relatam redução média de 30% a 50% nos gastos, e o Grafana Marketplace foi lançado com mais de 30 plugins.
Duas vulnerabilidades críticas de execução remota de código (RCE) no PHP, identificadas como CVE-2026-109618 e CVE-2026-109619, foram divulgadas publicamente em 21 de outubro. Já existe código de exploit de prova de conceito disponível, e as falhas afetam todas as versões do PHP a partir do PHP 5. A DigitalOcean está aplicando patches automaticamente nas instâncias WordPress do produto gerenciado Cloudways. Quem executa PHP em Droplets ou em outros serviços não gerenciados precisa atualizar imediatamente para o PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12. Não há patches para o PHP 8.1 ou versões anteriores, o que deixa essas versões sem correção.
O Harness AI Budgets converte políticas de custo de IA em limites semanais de gasto aplicados de forma obrigatória, que podem ser definidos por equipe, desenvolvedor, modelo ou projeto. Quando o consumo chega a 100% do limite, o acesso é pausado até a renovação semanal ou até que um aumento seja aprovado. Em um teste interno da própria Harness, o gasto semanal com IA por desenvolvedor caiu cerca de 37%.
Nathen Harvey, da equipe DORA do Google Cloud, apresentou os resultados da pesquisa de 2025, que reuniu quase 5.000 respondentes, dos quais cerca de 90% usam IA profissionalmente. Segundo ele, a IA amplifica tanto os pontos fortes quanto as disfunções já presentes nas organizações. Na apresentação, Harvey também mostra o DORA AI Capabilities Model.
Engenheiros da Radar testaram se adicionar contexto a coding agents melhora o diagnóstico de falhas em Kubernetes. Em 50 cenários de falha, os agentes com contexto chegaram a um diagnóstico correto em até dois minutos em 86% dos casos, contra 60% dos agentes que usavam um shell padrão. A precisão melhorou só um pouco com o contexto, mas o ganho de tempo foi significativo. O teste usou o Claude Code e o benchmark SREGym, da Microsoft, em um cluster Amazon EKS em execução.
Os workflow lockfiles do GitHub Actions fixam actions e suas dependências transitivas em commits revisados, sem abrir mão de tags legíveis nos arquivos de workflow. A public preview traz uma extensão do GitHub CLI para gerar os lockfiles, integração com o Dependabot para atualizá-los e políticas que exigem o uso dos lockfiles nos workflows.
Jesse Suen, da Akuity, descreve um ambiente com mais de 200 clusters em que cada merge era sincronizado em todos os lugares, sem nenhum gate. Segundo ele, as ferramentas de sync não cuidam do acompanhamento de releases nem das decisões de promoção. Por isso, Suen recomenda uma promoção em etapas, que avança em ondas e é interrompida quando as verificações falham.
A AWS anunciou a general availability do AWS Continuum para vulnerabilidades de código. O serviço de segurança encontra e valida vulnerabilidades e entrega correções como patches automatizáveis ou pull requests nos repositórios. Ele confirma quais achados são explotáveis no ambiente, classifica os problemas por impacto no negócio e propõe uma correção para cada um. Toda remediação começa em um modo em que o Continuum propõe e uma pessoa aprova antes de ir para produção. No futuro, será possível definir quais ações ele poderá executar sozinho, dentro de guardrails definidos pelo usuário. Segundo a AWS, com modelos de IA frontier, agentes maliciosos transformam a divulgação de uma vulnerabilidade em exploit funcional em minutos, enquanto as ferramentas que aceleram o desenvolvimento aumentam o volume de achados. Scanners em grandes ambientes geram milhares de achados por dia, e muitos não exigem ação: podem estar inalcançáveis, não explotáveis ou já mitigados por um controle de runtime. Scores genéricos de severidade não mostram o que um atacante realmente alcança; confirmar a explotabilidade levava horas de investigação manual, e entregar uma correção com segurança levava dias de coordenação entre times. O Continuum monta um context graph a partir dos repositórios e do ambiente AWS, usando um collector configurado na conta e na Region onde o código roda. Ele coleta detalhes como recursos do AWS Config e configuração de rede para avaliar se a vulnerabilidade é alcançável pela rede e o que um atacante poderia atingir. Assim, identifica sistemas críticos, como bases de dados de clientes, pipelines de pagamento e serviços de autenticação, e prioriza cada problema pela proximidade do attack path em relação a eles. Cada achado é analisado com o contexto do código e do ambiente e recebe um nível de evidência. Nos casos reproduzíveis, o exploit roda em um sandbox isolado, com proof-of-concept e passos de reprodução anexados. O serviço entrega o attack path, a análise do código-fonte e uma avaliação de blast radius, e verifica se as defesas existentes detectariam e barrariam o caminho validado. Para cada problema confirmado, gera uma correção (patch de código, atualização de dependência ou mudança de configuração) e a abre como pull request no repositório conectado. Toda correção exige aprovação humana: o time revisa e faz o merge. No futuro, será possível liberar a aplicação automática de classes específicas de correção após critérios de confiança, como cobertura de testes, limites de escopo e taxa histórica de sucesso. Para configurar, conecta-se uma fonte de código, via integração com GitHub ou bucket do Amazon S3, e cria-se um ambiente que faz o scan em uma agenda definida.
Mesmo equipes de segurança que adotaram uma imagem base hardened muitas vezes não sabem o que roda por cima dela. Em pesquisa recente com 250 líderes de DevSecOps da América do Norte, 91% apontaram a visibilidade dos componentes dos containers como o maior ponto cego: não a imagem base, mas tudo o que é adicionado sobre ela. Além disso, 90% disseram que suas equipes ainda executam imagens públicas levemente modificadas, com pouco ou nenhum hardening. O cenário pesa mais porque assistentes de código com IA adicionam dependências mais rápido do que as equipes conseguem revisar, os bancos de dados de vulnerabilidades não acompanham o volume de submissões, e exigências regulatórias como o EU Cyber Resilience Act elevam as expectativas sobre tratamento de vulnerabilidades, remediação e transparência na cadeia de suprimentos de software. Nesse contexto, Docker, Inc. e ActiveState anunciaram uma parceria de revenda que une os Docker Hardened Images (DHI) aos pacotes open source curados da ActiveState, para proteger tanto a base do container quanto as dependências adicionadas sobre ela. O DHI oferece imagens minimalistas e seguras por padrão: mais de 4.000 imagens construídas a partir do código-fonte, quase zero CVEs, SBOMs assinados e proveniência SLSA Build Level 3. O catálogo é gratuito e open source sob Apache 2.0, com camadas de produção respaldadas por SLA de 7 dias para CVEs críticas e de alta severidade. Os componentes curados da ActiveState cobrem mais de uma dúzia de ecossistemas de linguagens, incluindo Python, JavaScript, Java, Perl, Tcl e Ruby. Eles são construídos a partir do código-fonte, mantidos e corrigidos continuamente conforme SLAs contratuais, e entregues pelos gerenciadores de pacotes, pipelines, IDEs e ferramentas de código com IA que as equipes já usam. Segundo o anúncio, o DHI traz superfície de ataque 95% menor, e a ActiveState entrega 95% menos CVEs e remediação 90% mais rápida que o open source da comunidade, com SLA de 5 dias para vulnerabilidades críticas. A parceria já está disponível.
Ao ativar a telemetria de um agente de IA de programação, o volume de texto é enorme: caro de armazenar e difícil de interpretar. Como tudo é nativo do OpenTelemetry, dá para moldar esses dados no Collector antes de enviá-los ao backend. A pergunta passa a ser o que realmente é necessário. O autor deu ao Claude Code uma tarefa pequena: corrigir dois testes que falhavam e adicionar alguns testes de borda. Com todas as flags de conteúdo ativadas, essa única execução gerou 181 registros de telemetria e 289 KB de JSON. O que ele precisava eram contadores ou atributos curtos, sem prompts, corpos de arquivo ou diffs. Se nenhum dashboard, alerta ou consulta lê um campo, isso não é observability: é armazenamento que você paga para indexar. O volume vem do loop do agente. Cada interação gera um span claude_code.interaction, com um span filho llm_request por chamada ao modelo e um span filho por chamada de ferramenta. Com OTEL_LOG_TOOL_CONTENT ativado, cada span de ferramenta recebe um evento tool.output com o retorno da ferramenta; no caso da Read, o arquivo inteiro. Os logs repetem o conteúdo em tool_parameters, o que armazena tudo duas vezes. Nas métricas, cada data point carrega session.id, user.id, user.email e dois ids de conta, e cada nova sessão cria séries temporais novas: 25 sessões geraram 300 séries para oito métricas. A instrumentação padrão serve para depurar uma execução, não para operar uma frota, e cabe ao pipeline corrigir isso. A arquitetura usa um receiver OTLP que alimenta dois pipelines por sinal: um raw (controle, apenas com service.name e batch processor) e um otimizado, ambos enviando ao mesmo container Grafana LGTM. Um dashboard compara cardinalidade, bytes por minuto e contagem de registros. Nos logs, o autor descarta o evento api_request (cerca de um quarto dos registros), remove seis atributos (incluindo tool_parameters), aplica hash em session.id e user.id, limita error a 256 caracteres e trunca o digest a 16 caracteres hexadecimais, reduzindo os bytes de log aproximadamente pela metade. Nas métricas, remover seis atributos derruba 300 séries para 12, independentemente das flags de conteúdo. Como o Claude Code exporta temporalidade delta e o Prometheus espera cumulativa, é preciso converter após somar as sessões.
O GitHub está reconstruindo a infraestrutura de Git sem tirar a plataforma do ar, preparando a base para o desenvolvimento de software em escala de agentes. O blog também destaca o lançamento do Git 2.56, com as principais novidades desde a versão anterior, e um guia para automatizar o acesso seguro e a higiene de repositórios em organizações compartilhadas, revisando outside collaborators e arquivando repositórios inativos. Outro relato mostra como o histórico de estrelas passou de 2.500 requisições para 24, com uma nova API que entrega tendências sem expor identidades nem sobrecarregar o banco. O GitHub Universe acontece em 28 e 29 de outubro, em San Francisco e online.
Depois do Agent Baseline, arquitetura aberta criada com Snyk e Keycard em julho, a Docker publicou a Secure Software Factory, que aplica esses resultados de segurança ao workflow de agentes de IA: receber o pedido, alterar código, rodar testes e entregar para revisão humana. O documento cobre controles por etapa, identidade, supply chain, rede, isolamento de runtime e um modelo de maturidade em três níveis. A premissa: quanto mais autonomia, menos o agente pode se autorregular, então os controles devem viver no ambiente. Os Docker Sandboxes, microVMs isoladas, limitam arquivos, rede e credenciais de forma determinística.
O BAND lançou um kit oficial para Docker Sandboxes (docker.io/bandhq/band-python-kit:latest) que conecta agentes isolados em microVMs a salas de colaboração com humanos e outros agentes, locais ou na nuvem. Com identidades persistentes, @mentions, histórico e eventos de ferramentas visíveis, cada agente traz seu modelo e infraestrutura. Toda a conexão é de saída via WebSocket e API, e as chaves ficam no host, com o agente vendo só placeholders. No exemplo, o Repo Doctor, com Claude, corrige testes de um projeto Python quebrado.
Cloudflare e VoidZero Otimizam TypeScript com Port para Rust, Impulsionando Performance e Eficiência
A Cloudflare e a VoidZero unem forças no projeto tsrs, uma ambiciosa iniciativa para reescrever o compilador TypeScript em Rust. Testes preliminares revelam um avanço notável: o tsrs demonstra ser até oito vezes mais rápido e consumir cerca de 70% menos memória em comparação com o TypeScript 7.0. Essa colaboração não visa apenas performance; a equipe trabalha em estreita parceria com o time oficial do TypeScript para assegurar total compatibilidade e adesão ao design da linguagem. A adoção de Rust abre portas para que o compilador opere em WebAssembly, expandindo seu uso para ambientes de desenvolvimento no navegador e dispositivos embarcados, promovendo uma nova era de eficiência para desenvolvedores.
A AWS acaba de apresentar o Amazon ECS Gateway, uma solução que visa simplificar a gestão de tráfego de ingresso para cargas de trabalho conteinerizadas. Esta novidade automatiza o provisionamento de balanceadores de carga (ALBs) e certificados, permitindo que até 25 serviços ECS compartilhem um único ALB, otimizando recursos e custos de infraestrutura. Disponível em todas as regiões comerciais da AWS, o ECS Gateway não possui custo adicional direto, mas os usuários serão cobrados pelos recursos subjacentes que forem provisionados em suas contas. Essa funcionalidade é um avanço significativo para equipes de DevOps, que buscam eficiência e escalabilidade na orquestração de contêineres.
O Stack Overflow for Agents, desenvolvido em tempo recorde por apenas dois engenheiros utilizando o Codex, registrou um aumento expressivo de cadastros após a integração com um plugin do ChatGPT. Essa sinergia não só impulsionou o crescimento da base de usuários, mas também demonstrou o poder da IA no desenvolvimento ágil, reduzindo o tempo de criação de conectores empresariais de semanas para apenas quatro dias.