목차
Node마다 하드웨어 리소스가 다르며, application의 필요 리소스가 상이할 때, 필요 요구에 맞춰 특정 Node에 배치할 수 있는 방법으로 “Node Selector”와 “Node Affinity”가 있다
Node Selctors
# pod-definition.yml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: data-processor
image: data-processor
nodeSelector:
size: Large
YAML
복사
•
기존 정의 파일에 spec.nodeSelector 를 추가하여 크기 지정
◦
노드의 크기를 어떻게 판단?
▪
size와 그 크기에 대한 값 (키값 쌍)은 노드에 할당된 Labels임
◦
Scheduler는 Label을 이용해 Pod을 올릴 Node를 찾아냄
◦
따라서 Pod를 만들기 전에 Node에 Label를 달아야 함
Label Nodes
Label을 통해 Pod를 노드에 지정하기 위해 Node Labeling이 선행되어야 함
•
kubectl label nodes <node-name> <label-key>=<label-value>
◦
kubectl label nodes node1 size=Large
Node Selector는 간단하지만 복잡한 요구 사항을 해결할 수 없는 한계가 있다
Ex) Large나 Medium에 배치, Small이 아닌 Node에 배치 등
이를 해결하기 위해 Node Affinity 사용
Node Affinity
Node Affinity의 목적은 Pod가 특정 Node에 호스트될 수 있도록 하는 것이다
# pod-definition.yml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
spec:
containers:
- name: data-processor
image: data-processor
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: size
operator: In
values:
- Large
- Medium
YAML
복사
•
nodeSelectorTerms는 키값쌍의 key, operator, values를 가지며 values는 리스트를 값으로 가짐
Operators
•
In operator는 리스트에 지정된 값을 갖는 Node에 Pod를 배치하도록 함
◦
위의 정의 파일은 Large나 Medium 값을 가지는 Node에 배치됨
•
Exists operator는 단순히 Label이 존재하는지 확인하여 있으면 배치
◦
값 비교를 하지 않기 때문에 values 섹션이 필요 없음
Node Affinity Types
Scheduler의 기능을 정의 (Node Affinity와 Pod의 LifeCycle 정의)
•
타입은 두 가지 존재하며, 실행중에 조건이 바뀌어도 무시함
◦
Pod가 이미 생성되어 특정 Node에서 실행 중일 때, Node의 조건이 변경되어도 Pod는 유지됨
requiredDuringSchedulingIgnoredDuringExecution
스케줄링하는 동안 꼭 필요한 조건
•
Affinity를 만족하는 Node가 없다면 Pod는 Scheduling되지 않음
•
Pod의 위치가 중요할 때 사용
preferredDuringSchedulingIgnoredDuringExecution
스케줄링하는 동안 만족하면 좋은 조건
•
Affinity를 만족하는 Node가 없다면 Pod는 아무 가용한 Node에 Scheduling됨
•
Pod의 위치가 비교적 덜 중요할 때 사용