클러스터의 각 오브젝트는 해당 유형의 리소스에 대하여 고유한 이름을 가지고 있다. 모든 쿠버네티스 오브젝트는 전체 클러스터에 걸쳐 고유한 UID를 가지고 있다.
예를 들어, 동일한 네임스페이스 안에서는 myapp-1234라는 이름의 파드를 하나만 가질 수 있지만, myapp-1234라는 이름의 파드와 디플로이먼트(Deployment)는 각각 하나씩 가질 수 있다.
고유하지 않은 사용자 제공 속성의 경우 쿠버네티스는 레이블과 어노테이션을 제공한다.
/api/v1/pods/some-name과 같이, 리소스 URL에서 오브젝트를 가리키는 클라이언트 제공 문자열.
특정 시점에 같은 종류(kind) 내에서는 하나의 이름은 하나의 오브젝트에만 지정될 수 있다. 하지만, 오브젝트를 삭제한 경우, 삭제된 오브젝트와 같은 이름을 새로운 오브젝트에 지정 가능하다.
이름은 동일한 리소스의 모든 API 버전에서 고유해야 한다.
쿠버네티스는 네 가지 속성의 조합을 사용해 오브젝트를 고유하게 식별한다.
apps)deployments)서로 다른 API 버전 (예: v1 또는 v1beta1)을 통해 리소스에 접근할 수 있지만, 버전은 단순히 동일한 기본 오브젝트를 다르게 표현한 것이다. 버전은 고유 식별의 일부가 아니기 때문에, 서로 다른 API 버전을 사용해 같은 네임스페이스에서 동일한 이름과 리소스 타입을 가진 두 개의 오브젝트를 생성할 수 없다.
리소스 생성 요청에서 name 대신 generateName이 제공되면 서버가 이름을 생성할 수 있다.
generateName이 사용되면, 제공된 값이 이름 접두사로 사용되고, 서버는 여기에 생성된 접미사를
추가한다. 이름이 생성되더라도 기존 이름과 충돌하여 HTTP 409 응답이 발생할 수 있다. 이러한 충돌은
쿠버네티스 v1.31 이상에서 발생할 가능성이 훨씬 낮아졌는데, 서버가 HTTP 409 응답을 반환하기 전에
고유한 이름을 생성하기 위해 최대 8번 시도하기 때문이다.
다음은 리소스에 일반적으로 사용되는 네 가지 이름 제약 조건 타입이다.
대부분의 리소스 타입은 RFC 1123에 정의된 DNS 서브도메인 이름으로 사용할 수 있는 이름을 요구한다. 이는 이름이 다음을 충족해야 함을 의미한다.
- 또는 .만 포함해야 한다.일부 리소스 타입은 이름이 RFC 1123에 정의된 DNS 레이블 표준을 따르도록 요구한다. 이는 이름이 다음을 충족해야 함을 의미한다.
-만 포함해야 한다.RelaxedServiceNameValidation 기능 게이트가 활성화된 경우,
서비스 오브젝트 이름은 숫자로 시작할 수 있다.일부 리소스 타입은 이름이 RFC 1035에 정의된 DNS 레이블 표준을 따르도록 요구한다. 이는 이름이 다음을 충족해야 함을 의미한다.
-만 포함해야 한다.RelaxedServiceNameValidation
기능 게이트가 서비스 오브젝트에 활성화된 경우이며, 이 경우 서비스 이름이 숫자로 시작할 수 있다.일부 리소스 타입은 이름을 경로 세그먼트로 안전하게 인코딩할 수 있어야 한다. 다시 말해, 이름은 "." 또는 ".."일 수 없으며 "/" 또는 "%"를 포함할 수 없다.
다음은 nginx-demo라는 이름의 파드에 대한 매니페스트 예시이다.
apiVersion: v1
kind: Pod
metadata:
name: nginx-demo
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
오브젝트를 중복 없이 식별하기 위해 쿠버네티스 시스템이 생성하는 문자열.
쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록상 유사한 오브젝트의 출현을 서로 구분하기 위함이다.
쿠버네티스 UID는 보편적으로 고유한 식별자이다(UUID라고도 한다). UUID는 ISO/IEC 9834-8과 ITU-T X.667로 표준화되어 있다.