2024. 3. 24. 23:58ㆍBACKEND
본 포스팅에서는 Kubernetes의 Taint 와 Toleration의 개념을 이해하여 Affinity와의 차이점을 구분할 수 있는 목표를 가집니다.
🔗 Kubernetes Series
모든 Kubernetes 시리즈를 확인하시려면 위를 참고해 주세요.
Taints & Tolerations?
Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes.
Taint (테인트)와 Toleration(톨러레이션)는 Pod가 적절치 않은 노드에 스케줄링 되지 않는 것을 보장합니다.
특정 Pod가 Node에 스케줄링 될 때, Node 배치에 제한을 걸 수 있는 용도로 사용될 수 있습니다.
참고로, 실제 두 단어의 개념을 살펴보면 다음과 같습니다:
📕 Taint: the act or result of spoiling something or giving it an unpleasant quality
📔 Tolerant: having the ability to bear something unpleasant or annoying, or to keep going despite difficulties Example.
Toleratation은 Pod에, Taint는 Node에 적용되어 두 개념이 함께 사용됩니다.
이해를 위해 예시를 먼저 확인하고 조금 더 깊이 들어가보겠습니다.
Example.
벌레 3마리와 동물 3마리가 있다고 가정해보겠습니다.
🪲, 🐜, 🐞 와 🐶, 🐨, 🦊 가 있습니다.
Pods: 🪲 🐜 🐞
Nodes: 🐶 🐨 🦊
dog koala fox
벌레들이 동물들을 괴롭혀서, 동물들은 벌레 퇴치제 🌀 를 구매합니다.
벌레가 다가오지 못하게 🐶 에게 벌레 퇴치제를 뿌리면, 냄새에 견디지 못하는 벌레들이 다가오지 못하게 할 수 있습니다.
이 때, ① 강아지 🪄🐶 를 Taint 상태라고 지칭할 수 있습니다.
Pods: 🪲 🐜 🐞
Nodes: 🐶 🐨 🦊
🪄 dog koala fox
이제 퇴치제 🪄 를 뿌린 dog에게는 어떤 벌레도 다가오지 못합니다.
🐞, 🪲, 🐜 → ❌ 🐶
해당 벌레 퇴치제 냄새를 견딜 수 있는 벌레가 있을 수 있어서 동물에게 닿을 수 있다면,
그 벌레는 해당 Tolerant 에 견딜 수 있다고 할 수 있습니다.
이 때 벌레 C가 퇴치게에 내성(Tolerant)이 생겼다고 가정해보죠.
Pods: 🪲 🐜 🐞
A B 🪄 C
Nodes: 🐶 🐨 🦊
🪄dog koala fox
즉, 벌레가 다가오지 못하게 Taint 상태로 만들 수 있고,
해당 퇴치제를 견딜 수 있어 Taint 상태의 동물(🐶)에게 다가갈 수 있는 특정 벌레(🐞)를 Tolerate 하다고 표현합니다.
🪲, 🐜 → ❌ 🐶
🐞 → ⭕️ 🐶
쿠버네티스에 적용해보면 동물 → Node / 벌레 → Pod 입니다.
즉, 특정 Node에 아무 Pod 이나 배치되지 않게 Taint 상태를 만들어 두고,
지정하고자 하는 Pod에 Toleration 조건을 달아 특정 Node에 접근할 수 있게 만드는 것입니다.
(Toleration) 🪄 app Equal blue
Pods ⚪️ ⚪️ 🔵
Nodes 🟦 ⬜️ ⬜️
(Taint) 🪄app=blue
How to use
그럼, 쿠버네티스에서 어떻게 적용할 수 있는지 살펴보도록 하겠습니다.
1. Node - kubectl taint
Node에 taint를 적용시키려면 kubectl taint 명령어를 사용할 수 있습니다.
❯ kubectl taint nodes <<node-name>> <<key>>=<<value>>:<<taint-effect>>
node-name: taint를 적용할 노드 이름
key: taint key
value: taint value
taint-effect: taint에 tolerate 하지 않는 Pod에 대한 액션
가령 아래와 같은 명령어를 사용할 수 있습니다.
kubectl taint nodes node1 key1=value1:NoSchedule
node1 노드에 taint를 적용합니다.
taint는 key 값으로 key1을, value 값으로 value1을 지정하며,
taint effect 는 NoSchedule로 지정됩니다.
일치하는 Toleration이 없으면 파드를 node1 에 스케줄하지 않음을 의미합니다.
만약, 위의 taint 명령어를 제거하고 싶다면 아래와 같이 - 를 추가하여 입력합니다.
kubectl taint nodes node1 key1=value1:NoSchedule-
Taint Effect.
Taint effect 로 지정할 수 있는 값은 아래와 같이 3가지가 있습니다.
✔️ NoSchedule
: Pod가 Node에 스케줄되지 않음. 기존 실행되던 Pod는 유지됨 (퇴출 ❌)
✔️ PreferNoSchedule
: Pod가 Node에 스케줄되지 않도록 최대한 노력하지만 보장되는 건 아님
✔️ NoExecute
: 새로운 Pod는 해당 Node에 위치되지 않으며, 만약 해당 Node에 존재했던 Pod가 있다면 아래 조건에 따라 처리
- Tolerate 되지 않은 Pod, 즉시 퇴출
- Tolerate 된 Pod 이면서, toleration spec에 tolerationSeconds 가 지정되지 않으면, 영구적 바인딩
- Tolerate 된 Pod 이면서, toleration spec에 tolerationSeconds 에 특정 시간이 지정되어 있으면, 해당 시간 이후 Node Lifecycle Controller에 의해 퇴출
---
tolerationSeconds: Pod가 Node에 바인딩된 시간을 지정
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoExecute"
tolerationSeconds: 3600
2. Pod - PodSpec
아래 Tolerations에 정의된 내용이 taint와 일치한다면,
정의된 Pod는 해당 Node에 배치될 자격이 주어집니다.
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
위의 예시에서는 key가 key1이고 value가 value1으로 동일(Equal)하는 NoSchedule의
Taint 노드에 진입 (or 견딜 수 Tolerate) 있다는 의미입니다.
🚨 tolerations 필드 하위의 값들은 항상 쌍따옴표("")에 감싼 값을 입력해야 합니다.
Matching.
조건은 다양하게 지정할 수 있는데, operator의 기본 값은 Equal 입니다.
Toleration은 다음과 같은 3가지 조건을 만족해야 Taint와 "매칭"됩니다.
1. Key 동일
2. Effect 동일
3.1. Operator가 Equal 일 때, value 값이 동일
tolerations:
- key: "example-key"
operator: "Equal"
value: "example-value"
effect: "NoSchedule"
3.2. Operator가 Exists 일 때 (value 필드 값은 필요 없고 키 값이 존재하는 지 필요)
tolerations:
- key: "example-key"
operator: "Exists"
effect: "NoSchedule"
✔️ operator가 Exists 이면서 key 가 빈 값일 때, 모든 것들이 Tolerate 됩니다.
✔️ effect 가 빈 값일 때, key가 일치하는지만 확인합니다.
Caution
⚠️ Node 1 은 오직 Pod D만 배치될 수 있지만, 반대로 Pod D가 항상 Node 1에 배치된다는 보장은 없습니다.
즉, taint & toleration 은 특정 노드에 배치하기 위한 설정이 아니라, 특정 노드가 특정 Pod만을 수용한다는 것을 의미합니다.
만약, 반대로 특정 Pod 만을 제외하고 싶은 거라면, Node Affinity 를 통해 설정 가능합니다.
Master Node
클러스터에 존재하는 Master Node는 초기 설정 시,
다른 Pod가 지정되지 못하도록 자동으로 taint가 설정됩니다.
물론 해당 설정을 수정할 수는 있지만,
권장하는 Best Practice는, master 노드 서버에 애플리케이션 워크로드를 배포하지 않는 것입니다.
❯ kubectl describe node kind-control-plane -n kube-system | grep Taint
Taints: node-role.kubernetes.io/master:NoSchedule
실제 Control Plane 노드를 확인해보면, 쿠버네티스에서 지정해둔 Taint를 확인할 수 있습니다.
Node Affinity vs. Taints & Tolerations
세 개의 노드 blue, red, green ( 🟦, 🟥, 🟩 )와 세 개의 Pod blue, red, green ( 🔵, 🔴, 🟢 )가 있다고 가정해 보겠습니다.
Pods: 🔵 🔴 🟢
Nodes: 🟦 🟥 🟩
이 때, 다른 팀들과 같은 쿠버네티스 클러스터를 공유하고 있어서,
두 개의 Node (⬛️)와 두 개의 Pod (⚫️)를 추가로 존재하는 것을 감안해서 보겠습니다.
Pods: 🔵 🔴 🟢 ⚫️ ⚫️
Nodes: 🟦 🟥 🟩 ⬛️ ⬛️
목표
각 Node가 동일한 색상의 Pod 만을 가져야 합니다.
다른 팀의 Pod가 우리 노드에 놓여서는 안되고, 우리 포드가 다른 팀 노드에 있는 것도 안된다는 조건이 있습니다.
이제 Node Affinity와 Taints and Tolerations를 사용했을 때를 생각해보겠습니다.
1. Taints and Tolerations
먼저, Node에 각 색상 별 Taint를 추가 시킵니다.
(Toleration) blue red green
Pods: 🔵 🔴 🟢 ⚫️ ⚫️
Nodes: 🟦 🟥 🟩 ⬛️ ⬛️
(Taint) blue red green
이후, 각 Pod의 배치를 허용할 수 있도록 하는 Tolerate 를 색상 별로 설정합니다.
그럼 의도대로 blue 노드에는 blue Pod가, green 노드에는 green Pod가 배치될 수 있습니다.
Pods: ⚪️ ⚪️ ⚪️ ⚫️ ⚫️
(scheduled)
Nodes: 🟦 🔵 🟥 🟩 🟢 ⬛️ 🔴 ⬛️
(Taint) blue red green X
하지만, 가능성이 있는 것이지, 해당 노드만을 선호한다는 보장은 없습니다.
따라서 Red Pod가 다른 팀의 노드(검은 노드)에 배치될 수 있습니다.
2. Affinity
먼저, 각 노드에 Label을 붙입니다.
그 다음, 각 Pod에 nodeSelector를 설정해 해당 Pod가 특정 Node에 배치되도록 유도합니다.
그럼 의도대로 blue, red, green Pod가 각각의 노드에 배치될 것입니다.
Pods: ⚪️ ⚪️ ⚪️ ⚫️ ⚫️
(scheduled)
Nodes: 🟦 🔵 🟥 🔴 🟩 🟢 ⬛️ ⬛️
(Taint) blue red green
하지만, 다른 Pod가 해당 노드에 배치되지 않는다는 보장이 없습니다.
즉, 다른 Pod가 우리 팀의 노드에 올 가능성이 있습니다.
Pods: ⚪️ ⚪️ ⚪️ ⚪️ ⚫️
(scheduled)
Nodes: 🟦 🔵 🟥 🔴 ⚫️ 🟩 🟢 ⬛️ ⬛️
(Taint) blue red green
3. Taints and Tolerations + Node Affinity
두 방식을 결합해서 사용하면 의도하는 동작을 정확히 수행 가능합니다.
처음에는 Taint 와 Toleration 를 사용해 다른 팀의 Pod가 우리 노드에 놓이는 것을 막습니다.
Pods: 🔵 🔴 🟢 | ⚪️ ⚪️
|
|
Nodes: 🟦 🟥 🟩 | ⬛️ ⚫️ ⬛️ ⚫️
(Taint) blue red green
이후, Node Affinity 를 통해 우리 포드가 다른 팀 노드에 놓이는 것을 막습니다.
Pods: ⚪️ ⚪️ ⚪️ | ⚪️ ⚪️
|
|
Nodes: 🟦 🔵 🟥 🔴 🟩 🟢 | ⬛️ ⚫️ ⬛️ ⚫️
(Taint) blue red green
그럼 여기까지, Node Affinity의 차이점까지 알아보았습니다.
| Reference |
🔗 Kubernetes.io - Official Docs
🔗 Udemy: certified-kubernetes-administrator-with-practice-tests
'BACKEND' 카테고리의 다른 글
| Kubernetes Scheduler, 제대로 이해하기 (0) | 2024.03.31 |
|---|---|
| Kubernetes Affinity, 제대로 이해하기 (0) | 2024.03.25 |
| Kubernetes Deployment, 제대로 이해하기 (0) | 2024.03.17 |
| Kubernetes Architecture, 제대로 이해하기 (0) | 2024.03.03 |
| Redis ZSET, 제대로 이해하기 (1) | 2023.12.27 |
Backend Software Engineer
𝐒𝐮𝐧 · 𝙂𝙮𝙚𝙤𝙣𝙜𝙨𝙪𝙣 𝙋𝙖𝙧𝙠