Kubernetes / Helm

Validador YAML Kubernetes— revise recursos e referências juntos

Escolha a versão, confira os campos indicados e exporte os documentos necessários.

Validador YAML Kubernetes

YAML dos manifestos

Recursos e resultados

Resultado desatualizado. Formate novamente.

Manifestos e esquemas ficam neste navegador, sem envio nem conexão com o cluster.

Opções de validação
Esquema de recurso personalizado

Cole um JSON Schema draft-07 para uma combinação exata de apiVersion/kind. Referências internas são aceitas; referências externas não são baixadas e CEL não é executado.

Resultado desatualizado. Formate novamente.

A verificação estática não garante o deploy. É possível exportar YAML com erros de validação; consulte os diagnósticos antes.

Este Validador YAML Kubernetes ajuda quando o arquivo passa na análise de sintaxe, mas ainda contém dúvidas para o deploy. Um campo pode estar escrito corretamente como YAML e, mesmo assim, ter um nome ou tipo que a API não aceita. A identificação do documento mantém o erro ligado ao recurso certo.

Para validar arquivos do Kubernetes, selecione uma das definições fixas: 1.35.0, 1.36.0 ou 1.37.0. O validador de YAML não lê kubeconfig, não descobre o cluster e não aplica valores padrão do servidor. A comparação usa apenas a versão escolhida e o conteúdo atual.

Por que usar este Validador YAML Kubernetes

Não perder o recurso no meio do arquivo

O Validador YAML Kubernetes organiza os documentos por kind, namespace e nome. O diagnóstico inclui número do documento, linha, coluna e caminho do campo. Selecionar um recurso extrai seu YAML formatado, enquanto o texto completo continua disponível para conferir os outros objetos.

Três cartões de manifesto formam uma lista de recursos com um diagnóstico de campo destacado.

Tratar referências locais com cuidado

O seletor de um Service é comparado aos rótulos de Pods e modelos de workload do mesmo namespace. Referências a ConfigMap e Secret também são procuradas na entrada. Se o objeto não aparece, o resultado é um aviso, pois ele pode já existir no cluster.

Um serviço aponta para workloads correspondentes e uma referência de configuração ausente recebe um aviso.

Confira a versão antes de salvar

01

Execute novamente após editar

A versão inicial é 1.37.0 e a validação é manual. Alterar o texto, a indentação ou um esquema torna o resultado anterior desatualizado e desabilita seu export. Use o botão ou Ctrl/Cmd+Enter para processar o estado atual sem recompilar enquanto digita.

02

Informe a definição do recurso personalizado

Preencha apiVersion, kind e um JSON Schema draft-07 no painel específico. A definição só vale para essa combinação exata. Referências internas funcionam; uma referência externa que não foi fornecida causa erro em vez de ser baixada automaticamente.

03

Aplique a prévia de forma consciente

O formatador YAML e a mesclagem exibem a quantidade de caracteres e documentos antes da substituição. Aplicar altera a entrada; Desfazer recupera também o resultado anterior. Escolha um documento ou o conjunto inteiro para exportar sem recortar o texto original.

Estrutura e contexto na mesma revisão

Definições completas por versão

Os esquemas vêm de um commit fixo do registro derivado de Kubernetes OpenAPI. Verificam campos extras, tipos e valores obrigatórios. O primeiro erro de esquema de cada recurso é mostrado; depois da correção, outro problema pode aparecer na próxima execução.

Nomes e identidades duplicadas

Tipos comuns recebem verificações de nome DNS; objetos RBAC usam regras de segmento de caminho. A identidade combina grupo da API, kind, namespace e nome, sem diferenciar versões da API. Quando uma regra adicional de nome não está coberta, o aviso permanece explícito. Nomes de Job têm limite de 63 caracteres; os de CronJob, de 52.

Referências dentro dos modelos

São examinados Pods e modelos de Deployment, StatefulSet, Job, CronJob e outros workloads usuais. A análise cobre ambientes de contêineres, volumes e volumes projetados com ConfigMap ou Secret. Não testa conectividade nem confirma as chaves individuais desses objetos.

YAML multi-documento preservado

A formatação usa a árvore sintática, mantendo comentários, âncoras e a escrita original dos números. É possível mesclar arquivos locais e salvar documentos separadamente. Não há ordenação de recursos, remoção de campos ou conversão automática de tipos.

Como interpretar os limites

A aprovação do servidor é outra etapa
CEL, webhooks, RBAC, agendamento, imagens e feature gates não são executados. Valores padrão do servidor não são inseridos. Nomes de Service seguem a regra comum de começar com letra; opções de nomes relaxados do cluster não são simuladas.
Tipos desconhecidos não passam silenciosamente
Sem um esquema correspondente a apiVersion/kind, o recurso fica pendente. Forneça uma definição draft-07 para o alvo exato. A página não extrai definições de CRD, não renderiza Helm ou Kustomize e não busca referências externas.
List não é um separador de documentos
Separe recursos com ---. Objetos List ou kinds terminados em List não têm seus items expandidos nem validados individualmente. Documentos vazios ficam fora da lista, mas os demais preservam os números originais.
Tamanho e tempo são limitados
O máximo é 500.000 caracteres, 100 documentos, 100 níveis, 50.000 nós analisados e 1.000 diagnósticos. O worker para após 8 segundos. Chaves duplicadas, tags não aceitas, expansão excessiva de aliases e inteiros inseguros são recusados.
Exportar não autoriza o deploy
Erros estruturais não impedem salvar o YAML formatado como trabalho em andamento. Erros de sintaxe e resultados desatualizados bloqueiam o export. Espaçamento e estilo compacto podem mudar, por isso a prévia deve ser conferida antes de substituir a entrada.

Dúvidas sobre o Validador YAML Kubernetes

O formatador aceita YAML com vários documentos?

Sim. Use --- entre os recursos, até 100 documentos por entrada. Os documentos não vazios aparecem na lista e podem ser exportados individualmente. Um objeto List é uma estrutura diferente e recebe um aviso de não suporte, sem validação dos items como recursos separados.

Posso validar arquivos do Kubernetes?

Sim, desde que contenham recursos já renderizados. O Validador YAML Kubernetes usa apiVersion e kind para selecionar um esquema da versão escolhida. Arquivos de Helm com expressões de template precisam ser renderizados antes; configurações genéricas de outras ferramentas não são o foco da validação.

É seguro colar arquivos com senhas ou tokens?

O conteúdo e o esquema personalizado são processados no navegador, sem upload ou armazenamento persistente. O site carrega seus próprios arquivos de programa e definições, mas não busca URLs presentes no texto. Arquivos baixados e conteúdo copiado ficam sob seu controle.

Por que meu YAML valida, mas o deploy continua falhando?

Sintaxe e estrutura corretas não garantem permissões, políticas de admissão, imagens acessíveis ou recursos suficientes. O ambiente do cluster pode recusar um objeto que atende ao esquema. Use a validação local para revisar o arquivo e mantenha os controles do servidor no fluxo de deploy.

Chaves duplicadas são permitidas?

Nesta ferramenta, uma chave repetida no mesmo mapa causa erro para impedir substituição silenciosa de valores. Campos com o mesmo nome em documentos diferentes são normais. A duplicação de objetos é verificada separadamente por grupo da API, kind, namespace e nome.

Algo não saiu como esperado?

Revise o próximo manifesto

Guarde a versão do Validador YAML Kubernetes junto das observações da revisão. Após corrigir os campos, execute novamente e exporte somente o conjunto de documentos necessário para a próxima etapa.