Introduction
taint 및 tolerations는 어떤 파드가 노드에 스케쥴될수 있는지에 대한 제한을 설정하는 데 사용됩니다. taint 과 tolerations은 클러스터에 대한 보안 또는 침입과 아무 상관이 없습니다. Kubernetes에서 taint와 toleration은 특정 노드에 특정 파드만 배치되도록 제어하는 메커니즘입니다. 이 개념을 쉽게 이해하기 위해 사람과 벌레의 비유를 사용해 보겠습니다.
비유로 이해하기
- 사람(노드)이 구충제 스프레이(taint)를 뿌리면 벌레가 다가오지 못합니다.
- 하지만 내성(tolerance)이 있는 벌레(파드)는 스프레이가 있어도 접근할 수 있습니다.
Kubernetes에서 Taint와 Tolerations의 동작 방식
- Taint 추가: 특정 노드가 원치 않는 파드를 받지 않도록 설정합니다.
- Toleration 추가: 특정 파드가 해당 taint를 무시할 수 있도록 설정합니다.
- 스케줄링 과정:
- 기본적으로 taint가 있는 노드는 모든 파드를 거부합니다.
- 특정 파드에 toleration을 추가하면 해당 노드에 배치될 수 있습니다.
예제 시나리오
- 노드: 노드1, 노드2, 노드3
- 파드: A, B, C, D
기본적으로 스케줄러는 제한 없이 모든 노드에 파드를 균등 배치합니다. 그러나 노드1을 특정 애플리케이션 전용으로 설정하고 싶다면 taint를 추가합니다. 요구 사항은 노드1에 원치 않는 파드는 배치되지 않아야 합니다. 또한, 노드1에는 특정 파드만 배치될 수 있어야 합니다.
노드1에 blue라는 taint를 추가합니다. 이 설정으로 인해 기본적으로 어떤 파드도 노드1에 배치되지 않습니다.
kubectl taint nodes 노드1 key=blue:NoSchedule
특정 파드(D)만 노드1에 배치할 수 있도록 toleration을 추가합니다. pod-D 는 blue taint를 무시할 수 있기 때문에 노드1에 배치됩니다.
apiVersion: v1
kind: Pod
metadata:
name: pod-d
spec:
tolerations:
- key: "blue"
operator: "Exists"
effect: "NoSchedule"
결과적으로 파드 A, B, C는 노드1에 배치되지 않지만 파드 D는 노드1에 배치됩니다.
Taints
kubectl taint nodes 커맨드를 사용하여 노드에 taint를 설정합니다. 커맨드 뒤에 key-value쌍으로 노드이름과 taint를 지정하면 됩니다.
kubectl taint nodes <node-name> key=value:taint-effect
kubectl taint nodes 노드1 key=blue:NoSchedule
예를 들어 노드를 blue 애플리케이션 전용으로 지정하려는 경우, key-value 쌍은 app=blue가 됩니다. taint effect는 taint에 toleration가 없는 파드를 어떻게 처리할 것인지를 결정합니다. 3가지 종류의 taint effect가 있습니다.
- NoSchedule: 앞에서 우리가 말한 것 처럼 toleration가 없는 파드는 taint가 있는 노드에 스케쥴링 되지 않습니다.
- PreferNoSchedule: 시스템이 되도록이면 taint가 있는 노드에 파드를 배치하지 않으려하지만 가능은 합니다.
- NoExcuse: toleration이 없는 새로운 파드는 노드에 배치되지 않으며, 이미 노드에 존재하는 파드는 toleration가 없다면 축출됩니다. 이미 노드에 존재하던 파드는 노드에 taint가 설정되기 전에 스케쥴링되었을 것입니다.
Tolerations
파드에 toleration을 추가하려면 먼저 파드 Definition file을 가져와야 합니다. Definition file의 spec섹션에 tolerations라는 섹션을 추가합니다. taint를 생성했을 때 사용한 값과 동일하게 입력합니다. value는 "blue"이고, effect는 "NoSchedule"입니다. toleration섹션의 모든 값은 쌍따옴표로 감싸야 하는 것을 기억하세요.
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: nginx-container
image: nginx
tolerations:
- key: "app"
operator: "Equal"
value: "blue"
effect: "NoSchedule"
이제 파드가 toleration를 가지고 생성되거나 toleration을 가지도록 업데이트될 때, effect에 따라 스케쥴링이 안되거나 기존 노드에서 제거될 것입니다.
Taint - NoExcuse
NoExcuse taint effect에 대해 더 알아보겠습니다. 예를 들어 3개의 노드가 있습니다. 지금은 아무런 taint나 toleration이 없기 때문에 아래와 같은 방식으로 스케쥴링이 이루어집니다.

이제 노드1을 특정 애플리케이션 전용으로 사용하기로 결정했습니다. 노드에 taint를 애플리케이션 이름으로 설정하고 특정 애플리케이션에 속하는 파드D 에도 toleration을 추가했습니다. taint effect는 NoExcuse로 설정했습니다. taint effect가 발생하면 파드 C는 노드에서 제거되게 됩니다. 제거된 파드 C는 죽습니다. 파드D는 blue taint에 toleration을 가지고 있기 때문에 노드에서 계속 실행됩니다.

taints와 tolerations 는 노드가 특정한 파드를 허용하는 것에 대한 제한을 의미합니다. 이 케이스에서는 노드 1은 오직 파드 D만 수용할 수 있습니다. 그러나 파드D가 항상 노드1에 있다는 것을 보장하지는 않습니다. 다른 두 노드에 taints가 적용되지 않았기 때문에, 파드 D는 다른 두 노드에도 배치될 수 있습니다. 따라서 taints와 tolerations가 파드가 특정 노드로 간다는 것을 말하는 것이 아닙니다. 대신, 노드가 특정 toleration을 가지고 있는 파드만 허용한다는 것을 의미합니다.

만약 요구사항이 파드가 특정 노드로 가는 것을 제한하는 것이라면, 이는 또 다른 개념인 node affinity를 통해 구현됩니다.
https://hyukops.tistory.com/59
Kubernetes Node Selector & Node Affinity
Node Selector간단한 예시로 시작하겠습니다. 3개의 노드가 있는 클러스터가 있으며 그 중 2개는 더 낮은 하드웨어 리소스를 가진 더 작은 노드입니다. 다른 하나는 더 높은 리소스로 구성된 더 큰
hyukops.tistory.com
지금까지는 우리는 워커 노드만 언급했습니다. 그러나 클러스터에는 마스터 노드도 있습니다. 마스터노드는 파드를 호스팅하고 모든 관리 소프트웨어를 실행할 수 있습니다. 하지만 Kubernetes 클러스터가 처음 설정되면 마스터 노드에 taint가 자동으로 설정되어 파드가 마스터 노드에 스케쥴링되지 않도록 합니다. 우리는 이 것을 확인할수도 있고 필요하면 동작을 수정할 수도 있습니다. 그러나 best pratice는 마스터 서버에 애플리케이션 워크로드를 배포하지 않는 것입니다.
kubectl describe node kubemaster
이 taint를 보려면 위의 명령을 실행하면 확인할 수 있습니다. taint섹션을 보려면
kubectl describe node kubemaster | grep Taint
위의 명령어를 실행하면 됩니다.
'Kubernetes & EKS > k8s 공부 기록' 카테고리의 다른 글
| [kubernetes] EKS 파드 스케줄링: topologySpreadConstraints (0) | 2025.03.31 |
|---|---|
| [kubernetes] EKS 파드 스케줄링: podAntiAffinity (0) | 2025.03.31 |
| [kubernetes] Resource Requirements and Limits (0) | 2025.03.14 |
| [kubernetes] Node Selector & Node Affinity (0) | 2025.03.14 |
| [kubernetes] Pod 헬스 체크 (Probe) (0) | 2025.03.14 |