Manual scheduling
수동 스케쥴링엔 크게 두가지.
1. Nodename 필드 사용
- 이방법이 기본 방법이라 할수 있는데, yaml 에서 nodename 필드를 사용해서 pod를 특정 node에 배치 가능.
2. 바인딩 객체 생성
- 좀더 심화된 방법이라 할수 있으며, 이미 생성된 pod를 api를 사용해서 post요청을 통해 내부적 스케줄링 가능.
* 근데 실행중인 pod를 옮길순 없음. 그래서 replace --force -f 하면 삭제후 재실행됨
Labels and Selectors
labels를 통해서 각 요소간에 그룹핑을 할수 있고 selector를 통해서 그 그룹된것들을 묶어서 확인 혹은 명령어를 줄수 있음
kubectl get pod --selector bu=finance
이런식으로 확인하면 됨.
kubectl get pod --selector tier=frontend,bu=finance,bu=finance
여러개면 쉼표로 구분해서 하면 됨.
Taints and Tolerations
노드에 pod 를 스케쥴링 하는것을 제어하는 메커니즘
* Taint
Node에 설정되는것. 노드에 특정 조건을 만족하지 않는 Pod의 스케줄링을 방지. 예를 들어, 특정 노드에 "blue"라는 Taint가 있으면, 이 Taint를 용인할 수 있는 Toleration이 있는 Pod만 해당 노드에 배치될 수 있음
* Toleration
Pod에 설정되는것. Node의 Taint를 무시하고 스케쥴링 될수 있는거임.
kubectl taint nodes <노드 이름> key=value:effect
## example
kubectl taint nodes node1 app=blue:NoSchedule
Taint 종류에는 NoSchedule, PreferNoSchedule, NoExecute세가지 방법이 있음
그런데 Taint가 있다고 Toleration있는 파드를 그 노드에 스케쥴링을 보장하지는 않음. 그거는 Node Affinity라는 나중에 있을 개념으로 해야함.
그리고 이 모든건 마스터 노드는 제외하고 스케쥴링 됨. 왜냐면 클러스터 만들때 기본으로 마스터 노드는 테인트가 걸리기 때문임. 마스터엔 스케쥴링 안하는게 좋음
Node Selectors
Kubernetes에서 노드 선택자(Node Selectors)를 사용하여 특정 노드에 Pod를 스케줄링하는 방법은 간단하며, 리소스 요구사항이 특정한 Pod를 적합한 노드에 배치하는 데 도움이 됩니다.
kubectl label nodes <노드 이름> size=large
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mycontainer
image: myimage
nodeSelector:
size: large
한계가 있음 예를드, 예를들어 여러 조건의 limit을 못검. 그래서 그러면 Node Affinity를 써야함.
Node Affinity
Pod를 특정 노드에 스케줄링하는 데 사용되며, Node Selectors보다 더 세밀하고 유연한 조건을 제공
목적
노드 어피니티는 특정 조건을 만족하는 노드에만 Pod를 배치하기 위해 사용.
예시
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mycontainer
image: nginx
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: size
operator: In
values:
- large
여기서는 size=large 라벨 있는 노드에서만 실행되게함.requiredDuringSchedulingIgnoredDuringExecution은 Pod 스케줄링 시 노드 어피니티 규칙을 필수로 적용하지만, 실행 중에는 이를 무시한다는 것을 의미
타입
유형 | 설명 | 스케쥴링시 | 실행중 |
requiredDuringSchedulingIgnoredDuringExecution | Pod가 처음 스케줄링될 때 노드 어피니티 규칙을 반드시 만족해야 하며, 실행 중에는 규칙 변경을 무시함. | 반드시 규칙을 만족하는 노드에 스케줄링 | 노드의 상태 변경을 무시하고 Pod 계속 실행 |
preferredDuringSchedulingIgnoredDuringExecution | 스케줄러가 규칙을 만족하는 노드를 선호하지만, 필수 조건은 아님. 규칙을 만족하는 노드가 없다면 다른 노드에 스케줄링 가능. | 규칙을 만족하는 노드를 선호하지만, 필수 아님 | 노드의 상태 변경을 무시하고 Pod 계속 실행 |
requiredDuringSchedulingRequiredDuringExecution (계획 중) | 스케줄링 시뿐만 아니라 실행 중에도 지속적으로 노드 어피니티 규칙을 만족해야 함. 규칙을 더 이상 만족하지 않으면 Pod가 노드에서 제거될 수 있음. | 반드시 규칙을 만족하는 노드에 스케줄링 | 노드의 어피니티 규칙 불만족 시 Pod 제거 |
그러니까 taint&toleration은 다른걸 못들어오게 하는느낌이고 affinity는 원하는곳 배치시키는 느낌임. 둘다 사용해서 보완 가능
'kubernetes(cka)' 카테고리의 다른 글
[Kubernetes, cka] 08. Static Pods (1) | 2024.04.10 |
---|---|
[Kubernetes, cka] 07. DaemonSets (0) | 2024.04.01 |
[Kubernetes, cka] 05. Service, Namespaces (1) | 2024.03.24 |
[Kubernetes, cka] 04. Deployment (0) | 2024.03.24 |
[Kubernetes, cka] 03. Replica set (0) | 2024.03.24 |