Kubernetes YAML 검사기
kubectl apply를 하기 전에 Kubernetes 매니페스트(여러 개면 ---로 구분)를 붙여넣어 실제 스키마와 대조해 보세요.
여기에 .yaml/.yml 파일을 드롭하거나, 위에 매니페스트 텍스트를 붙여넣으세요.
"---"로 구분된 여러 매니페스트는 각각 별도의 문서로 검사됩니다.
고급 옵션
파싱과 검증은 브라우저 안에서 이루어집니다 — 공개 CDN에서 가져오는 것은 리소스 스키마뿐이며, 매니페스트 내용은 전송되지 않습니다.
위에 Kubernetes 매니페스트를 붙여넣거나 샘플을 불러오면 검증 결과가 여기에 표시됩니다.
kubectl보다 먼저 Kubernetes 매니페스트 실수 잡기
`kubectl apply`가 거부되어야 비로소 Kubernetes 매니페스트의 실수를 알게 되는 경우가 많습니다. 그때는 이미 배포 도중이고, 방금 고치던 YAML 파일과 바로 연결되지 않는 JSON Schema 검증 경로(`spec.template.spec.containers[0].image: Required value`)가 담긴 오류 메시지를 보게 됩니다. 같은 종류의 오류를 더 일찍, 정확한 줄을 짚어서 잡으면 맥락을 전환할 필요 없이 5초 만에 고칠 수 있습니다.
YAML 자체의 문법에는 다른 설정 형식에서는 잘 드러나지 않는 함정이 있습니다. 들여쓰기가 의미를 가지므로 탭과 공백이 섞이면 오류 대신 조용히 다른(잘못된) 구조가 만들어질 때가 있고, 긴 멀티 리소스 파일에서는 `---` 문서 구분자를 놓치기 쉽습니다. 불필요하게 한 단계 더 들어간 중첩은 올바른 YAML처럼 읽히지만 Kubernetes에는 전혀 다른 의미가 됩니다. 이 도구는 파싱 과정 내내 원본 위치 정보를 유지하는 방식의 라이브러리로 파싱하므로, 구문 문제를 "200줄짜리 파일 어딘가"가 아니라 실제 발생한 줄 기준으로 알려 줍니다.
지원 중단된 apiVersion은 더 천천히 찾아오는 함정입니다. `extensions/v1beta1` Deployment, `apps/v1beta1`/`apps/v1beta2` StatefulSet과 DaemonSet, `networking.k8s.io/v1beta1` Ingress는 모두 YAML로는 완벽하게 유효하고 예전 클러스터에서도 동작했습니다. 하지만 클러스터를 Kubernetes가 옛 API 그룹을 완전히 제거한 버전 이후로 업그레이드하면, 이를 쓰는 모든 매니페스트가 아무 예고 없이 적용에 실패합니다. 편집하는 동안 이를 잡아 대체할 정확한 apiVersion을 안내받으면 클러스터 업그레이드 도중에 알게 되는 일을 피할 수 있습니다.
나머지는 실제 Kubernetes OpenAPI 스펙을 기준으로 한 스키마 검증이 잡아냅니다. 숫자여야 할 `replicas`가 따옴표 붙은 문자열이 된 경우, 유효 범위를 벗어난 `containerPort`, 매니페스트 사이를 복사해 붙이다가 Deployment의 필수 필드인 `spec.selector`가 지워진 경우 등입니다. 이런 문제는 YAML 구문 오류가 아니라 파일이 정상적으로 파싱되기 때문에, 눈으로 훑어서는 놓치기 쉽고 전용 스키마 검사가 필요한 이유이기도 합니다.
자주 묻는 질문
`kubectl apply --dry-run`이나 `kubeconform`을 대체하나요?
아니요. `kubectl apply --dry-run=server`는 설치된 CRD와 어드미션 웹훅을 포함해 실제 클러스터의 API 서버를 대상으로 실행되는 유일한 검사이고, `kubeconform`/`kubeval`은 CI 파이프라인용으로 잘 만들어진 CLI 도구입니다. 이 도구는 YAML 구문, 스키마 구조, 지원 중단된 apiVersion처럼 같은 종류의 문제를 브라우저 탭에서 확인합니다. `kubectl`을 아직 어디에도 연결하지 않았거나 다른 사람이 보낸 매니페스트를 검토할 때 유용합니다.
스키마는 어디서 가져오나요?
커뮤니티가 관리하며 자동으로 갱신되는 Kubernetes 공식 OpenAPI 기반 JSON Schema 미러인 `yannh/kubernetes-json-schema`에서, 선택한 Kubernetes 버전에 맞는 파일을 공개 CDN에서 필요할 때 내려받습니다. 매니페스트는 어디로도 전송되지 않으며, 해당 종류와 버전을 검증하는 모든 사용자에게 같은 (버전별 공개) 스키마 파일만 내려받습니다.
왜 리소스 종류가 10가지뿐인가요?
Deployment, Service, Ingress, ConfigMap, Secret, StatefulSet, DaemonSet, Job, CronJob, PersistentVolumeClaim이면 직접 작성하는 매니페스트의 대부분을 다룹니다. 다른 종류도 YAML 구문 검사와 지원 중단 apiVersion 감지는 그대로 받지만, 스키마 구조 검증은 아직 제공되지 않습니다.
내 YAML이 브라우저 밖으로 나가나요?
아니요. 파싱과 스키마 검증은 모두 이 탭에서 순수 JavaScript로 실행됩니다. 이 도구가 보내는 네트워크 요청은 선택한 리소스 종류와 Kubernetes 버전의 공개 JSON Schema 파일을 내려받는 것뿐이며, 매니페스트 내용은 전송되지 않습니다.