특정 노드에 파드를 스케줄링하기 위함
node selector와 유사하지만 다양한 operator사용 가능하다는 점에서 더 고급기술?이라고 할 수 있음 → 더 유연하게 스케줄링 가능
노드에 붙어있는 라벨을 기반으로 이 파드를 배치할지 말지를 판단함
"조건에 맞는 라벨을 가진 노드가 있다면 파드를 그곳에 배치한다"
중간에 배를 갈라서 앞뒤로 2가지가 합쳐졌다고 보면 된다.
노드 어피니티 = 스케줄링 규칙 + 실행중 규칙
예를 들어,
requiredDuringSchedulingIgnoredDuringExecution
= requiredDuringScheduling
+ IgnoredDuringExecution
requiredDuringScheduling
: 조건을 만족해야 스케줄링preferredDuringScheduling
: 조건을 만족하는 노드를 선호하지만, 마땅치 않으면 임의의 노드에 파드를 배치IgnoredDuringExecution
: 조건을 만족하는 노드가 없어지더라도(노드의 라벨 변경 등의 사유) 파드를 건드리지 않음RequiredDuringExecution
: 조건을 만족하는 노드가 없어진다면(노드의 라벨 변경 등), 해당 파드를 제거requiredDuringSchedulingIgnoredDuringExecution
preferredDuringSchedulingIgnoredDuringExecution
requiredDuringSchedulingRequiredDuringExecution
spec.affinity.nodeAffinity
에 원하는 종류의 어피니티와 규칙을 적는다.
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disktype
operator: In
values:
- ssd
...
이 파드는 노드의 disktype 이라는 라벨의 키가 존재하며, 그 값이 ssd일 때 스케줄링 된다.
실행 중 조건에 맞는 노드가 없어도 여전히 그 노드에 유지된다.
# 예시
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
app: red
name: red
spec:
replicas: 2
selector:
matchLabels:
app: red
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: red
spec:
containers:
- image: nginx
name: nginx
resources: {}
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: node-role.kubernetes.io/control-plane
operator: Exists