01
레이블을 읽을 위치 정하기
리소스 모드는 단일 객체, 배열, items 배열을 가진 List 또는 이름이 List로 끝나는 종류를 받습니다. metadata.labels만 읽으며 Deployment의 Pod 템플릿 내부는 자동으로 찾지 않습니다.
Kubernetes
쿠버네티스 레이블 셀렉터조건별 일치 이유 확인
레이블 문법을 확인한 뒤 각 리소스가 어떤 조건을 만족하는지 살펴보세요.
쿠버네티스 레이블 셀렉터
일치 결과
입력은 이 브라우저에서만 처리합니다. 클러스터 연결, 업로드, 네트워크 조회는 하지 않습니다.
입력 설정과 지원 문법
= · == · != · in · notin · key · !key. 쉼표는 AND 조건이며 빈 셀렉터는 모든 입력과 일치합니다.
한도: JSON 500,000자, 셀렉터 8,192자, 리소스 500개, 조건 64개, 리소스당 레이블 256개.
의미 기준: Kubernetes 1.35 / apimachinery v0.35.0의 일치, 집합, 존재 조건.
입력이 변경되었습니다. 다시 테스트한 뒤 내보내세요.
쿠버네티스 레이블 셀렉터 검사에서 예상보다 많은 Pod가 선택된다면 빠진 키부터 확인해 보세요. env!=prod는 다른 환경뿐 아니라 env가 아예 없는 객체도 선택합니다. 전체 일치 수만으로는 이 차이를 알아내기 어렵습니다.
레이블 맵 모드는 객체 자체를 읽고, 리소스 모드는 metadata.labels만 읽습니다. 각 모드의 입력은 따로 보관합니다. 따라서 metadata라는 이름의 레이블을 리소스 구조로 잘못 해석하지 않습니다.
쿠버네티스 레이블 셀렉터 결과를 자세히 확인하는 이유
실패한 조건을 리소스별로 찾기
쿠버네티스 레이블 셀렉터 테스트는 첫 실패에서 멈추지 않고 모든 조건을 평가합니다. 개발 환경의 웹 Pod가 app=web과 !paused를 통과하더라도 환경 집합 조건은 실패할 수 있습니다. 어느 키를 다시 확인해야 하는지 결과에서 바로 알 수 있습니다.
빈 값과 키 누락을 다르게 보기
값이 빈 문자열인 레이블도 존재하는 키입니다. 키 자체가 없는 경우에는 값도 없습니다. 보고서에서 실제 문자열과 키 없음을 구분하므로, 부정 조건을 존재 여부 검사처럼 오해하지 않고 읽을 수 있습니다.
예상치 못한 선택을 줄이는 세 가지 확인
02
키를 지운 반례도 시험하기
예제의 production을 development로 바꾸고 environment 키도 삭제해 보세요. in과 notin이 어떻게 달라지는지 확인할 수 있습니다. 자동 모드는 입력이 멈춘 뒤 350ms에 실행되고 수동 모드는 Ctrl/Cmd + Enter를 지원합니다.
03
펼친 결과와 내보낼 범위 확인하기
리소스를 펼치면 레이블과 각 조건의 결과가 보입니다. 화면에는 50개씩 추가되지만 복사와 다운로드에는 전체 결과가 담깁니다. 입력을 바꾸면 내보내기가 즉시 비활성화되며 새 검사가 끝나야 사용할 수 있습니다.
문법 검증부터 일치 설명까지
키와 값에 맞는 규칙 적용
선택적 DNS 접두사는 소문자이며 최대 253자입니다. 이름 부분은 1~63자의 영숫자로 시작하고 끝나며 중간에는 -_.도 허용합니다. 값은 최대 63자이고 빈 문자열도 가능합니다. 예약된 접두사는 문법상 유효하면 통과합니다.
일치성 기준과 집합성 기준 조합
=와 ==는 같은 값인지, !=는 다른 값인지 확인합니다. 집합성 기준 in과 notin은 후보 값 목록을 사용합니다. 쉼표로 나눈 조건은 모두 만족해야 하며, 같은 키의 여러 후보는 하나의 in에 넣어야 합니다.
객체를 빠뜨리지 않는 배치 결과
입력 순서와 JSON 경로, 제공된 종류·네임스페이스·이름을 보존합니다. metadata나 labels가 없거나 null이면 빈 맵으로 처리합니다. 이름이 같아도 항목을 합치지 않으므로 중복 이름 때문에 결과가 사라지지 않습니다.
값의 타입을 임의로 바꾸지 않기
kubectl 레이블 쿼리에서 "01"과 "1"은 다른 문자열입니다. 숫자, 불리언, null을 문자열로 바꾸지 않고 오류로 표시합니다. 중복 JSON 키도 거부하므로 뒤의 값이 앞의 값을 덮어쓴 상태로 검사하지 않습니다.
지원하는 입력과 판단의 한계
- 문자열 문법의 정해진 범위
- Kubernetes 1.35 / apimachinery v0.35.0의 일치, 집합, 존재 조건을 기준으로 합니다. 숫자 < 또는 >, 서로 다른 키의 OR, 와일드카드, 정규식, 필드 셀렉터, 노드 어피니티는 지원하지 않습니다.
- 모드를 지정한 엄격한 JSON
- 주석과 끝 쉼표는 허용하지 않습니다. YAML, 파일 업로드, URL 읽기, 구조화된 matchLabels나 matchExpressions도 받지 않습니다. List 종류에는 items 배열이 필요하며 일반 리소스의 임의 필드를 목록으로 추측하지 않습니다.
- 한도를 넘거나 잘못된 값이 있으면 전체 중단
- JSON 500,000자, 표현식 8,192자, 리소스 500개, 조건 64개, 리소스당 레이블 256개까지입니다. 문자 수는 UTF-16 코드 단위입니다. JSON 깊이 100, 노드 50,000, 숫자 길이 1,000 제한도 적용합니다. 일부만 성공한 보고서를 내보내지 않습니다.
- 빈 문자열의 의미는 API마다 다를 수 있음
- 이 도구의 빈 셀렉터 문자열은 빈 맵을 포함한 모든 유효한 입력과 일치합니다. 빈 JSON 입력란은 데이터가 없는 상태이므로 빈 맵은 {}로 적어야 합니다. Service의 빈 selector나 구조화된 null 셀렉터도 같은 의미라고 판단해서는 안 됩니다.
- 클러스터 상태를 보증하지 않는 스냅샷
- 보고서에는 식별 정보, 레이블, 조건 결과만 포함하며 나머지 리소스 필드는 제외합니다. 레이블 수정, Pod 템플릿 추출, 준비 상태·엔드포인트·라우팅·컨트롤러 소유권 검사는 수행하지 않습니다. 선택 결과가 맞아도 실제 통신은 별도로 확인해야 합니다.
쿠버네티스 레이블 셀렉터 자주 묻는 질문
여러 레이블로 Pod를 조회하려면 어떻게 하나요?
app=web,environment=production처럼 쉼표로 연결합니다. 두 조건을 모두 만족해야 합니다. app.kubernetes.io/name 같은 키는 접두사까지 써야 하며 단순한 name과 같은 키가 아닙니다.
조건 사이에 OR를 쓸 수 있나요?
서로 다른 키를 OR로 연결하는 문법은 없습니다. 같은 키의 대안은 environment in (production,staging)처럼 씁니다. 같은 키에 두 개의 등식 조건을 쓰면 동시에 두 값을 요구하므로 결과가 없을 수 있습니다.
값 없이 키만 있는 레이블도 가능한가요?
JSON에서는 {"maintenance":""}로 나타냅니다. maintenance는 존재 여부, maintenance=는 존재하는 빈 값, !maintenance는 키 누락을 검사합니다. 문자열 문법의 maintenance in ()도 빈 문자열 하나를 가진 집합이므로 존재하는 빈 값에 일치합니다.
Service에 엔드포인트가 없으면 셀렉터 문제인가요?
원인 중 하나일 수 있습니다. 먼저 예상 Pod가 모든 레이블 조건을 만족하는지 확인한 다음 클러스터의 네임스페이스, 준비 상태와 엔드포인트를 살펴보세요. 이 도구는 붙여 넣은 레이블만 검사하며 통신 가능 여부를 판단하지 않습니다.
env가 없는데 env!=prod와 일치하는 이유는 무엇인가요?
!=와 notin은 누락된 키도 포함합니다. env가 반드시 있고 prod가 아닌 값이어야 한다면 env,env!=prod를 사용하세요. 조건 설명은 키 누락과 다른 값이 존재하는 경우를 구분해서 보여 줍니다.
아직 해결하지 못한 질문이 있나요?