[Kubernetes] Labels & Selectors

쿠버네티스에서 리소스(쿠버네티스 내에선 Object이라 불린다)를 구별하는 Label과 Selector를 알아보자.

• Label & Selectors

 

Labels & Selectors

라벨과 셀렉터라는 개념은 처음 들어본다. 아마 쿠버네티스에서 리소스를 구별할 때 쓰는 것 같은데, 공식문서를 보고 의미를 찾아보자. 

1️⃣ 라벨이란?

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

라벨은 리소스에 붙이는 키-값 쌍 데이터이다. 파드와 같이 쿠버네티스에서 사용하는 리소스들에 붙이는 이름표다.

라벨은 파드를 처음 생성할 때 붙일 수도 있고, 그 후에도 사용자가 원할 때 언제든지 붙일 수 있다.

한 리소스 당 하나의 라벨을 붙일 수도 있고, 한 집합에 안에 속하는 리소스들 사이에서 부분 집합만 선택하도록 라벨을 설정할 수 있다. (한 노드에 있는 여러 파드들 중 몇 개만 라벨로 묶을 수 있는 소리 같다.)

 

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

Docker Compose를 통해 컨테이너를 생성할 때 docker-compose.yml 파일에서 컨테이너의 이름을 생성할 수 있는데, 그것이랑 똑같은 개념인 것 같다. 

 

 

2️⃣ 라벨은 왜 만들어졌을까?

라벨은 사용자로 하여금 자신이 설정한 리소스 구조를 사용할 수 있게끔 해준다. 

예를 들어, 내가 노드 A와 노드 B를 설정했다고 하자. 각각의 노드는 1번부터 10번까지의 파드를 가지고 있다. 만약 사용자가 노드 A의 1번부터 5번까지, 그리고 노드 B의 1번부터 5번까지의 파드를 묶어 프론트엔드 서버로 관리하고 싶을 수 있다. 관리하던 도중 파드 안에 있는 서버들에 수정사항이 생긴다면, 사용자는 이 파드들을 하나씩 접속하면서 변경 사항을 적용해야 할 것이다.

 

라벨은 바로 이때 필요하다. 클러스터를 통해 서비스를 배포하면 각 노드들은 수많은 '상태(혹은 차원)'을 가지게 된다. 클러스터 전체로 놓고 보면 이러한 차원들이 굉장히 많을 것이다. 문제는 이런 상황에서 각 노드들을 관리해야 하는 경우인데, 각 노드들이 다양한 집합에 소속되거나 상태가 다양하다면 관리자가 이를 관리하기 매우 힘들어진다.

 

라벨은 이러한 Cross-Cutting Operation(어플리케이션의 여러 모듈이나 계층에 걸쳐서 공통적으로 적용되어야 하는 기능이나 동작) 상황에서 기존 구조를 깨뜨리지 않은 채 각 리소스를 관리할 수 있게끔 도와준다. 

 

 

📍 네임스페이스와 차이점은 무엇인가?

네임스페이스는 리소스 사이에 설정하는 경계이고, 라벨은 리소스들에 붙이는 이름표이다. 리소스들은 경계를 넘어갈 수 없는 대신 여러 개의 이름표를 가질 수 있다.

깊게 설명하자면 리소스는 자신이 유일하게 결정되는 물리적인 경계이다. 한 네임스페이스 안에서는 동일한 이름을 사용하지 못한다. 반면 라벨은 네임스페이스에 상관없이 붙일 수 있는 속성이다.

 

실무적인 상황에서 예를 들어보자.

노드 2개로 구성되어 있는 노드 클러스터

네임스페이스는 '경계'이다. Namespace A에서 A-01은 유일하다. A-01은 Namespace A에서 유일하게 결정된다.

반면 라벨은 속성이다. Namespace A에서 Frontend와 Namespace B에서의 Frontend는 같다. 라벨은 리소스 사이의 다양한 계층과 물리적 거리를 뛰어넘어 적용된다. 

 

 

3️⃣ 라벨 셀렉터는 무엇인가?

셀렉터는 쿠버네티스의 리소스를 선택하는 필드이자 필터이다. 파드나 컨테이너처럼 리소스 자체는 아니고, 리소스 안에 포함되어 있는 검색 엔진 정도로 생각하면 될듯하다. 쿠버네티스는 두 종류의 셀렉터를 제공한다.

 

 

📍Equality-Based Selector

일치/불일치 조건을 통해 원하는 리소스를 필터링 하는 방법이다. =, ==('=' 와 같음), != 세 개의 연산자가 허용된다. 연산자들을 조합해 특정 조건에 맞는 리소스를 찾을 수 있다. 밑에 예시를 보자. 

environment = production
tier != frontend

두 개의 라벨 필터를 적용해 원하는 리소스를 찾는 과정이다. 이미 배포된 라벨 리소스 중 프론트엔드가 아닌 리소스만 선정하는 과정이다. 이런식으로 일치/불일치 조건을 통해 라벨로 원하는 리소스를 관리할 수 있다.

 

 

📍Set-Based Selector

집합 조건을 통해 원하는 리소스를 필터링 하는 방법이다. in, notin, exists를 통해 원하는 리소스를 찾는다. 예시를 보자.

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

첫 번째 예시는 environment라는 키에서 production, qa 라는 value를 가진 리소스를 찾는 것이다.

두 번째는 tier 키에서 frontend, backend라는 value를 가진 리소스를 제외한 나머지를 찾는 것이다.

세 번째는 오직 partition이라는 key를 가진 전체 리소스를 찾는 것이고, 네 번째는 제외해 찾는다.

 

참고로 , 는 AND 연산자 처럼 동작하며, Set-Based는 Equality-Based와 혼합해서 사용할 수 있다.

 

4️⃣ 라벨을 효율적으로 쓰는 방법은?

그럼 라벨을 효과적으로 쓰는 방법은 무엇일까? 하나의 리소스에 하나의 라벨을 붙일 수 있지만, 이는 권장되는 방법이 아니다. 애초에 라벨은 여러 리소스에 붙여 사용하도록 설계됐기 때문이다!

한 서비스에서 여러 tier의 리소스들이 동시에 동작하고 있고, 각각의 관리가 필요할 때 라벨의 사용을 고려할 수 있다.

프론트엔드와 Redis를 사용한 여러 리소스들이 존재하는 서비스일 때, 어떻게 라벨을 관리하는지 살펴보자.

 

labels:
  app: guestbook
  app.kubernetes.io/name: guestbook
  tier: frontend

프론트엔드에는 다음과 같이 설정할 수 있다. 

 

labels:
  app: guestbook
  app.kubernetes.io/name: guestbook
  tier: backend
  role: master

만약 Redis의 마스터 리소스라면 이렇게 설정할 수 있다.

 

labels:
  app: guestbook
  app.kubernetes.io/name: guestbook
  tier: backend
  role: replica

Replica면 이렇게 설정할 수 있다.

 

[출처]

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

Labels and Selectors

 

공식 문서를 통해 라벨과 셀렉터를 봤는데, 나중에 기술 블로그를 찾아봐서 실제로 어떻게 쓰이는지 공부해야겠다.