Kubernetes - Label 및 Annotation

- 출처: kubernetes in action

- 레이블

파드 예제에서는 2개 정도밖에 생성해보지 않았지만 실제 환경에서는 서비스 규모에 따라 컴포넌트가 수십개 이상이 될수도 있다. 여기에 개발, 운영과 같은 환경까지 고려하면 배수만큼 늘어나므로 파드들을 관리하기가 쉽지 않다.

 

레이블은 개발자나 시스템 관리자가 파드를 쉽게 그룹화할 수 있도록 해준다. 레이블을 활용하면 파드에 대한 작업을 수행할 때 개별적으로 하지 않고 한꺼번에 할 수 있다.

 

파드를 기반으로 설명했지만 레이블은 다른 쿠버네티스 리소스에도 적용할 수 있다. 리소스에 키/값 형태를 추가하고 레이블 셀렉터를 통해 리소스 선택시 활용한다.

 

실제로 레이블을 활용하는 예로는 앱이나 배포 환경에 대한 레이블을 붙이는것이다. app에는 파드가 속한 앱, 구성요소, 마이크로 서비스 값을 붙이고, rel에는 beta, stable, 카나리(안정버전 옆에 새버전을 배포, 모든 사용자를 대상으로 배포하기 전 소수에게만 새로운 버전을 공개하는 환경) 여부를 붙이는것이다. 이렇게 하면 리소스를 2차원으로 구조화해서 관리할 수 있다.

---

- 파드 생성시 레이블 지정

생성방법(creation_method)와 환경(env) 레이블을 가진 파드를 생성하는 yaml 파일은 아래처럼 작성한다.

 

apiVersion: v1
kind: Pod
metadata:
  name: kubia-manual-v2
  labels:
    creation_method: manual
    env: prod
spec:
  containers:
  - image: ocwokocw/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

 

metadata.labels 항목에 레이블을 추가했다. "kubectl create -f [yaml file]" 명령어를 통해서 파드를 생성해보자.

 

 

 

파드 생성여부를 확인하기 위해 여태까지 "kubectl get pod"로 조회했지만 이렇게 조회하면 레이블 관련 사항이 출력되지 않는다. --show-labels 옵션을 추가해서 조회한다. LABELS에 하나의 문자열이 아닌 레이블을 별도의 열로 출력하고 싶다면 -L 옵션과 함께 레이블 키값을 지정한다.

 

 

 

yaml 파일에 레이블을 기술해서 생성하는 방법 이외에도 직접 레이블은 추가 및 수정할 수 있다. kubia-manual 에는 creation_method 레이블을 추가하고, kubia-manual-v2의 env 라벨은 debug 값으로 수정한다.

 

 

 

---

- 레이블 셀렉터

레이블 셀렉터는 레이블로 태그된 자원들의 부분 집합을 선택한다. 셀렉터의 리소스 선택기준은 아래와 같다.

 

• 특정키를 포함 or 미포함
• 특정키와 값을 가진 레이블
• 특정 키는 갖고 있지만 다른 값을 가진 레이블

 

레이블 셀렉터를 활용한 몇 가지 예제를 살펴보자. 레이블 셀렉터를 이용하여 조회할때에는 -l 옵션을 사용하면 된다.

 

 

 

• 특정 키와 값을 가진 리소스 조회: "-l creation_method=manual" 과 같이 키와 값을 둘다 써주면 된다.
• 특정 키만 갖는 리소스 조회: "-l env"
• 특정 키를 포함하지 않는 리소스 조회: "-l '!env'", bash 셸이 느낌표를 처리하지 않도록 '로 감싸준다.

 

이 외에도 != 이나 in, not in 조건도 존재한다. 위의 예제 에서는 조건을 하나만 사용했지만 and 조건을 여러개 사용할 수도 있다. 

 

 

 

---

- 레이블 셀렉터를 활용한 파드 스케줄링 제한

쿠버네티스 파드는 어떤 워커노드에 배포되는지 신경쓰지 않는다. 또한 이렇게 사용하는것이 쿠버네티스를 적절하게 사용하고 있는 것이다. 하지만 어쩔 수 없이 파드 스케줄링시 특정 워커노드에 배포해야 하는 상황도 존재한다. 쿠버네티스가 하드웨어 계층에 의존성을 갖지 않게 해주지만 결국 장비의 하드웨어는 동일하지 않다. 어떤 워커노드는 HDD 일수도 있고 나머지는 SSD 일수도 있다. 

 

이런 상황에도 정확히 어떤 특정 노드를 지정하여 배포하는것은 피해야한다. 셀렉터를 올바르게 사용하려면 배포되어야 하는 노드의 요구사항을 기술하고 이를 만족하는 노드를 선택하도록 활용해야 한다.

 

예를 들어 클러스터에 범용 GPU 컴퓨팅이 가능한 노드가 있다면 gpu=true와 같은 레이블을 추가할 수 있다.

 

 

 

노드에 레이블은 추가했는데 파드 배포시 해당 노드에 배포하도록 어떻게 강제할까? 스케줄러가 특정 레이블을 만족하는 노드를 선택하게 하려면 yaml 파일에서 spec 섹션에 nodeSelector를 추가하면 된다.

 

apiVersion: v1
kind: Pod
metadata:
  name: kubia-manual-v3
  labels:
    creation_method: manual
    env: prod
spec:
  nodeSelector:
    gpu: "false"
  containers:
  - image: ocwokocw/kubia
    name: kubia
    ports:
    - containerPort: 8080
      protocol: TCP

 

위와 같이 gpu: "false"인 레이블 nodeSelector를 추가한 후 "kubectl create" 명령어로 파드를 생성해보자.

 

 

 

생성되었다고 메시지가 나오긴 하지만 시간이 지나서 파드를 조회해도 Pending 상태일것이다. true로 변경한 후 다시 실행하면 정상적으로 파드가 생성되는것을 확인할 수 있다. 

 

---

- 어노테이션 추가 및 수정

레이블 말고도 쿠버네티스는 어노테이션을 제공하는데 레이블과 비슷하게 어떤 정보를 태깅할 수 있다.

 

레이블과 다른점은 식별 정보가 없으며 오브젝트를 그룹화할 수 없다는것이다. 레이블은 셀렉터가 있지만 어노테이션은 셀렉터가 없다. 대신 훨씬 많은 정보를 보유할 수 있다.

 

어노테이션은 2가지 방식으로 활용될 수 있다.

 

• 쿠버네티스에 신규 기능을 도입할 때 이를 곧바로 API 필드로 확정짓지 않는다. 필드 대신 어노테이션을 사용하다가 명세가 명확해지면 새로운 필드가 도입되고 어노테이션 사용을 중단한다.
• 단순히 어떤 정보를 기술할수도 있다. 어떤 리소스에 담당자를 적어 놓으면 해당 정보를 기반으로 협업을 하기 편해진다.

 

어노테이션은 "kubectl describe pod [파드명]"을 통해 조회하거나 "kubectl get pod [파드명] -o yaml"을 통해 조회한다.

 

 

 

yaml로 조회할 경우 metadata 하위 필드에 있게 된다.

 

추가하는법은 레이블 추가하는법과 비슷한데, label 대신 annotate를 사용하면 된다. 어노테이션 키 충돌을 방지하기 위해 아래형식과 같이 사용하는게 좋다.