스케쥴링

 

 

https://kubernetes.io/ko/docs/concepts/scheduling-eviction/assign-pod-node/

노드에 파드 할당하기

 

 

특정한 노드(들) 집합에서만 동작하거나 특정한 노드 집합에서 동작하는 것을 선호하도록 파드를 제한할 수 있다.

스케쥴러가 결정하던 노드/파드 배치를 관리자가 수동으로 조절

예를 들어 SSD가 장착된 머신에 파드가 배포되도록 하거나 또는 많은 통신을 하는 두 개의 서로 다른 서비스의 파드를 동일한 가용성 영역(availability zone)에 배치하는 경우와 같이, 파드가 어느 노드에 배포될지를 제어해야 하는 경우도 있다

 

 

 

노드셀렉터(nodeSelector)

nodeSelector는 노드 선택 제약사항의 가장 간단하면서도 추천하는 형태이다. 파드 스펙에 nodeSelector 필드를 추가하고, 타겟으로 삼고 싶은 노드가 갖고 있는 노드 레이블을 명시한다. 쿠버네티스는 사용자가 명시한 레이블을 갖고 있는 노드에만 파드를 스케줄링한다.

 

 

어피니티(affinity)와 안티-어피니티(anti-affinity)

nodeSelector 는 파드를 특정 레이블이 있는 노드로 제한하는 가장 간단한 방법이다. 어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다

•  nodeSelector로는 명시한 레이블이 있는 노드만 선택할 수 있다. 어피니티/안티-어피니티는 선택 로직에 대한 좀 더 많은 제어권을 제공한다.
• 규칙이 "소프트(soft)" 또는 "선호사항(preference)" 임을 나타낼 수 있으며, 이 덕분에 스케줄러는 매치되는 노드를 찾지 못한 경우에도 파드를 스케줄링할 수 있다.
• 다른 노드 (또는 다른 토폴로지 도메인)에서 실행 중인 다른 파드의 레이블을 사용하여 파드를 제한할 수 있으며, 이를 통해 어떤 파드들이 노드에 함께 위치할 수 있는지에 대한 규칙을 정의할 수 있다.

 

 

노드 어피니티

노드의 레이블을 기반으로 파드가 스케줄링될 수 있는 노드를 제한할 수 있다.

 

• requiredDuringSchedulingIgnoredDuringExecution: 규칙이 만족되지 않으면 스케줄러가 파드를 스케줄링할 수 없다. 이 기능은 nodeSelector와 유사하지만, 좀 더 표현적인 문법을 제공한다.
• preferredDuringSchedulingIgnoredDuringExecution: 스케줄러는 조건을 만족하는 노드를 찾으려고 노력한다. 해당되는 노드가 없더라도, 스케줄러는 여전히 파드를 스케줄링한다.

 

(IgnoredDuringExecution는 쿠버네티스가 파드를 스케줄링한 뒤에 노드 레이블이 변경되어도 파드는 계속 해당 노드에서 실행됨을 의미한다)

 

 

예를 들어 아래와 같은 파드를 생산하는 yaml을 분석해보자.

파드쪽에서 자신이 할당될 노드에 대해 어피니티로 조건을 걸고 있다.

apiVersion: v1
kind: Pod
metadata:
  name: with-node-affinity
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: topology.kubernetes.io/zone
            operator: In
            values:
            - antarctica-east1
            - antarctica-west1
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: another-node-label-key
            operator: In
            values:
            - another-node-label-value
  containers:
  - name: with-node-affinity
    image: registry.k8s.io/pause:2.0

• 노드는 키가 topology.kubernetes.io/zone인 레이블을 갖고 있어야 하며, 레이블의 값이 antarctica-east1 혹은 antarctica-west1여야 한다.
• 키가 another-node-label-key이고 값이 another-node-label-value인 레이블을 갖고 있는 노드를 선호한다 .

operator 필드를 사용하여 쿠버네티스가 규칙을 해석할 때 사용할 논리 연산자를 지정할 수 있다. In, NotIn, Exists, DoesNotExist, Gt 및 Lt 연산자를 사용할 수 있다.

 

 

 

 

 

테인트(Taints)와 톨러레이션(Tolerations)

 '파드가 스케줄링될 수 있는 노드를 제한'하는 어피니티와는 반대로,

테인트는 '노드가 파드 셋을 제외'시킬 수 있다.

 

테인트와 톨러레이션은 함께 작동하여 파드가 부적절한 노드에 스케줄되지 않게 한다.

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

하지만 톨러레이션은 스케줄을 허용하지만 보장하지는 않는다.

스케줄러는 그 기능의 일부로서 다른 매개변수를 고려한다.

 

하나 이상의 테인트가 노드에 적용되는데, 노드가 테인트를 용인하지 않는 파드를 수용해서는 안 된다는 뜻이다.

 

 

노드에 테인트 추가

예를 들어 kubectl taint를 사용하여 노드에 테인트을 추가한다.

kubectl taint nodes node1 key1=value1:NoSchedule

node1 노드에 테인트을 배치한다. 테인트에는 키 key1, 값 value1 및 테인트 이펙트(effect) NoSchedule 이 있다.

이는 일치하는 톨러레이션이 없으면 파드를 node1 에 스케줄할 수 없음을 의미한다.

 

테인트의 제거는 위 명령어 맨뒤에 - 를 붙이면 된다.

 

 

파드에 톨러레이션 추가

PodSpec에서 파드에 대한 톨러레이션를 지정한다

다음의 톨러레이션들은 위의 테인트와 "일치"하므로 둘다 node1 에 스케줄 될 수 있다.

톨러레이션은, 키와 이펙트가 동일한 경우에 테인트와 "일치"한다. 그리고 다음의 경우에도 마찬가지다.

• operator 가 Exists 인 경우(이 경우 value 를 지정하지 않아야 함), 또는
• operator 는 Equal 이고 value 는 value 로 같다.

(지정하지 않으면 operator 의 기본값은 Equal 이다.)

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoSchedule"

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "key1"
    operator: "Exists"
    effect: "NoSchedule"

 

effect 종류

• NoSchedule 이펙트가 있는 무시되지 않은 테인트가 하나 이상 있으면 쿠버네티스는 해당 노드에 파드를 스케줄하지 않는다.
• NoSchedule 이펙트가 있는 무시되지 않은 테인트가 없지만 PreferNoSchedule 이펙트가 있는 무시되지 않은 테인트가 하나 이상 있으면 쿠버네티스는 파드를 노드에 스케쥴하지 않으려고 시도 한다
• NoExecute 이펙트가 있는 무시되지 않은 테인트가 하나 이상 있으면 파드가 노드에서 축출되고(노드에서 이미 실행 중인 경우), 노드에서 스케줄되지 않는다(아직 실행되지 않은 경우).

 

 

 

 

노드에 레이블 명시하는 법

 

node에도 labels가 있다.

 

labels를 각 노드에 추가해보자.

 

다음과같이 추가가 완료되었다.

참고로 잘못 추가한 레이블(prefferedkey2=worknodeprekey3)은 다음과 같이 제거해주면 된다.

prefferedkey2-

 

 

 

 

 

다음과 같은 yaml 파일 3개를 /required 디렉토리에 작성한 후 실행해보자.

cat << EOF > pod-required-affinity-1.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-1
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: requiredkey
            operator: In
            values:
            - worknodereqkey
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
EOF

 

cat << EOF > pod-required-affinity-2.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-2
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: requiredkey
            operator: In
            values:
            - worknodereqkey
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
EOF

cat << EOF > pod-required-affinity-3.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-3
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: requiredkey
            operator: In
            values:
            - worknodereqkey
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
EOF

cd /required

 k create -f ./

 

다음과 같이 모두 node1에 만들어졌다.

 

cat <<EOF > pod-preferred-affinity.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 2
        preference:
          matchExpressions:
          - key:  preferredkey2
            operator: In
            values:
            - worknodeprekey2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 3
        preference:
          matchExpressions:
          - key:  preferredkey3
            operator: In
            values:
            - worknodeprekey3
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
EOF

 

cd /preffered

 k create -f ./

 

weight 2 인 노드2의 키의 우선순위가 더 높아서 다음과 같이 노드2에 생성됐다.

k get pods -o wide

 

만약 위의 yaml파일의 웨이트를 위쪽을 더 높게 주면 어떻게될까?

아래와 같이 수정해서 적용해보자.

 

설정한 웨이트와는 상관 없는 노드에 배치된다. 처음 부분부터 만족하는 결과가 정해져있지 않아서

스케쥴러가 스스로 알아서 배치한것이다.

 

 

 

cat <<EOF > pod-nginx-with-label-security.yaml
 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    security: S1
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
EOF