1) About
어플리케이션에 따라 요구하는 자원이 다르므로, 만일 특정 어플리케이션이 매우 큰 자원을 요구하는 경우, 자원량이 큰 노드에 배치하는 것이 적절
이와 같이 어플리케이션을 특정 노드로 제한시키는 작업을 쿠버네티스가 지원하는데, Node Selector와 Node Affinity의 방법이 있음
2) Node Selector
Pod 정의 파일에서 spec.nodeSelector 필드를 기재할 수 있음
해당 필드에 기재되는 것은 키와 값 묶음인데, 이는 노드에 할당된 라벨을 지칭
즉, Pod가 특정 노드로만 스케줄링 되기 위해 Node Selector를 이용하는 것은 노드에 존재하는 라벨의 매칭을 이용하는 것이므로, 노드에 라벨을 붙일 수 있어야함
apiVersion: v1
kind: Pod
metadata:
name: pod-sample
spec:
containers:
- name: pod-sample
image: pod-sample
nodeSelector:
key: value
YAML
복사
kubectl label node ${NODE_NAME} ${KEY}=${VALUE}
노드에 Taint를 붙이는 작업과 비슷한데, 위 명령어를 통해 노드에 라벨을 할당할 수 있음
Node Selector는 라벨의 정확항 매칭에 따라서 동작하기 때문에, 라벨1 또는 라벨2라든가 라벨3이 아닌… 등의 조금 더 복잡한 표현식으로는 동작하기 어려움
이를 만족시키기 위해 Node Affinity (Affinity & Anti-Affinity)라는 개념이 등장
3) Node Affinity
Great Power comes Great Complexity
Node Affinity는 Node Selector에 비해 더 복잡한 기능을 제공하는 만큼 복잡성이 높음
이전에 작성된 yaml과 동일한 기능을 수행하기 위해선 아래와 같이 작성하게 됨
apiVersion: v1
kind: Pod
metadata:
name: pod-sample
spec:
containers:
- name: pod-sample
image: pod-sample
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: key
operator: In
values:
- value
YAML
복사
Node Affinity에 명시된 조건이 일치하는 노드가 없거나, 노드에 붙여진 라벨이 변경되는 경우에는 어떻게 될까?
이 때의 행동을 결정하는 것이 requiredDuringSchedulingIgnoredDuringExecution과 같이 장황한 필드
이와 같은 필드는 Node Affinity Type이라고 함
Node Affinity Type은 곧 Pod의 라이프사이클을 정의하는 것과 동일한데, 총 3가지의 타입이 있음
1) requiredDuringSchedulingIgnoredDuringExecution
2) preferredDuginSchedulingIgnoredDuringExecution
3) requiredDuringSchedulingRequiredDuringExecution
1, 2는 현재 이용할 수 있으며, 3은 지원 예정
필드의 이름에서 볼 수 있듯이 라이프사이클은 2가지 상태로 구분 되는데, Pod가 처음 생성되는 상태를 Scheduling, 이미 생성되어 있는 상태가 Execution
옵션의 이름대로 동작하게 되는데,
Scheduling | Execution | |
1 | required | Ignored |
2 | preferred | Ignored |
3 | required | required |
와 같다고 볼 수 있음
** 1의 경우 반드시 매칭되는 라벨이 있어야 스케줄링이 되고, 2의 경우 매칭되는 라벨이 없다면 아무 노드에 배치
** 현재 지원되는 옵션의 경우 Execution에서는 무시인데, 3이 지원된다면 매칭되는 라벨이 없을 때는 Pod를 방출하거나 종료