[k8s] pod의 node 배치

쿠버네티스는 멀티 노드 분산 환경에서의 컨테이너 관리를 위한 시스템이다.
멀티노드에 컨테이너를 알뜰하게 채우는건 좋은데, 그렇다고 해서 항상 컨테이너가 랜덤 노드에 할당되어서는 목표를 이룰 수 없을 경우가 많을 것이다.

예를 들면, 부하가 많은 서버를 스펙이 넉넉한 특정 서버에 몰아줘야 한다든지, 아니면 특정 IP를 가진 노드에 서버를 띄워야만 의도대로 동작한다든지 하는 현실적인 제한사항들이 있을 수 있는 것이다.

여기에는 2가지 방향성이 있다.
Pod가 직접 특정 노드에 배치되도록 유도하는 긍정적인 접근법이 있고, 노드가 Pod를 거부하는 부정적인 접근법이 있다.

전자는 nodeName, nodeSelector나 affinity라고 부르는 방법이고, 후자는 Taint라고 하는 방법을 사용한다.

이 포스트에서 주로 다룰 것은 전자다. 후자의 경우에는 별도 문서를 참조한다.
https://blog.naver.com/sssang97/223645592718

nodeSelector

nodeSelector는 Pod를 특정 Node에 뜨도록 유도하는 가장 단순한 방법이다.

Node도 다른 k8s 리소스들과 마찬가지로 label이라고 하는 메타데이터 값들을 갖는다. 이걸 기반으로 노드를 선택하고 들어가는 것이다.

노드에 레이블을 추가하는건 어렵지 않다.
그냥 이렇게 치면 된다.

kubectl label nodes 노드명 키=값

그리고 Pod에 node 선택 정보를 넣으려면, spec.nodeSelector에 키값쌍을 넣으면 된다.

  nodeSelector:
    키: 값

만약 저 셀렉터와 일치하는 노드가 없다면

pod는 스케줄되지 못하고 무한 대기상태에 빠진다.

일치하는대로 입력한다면

그 노드에 올바르게 배치될 것이다.

nodeName

nodeSelector는 레이블을 기반으로 한 노드 선택이었다.
반면, 진짜 노드 이름을 직접 지정해서 딱 그 노드에 뜨게 하는 방법도 있다.

사용법은 매우 간단하다.

spec:
  nodeName: 노드명

그냥 이렇게 노드명 넣고 돌리면

딱 그 노드에 배치가 될 것이다.

그리고 일치하는 노드가 없다면

nodeSelector와 마찬가지로 무한 대기 상태에 빠진다.

nodeName이 간편하긴 하지만, 장기적으로 관리하기에는 영 좋지 않아서 일반적으로 권장되지 않고, 잘 사용되지도 않는다. 그냥 있기만 한 기능이다.

아무튼 nodeName이나 nodeSelector 기반의 방법은 직관적이고 잘 동작하긴 하지만, 복잡한 상황에서는 적용하기 어려울 수도 있다.
딱 특정 머신에 배치되는걸 원할 수도 있지만, 그냥 우선순위를 기반으로 특정 머신에 배치하는 것을 "선호"하도록 구성하고 싶을 수도 있기 때문이다. 그걸 위한 기능이 affinity다.

node affinity

node affinity는 복잡한 형태의 노드 배치 구조를 정의할 수 있는 매커니즘이다.

이건 nodeSelector처럼 일치하는 것에만 배치되도록 엄격한 제한을 추가할 수도 있고, 단지 "선호"하도록 우선순위를 지정하는 정도로 끝낼 수도 있다.

딱 일치하는 것에만 배치되도록 하는 옵션이 requiredDuringSchedulingIgnoredDuringExecution고, 우선순위만 지정하는 것이 preferredDuringSchedulingIgnoredDuringExecution다.

한번 예제를 까보면서 기본 형태를 이해해보자.

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/os
            operator: In
            values:
            - linux
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: label-1
            operator: In
            values:
            - key-1
      - weight: 50
        preference:
          matchExpressions:
          - key: label-2
            operator: In
            values:
            - key-2

앞서 언급했듯 requiredDuringSchedulingIgnoredDuringExecution는 must 조건이다.

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/os
            operator: In
            values:
            - linux

이건 kubernetes.io/os=linux라는 레이블이 포함된 node에만 pod가 배치될 것임을 뜻하는 구문이다.
이 부분은 꽤 단순명료하다.

preferredDuringSchedulingIgnoredDuringExecution는 단순히 우선순위를 지정하는 옵션이다.
이 우선순위와 맞지 않더라도 적절한 노드가 없으면 아무거나 상황에 따라 배치한다.

      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: label-1
            operator: In
            values:
            - key-1
      - weight: 50
        preference:
          matchExpressions:
          - key: label-2
            operator: In
            values:
            - key-2

보이는 것처럼, 이건 가중치(weight) 기반으로 노드를 선택한다.
그러니까, label-1:key-1 레이블이 있는 노드에 1점을 주고, label-2:key-2 레이블이 있는 노드에 50점을 줘서 가장 높은 점수를 가진 노드를 우선적으로 선택하는 것이다.

pod affinity & pod anti affinity

이건 좀 더 복잡한 사용사례를 상정한 노드 선택 매커니즘이다.
node affinity의 경우에는 순수하게 노드의 레이블을 기반으로 해서 노드를 선택했다. 노드가 pod가 몇개 떠있든, 리소스가 얼마나 남았든 신경쓰지 않는다.

하지만 pod가 이미 떠있는 것까지 고려해서 노드 배치를 고려하고 싶을 수도 있다.
예를 들면 특정 Pod가 떠있는 노드는 리소스가 부족할 테니 다른 노드에 배치하게끔 하고 싶다든지 하는 그런 상황 말이다.
pod affinity는 이런 상황에 유용한 기능이다.

pod affinity도 node affinity와 비슷하게 2가지 옵션을 가진다.

• requiredDuringSchedulingIgnoredDuringExecution
• preferredDuringSchedulingIgnoredDuringExecution

한번 실제적인 예시를 들어서 보여보겠다.

apiVersion: v1
kind: Pod
metadata:
  name: with-pod-affinity
spec:
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: topology.kubernetes.io/zone

이건 security:S1라는 pod가 있는 영역(zone)에 배치하는 것이다. 그리고 이 zone의 기준이 topologyKey로 설정한 "topology.kubernetes.io/zone"다. 이건 노드를 묶는 기준이 되는 레이블 값이다.

그러니까, 다시 말해 이 경우에는 security:S1라는 pod가 있는 노드와 동일한 "topology.kubernetes.io/zone" 레이블을 가진 모든 노드가 스케줄링 대상이 될 수 있는 것이다.

"topology.kubernetes.io/zone"는 클라우드 클러스터 환경에서 자동으로 주입되는 레이블 값이고, 온프레미스에서는 직접 적절히 구성해야 한다.
관례적으로 kubernetes.io/hostname도 많이 쓴다. 이건 보통 노드마다 다르게 짓는다.

podAntiAffinity도 원리가 거의 같다. 정확히 그 반대로, 그 zone에 속하는 것들에 pod가 배치되지 않게 하는 것일 뿐이다.

spec:
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: security
              operator: In
              values:
              - S2
          topologyKey: topology.kubernetes.io/zone

pod anti affinity 응용 - 노드 분산

그럼 저 복잡한 놈들을 어떻게 써먹어야 할까?

anti affinity는 특정 조건의 pod가 떠있는 상황을 기피하도록 구성할 수 있다.
그러니까, 이 특성을 응용하면 deployment 같은 그룹 단위의 pod가 노드별로 고르게 분산되는 것을 강요할 수 있는 것이다.

다음은 redis로 노드 분산을 구성하는 간단한 예제다.
redis 같은 경우에는 실제로 각 노드의 웹 서버들이 최적의 경로로 접근할 수 있게끔 노드별로 배치를 할 필요가 있을 수 있을 것이다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: redis-cache
spec:
  selector:
    matchLabels:
      app: store
  replicas: 3
  template:
    metadata:
      labels:
        app: store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: redis-server
        image: redis:3.2-alpine

보다시피 이 deploement는 각각의 pod에 app: store 레이블값을 갖도록 구성했다.
그런데 podAntiAffinity로는 app: store가 있는 노드를 무시하도록 했으니, 총 3개의 노드에 랜덤으로 분산되는 것이다.

이처럼 복잡할 수도 있는 프로비저닝 구성을 비교적 간편하게 설정할 수 있다.

pod affinity 응용 - 분산 노드 따라가기

방금 위에서는 redis를 3개의 노드에 분산해서 배치하도록 구성을 했었다.
그런데 여기서 redis를 가리키는 웹서버들을 최적의 경로로 붙게 하려면 어떻게 해야할까?

이것도 pod affinity를 응용하면 비교적 간편하게 구성이 가능하다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  selector:
    matchLabels:
      app: web-store
  replicas: 3
  template:
    metadata:
      labels:
        app: web-store
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - web-store
            topologyKey: "kubernetes.io/hostname"
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: web-app
        image: .../web-server-image

좀 길고 복잡해보일 수도 있는데, 구조를 안다면 그렇게 어렵지는 않다.

podAntiAffinity에는 방금 redis 구성과 마찬가지로 노드별로 하나씩만 뜨도록 분산 구성이 되어있다. 이건 어려울 건 없다.

근데 여기서 우리는 더 나아가서, 각 redis가 위치한 곳에 웹서버를 위치시켜서 최소한의 레이턴시를 만들고 싶다.
그래서 podAffinity를 통해서 app: store가 있는, 그러니까 redis가 있는 node에만 배치하도록 했다.

이렇게 구성할 경우 redis과 웹서버는 다음과 같이 컴팩트하게 구성될 수 있다.

참조
https://kubernetes.io/ko/docs/tasks/configure-pod-container/assign-pods-nodes/
https://kubernetes.io/ko/docs/concepts/scheduling-eviction/assign-pod-node/#%EC%96%B4%ED%94%BC%EB%8B%88%ED%8B%B0-affinity-%EC%99%80-%EC%95%88%ED%8B%B0-%EC%96%B4%ED%94%BC%EB%8B%88%ED%8B%B0-anti-affinity
https://kubernetes.io/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/
https://stackoverflow.com/questions/72240224/what-is-topologykey-in-pod-affinity