Namespace & Annotation

본 포스팅은 Kubernetes Official Documents를 기반으로 한다.

https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/namespaces/

 

네임스페이스

쿠버네티스에서, 네임스페이스 는 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 하며, 네임스페이스 간에서 유일할 필요는

kubernetes.io


# Namespace

네임스페이스는 쿠버네티스에서 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공한다.

 

리소스의 이름은 네임스페이스 안에서 유일해야 하지만, 네임스페이스 간에는 유일할 필요는 없다.

 

네임스페이스 기반 스코핑은 네임 스페이스 기반 오브젝트(예: Deployment, Service 등)에만 적용 가능하며, 클러스터 범위 오브젝트(예: 스토리지클래스, Node, PV)에는 적용이 불가능하다.


여러 개의 네임스페이스를 사용하는 경우

네임스페이스는 여러 개의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록 만들어졌다. 

사용자가 거의 없거나, 수 십명 정도가 되는 경우에는 네임스페이스를 전혀 고려할 필요가 없다. 

 

네임스페이스는 이름의 범위를 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야하지만, 네임스페이스를 통틀어서 유일할 필요는 없다. 네임스페이스는 서로 중첩될 수 없으며, 각 쿠버네티스 리소스는 하나의 네임스페이스에만 있을 수 있다.

 

네임스페이스는 클러스터 자원을 (리소스 쿼터를 통해) 여러 사용자 사이에서 나누는 방법이다.

 

동일한 소프트웨어의 다른 버전과 같이 약간 다른 리소스를 분리하기 위해 여러 네임스페이스를 사용할 필요는 없다.

 

동일한 네임스페이스 내에서 리소스를 구별하기 위해선 일반적으로 레이블을 사용한다.

참고: 프로덕션 클러스터의 경우, default 네임스페이스를 사용하지 않는 것을 고려한다. 대신에, 다른 네임스페이스를 만들어 사용한다.

초기 네임스페이스

쿠버네티스는 처음에 네 개의 초기 네임스페이스를 갖는다.

 

# default

쿠버네티스에는 이 네임스페이스가 포함되어 있으므로 먼저 네임스페이스를 생성하지 않고도 새 클러스터를 사용할 수 있다.

# kube-node-lease

이 네임스페이스는 각 노드와 연관된 리스 오브젝트를 갖는다. 노드 리스는 kubelet이 하트비트를 보내서 컨트롤 플레인이 노드의 장애를 탐지할 수 있게 한다.

# kube-public

이 네임스페이스는 모든 클라이언트(인증되지 않은 클라이언트 포함)가 읽기 권한으로 접근할 수 있다. 이 네임스페이스는 주로 전체 클러스터 중에 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다. 이 네임스페이스의 공개적인 성격은 단지 관례이지 요구 사항은 아니다.

# kube-system

쿠버네티스 시스템에서 생성한 오브젝트를 위한 네임스페이스.


# 네임스페이스 다루기

참고: kube- 접두사로 시작하는 네임스페이스는 쿠버네티스 시스템용으로 예약되어 있으므로, 사용자는 이러한 네임스페이스를 생성하지 않는다.

네임 스페이스 조회

사용 중인 클러스터의 현재 네임스페이스를 나열할 수 있다.

kubectl get namespace
NAME              STATUS   AGE
default           Active   1d
kube-node-lease   Active   1d
kube-public       Active   1d
kube-system       Active   1d

요청에 네임스페이스 설정(지정)하기

현재 요청에 대한 네임스페이스를 설정하기 위해서 --namespace 플래그를 사용한다.

 

예를 들면,

kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
kubectl get pods --namespace=<insert-namespace-name-here>

또는, -n 플래그로 이를 축약해서 사용할 수 있다.


선호하는 네임스페이스 설정하기

아래의 명령을 입력하면 모든 kubectl 명령에서 사용하는 네임스페이스를 Context에 영구적으로 저장할 수 있다.

kubectl config set-context --current --namespace=<insert-namespace-name-here>
# 확인하기
kubectl config view --minify | grep namespace:

# 네임스페이스와 DNS

서비스를 생성하면 해당 DNS 엔트리가 생성된다. 

 

이 엔트리는 <서비스-이름>.<네임스페이스-이름>.svc.cluster.local의 형식을 갖는데, 이는 컨테이너가 <서비스-이름>만 사용하는 경우, 네임스페이스 내에 국한된 서비스로 연결된다.

 

즉, 쿠버네티스 내부에서 서로 다른 네임스페이스에 위치하는 요소들 간의 DNS 통신이 기본적으로 가능하다. CoreDNS의 위대함

 

개발, 스테이징, 운영과 같이 여러 네임스페이스 내에서 동일한 설정을 사용하는 경우에 유용하다. 

 

네임스페이스를 넘어서 접근하기 위해서는, 전체 주소 도메인 이름(FQDN - Full Qualified Domain Name)을 사용해야 한다.

 

그렇기 때문에, 모든 네임스페이스 이름은 유효한 RFC 1123 DNS 레이블이어야 한다.


# 모든 오브젝트가 네임스페이스에 속하지는 않음

대부분의 쿠버네티스 리소스(예를 들어, 파드, 서비스, 레플리케이션 컨트롤러 외)는 네임스페이스에 속한다. 

하지만 네임스페이스 리소스 자체는 네임스페이스에 속하지 않는다. 

 

그리고 노드나 퍼시스턴트 볼륨과 같은 저수준 리소스는 어느 네임스페이스에도 속하지 않는다.

 

다음은 네임스페이스에 속하지 않는 쿠버네티스 리소스를 조회하는 방법이다.

# 네임스페이스에 속하는 리소스
kubectl api-resources --namespaced=true

# 네임스페이스에 속하지 않는 리소스
kubectl api-resources --namespaced=false

네임 스페이스 리소스들!


# Annotaion

쿠버네티스 어노테이션을 사용하여 임의의 비-식별 메타데이터를 오브젝트에 첨부할 수 있다. 도구 및 라이브러리와 같은 클라이언트는 이 메타 데이터를 검색할 수 있다.


오브젝트에 메타 데이터 첨부

레이블이나 어노테이션을 사용하여 쿠버네티스 오브젝트에 메타 데이터를 첨부할 수 있다. 레이블을 사용하여 오브젝트를 선택하고, 특정 조건을 만족하는 오브젝트 컬렉션을 찾을 수 있다.

 

반면에, 어노테이션은 오브젝트를 식별하고 선택하는데 사용되지 않는다. 어노테이션의 메타 데이터는 작거나 크고 구조적이거나 구조적이지 않을 수 있으며, 레이블에서 허용되지 않는 문자를 포함할 수 있다.

 

어노테이션은 레이블과 같이 키/값 맵이다.

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}
참고: 맵의 키와 값은 문자열이어야 한다. 다르게 말해서, 숫자, 불리언(boolean), 리스트 등의 다른 형식을 키나 값에 사용할 수 없다.

다음은 어노테이션에 기록할 수 있는 정보의 예제이다.

 

  • 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은 클라이언트 또는 서버가 설정한 기본 값, 자동 생성된 필드, 그리고 오토사이징 또는 오토스케일링 시스템에 의해 설정된 필드와 구분된다.
  • 빌드, 릴리스, 또는 타임 스탬프, 릴리스 ID, git 브랜치, PR 번호, 이미지 해시 및 레지스트리 주소와 같은 이미지 정보.
  • 로깅, 모니터링, 분석 또는 감사 리포지터리에 대한 포인터.
  • 디버깅 목적으로 사용될 수 있는 클라이언트 라이브러리 또는 도구 정보: 예를 들면, 이름, 버전, 그리고 빌드 정보.
  • 다른 생태계 구성 요소의 관련 오브젝트 URL과 같은 사용자 또는 도구/시스템 출처 정보.
  • 경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트
  • 책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은 해당 정보를 찾을 수 있는 디렉터리 진입점.
  • 행동을 수정하거나 비표준 기능을 수행하기 위한 최종 사용자의 지시 사항.

어노테이션을 사용하는 대신, 이 유형의 정보를 외부 데이터베이스 또는 디렉터리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한 공유 클라이언트 라이브러리와 도구 생성을 훨씬 더 어렵게 만들 수 있다.

 


문법과 캐릭터 셋

어노테이션은 키 & 값 쌍이다. 유효한 어노테이션 키에는 두 개의 세그먼트가 있다. 두 개의 세그먼트는 선택적인 접두사와 이름이며, 슬래시로 구분된다.

이름 세그먼트는 필수이며, 영문 숫자로 시작하고 최대 길이는 63자 이하여야 한다. 사이에 대시(-), 밑줄(\_), 점(.)이 들어갈 수 있다.

접두사는 선택적이다. 지정된 경우, 접두사는 DNS 서브 도메인이어야 한다. 점으로 구분된 일련의 DNS 레이블은 총 253자를 넘지 않고, 뒤에 슬래시(/)가 붙는다.

 

접두사가 생략되면, 어노테이션 키는 사용자에게 비공개로 간주된다. 최종 사용자 오브젝트에 어노테이션을 추가하는 자동화된 시스템 구성 요소(`kube-scheduler, kube-controller-manager, kube-apiserver, kubectl, 또는 다른 서드파티 자동화 도구`)는 접두사를 지정해야 한다.

 

kubernetes.io/와 k8s.io/ 접두사는 쿠버네티스 핵심 구성 요소를 위해 예약되어 있다.

 

다음은 imageregistry: https://hub.docker.com/ 어노테이션이 있는 파드의 구성 파일 예시이다.

apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "https://hub.docker.com/"
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
728x90
반응형