01
수정 후에는 다시 실행하기
기본 버전은 1.37.0이며 수동으로 실행합니다. 입력, 버전, 들여쓰기 또는 사용자 스키마를 바꾸면 이전 결과의 복사와 다운로드가 즉시 비활성화됩니다. 버튼이나 Ctrl/Cmd+Enter로 현재 내용을 검사하세요.
Kubernetes / Helm
Kubernetes YAML 검증— 문서별 오류와 연결을 함께 확인
대상 버전을 선택하고 필드 진단을 확인한 뒤 필요한 리소스만 내보내세요.
Kubernetes YAML 검증
매니페스트 YAML
리소스와 결과
결과가 오래되어 내보내기가 비활성화되었습니다.
매니페스트와 스키마는 브라우저에서 처리하며 업로드하거나 클러스터에 연결하지 않습니다.
결과가 오래되어 내보내기가 비활성화되었습니다.
정적 검사는 배포 성공을 보장하지 않습니다. 검증 오류가 있어도 YAML을 내보낼 수 있으므로 진단을 먼저 확인하세요.
Kubernetes YAML 검증은 들여쓰기가 맞는데도 배포 파일 검토가 끝나지 않을 때 유용합니다. 문법이 올바른 YAML에도 replicas의 잘못된 타입이나 오타가 있는 필드가 들어갈 수 있습니다. 문서 번호와 리소스 이름을 함께 보면 어느 객체를 고쳐야 하는지 알 수 있습니다.
이 YAML 검증기는 렌더링이 끝난 쿠버네티스 매니페스트를 대상으로 합니다. 1.35.0, 1.36.0, 1.37.0의 고정된 정의 중 하나를 선택하며, 로컬 kubeconfig를 읽어 버전을 추측하거나 서버 기본값을 추가하지 않습니다.
Kubernetes YAML 검증이 돕는 검토
오류가 속한 리소스를 놓치지 않기
Kubernetes YAML 검증은 각 문서를 kind, 네임스페이스, 이름과 함께 목록으로 보여 줍니다. 진단에는 문서 번호, 행과 열, 필드 경로가 남습니다. 리소스를 선택하면 해당 문서의 정리된 YAML을 볼 수 있지만 전체 입력은 그대로 유지되어 다른 문서의 오류도 함께 점검할 수 있습니다.
입력 안에서 확인 가능한 연결 보기
Service 선택자는 같은 네임스페이스의 Pod 및 워크로드 템플릿 라벨과 비교합니다. 환경 변수와 볼륨의 ConfigMap, Secret 참조도 찾습니다. 입력에 없는 대상은 클러스터에 이미 있을 수 있으므로 연결 실패로 단정하지 않고 경고로 표시합니다.
버전과 출력 범위를 확인하는 순서
02
사용자 리소스의 정확한 종류 지정하기
사용자 스키마 패널에 apiVersion, kind와 draft-07 JSON Schema를 넣으세요. 종류가 정확히 일치하는 객체에만 적용합니다. 내부 참조는 지원하지만 제공하지 않은 외부 참조는 자동으로 가져오지 않고 오류로 처리합니다.
03
적용과 내보내기를 구분하기
서식 정리와 파일 병합은 바뀔 문자 수와 문서 수를 미리 보여 줍니다. 적용을 눌러야 입력이 바뀌며 한 번 되돌리면 입력과 이전 결과가 함께 복원됩니다. 내보내기는 전체 문서 또는 선택한 리소스만 대상으로 합니다.
문법 확인 이후에 필요한 정보
버전별 스키마 검증
Kubernetes OpenAPI에서 생성한 상위 저장소의 전체 정의를 고정해 사용합니다. 추가 필드, 필수 필드와 타입을 검사하며 리소스당 첫 번째 스키마 위반을 표시합니다. 하나를 수정하면 다음 오류가 드러날 수 있으므로 다시 실행해야 합니다.
이름과 중복 객체 구분
일반적인 리소스에는 DNS 이름 규칙을, RBAC에는 경로 구간 규칙을 적용합니다. API 그룹, kind, 네임스페이스와 이름이 같으면 API 버전이 달라도 같은 객체로 봅니다. 별도 이름 규칙을 확인하지 못하는 kind에는 경고를 남깁니다. Job 이름은 63자, CronJob 이름은 52자까지 허용합니다.
템플릿 내부의 설정 참조 확인
Pod 외에도 Deployment, StatefulSet, DaemonSet, Job, CronJob 등의 템플릿을 살펴봅니다. 컨테이너 환경 변수, 일반 볼륨과 투사 볼륨의 참조가 대상입니다. 설정의 개별 키 존재 여부나 실제 서비스 연결 상태는 검사하지 않습니다.
주석과 문서 경계 유지
JSON으로 바꿨다가 되돌리는 대신 YAML 구문 트리를 정리합니다. 주석, 앵커와 수치의 원래 표기를 보존하며 개별 문서를 분리해 저장할 수 있습니다. 리소스 순서 변경, 필드 삭제, 문자열 타입 변환은 자동 수행하지 않습니다.
검증 결과를 해석할 때의 한계
- 서버 승인이나 실행 성공은 별개
- CEL, webhook, RBAC, 스케줄링, 이미지 가져오기와 기능 게이트를 실행하지 않습니다. 서버 기본값도 주입하지 않습니다. Service 이름은 영문자로 시작하는 기본 규칙을 사용하며 완화된 이름 기능을 모방하지 않습니다.
- 모르는 리소스를 통과시키지 않음
- 일치하는 apiVersion/kind 정의가 없으면 미검증으로 남습니다. 사용자 schema를 직접 제공해야 하며 CRD에서 자동 추출하거나 원격 참조를 내려받지 않습니다. Helm과 Kustomize 템플릿은 먼저 다른 도구에서 렌더링하세요.
- List 래퍼는 문서 스트림과 다름
- 여러 리소스는 ---로 구분하세요. List 또는 List로 끝나는 래퍼의 items는 펼치지 않으며 각각 검증했다고 표시하지 않습니다. 빈 문서는 리소스 목록에서 빠지지만 나머지 문서의 원래 번호는 유지됩니다.
- 입력과 실행 비용 제한
- 최대 500,000자, 100문서, 중첩 100단계, 파싱 노드 50,000개와 진단 1,000개를 허용합니다. 작업 스레드는 8초 후 중지됩니다. 중복 키, 미지원 태그, 과도한 별칭 확장과 안전하지 않은 정수는 명시적으로 거부합니다.
- 내보내기는 검토 완료 표시가 아님
- 구조 오류가 있는 작업 중 문서도 서식화된 YAML로 저장할 수 있습니다. 문법 오류나 오래된 결과는 내보내지 못합니다. 공백이나 흐름 형식은 바뀔 수 있으므로 입력에 적용하기 전에 미리 보기를 확인하세요.
Kubernetes YAML 검증 질문과 답변
YAML에서 들여쓰기는 왜 중요한가요?
들여쓰기가 매핑과 목록의 계층을 결정하기 때문입니다. Kubernetes YAML 검증은 문법뿐 아니라 그 결과 만들어진 리소스 구조도 검사합니다. 문법상 유효해도 잘못된 부모 아래에 필드가 들어가면 schema 오류가 날 수 있습니다.
YAML에서 탭을 사용해도 되나요?
들여쓰기에 탭을 쓰면 파싱 오류가 발생할 수 있습니다. 공백을 사용하세요. 출력은 기본 2칸 또는 선택한 4칸으로 정리하지만 문자열 안의 탭을 임의로 삭제하는 기능은 아닙니다. 파싱이 안 되는 입력은 먼저 직접 수정해야 합니다.
민감한 설정을 입력해도 되나요?
입력과 사용자 스키마는 브라우저 작업 스레드에서 처리하며 서버로 보내거나 영구 저장하지 않습니다. 페이지의 프로그램과 정의는 사이트에서 읽지만 입력에 적힌 URL로 요청하지 않습니다. 복사나 다운로드한 파일은 사용자가 관리해야 합니다.
정상이라고 나오면 바로 배포해도 되나요?
정적 검사 범위에서 문제가 없다는 뜻입니다. 실제 클러스터의 권한, 승인 정책, 리소스 상태, 이미지 가용성은 확인하지 않습니다. 특히 경고 없이 통과하더라도 서버 검증과 배포 절차를 생략하는 근거가 되지는 않습니다.
입력 크기와 중첩 깊이를 제한하는 이유는 무엇인가요?
깊은 구조와 별칭 확장은 작은 입력도 큰 계산으로 만들 수 있습니다. 문자와 문서 수뿐 아니라 노드 수, 깊이와 실행 시간도 제한합니다. 제한에 걸리면 파일을 나누거나 스키마를 단순하게 한 뒤 다시 확인하세요.
올바르게 처리되지 않는 설정이 있나요?
다음 매니페스트 확인
Kubernetes YAML 검증 결과와 선택한 버전을 함께 검토 기록에 남기세요. 변경 후 다시 검사하고 필요한 문서만 다음 단계로 전달할 수 있습니다.