[따배쿠/멤버십] 12-1. Pod Scheduling

파드를 스케줄링할때 커스터마이징 할 수 있다.

그때 사용되는 기술은 

 

• Node Selector
• Affinity & antiAffinity
• taint & toleration
• cordon & drain

으로 4가지 가 있다.

 

먼저 Node Selector에 대해 알아보자

Node Selector는 노드의 할당된 레이블을 이용해서 파드를 실행할 노드를 선택한다.

그림과 같이 3개의 노드가 있다고 가정해보자

각 노드의 하드웨어 스펙이 같으면 좋겠지만 다른 경우가 종종 있다.

이런 경우에는 우리가 k8s에 각 노드의 스펙에 대해 알려줘야한다.

알려주는 방법으로는 노드에 레이블을 붙여주는 것이다.

 

kubectl label node node{1,2} gpu=true 를 통해 노드 1, 노드2에 gpu=true라는 레이블을 붙여줬다.

 

이제TensorFlow라는 gpu가 요구되는 애플리케이션 파드를 실행해보기 위해서 먼저 tensorflow.yaml 파일의 내용을 보자

nodeSelector에 gpu: "true"를 통해 레이블에 gpu가 true인 노드들에만 텐서플로우의 파드가 동작하도록 하였다.

 

kubectl apply -f tensorflow-gpu.yaml 로 동작시킨다.

그럼 레이블에 gpu=true가 있는 노드1에 잘 실행 되는걸 볼 수 있다.

 

 

 

 

 

 

두 번째로 Affinity와 antiAffinity에 대해 알아보자

 

nodeAffinity는 nodeSelector와 매우 유사하다.

다른 점이 있다면 nodeAffinity에는 조건을 넣을 수 있다.

requireDuringSchedulingIgnoredDuringExecution은 노드셀렉터와 같이 조건에 맞는 노드에서만 파드를 실행시킨다.

preferredDuringSchedulingIgnoredDuringExecution은 조건에 맞는 노드가 있으면 가중치를 붙여서

밸류가 가장 높은 순서대로 파드실행을 시켜준다.

 

kubectl label node node2 disktype=ssd 을 통해 이번에는 노드2에 디스크 타입이 ssd라는 레이블을 추가해보자

그럼 노드2에는 gpu가 true이고 disktype은 ssd인 레이블을 가지게 된다.

 

텐서플로우를 실행시키기 위한 tensorflow-gpu-ssd.yaml의 내용은 아래와 같다.

affinity 항목의 nodeAffinity를 보면 

requireDuringSchedulingIgnoredDuringExecution에는 레이블의 key가 disktype으로 존재하는 노드에서만 실행한다는 필수조건을 넣었고

preferredDuringSchedulingIgnoredDuringExecution에는 레이블의 key가 gpu에 true값을 가지고 또한 key가 disktype에 ssd 값을 가지는 노드에 가중치를 10을 누적시키도록 하였다.

 

노드1은 레이블의 key가 gpu에 true값을 가지므로 가중치가 10이다.

그러나 노드1은 requireDuringSchedulingIgnoredDuringExecution를 만족시키지 못하므로 노드1에서는 파드가 실행되지 않는다.

노드2는 레이블의 key가 gpu에 true값을 가지고 레이블의 key가 disktype에 ssd값을 가지므로 가중치가 20이다.

 

만약 노드3이 존재하고 레이블의 key가 disktype에 ssd값을 가지고 레이블의 key가 gpu에 true값을 가지지 않는다면

requireDuringSchedulingIgnoredDuringExecution는 통과하고 preferredDuringSchedulingIgnoredDuringExecution에서는 가중치가 10으로 kubectl apply -f tensorflow-gpu-ssd.yaml로 파드를 실행시키면 노드2에서 파드가 실행될 것이다.

 

 

kubectl label node node2 gpu- 을 통해 노드2의 gpu 레이블을 삭제하고

kubectl label node node1 disktype=ssd를 통해 노드1에 disktype=ssd 레이블을 추가하면

노드1의 가중치는 20이 되고 노드2의 가중치는 10이 되어서 노드1에서 파드가 실행된다.

 

 

 

 

kubectl delete pods --all 로 모든 파드를 지우고

kubectl label node{1,2} gpu- disktype- 로 레이블을 지우자

 

 

 

 

Affinity는 pod에도 사용 가능하다.

만약 DB pod와 프론트, 백엔드로 동작되는 워드프레스 pod가 있다고 가정해보자

DB pod와 워드프레스 pod가 같은 노드에 있을때 파드간 네트워크 통신이 외부로 나가지않아서 성능이 더 좋다고 한다면

이 두개의 파드 같은 노드에 실행시켜달라고 podAffinity를 요청할 수 있다.

반대로 같은 노드에 실행시킬때 성능이 떨어진다면 다른 노드에서 실행하도록 podAntiAffinity를 pod에 적용해 사용할 수 있다.

추가로 podAffinity에서는 topologyKey라는 서브 조건이 들어갈 수 있다.

 

 

kubectl run -l app=backend backend --image=busybox -- sleep 9999999 을 통해

busybox라는 이미지의 컨테이너를 backend라는 이름으로 app=backend라는 레이블을 가지고 백엔드에서 동작 시키고  9999999초라는 긴 시간 동안 슬립시킨다.

 

 

pod-affinity.yaml파일의 내용은 아래와 같다.

replicas는 5개이고

requiredDuringSchedulingIgnoredDuringExecution은 레이블이 app=backend인 곳에서 실행시키도록 하고

top

 

 

kubectl apply -f pod-affinity.yaml로 실행시키면 모두 노드2에서 실행되는걸 볼 수 있다.

이는 레이블이 app=backend인 노드2에서 동작하고 있는 것이다.

 

 

이제 antiAffinity를 적용해보자

kubectl delete -f pod-affinity.yaml로 파드 5개를 삭제시킨다.

 

pod-antiaffinity.yaml 파일의 내용은 아래와 같다.

podAntiAffinity로 app=backend 레이블이 없는 노드에 파드를 실행하도록 되어있다.

 

kubectl apply -f pod-antiaffinity.yaml 을 통해 실행시키고 확인해보면 app=backend 레이블이 없는 노드1에서 파드 5개가 실행중인걸 볼 수 있다.

 

 

 

실습을 마쳤으니 kubectl delete -f pod-antiaffinity.yaml로 파드5개를 삭제한다.