devops

Kubernetes v1.35: 인플레이스 Pod 재시작으로 새로운 효율성 수준

발행: (2026년 1월 3일 오전 03:30 GMT+9)
14 min read
원문: Kubernetes Blog

Source: Kubernetes Blog

기능 활성화

RestartAllContainersOnContainerExits 기능 게이트를 활성화하면 이 기능을 사용할 수 있습니다. 이 알파 기능은 Container Restart Rules 기능을 확장한 것으로, Kubernetes 1.35에서 베타로 승격되었습니다.

# Example feature‑gate configuration
apiVersion: apiserver.k8s.io/v1
kind: AdmissionConfiguration
plugins:
  - name: RestartAllContainersOnContainerExits
    configuration:
      enabled: true

문제

단일 컨테이너 재시작만으로는 충분하지 않고, Pod를 재생성하는 것이 비용이 많이 들 때 기존 재시작 메커니즘은 한계가 있습니다.

  • Kubernetes는 오랫동안 restartPolicy 를 Pod 수준에서 지원했으며, 최근에는 개별 컨테이너 수준에서도 지원합니다.
  • 이러한 정책은 개별적인 충돌에는 잘 작동하지만, 많은 최신 애플리케이션은 복잡한 컨테이너 간 의존성을 가지고 있습니다.

전형적인 시나리오

  • Init 컨테이너가 환경을 준비합니다(예: 볼륨을 마운트하거나 설정 파일을 생성).
    메인 애플리케이션 컨테이너가 이 환경을 손상시키면 해당 컨테이너만 재시작하는 것으로는 충분하지 않으며, 전체 초기화 과정을 다시 실행해야 합니다.

  • Watcher 사이드카가 시스템 상태를 모니터링합니다.
    복구 불가능하지만 재시도 가능한 오류 상태를 감지하면, 메인 애플리케이션 컨테이너를 깨끗한 상태에서 다시 시작하도록 트리거해야 합니다.

  • Resource‑managing 사이드카가 실패합니다.
    사이드카가 자체적으로 재시작하더라도, 메인 컨테이너는 오래되었거나 깨진 연결에 접근하려다 멈출 수 있습니다.

이 모든 경우에 원하는 동작은 단일 컨테이너를 재시작하는 것이 아니라 모든 컨테이너를 재시작하는 것입니다. 이전에는 이를 달성하기 위해 Pod를 삭제하고 컨트롤러(예: Job 또는 ReplicaSet)가 새 Pod를 만들도록 해야 했으며, 이는 스케줄러, 노드‑리소스 할당, 네트워킹 및 스토리지 재초기화 등을 포함하는 느리고 비용이 많이 드는 과정이었습니다.

대규모 AI/ML 워크로드에 미치는 영향

  • 규모: ≥ 1,000 노드에 노드당 하나의 Pod 배치.
  • 요구사항: 장애가 발생했을 때(예: 노드 충돌) 전체 플릿의 모든 Pod를 재생성하여 상태를 초기화해야 학습을 재개할 수 있습니다. 대부분의 Pod가 직접적인 영향을 받지 않더라도 마찬가지입니다.
  • 비용: 수천 개의 Pod를 동시에 삭제·생성·스케줄링하면 거대한 병목이 발생합니다. 추정되는 오버헤드만 해도 ≈ $100 k per month에 달하는 낭비된 리소스 비용이 발생합니다.

전통적으로 이러한 장애를 처리하려면 학습 프레임워크와 Kubernetes 간의 복잡한 통합이 필요했으며, 이는 종종 취약하고 번거로운 작업이었습니다. 새 기능은 Kubernetes‑네이티브 솔루션을 제공하여 견고성을 높이고 개발자가 핵심 학습 로직에 집중할 수 있게 합니다.

추가 이점

Pod를 할당된 노드에 그대로 유지하면 특정 Pod 아이덴티티에 묶인 노드‑레벨 캐시와 같은 추가 최적화를 수행할 수 있습니다. 이는 Pod가 불필요하게 다른 노드에서 재생성될 때는 불가능합니다.

RestartAllContainers 액션 소개

Kubernetes v1.35는 컨테이너 재시작 규칙에 새로운 액션 RestartAllContainers를 추가합니다.
이 액션이 적용된 규칙에 맞게 컨테이너가 종료되면, kubelet은 빠른 인‑플레이스 팟 재시작을 수행합니다.

인‑플레이스 재시작 시 보존되는 항목

  • Pod UID, IP 주소, 네트워크 네임스페이스
  • Pod 샌드박스 및 연결된 모든 디바이스
  • 모든 볼륨, emptyDir 및 PVC에서 마운트된 볼륨 포함

모든 실행 중인 컨테이너를 종료한 후, 팟의 시작 순서가 처음부터 다시 실행됩니다:

  1. 모든 init 컨테이너가 순서대로 다시 실행됩니다.
  2. 사이드카와 일반 컨테이너가 그 뒤에 시작되어, 알려진 정상 환경에서 완전히 새로 시작됩니다.

Note: 임시 컨테이너는 종료됩니다. 이전에 성공했든 실패했든 모든 다른 컨테이너는 개별 재시작 정책과 관계없이 재시작됩니다.

사용 사례

1. ML/배치 작업을 위한 효율적인 재시작

  • 문제: 워커 Pod가 실패했을 때 재스케줄링하는 데 비용이 많이 듭니다. 1,000노드 규모의 학습 클러스터에서는 월 > $100 k에 달하는 컴퓨팅 자원이 낭비될 수 있습니다.
  • 솔루션: RestartAllContainers를 사용해 빠르고 하이브리드적인 복구 전략을 구현합니다:
    • “문제 있는” Pod(예: 비정상적인 Node에 있는 Pod)만 재생성합니다.
    • 나머지 정상적인 Pod에 대해서는 RestartAllContainers를 트리거합니다.
  • 결과: 벤치마크 결과 복구 오버헤드가 몇 분에서 몇 초 수준으로 감소했습니다.

2. Watcher‑Sidecar‑구동 리셋

Watcher 사이드카가 메인 학습 프로세스를 모니터링할 수 있습니다. 특정 재시도 가능한 오류가 발생하면, 사이드카가 지정된 코드를 반환해 워커 Pod를 빠르게 리셋하도록 트리거합니다. 이를 통해 Job 컨트롤러를 거치지 않고 마지막 체크포인트에서 바로 재시작할 수 있습니다. 이 기능은 이제 Kubernetes에서 기본적으로 지원됩니다.

자세히 보기: Future development and JobSet features are described in KEP‑467 – JobSet in‑place restart.

apiVersion: v1
kind: Pod
metadata:
  name: ml-worker-pod
spec:
  restartPolicy: Never
  initContainers:
    # This init container will re‑run on every in‑place restart
    - name: setup-environment
      image: my-repo/setup-worker:1.0
  containers:
    - name: watcher-sidecar
      image: my-repo/watcher:1.0
      # Container‑level restart policy (still respected for individual restarts)
      restartPolicy: Always
  restartPolicyRules:
    - action: RestartAllContainers
      # Example rule: trigger when the watcher exits with code 42
      exitCodes: [42]

위 스니펫은 watcher-sidecar가 종료 코드 42로 종료될 때 모든 컨테이너를 재시작하도록 파드를 선언하는 방법을 보여줍니다.

핵심 요약

RestartAllContainers는 Kubernetes 사용자가 경량의 인‑플레이스 포드 재설정 메커니즘을 제공하여:

  • 대규모에서 컴퓨팅 자원과 비용을 절감합니다.
  • 복구 시간을 분에서 초로 단축합니다.
  • 중요한 포드 아이덴티티(UID, IP, 볼륨 등)를 보존합니다.
  • 추가 컨트롤러 로직 없이도 보다 풍부한 사이드카 기반 복구 패턴을 가능하게 합니다.

이 기능은 Kubernetes 위에서 견고하고 효율적인 AI/ML 플랫폼을 구축하는 데 중요한 진전을 의미합니다.

RestartAllContainers

onExit

exitCodes:
  operator: In          # A specific exit code from the watcher triggers a full pod restart
  values: [88]
containers:
  - name: main-application
    image: my-repo/training-app:1.0

1. 깨끗한 상태를 위한 Init 컨테이너 재실행

시나리오를 상상해 보세요. init 컨테이너가 자격 증명을 가져오거나 공유 볼륨을 설정하는 역할을 담당합니다.
메인 애플리케이션이 이 공유 상태를 손상시키는 방식으로 실패하면 init 컨테이너를 다시 실행해야 합니다.

메인 애플리케이션이 이러한 손상을 감지했을 때 특정 코드를 반환하도록 구성하면 RestartAllContainers 동작을 트리거할 수 있으며, 이를 통해 애플리케이션이 재시작되기 전에 init 컨테이너가 깨끗한 설정을 제공하도록 보장합니다.

2. 높은 유사 작업 실행 비율 처리

일부 워크로드는 각 작업이 깨끗한 환경을 필요로 하는 Pod 실행 형태로 가장 잘 표현됩니다(예: 게임‑세션 백엔드 또는 큐‑아이템 프로세서).
작업 비율이 높을 경우, Pod 생성, 스케줄링 및 초기화 전체 사이클이 비용이 많이 들게 됩니다—특히 짧은 수명의 작업에서는 더욱 그렇습니다.

모든 컨테이너를 처음부터 다시 시작할 수 있는 기능은 맞춤형 솔루션이나 프레임워크 없이도 이 시나리오를 Kubernetes‑네이티브 방식으로 처리할 수 있게 해줍니다.

사용 방법

  1. Feature gate 활성화

    • Kubernetes 컨트롤 플레인 컴포넌트(API 서버와 kubelet)에서 RestartAllContainersOnContainerExits를 설정합니다.
    • Kubernetes **v1.35+**가 필요합니다.
    • 이 알파 기능은 ContainerRestartRules 기능을 확장한 것으로, v1.35에서 베타로 승격했으며 기본적으로 활성화됩니다.

  2. restartPolicyRules 를 원하는 컨테이너(Init, 사이드카, 일반 컨테이너) 에 추가하고 RestartAllContainers 액션을 사용합니다.

  3. 베스트 프랙티스 체크리스트

    • 모든 컨테이너가 재진입 가능하도록 보장합니다.
    • 외부 도구가 Init 컨테이너의 재실행을 처리할 수 있는지 확인합니다.
    • 전체 컨테이너 재시작 시 preStop 훅이 실행되지 않음을 기억하세요; 컨테이너는 갑작스러운 종료를 견딜 수 있어야 합니다.

Observing the Restart

  • 새로운 Pod 조건 AllContainersRestarting 가 Pod의 상태에 추가됩니다.

    • 재시작이 트리거될 때 True 가 됩니다.
    • 모든 컨테이너가 종료되고 Pod가 다시 라이프사이클을 시작할 준비가 되면 False 로 되돌아갑니다.

  • 이 동작에 의해 재시작된 모든 컨테이너는 컨테이너 상태에서 재시작 횟수가 증가합니다.

자세히 알아보기

  • Pod Lifecycle – 공식 문서.
  • KEP‑5532 – 컨테이너 종료 시 모든 컨테이너 재시작 (상세 제안).
  • JobSet in‑place restart – JobSet 이슈 #467에서의 논의.

여러분의 의견을 기다립니다!

As an alpha feature, RestartAllContainers는 실험을 위해 준비되었습니다.
여러분의 사용 사례와 피드백을 환영합니다. 이 기능은 SIG Node 커뮤니티에 의해 주도됩니다.

참여 방법:

  • Slack: #sig-node
  • Mailing list: (link to SIG Node mailing list)
Back to Blog

관련 글

더 보기 »