03. K8s Scheduling

Manual Scheduling

---

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 8080
  nodeName:

Pod 를 생성하면 위 처럼 nodeName 이 빈 칸인 상태가 K8s memory 에 저장된다. kube-scheduler 는 생성된 Pod 중 scheduling 대상이 될 Pod 들을 nodeName 필드가 빈 칸인 것을 통해 찾아낸다. 이후 scheduling algorithm 으로 Pod 를 배치할 적절한 Node 를 찾아낸 후 Pod 를 배치한 뒤 nodeName 에 Node 의 이름을 추가한다.

apiVersion: v1
kind: Binding
metadata:
  name: nginx
target:
  apiVersion: v1
  kind: Node
  name: node02

curl --header "Content-Type:application/json" --request POST --data '{"apiVersion":"v1", "kind":"Binding", ...}' http://$SERVER/api/v1/namespaces/default/pods/$PODNAME/binding/

만약 kube-scheduler 가 실행 중이지 않다면 Pod 를 생성해도 Pending 상태로 Pod 가 작동하지 않는다. 때문에 수동으로 Pod 를 scheduling 하고 싶은 경우 직접 nodeName 을 지정해준 상태로 Pod 를 생성하거나, Pod 가 이미 생성된 경우 위 처럼 Binding 을 만들고 curl 요청을 통해 동적으로 Pod 를 배치할 수도 있다.

Labels and Selectors

---

 apiVersion: v1
 kind: Pod
 metadata:
   name: simple-webapp
   labels:
     app: App1
     function: Front-end
 spec:
   containers:
   - name: simple-webapp
     image: simple-webapp
     ports:
     - containerPort: 8080

Label 은 여러 K8s Object 중 관련된 Object 들만 찾아내기 위해 사용자가 지정한 일종의 별명과 같다. 위와 같은 Pod 를 생성하였을 경우,

kubectl get pods --selector app=App1

Selector 옵션을 통해 Label 값이 일치하는 Pod 만 찾아낼 수 있다.

 apiVersion: apps/v1
 kind: ReplicaSet
 metadata:
   name: simple-webapp
   labels:
     app: App1
     function: Front-end
 spec:
   replicas: 3
   selector:
     matchLabels:
       app: App1
   template:
     metadata:
       labels:
         app: App1
         function: Front-end
     spec:
       containers:
       - name: simple-webapp
         image: simple-webapp

위와 같은 ReplicaSet 을 생성할 때 metadata.labels 는 해당 ReplicaSet 에 대한 Label 이고, spec.selector.matchLabels 는 ReplicaSet 이 제어할 Pod 을 특정하기 위한 Label 이고, spec.template.metadata.labels 가 ReplicaSet 에 의해 생성될 Pod 의 Label 이다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: App1
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376 

Service 도 마찬가지로 spec.selector 를 통해 연결할 Pod 를 특정할 수 있다.

Annotations

---

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: simple-webapp
  labels:
    app: App1
    function: Front-end
  annotations:
    buildversion: 1.34
spec:
  replicas: 3
  selector:
    matchLabels:
      app: App1
template:
  metadata:
    labels:
      app: App1
      function: Front-end
  spec:
    containers:
    - name: simple-webapp
      image: simple-webapp

Label 은 Selector 를 통해 Object 를 특정하기 위해 쓰이는 반면, Annotation 은 다른 일반적인 정보를 기록하기 위해 쓰인다.

Taints and Tolerations

---

kubectl taint nodes {node-name} {key}={value}:{taint-effect}
# Taint 설정
kubectl taint nodes node1 app=blue:NoSchedule
# Taint 제거
kubectl taint nodes node1 app=blue:NoSchedule-

Taint 는 Pod 가 특정 Node 에 배치되는 것을 방지하기 위해 사용할 수 있는 설정이다. 위와 같은 명령어를 통해 특정 Node 를 Taint 시킬 수 있다. taint-effect 는 총 3가지로 아래와 같다.

• NoSchedule: Tolerant 하지 않은 Pod 는 schedule 되지 않는다. 이미 배치된 Intolerant 한 Pod 는 그대로 실행된다.
• PreferNoSchedule: 웬만하면 schedule 되지 않지만 보장되진 않는다.
• NoExecute: Tolerant 하지 않은 Pod 가 제거된다.

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: nginx-container
    image: nginx
  tolerations:
  - key: "app"
    operator: "Equal"
    value: "blue"
    effect: "NoSchedule"

Pod 에 Tolerantion 을 부여하고 싶은 경우, spec.tolerations 에 Taint 와 같은 설정을 지정해주면 된다. kube-scheduler 는 기본적으로 Taint 와 Toleration 을 고려하며 Pod 를 배치하는데, 만약 Pod definition 에 spec.nodeName 필드가 명시되어 있다면 NoSchedule 이어도 scheduling 을 건너뛰고 Pod 가 배치된다. NoExecute 의 경우라면 Pod 가 배치되더라도 제거될 수 있다.

kubectl describe node kubemaster | grep Taint

Master Node 도 사실은 Taint 되어 있어서 Core Component 외 Object 가 배치되지 않는 것이다.

Node Selectors

---

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: data-processor
    image: data-processor
  nodeSelector:
    size: Large

상대적으로 많은 하드웨어 리소스를 요구하는 컨테이너를 적절한 Node 에서 실행하기 위해서 spec.nodeSelector 설정을 활용할 수 있다. Node Selector 역시 label 을 활용해 대상이 될 Node 를 특정할 수 있다.

kubectl label nodes {node-name} {label-key}={label-value}
kubectl label nodes node-1 size=Large

위와 같은 커맨드로 특정 Node 에 label 을 달아주고 Pod definition file 에서 해당 label 을 가진 Node 를 지정해준 뒤 생성하면 원하는 Node 에 Pod 를 실행할 수 있다.

다만 spec.nodeSelector 설정은 단순히 label 만 확인하기 때문에 더 복잡한 조건으로 Node 를 설정하고 싶을 때 Node Affinity 를 활용할 수 있다.

Node Affinity

---

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: data-processor
    image: data-processor
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: size
            operator: In
            values:
            - Large
            - Medium

위와 같이 Node Affinity 를 사용하면 size In Large, size NotIn Small, size Exists 등 더 복잡한 조건문을 통해 Pod 가 배치될 Node 를 지정할 수 있다. Pod 가 배치될 적절한 Node 를 찾기 위해 requiredDuringSchedulingIgnoredDuringExecution 과 같은 설정값을 줄 수 있는데,

• Available
  • requiredDuringSchedulingIgnoredDuringExecution
  • preferredDuringSchedulingIgnoredDuringExecution
• Planned
  • requiredDuringSchedulingRequiredDuringExecution
  • preferredDuringSchedulingRequiredDuringExecution 현재 2가지가 제공되고 추후 2가지가 더 추가될 예정이다. 해당 설정은 이름 그대로 작동하는데, DuringScheduling 은 Pod 가 Schedule 되는 시점에 Node 에 알맞는 label 이 있는지 확인하는 것이고 DuringExecution 은 Node 가 Pod 를 호스팅하는 중 label 이 변경되었을 시 처리를 지정하는 것이다. 예를 들어, preferredDuringSchedulingIgnoredDuringExecution 은 웬만하면 Node label 이 설정된 곳에 Pod 를 배치하고 싶다는 것이고, 배치된 이후 Node label 이 변경되더라도 그대로 호스팅해달라는 의미다.

Taints and Tolerations vs Node Affinity

---

Taints and Tolerations 기능과 Node Affinity 를 적절히 조합하여 사용하면 원하는 Pod 를 원하는 Node 에 배치시키는 것을 보장할 수 있다. 위 그림처럼 Node 를 Taint 시켜 원하는 Pod 외의 Pod 가 배치되는 것을 막고, Node Affinity 를 통해 Pod 가 특정 Node 에 배치되게끔 설정할 수 있다.

Resource Requirements and Limits

---

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Pod 가 Node 에 배치되면 Node 의 리소스를 사용하게 되는데 위처럼 리소스 사용량을 지정해줄 수 있다. Request 와 Limit 은 말 그대로 Pod 가 필요한 최소 용량의 리소스와 최대로 점유할 수 있는 리소스를 의미한다. CPU 의 경우 Limit 을 절대 초과하지 않지만 메모리의 경우 어느정도 초과분을 사용할 수 있게 한다. 다만 너무 오랜 기간 Limit 을 초과하면 OOM 이 발생하며 Pod 가 제거될 수 있다.

LimitRange

apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default:        # 기본 Limit
      cpu: 500m
    defaultRequest: # 기본 Request
      cpu: 500m
    max:            # 최대 Limit
      cpu: "1"
    min:            # 최소 Request
      cpu: 100m
    type: Container

K8s Cluster 에 배치될 모든 Pod 에 대한 기본값을 설정해주고 싶은 경우 LimitRange Object 를 활용할 수 있다. LimitRange 는 namespace 내에서 적용되며 메모리도 동일하게 적용 가능하다. LimitRange Object 가 생성된 이후 적용되기 때문에 중간에 수정한다 하더라도 기존에 생성되어 있는 Pod 엔 적용되지 않고 새로 생성하는 Pod 에만 적용된다. 범위를 설정해주는 것이기 때문에 requests.cpu: 700m 짜리 Pod 를 생성하려고 하면 범위 외 요청이기에 Pod 생성이 제한된다.

ResourceQuota

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-resource-quota
spec:
  hard:
    requests.cpu: 4
    requests.memory: 4Gi
    limits.cpu: 10
    limits.memory: 10Gi

namespace 마다 리소스 사용량을 제한하고 싶을 경우 ResourceQuota 를 활용하여 namespace 전체에 리소스 요청 및 제한을 설정할 수 있다.

DaemonSets

---

Static Pods

---

Multiple Schedulers

---

Configuring Scheduler Profiles

---

Admission Controllers

---

Validating and Mutating Admission Controllers

---

References

---

• Udemy - Certified Kubernetes Administrator (CKA) with Practice Tests