49. Scheduling Section Introduction
Scheduling 과 관련되 여러 옵션들을 배워보자!
50. Download Presentation Deck for this section
51. Manual Scehduling
Scheduling 이 백엔드단에서 어떻게 작동할까
pod 엔 nodeName 이라는 속성이 있다. default는 설정 안되어있다.
nodeName을 명시 안하면 쿠버네티스가 자동으로 nodeName 특성을 추가한다.
스케줄러가 pod들을 탐색하면서 nodeName 속성이 없는 것을 탐색한다.
nodeName이 없는 것들은 scheduling 대상이다.
Once identified it schedules the POD on the Node by setting the node Name property to the name of the node by creating a binding object.
scheduler가 nodeName 이 설정 안된 pod를 보면 nodeName을 지어주고 객체를 생성하고 바인딩한다.
만약 scheduler가 없다면 무슨 일이 벌어질까?
pod는 pending status 에 머무르게 된다.
You can manually assign pods to node yourself. Well without a scheduler, the easiest way to schedule a pod is to simply set the node name field to the name of the node in your pod specification while creating the POD.
수동으로 pod를 할당하는 가장 쉬운 방법은 nodeName을 직접 기입하는 것이다.
pod가 running status 가 되었다.
pod를 생성할때 nodeName을 지정할 수 있다.
만약 pod가 미리 생성되어있고 pod를 node에 할당할려고 한다면?
Kubernetes won’t allow you to modify the node Name property of a pod.
쿠버네티스에서는 pod 의 nodeName을 수정하게 두지 않는다.
So another way to assign a note to an existing pod is to create a binding object and send a post request to the pod binding API thus mimicking what the actual scheduler does.
pod 와 node를 연결해주는 객체인 binding을 하나 생성하고 연결을 요청한다.
scheduler 가 하는 일을 모방한 것.
바인딩에는 nodeName이 들어간다.
. Then send a post request to the pods binding API with the data set to the binding object in a JSON format.
위와 같이 요청을 보내면 pod가 바인딩 된다. 이때 json 포맷
So you must convert the YAML file into its equivalent JSON format.
JSON 포멧으로 변경된다는 점을 유의하자!52. Practice Test - Manual Scheduling
1.
A pod definition file nginx.yaml is given. Create a pod using the file.
Only create the POD for now. We will inspect its status next.
2.
What is the status of the created POD?
3.
Why is the POD in a pending state?
Inspect the environment for various kubernetes control plane components.
kubectl get pods -n kube-system 에서 scheduler가 없는 것을 확인
4.
Manually schedule the pod on node01.
Delete and recreate the POD if necessary.
yaml 파일 변경하고 pod 삭제하고 apply 하기
아니면 replace --force 로 변경 가능하다.
5.
Now schedule the same pod on the controlplane node.
Delete and recreate the POD if necessary.
53. Solution - Manual Scheduling
54. Labels and Selectors
분류할때 labels 을 사용하는 것이 좋다.
selectors 는 필터 역할
We have created a lot of different types of Objects in Kuberentes. Pods, Services, ReplicaSets and Deployments.
etc. For Kubernetes, all of these are different objects.
metadata 의 label 에서 여러 가지 label을 지정할 수 있다. (yaml 파일에서 )
이 label은 나중에 분류할때 요긴하게 쓰인다.
selector 옵션 사용하기
kubectl get pods --selector app=App1
annotation 가능
55. Practice Test - Labels and Selectors
1.
We have deployed a number of PODs. They are labelled with tier, env and bu. How many PODs exist in the dev environment (env)?
Use selectors to filter the output
7개
2.
How many PODs are in the finance business unit (bu)?
3.
How many objects are in the prod environment including PODs, ReplicaSets and any other objects?
kubectl get all --selector 조건 이렇게 할 수 있음
4.
Identify the POD which is part of the prod environment, the finance BU and of frontend tier?
쉼표를 붙여써야한다.
5.
A ReplicaSet definition file is given replicaset-definition-1.yaml. Try to create the replicaset. There is an issue with the file. Try to fix it.
tier 를 맞춰준다.
57. Taints and Tolerations
pod와 node 의 관계를 생각하자
벌레가 사람 몸에 착지한다고 가정하자
사람한테는 모기 방지 스프레이를 뿌렸다.
스프레이에 민감한 벌레는 사람에게서 벗어나겠지만 면역인 벌레는 사람 몸에 착지할 거다.
So there are two things that decide if a bug can land on a person.
First the taint on the person.
And second the bugs toleration level to that particular taint
모기를 막는 요소는 두가지
첫째 사람의 모기 스프레이 강도
둘째 모기의 면역 정도
노드가 사람이고 컨테이너가 벌레
taints 와 toleration은 어떤 pod가 스케쥴 될수 있는지 정한다.
pod 가 생성되면 scheduler는 pod를 worker node 에 배정하려고 한다.
만약 node1을 특별한 이유에서 pod를 안올리고 싶다면 ?
node 에 taint 작업을 하면 pod가 올려지는 것을 막는다.
만약 D pod를 올리고 싶게 한다면 toleration 을 설정한다.
그러면 node1 은 d pod 만 쓸 수 있다.
It goes through so remember trains are set on nodes and toleration are set on pods.
Taints 사용법
node 이름을 명시한다.
key value 가 뒤에 따라온다.
taint-effect는 세개가 있다.
NoSchedule : toleration 가 없으면 pod 스케쥴 x , 기존 실행되던 pod에는 적용 안됨
PreferNoSchedule: toleration이 없으면 pod을 스케줄링안하려고 하지만 확실하지 않음 클러스터내에 자원이 부족하거나 하면 taint가 걸려있는 노드에서도 pod이 스케줄링될 수 있음
NoExecute : toleration 이 없으면 pod 스케쥴 x, 기존에 실행되는 pod도 toleration 없으면 종료
tolerations 은 pod 에서 정의 가능함. 쌍따옴표로 해야함.
NoExecute
잘돌아가던 node1 에 갑자기 taints 를 걸고 pod d 에 tolerations을 건다면?
NoExecute taints는 현재 진행중인 pod를 대상으로 하기 때문에 tolerations이 없는 c pod를 방출시키고 d pod는 유지 시킨다.
하지만 명심해야할 것이 pod d 에 toleration이 있다고해서 무조건 node 1 에만 배정되는 것이 아니다!
taints, toleration은 경계 조건처럼 사용해야한다!
master node 도 사실 똑같은 node 이다. 하지만 여러 막강한 기능을 더 첨가한...
최초 master node 는 그 어떤 pod도 배정되지 않게 taints 가 되어있다.
master node는 쓰지 않는 것이 좋다.
master node 를 보면 위와 같이 taints 가 되어있다.
58. Practice Test - Taints and Tolerations
1.
How many nodes exist on the system?
Including the controlplane node.
2.
Do any taints exist on node01 node?
3.
Create a taint on node01 with key of spray, value of mortein and effect of NoSchedule
4.
Create a new pod with the nginx image and pod name as mosquito.
5.
What is the state of the POD?
6.
Why do you think the pod is in a pending state?
node가 taint 를 가지고 있음.
7.
Create another pod named bee with the nginx image, which has a toleration set to the taint mortein.
8.
Notice the bee pod was scheduled on node node01 despite the taint.
bee pod는 tolerations 이 있기 때문에 node01 taints 에도 불구하고 배치 받은 것
9.
Do you see any taints on controlplane node?
10.
Remove the taint on controlplane, which currently has the taint effect of NoSchedule.
11.
What is the state of the pod mosquito now?
12.
Which node is the POD mosquito on now?
controlplane의 taints를 없앴기때문에 mosquito pod가 controlplane에 배정됨