Kubernetes - 파드 스케쥴 (자동배치, 수동배치)

파드 스케쥴 (자동배치)

# vi pod-schedule.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-schedule-metadata
  labels:
    app: pod-schedule-labels
spec:
  containers:
  - name: pod-schedule-containers
    image: 34.22.96.240:5000/nginx:latest
    ports:
    - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: pod-schedule-service
spec:
  type: NodePort
  selector:
    app: pod-schedule-labels
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    
# k apply -f pod-schedule.yaml

 

-> worker2에 파드가 배치된 것을 확인할 수 있음

 

 

파드 노드네임 (수동배치)

내가 원하는 노드에 배치해보도록 수동배치를 해보는 것!

# vi pod-nodename.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-nodename-metadata
  labels:
    app: pod-nodename-labels
spec:
  containers:
  - name: pod-nodename-containers
    image: 34.22.96.240:5000/nginx:latest
    ports:
    - containerPort: 80
  nodeName: worker3
---
apiVersion: v1
kind: Service
metadata:
  name: pod-nodename-service
spec:
  type: NodePort
  selector:
    app: pod-nodename-labels
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    
# k apply -f pod-nodename.yaml

내가 노드네임을 지정한것과 동일하게 worker3에 배치가 되었다.

 

 

노드 셀렉터 (수동배치)

tier는 라벨이라는 의미이다.

노드에게 라벨을 다는 것!

# kubectl label nodes worker3 tier=dev
# kubectl get nodes --show-labels
# vi pod-nodeselector.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-nodeselector-metadata
  labels:
    app: pod-nodeselector-labels
spec:
  containers:
  - name: pod-nodeselector-containers
    image: 34.22.96.240:5000/nginx:latest
    ports:
    - containerPort: 80
  nodeSelector:
    tier: dev
---
apiVersion: v1
kind: Service
metadata:
  name: pod-nodeselector-service
spec:
  type: NodePort
  selector:
    app: pod-nodeselector-labels
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

# kubectl apply -f pod-nodeselector.yaml

 

이미 만들어진 노드와 동일하게 worker2에 만들어 보았음.

 

노드들이 달고있는 라벨을 볼 수 있음

방금 수동으로 단 tier-dev의 라벨도 확인 가능!

 

kubectl get po -o wide

해당 파드가 worker3 노드에 생성된 것을 확인할 수 있다.

 

 

라벨 제거하기

kubectl label nodes worker3 tier-
kubectl get nodes --show-labels

뒤에 [-]를 달면 제거하겠다는 의미임.

 

뒤에 달려있던 라벨 tier=dev가 사라짐!

 

 

taint와 toleration

taint : 더러움

tolation : 허용, 용인

https://kubernetes.io/ko/docs/concepts/scheduling-eviction/taint-and-toleration/

 

노드 어피니티(nodeSelector)는 노드 셋을 (기본 설정 또는 어려운 요구 사항으로) 끌어들이는 파드의 속성이다. 

테인트 는 그 반대로, 노드가 파드 셋을 제외시킬 수 있다.

 

톨러레이션 은 파드에 적용된다. 톨러레이션을 통해 스케줄러는 그와 일치하는 테인트가 있는 파드를 스케줄할 수 있다. 

톨러레이션은 스케줄을 허용하지만 보장하지는 않는다. 스케줄러는 그 기능의 일부로서 다른 매개변수를 고려한다.

테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지 않게 한다. 하나 이상의 테인트가 노드에 적용되는데, 이것은 노드가 테인트를 용인하지 않는 파드를 수용해서는 안 된다는 것을 나타낸다.

 

 

k label nodes worker3 tier=dev

일단, 라벨을 다시한번 주자. 

라벨은 노드 뿐 아니라 파드에도 줄 수가 있음!

 

kubectl taint node worker3 tier=dev:NoSchedule
kubectl describe nodes worker3

테인트를 통해서 worker3를 오염시켜보는 거다.

 

만들어진 거 확인 가능!

 

 

수동으로 파드 만들어서 확인해보기

kubectl run new-nginx1 --image=34.22.96.240:5000/nginx:latest

 

확인해보면 3개의 파드를 수동으로 만들었어도 테인트된 worker3에는 배치가 되지 않는다.

 

 

하지만,

특별한 경우에는 taint 되었어도 toleration될 수 있도록 해보기

# vi pod-taint.yaml
apiVersion: v1
kind: Pod
metadata:
  name: pod-taint-metadata
  labels:
    app: pod-taint-labels
spec:
  containers:
  - name: pod-taint-containers
    image: 34.22.96.240:5000/nginx:latest
    ports:
    - containerPort: 80
  tolerations:
  - key: "tier"
    operator: "Equal"
    value: "dev"
    effect: "NoSchedule"
---
apiVersion: v1
kind: Service
metadata:
  name: pod-taint-service
spec:
  type: NodePort
  selector:
    app: pod-taint-labels
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

# kubectl apply -f pod-taint.yaml
# kubectl get pod -o wide

 

자동으로 스케쥴한다는 것은 자동으로 노드상태를 보고 스케쥴을 하는 것임

 

 

흠.. 어쨋든 자동 스케쥴링이 되는 것인지..

토네이션 후, pod를 3개 생성해보았더니 골고루 노드에 분배가 되긴 했다.

어쨋든! taint 등록을 햇어도 토네이션하면 배분이 가능해진다는 의미일까?! 공부가 더 필요할 듯 ㅠㅠ

 

테인트가 되어있는 노드네임에다가 수동으로 넣어보기!

vi pod-nodename.yaml
k apply -f pod-nodename.yaml

수동으로 찍고 들어갔더니 바로 테인트를 뚫고 생겨버림 ㄷㄷ

테인트 시키면 노스케쥴링

자동배치는 X

테인트를 건 시점부터 적용됨

 

kubectl taint node worker1 tier=dev:NoSchedule-

 

 

Cordon와 Drain

커든(Cordon; 비상경계선)
노드에 추가로 파드를 스케줄링하지 않도록 함

드레인(Drain; 물을 빼다)
노드 관리를 위해 파드를 다른 노드로 이동

https://velog.io/@_zero_/%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4-%EC%BB%A4%EB%93%A0Cordon-%EB%B0%8F-%EB%93%9C%EB%A0%88%EC%9D%B8Drain-%EA%B0%9C%EB%85%90%EA%B3%BC-%EC%84%A4%EC%A0%95

쿠버네티스 커든(Cordon) 및 드레인(Drain) 개념과 설정

 

커든 명령은 지정된 노드에 추가로 파드를 스케쥴하지 않는다.

 

k cordon worker3

현재 나의 경우, worker3에 파드가 많이 지정되어 있어서 worker3에 cordon을 달아주었다.

SchedulingDisabled?!

그렇다면 이제 disabled되어 더이상 새로운 파드가 만들어지지 않는다는거임

 

vi pod-nodename.yaml
k apply -f pod-nodename.yaml
k get po -o wide

 

잉?? 그런데 만들어짐...

노드네임을 지정하면 테인트하든 커든을 하든 무조건 생성이된다.

 

 

하지만 자동배치를 하면 생성되지 않을 것임...

해보쟈...

kubectl run new-nginx4 --image=34.22.96.240:5000/nginx:latest
kubectl run new-nginx5 --image=34.22.96.240:5000/nginx:latest
kubectl run new-nginx6 --image=34.22.96.240:5000/nginx:latest
kubectl run new-nginx7 --image=34.22.96.240:5000/nginx:latest

확인해보면. 이미 배치되어 있는 것은 그대로 두고, 자동배치로 신청한 것은 배치가 되지 않았다.

 

 

커든 삭제하기 = uncordon

kubectl uncordon worker3
k get no

k delete pod --all

커든되었던 내용이 삭제된 것을 확인할 수 있음

---

워커노드3개 중 2개씩 총 6개의 워커노드를 분산시킨 후,

 

k describe node worker3 | grep Taint
k taint node worker3 tier=dev:NoSchedule-
k describe node worker3 | grep Taint

테인트된 내용 확인 후, 테인트된 것 제거해주기

 

# vi deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-site-deployment
spec:
  replicas: 6
  selector:
    matchLabels:
      app: web-site-deployment
  template:
    metadata:
      name: web-site-deployment
      labels:
        app: web-site-deployment
    spec:
      containers:
      - name: web-site-deployment-container
        image: 34.22.96.240:5000/nginx:latest

# k apply -f deployment.yaml

각 2개씩 노드가 잘 배치된 것을 확인할 수 있다.

 

worker3를 드레인 해보자.

 

 

daemonset?

워커3를 드레인한다는 건 워커3안에 있는 모든 파드를 지운다는 것임

데몬셋이라고 하는 애가 관리하는 파드가 있음.

데몬이 뭐냐면 httpd, naemd, ftp 등 백그라운드 실행하는 것임.

쿠버네티스도 데몬이라는 것이 존재함. 데몬은 어떤 서버와 주요 기능들을 하는데 우리가 다루는 kube-proxy라고 했던 것

pod network를 꾸며주는 flannel같은

 

서버의 데몬이라는 의미가 맞는데 지워져서는 안되는 것들. 항시 존재하는 것들.

실수로라도 지운다면 kube-system에 있는 파드임.

 

 kubectl drain worker3 --ignore-daemonsets --force --delete-local-data

 

확인해보면 worker3는 드레인되어 사라졌음.

새롭게 만들어진 파드를 확인해보면 worker3에 있던 파드들이 새롭게 배정되어 생성된 것이다.

 

 

혹시몰라서 한번 더 확인하기 위해

노드네임을 지정해서 다시 해봄..

드레인으로 지정되었다고 하더라도 노드네임을 지정하면 파드가 배정이 됨!

 

노드네임 지정이야 말로 타노스 그잡채~

k uncordon worker3
k get no