Labels and Selectors에 대해 공부한 내용을 정리한 글입니다.
Service and Expose에 대한 선행지식 학습내용입니다.

쿠버네티스 공식 홈페이지 - Labels and Selectors (https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/labels/)를 참고하여 진행하였습니다.
또한, 마스터 노드1, 워커노드 2로 실습 진행하였습니다.
🤣🤩😊CKA 자격증 준비 및 쿠버네티스 공부 정리입니다.

서론

apiVersion: v1
kind: Pod
metadata:
  name:
  labels:
spec:

사용자 정의 파일(yaml, Json)파일을 사용하는 중, metadata밑에 존재하는 label이라는 속성이 존재합니다. label을 안써도 문제가 생기지 않고, 마음대로 지정할 수 있다고만 알고 넘어가는 내용이었습니다.

하지만, service and expose 주제로 쿠버네티스 공식문서를 공부하다보니
label과 selector에 대해 언급이 나왔고, 이것이 수 많은 pod들을 필터링 및 원하는 작업을 할 수 있도록 labeling을 하는데 필요한 내용임을 알게 되었습니다.

1. Label?

metadata: 
  labels: 
    key1 : value1
    key2 : value2

label은 모든 쿠버네티스 리소스를 조직화 하는 기능입니다.

• label은 pod와 같은 오브젝트에 첨부된 키:값의 쌍입니다.
• label의 특성을 식별하는데 사용되어 사용자에게 중요하지만, 코어 시스템에 직접적인 의미는 없습니다
• 리소스 생성 후에도 label 추가 및 수정이 가능합니다.

1-1 어째서 label을 사용해야 하나요?

레이블을 이용하면 사용자가 느슨하게 결합한 방식으로 조직 구조와 시스템 오브젝트를 매핑할 수 있으며, 클라이언트에 매핑 정보를 저장할 필요가 없다.

서비스 배포와 배치 프로세싱 파이프라인 관리에는 다양한 작업이 필요한데, 인프라에 의해 결정된 계층 표현인 캡슐화를 깰 수 있다는 단점을 해결해줍니다.

클러스터에서 수많은 오브젝트(pod, service, deployment...)를 label에 맞게 필터링 및 작업을 하기 위해서 사용하게 됩니다.

Syntax and character set

kubernetes.io/ 와 k8s.io/ 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어 있다.

$ kubectl get nodes --show-labels

• 접두사를 생략하면 키 레이블은 개인용으로 간주한다.
• 접두사는 선택이다. 만약 접두사를 지정한 경우 접두사는 DNS의 하위 도메인으로 해야 하며, 점(.)과 전체 253자 이하, 슬래시(/)로 구분되는 DNS 레이블이다.

1-2 Label 사용해보기

• 파드에 붙어있는 label 확인

$ kubectl get pods --show-labels

• app=frontend 라는 label 추가

$ kubectl label pod [pod이름] app=frontend

• label을 수정

$ kubectl label pod my-pod app=frontend --overwrite

• label의 key 값으로 리소스 찾기

$ kubectl get pod/my-pod -L app,env

• app이라는 label 삭제

kubectl label pod/my-pod app-

2. Label Selector

Label Selector를 통해 클라이언트와 사용자는 오브젝트를 식별할 수 있다. Label Selector는 쿠버네티스 코어 그룹의 기본이다.

⚡️ 기능

• 특정 Label을 지정하여 원하는 pod를 찾거나 작업을 수행할 수 있다.
• 특정 기준을 통해 리소스를 필터링 할 수 있다.

⭐️ 검색

$ kubectl get pods -l [특정 기준]

2-1 일치성 기준(Equality-based requirement)

레이블의 명시된 제약 조건을 모두 만족해야 한다. =, ==, != 이 세 가지 연산자만 허용한다.

• =, ==는 label의 키:값 일치성을 나타냄
• !=는 불일치성을 나타냅니다.
  
  

environment = production
tier != frontend

• environment라는 키는 production을 값을 가지는 모든 리소스를 선택한다.
• 후자는 tier를 키로가지고, frontend라는 값을 가지지 않는 모든 리소스를 선택한다. 공백인 값을 가지는 모든 리소스도 선택한다.

environment=production,tier!=frontend

쉼표를 통해 한 문장으로 필터링이 가능하다.

일치성 기준 실제 예시

$ kubectlget pods -l environment=production

$ kubectlget pods -l tier!=production

2-2 집합성 기준(Set-based requirement)

• 값 집합을 키로 필터링할 수 있다. in, notin과 exists(키 식별자만 해당)의 3개의 연산자를 지원한다.
• 일치성 기준과 다르게 ''로 감싸주어야 합니다!!!

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

• 키가 environment이고, 값이 production, qa인 모든 리소스를 선택.
• 키가 tier이고 값이 frontend와 backend가 아닌 모든 리소스를 선택, 공백인 값의 모든 리소스를 선택.
• label의 값에 상관없이 키가 partition인 모든 리소스를 선택. (Exists)
• label의 값에 상관없이 키가 partition이 아닌 모든 리소스를 선택. (DoNotExists)

집합성 기준 실제 예시

$ kubectl get pods -l 'environment in (production,qa)'

$ kubectl get pods -l 'partition'

$ kubectl get pods -l '!partition'

3. 서비스와 레플리케이션 컨트롤러

• services에서 지정하는 파드 집합은 label selector로 정의한다. 마찬가지로 replicationcontrollers가 관리하는 pod의 오브젝트 그룹도 label selector로 정의한다.
• 서비스와 레플리케이션 컨트롤러의 label selector는 json, yaml 파일에 매핑된 일치성 기준 요구사항의 셀렉터만 지원한다.

selector:
    component: redis

3-1 집합성 기준을 지원하는 리소스

Job, Deployment, ReplicaSet 그리고 DaemonSet 같은 새로운 리소스들은 집합성 기준 의 요건도 지원한다.

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}
    - {key: environment, operator: NotIn, values: [dev]}

• matchLabels에 매칭된 단일 {key, value}는 matchExpressions의 요소와 같다.
• matchExpressions는 파드 셀렉터의 요건 목록이다.
• 유효한 연산자에는 In, NotIn, Exists 및 DoNotExist가 포함된다.

• 일치성 기준만 지원: service, replica controller
• 집합성 기준만 지원: job, deployment, daemonset ..

마치며

service and expose라는 주제에 대해 공부를 하던 도중에 labels와 selectors의 개념에 대해 알지 못했기에 공식문서를 참고하여 공부를 진행하였습니다.

보통은 service를 통해 생성되는 pod들을 정의하여 어떤 서비스로 묶을 것인지를 나타내는데 사용되는 개념인 것 같습니다.
service뿐 아니라 다양하게 사용할 수 있는 개념입니다.