Skip to Content
Infra & DevOpsK8s 마스터 노드 파드 배포 (Tolerations)
☁️ Infra & DevOps2019년 6월 20일

K8s 마스터 노드 파드 배포 (Tolerations)

#kubernetes#infra-devops#pod#scheduling#toleration#taint

1. 마스터 노드 전용 배포의 필요성

에서 쿠버네티스(K8s) 기반의 빅데이터/AI 통합 플랫폼을 사내망에 처음 구성하던 R&D 초창기 시절이었습니다. 개발용으로 할당받은 물리 서버 자원은 한정되어 있었는데, K8s 스탠다드 아키텍처 상 ‘마스터 노드(Control Plane)‘는 오직 클러스터 매니지먼트(apiserver, etcd, scheduler 등) 용도로만 고립되어 일반 파드(Pod)가 스케줄링되지 않는 낭비(?)가 발생했습니다.

또한 리소스 부족 문제 외에도, 클러스터 전체의 로그를 수집하는 Filebeat 데몬셋이나 하드웨어 지표를 수집하는 Node Exporter는 워커 노드뿐만 아니라 마스터 노드 위에도 반드시 배포되어야 하는 시스템 레벨의 필수 워크로드였습니다.

하지만 일반적인 매니페스트(YAML)로 데몬셋을 띄우면, 마스터 노드에만 파드가 생성되지 않거나 영원히 Pending 상태로 머물게 되는 현상이 발생합니다.

2. 보안의 핵심: Taint와 Toleration 개념

이 현상은 마스터 노드에 기본적으로 Taint(오염/거부 표식) 가 걸려 있기 때문입니다. Taint는 “아무나 여기 들어오지 마”라는 푯말과 같습니다.

  • Taint (오염): 노드에 설정하는 제약 조건. 이를 가진 노드는 특정 파드의 접근을 거부함.
  • Toleration (관용/내성): 파드에 설정하는 통행증. 자신이 어떤 Taint를 무시하고 스케줄링될 수 있는지를 K8s 스케줄러에게 알려줌.

기본적으로 K8s 클러스터가 kubeadm 커맨드로 생성될 때, 마스터 노드에는 아래와 같은 NoSchedule Taint가 자동으로 강제 주입됩니다.

bash
# 마스터 노드의 Taint 확인 명령
$ kubectl describe node <master-node-name> | grep Taints
Taints:             node-role.kubernetes.io/master:NoSchedule

(※ 버전에 따라 node-role.kubernetes.io/control-plane:NoSchedule 일 수도 있습니다.)

3. 파드 매니페스트에 Toleration 룰 주입하기

① 특정 파드에 마스터 노드 통행증(tolerations) 부여

단일 파드(Pod)나 데몬셋, 디플로이먼트의 .spec.template.spec 하위에 tolerations 배열 속성을 명시하면 됩니다. “나는 저 master Taint를 허용(Tolerate)하겠다” 라고 선언하는 것입니다.

yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-special-pod
spec:
  containers:
  - name: my-special-pod
    image: nginx:latest
  tolerations:
  - key: "node-role.kubernetes.io/master"  # 버전에 따라 control-plane 으로 변경
    operator: "Exists"
    effect: "NoSchedule"
  • operator: "Exists": Taint의 값이 무엇이든 상관없이 해당 key가 존재한다면 용인하겠다는 의미입니다.
  • effect: "NoSchedule": 이 Taint의 스케줄링 차단 효과를 무시하겠다는 의미입니다.

② (안티 패턴) 마스터 노드의 Taint 자체를 삭제하기

자원 부족이 너무 심각해서 마스터 노드를 아예 일반 워커 노드처럼 굴리고 싶다면, 통행증을 주는 대신 출입문 자체를 부숴버릴 수도 있습니다.

bash
# 마스터 노드의 Taint 표식 강제 삭제 (끝에 마이너스 '-' 기호 주의)
$ kubectl taint nodes --all node-role.kubernetes.io/master-

이 명령어는 로컬 미니쿠베(Minikube)나 R&D 서버에서는 유용하지만, 프로덕션 환경에서는 마스터 노드 자원 고갈이 클러스터 전체의 붕괴를 초래할 수 있으므로 절대 권장하지 않습니다.

4. 결론 및 회고

인프라 리소스가 극도로 부족했던 시절에는 앞서 언급한 두 번째 방법(Taint 자체 제거)을 통해 마스터 노드의 CPU와 RAM 리소스까지 알뜰하게 끌어다 썼습니다.

하지만 플랫폼이 프로덕션 환경에 가까워지고 여러 고객사에 배포될수록, 마스터 노드의 보안과 리소스 독립성을 철저히 보장하는 것이 최우선이 되었습니다. 결국 마스터 노드에는 Taint를 무조건 남겨두고, 시스템 상태 감시를 위해 100% 필요한 ‘최소한의 모니터링 에이전트’ 파드에만 엄격하게 Tolerations 권한을 부여하여 마스터 노드에 내리는 모범 사례(Best Practice) 아키텍처로 정착하게 되었습니다.

쿠버네티스의 스케줄링 알고리즘은 이처럼 Taint와 Toleration의 교묘한 조합을 통해, 클러스터의 안정성과 유연성이라는 두 마리 토끼를 모두 잡을 수 있게 해줍니다.

Last updated on