Nesta quinta entrevista da série de destaques do SIG Architecture, mergulhamos no funcionamento do subprojeto de API Governance. Conversamos com Jordan Liggitt, líder da iniciativa, para entender como o Kubernetes mantém sua integridade conceitual enquanto escala para suportar as demandas das maiores empresas do mundo.
Para empresas brasileiras que operam clusters críticos, entender a governança por trás das atualizações do Kubernetes é fundamental para estratégias de lifecycle management e mitigação de riscos operacionais.
Introdução
FM: Olá, Jordan. Conte-nos um pouco sobre você, seu papel e como se envolveu com o Kubernetes.
JL: Trabalho com Kubernetes desde 2014. Na época, eu estava focado em authentication e authorization na Red Hat. Meu primeiro pull request tentava adicionar um servidor OAuth ao servidor de API do Kubernetes. Ele nunca saiu do status de work-in-progress, mas essa experiência inicial me manteve envolvido no desenvolvimento das capacidades de segurança do core.
Fui nomeado revisor de API em 2016 e aprovador em 2017. Hoje, além de liderar a Governança de API e a organização de código no SIG Architecture, sou tech lead do SIG Auth.
Objetivos e escopo da Governança de API
FM: Como você descreveria os principais objetivos do subprojeto?
JL: O escopo inclui todas as interfaces do Kubernetes, inclusive aquelas que as pessoas nem sempre percebem que são APIs: flags de linha de comando, arquivos de configuração, como os binários são executados e como eles persistem dados no ETCD. Embora a API REST seja a mais óbvia e com maior público, todas exigem governança.
O objetivo central é ser estável e, ao mesmo tempo, permitir a inovação. A estabilidade é fácil se você nunca mudar nada, mas isso impediria o crescimento. Nós equilibramos o "ser estável" com o "permitir mudanças".
FM: Sobre essas mudanças, quais são os gates de qualidade no ciclo de vida do Kubernetes?
JL: Temos diretrizes e convenções densas que atualizamos constantemente. Atuamos tanto na fase de design quanto na de implementação. Idealmente, entramos cedo no processo de KEP (Kubernetes Enhancement Proposal).
Quando uma equipe apresenta um design detalhado de API em um KEP, podemos revisá-lo antes mesmo da primeira linha de código ser escrita. Isso evita retrabalho massivo e garante que a nova funcionalidade respeite a semântica de spec/status e as convenções de retrocompatibilidade do projeto.
O impacto das Custom Resource Definitions (CRDs)
FM: Existe algum marco que tenha mudado drasticamente o trabalho de governança?
JL: O momento divisor de águas foi a chegada dos Custom Resources. Antes deles, cada API era feita à mão por nós e totalmente revisada. Com as CRDs, qualquer um poderia definir qualquer coisa.
As primeiras versões nem exigiam um schema, o que permitiu uma inovação rápida, mas gerou desafios de consistência. Desde que as CRDs se tornaram GA (General Availability), trabalhamos para dar aos autores de CRDs capacidades de validação equivalentes às APIs nativas. Recursos recentes de validation rules integradas são marcos fundamentais para trazer essa consistência de volta ao ecossistema.
Governança em contexto: SIG Architecture e API Machinery
FM: Como vocês se relacionam com o API Machinery?
JL: O API Machinery fornece o código e as ferramentas (a base técnica). O SIG Architecture define a direção do sistema. Nós, da Governança de API, trabalhamos com os outros SIGs (como Storage, Network, Scheduling) para garantir que as novas APIs criadas sobre essa base técnica sigam padrões consistentes e não quebrem a experiência do usuário final.
Conclusão e visão de futuro
FM: Algum comentário final sobre por que esse rigor é necessário?
JL: O motivo pelo qual nos importamos tanto com estabilidade é o usuário. É fácil para um contribuidor ver esses requisitos como obstáculos, mas as empresas integram seus sistemas ao Kubernetes baseadas em uma promessa de que não quebraremos seus contratos.
Nossas perguntas em revisões focam no futuro: "como você evoluirá isso daqui a dois anos sem quebrar quem usa hoje?". Assumimos que cometeremos erros, então o design precisa deixar espaço para melhorias mantendo a compatibilidade.
Artigo originalmente publicado por Frederico Muñoz (SAS Institute) em Kubernetes Blog.
