오브젝트 이름과 ID
클러스터의 각 오브젝트는 해당 유형의 리소스에 대하여 고유한 이름 을 가지고 있다. 또한, 모든 쿠버네티스 오브젝트는 전체 클러스터에 걸쳐 고유한 UID 를 가지고 있다.
예를 들어, 이름이 myapp-1234
인 파드는 동일한 네임스페이스 내에서 하나만 존재할 수 있지만, 이름이 myapp-1234
인 파드와 디플로이먼트는 각각 존재할 수 있다.
유일하지 않은 사용자 제공 속성의 경우 쿠버네티스는 레이블과 어노테이션을 제공한다.
이름
쿠버네티스에서 동일한 물리 클러스터컨테이너화된 애플리케이션을 실행하는 {{< glossary_tooltip text=“노드” term_id=“node” >}}라고 하는 워커 머신의 집합. 모든 클러스터는 최소 한 개의 워커 노드를 가진다. 에서 다중의 가상 클러스터를 지원하기 위해 사용하는 추상화.
네임스페이스는 클러스터의 오브젝트를 체계화하고 클러스터의 리소스를 분리하는 방법을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 한다. 그러나, 네임스페이스 간에서 유일할 필요는 없다.
다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.
DNS 서브도메인 이름
대부분의 리소스 유형에는 RFC 1123에 정의된 대로 DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다. 이것은 이름이 다음을 충족해야 한다는 것을 의미한다.
- 253자를 넘지 말아야 한다.
- 소문자와 영숫자
-
또는.
만 포함한다. - 영숫자로 시작한다.
- 영숫자로 끝난다.
DNS 레이블 이름
일부 리소스 유형은 RFC 1123에 정의된 대로 DNS 레이블 표준을 따라야 한다. 이것은 이름이 다음을 충족해야 한다는 것을 의미한다.
- 최대 63자이다.
- 소문자와 영숫자 또는
-
만 포함한다. - 영숫자로 시작한다.
- 영숫자로 끝난다.
경로 세그먼트 이름
일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수 있어야 한다. 즉 이름이 “.” 또는 “..“이 아닐 수 있으며 이름에는 “/” 또는 “%“가 포함될 수 없다.
아래는 파드의 이름이 nginx-demo
라는 매니페스트 예시이다.
apiVersion: v1
kind: Pod
metadata:
name: nginx-demo
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
참고: 일부 리소스 유형은 이름에 추가적인 제약이 있다.
UID
오브젝트를 중복 없이 식별하기 위해 쿠버네티스 시스템이 생성하는 문자열.
쿠버네티스 클러스터가 구동되는 전체 시간에 걸쳐 생성되는 모든 오브젝트는 서로 구분되는 UID를 갖는다. 이는 기록 상 유사한 개체의 출현을 서로 구분하기 위함이다.
쿠버네티스 UID는 보편적으로 고유한 식별자이다(또는 UUID라고 한다). UUID는 ISO/IEC 9834-8 과 ITU-T X.667 로 표준화 되어 있다.
다음 내용
- 쿠버네티스의 레이블에 대해 읽기.
- 쿠버네티스의 식별자와 이름 디자인 문서 읽기.
피드백
이 페이지가 도움이 되었나요?
피드백 감사합니다. 쿠버네티스 사용 방법에 대해서 구체적이고 답변 가능한 질문이 있다면, 다음 링크에서 질문하십시오. Stack Overflow. 원한다면 GitHub 리포지터리에 이슈를 열어서 문제 리포트 또는 개선 제안이 가능합니다..