Control Plane 노드에 Pod를 배치할 때의 Toleration

일반 Pod가 배치되지 않도록 설정된 master 노드에서 워크로드를 실행해야 할 때 참고했던 설정입니다. 당시 메모에는 node-role.kubernetes.io/master의 NoSchedule Taint에 대응하는 Toleration이 있었습니다.

현재 문서에서는 master보다 control plane이라는 용어를 사용합니다. 실제 Taint 키도 클러스터의 버전과 설치 방식에 따라 다를 수 있으므로 노드에 설정된 값을 먼저 확인해야 합니다.

노드의 Taint 확인

bash


kubectl describe node control-plane-1

출력의 Taints 항목에서 키와 값, effect를 확인합니다. control-plane-1은 설명용 노드 이름입니다.

NoSchedule은 이를 허용하지 않는 Pod의 새 배치를 막습니다. 이미 실행 중인 Pod를 바로 내보내는 동작은 아닙니다. Pod가 Pending이라고 해서 원인이 항상 이 Taint인 것은 아니므로 Pod 이벤트도 함께 확인합니다.

다음은 당시 키를 사용하는 Pod spec의 일부입니다.

yaml


tolerations:
  - key: node-role.kubernetes.io/master
    operator: Exists
    effect: NoSchedule

Pod에서는 .spec.tolerations에, Deployment나 DaemonSet에서는 .spec.template.spec.tolerations에 넣습니다. Exists는 해당 키와 effect에 대응하며 특정 값을 지정하지 않는 방식입니다.

클러스터에 node-role.kubernetes.io/control-plane 키가 설정돼 있다면 실제 키에 맞춰 작성해야 합니다. 두 키가 언제나 함께 존재한다고 가정할 수는 없습니다.

Toleration은 해당 Taint 때문에 배치가 거절되지 않게 해줍니다. 특정 노드에 반드시 배치하라는 조건은 아닙니다. 다른 Taint와 자원 요청, Node Affinity 등의 조건도 통과해야 합니다.

대상 노드를 제한하려면 노드 레이블을 확인해 nodeSelector나 Node Affinity를 별도로 구성할 수 있습니다. Taint와 Toleration은 권한 인증이나 네트워크 격리 기능을 대신하지도 않습니다.

Pod의 이벤트와 실제 배치 노드를 확인합니다.

bash


kubectl describe pod example-pod -n example
kubectl get pod example-pod -n example -o wide

노드의 Taint를 없애면 다른 워크로드의 배치 조건도 함께 바뀝니다. 특정 Pod를 허용하려는 목적이라면 노드 전체의 조건을 바꾸기보다 해당 워크로드의 설정으로 범위를 좁히는 편이 관리하기 쉽습니다.