GKE 포드 스냅샷 정보

Google Kubernetes Engine (GKE) 포드 스냅샷은 실행 중인 포드의 스냅샷을 복원하여 워크로드 시작 지연 시간을 개선하는 데 도움이 됩니다. 포드 스냅샷은 메모리 및 파일 시스템 변경사항을 포함한 전체 포드 상태를 저장합니다. 새 복제본을 만들면 스냅샷에서 복원되므로 워크로드가 새 상태에서 시작하는 대신 재개될 수 있습니다.

이 문서에서는 GKE 포드 스냅샷의 개념 개요를 설명합니다. 이 기능을 사용 설정하고 사용하는 방법은 Pod 스냅샷에서 복원을 참고하세요.

Pod 스냅샷을 사용해야 하는 경우

CPU 또는 GPU 메모리에 대규모 모델을 로드하는 AI 추론 워크로드나 많은 라이브러리와 종속 항목을 로드하는 대규모 애플리케이션과 같이 초기화 시간이 긴 워크로드에는 포드 스냅샷을 사용하세요. 시작 시간이 이미 빠른 워크로드는 일반적으로 포드 스냅샷의 이점을 누릴 수 없습니다.

포드 스냅샷 작동 방식

GKE 포드 스냅샷은 특정 시점의 포드 프로세스 상태의 정확한 사본을 저장합니다. 새 복제본이 생성되면 포드가 초기 상태에서 초기화되는 대신 스냅샷에서 복원되어 스냅샷이 생성된 시점부터 실행이 재개됩니다.

Pod 스냅샷을 사용하려면 스냅샷 동작을 선언적으로 구성하는 Kubernetes 커스텀 리소스 정의 (CRD)를 만듭니다. 각 GKE 노드에서 실행되는 에이전트는 스냅샷 수명 주기를 관리합니다. 정의한 정책에 따라 에이전트는 새 스냅샷을 만들 시점과 기존 스냅샷을 사용하여 새 포드를 복원할 시점을 결정합니다. GKE 컨트롤 플레인에서 실행되는 컨트롤러는 오래된 스냅샷을 정리하고 문제를 해결합니다. Cloud Storage는 포드 스냅샷을 저장합니다.

커스텀 리소스 정의

포드 스냅샷은 다음 CRD를 사용하여 선언적으로 구성됩니다.

  • PodSnapshotStorageConfig: 스냅샷의 스토리지 위치를 지정합니다. Cloud Storage 버킷만 지원됩니다.
  • PodSnapshotPolicy: Kubernetes 라벨 선택기를 기반으로 스냅샷을 생성할 포드를 정의합니다. 이 리소스에는 스냅샷 트리거 방식, 보관 정책 등 기능의 대부분의 구성 옵션이 포함되어 있습니다.
  • PodSnapshotManualTrigger: (선택사항) 워크로드 트리거를 사용하지 않는 경우 특정 포드의 스냅샷을 만드는 수동 트리거를 정의합니다.

스냅샷 트리거

다음과 같은 방법으로 포드 스냅샷을 트리거할 수 있습니다.

  • 워크로드 트리거: 포드 내부의 애플리케이션이 GKE 에이전트에 스냅샷을 찍을 준비가 되었음을 알립니다. 이 유형의 트리거는 워크로드 주기에서 한 번 실행됩니다(예: 워크로드 준비 상태). 이 방법은 수평으로 확장되는 워크로드의 시작 지연 시간을 개선하는 데 가장 적합합니다.
  • 수동 트리거: PodSnapshotManualTrigger 커스텀 리소스를 만들어 특정 포드의 주문형 스냅샷을 트리거할 수 있습니다. 이 유형의 트리거는 필요한 만큼 여러 번 실행될 수 있습니다. 이 방법은 준비 상태를 알리도록 애플리케이션을 수정할 수 없는 상황에 가장 적합합니다.

스냅샷 일치

포드 일치는 포드 스냅샷이 특정 포드와 호환되는지 여부를 결정합니다. 이 일치는 포드의 필수 런타임 사양(증류된 포드 사양이라고도 함)에서 고유한 해시를 만들어 달성됩니다. 이 해시는 포드 스냅샷 내에 삽입됩니다. 나중에 이 포드 스냅샷에서 포드를 복원하려면 자체 증류 포드 사양에서 동일한 해시를 생성해야 합니다. 이 프로세스를 통해 체크포인트가 지정되고 복원된 포드의 런타임 구성이 동일해집니다.

증류는 image와 같은 중요한 런타임 필드만 유지하고 nodeName 또는 nodeSelector와 같은 필수적이지 않은 필드를 삭제하여 포드 사양을 단순화합니다. 이러한 필수 필드의 값이 체크포인트에 사용된 포드와 복원에 사용될 포드 간에 일관되도록 해야 합니다.

포드 객체의 다음 필드는 고유 해시에 영향을 미칩니다.

  • metadata:
    • annotations: gVisor 런타임과 관련된 주석만(예: dev.gvisor.* 접두사로 시작하는 주석)
    • labels: batch.kubernetes.io/job-completion-index
  • spec:
    • volumes: name, volumeSource, hostPath, persistentVolumeClaim, configMap
    • containers:
      • name
      • image
      • command
      • args
      • workingDir
      • ports: name, containerPort, protocol
      • volumeMounts: name, readOnly, recursiveReadOnly, mountPath, subPath, mountPropagation, subPathExpr
      • volumeDevices: name
      • lifecycle: postStart, preStop
      • terminationMessagePath
      • terminationMessagePolicy
      • securityContext (및 모든 하위 필드)
      • stdin
      • stdinOnce
      • tty
    • initContainers: containers과 동일한 하위 필드입니다.
    • dnsPolicy
    • automountServiceAccountToken
    • hostNetwork
    • hostPID
    • hostIPC
    • shareProcessNamespace
    • securityContext
    • dnsConfig
    • runtimeClassName
    • os
    • hostUsers

호환되는 스냅샷으로 간주되려면 다음 추가 기준이 일치해야 합니다.

  • 하드웨어: 새 포드는 원래 포드와 머신 시리즈 및 아키텍처가 동일한 노드에서 실행되어야 합니다. 머신 시리즈와 아키텍처가 동일해야 합니다. CPU 수와 메모리 양은 변경될 수 있습니다. E2 머신 유형은 동적 기본 아키텍처로 인해 지원되지 않습니다.
  • 버전 관리: gVisor 커널 버전과 GPU 드라이버 버전이 일치해야 합니다.

GKE는 스냅샷 호환성을 관리합니다. GKE가 호환되는 스냅샷을 찾으면 GKE는 스냅샷에서 새 포드를 복원합니다. 호환되는 스냅샷이 없으면 포드가 정상적으로 시작됩니다.

컨디션 및 백그라운드 로딩 복원

스냅샷에서 Pod가 복원되면 gVisor 커널이 먼저 복원되며, 이는 일반적으로 몇 초가 걸립니다. 시작 지연 시간을 최소화하기 위해 커널이 복원된 후 애플리케이션이 즉시 재개됩니다. 애플리케이션 메모리가 완전히 로드될 때까지 기다리지 않습니다. 애플리케이션 메모리는 백그라운드 스트리밍 메커니즘을 사용하여 복원됩니다.

애플리케이션이 아직 로드되지 않은 메모리 부분에 액세스하려고 하면 페이지 오류가 발생합니다. gVisor는 이 오류를 가로채고 애플리케이션 스레드를 일시중지하며 스토리지에서 필요한 메모리 페이지를 즉시 가져옵니다. 이 주문형 가져오기는 백그라운드 스트림보다 우선순위가 높습니다.

이러한 백그라운드 로딩으로 인해 애플리케이션에 아직 스트리밍되지 않은 메모리가 필요한 경우 복원 후 처음 몇 초 동안 메모리 액세스에 약간의 지연 시간이 발생할 수 있습니다. 이 지연 시간은 메모리 상태가 완전히 동기화되면 사라집니다.

이 백그라운드 로드 동작은 GPU 상태에도 적용됩니다. 예를 들어 대규모 언어 모델 (LLM) 포드는 GPU 메모리가 아직 채워지고 있음에도 Running 상태로 표시되고 네트워크 확인에 응답할 수 있습니다. GPU 상태가 완전히 복원될 때까지 모델이 추론에 완전히 응답하지 않습니다. 따라서 복원 속도를 측정할 때는 모델 서버가 시작된 시점을 캡처해야 합니다. 첫 번째 토큰까지의 시간 (TTFT) 또는 Pod 준비 프로브와 같은 측정항목을 사용하여 모델 서버가 시작되는 시점을 확인할 수 있습니다.

GPU 상태

포드 스냅샷은 GPU 상태 캡처를 지원합니다. GPU를 사용하는 포드의 스냅샷을 트리거하면 NVIDIA cuda-checkpoint 도구가 GPU 상태를 프로세스 메모리에 저장합니다. 즉, 모델 가중치와 같이 GPU에 저장된 모든 데이터가 스냅샷에 포함됩니다. 그런 다음 포드가 일시중지되고 스냅샷이 생성됩니다. 복원 중에는 프로세스가 반대로 진행됩니다.

GPU 상태가 프로세스 메모리에 기록되므로 스냅샷 및 복원 작업 중에 포드 메모리 사용량이 증가합니다. 포드의 메모리 한도를 설정할 때 이 추가 메모리 요구사항을 고려해야 합니다.

복원된 포드 고려사항

Kubernetes API 관점에서 새 포드가 생성됩니다. 포드가 시작되면 포드에 해당하는 스냅샷이 있는 경우 원래 메모리 및 프로세스 상태를 포함하여 해당 스냅샷에서 포드가 복원됩니다. 하지만 새롭고 고유한 인스턴스로 작동하려면 Pod 상태의 일부 측면이 변경되어야 합니다.

복원 후 다음과 같은 상태 변경이 발생합니다.

  • 네트워크 인터페이스: 복원된 포드가 새 IP 주소를 수신합니다. 모든 네트워크 인터페이스와 경로가 재구성됩니다. 스냅샷 시점에 존재했던 활성 네트워크 연결은 복원 시 닫힙니다. 수신 소켓은 계속 작동합니다.
  • 호스트 이름: 복원된 포드는 새 ID를 가정하고 새 호스트 이름을 수신합니다.
  • 애플리케이션 상태: 실험 ID나 난수 시드와 같이 각 포드에 고유해야 하는 애플리케이션 상태는 복원 후 다시 초기화해야 합니다.
  • 보안 비밀: 스냅샷을 찍기 전에 생성된 암호화 키와 인증서는 다시 생성해야 합니다.
  • 환경 변수: 스냅샷과 복원 간에 환경 변수를 변경할 수 있습니다. 하지만 환경 변수는 애플리케이션 메모리에 저장되므로 GKE Sandbox에서 안정적으로 찾아서 바꿀 수 없습니다. 워크로드가 복원 후 새 환경 변수를 사용하는 경우 Pod가 수동으로 새로고침해야 합니다. 새 환경 변수는 /proc/gvisor/spec_environ 파일에서 사용할 수 있습니다. 파일 형식은 /proc/<pid>/environ와 동일합니다.

복원 후 변경되는 상태

복원 시 일부 상태는 유지되지 않습니다. 포드가 새 ID를 사용할 수 있도록 포드 상태의 다음 부분이 변경됩니다.

  • 네트워크 인터페이스: 복원된 포드가 새 IP 주소를 수신합니다. 모든 인터페이스와 경로가 재구성됩니다. 스냅샷 시점에 있던 활성 네트워크 연결은 복원 시 닫힙니다. 수신 소켓, 루프백 연결, Unix 도메인 소켓 연결은 계속 작동합니다.
  • 호스트 이름: 복원된 포드는 새 ID를 가정하고 새 호스트 이름을 수신합니다.
  • 벽시계 시간: 벽시계 시간이 현재 시간으로 점프합니다.

제한사항 및 요구사항

GKE Pod 스냅샷에는 다음과 같은 제한사항이 있습니다.

  • Pod는 GKE Sandbox에서 실행되어야 합니다. Pod 스냅샷은 GKE Sandbox에서 제공하는 gVisor 컨테이너 런타임에 종속되기 때문입니다.
  • 포드 스냅샷은 E2 머신 유형을 지원하지 않습니다.
  • 포드 스냅샷은 단일 GPU 포드와 함께 작동합니다. 다음 멀티 GPU 구성만 지원됩니다.
    • g2-standard-4 (L4 1개)
    • g2-standard-8 (L4 1개)
    • g2-standard-12 (L4 1개)
    • g2-standard-16 (L4 1개)
    • g2-standard-32 (L4 1개)
    • g2-standard-48 (L4 4개)
    • g2-standard-96 (L4 8개)
    • a2-highgpu-1g (A100-40GB 1개)
    • a2-ultragpu-1g (A100-80GB 1개)
    • a3-highgpu-1g (H100-80GB 1개)
  • 부분 GPU 사용은 지원되지 않습니다. 노드에 GPU가 여러 개 있는 경우 포드는 모든 GPU를 사용해야 합니다. 예를 들어 4개의 GPU 머신에서 각각 GPU 하나를 사용하는 포드 4개로는 포드 스냅샷을 사용할 수 없습니다.
  • 포드 스냅샷과 함께 Cloud Storage FUSE CSI 드라이버 사이드카 컨테이너를 사용하는 것은 지원되지 않습니다.

다음 단계