Kubernetes 1.14 leva Windows nodes ao suporte estável

O Kubernetes 1.14 chega como a primeira versão do projeto em 2019 e traz um marco importante para ambientes corporativos: suporte estável a Windows nodes e Windows containers.¹ A mudança amplia o alcance do orquestrador para workloads que não podem simplesmente ser reescritos para Linux.

A versão reúne 31 melhorias, com 10 recursos movendo para estável, 12 em beta e 7 novos.¹ A lista inclui kubectl plugins em GA, persistent local volumes em GA, PID limiting em beta e endurecimento de RBAC em pontos de descoberta. Ainda assim, Windows é o sinal mais visível para empresas com portfólios mistos.

Clusters heterogêneos ficam mais realistas

Segundo a Microsoft, o suporte a Windows Server nodes graduou de beta para estável com Kubernetes 1.14.² Antes, worker nodes em Kubernetes eram essencialmente Linux para execução de containers Linux. Com a evolução do suporte a Windows Server, um cluster pode combinar workers Linux e Windows, mantendo o control plane em Linux.

Essa distinção importa. Kubernetes não transforma aplicações Windows em aplicações Linux. Ele oferece um plano comum de orquestração para workloads diferentes. Equipes ainda precisam lidar com imagens compatíveis, versões de Windows Server, rede, storage, observabilidade e diferenças de comportamento entre sistemas operacionais.

Para empresas, o ganho está em padronizar parte da operação. Deploy, scheduling, health checks, service discovery e práticas de plataforma podem se aproximar, mesmo quando o runtime de aplicação continua dependente de Windows. Isso reduz ilhas operacionais sem prometer uniformidade total.

Operação ganha recursos além do Windows

kubectl plugins em GA permitem que equipes publiquem subcomandos customizados como binários no PATH, seguindo uma mecânica parecida com plugins do Git.¹ É um detalhe importante para plataformas internas: extensões operacionais podem ficar mais fáceis de distribuir sem alterar o core do kubectl.

Persistent local volumes também chegam a GA, oferecendo forma estável de usar armazenamento local ligado ao nó para workloads que se beneficiam de latência menor ou custo reduzido, como bancos distribuídos e sistemas de arquivos.¹ Isso amplia opções para aplicações stateful, embora exija disciplina com scheduling e tolerância a falhas.

PID limiting em beta responde a um problema clássico de estabilidade: processos podem esgotar PIDs do host e afetar kubelet, runtime e outros pods. Limitar PIDs por pod ajuda a conter impacto de workload mal comportado.

Adoção depende de inventário de aplicações

Windows nodes estáveis não significam migração automática. Times precisam identificar quais aplicações Windows realmente se beneficiam de containerização, quais dependem de interface gráfica, drivers, estado local ou integrações difíceis, e quais podem ser modernizadas por etapas.

Também é necessário ajustar pipelines. Build de imagens Windows, scanning, registry, testes e atualização de base images têm características próprias. Misturar Linux e Windows no mesmo cluster exige políticas claras para node selectors, tolerations, namespaces e observabilidade.

Kubernetes 1.14 torna a conversa mais concreta. O projeto passa a acomodar melhor uma realidade empresarial comum: o futuro cloud native precisa conviver com workloads existentes enquanto novos serviços seguem padrões modernos. A maturidade está em operar essa convivência sem esconder suas diferenças.