labels

# 레이블 개념

난 라벨링이라고 했는데.. 일본식 발음방법이고 레이블이라고 한다.

컨트롤러와 서비스를 가지고 설명을 할때 써먹었던건데.. 레이블은 셀렉터로 인식할 레이블들을 말한다.

공식문서에서 deployment yaml양식을 가져와보면,

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

저기 deployment의 spec필드에 있는 selector가

아래 template필드에 있는 deployment가 만들 pod들의 metadata의 labels필드에있는 값들이랑 커넥트된다.

그림으로 보면 이렇다.

레이블은 k8s에서 다양한 방면으로 활용가능하다.

 

 

 

 

# label의 활용

1. name : 이름으로 붙이는 레이블.. pod들을 관리할때 login page인지 main ui인지 등등 나눠서 관리하면 편할것같다. 
2. tier : front, back, cache등등으로 나눠서 티어를 관리할 수 있을 듯.
3. rel : stable, beta, canary등등으로 배포버전을 관리할수 있는 레이블.

 

 

 

# selector에서 matchLabels, matchExpressions

controller/ replicaSet & deployment

이전 포스팅에서 replication controller와 replicaSet의 차이가 레이블 셀렉터의 활용이었다.

다시 쓰긴 귀찮고 오퍼레이터로 and or 연산등을 지원한다.

참고로 matchLabel에서 두개를 쓰면 and연산으로 작동한다.

 

 

 

 

# 라벨링 제한

• 키 벨류는 63글자 미만,
• 시작과 끝은 알파벳or숫자.
• 특수문자는 - . _ 이것들 쓸 수 있음.
• 단순하게 문자열 들어갈경우는 ""으로 안묶어도 됨.
• TRUE, FALSE, YES, NO는 "" 꼭써야함

.

# 라벨링은 뭐로 쓸까?

케밥케이스를 자주 쓴다고 한다. 예를들어 muzzi-page이런식으로 -문자로 엮은거다.

난 카멜케이스를 사랑하는데.. 카멜케이스도 되긴한다.

예전에 안됐던 기억이 있긴한데.. 뭔가 기억이 안난다..

 

 

 

# 라벨링 해시

테스트를 위해서 deployment로 pod들을 생성해봤는데, name=muzzipage라는 라벨링은 yaml에서 명시적으로 해줬는데, 저기 뒤에 있는 pod-template머시기 라벨링은 해준적이 없다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: babo-dep
  creationTimestamp: null
spec:
  replicas: 2
  selector:
    matchLabels:
      name: muzzipage
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        name: muzzipage
    spec:
      containers:
      - image: nginx:latest
        name: nginx
        resources: {}
status: {}

이게 deployment양식인데 분명 난 name: muzzipage만 해줬었다.

근데 저게 생긴 이유는 뭘까? 

gpt한테 물어보니, 

이렇단다..

그래서 난 이 deployment의 template부분에서 nginx버전을 변경하고 apply해보겠다.

실제로 아까 5cc머시기 해시붙은 라벨링이 있는 pod들은 지워지면서 새로운 pod들로 바뀌는데, 해시가 694머쩌고로 바뀌고있다.

 

 

# 롤링업데이트는? 

kubectl set image deployment babo-dep nginx=nginx:latest --record

아까 1.14버전으로 바꾼상태였기때문에 다시 latest로 바꿔보았다.

다시 라벨링 해시가 바뀌었다. 근데 신기하게, 아까 했던 5cc머시기로 다시 바뀐듯하다.

다시 1.14로 업데이트 해볼까?

kubectl set image deployment babo-dep nginx=nginx:1.14 --record

다시 694..

kubectl set image deployment babo-dep nginx=nginx:1.13 --record

계속 바뀌는듯??

롤백도 해봤는데 뭐 다 비슷한듯.. 암튼 라벨링 얘기하다가 산으로가는것같아서 다시 돌아오자..

 

 

 

 

 

## cli환경에서 라벨링 제어하기.

 

# pod생성방법 & yaml라벨링에따른 pod 레이블 차이

kubectl run testpod --image=nginx:latest --port=80

해당 cli 명령어로 pod를 생성하고 레이블을 보면, 

요런 run=testpod라는 레이블이 붙는다.

 

참고로 pod의 레이블정보도 같이 보고싶으면 

kubectl get pods --show-labels

요렇게 보면 된다.

 

 

추가해서 두가지 pod를 더 만들어보겠다.

- 라벨링 없는 pod

apiVersion: v1
kind: Pod
metadata:
  name: no-label
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
      - containerPort: 80

- 라벨링 있는 pod

apiVersion: v1
kind: Pod
metadata:
  name: label-pod-demo
  labels:
    name: muzzipage
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
      - containerPort: 80

 

pod들 정보를 보면, 

yaml로 아예 라벨링을 안해준 pod는 none이라고 뜨고, 

라벨링해준건 name=muzzipage라는 라벨링이 되어있다.

참고로 아까 deployment로 만들어준건 해시라벨링이 자동으로 하나 더 붙는것같다.

 

 

 

# 특정 라벨있는 pod정보만 보기

kubectl get pods -l name=muzzipage

-l옵션으로 볼 수 있다.

 

아니면, --selector옵션으로도 볼 수 있다.

kubectl get pods --selector name=muzzipage

 

추가해서 get말고 delete도 됨. 셀렉터로 활용할수있다는 말임.

 

 

 

 

# 특정pod에 라벨 cli명령으로 집어넣기

kubectl label pod testpod rel=canary

아까 cli로 만든 testpod에는 run=testpod밖에 없었다.

rel=canary라는 라벨링을 cli커맨드로 직접 추가해줬다.

 

 

 

# 덮어쓰며 집어넣기

kubectl label pod testpod rel=beta --overwrite

기존 레이블키 있는거 덮어쓰는식으로 할당하기

rel=canary였던게 rel=beta로 덮어씌워졌다.

 

 

# 레이블 두개이상 집어넣기

kubectl label pod testpod name=muzzi rel=stable --overwrite

 

두개이상은 걍 한 칸 띄워써주면 된다.

 

 

# 레이블 삭제하기

kubectl label pod test-pod run-

test-pod에서 run이라는 레이블 삭제되었다. (위에랑 다른건 난 덮어쓰기가 새로 라벨링한것도 포함되서 동작하는지 테스트하려고 해서 version붙고 name이랑 rel바뀐거임)