Blog/Artigos · Cloud e Plataforma
O modelo declarativo, o control loop que se autocura, os objetos essenciais, e a pergunta honesta de quando não usar.
No livro de Yonah, em plena tempestade, é o rav hachovel, o comandante do navio, quem desce ao porão para acordar quem dorme e conduzir a embarcação pela crise. Kubernetes é grego para exatamente isso, timoneiro, e o nome descreve o trabalho com precisão. Numa frota de contêineres que sobem, caem, escalam e se movem entre máquinas o tempo todo, alguém precisa segurar o leme: garantir que a quantidade certa está no ar, substituir o que morreu, redistribuir a carga quando um nó cai. Você não pilota cada contêiner à mão; você declara o destino, o estado desejado, e o timoneiro conduz a frota até lá, e a mantém lá, mesmo na tempestade.
Contêiner resolveu empacotar a aplicação com tudo de que ela precisa, mas criou um problema novo em escala: quem cuida de centenas ou milhares deles? Quem garante que há sempre cinco réplicas no ar, sobe outra quando uma morre, distribui a carga entre as máquinas, e faz isso sem alguém de plantão apertando botão? Antes do Kubernetes, isso era script frágil e vigília humana. O Kubernetes, nascido de dez anos de experiência do Google orquestrando contêineres e doado à CNCF, virou o padrão da indústria para esse trabalho.
A ideia que o torna poderoso é a mesma do IaC e do GitOps: declarativo. Você não manda subir três réplicas; você declara que quer três réplicas, e o Kubernetes cuida de que sempre haja três, recriando as que caírem. Você não escolhe em qual máquina cada contêiner roda; você declara requisitos e o escalonador decide. Essa inversão, de mandar o passo para declarar o destino, é o que permite operar em escala sem enlouquecer. O operador para de pilotar cada contêiner e passa a descrever a frota que quer, deixando o timoneiro conduzir.
O coração do Kubernetes é o control loop, o mesmo laço de reconciliação que o GitOps depois estendeu. Um conjunto de controladores observa sem parar a diferença entre o estado desejado, o que você declarou, e o estado atual, o que existe no cluster, e age para fechar essa diferença. Um pod morreu e as réplicas caíram de cinco para quatro? O controlador sobe uma nova. Um nó inteiro caiu? Os pods dele são recriados em outro nó. Ninguém precisa reagir; o laço reage, e é isso que se chama autocura.
Essa autocura muda a expectativa de operação. Falha de um contêiner deixa de ser incidente e vira rotina silenciosa: o Kubernetes trata contêiner como gado, não bicho de estimação, e substitui o que adoece sem cerimônia. O plantão para de ser acordado por um processo que caiu, porque o processo que cai é reposto sozinho. O que sobra para o humano é o que o laço não resolve: a falha que se repete, o estado desejado errado, o recurso que acaba. A autocura não elimina a operação; ela sobe o nível dela, do apertar botão para o entender padrão.
Operar Kubernetes é falar a língua dos seus objetos, e um punhado deles cobre a maior parte do dia a dia. O Pod é a unidade que roda; raramente se cria um sozinho. O Deployment gerencia réplicas de pods e cuida da atualização sem derrubar o serviço. O Service dá um endereço estável a um conjunto de pods que vive e morre. O Ingress expõe o serviço para fora, roteando o tráfego externo. O ConfigMap e o Secret separam configuração e segredo do código. Juntos, esses objetos descrevem uma aplicação inteira de forma declarativa.
A elegância é que tudo é o mesmo padrão: um objeto declara o desejado, um controlador o realiza. Isso torna o Kubernetes extensível de um jeito raro: você pode criar seus próprios objetos, os Custom Resources, com seus próprios controladores, o padrão Operator, e ensinar o cluster a gerenciar um banco de dados ou um certificado com a mesma lógica declarativa com que gerencia um pod. É por isso que o ecossistema explodiu: quase tudo em nuvem hoje tem um Operator que traz aquele recurso para a língua declarativa do Kubernetes. O vocabulário é pequeno; a gramática que o combina é o que dá o poder.
Kubernetes é poderoso e é complexo, e negar a segunda parte é vender ilusão. Rede, armazenamento, segurança, atualização do próprio cluster, cada uma é um mundo, e a curva de aprendizado é íngreme. Muita empresa adotou Kubernetes por moda, para rodar três serviços que caberiam confortavelmente numa plataforma gerenciada mais simples, e trocou um problema pequeno por uma operação grande. A pergunta madura não é como uso Kubernetes, é preciso mesmo de Kubernetes para este caso, e ela precisa ser feita antes, não depois de meses de dor.
A resposta depende de escala e de time. Se são poucos serviços, sem necessidade de orquestração sofisticada, uma opção gerenciada, contêiner como serviço, serverless, plataforma de aplicação, entrega o mesmo com uma fração da carga cognitiva. Kubernetes rende quando há muitos serviços, necessidade real de orquestração fina, e um time, ou uma plataforma por cima, que absorva a complexidade para que os desenvolvedores não a sintam. E quando ele é a escolha certa, a decisão seguinte é quase sempre a versão gerenciada, EKS, GKE, AKS, para não gastar o time operando o painel de controle do cluster em vez do negócio.
A maturidade com Kubernetes vai de operar o cluster à mão a escondê-lo por completo do desenvolvedor. No começo é subir e manter o próprio cluster, gastando o time no painel de controle. No meio é a versão gerenciada, que devolve esse tempo ao negócio. No topo é a plataforma interna por cima do Kubernetes, com golden path, GitOps para deploy e autoscaling automático, de modo que o desenvolvedor colha o poder da orquestração sem sentir a complexidade. O objetivo final não é dominar Kubernetes; é fazê-lo desaparecer sob a estrada aplainada da plataforma.
Kubernetes é o chão sobre o qual boa parte deste eixo se apoia. O GitOps reconcilia o estado dele; o Service Mesh gerencia o tráfego entre os pods; o autoscaling ajusta a frota à demanda; o Policy as Code barra o manifesto inseguro na admissão. Ele é o timoneiro, e os outros são a tripulação especializada que o cerca. Saber conduzir a frota é útil; saber quando não precisar de frota alguma, e quando escondê-la sob uma plataforma, é o que separa quem usa Kubernetes de quem o domina.
Kubernetes é o timoneiro que conduz a frota de contêineres pelo estado desejado: você declara o destino e o control loop mantém a frota lá, autocurando o que cai. Os objetos, pod, deployment, service, ingress, dão o vocabulário, e os Operators o estendem a quase tudo. Mas o poder vem com complexidade real, e a maturidade começa na pergunta honesta de quando não içar essa vela, e segue em escondê-la sob uma plataforma quando ela é a escolha certa. A IA traduz o erro e dimensiona o recurso. Decidir se o caso justifica a frota, porém, continua sendo julgamento de arquitetura de quem responde pela operação.
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
Cloud e Plataformaשׁוּב
GitOps faz do Git a única fonte de verdade do que roda, e um controlador puxa a realidade de volta ao que está escrito, sem parar. Deploy vira commit, rollback vira reverter, e o drift se corrige sozinho. O repositório declara, o laço reconcilia.
Cloud e Plataformaהַרְחָבָה
Capacidade fixa erra dos dois lados: desperdiça no vale e satura no pico. Autoscaling alarga a tenda quando a demanda cresce e a recolhe quando ela cai, pagando pelo que se usa. O segredo está em escalar na hora certa, nem tarde a ponto de saturar, nem cedo a ponto de desperdiçar.
