Pular para o conteúdo
100% Privacidade — Seus arquivos permanecem no seu dispositivo
>_
Português

Validador YAML do Kubernetes

Cole um ou vários manifests do Kubernetes (separados por ---) e valide-os com o esquema real antes de fazer kubectl apply.

Arraste um arquivo .yaml/.yml aqui, ou cole o texto do manifest acima.

Vários manifests separados por "---" são validados como documentos independentes.

Opções avançadas

A análise e a validação são executadas no seu navegador — apenas o esquema do recurso (nunca o seu manifest) é obtido de um CDN público.

Cole um manifest do Kubernetes acima (ou carregue o exemplo) e os resultados da validação aparecerão aqui.

Como pegar erros de manifest do Kubernetes antes do kubectl

Um `kubectl apply` rejeitado costuma ser a primeira vez que um erro no manifest do Kubernetes aparece — e a essa altura você normalmente está no meio de um deploy, olhando uma mensagem que cita um caminho de validação de JSON Schema (`spec.template.spec.containers[0].image: Required value`) que não remete de imediato ao arquivo YAML que você acabou de editar. Pegar o mesmo tipo de erro antes, com a linha exata destacada, transforma isso em uma correção de cinco segundos, em vez de uma troca de contexto.

A sintaxe do YAML tem arestas que outros formatos de configuração não têm: a indentação é significativa e a mistura de tabs e espaços pode, em alguns casos, produzir em silêncio uma estrutura diferente (e errada) em vez de um erro; os separadores de documento `---` são fáceis de perder de vista em um arquivo longo com vários recursos; e um nível extra de aninhamento perdido continua sendo YAML válido, mas significa algo totalmente diferente para o Kubernetes. Esta ferramenta analisa o texto com uma biblioteca que preserva a posição de cada trecho do código-fonte, então um problema de sintaxe é apontado na linha real em que ocorre, e não só em "algum lugar deste arquivo de 200 linhas".

As apiVersions obsoletas são uma armadilha em câmera lenta: Deployments com `extensions/v1beta1`, StatefulSets e DaemonSets com `apps/v1beta1`/`apps/v1beta2` e Ingresses com `networking.k8s.io/v1beta1` ainda são YAML perfeitamente válido e funcionavam em clusters antigos — até o cluster ser atualizado para uma versão em que o Kubernetes finalmente remove o grupo de API antigo. A partir daí, todo manifest que o usa deixa de ser aplicado, sem aviso prévio. Detectar isso durante a edição (com a apiVersion substituta sugerida) evita descobrir o problema no meio de uma atualização do cluster.

A validação pelo esquema OpenAPI real do Kubernetes pega o resto: um campo `replicas` que virou string entre aspas em vez de número, um `containerPort` fora do intervalo válido, um campo obrigatório como `spec.selector` em um Deployment que se perdeu ao copiar e colar entre manifests. Nada disso é erro de sintaxe YAML — o arquivo é lido sem problemas — e é justamente por isso que uma passada dedicada de validação por esquema encontra o que uma leitura rápida a olho geralmente deixa passar.

Perguntas frequentes

Isto substitui o `kubectl apply --dry-run` ou o `kubeconform`?

Não. O `kubectl apply --dry-run=server` é a única verificação feita contra o servidor de API do seu cluster de verdade (incluindo CRDs e admission webhooks instalados), e `kubeconform`/`kubeval` são ferramentas de linha de comando maduras, feitas para pipelines de CI. Esta ferramenta valida o mesmo tipo de coisa — sintaxe YAML, estrutura do esquema, apiVersions obsoletas — direto de uma aba do navegador, antes de você ter o `kubectl` configurado em algum cluster ou ao revisar um manifest enviado por outra pessoa.

De onde vêm os esquemas?

Do `yannh/kubernetes-json-schema`, um espelho mantido pela comunidade e atualizado automaticamente dos JSON Schemas derivados do OpenAPI do próprio Kubernetes, buscado sob demanda em uma CDN pública para a versão do Kubernetes escolhida. Nada do seu manifest é enviado — só o arquivo de esquema (versionado e público) é baixado, o mesmo para todos os usuários que validam aquele kind/versão.

Por que apenas 10 tipos de recurso?

Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob e PersistentVolumeClaim cobrem a grande maioria dos manifests escritos à mão. Os demais tipos ainda recebem a verificação completa de sintaxe YAML e a detecção de apiVersion obsoleta — só não passam, por enquanto, pela validação da estrutura do esquema.

Meu YAML sai do navegador em algum momento?

Não. A análise e a validação por esquema rodam com JavaScript puro nesta aba — a única requisição de rede feita por esta ferramenta é baixar o arquivo público de JSON Schema do tipo de recurso e da versão do Kubernetes que você escolheu, nunca o conteúdo do seu manifest.

Ferramentas relacionadas