인프런 커뮤니티 질문&답변

안녕하세요.

쿠버네티스에서 네이밍과 레이블의 이름들을 잘 만드는 건 중요합니다.

하지만 자바처럼 공식적이고 명료한 네이밍 컨벤션은 없기 때문에 인터넷에서 딱 마음에 드는 내용은 찾기 힘들꺼예요.

그래서 먼저 쿠버네티스 공식 문서로 리소스의 이름과 레이블/셀렉터의 이름 규칙에 대해서 대략적으로 알아야 하고

• 쿠버네티스 공식 문서

이름 생성 규칙 : https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/names/

레이블과 셀렉터 규칙 : https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels/

다른 공식 오픈소스들에서는 어떻게 네이밍을 했는지 살펴봐야 합니다. 결국 마이크로 서비스 상에서의 트리구조인 기능들을 잘 표현할 수 있는 이름을 작명하는 게 가장 중요하고요. 결국 이름 자체는 소문자와 숫자 그리고 하이픈(-)을 사용해서 만듭니다.

• 제 다른 강의에서 Promethues를 가지고 정리한 내용

그리고 현업에서 더 다양한 방법으로 만들기 때문에 말씀드리면 더 혼란이 가중될 꺼예요.

예를들어 frontend-service, database-deployment, redis-pod 이런식으로 리소스 유형을 포함 시켜서 만들기도 하고요.

그리고 dev-frontend, prod-database 같이 각 환경에 따라서 접두사를 추가하기도 합니다.

그리고 api-server-v2, frontend-v1.3 이렇게 리소스 버전을 붙이기도 하고요.

또, 그리고 us-east-db-replica, eu-cache 등 식으로 클라우드 환경에서는 지리적인 영역을 접두사에 포함하기도 합니다.

또, 그리고 payment-system-queue, payment-system-db 처럼 각 시스템 별로 접두사를 주기도 해요.

그래서 이렇게 이름(라벨/셀렉터)를 통해서 그 시스템이 어떤 건지 명확하게 알 수 있게 만드는 게 중요하고요. 명령 규칙만 보자면 쿠버네티스 공식 문서에 아래 내용이 전부입니다.

• 253자를 넘지 말아야 한다.

• 소문자와 영숫자 - 또는 . 만 포함한다.

• 영숫자로 시작한다.

• 영숫자로 끝난다.

그리고 위 규칙은 Service의 경우 기능적으로 이 리소스 이름 자체가 DNS 이름으로도 쓰이기 때문에, 결국 우리가 인터넷에서 도메인으로 본 이름들이 쓰인다고 볼 수 있어요.

좀 느낌이 오셨나요?