kubernetes scheduling

기본적인 kubernetes resource, option 등을 설명한 블로그입니다. 추가적인 기능을 보고싶으시면 docs를 참고바랍니다.

https://kubernetes.io/docs/home/

Kubernetes Documentation

 

• Pod를 scheduling할 때 Node Selector, Affinity & antiAffinity, taint & toleration, cordon & drain이 있다.
• pod를 scheduling할 때 위와 다르게 manual하게 하는 방법도 있는데, nodeName: [node name]을 지정하거나, binding type을 지정해서 curl로 직접 request를 한다.
• kubectl label nodes [node name] [key]=[value] -> node label을 설정한 다음 node selector를 이용하여 schedulling.
• kubectl label node node{2,3}.example.com gpu=true -> node 2, 3번이 gpu=true라는 label이 생김. {1..3}이라는 뜻은 1~3.

 

...
kind: Pod
...
spec:
  containers:
  - name: tensorflow
  ...
  nodeSelector:
    gpu: "true"

 

• nodeAffinity -> 특정 노드에만 pod가 실행되도록 유도하며 nodeSelector와 비슷하지만 요구를 만들 수 있다.
• requiredDuringSchedulingIgnoredDuringExecution -> 엄격한 요구, nodeSelector와 똑같음. 조건에 맞으면 할당.
• preferredDuringSchedulingIgnoredDuringExecution -> 선호도 요구, 조건에 맞으면 가중치를 높여서 할당.
• requiredDuringSchedulingRequiredDuringExecution -> 중간에 label 바꾸고 pod와 taint-toleration관계가 맞지 않으면 ignore 되지 않고 pod들이 evict 된다.

 

kind: Pod
...
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - {key: disktype, operator: In, values: ["ssd"]}
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 10
        preference:
          matchExpressions:
          - {key: gpu, operator: In, values: ["true"]}
# disktype key가 ssd인 node에서 실행
# 그 중에서도 gpu가 true인 곳에서 우선순위를 둔다.

 

• podAffinity -> pod를 더 가깝게 배치. requiredDuringSchedulingIgnoredDuringExecution 
• podAntiAffinity -> pod를 더 멀리 배치. preferredDuringSchedulingIgnoredDuringExecution
• topologyKey -> 노드 label을 이용해 pod의 affinity와 antiaffinity를 설정할 수 있는 또 하나의 기준. pod를 스케줄링 할 때 먼저 pod의 label을 기준으로 대상 노드를 찾고, topologyKey를 이용해 해당 노드가 원하는 노드인지 확인.

 

kind: Pod
...
spec:
  replicas: 5
  ...
  affinity:
    podAffinity: #podAntiAffinity를 쓰면 label이 app: backend가 아닌 pod가 있는 node에서 실행
      requiredDuringSchedulingIgnoredDuringExecution: # preferred를 쓰면 weight 쓸 수 있다.
      - labelSelector:
          matchLabels:
            app: backend
        topologyKey: kubernetes.io/hostname
# replicas 5개 전부 label이 app: backend인 pod가 있는 node에서 실행.

 

• node들마다 taint를 설정할 수 있다.
• master에 pod들이 할당이 안되는 이유 -> kubectl describe nodes master.example.com | grep -i taint 정보를 보면 node-role.kubernetes.io/master:NoSchedule로 되어있기 때문.
• worker node에 taint가 설정된 경우 동일 값의 toleration이 있는 pod만 배치 가능.
• toleration이 있는 pod는 동일한 taint가 있는 node를 포함하여 모든 node에 배치된다.

 

effect 필드 종류
- NoSchedule: toleration이 맞지 않으면 배치되지 않는다.
- PreferNoSchedule: toleration이 맞지 않으면 배치되지 않으나, 클러스터 리소스가 부족하면 할당.
- NoExecute: toleration이 맞으면 동작중인 pod를 종료.

 

• kubectl taint nodes [node name] [taint ex) role=web:NoSchedule]
• kubectl taint nodes [node name] role- -> role key를 가지는 taint 제거

 

...
spec:
  containers:
  ...
  tolerations:
  - key: "role"
    operator: "Equal"
    value: "web"
    effect: "NoSchedule"
# role=Equal:NoSchedule이라는 taint가지고 있는 node에도 할당.
# taint가 없는 곳에도 배치된다.

 

•  
•  
• node가 down됬을 때 pod는 5분뒤 terminate되고 rs, deployment라면 다른 node에 생성. kube-controller-manager --pod-eviction-timeout=5m0s
• kubectl drain [node name] [options] -> --ignore-daemonsets - DaemongSet-managed pod들은 ignore, --force - RC, RS, Job, DaemongSet 또는 StatefuleSet에서 관리하지 않는 pod까지 제거
• drain이랑 cordon이랑 다른 점은 cordon은 pod를 terminate하거나 move하지않고 새로운 pod들에 대해서 unscheduling하는 것.
• multi schedule 가능. 보통 default scheduler로 kube-schedule이 생성되는데 pod를 생성하여 kube-system에 custom scheduler를 설정할 수 있다.

apiVersion: v1
kind: Pod
metadata:
  name: kube-scheduler
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-scheduler
    - --address=127.0.0.1
    - --kubeconfig=/etc/kubernetes/scheduler.conf
    - --leader-elect=true
    - --scheduler-name=my-custom-scheduler
    - --lock-object-name=my-custom-scheduler
    image: k8s.gcr.io/kube-scheduler-amd64:v1.11.3
    name: kube-scheduler

• 아래와 같이 custom scheduler를 지정할 수 있다.

...
spec:
  containers:
  - name: ...
    ...
  schedulerName:

• kubectl get events를 통해 어떤 scheduler를 사용했는지 알 수 있다.
• kubectl logs [scheduler name] --name-space=[name space] 를 통해 log 확인
• multiple scheduler를 사용할 경우, 만약 multiple master 사용 환경이 아닌 경우 learder elect option을 false로 주고, multiple master 사용 환경일 경우, --lock-object-name=[scheduler name]을 줘서 default scheduler랑 구별짓는다.