Manual Scheduling

• 스케줄러가 없으면? 직접 해야지.
• nodeName이라는 필드가 pod 생성 시 자동으로 생긴다. 스케줄러는 nodeName이 기입되지 않은 pod들을 탐지해서, 얘네를 필요한 Node에 배정해준다.
• 스케줄러가 없으면? 직접 nodeName을 기입해주면 된다.
• BUT 사후 수정은 불가하다. 대신 binding obj를 생성해서 post 리퀘를 날리면 된다. 이때 binding ymal 파일을 json으로 바꿔 보내야 한다.

Labels and Selectors

• k8s의 다양한 오브젝트들의 그루핑을 위한 것. (pod, rs, deployments …)
• metadata 아래에 key value 방식으로 추가

metadata:
	labels:
		app: App1
		function: Front-end

kubectl get pods —selector app=App1

• replicaset의 경우, 그냥 metadata 내의 labels는 rs 자체. template 내 labels는 pods의 label.
• rs는 pod의 수를 유지해주는게 주요 역할이었다. 이때 pod을 찾게 해주는게 spec 내 selector 내 matchLabels이다.
• matchLabels는 template 내 metadata 내 labels와 동일해야한다.
• annotation: 정보를 위해 디테일을 저장한다. 따로 pod 찾기용은 아닌듯.

Taints and Tolerations

• taints, toleration는 노드에 어떤 pod가 스케줄링 될 지를 restrict하기 위해 사용된다.
• pod의 접근을 원치 않는 node에 taint를 뿌린다. tainted node는 by default 접근 불가하지만, toleration 처리한 pod는 접근 가능하다.
• taints are applied on nodes, toleration are applied on pods
• 주의! 이는 특정 Node에 특정 Pod만 오게 '허용'하는것이지, 특정 pod를 특정 Node에 띄우는 것이 아니다. 실제로 toleration이 적용된 pod가 taint가 적용된 node로 갈지는 전혀 guarantee가 되지 않는다.

taints 적용법

kubectl taints nodes node-name key=value:taint-effect
kubectl taint nodes node1 app=blue:NoSchedule

• NoSchedule(아예 스케줄링에서 제외)
• PreferNoSchedule(스케줄링 제외가 guarantee되지는 않음)
• NoExecute(아예 스케줄링에서 제외 + 기존 node 내 pods까지 stop) -> 이미 pods 돌아가는 상황에서 특정 pod만 쫓아내기 위해 사용한다.

tolerations 적용법

//pod.yaml
spec:
	tolerations:
    - key: "app"
      operator: "Equal"
      value: "blue"
      effect: "NoSchedule" // 꼭 쌍따옴표여야함

• 흥미로운 사실! Master node에 아무런 pod이 스케줄링 되지 않는 이유는 클러스터 생성 순간부터 taint가 적용되어 있기 때문이다!

Node Selectors

• 어떤 pod는 리소스를 많이 잡아먹고, 따라서 덩치가 큰 노드에 할당되어야 한다. 이를 위해 Node Selector를 사용할 수 있다.

kubectl label nodes <node-name> <label-key>=<label-value>
kubectl label nodes node01 size=Large

//pod.yaml
spec:
	nodeSelector:
    	size: Large // Large는 Node 생성시에 할당한 label이다.

• 물론 다양한 조건을 걸지 못한다는 한계가 있다. ex. 'Large만 제외하고' 같은 조건 불가능.
• 이를 위해서는 Node Affinity를 사용해야 한다.

Node Affinity

• 목적은 Node Selector와 동일하다. 특정 pod가 특정 node에서 호스팅될 수 있도록 하는 것.

spec:
	affinity:
    	nodeAffinity:
        	requiredDuringSchedulingIgnoredDuringExecution:
            	nodeSelectorTerms:
                - matchExpressions:
                	- key: size
                      operator: In // 아래 value (리스트) 내 아무거나. // NotIn, Exists등도 찾아보기
                      values:
                      - Large
                      - Medium

• node affinity types
  • requiredDuringSchedulingIgnoredDuringExecution
  • preferredDuringSchedulingIgnoredDuringExecution
  • requiredDuringSchedulingRequiredDuringExecution (PLANNED)
• During Scheduling: pod가 막 생성될때. pod의 placement가 매우 중요하면 required, '되도록'이면 preferred.
• During Execution: 실행중인 pod에 대해서. 현재로서는 node affinity를 조정하더라도 이미 호스팅된 pod는 영향받지 않고 돌아간다.

Node Affinity vs Taints & Tolerations

• 우리가 원하는 pod만 우리 노드에 넣고싶다!
  • taints & tol만 사용하면, 다른 팀의 pod는 우리꺼에 안들어오겠지만, 반대로 우리 pod가 다른 팀의 node에 들어갈 수 있다.
  • node aff.만 사용하면, 우리 팀의 pod를 우리 node에만 잘 넣을 수 있지만(다른 팀 node에 안들어가게), 다른 팀의 pod가 우리 node에 들어올 수 있다.
• 결론: 함께 쓰자. T&T로 다른 pod가 우리 node에 접근하지 못하게 막고, node aff.로 우리 팀의 pod가 다른 팀의 node에 올라가지 않게 할 수 있다.