Kubernetes - (4) Scheduling

1. Scheduling

• POD 생성 시, 쿠버네티스는 내부적으로 nodeName 생성
• 만일 해당 POD에 nodeName이 없다면 pending 상태 지속

scheduler 유무 체크

kubectl get pods --namespace kube-system

// 스케쥴러 상세 정보
kubectl describe pod kube-scheduler-controlplane --namespace=kube-system

nodeName 수동 할당

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  nodeName: node01
  containers:
  -  image: nginx
     name: nginx

2. Labels & Selector

• 쿠버네티스의 POD / Service / Deployment 등에 라벨을 설정하면 Selector를 통해 필터 가능

Label 생성

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: App1
    function: Front-end
spec:
  containers:
  -  image: nginx
     name: nginx

Selector 조회

kubectl get pods --selector app=App1
kubectl get pods --selector app=App1 --no-headers | wc -l // 갯수확인 가능
kubectl get all --selector app=App1 // 모든 환경의 리소스 조회
kubectl get all --selector env=prod,bu=finance,tier=frontend // multi label 조회
kubectl get pods --show-labels // pod의 label까지 출력

ReplicaSet / service 생성 시 Label 적용

ReplicaSet.yaml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: nginx
  labels:
    app: App1
    function: Front-end
spec:
  replicas: 3
  selector:
    matchLabels: // *Label 적용
      app: App1
  template:
    metadata: // *Label 적용
      labels:
        app: App1
        function: Front-end
      annotations: // 어노테이션 적용하여 record 생성 가능
        buildversion: 1.34
  containers:
  -  image: nginx
     name: nginx

Service.yaml

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

3. Taints and Tolerations

• 일반적으로 mutli node가 있을 시 스케쥴러는 균등하게 POD을 배분
• taints는 Node에 설정, tolerations은 POD에 설정하여 특정 Node에 특정 POD만 배정되도록 할 수 있다.
• 그러나 균등하게 배분되는 과정에서 toleration이 있는 POD이 일치하는 taint Node에 할당되지 않을 수 있다.

1) Taints

kubectl taint nodes Node명 key=value:taint-effect
ex) kubectl taint nodes node1 app=blue:NoSchedule

// node에 taints 있는지 체크
kubectl describe node node명 | grep -i taints

// taints 제거
kubectl taint nodes NODE명 node-role.kubernetes.io/master:NoSchedule-

taint-effect

• NoSchedule : Toleration이 없는 POD을 해당 Node에 배치하지 않는다.
• PreferNoSchedule : Toleration이 없는 POD을 해당 Node에 배치하지 않지만 이를 보장하지 않는다.
• NoExcute : 새로운 POD은 해당 Node에 배치가 안되며, 기존 POD 중 Toleration이 있는 POD만 가능

2) Tolerations

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

4. Node Selectors & Node Affinity

1) Node Selectors

• 해당 POD을 Node Selectors 통해 특정 Node에 할당

kubectl label nodes Node명 key=value
ex) kubectl label nodes node1 size=Large

// 라벨 확인
kubectl describe node node명

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  -  image: nginx
     name: nginx
     
  nodeSelector:
    size: Large

2) Node Affinity

• Node에 라벨 지정하여 Not / or / Exists 등 여러 옵션에 따라 POD을 특정 Node에 할당
• 특정 POD이 특정 Node에 할당되는것을 보장하지만, 다른 POD이 해당 Node에 할당될 수 있음

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  -  image: nginx
     name: nginx
     
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
          - matchExpressions:
            - key: color
              operator: In
              values:
              - blue

		// Exists 옵션 해당 NODE에 POD 할당
		nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: node-role.kubernetes.io/master
                operator: Exists

// 생성한 deployment의 yaml 파일 생성
kubectl get deployments.apps deployment명 -o yaml > blue.yaml
// deplyment yaml 파일 생성
kubectl create deployment deployment명 --image=nginx --dry-run -o yaml > red.yaml

Node Affinity Types

(1) requiredDuringSchedulingIgnoredDuringExecution

• 해당 라벨이 있는 Node에만 POD이 할당되고 추후 Node의 Label이 변해도 POD은 그대로 Node에 존재
  (2) preferredDuringSchedulingIgnoredDuringExecution
• 해당 라벨에 우선순위로 POD이 할당되지만 없어도 어느곳이든 할당되며, 추후 Node의 Label이 변해도 POD은 그대로 Node에 존재
  (3) requiredDuringSchedulingIgnoredDuringExecution
• 해당 라벨이 있는 Node에만 POD이 할당되고 추후 Node의 Label이 변하면 해당 POD은 축출 or 제거

결론 : Taints & Tolerations 와 Node affinity의 결합을 통해 특정 Node에 특정 POD만 할당되도록 할 수 있다.

5. Reasource Requirements and Limits

• Scheduler에 의해 각 Node에 POD이 할당 될때 해당 NODE에 CPU / Memory / Disk에 적절한 용량이 없을 시 해당 POD은 pending 된다.
• Resource Requests : POD을 실행하기 위한 최소 리소스 요청
• Resource Limits : POD가 사용할 수 있는 최대 리소스 제한

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  -  image: nginx
     name: nginx
     ports:
       - containerPort: 8080
     resources:
       requests:
         memory: "1GI"
         cpu: 1
       limits:
         memory: "2Gi"
         cpu: 2

6. Daemon Sets

• DaemonSets은 POD의 복사본이 항상 클러스트의 모든 노드에 할당되도록 보장 ex) kube-proxy
• Monitoring Solution / Logs Viewer 활용 시 유용하다.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: monitoring-daemon
spec:
  template: // POD 정보 기입
    metadata:
      labels:
        app: monitoring-daemon
    spec:
      containers:
      - name: monitoring-daemon
        image: monitoring-daemon
        
        
ex)
apiVersion: apps/v1
kind: DaemonSet
metadata:
  labels:
    app: elasticsearch
  name: elasticsearch
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: elasticsearch
  template:
    metadata:
      labels:
        app: elasticsearch
    spec:
      containers:
      - image: k8s.gcr.io/fluentd-elasticsearch:1.20
        name: fluentd-elasticsearch

// 조회
kubectl get daemonsets
// 모든 namespaces 내 조회
kubectl get daemonsets --all-namespaces
// namesapces내 상세 조회
kubectl describe daemonset daemonse명 --namespace=네임스페이스명
// deploy yaml 파일 만든 후 Daemonset으로 변경
kubectl create deployment elasticsearch --image=이미지명 -n 네임스페이스명 --dry-run=client -o yaml > fluentd.yaml

7. Static Pods

• static pods은 control plane과 독립적이므로 Control Plane component들을 static pods으로 배포 가능
• static pods은 kubelet에 의해 생성되며, DaemonSets은 kube-api server에 의해 POD 생성, 둘다 kube-scheduler의 영향은 받지 않는다.
• kube-apisever의 지침과 별도로 kubelet은 워커노드 내 지정된 폴더의 파일의 POD.yaml을 읽고 POD을 생성 / 재부팅 / 제거 할 수 있다.

// static pod 조회 시 -controlplane 붙은 pod으로 확인
kubectl get pods --all-namespaces

// static pod path 조회
ps -ef | grep /usr/bin/kubelet
grep -i staticpod /var/lib/kubelet/config.yaml
// 해당 디렉토리에서 사용한 defenition file의 image 조회
grep -i image kube-apiserver.yaml
// 해당 static POD이 다른 Node에 할당된 경우 ssh 접속하여 위 command 적용

• /usr/local/bin/kubelet 내 --pod-manifest-path=/etc/Kubernetes/manifests

// 지정된 folder에 yaml 파일 생성 시, apply command 쓰지 않아도 static-pod 생성
kubectl run --restart=Never --image=이미지명 POD명 --dry-run=client -o yaml --command -- sleep 1000 > /etc/kubernetes/manifests/static-busybox.yaml