Manutenção de Kubernetes on‑prem e na nuvem: upgrades, etcd e o custo invisível

O cluster Kubernetes é frequentemente vendido como destino final de modernização. Na operação, ele é um sistema distribuído que exige patching, capacidade planejada e continuidade de conhecimento no time — sob pena de incidentes em horários inconvenientes.

On‑premises

Upgrades de control plane coordenados com janela de manutenção, validação de CNI e CSI, e compatibilidade com SO dos nós. etcd como ponto sensível: backup e restauração testados de verdade, não só job agendado “verde”. Hardware heterogêneo e firmware desatualizado geram falhas difíceis de correlacionar com métricas de aplicação.

Na nuvem gerenciada

Menos peso em control plane, mas node groups, add‑ons, quotas e IAM continuam sob responsabilidade do cliente. Versões deprecadas de API extensions/v1beta1 ainda aparecem em manifests antigos e quebram upgrades silenciosamente até o próximo deploy.

Investimento em plataforma

Runbooks, simulacros de disaster recovery, ownership claro de cluster per team vs plataforma central, e FinOps para workloads que poderiam ser autoscaled ou movidos para modelo mais barato. Manutenção não é overhead — é parte do produto interno de plataforma.