Node Affinity

kind로 클러스터 구축

~/Desktop/code/kind  cat k8s-2node.yaml                                                                                        
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker

컨트롤 플레인 1개 워커 노드 2개가 생성된걸 확인할수있다.

kind-worker의 라벨을 확인

kind-worker2의 라벨을 확인

kind-worker 노드에 color=blue 라벨을 추가

Deployment를 생성하기전 명령어를 모르겠으면 찾아볼수있다.

kubectl create deployment --help

kind-worker 노드에 nginx 이미지 3개의 복제본을 사용하여 blue라는 이름의 Deployment 생성

kubectl create deployment blue --image=nginx -r 3

파드가 3개 생성된걸 확인할수있으며 파드가 생성된 노드를 확인할수있다.

여기서 궁금한게 왜 파드가 컨트롤 플레인에는 생성이 안되고 워커 노드에만 생성되었는지 궁금해졌다.
컨트롤 플레인에는 기본으로 Taint 설정이 되어있어서 파드가 생성이 안되었다는걸 알수있다.

아까 kind-worker 노드에 추가해준 color=blue 라벨로 blue 파드들을 kind-worker에만 생성될수있도록 수정해보겠음.
먼저 쿠버네티스 공식문서에 들어가면 Node Affinity 예시를 볼수있다.

이제

kubectl edit deploy blue

로 들어가서 파일을 수정해보겠습니다.

Node Affinity 필드를 추가해주고

kubectl get pods -o wide

로 확인해보면 blue 파드들이 kind-worker 노드에 배포된걸 확인할수있다.

이번에는 kind-control-plane 노드에 nginx 이미지 2개의 복제본을 사용하여 red라는 이름의 Deployment 생성 및 이미 설정된 레이블 키(node-role.kubernetes.io/control-plane)를 사용해보겠습니다.

kubectl create deploy red --image=nginx -r 2 --dry-run=client -o yaml > red.yaml

Node Affinity 필드를 추가해주기위해 파일 부터 만들었습니다.

vim red.yaml

로 파일 수정했습니다.

키=벨류 라벨을 잘못 넣어줘서 오류가났다.

The Deployment "red" is invalid: spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution.nodeSelectorTerms[0].matchExpressions[0].key: Invalid value: "kubernetes.io/hostname=kind-control-plane": name part must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName',  or 'my.name',  or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]')

다시 파일을 수정해서

다시 배포해줬는데 파드가 Pending 상태이다.

describe 파드의 이벤트를 확인해보겠다.

kubectl describe pods red-6c6fc8b746-srvfq

컨트롤 플레인의 Taint 때문에 오류가 난것같다.

Events:
  Type     Reason            Age                 From               Message
  ----     ------            ----                ----               -------
  Warning  FailedScheduling  2m56s (x7 over 9h)  default-scheduler  0/3 nodes are available: 1 node(s) had untolerated taint(s), 2 node(s) didn't match Pod's node affinity/selector. no new claims to deallocate, preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling.

컨트롤 플레인의 Taint 설정을 확인할수있으며, red Deployment에 Toleration 필드를 추가해서 컨트롤 플레인에 파드가 생성될수있도록 해보겠습니다.

kubectl edit deploy red

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

파드를 다시 확인해보면 red 파드들이 정상적으로 생성된것을 확인할수있다.

이번에는 동일한 상황에서 파드가 유연하게 컨트롤 플레인이 안되면 워커 노드에 red pod들이 생성될수있게 해보겠다. 기존에 배포해놓은 red Deployment를 지우겠습니다.

그리고 다시 라벨을 확인

red Deployment 파일을 만들어주겠습니다. Node Affinity를 설정해줘야하기때문에 --dry-run=client 로 하겠습니다.

k create deploy red --image=nginx -r 3 --dry-run=client -o yaml > red.yaml

red.yaml 파일이 생성된것을 확인할수있습니다.

이제 preferred 필드를 사용해서 동일하게 컨트롤 플레인에 배포해보겠습니다.

그러면 아까와는 다르게 pending 이 안걸리고 워커 노드에 생긴걸 확인할수있다.

toleration 필드를 추가해줘서 컨트롤 플레인에 파드가 재배치되는지 해보겠습니다.
다시 테인트 값을 확인하구

vim으로 tolerations 필드를 추가해줬습니다.

이제 파드의 위치를 확인해보면 컨트롤 플레인에 파드가 뜬것을 확인할수있다.

... (실습 내용 마침) ...

결국 Toleration과 Node Affinity 설정을 모두 마친 뒤에야 파드가 의도한 마스터 노드에 안착하는 것을 확인할 수 있었다.

요약: 설정 방식에 따른 결과 차이

구분	required (강제 규정)	preferred (유연한 권고)
핵심 철학	"조건 안 맞으면 차라리 안 띄운다."	"가급적 여기로, 안 되면 다른 데라도!"
스케줄링 결과	조건 만족 노드 없으면 Pending	조건 만족 노드 없어도 다른 노드 배포
주요 특징	엄격한 격리, 보안 및 성능 보장	고가용성(HA), 리소스 효율성 극대화

---

참조 자료 (References)

• [Kubernetes Docs][Taints and Tolerations] (https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)
• [Kubernetes Docs][Node Affinity] (https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)