[kubernetes] NameSpace & Label & Annotation

728x90

Namespace

리소스를 분리(격리)한다.

서비스 별
사용자 별
환경: 개발, 스테이징, 프로덕션

서비스: NDS 이름이 분리되는 용도

RBAC: 권한을 NS 에 설정

[~]$ kubectl get namespace
NAME              STATUS   AGE
default           Active   23h
kube-node-lease   Active   23h
kube-public       Active   23h
kube-system       Active   23h

kube-system: Kubernetes 의 핵심 컴포넌트
kube-public: 모든 사용자가 읽기 권한
kube-node-lease: Worker Node 에 장애가 발생했는지 확인
default: 기본 작업 공간

kubectl create ns developments
kubectl delete ns developments

kubectl get pods -A | --all-namespaces
kubectl get pods -n kube-system

ns-dev.yml

apiVersion: v1
kind: Namespace
metadata:
  name: dev

kubectl create -f ns-dev.yml

myweb-dev.yml

apiVersion: v1
kind: Pod
metadata:
  name: myweb
  namespace: dev
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
      - containerPort: 80
        name: myweb
        protocol: TCP

레이블과 셀렉터

공식 문서: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels/

레이블 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이다. 레이블은 오브젝트의 특성을 식별하는 데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없다. 레이블로 오브젝트의 하위 집합을 선택하고, 구성하는데 사용할 수 있다. 레이블은 오브젝트를 생성할 때에 붙이거나 생성 이후에 붙이거나 언제든지 수정이 가능하다. 오브젝트마다 키와 값으로 레이블을 정의할 수 있다. 오브젝트의 키는 고유한 값이어야 한다.

"metadata": {
  **"labels"**: {
    **"key1"** : "value1",
    **"key2"** : "value2"
  }
}

레이블은 UI와 CLI에서 효율적인 쿼리를 사용하고 검색에 사용하기에 적합하다. 식별되지 않는 정보는 어노테이션으로 기록해야 한다.

권장 레이블

권장 레이블 공식 문서: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/common-labels/

레이블은 주로 검색을 하거나 리소스를 연결할 때 사용한다.

레이블 명령어

레이블 확인

kubectl get pods --show-labels

kubectl get pods <파드_이름> -o yaml

kubectl describe pods <파드_이름>

레이블 관리

kubectl label pods <파드_이름> Key=Value # key 추가

kubectl label pods <파드_이름> Key=Value --overwrite # value 덮어쓰기

kubectl label pods <파드_이름> Key-   # key 삭제

YAML 파일에서 label

apiVersion: v1
kind: Pod
metadata:
  name: myweb
  namespace: dev
  labels:
    APP: apache
    ENV: dev
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
      - containerPort: 80
        name: myweb
        protocol: TCP

사용 동기

레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.

서비스 배포와 배치 프로세싱 파이프라인은 흔히 다차원의 엔티티들이다(예: 다중 파티션 또는 배포, 다중 릴리스 트랙, 다중 계층, 계층 속 여러 마이크로 서비스들). 관리에는 크로스-커팅 작업이 필요한 경우가 많은데 이 작업은 사용자보다는 인프라에 의해 결정된 엄격한 계층 표현인 캡슐화를 깨트린다.

레이블 예시:

"release" : "stable", "release" : "canary"
"environment" : "dev", "environment" : "qa", "environment" : "production"
"tier" : "frontend", "tier" : "backend", "tier" : "cache"
"partition" : "customerA", "partition" : "customerB"
"track" : "daily", "track" : "weekly"

이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.

구문과 캐릭터 셋

레이블 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시(/)로 구분되는 선택한 접두사와 이름이라는 2개의 세그먼트가 있다. 이름 세그먼트는 63자 미만으로 시작과 끝은 알파벳과 숫자([a-z0-9A-Z])이며, 대시(-), 밑줄(_), 점(.)과 함께 사용할 수 있다. 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야 하며, 점(.)과 전체 253자 이하, 슬래시(/)로 구분되는 DNS 레이블이다.

접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: kube-scheduler, kube-controller-manager, kube-apiserver, kubectl 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.

kubernetes.io/와 k8s.io/ 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어 있다.

kubectl get nodes --show-labels
NAME     STATUS   ROLES                  AGE   VERSION   LABELS
node-1   Ready    control-plane,master   24h   v1.22.8   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-1,kubernetes.io/os=linux,node-role.kubernetes.io/control-plane=,node-role.kubernetes.io/master=,node.kubernetes.io/exclude-from-external-load-balancers=
node-2   Ready    <none>                 24h   v1.22.8   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-2,kubernetes.io/os=linux
node-3   Ready    <none>                 24h   v1.22.8   beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=node-3,kubernetes.io/os=linux

LabelSelector

검색을 담당
리소스 간의 연결을 담당

일치성(equality base)

kubectl get pods -l APP=nginx

kubectl get pods -l APP==nginx

kubectl get pods -l 'APP!=nginx'

집합성(set base)

in
notin
exists: 키만 매칭
doesnotexists: 키 제외 매칭

kubectl get pods -l 'ENV in (dev, staging)'

kubectl get pods -l 'ENV notin (dev)'

kubectl get pods -l 'ENV'

kubectl get pods -l '!ENV'

Annotations

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

즉, 레이블과 다르게 검색과 리소스 간 연결을 하는 특별한 기능이 없다.

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

레이블이나 어노테이션을 사용하여 쿠버네티스 오브젝트에 메타데이터를 첨부할 수 있다. 레이블을 사용하여 오브젝트를 선택하고, 특정 조건을 만족하는 오브젝트 컬렉션을 찾을 수 있다. 반면에, 어노테이션은 오브젝트를 식별하고 선택하는데 사용되지 않는다. 어노테이션의 메타데이터는 작거나 크고, 구조적이거나 구조적이지 않을 수 있으며, 레이블에서 허용되지 않는 문자를 포함할 수 있다.

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

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

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

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

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

명령형 커맨드

kubectl annotate pods <파드_이름> Key=Value  # 어노테이션 추가
 
kubectl annotate pods <파드_이름> Key=Value --overwrite # 어노테이션 덮어 쓰기

kubectl annotate pods <파드_이름> Key-  # 어노테이션 삭제

YAML

apiVersion: v1
kind: Pod
metadata:
  name: myweb
  labels:
    APP: apache
    ENV: dev
  annotations:
    Created-by: Choi
spec:
  containers:
    - name: myweb
      image: httpd
      ports:
      - containerPort: 80
        name: myweb
        protocol: TCP