[Kubernetes] 쿠버네티스에서 레이블(Label)이란?

목차

1. 레이블이 필요한 이유
2. 레이블이란
3. 레이블 셀렉터 이용하기
4. 레이블 셀렉터 편의기능
5. 레이블과 셀렉터로 파드 스케줄링 제한
6. 파드 이외에도 레이블 사용하기
7. 특정 노드에 파드 스케줄링
8. 하나의 특정 노드로 스케줄링

---

레이블이 필요한 이유

실제 애플리케이션을 배포할 때 대부분의 사용자는 더 많은 파드를 실행하게 될 것입니다. 파드 수가 증가함에 따라 파드를 부분 집합으로 분류할 필요가 있습니다.

 

예를 들어 마이크로서비스 아키텍처의 경우 배포된 마이크로서비스의 수는 20개를 매우 쉽게 초과합니다. 이러한 구성 요소는 복제돼(동일한 구성 요소의 여러 복사본이 배포됩니다.) 여러 버전 혹은 릴리스 (안정, 베타, 카나리 등)가 동시에 실행됩니다. 이로 인해 시스템에 수백 개 파드가 생길 수 있다. 파드를 정리하는 메커니즘이 없다면, 크고 이해하기 어려운 난장판이 됩니다. 그림은 여러 개 레플리카를 실행하는 여러 마이크로서비스에 속해 있는 파드와 동일한 마이크로 서비스의 다른 릴리스에 속한 파드를 보여줍니다.

 

모든 개발자와 시스템 관리자는 어떤 파드가 어떤 것인지 쉽게 알 수 있도록 임의의 기준에 따라 작은 그룹으로 조직하는 방법이 필요합니다. 각 파드에 대해 개별적으로 작업을 수행하기보다 특정 그룹에 속한 모든 파드에 관해 한 번에 작업하기를 원할 것 입니다. 레이블을 통해 파드와 기타 다른 쿠버네티스 오브젝트의 조직화가 이뤄집니다.

label을 사용하면 이렇게 정리가 가능해집니다.

---

레이블이란

레이블은 파드와 모든 다른 쿠버네티스 리소스를 조직화할 수 있는 단순하면서 강력한 쿠버네티스 기능입니다. 레이블은리소스에 첨부하는 키-값 쌍으로, 이 쌍은 레이블 셀렉터를 사용해 리소스를 선택할 때 활용됩니다.(리소스는 셀렉터에 지정된 레이블을 포함하는지 여부에 따라 필터링된다.) 레이블 키가 해당 리소스 내에서 고유하다면, 하나 이상 원하는 만큼 레이블을 가질 수 있다. 일반적으로 리소스를 생성할 때 레이블을 붙이지만, 나중에 레이블을 추가하거나 기존 레이블 값을 수정할 수도 있습니다.

 

위 그림의 마이크로서비스 예제로 돌아가봅시다. 파드에 레이블을 붙여 누구나 쉽게 이해할 수 있는 훨씬 체계적인 시스템을 구성할 수 있습니다. 각 파드에는 레이블 두개를 붙였습니다. 이 외에도 다양한 구성이 가능합니다.

* app: 파드가 속한 애플리케이션, 구성 요소 혹은 마이크로서비스를 지정합니다.

* rel : 파드에서 실행 중인 애플리케이션이 안정(stabl), 베타 혹은 카나리 릴리스인지 보여줍니다.

 

두 레이블을 추가해 위 그림의 아래처럼 파드를 2차원으로 구성이 가능합니다.  (애플리케이션은 수평으로, 릴리스는 수직으로) 클러스터에 접속할 수 있는 개발자와 운영자는 이제 파드 레이블을 보고 시스템 구조와 각 파드가 적합한 위치에 있는지 볼 수 있게 됩니다.

---

레이블 셀렉터 이용하기

리소스를 조회할 때 각 리소스 옆에 부착된 레이블을 같이 표시하는 것은 그다지 흥미로운 일이 아닙니다. 중요한 것은 레이블 셀렉터와 함께 사용된다는 점입니다. 레이블 셀렉터는 특정 레이블로 태그된 파드의 부분 집합을 선택해 원하는 작업을 수행합니다. 레이블 셀렉터는 특정 값과 레이블을 갖는지 여부에 따라 리소스를 필터링하는 기준이 됩니다.

 

레이블 셀렉터는 리소스 중에서 다음 기준에 따라 리소스를 선택합니다.

1. 특정한 키를 포함하거나 포함하지 않는 레이블
2.  정한 키와 값을 가진 레이블
3. 특정한 키를 갖고 있지만, 다른 값을 가진 레이블

명령어 kubectl get pod 에 옵션을 부가해 원하는 부분만 뽑아낼 수 있습니다. --selector 또는 -l 로 사용되며 구조는 다음과 같습니다.

kubectl get pod -l <label>

---

레이블 셀렉터 편의 기능

셀렉터는 쉼표를 사용해 여러 기준을 포함하는 것도 가능합니다. 셀렉터를 통해 선택하기 위해서는 리소스가 모든 기준을 만족해야 합니다. 위 사진에서 예를 들어 제품 카탈로그 마이크로서비스의 베타 릴리스인 파드를 선택하기 위해서는 app=pc, rel=beta 셀렉터를 사용합니다.

 

레이블 셀렉터는 파드 목록을 나열하는 것 뿐만 아니라, 파드 부분 집합에 작업을 수행할 때도 유용합니다. 예를 들어 레이블 셀렉터를 이용해 여러 파드를 한번에 삭제할 수 있습니다. 또한 레이블 셀렉터는 kubectl에서만 사용하는 것이 아니고 내부적으로도 사용됩니다.

---

레이블과 셀렉터로 파드 스케줄링 제한

지금까지 생성한 모든 파드는 워커 노드 전체에 걸쳐 무작위로 스케줄링됐고 이것이 쿠버네티스에서 동작하는 방식입니다. 쿠버네티스는 모든 노드를 하나의 대규모 배포 플랫폼으롤 노출하기 때문에, 파드가 어느 노드에 스케줄링됐느냐는 중요하지 않습니다. 각 파드는 요청한 만큼의 정확한 컴퓨팅 리소스(GPU, 메모리 등)를 할당받습니다. 그리고 다른 파드에서 해당 파드로 접근하는 것은 파드가 스케줄링된 노드에 아무런 영향을 받지 않습니다. 그렇기 때문에 쿠버네티스에게 파드를 어디에 스케줄링할지 알려줄 필요는 없습니다.

 

하지만 예를 들어 하드웨어 인프라가 동일하지 않은 경우를 들 수 있습니다. 워커 노드 일부는 HDD를 가지고 있고 나머지에게 SSD를 가지고 있는 경우, 특정 파드를 한 그룹에 나머지 파드는 다른 그룹에 스케줄링되도록 할 수 있습니다. 또 다른 예는 GPU 가속을 제공하는 노드에만 GPU 계산이 필요한 파드를 스케줄링하는 것을 들 수 있습니다.

 

쿠버네티스의 전체적인 아이디어는 그 위에 실행되는 애플리케이션으로부터 실제 인프라스트럭처를 숨기는 것에 있기에 파드가 어떤 노드에 스케줄링돼야 하는지 구체적으로 지정하고 싶지는 않을 것입니다. 그로 인해 애플리케이션이 인프라스트럭처에 결합되기 때문입니다.

즉, 애플리케이션이 인프라 스트럭처에 너무 세밀하게 연결되어 쿠버네티스의 목적성에 맞지 않다는 것을 뜻합니다. 그러나 정확한 노드를 지정하는 대신 필요한 노드 요구 사항을 기술하고 쿠버네티스가 요구 사항을 만족하는 노드를 선택하도록 해야합니다. 이는 노드 레이블과 레이블 셀렉터를 통해 할 수 있습니다.

 

• 인프라 스트럭처(인프라) : 물리적 기반 시설

---

파드 이외에도 레이블 사용하기

앞에서 확인한 바와 같이 파드는 레이블을 부착할 수 있는 유일한 쿠버네티스 리소스가 아닙니다. 노드를 포함한 모든 쿠버네티스 오브젝트에 레이블을 부착할 수 있습니다. 일반적으로 ops 팀은 새 노드를 클러스터에 추가할 때, 노드가 제공하는 하드웨어나 파드를 스케줄링할 때 유용하게 사용할 수 있는 기타 사항을 레이블로 지정해 노드를 분류합니다.

 

클러스터에 범용 GPU 컴퓨팅에 사용할 수 있는 GPU를 가지고 있는 노드가 있다고 가정해봅시다. 이 기능을 가지고 레이블을 노드에 추가하려고 합니다. gpu=true 레이블을 노드 중 하나에 추가합니다. 이제 파드를 나열할 때처럼 노드를 나열할 때 레이블 셀렉터를 사용할 수 있습니다. 노드 중에 gpu=true 레이블을 가진 노드를 나열해봅시다. 이러한 방식으로 kubectl을 이용해 모든 노드를 나열하고 각 노드의 gpu 레이블 값을 보여주는추가 열을 표시하도록 하는 것도 가능합니다.

---

특정 노드에 파드 스케줄링

이제 GPU를 필요로 하는 새로운 파드를 배포해야 한다고 가정해봅시다. 스케줄러가 GPU를 제공하는 노드를 선택하도록 요청하려면, 파드의 yaml 파일에 노드 셀렉터를 추가해야 합니다. 파드를 생성하는 yaml 파일에 다음 내용을 추가하고 kubectl create -f <수정한 yaml 파일> 명령을 실행합니다.

 

spec:
  nodeSeloector:
    gpu: "true" 

보통 해당 내용은 yaml파일의 container가 정의 되어있는 부분 근처에 'spec: '이 있을텐데 거기에 추가해주면 됩니다.

---

하나의 특정 노드로 스케줄링

마찬가지로 각 노드에는 키를 kubernetes.io/hostname으로 하고 값에는 호스트 이름이 설정돼 있는 고유한 레이블이 있기 때문에, 파드를 특정한 노드로 스케줄링하는 것도 가능합니다. 그러나 nodeSelector에 실제 호스트 이름을 지정할 경우에 해당 노드가 오프라인 상태인 경우 파드가 스케줄링되지 않을 수 있습니다. 따라서 개별 노드로 생각하기 보다 레이블 셀렉터를 통해 지정한 특정 기준을 만족하는 노드의 논리적인 그룹을 생각해야 합니다.

 

레이블 셀렉터의 중요성은 이후에 다뤄볼 레플리케이션 컨트롤러와 서비스를 이야기 할 때 다시 한번 강조될 것으로 생각 됩니다. 내용은 순차적으로 차근차근 다뤄보도록 하겠습니다.

---