Labels/ Annotations

1. Label

클러스터 내부에서 객체 구별위한 임의 식별자

하나 이상의 레이블 존재 가능

설정 형식 =  키 : 값
ex) label : test

✅ 역할
Kubernetes 리소스 분류 및 선택(Select)
selector로 사용 가능 
Service, Deployment, ReplicaSet 연결 고리 역할을 함

✅ 특징

key-value 쌍 형태
빠르게 조회/검색/선택 가능

제한된 크기: key는 63자 이하
총 label 수는 제한 있음 (보통 64개 이하 권장)

용도가 시스템 로직에 직접 관여함

ReplicaSet, Service 연결, 롤링 업데이트 등 핵심 기능

 

 

레이블 없는 파드 생성 YAML 

apiVersion: v1
kind: Pod
metadata:
  name: nolabel
spec:
  containers:
    - name: mynginx
      image: nginx:1.14
      ports:
      - containerPort: 80

 

 

apiVersion: v1
kind: Pod
metadata:
  name: withlabel
  labels:
    name: mylabel
    rel: stable
spec:
  containers:
    - name: mynginx1
      image: nginx:1.14
      ports:
      - containerPort: 80

 

[특정 라벨 검색]

kubectl get pod -l name/rel (--show-labels)
kubectl get pod -l name=mylabel (--show-labels)
NAME        READY  (LABELS)
withlabel   1/1    (name=mylabel,rel=stable)

[Selector]
kubectl get pod --selector app(=aa) --show-labels
kubectl get pod --selector app!=aa --show-labels

[Label 생성 및 추가]

kubectl label pod/node nolabel name=label rel=ip
pod/nolabel labeled

kubectl get pod nolabel --show-labels
NAME      READY    LABELS
nolabel   1/1      name=label,rel=ip

kubectl label pod nolabel **app=abc**
NAME      READY    LABELS
nolabel   1/1      **app=abc**, name=label

---------------------------------------
[Label 변경] 

kubectl edit pod

kubectl label pod nolabel name=YES --overwrite
pod/nolabel labeled

NAME      READY    LABELS
nolabel   1/1      name=YES
-----------------------------------------
[Label 일괄 변경]
kubectl label pod --selector(=)app app=cc --overwrite
kubectl label pod --selector(=)app=cc app=aa --overwrite

[Label 삭제]
kubectl label pod nolabel [app]-   
NAME      READY    LABELS
nolabel   1/1      [app]=abc] name=label
nolabel   1/1      name=label / app 제거

-------------------------------------
✅ YAML에서 boolean으로 인식되는 키워드
yes / no
true / false
on / off

rel: yes라고 작성하면 
**boolean true**로 인식

"yes"처럼 따옴표 표기해야 
강제로 문자열로 인식

[연산자]
kubectl get pods -l '!app'

kubectl get pod -l 'app notin (aa,bb)' --show-labels
kubectl get pod --selector 'app notin (aa)' --show-labels
NAME        READY   STATUS    RESTARTS   AGE   LABELS
nolabel     1/1     Running   0          50m   app=bb
withlabel   1/1     Running   0          46m   app=cc
----------------------------------------
kubectl label node node1 disktype=ssd gpu=true
kubectl get node -L disktype,gpu

NAME     STATUS   ROLES           VERSION   DISKTYPE   GPU
master   Ready    control-plane   v1.27.7              
node1    Ready    worker          v1.27.7   ssd        true
node2    Ready    worker          v1.27.7   ssd        true
node3    Ready    worker          v1.27.7              

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  nodeSelector:
    disk: ssd
    gpu: "true"
  containers:
    - name: nginx1
      image: nginx:1.14
      portsㅕ:
      - containerPort: 80

nodeSelector:
Pod가 특정 라벨을 가진 노드에 배치되도록 지정

클러스터의 노드 중 하나 이상이 
해당 라벨을 가지는 경우 해당 노드에서 파드로 스케줄링
해당 라벨이 없다면 Pod는 Pending 상태로 대기

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  labels:
    app: nginx
    env: test
spec:
  nodeSelector: /// 특정 라벨 가진 노드 탐색 후 파드 배치 기능
    disk: ssd
    gpu: "true"
  containers:
    - name: nginx1
      image: nginx:1.14
      ports:
      - containerPort: 80
      
      
      

 

 

 

 

apiVersion: apps/v1
kind: DaemonSet
metadata:
	name: nginx-on-ssd
	labels:
	app: nginx
	spec:
selector:
	matchLabels:
	name: nginx
template:
	metadata:
		labels:
		name: nginx
	spec:
	nodeSelector:
		disk: ssd
	containers:
		- name: nginx
			image: nginx:1.14
			ports:
			- containerPort: 80

kubectl get pod 

NAME           DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   
nginx-on-ssd   2         2         2       2            2           disk=ssd    

[None으로 노드 레이블 지정하여 파드 생성]

특정 라벨이 없는 노드에 파드를 스케줄링

apiVersion: v1
kind: Pod
metadata:
  name: without-label
spec:
  nodeSelector:
    disk: ssd
    mem: high
  containers:
    - name: nginx2
      image: nginx:1.15
      ports:
        - containerPort: 80

2. Annotation

✅ 역할

부가 정보 저장 (Metadata)

쿠버네티스 리소스에 대한 부가 정보,설명을 저장(=주석)

사용자 및 외부시스템이 참조하는 정보

selector로 사용할 수 없음 → 시스템 로직에는 영향을 주지 않음

✅ 특징

key-value 쌍 형태

사이즈에 제약 작음 → 긴 문자열, JSON 저장 가능

모니터링, 배포 도구, 자동화 시스템에서 사용

롤링업데이트,배포,로깅,모니터링 정보 기록
문서화, 도구 위한 메타데이터, 내부 관리 활용

예: Helm, Istio, ArgoCD 등에서 내부적 활용

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  annotations:
    builder: orkr@or.kr
    builderDate: "20250423"
    container-_.version: nginx:latest /// 공백 사용 불가    
    imageregistry: "<https://hub.docker.com>"

spec:
  containers:
    - name: nginx
      image: nginx:1.14
~                       

 

 

 

3. Label 이용한 카나리 버전 수동 배포

• 신규 버전 배포 이전 시험 버전 배포

1. 컨테이너 이미지 생성 YAML 파일

vi mycanari.yml

✅ 1. Stable 버전 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-stable
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ***myapp***
      version: stable
  template:
    metadata:
      labels:
        app: ***myapp***
        version: stable
    spec:
      containers:
        - name: app
          image: myapp:v1
          
✅ 2. Canary 버전 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ***myapp***
      version: canary
  template:
    metadata:
      labels:
        app: ***myapp***
        version: canary
    spec:
      containers:
        - name: app
          image: myapp:v2
          
✅ 3. Service (두 버전을 모두 선택)
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
	type: ClusterIP
  clusterIP: 10.233.10.10
  ***selector:***
    ***app: myapp***
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

kubectl scale deploy [] --replicas 2

canary 정상 작동 시
stable -> canary migration

kubectl scale deploy [canary] --replicas 2
kubectl scale deploy [stable] --replicas 0

 

 

kubectl set image deploy [name] [container]=nginx:1.16

📌 핵심 차이 요약

항목 set image Canary 배포

방식	명령어로 직접 이미지 교체	배포 전략
적용 범위	한 번에 전체 이미지 변경	일부만 변경
위험 관리	바로 전체에 적용 → 위험 있음	점진적 적용
YAML 사용 여부	명령어 위주 (kubectl)	YAML로 설계
주로 사용 시기	단순 업데이트, 테스트 중	실서비스 안정 배포 시