60. Node Selectors
node selectors 에 대해 배워보자!
node 3개로 구성된 클러스터가 있다.
큰 pod는 큰 node 에서 구동되야 자원이 부족하지 않다.
하지만 pod를 어느 node에 배정할지 초기에 설정을 안하면 아무거나 배정한다.
그 과정에서 비효율이 발생할 수 있다.
To solve this
we can set a limitation on the pods so that they only run on particular nodes.
pod에 제약 조건을 추가함으로써 특정 node 에 분배되게 할 수 있다.
nodeSelector
nodeSelector 옵션을 추가함으로써 node 의 크기 제약조건을 추가할 수 있다.
그런데 nodesize 가 large 는 진짜 large 인가? 기준은 뭔가?
Where did the size large come from and how does Kubernetes know which is the large node. The key value
pair of size and large are in fact labels assigned to the nodes the scheduler uses these labels to match
and identify the right note to place the pods on labels and selectors are a topic we have seen many
times throughout this Kubernetes course
nodeSelector 도 label을 사용하는 것이다.
따라서 먼저 node에 label을 달아야한다.
Label Nodes
taint랑 비슷하다.
node label 을 정한 후 nodeSelector 를 설정하면 pod는 해당 node 에게만 분배된다.
만약 node 의 제약 조건이 복잡해진다면?
nod Affinity 로 처리한다.
61. Node Affinity
Node 의 복잡한 제약 조건을 위해 Node Affinity 개념이 필요하다 .
단순 nodeSelector를 label로만 사용하면 복잡한 조건을 사용할 수 없다.
nodeSelector 대신에 affinity 속성이 하나 생긴다.
requiredDuringSchedulingIgnoredDuringExecution
nodeSelectorTerms
마지막에 key, operator , value
operator in 의 의미는 values에 정의된 리스트에 포함되면 배치가능하다는 것을 의미
여기엔 Large 밖에 없으니 Large만 됨
필요하다면 large 밑에 -medium 추가 이런식
또는 NotIn operator 를 지정해 포함안되는 것만 정의할 수 있음.
Exists operator를 사용하면 label 여부만으로 배정 가능하게 한다.
만약 누가 node의 label을 변경한다면? 어떻게 될까?
Node Affinity Types
위에 세가지 경우가 있다.
Available
기본적으로 pod는 두가지 life cycle 이 있다.
1. DuringScheduling
Is the state where a pod does not exist and is created for the first time.
pod가 생성될때
when a pod is first created the affinity rules specified are considered to place
the pods on the right note.
affinitiy rule는 pod를 적당한 node 에 배정할려고 할 것이다.
하지만 node label이 안되어있다면?
Required
the scheduler will mandate that the pod be placed
on a node with a given affinity.
scheduler는 pod를 affinity 에 따라 배정할려고 함.
만약 없다면 배정되지 않는다.
This type will be used in cases where the placement of the pod is crucial.
If a matching node does not exist the pod will not be scheduled.
따라서 requiredDuringScheduling에서 affinity에 정의된 label이 있으면 배정하고 없으면 배정 안한다.
Preferred
pod의 배정위치가 중요한게 아닌 pod 실행 자체가 중요한 경우
affinity에 정의된 node 가 없어도 그냥 아무 node 에 pod를 배정한다.
2. DuringExecution
during execution is the state
where a pods has been running and a change is made in the environment that affects node affinity such
as a change in the label of a node.
DuringExecution 은 pod이 실행되고 node affinity 가 변하는 등 변화가 있는 상태
만약 실행 중인 node의 label을 삭제한다면? label=large 를 삭제 하는 경우
Igonred
As you can see the two types of node affinity available today has this value set too ignored which means
pods will continue to run and any changes in node affinity will not impact them once they are scheduled.
pods는 계속 실행된다.
Planned
위의 케이스는 node label 이 변경되면 pod를 방출한다.
62. Practice Test- Node Affinity
1.
How many Labels exist on node node01?
2.
What is the value set to the label key beta.kubernetes.io/arch on node01?
3.
Apply a label color=blue to node node01
노드에 레이블 추가하는 법
4.
Create a new deployment named blue with the nginx image and 3 replicas.
5.
Which nodes can the pods for the blue deployment be placed on?
Make sure to check taints on both nodes!
taints 가 설정된게 없기 때문에 두 Node 모두 pods을 배정 받는다.
6.
Set Node Affinity to the deployment to place the pods on node01 only.
7.
Which nodes are the pods placed on now?
8.
Create a new deployment named red with the nginx image and 2 replicas, and ensure it gets placed on the controlplane node only.
Use the label key - node-role.kubernetes.io/control-plane - which is already set on the controlplane node.
해당 key 만 존재하는 걸로 한다.
64. Taints and Tolerations vs Node Affinity
taints 는 node 에 접근 제한
tolerations는 pod가 taints를 뚫고 node 에 배치
node Affinity 는 pod 가 특정 node 에 배치 시키는 것
Taints & Tolerations
pod를 각각 알맞은 node 에 배정되게 하는 것을 가정하자
blue, red,green 에 taints를 뿌리고 pod 에는 tolerations을 한다.
하지만 red pod에 tolerations 가 있음에도 불구하고 other node 에 배치 될 수 있다.
node affinity
node affinity 는 node 에 label 을 매긴다.
pods 에선 node selector 를 기입한다.
문제는 아무것도 정하지 않은 pod가 blue, red, green node에 배정 될 수도 있다는 점이다.
막을 방법이 없다.
그러면 하이브리드로 다른 pod의 배정을 막기위해 blue, red, green 에는 taint를 바른다.
그리고 pods 엔 node affinity로 지정한 node로만 배정 받게 한다.
65. Resource Requirements and Limits
node cluster 가 있다고 치자
각 node cluster는 cpu, memory, disk 로 구성
테트리스랑 비슷함.
pod 가 node 에 맞게 배치되어야함.
pod이 배정되었는데 node의 자원이 부족하다? -> pending state가 된다.
Resource Requests
By default, Kubernetes assumes that a pod or a container within a port requires 0.5 CPU and 256,
maybe byte of memory.
This is known as the resource request for a container.
만약 pod 가 더 많은 자원을 요구한다면?
yaml 파일 spec -> containers 하단에 resources 를 추가한다.
One count of CPU is equal to one VC CPU.
1m 는 백만을 의미
쿠버네티스는 기본적으로 컨테이너 하나에 1 cpu 까지 할당 메모리는 512 바이트까지 할당
limits 를 추가해서 memory, cpu 한계를 정할 수 있다.
만약 메모리가 자원이 부족할 정도로 사용되면
pod는 자동적으로 삭제된다.
66. Note on default resource requirements and limits
In the previous lecture, I said - "When a pod is created the containers are assigned a default CPU request of 0.5 and memory of 256Mi". For the POD to pick up those defaults you must have first set those as default values for request and limit by creating a LimitRange in that namespace.
pod이 생성될때 cpu 기본요구 사항을 0.5 , 메모리 256 mb 라고 했는데 이것도 사실 미리 정의해야함.
apiVersion: v1
kind: LimitRange
metadata:
name: mem-limit-range
spec:
limits:
- default:
memory: 512Mi
defaultRequest:
memory: 256Mi
type: ContainerapiVersion: v1
kind: LimitRange
metadata:
name: cpu-limit-range
spec:
limits:
- default:
cpu: 1
defaultRequest:
cpu: 0.5
type: Container
67. A quick note on editing PODs and Deployments
Edit a POD
Remember, you CANNOT edit specifications of an existing POD other than the below.
아래의 pods spec은 수정 불가능하다.
- spec.containers[*].image
- spec.initContainers[*].image
- spec.activeDeadlineSeconds
- spec.tolerations
For example you cannot edit the environment variables, service accounts, resource limits (all of which we will discuss later) of a running pod. But if you really want to, you have 2 options:
실행중인 pod는 함부로 수정 못하지만 2가지 방법이 있다.
1.
Run the kubectl edit pod <pod name> command. This will open the pod specification in an editor (vi editor). Then edit the required properties. When you try to save it, you will be denied. This is because you are attempting to edit a field on the pod that is not editable.
A copy of the file with your changes is saved in a temporary location as shown above.
수정이 거부된다.
대신 수정 사항은 위의 장소에 임시 보관된다.
You can then delete the existing pod by running the command:
kubectl delete pod webapp기존 pod 을 삭제하고
kubectl create -f /tmp/kubectl-edit-ccvrq.yaml위의 경로에서 create를 한다.
2.
The second option is to extract the pod definition in YAML format to a file using the command
kubectl get pod webapp -o yaml > my-new-pod.yaml기존 pod으로부터 yaml 파일을 얻어낸다. get
vi my-new-pod.yaml수정
kubectl delete pod webapp기존 pod 삭제
kubectl create -f my-new-pod.yaml생성
Edit Deployments
kubectl edit deployment my-deploymentDeployments는 pods 들을 관리한다.
따라서 deployments 에서 수정하면 pod 들을 삭제하고 새로운 pod가 생성된다.
68. Practice Test - Resource Requirements and Limits
1.
A pod called rabbit is deployed. Identify the CPU requirements set on the Pod in the current(default) namespace
2.
Delete the rabbit Pod. Once deleted, wait for the pod to fully terminate.
3.
Another pod called elephant has been deployed in the default namespace. It fails to get to a running state. Inspect this pod and identify the Reason why it is not running.
4.
The status OOMKilled indicates that it is failing because the pod ran out of memory. Identify the memory limit set on the POD.
memory 부족을 의미한다.
5.
The elephant pod runs a process that consume 15Mi of memory. Increase the limit of the elephant pod to 20Mi.
Delete and recreate the pod if required. Do not modify anything other than the required fields.
-
Pod Name: elephant
-
Image Name: polinux/stress
-
Memory Limit: 20Mi
실행 중인 pods를 수정하는 것!
pod 삭제하고 다시 실행
6.
Inspect the status of POD. Make sure it's running
7.
Delete the elephant Pod. Once deleted, wait for the pod to fully terminate.
