Kubernetes 고급지게 scheduling 하기

Jiyoon·2022년 3월 4일

Kubernetes

목록 보기

9/10

이번장 한줄 요약
Pod 스케줄링 - 고급편. 근데 이제 시나리오를 중심으로..

목차는
1. Taints와 Tolerance를 이용해 특정 node에 scheduling하기
2. Node affinity를 이용해 pod를 특정 node에다가 예약하기 / 우선순위 주기
3. Pod affinity를 이용해 pod를 co-locating하기

1.Taints와 Tolerence를 이용해 특정 Node에 Pod를 scheduling하기

Pod가 node의 taints를 허용하는 경우에만 node에 scheduling 될 수 있도록 한다.

Negative 👎
Taints
<key>=<value>;<effect> 의 형태로 되어있다

시나리오 📖

기존 Pod를 수정하고 싶지 않고, Node에 taint만 추가해서 특정 node에다가 특정 pod의 배포를 거부하고 싶을 때

mzc01-jiyoon@MZC01-JIYOON ~ % kubectl describe node minikube
Name:               minikube
...
Taints: node-role.kubernetes.io/master:NoSchedule

여기서는 master node에 NoSchedule이라는 효과를 가진 taint가 적용된다. 이 taint는 pod가 master node에 예악되는 것을 방지한다.

Node affinity를 이용해 pod를 특정 node에다가 예약하기

지난 시간에 했었던 Node selector랑 비슷한데, Node selector가 node affinity로 대체될 것이라는 점, enterprise 스케일에서는 더 세밀한 조정이 가능한(weight, 다양한 operator 지정 등..) affinity를 사용하는게 좋을 것이라는 점에서 차이가 있다.

Positive 👍
각 pod는 자체 node preference 규칙을 정의한다. 특정 pod에 대해 선호하는 node를 K8S에게 알려주면, 그 해당 node중 하나로 pod를 예약하려고 시도한다.

requiredDuringScheduling : 이 node에 예약되기 위해 가져야하는 label을 지정해야한다는 것을 의미한다
IgnoredDuringExecution : 이미 node에서 실행되고 있는 pod들에는 영향을 미치지 않음 (scheduling될 pod에만 영향을 미침)
nodeSelectorTerms & matchExpressions : pod가 node에 예약되기 위해서 node의 label이 일치해야하는 expressions를 정의

2. Node affinity를 이용해 pod scheduling시 우.선.순.위를 지정해주기

NodeAffinity는 node를 기준으로 스케줄링하는 기능이다.

시나리오 📖
각 node에 node가 속한 AZ를 지정하는 label을 주고, Node affinity rules를 통해 우선순위를 지정한다.

How?
NodeAffinity 에 preferredDuringSchedulingIgnoredDuringExecution 필드를 지정한다!

1) kubectl label node <node_name> availability-zone=zone1 명령어를 통해 라벨을 지정한다.
2) Deployment yaml 파일에 preferredDuringSchedulingIgnoredDuringExecution을 적용한다.

가중치에 대한 탐구
weight in preferredDuringSchedulingIgnoredDuringExecution ?
Node affinity가 작동하는 방식
cluster에 node가 많은 경우, pod 스케줄링할 때 node는 4개의 group으로 분할된다.
label이 2개 다 일치하는 그룹 / 하나만 일치하는 그룹2개 / 하나도 일치안하는 그룹

시나리오 📖
frontend pod / backend pod가 있을 때, 서로 가까이 대기하면 대기 시간이 단축된다. Backend pod 1개, front end pod(replicas) 5개 배포.

1) Backend pod deployment로 app=backend 라벨만 달아서 평범하게 배포한다
2) Frontend pod를 배포한다

Backend pod가 중간에 삭제되어도, 이미 적용된 규칙을 위반하지 않기 위해서 frontend의 new pods들은 같은 node에 배포된다.

여기서 topologyKey를 주목해보자.

topologyKey 가 작동하는 방식
Scheduler가 pod를 배포할 위치를 결정할 때,

- pod affinity config를 확인한다
- 이 label selector와 매치하는 pods를 찾는다 (약간 SQL WHERE절과 유사) , ex.app=backend
- 이 pods들이 어디서 실행중인지 nodes 를 찾아 이 키의 label을 사용하는 모든 nodes를 선택한다. (약간 SQL SELECT절과 유사) ex.rack:rack2
- topologyKey의 kubernetes.io/hostname (쿠버네티스에서 자동으로 미리 저장하는 label로 Node의 이름을 정의하는 label이다.