- Kubernetes liderou a inovação em orquestração de contêineres nos últimos 10 anos
- Foram observadas várias limitações e necessidades de melhoria na configuração em YAML, dependência de etcd e gerenciamento de pacotes com Helm
- Adoção de HCL, armazenamento plugável, um novo gerenciador de pacotes (KubePkg), IPv6 por padrão, entre outros são discutidos como elementos de mudança para o Kubernetes 2.0
- Embora a estrutura aberta atual também seja importante, os padrões e a definição de uma direção oficial têm impacto decisivo na inovação do ecossistema
- Fica claro que o Kubernetes precisa se tornar adequado para uma base mais ampla de usuários e organizações por meio de melhorias disruptivas contínuas
10 anos de Kubernetes: sucesso e limites
Início e crescimento
- Em 2012~2013, começaram a circular na comunidade de sysadmins rumores sobre o Borg, sistema interno de contêineres Linux do Google
- Em 2014, o Kubernetes foi lançado publicamente, e no começo até seu nome era difícil de pronunciar
- Microsoft, RedHat, IBM, Docker e outras grandes empresas aderiram rapidamente, e o Kubernetes começou a se consolidar como padrão do ecossistema
- Em 2015, com o lançamento da v1.0 e a criação da CNCF, formou-se de fato um ecossistema aberto
Principais pontos de inovação
Gerenciamento de contêineres em larga escala
- O Kubernetes trouxe escalabilidade para o desenvolvimento e a implantação de software baseado em contêineres
- Tornou possível a implantação em grande escala de ambientes idênticos, desde ambientes simples de desenvolvimento até milhares de servidores
- As organizações puderam encontrar um caminho para migrar de arquiteturas monolíticas para microsserviços distribuídos
Manutenção de baixo custo e autocura
- A administração de servidores mudou rapidamente da era "Simpsons" (apelidos para cada servidor, operação manual) para a era "UUID" (substituição completa, automação, sem estado)
- Os conceitos de vida útil da máquina e período de suporte do sistema operacional praticamente desapareceram, e em caso de falha a infraestrutura é reconstruída automaticamente com a "recriação do nó"
- Muitas habilidades de Linux deixaram de ser requisito essencial e passaram a ser apenas um diferencial desejável
Processamento em lote e gerenciamento de Jobs
- O processamento em lote, antes dependente de "máquinas dedicadas a cron", foi substituído por automação baseada em filas e mecanismos de retry
- Reinicialização automática em caso de falha e tratamento flexível elevaram bastante a eficiência operacional e a satisfação dos desenvolvedores
Service discovery e balanceamento de carga
- Em vez de hardcode de endereços IP, foi adotado um sistema de nomeação de serviços baseado em DNS interno
- APIs, IPs fixos e nomes de host simplificaram a conexão entre serviços e permitiram tratar serviços externos como se fossem internos
Kubernetes 2.0: propostas centrais de melhoria
De YAML para HCL, troca da linguagem de configuração
Limites do YAML
- O YAML é fácil de ler e parece melhor que JSON ou XML, mas tem problemas sérios como facilidade para gerar erros, ausência de tipagem e dificuldade de depuração
- Exemplos: o problema norueguês ("NO" interpretado como false), erros de indentação, confusão entre strings e números, entre muitos outros fatores de falha
Alternativa: adoção de HCL
- HCL (HashiCorp Configuration Language), formato padrão do Terraform, oferece recursos excelentes como tipagem forte, validação, funções e ramificações condicionais
- Uma parcela considerável dos clusters Kubernetes já usa HCL junto com Terraform
- O HCL tem recursos mais poderosos que o YAML, como segurança de tipos, redução de duplicação, configuração dinâmica, repetição, lógica condicional, excelente suporte a comentários, modularidade e validação
- Ainda há a questão da licença open source (MPL 2.0 → compatibilidade com Apache 2.0), mas o valor para melhorar a qualidade é suficiente
Exemplo: HCL vs YAML
- Graças às vantagens do HCL em tipagem, variáveis, funções, condicionais e loops, é possível prevenir erros de configuração, melhorar a manutenibilidade e garantir consistência mesmo em ambientes complexos
Suporte a opções para substituir o etcd
- O etcd é poderoso, mas em clusters pequenos ou ambientes com poucos recursos acaba consumindo recursos em excesso
- A necessidade de ampliar a flexibilidade do armazenamento padrão é levantada por meio do suporte oficial a backends plugáveis, como Kine
- Exemplo: k8s-dqlite: oferece uma camada de dados leve e flexível com SQLite distribuído + Raft
Além do Helm: um gerenciador de pacotes nativo
Limites do Helm
- O Helm é um caso em que uma solução improvisada virou padrão, mas traz vários problemas como complexidade de templates, dificuldade de depuração, conflitos de dependência/versão e validação insuficiente
- Na prática, surgem muitas dificuldades como duplicação de charts, incompatibilidade de versões, dificuldade de instalação entre namespaces, ausência de busca/metadados de charts, desrespeito a versionamento semântico e gerenciamento inseguro de CRDs
Proposta de um novo sistema de pacotes: KubePkg
- Gerenciamento abrangente de pacotes, dependências, versionamento semântico, segurança, ciclo de vida e metadados na forma de recursos do Kubernetes
- Inclui hooks de ciclo de vida sofisticados, estratégias de estado e backup/recuperação, configuração declarativa, processo de assinatura verificável, trilhas de auditoria e controle por políticas organizacionais
- O objetivo é herdar as vantagens dos gerenciadores de pacotes Linux para oferecer confiabilidade e consistência fortes na gestão real de infraestrutura
Requisitos principais
- Estrutura totalmente nativa de recursos do Kubernetes
- Suporte embutido a aplicações stateful
- Fortalecimento dos processos de assinatura/validação/varredura de segurança
- Configuração declarativa estruturada + validação de schema
- Controle de todo o ciclo de vida e suporte simples a Upgrade/Hook
- Resolução de dependências/versões no estilo Linux
- Histórico de mudanças e rastreabilidade de auditoria
- Possibilidade de aplicar políticas por organização
- UX familiar de gerenciamento de pacotes no estilo Linux
Mudança do padrão para IPv6
- Atualmente IPv6 e dualstack já são suportados, mas o padrão ainda é IPv4
- Isso ajuda a resolver comunicação entre clusters, problemas de NAT e escassez de IPs, além de trazer vantagens como estrutura de rede mais simples e IPSec embutido
- Em ambientes que exigem grande volume de IPs (exemplo: faixa /20, 40 nós, 30 pods por nó), os limites do IPv4 são atingidos rapidamente
- Há benefícios práticos claros, como simplificação da operação em ambientes públicos com IPv6, atração de usuários de cloud e redução da carga de administrar áreas privadas
Conclusão: a necessidade de mudar e o poder dos padrões
- Há quem diga "é uma plataforma aberta, então a comunidade que resolva", mas os padrões moldam o comportamento da indústria
- O Kubernetes 2.0 chegou a um ponto em que precisa de convicções oficiais, bom design e padrões fortes
- É um momento importante para um salto inovador à altura de sua posição como padrão da indústria e tendência dominante na operação de datacenters globais
- Em áreas como mobile e web, o ecossistema já passou repetidas vezes por transformações profundas impulsionadas por mudanças ousadas
- O Kubernetes também chegou ao momento de pensar no próximo passo por meio de um 2.0 marcante
2 comentários
Acho que os engenheiros capazes de configurar e operar um vanilla k8s, feito a partir da integração de open source, continuarão sendo minoria no futuro.
Assim como eram pouquíssimos os engenheiros que conseguiam operar o ecossistema Hadoop vanilla, em vez de comprá-lo empacotado em uma plataforma da Cloudera.
Comentários do Hacker News
Eu diria que o maior problema do Kubernetes é que ele não é um sistema que “simplesmente funciona”. Na prática, são poucos os engenheiros capazes de operá-lo sem atrito em produção, e montar e manter um cluster Kubernetes diretamente sobre VMs é ainda mais difícil. É por isso que startups serverless têm ganhado espaço ultimamente: espalhou-se a percepção de que isso (1) consome muito tempo, (2) é extremamente sujeito a erros e (3) tem alta chance de falhar em produção. Acho que no Kubernetes 2.0 deveríamos pensar em uma direção em que qualquer pessoa possa auto-hospedar uma plataforma de deploy com facilidade e usá-la com confiança, mantendo um núcleo de orquestração pequeno e poderoso. Estou desenvolvendo diretamente um orquestrador e plataforma de deploy chamado Rivet, e embora eu o apresente como a plataforma serverless open source Rivet, eu mesmo me pego pensando com frequência: “o que seria um Kubernetes 2.0?”. Também está aumentando o número de casos em que as pessoas adotam o Rivet para cenários além do que eu esperava. A maior força do Rivet é permitir desenvolver com facilidade funcionalidades no nível de um Kubernetes controller, o que o torna útil em vários cenários, como servidores de jogo, deploy por tenant, orquestração avançada de workloads, multitenancy, cobrança por tenant e design de operators robustos.
Essa perspectiva me causa certa antipatia. Talvez porque eu já tenha mais idade e seja um pouco cínico, mas é um padrão que vejo com frequência. A tecnologia X é pesada demais, então alguém cria a tecnologia Y dizendo “eu só quero rodar isso de forma simples no meu notebook”. Aí Y também fica popular e, quando passa a ser usada fora do notebook, precisa escalar e ganha todo tipo de recurso até ficar pesada também. Então aparece alguém dizendo “agora Y também está pesada demais” e repete exatamente o mesmo discurso. É como uma 'roda do tempo': uma história que se repete sem começo nem fim.
Na prática, o k3s (k8s leve) é realmente muito fácil de manter. Com atualização automática do k3s e regras adequadas de eviction, quase não exige intervenção; e se storage como Ceph for complicado demais, dá para escolher alternativas “quase sem administração” como Lemon ou Longhorn. Existem milhares de charts Helm, então até bancos de dados complexos podem ser implantados em 1 minuto. Fazer deploy de serviços também é muito fácil se você usar só templates Helm comuns. O Helm não é perfeito, mas se você o configurar do jeito que quer, ainda pode aproveitar coisas como autocomplete de valores. A barreira de entrada é um pouco mais alta do que serverless, mas aprender isso por uma semana para economizar dezenas de milhares em produção vale totalmente a pena.
O problema que o Kubernetes resolve é “como vou fazer o deploy disso?”. Olhando a documentação do Rivet, só vejo contêiner único, Docker Compose e deploy manual (com comandos Docker). Fico em dúvida se dá para implantar uma infraestrutura serverless em escala real dessa forma. Minha primeira pergunta seria: “nesse ponto, não daria para rodar o Rivet em cima de Kubernetes (containers, kube-virt etc.)?”. Não vejo como Docker Compose poderia ser mais robusto ou mais escalável do que Kubernetes. E se a ideia for vender um serviço em nuvem, então isso também não combina com o conceito de Kubernetes 2.0. Se eu fosse hospedar o Rivet por conta própria, provavelmente mudaria a documentação para permitir rodá-lo no Kubernetes.
Se você usa “k8s como serviço”, terceirizando a manutenção do cluster para o fornecedor de nuvem, eu gostaria de saber exatamente o que parece tão complexo. O escopo de configurações é amplo, mas para montar um serviço de verdade em produção basta conhecer um pequeno subconjunto delas. Um nível de configuração só um pouco mais complexo que Docker Compose já é suficiente para fazer deploy em k8s. Mas para a maioria dos apps até esse “um pouco mais” talvez seja desnecessário. Na verdade, Docker Compose era justamente o que atendia essa necessidade mais popular, e é uma pena que não tenha recebido atenção contínua.
Minha experiência em operação de infraestrutura é que algo que “simplesmente funciona” jamais vai existir. Até o Heroku apresenta problemas ao escalar. Se você quer uma plataforma de deploy que todos possam adotar facilmente, faz mais sentido entender o Kubernetes como o primitive de base de algum PaaS específico. O Rivet é interessante por ser diferente e por trazer algumas ideias do ecossistema BEAM. Pessoalmente, me interesso mais por robustez e local-first do que por deploy em larga escala.
“Low maintenance”... Eu uso bastante EKS (k8s gerenciado), e realmente não preciso me preocupar com o estado do cluster em si (tirando, claro, algum jeito criativo de eu mesmo quebrar os nós). O Kubernetes realmente posa de sistema “quase sem manutenção”, mas na prática ele é pura manutenção. O fato de você conseguir colocar um yaml na mesa e implantar software no mundo é realmente impressionante. Mas o preço é justamente uma manutenção complexa. Configurar o cluster, inicializar o ArgoCD, registrar outros clusters em um modelo hub-and-spoke — tudo isso já é um número de circo por si só. Além disso, você acaba instalando operators úteis do tooling da CNCF Landscape e mais uns 30 tools auxiliares (que tecnicamente não são primárias, mas são indispensáveis). Configurar
values.yamlleva bem mais do que uma ou duas horas, e grande parte disso vira trabalho com ArgoCD e templates. Secrets Manager -> External Secrets -> ArgoCD ApplicationSet -> outrovalues.yaml... muitas vezes você gasta tempo demais só para passar um único valor booleano. O ciclo de atualização de cluster/operator também é rápido, então a manutenção é um problema permanente. Se você usa Karpenter para autoscaling, troca de nós e zero downtime viram outro malabarismo (e apps stateful no k8s dobram a diversão). Resumo: chamar isso de “Low maintenance” é puro sarcasmo.“Low maintenance” no fim é um conceito relativo às alternativas. Na minha experiência, usando k8s a carga de manutenção para obter serviços da mesma qualidade — em escalabilidade, failover, rollback, recuperação de desastres, DevOps, provisionamento de clusters independentes etc. — foi muito menor. Pode variar conforme o contexto, mas para mim foi assim.
Eu uso k3s na Hetzner há dois anos e tive 100% de uptime. A carga de manutenção é tão baixa que eu até perdi a chave SSH do nó master uma vez, e ainda assim reprovisionar o cluster inteiro, incluindo atualização da documentação, levou só 90 minutos. Se fosse realmente urgente, teria dado para fazer em 15. Estou rodando um cluster k8s com 3 nós ARM e 1 master, um pouco de storage e DNS automático integrado ao Cloudflare por 20 euros por mês.
Mas o que você está realmente administrando não é o Kubernetes em si, e sim sistemas auxiliares como CI/CD, gerenciamento de secrets e automação de operação de banco de dados. Antigamente isso teria sido feito com cron jobs, ansible, systemd, scripts bash etc. em vez de yaml.
Parece que você construiu o próprio picadeiro. Não deveria instalar tanta coisa. Cada coisa que você adiciona vem com dívida técnica e custo de manutenção, mesmo sendo ferramenta gratuita. Se o autoscaling gera mais dívida/manutenção do que economia, então é melhor simplesmente desligá-lo.
Se você tivesse montado e operado esse mesmo conjunto de serviços de forma isolada, a carga de manutenção teria sido muito maior. Mas o Kubernetes é fácil o bastante de administrar a ponto de você conseguir deixá-lo “pegando fogo” e ainda assim seguir em frente. Só precisa saber o que está fazendo para não cair na tentação de instalar “ferramentas legais”.
K8S também não obriga você a usar yaml. Pode ser idiomático, mas não é obrigatório. O
kubectl applysuportava json desde o começo, e os endpoints são json e grpc. Dá para gerar config a partir de várias linguagens, como jsonnet. Em segundo lugar, fico curioso sobre por que dependency e dependency ordering seriam um problema em charts Helm. O principal idiom do Kubernetes está no loop: se uma dependência não existir, o app deve tratar isso como um erro recuperável e continuar tentando até conseguir. Ou então ele falha e o controller do ReplicaSet reinicia automaticamente. Se não há dependência no chart, não há conflito de dependência. Se o app realmente depende de outro, então faz sentido incluir o app/serviço dependente junto no chart Helm.(Citando o comentário principal) > Dizer que em caso de crash o controller do ReplicaSet vai reiniciar o app não é suficiente. Se, por exemplo, o Keycloak leva 1 minuto para subir, o serviço que depende dele cai imediatamente por não encontrá-lo e fica nesse ciclo até entrar em throttle, de modo que mesmo depois de o Keycloak subir ele ainda espera inutilmente por mais 5 a 10 minutos. Se a dependência é clara, faz mais sentido verificar o serviço dependente com um init container antes de seguir para o contêiner principal. Eu gostaria que o Kubernetes tivesse algum recurso explícito para declarar dependências de inicialização. Cair e entrar em throttle depois de algumas tentativas não é a resposta. Dependências simplesmente existem na vida real.
Eu acho que falhas de dependência sempre deveriam ser recuperáveis. Já tive incidente antes por causa de um fail-closed disparado por uma dependência que nem era realmente usada. Dependências entre servidores quase sempre são soft dependencies. Se a dependência downstream não responde, basta retornar 500 e o load balancer evita os servidores unhealthy.
As pessoas dizem “supposed to”, mas isso só se encaixa bem quando você está construindo uma stack de software interna. Há muitos casos de software legado, já pronto, que só suportava Docker e depois passou a rodar em Kubernetes. Quando desenvolvedores criam ferramentas com base na própria filosofia, as pessoas acabam usando do jeito que queriam de qualquer forma, e o resultado vira uma bagunça. No fim, é preciso dar às pessoas vários recursos e opções, e o mercado vai usar como quiser.
Criticar alguém com base no fato de que “dá para usar json em vez de yaml” não responde ao ponto principal. Ninguém realmente se importa com isso. Parece só implicância desnecessária.
Sou fortemente contra a ideia de trocar yaml por HCL. HCL é difícil para desenvolvedores visualizarem e lerem. Tenho muitas reclamações de usabilidade, como suporte a import e dificuldade de depuração. Não entendo por que não colocaram no centro uma linguagem de definição de interface como protobuf, permitindo só converter o formato conforme a preferência do usuário.
HCL é o pior. Nunca senti falta de nada usando apenas yaml no k8s. Se a configuração está complexa demais, o problema provavelmente está mais no design do app do que em config map.
Na verdade, seja HCL, JSON ou YAML, isso é só serialização/desserialização do lado do cliente. Ou seja, não é um problema do Kubernetes em si, mas apenas uma camada externa de transformação.
As definições de interface do Kubernetes já são baseadas em protobuf (tirando CRD).
Minha principal reclamação com HCL é a sintaxe de
for loop. É realmente horrível.Dizer que “HCL é difícil para desenvolvedores e é difícil de lintar e depurar” me soa mais como resistência a aprender algo novo. Parece um problema de confundir a complexidade do domínio com o ato de aprender HCL.
Estou desenvolvendo o projeto nebulous no estilo “Kubernetes 2.0” (ainda em estágio pre-alpha). A meta é ser distribuído/global e leve, rodar como binário único no notebook e escalar até milhares de nós na nuvem, com rede Tailnet, storage com BitTorrent, multitenancy, live migration etc. A maioria dos requisitos surgiu de operação de ML (especialmente por causa da escassez de GPU), e talvez isso vire o padrão se ML se tornar algo comum no futuro.
Live migration é interessante. Hoje usamos uma estratégia de preço baseada em autoscaling entre vários clusters e nuvens, e live migration é um desafio de outro nível.
Isso não é Kubernetes, e sim um sistema separado especializado em operação de GPU.
“Distribuição global” talvez seja, na verdade, um non-requirement. Se você usa Tailnet como rede padrão, é até um recurso que eu tiraria logo de cara. O fato de o Kubernetes assumir uma única NIC é um legado frustrante moldado para a nuvem (por isso é bom ver vários CNIs e projetos recentes como o Multus; referência: blog da Red Hat). Fico curioso sobre o que realmente difere o design multi-tenant disso em relação ao k8s. E se o storage for via BitTorrent, compartilhar até imagens públicas de contêiner pode gerar uma conta enorme de tráfego de egress.
No GitHub, vejo
Chart.yaml, e até templates comoprovider_aws.yaml, que sinceramente representam um padrão de código que eu preferia não ver.Ainda acho o Kubernetes realmente muito complexo. Só parece menos por causa da popularização. Num Kubernetes 2.0, seria ótimo se a experiência do usuário, especialmente nas operações frequentes (deploy de app, exposição de serviço, mudança de service account/imagem etc.), fosse mais simples. Mas como a onda agora é LLM, parece difícil que haja evolução nessa direção.
O Kubernetes tem camadas demais de abstração. Pods são um conceito central ótimo, mas quando entram deployment, rep set, namespace etc., fico pensando que eu gostaria que fosse tão simples quanto Docker Swarm. O Terraform também é uma camada única e foi fácil de aprender. Estou sentindo na pele como a curva de aprendizado do k8s é realmente íngreme.
Esse tema me faz pensar que “a distinção de tipos em programas de computador é resultado da percepção humana”. Operators/controllers são abstratos demais, como COM/CORBA no passado (isso é vantagem e desvantagem ao mesmo tempo). Para implementações simples, um k8s-lite mais restrito parece até mais adequado. Por outro lado, em ambientes complexos, muitas vezes até as abstrações atuais do k8s são insuficientes. Fico em dúvida se um único sistema — seja Kubernetes 2.0 ou qualquer outro — conseguiria abranger todos os problemas reais de forma que desenvolvedores e arquitetos humanos ainda consigam lidar com ele.
Eu quero um sistema com “sane defaults”, ou seja, que sem precisar escolher muita coisa já ofereça um estado padrão bom o bastante (rede/storage/load balancer etc.). Não gosto nem de yaml nem de HCL. Precisamos de uma forma melhor de configurar, e trocar só a linguagem não vai resolver. Acho IPv6 indispensável. Docker, containers e Kubernetes deveriam ter sido IPv6-only internamente, deixando IPv4 como exceção tratada no ingress controller.
Existe um conflito essencial entre “sane defaults” e “conversão de clientes para serviços gerenciados”. Quanto mais acompanho o k8s, mais vejo crescer a filosofia de “batteries not included” em storage/rede etc., e AWS/GCP vendendo isso como serviços de integração caros. Na prática, o k8s do mundo real às vezes nem parece open source, e sim uma ferramenta para vender preenchimento de lacunas da nuvem.
(Experiência pessoal) A vantagem de Terraform/HCL sobre YAML é que ele não depende de caracteres invisíveis, então fica mais fácil de ler.
É justamente por causa dos “sane defaults” que eu gosto muito mais do k3s.
Acho uma wishlist um pouco modesta para um release 2.0. Todo mundo ao meu redor reclama muito da complexidade do k8s em produção. O ponto realmente central é como implementar backward compatibility e simplicidade ao mesmo tempo. Normalmente é justamente a compatibilidade retroativa que faz a complexidade explodir, porque o sistema novo acaba carregando tanto os recursos antigos quanto os novos.
Sinto que já vivo num “mundo Kubernetes 2.0” ao gerenciar clusters e apps com Terraform.
tf apply, configuro de uma vez cluster, nós, integrações com a nuvem (S3 etc.) e até serviços dentro do clustercloudflaredno cluster + config de túnel via API da Cloudflare)Como alguém que veio do frontend, achei o Kubernetes bastante intuitivo. Antes eu pegava dados de entrada e fazia a UI reagir a eles; agora parece que escrevo código para fazer os recursos e as configurações convergirem no painel de controle.