KYAML no Kubernetes: torne a configuração explícita sem reescrever a frota
O projeto Kubernetes voltou ontem a explicar o seu dialeto estrito de YAML. É compatível com parsers existentes e reduz ambiguidades de indentação e tipos; não é um novo formato obrigatório nem substitui validação de schema, política ou drift.
- Estado
- KYAML beta desde Kubernetes 1.35; formato de saída opcional
- Compatibilidade
- Subconjunto estrito; qualquer KYAML válido é YAML válido
- Não resolve
- Schema inválido, valor errado, segredo exposto, drift, admission ou rollout
- Verificado
- 12 de agosto de 2026
Em resumo
KYAML é um subconjunto estrito de YAML desenhado para manifests Kubernetes mais explícitos. Usa flow style: chavetas para mapas, parênteses retos para listas, strings de valor sempre entre aspas duplas, comentários e trailing commas. Todo KYAML válido continua a ser YAML válido. O suporte de saída surgiu como alpha no kubectl 1.34, passou a beta e ficou ativo por defeito no 1.35; pedir a saída continua a exigir -o kyaml ou uma preferência kuberc aplicável. O anúncio de 11 de agosto não obriga a converter repositórios. Uma adoção segura compara o objeto parseado antes e depois, testa Helm, linters, editores e políticas e evita misturar uma alteração de formato com mudanças funcionais.
- Use KYAML primeiro como pretty-print e revisão, não como conversão massiva de todo o GitOps.
- Compare representação semântica parseada antes e depois; um diff textual limpo não prova o mesmo objeto.
- Teste a cadeia inteira: templates, comentários, linters, validação de schema, policy-as-code, diffs e editores.
- Mantenha alterações funcionais separadas da reforma de formato para conservar revisão e rollback claros.
Menos liberdade sintática, a mesma API
YAML permite várias formas de representar a mesma estrutura. Indentação define nesting e valores sem aspas podem sofrer coerção implícita. KYAML reduz essa superfície com mapas e listas delimitados, strings de valor citadas e uma apresentação consistente. Conserva comentários e trailing commas, duas capacidades que diferenciam a experiência de JSON.
O Kubernetes descreve KYAML sobretudo como formato de saída. Um ficheiro KYAML pode ser recebido por ferramentas que já aceitam YAML, mas Kubernetes não exige input nesse dialeto. A documentação de 11 de agosto afirma que não existem planos para o tornar o output predefinido. No 1.35 o suporte beta está ativo; ainda se pede -o kyaml. No 1.36, kuberc pode definir a preferência por comando para quem a quer localmente.
Maturidade e adoção real
- 1.34Alpha opt-in
kubectl introduz saída KYAML através do feature gate indicado.
- 1.35Beta ativa
A funcionalidade fica disponível por defeito, mantendo seleção explícita de output.
- 1.36Preferência kuberc
O utilizador pode configurar KYAML por comando sem mudar o contrato do cluster.
- 11 AGOGuia de pretty-print
O projeto documenta conversão, diff e uso sem anunciar obrigatoriedade.
Faça um piloto de representação, não uma migração funcional
Escolha um diretório pequeno com Deployments, Services, ConfigMaps e pelo menos um Custom Resource. Gere KYAML e parseie as duas versões para uma representação canónica, removendo apenas diferenças conhecidas de serialização. Bloqueie se apiVersion, kind, metadata relevante ou spec mudar. Preserve comentários que codificam intenção operacional.
Helm e outros templates merecem uma pista própria: converter apenas o resultado renderizado não converte a fonte e reformatar a fonte pode quebrar expressões sensíveis a whitespace. Teste template, render, parse, validação, policy e dry-run. Não use a saída de um objeto live como substituto automático do estado desejado; campos calculados e estado do servidor pertencem a outra camada.
Escolha por artefacto
| Artefacto | Uso KYAML | Comparação | Risco |
|---|---|---|---|
| Manifest simples | Converter piloto | Objeto parseado | Diff volumoso |
| Template Helm | Testar render | Fonte + output | Whitespace/template |
| Custom Resource | Só com schema | OpenAPI + policy | Campo desconhecido |
| Objeto live | Inspeção | Desired vs observed | Estado calculado |
| kuberc local | Preferência | Comando e equipa | Saída inconsistente |
Um rollout que não esconde mudanças de comportamento
Crie uma alteração dedicada apenas a formato. Registe versão do kubectl e formatter, comando exato e hash dos objetos canónicos. Execute validação de schema, políticas e dry-run no ambiente de teste. Peça revisão a alguém que não fez a conversão e verifique se a nova forma melhora leitura de nesting, tipos e alterações reais.
Se o piloto passar, avance por diretórios pequenos. Não force preferências locais antes de alinhar CI e documentação; outputs diferentes entre pessoas criam diffs que anulam o ganho. Mantenha um caminho reversível para o estilo anterior enquanto plugins, IDEs e geradores ainda não produziram resultados consistentes.
- Fixe formatter e versão em CI; não use latest sem controlo.
- Compare JSON canónico ou objeto equivalente, não apenas linhas.
- Preserve comentários e reveja qualquer perda como mudança material.
- Separe reformatação, upgrade de API e mudança de valores em commits distintos.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.- 01How to Pretty-Print Your Kubernetes YAML as KYAMLKubernetes · SYS-KUBERNETES
- 02KYAML referenceKubernetes · SYS-KUBERNETES
- 03Kubernetes v1.35 release — KYAML betaKubernetes · SYS-KUBERNETES
- 04Command line tool kubectl — output formatsKubernetes · SYS-KUBERNETES
- 05Kubectl user preferences — kubercKubernetes · SYS-KUBERNETES
- 06Declarative management using configuration filesKubernetes · SYS-KUBERNETES
Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.