Kubernetes 1.37: adotar DRA por funcionalidade, não pelo rótulo

Ler o estado de cada capacidade

O artigo oficial de 3 de setembro descreve as novidades DRA em Kubernetes 1.37. Entre elas, o suporte a recursos estendidos passa a estável, permitindo ao driver DRA satisfazer pedidos tradicionais sem um ResourceClaim declarado pela carga. Taints e tolerations de dispositivos também estão estáveis.

A seleção seguinte não é uma lista completa da versão. Serve para impedir que funcionalidades com contratos diferentes sejam aprovadas em conjunto.

O cluster precisa de mais do que a versão

A documentação DRA atribui responsabilidades ao proprietário dos dispositivos, ao administrador do cluster e ao operador da carga. Os drivers compatíveis publicam ResourceSlices, acompanham alterações de capacidade e preparam dispositivos. O operador da carga usa os mecanismos de pedido apropriados. A existência da API não confirma que o driver instalado cumpre esse percurso.

A mesma documentação explicita uma limitação: o scheduler não suporta preempção de recursos DRA. Uma carga de prioridade superior pode ficar pendente enquanto o dispositivo está ocupado. Na nossa interpretação, esse comportamento deve entrar nos critérios de serviço antes de prometer capacidade prioritária a um cliente.

Ensaio de aceitação antes da expansão

Perspetiva Velqory: escolha primeiro uma carga e uma capacidade. O plano seguinte é uma proposta de ensaio em staging; não é um benchmark nem um teste executado neste artigo.

• Registe versão do cluster, driver, runtime, modelo de dispositivo e feature gates necessários. Confirme o suporte declarado para a combinação concreta, incluindo o formato de pedido escolhido.
• Capture o comportamento de referência da carga: dispositivo atribuído, tempo até arrancar, resultado funcional e libertação após terminar. Use o mesmo conjunto de dados no candidato.
• Peça um recurso existente, um indisponível e um incompatível. Para cada caso, escreva antecipadamente o resultado esperado: execução correta ou pendência explicável, nunca alocação silenciosa diferente da autorizada.
• Exerça a manutenção de um dispositivo num ambiente isolado. Valide o efeito das tolerâncias e a recuperação da carga; não experimente expulsões numa produção sem plano e janela autorizada.
• Confirme que o encerramento da carga liberta o que deve libertar e que um novo pedido consegue usar a capacidade. Preserve eventos e estados suficientes para explicar qualquer reserva remanescente.
• Defina o caminho de retorno para o driver e a configuração previamente aprovados, com as cargas quiescidas quando necessário. Se não consegue demonstrar esse retorno em teste, não expanda a migração.

Compatibilidade não é apenas DRA

A política oficial de version skew define relações entre componentes e avisa que ferramentas de instalação podem impor restrições adicionais. O kubelet não deve ser mais recente do que o kube-apiserver; as regras também condicionam a ordem de atualização. O projeto não admite saltar versões minor do API server na atualização.

A recomendação operacional é manter duas aprovações separadas: atualização do cluster e mudança do percurso de alocação. Assim, uma falha tem uma hipótese mais clara para investigar. Não interprete o estado estável de uma capacidade como garantia de compatibilidade do seu dispositivo, driver ou aplicação.

Critério de saída e revisão

A expansão proposta só acontece quando casos aprovados funcionam, casos indisponíveis ficam diagnosticáveis e o retorno foi demonstrado. Uma funcionalidade beta ou alpha exige ainda uma decisão explícita sobre o risco aceite e a ativação necessária.

Âmbito: Kubernetes 1.37 e as capacidades DRA selecionadas, não todos os clusters geridos ou fornecedores de hardware. Revalidar quando mudar a release, o driver, o dispositivo, os gates ou a documentação de suporte. Os estados apresentados são os confirmados em 6 de setembro de 2026.