1) About
Pod가 특정 노드에 배치되지 않도록 강제할 수 있는데, 이를 가능하게 하는 것이 Taint와 Toleration
** Pod가 특정 노드에 배치되도록 강제하는 것과는 다름 → 이는 추후에 소개되는 Node Affinity를 이용해야함
예를 들어 특정 객체에 Taint로 마킹을 해두고, 해당 객체에 접근하려는 다른 객체가 Taint에 Tolerable 하다면 접근이 가능하고, In-Tolerable 하다면 접근이 불가능하게 되는데, 이와 같은 개념을 노드와 Pod 사이에 적용 가능
Taint와 Toleration은 보안적인 측면과는 크게 관련이 없고, 그저 스케줄링에 제한을 두는 방법
예를 들어 특정 x라는 노드에 Taint=t라고 두고 y라는 Pod에게 Toleration=t를 부여한다면, y는 x에 배치될 수 있음
노드에 Taint를 지정하기 때문에 kubectl로 이를 명시할 때는 노드의 이름을 사용하게 됨
잘 살펴보면 찾을 수 있는 사항인데, 스케줄러는 Pod를 마스터 노드에 스케줄링하지 않음
이는 쿠버네티스 클러스터가 초기에 세팅될 때, 마스터 노드에 Taint를 설정하기 때문
이와 같은 부분은 충분히 수정할 수 있지만, 마스터 노드에는 어플리케이션을 두지 않는 것이 쿠버네티스 운용 모범 사례
kubectl describe node kubemaster | grep Taint
위 명령어를 통해 마스터 노드에 적용된 Taint를 볼 수 있음
2) Commands
kubectl taint node ${NODE_NAME} ${KEY}=${VALUE}:${TAINT_EFFECT}
이름에 해당되는 노드에 키와 값에 해당되는 Taint를 남기고, Taint에 In-Tolerable할 때 어떻게 동작할지를 명시
${TAINT_EFFECT}에 해당되는 값으로는 NoSchedule / PreferNoSchedule / NoExecute로 나뉨
** ${VALUE}는 생략 가능
** NoSchedule은 추가적으로 Pod를 생성하여 스케줄링 시 배치되지 않도록 만듦
** PreferNoSchedule은 추가적으로 Pod를 생성하여 스케줄링 시 최대한 배치되지 않도록 만듦
** NoExecute는 Taint를 적용했 을 때 NoSchedule과 더불어 기존에 있던 Pod들 중에서도 In-Tolerable한 Pod를 모두 방출
** 이렇게 정의된 Taint를 Tolerable하게 만들기 위해선 Pod의 정의 파일에서 spec.tolerations 필드에 Taint 값을 명시 (해당 필드 하위 항목은 모두 “로 명시해야함)
apiVersion: v1
kind: Pod
metadata:
name: pod-sample
labels:
app: pod-sample
spec:
containers:
- name: nginx
image: nginx
tolerations:
- key: "taint-key"
operator: "Equal"
value: "taint-value"
effect: "NoSchedule"
YAML
복사
kubectl taint node ${NODE_NAME} ${KEY}=${VALUE}:${TAINT_EFFECT}-
Taint를 생성하는 형식과 비슷하지만 마지막에 대쉬 문자가 붙이면 Taint를 삭제