Resumo

  • implementable registra que approvers dos SIGs impactados aceitam que um KEP entre na implementação; não registra que código foi incorporado, que uma release o contém ou que algum cluster o ativou.
  • Marco de release, Production Readiness Review, testes, feature gate, artefato numerado e suporte de um operador pertencem a registros e responsáveis distintos.
  • Um recibo curto que siga a mudança da proposta à operação conserva essas passagens sem transformar aprovação de desenho em garantia de serviço.

A decisão implementable tem um dono e um alcance delimitados

O processo de Kubernetes Enhancement Proposals não serve apenas para catalogar ideias. Ele cria um registro de motivação, desenho, responsabilidades, metas de estabilidade e evolução entre ciclos. O processo público diz que os approvers são escolhidos entre os SIGs afetados e que eles decidem quando um KEP se torna implementable. O mesmo registro distingue os estados provisional, implemented, deferred, rejected, withdrawn e replaced. Processo de KEP

Isso dá peso real ao estado implementable. Ele é uma decisão técnica, tomada por pessoas com mandato para avaliar aquele desenho no escopo dos SIGs envolvidos. Mas o seu alcance termina aí. O estado não demonstra que determinado commit entrou no repositório, que uma versão específica o aceitou ou que um administrador ativou um valor em apiserver, kubelet ou qualquer outro componente. Também não substitui a decisão de uma organização que paga pelos incidentes e promete suporte a seus clientes.

Manter essa fronteira não diminui o trabalho dos SIGs. Ao contrário, impede que a decisão deles seja aumentada por linguagem até significar uma garantia que nunca emitiram. Approvers de desenho ponderam APIs, arquitetura e dependências entre SIGs. Operadores precisam ponderar capacidade, complementos, version skew, telemetria, caminho de retorno e contratos de serviço. Uma frase que chama ambos de “aprovação” remove do registro justamente quem arca com o segundo conjunto de perdas.

A candidatura a uma release exige uma nova cadeia de evidências

O modelo de KEP descreve esse segundo limite de forma direta. Para que uma mudança seja considerada em uma release-alvo, a issue de enhancement associada deve apontar para o marco antes do Enhancement Freeze. A lista de signoff vai além de implementable: inclui detalhe de desenho, plano de testes, critérios de graduation, Production Readiness Review concluída e aprovada, histórico de implementação, documentação de usuário e materiais de apoio. A instrução pede que a lista seja revisitada a cada vez que o enhancement for considerado para um marco. Modelo de KEP

Essa repetição não é burocracia sem função. Uma decisão que basta para começar a implementar pode não bastar para o ciclo de release atual: testes ainda podem faltar, a documentação pode ter envelhecido ou uma questão de operação do ciclo anterior pode exigir resposta. E uma issue apontada para um marco não demonstra, por si, que toda a lista foi fechada. Trocar “alvo” por “lançado” é tão impreciso quanto trocar “implementable” por “incorporado”.

A Production Readiness Review acrescenta outra superfície de decisão. A documentação a coloca em uma equipe distinta dos SIG leads, com atenção a observabilidade, escalabilidade, capacidade de suporte, operação segura e meios de desabilitar ou reverter. Desde Kubernetes 1.21, a aprovação de PRR é exigida para que um enhancement faça parte de uma release. Processo de Production Readiness Review

Trata-se de uma fronteira forte para inclusão no projeto, não de uma garantia para qualquer ambiente. PRR não decide se uma combinação particular de CNI, CSI, políticas de admissão, capacidade, distribuição ou contrato de cliente será aceitável. Ela comprova que uma revisão independente realizou o que lhe compete; não faz com que outra instituição assuma as suas consequências operacionais.

Feature gate documenta uma opção de componente, não uma adoção universal

A referência de feature gates define um gate como uma configuração key=value fornecida por --feature-gates em componentes Kubernetes. Cada componente reconhece apenas gates relativos às próprias funções, e a referência separa os estágios Alpha, Beta e stable das informações de introdução e remoção de versão. Referência de Feature Gates

Essa página responde “como pode ser configurado”, não “quem o configurou”. A presença de um gate na documentação não informa se ele está verdadeiro em um cluster. Um recurso pode depender de configurações coordenadas em mais de um componente; uma distribuição pode impor condições adicionais; um operador pode manter a opção desativada enquanto verifica sinais de observabilidade, semântica de armazenamento, compatibilidade de versão e reversão. O projeto fornece o controle. Não gira o controle pelo operador.

Os exemplos de graduation no modelo de KEP mantêm a mesma separação. Alpha requer implementação atrás de uma feature flag e testes e2e iniciais. Beta requer requisitos de funcionalidade, segurança, monitoramento e testes, além de tratamento de lacunas conhecidas. GA considera uso real, tempo de feedback e a resolução do feedback de Beta; recursos não opcionais requerem também testes de conformidade. Modelo de KEP São evidências da maturidade no ciclo do projeto, não uma autorização de adoção concedida em nome de cada operador.

Uma release numerada ainda não fala pelo operador

A página de releases de Kubernetes registra branches de release, versões x.y.z, patches e datas de EOL. É um recibo público mais concreto que o estado de uma proposta: permite localizar artefatos lançados pelo projeto e a janela de suporte no nível do projeto. Registros de releases Kubernetes Mas essa janela não informa o que uma plataforma gerenciada empacotou, se um cluster é compatível ou se alguém se comprometeu a responder por incidentes.

O repositório de enhancements é útil para acompanhar KEPs, issues e ciclos, mas não é prova de adoção. Kubernetes enhancements Inferir diretamente de KEP para release, de release para configuração e de configuração para suporte elimina, em cada salto, o único sujeito que poderia confirmar o próximo salto.

Uma prática melhor é guardar um pequeno recibo da proposta à operação: identificação e revisão imutável do KEP; SIG proprietário e SIGs afetados; approvers e estado; marco e freeze; pedido e resultado de PRR; revisões de código e testes; gate, componente e valor padrão; release numerada e nota de release; limite da distribuição; e declaração explícita do operador sobre habilitação, suporte, version skew e rollback. O recibo não cria uma nova autoridade. Ele apenas devolve cada juízo ao seu autor.

Essa disciplina coincide com a distinção de Lu Heng: participação e perícia podem ser evidência, mas não fabricam por si uma delegação de quem está ausente; consequências de operação devem ser assumidas claramente por quem as carrega. The Multi-Stakeholder Mirage Running-Code Primacy

O que este registro não prova

As fontes não comprovam o estado de um KEP nomeado, a inclusão de uma mudança em uma release determinada, a ativação de qualquer gate em um cluster ou um compromisso de compatibilidade e suporte por uma distribuição ou operador. Elas não avaliam fornecedor, cliente, cluster ou incidente específico. O recibo proposto aqui é uma recomendação editorial de Daniel Kade, não uma regra de Kubernetes.

Fontes