Kubernetes v1.35: 숫자 비교를 지원하도록 확장된 Toleration 연산자 (Alpha)

I’m happy to translate the article for you, but I’ll need the text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided and preserve all formatting, markdown, and code blocks.

개요

많은 프로덕션 Kubernetes 클러스터는 on‑demand(높은 SLA)와 spot / preemptible(낮은 SLA) 노드를 혼합하여 비용을 최적화하면서 중요한 워크로드에 대한 신뢰성을 유지합니다. 플랫폼 팀은 대부분의 워크로드를 위험한 용량에서 멀리 떨어뜨리는 안전한 기본값을 필요로 하며, 동시에 “실패 확률이 5 %까지인 노드를 허용한다”와 같은 명시적인 임계값을 통해 특정 워크로드가 선택적으로 참여할 수 있도록 해야 합니다.

현재 Kubernetes taint와 toleration은 정확한 값 매칭이나 존재 여부 확인은 가능하지만, 수치 임계값을 비교할 수는 없습니다. 일반적인 우회 방법은 다음과 같습니다:

• 이산적인 taint 카테고리 생성
• 외부 admission controller 사용
• 최적이 아닌 배치 결정 수용

Kubernetes v1.35에서는 Extended Toleration Operators(alpha)를 도입합니다. 이 확장은 spec.tolerations에 Gt(Greater‑Than)와 Lt(Less‑Than) 연산자를 추가하여, 임계값 기반 스케줄링 결정을 가능하게 하고 SLA 기반 배치, 비용 최적화, 성능 인식 워크로드 분배와 같은 새로운 가능성을 열어줍니다.

Tolerations의 진화

역사적으로 Kubernetes는 두 가지 주요 toleration 연산자를 지원했습니다:

이들은 범주형 시나리오에서는 잘 작동하지만 숫자 비교에서는 한계가 있습니다. v1.35부터 이 격차를 해소합니다.

숫자 연산자를 통해 가능해진 실제 시나리오

• SLA 요구사항 – 장애 확률이 임계값 이하인 노드에만 고가용성 워크로드를 스케줄링합니다.
• 비용 최적화 – 비용에 민감한 배치 작업이 특정 시간당 비용 값을 초과하는 저렴한 노드에서 실행되도록 허용합니다.
• 성능 보장 – 지연 시간에 민감한 애플리케이션이 디스크 IOPS 또는 네트워크 대역폭이 최소 임계값 이상인 노드에서만 실행되도록 보장합니다.

숫자 비교 연산자가 없으면 클러스터 운영자는 확장성이 없고 유연성이 부족한 우회 방법에 의존해야 했습니다.

왜 NodeAffinity 대신 tolerations를 확장하는가?

NodeAffinity는 이미 숫자 비교 연산자를 지원하고 있는데, 왜 tolerations에 추가하는가?

tolerations를 확장하면 잘 이해된 안전 모델을 유지하면서 SLA‑인식 스케줄링을 위한 임계값 기반 배치를 가능하게 합니다.

Introducing Gt and Lt operators

Kubernetes v1.35 adds two new operators for tolerations:

When a pod tolerates a taint with Lt, it is saying “I can tolerate nodes where this metric is less than my threshold”. Since tolerations allow scheduling, the pod can run on nodes where the taint value is greater than the toleration value – i.e., “I tolerate nodes that are above my minimum requirements”.

These operators work with numeric taint values and are applicable to all taint effects: NoSchedule, NoExecute, and PreferNoSchedule.

Note
Numeric values for Gt and Lt must be positive 64‑bit integers without leading zeros. For example, "100" is valid, but "0100" (leading zero) and "0" (zero value) are not permitted.

사용 사례 및 예시

예시 1 – SLA 임계값을 가진 스팟 인스턴스 보호

많은 클러스터가 비용 최적화를 위해 온‑디맨드와 스팟/프리엠프티블 노드를 혼합해서 사용합니다. 스팟 노드는 비용 절감 효과가 있지만 실패율이 높습니다. 목표: 대부분의 워크로드는 기본적으로 스팟 노드를 피하고, 특정 워크로드만 명확한 SLA 경계와 함께 선택적으로 사용할 수 있게 합니다.

1️⃣ 스팟 노드에 실패 확률(예: 연간 15 % 실패율)로 taint 적용

apiVersion: v1
kind: Node
metadata:
  name: spot-node-1
spec:
  taints:
  - key: "failure-probability"
    value: "15"
    effect: "NoExecute"

2️⃣ 온‑디맨드 노드에 더 낮은 실패율로 taint 적용

apiVersion: v1
kind: Node
metadata:
  name: ondemand-node-1
spec:
  taints:
  - key: "failure-probability"
    value: "2"
    effect: "NoExecute"

3️⃣ 엄격한 SLA(≤ 5 % 실패 확률)를 요구하는 핵심 워크로드

apiVersion: v1
kind: Pod
metadata:
  name: payment-processor
spec:
  tolerations:
  - key: "failure-probability"
    operator: "Lt"
    value: "5"
    effect: "NoExecute"
    tolerationSeconds: 30   # 노드 SLA가 악화될 경우의 유예 기간
  containers:
  - name: app
    image: payment-app:v1

결과: 이 파드는 failure-probability가 5 미만인 노드에만 스케줄됩니다(즉, 값이 2인 ondemand-node-1). NoExecute 효과와 tolerationSeconds: 30은 노드의 taint 값이 변할 경우 파드가 30 초 동안 정상 종료할 수 있는 시간을 제공합니다.

4️⃣ 스팟 인스턴스를 명시적으로 선택하는 내결함성 배치 작업

apiVersion: v1
kind: Pod
metadata:
  name: batch-job
spec:
  tolerations:
  - key: "failure-probability"
    operator: "Gt"
    value: "10"
    effect: "NoExecute"
    tolerationSeconds: 60
  containers:
  - name: worker
    image: batch-worker:v2

결과: 이 파드는 실패 확률이 10 초과인 노드(즉, 스팟 노드)를 허용합니다. 스팟 노드의 실패 확률이 나중에 임계값 이하로 떨어지면, 파드는 60 초 유예 기간 후에 퇴출됩니다.

예시 2 – GPU 티어를 활용한 AI 워크로드 배치

1. GPU 노드에 컴퓨팅 능력 점수로 taint 적용

apiVersion: v1
kind: Node
metadata:
  name: gpu-node-a100
spec:
  taints:
  - key: "gpu-compute-score"
    value: "1000"
    effect: "NoSchedule"
---
apiVersion: v1
kind: Node
metadata:
  name: gpu-node-t4
spec:
  taints:
  - key: "gpu-compute-score"
    value: "500"
    effect: "NoSchedule"

2. 고성능 GPU가 필요한 대규모 학습 워크로드

apiVersion: v1
kind: Pod
metadata:
  name: model-training
spec:
  tolerations:
  - key: "gpu-compute-score"
    operator: "Gt"
    value: "800"
    effect: "NoSchedule"
  containers:
  - name: trainer
    image: ml-trainer:v1
    resources:
      limits:
        nvidia.com/gpu: 1

이 파드는 컴퓨팅 점수가 800 초과인 노드(예: A100 노드)에서만 스케줄되어, 낮은 티어 GPU에 배치돼 학습 속도가 저하되는 것을 방지합니다.

3. 추론 워크로드 – 사용 가능한 모든 GPU 활용 가능

apiVersion: v1
kind: Pod
metadata:
  name: model-inference
spec:
  tolerations:
  - key: "gpu-compute-score"
    operator: "Gt"
    value: "400"
    effect: "NoSchedule"
  containers:
  - name: inference
    image: ml-inference:v1
    resources:
      limits:
        nvidia.com/gpu: 1

이 파드는 컴퓨팅 점수가 400 초과인 모든 노드(A100와 T4 모두)에서 스케줄됩니다.

예시 3 – 비용 최적화 워크로드 배치

1. 노드에 비용 등급으로 taint 적용

spec:
  taints:
  - key: "cost-per-hour"
    value: "50"
    effect: "NoSchedule"

2. 비용에 민감한 배치 작업 – 저렴한 노드만 허용

tolerations:
- key: "cost-per-hour"
  operator: "Lt"
  value: "100"
  effect: "NoSchedule"

이 작업은 시간당 $100 미만인 노드에만 스케줄되어, 더 비싼 리소스를 회피합니다.

예시 4 – 성능 기반 배치 (디스크 IOPS)

tolerations:
- key: "dis

```yaml
k-iops"
  operator: "Gt"
  value: "3000"
  effect: "NoSchedule"

Pod는 disk-iops가 3000을 초과하는 노드에만 스케줄됩니다.

이 기능 사용 방법

Extended Toleration Operators는 Kubernetes v1.35의 알파 기능입니다.

1. Enable the feature gate on both the API server and the scheduler:

   --feature-gates=TaintTolerationComparisonOperators=true

2. Taint your nodes with numeric values that represent the metrics relevant to your scheduling needs:

   kubectl taint nodes node-1 failure-probability=5:NoSchedule
   kubectl taint nodes node-2 disk-iops=5000:NoSchedule

3. Use the new operators in your pod specifications:

   spec:
     tolerations:
     - key: "failure-probability"
       operator: "Lt"
       value: "1"
       effect: "NoSchedule"

참고

• 알파 기능이므로, Extended Toleration Operators는 향후 릴리스에서 변경될 수 있습니다.
• 프로덕션 환경에서는 주의해서 사용하고, 비프로덕션 클러스터에서 충분히 테스트하십시오.

다음은?

이 알파 릴리스는 시작에 불과합니다. 커뮤니티 피드백을 수집하면서 우리는 다음을 계획하고 있습니다:

• CEL (Common Expression Language) 표현식을 tolerations와 node affinity에 지원하여 시맨틱‑버전 비교를 포함한 보다 유연한 스케줄링 로직을 제공.
• cluster autoscaling과의 통합을 개선하여 임계값을 인식한 용량 계획을 지원.
• 기능을 beta 단계로 승격하고 궁극적으로 GA(General Availability) 단계에 올려 프로덕션 수준의 안정성을 제공.

우리는 특히 여러분의 사용 사례에 관심이 많습니다!
임계값 기반 스케줄링으로 문제를 해결할 수 있는 시나리오가 있나요?
추가로 보고 싶은 연산자나 기능이 있나요?

참여하기

이 기능은 SIG Scheduling 커뮤니티에 의해 주도됩니다. 아이디어와 피드백을 공유하려면 참여해 주세요:

• Slack: #sig-scheduling on the Kubernetes Slack workspace
• Mailing list: kubernetes-sig-scheduling@googlegroups.com

Extended Toleration Operators와 관련된 구체적인 문의는 SIG Scheduling 커뮤니티에 연락해 주세요. 여러분의 의견을 기다리고 있습니다!

더 알아보기

• Taints and Tolerations – 노드‑파드 스케줄링의 기본 개념
• Numeric Comparison Operators – Gt 및 Lt 연산자 사용에 대한 자세한 내용
• KEP‑5471: 임계값 기반 배치를 위한 확장된 Toleration 연산자