GKE 포드 스냅샷 정보

Autopilot Standard

Google Kubernetes Engine (GKE) 포드 스냅샷은 실행 중인 포드의 스냅샷을 복원하여 워크로드 시작 지연 시간을 개선하는 데 도움이 됩니다. 포드 스냅샷은 메모리 및 파일 시스템 변경사항을 포함한 전체 포드 상태를 저장합니다. 새 복제본을 만들면 스냅샷에서 복원되므로 워크로드가 새 상태에서 시작하는 대신 재개됩니다. 이 기능은 대규모 가중치를 메모리에 로드하는 AI 추론 모델이나 광범위한 종속 항목을 로드하는 애플리케이션과 같은 워크로드를 수평 확장하는 데 유용합니다.

이 문서를 사용하여 GKE 포드 스냅샷의 작동 방식을 이해하고 워크로드에 도움이 되는지 평가하세요.

플랫폼 관리자, 운영자, 애플리케이션 개발자는 이 문서를 사용하여 워크로드 호환성을 평가하고, 스냅샷 스토리지 정책을 계획하고, GKE가 체크포인트 및 복원을 관리하는 방법을 이해할 수 있습니다.Google Cloud 콘텐츠에서 참조하는 일반적인 역할과 예시 태스크에 대한 자세한 내용은 일반 GKE 사용자 역할 및 태스크를 참조하세요.

클러스터에서 포드 스냅샷을 준비하고 사용하려면 다음 가이드를 참고하세요.

1. 포드 스냅샷 준비
2. 포드 스냅샷 트리거
3. 포드 스냅샷에서 워크로드 복원

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

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

포드 스냅샷 작동 방식

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

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

스냅샷 콘텐츠

다음 표에는 포드 스냅샷에 포함되는 항목과 제외되는 항목이 나와 있습니다.

카테고리	포함됨	제외됨
애플리케이션 상태	프로세스 메모리 실행 스레드 CPU 레지스터 열린 파일 설명자	없음 (모든 메모리 내 프로세스 상태가 캡처됨)
파일 시스템	컨테이너 루트 파일 시스템 (rootfs) emptyDir권 tmpfs 마운트	PersistentVolumeClaim 객체 포함된 것으로 나열되지 않은 기타 볼륨 또는 스토리지 유형
네트워킹	루프백 연결 수신 소켓 Unix 도메인 소켓	활성 외부 연결 (복원 시 종료됨) 커스텀 경로 사용자 정의 규칙 (iptables, nftables)

커스텀 리소스

선언적으로 포드 스냅샷을 구성하려면 다음 커스텀 리소스를 사용합니다.

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

참조 사양은 PodSnapshot CustomResourceDefinition 참조를 확인하세요.

스냅샷 트리거

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

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

스냅샷 일치 및 호환성

스냅샷이 복원된 워크로드와 호환되는지 확인하기 위해 GKE는 원래 체크포인트가 지정된 포드와 대상 포드 간에 호환성 일치를 수행합니다.

GKE는 다음 규칙을 사용하여 호환성을 확인합니다.

• 선택 순서: 기본적으로 GKE는 포드의 네임스페이스 및 구성과 일치하는 가장 최근의 PodSnapshot 커스텀 리소스에서 워크로드를 복원합니다.
• 일치 기준: 호환성 검사는 PodSnapshotPolicy 커스텀 리소스 (whole-pod 또는 rootfs-only)에 구성된 스냅샷 범위에 따라 달라집니다.

whole-pod 범위 일치 (기본값)

기본 whole-pod 범위가 있는 정책의 경우 GKE는 다음을 확인합니다.

• 정제된 사양 해시: GKE는 포드 사양의 필수 런타임 필드를 기반으로 고유한 해시를 생성합니다. 복원이 성공하려면 대상 포드가 추출된 사양에서 동일한 해시를 생성해야 합니다. 이 검사는 체크포인트 및 복원된 포드의 런타임 구성이 동일한지 확인합니다.

  포드 객체의 다음 필드는 정제된 사양의 일부이며 고유 해시에 영향을 미칩니다.

  • metadata:
    • annotations: GKE Sandbox와 관련된 주석만 해당합니다 (예: 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 공급업체, CPU 기능 세트 (CPUID 플래그)가 있는 노드에서 실행되어야 합니다. 예를 들어 두 노드 모두 동일한 N2 또는 G2 시리즈와 동일한 Intel 또는 AMD 프로세서 기능을 사용해야 합니다. GKE Sandbox는 프로세스 메모리 및 CPU 상태를 복원하기 전에 CPU 기능을 확인하므로 whole-pod 범위가 있는 스냅샷은 다른 CPU 기능이 있는 노드에 복원할 수 없습니다.

• 버전 호환성: GKE Sandbox 커널 버전과 GPU 드라이버 버전이 원래 스냅샷에 캡처된 버전과 일치해야 합니다.

범위 일치 rootfs-only개

rootfs-only 범위(GKE 버전 1.35.3-gke.1031000 이상에서 사용 가능)로 정책을 구성하는 경우 일치 요구사항이 덜 엄격합니다.

• GKE는 정제된 포드 사양 해시를 계산하거나 비교하지 않습니다. 이 완화된 일치를 사용하면 다른 리소스, 환경 또는 기타 구성 필드가 있는 대상 포드에 스냅샷을 복원할 수 있습니다. 하지만 기본 컨테이너 이미지와 노드 버전이 호환되어야 합니다.
• 프로세스 메모리가 복원되지 않으므로 한 머신 계열에서 생성된 스냅샷을 다른 머신 계열 (E2 머신 유형 포함)로 복원할 수 있습니다.

그룹화 규칙 일치

정책이 snapshotGroupingRules 필드를 사용하여 특정 라벨 값 (예: 테넌트 또는 환경)으로 스냅샷을 그룹화하는 경우 복원된 포드에 일치하는 라벨 키와 값이 있어야 합니다. 포드 스냅샷 컨트롤러는 일치하는 그룹에서만 스냅샷을 선택합니다. 그룹화 라벨을 설정하는 방법에 대한 자세한 내용은 추가 포드 스냅샷 정책 설정 구성을 참조하세요.

복원 준비 및 백그라운드 로드

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

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

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

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

GPU 상태

포드 스냅샷은 GPU 상태 캡처를 지원합니다. GPU를 사용하는 포드의 스냅샷을 트리거하면 NVIDIA cuda-checkpoint 도구가 GPU 상태를 프로세스 메모리에 저장합니다. 이 단계는 모델 가중치와 같이 GPU에 저장된 데이터가 스냅샷에 포함되도록 하는 데 도움이 됩니다. GKE는 포드를 일시중지하고 스냅샷을 만듭니다. 복원 중에 GKE는 이 작업을 되돌립니다.

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

복원된 포드 고려사항

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

복원 후 다음과 같은 상태 변경을 고려하세요.

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

멀티테넌시 및 ID

포드 스냅샷을 사용하려면 Cloud Storage를 사용하기 위해 각 포드의 Kubernetes ServiceAccount 객체에 대한 수동 Identity and Access Management (IAM) 바인딩이 필요합니다. 수동 IAM 바인딩은 전파하는 데 시간이 걸릴 수 있으며, 포드를 만든 직후에 스냅샷을 만들어야 하는 경우 문제가 될 수 있습니다.

지연을 해결하고 멀티 테넌트 관리를 간소화하기 위해 IAM을 ServiceAccount 객체에 수동으로 바인딩하는 대신 GKE 노드 서비스 계정을 사용하여 요청 시 단기 토큰을 만들 수 있습니다. 이 접근 방식으로 포드 스냅샷을 구성하려면 PodSnapshotStorageConfig 커스텀 리소스의 tokenSource 필드를 다음 값 중 하나와 함께 사용합니다.

• podKSA (기본값): 포드의 ServiceAccount 객체와 Cloud Storage 버킷 간에 수동 IAM 바인딩을 사용합니다.
• federatedP4SA: 노드 서비스 계정에서 생성된 경로별 토큰을 사용합니다.

요구사항

GKE 포드 스냅샷을 사용하려면 다음 요구사항을 충족해야 합니다.

• 포드 스냅샷은 GKE Sandbox에서 제공하는 격리된 환경에 따라 달라지므로 포드는 GKE Sandbox에서 실행되어야 합니다.
• 기본 whole-pod 스냅샷 범위의 경우 포드가 복원되는 노드에는 스냅샷이 생성된 노드와 동일한 머신 시리즈, CPU 공급업체, CPU 기능이 있어야 합니다. CPU 전용 워크로드는 GKE Sandbox에서 지원하고 하드웨어 호환성 요구사항을 충족하는 모든 비E2 머신 시리즈를 사용할 수 있습니다. 자세한 내용은 제한사항을 참조하세요.
• 포드 스냅샷에 GPU를 사용하려면 다음 요구사항도 충족해야 합니다.
  • 단일 GPU 포드는 단일 GPU 노드와 멀티 GPU 노드 모두에서 지원됩니다.
  • 멀티 GPU 포드는 L4 GPU (g2-standard-* 머신 유형)에서만 지원됩니다.
  • GKE 버전 1.35.0-gke.1738000 이하에서는 멀티 GPU 노드에서 실행되는 포드가 해당 노드에서 사용 가능한 모든 GPU를 사용해야 합니다. 버전 1.35.0-gke.1738000 이상에서는 포드가 노드의 GPU 하위 집합을 사용할 수 있습니다.
  • 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개)

제한사항

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

• 기본 whole-pod 스냅샷 범위를 사용하는 경우 스냅샷을 생성한 VM과 CPU 기능 (CPUID 플래그)이 다른 Compute Engine VM으로 스냅샷을 복원할 수 없습니다.
  • whole-pod 범위의 포드 스냅샷은 E2 머신 시리즈 또는 Intel 및 AMD 프로세서 또는 CPU 세대를 동적으로 혼합하는 다른 머신 시리즈를 지원하지 않습니다. 파일 시스템 스냅샷 (rootfs-only 범위)은 E2 머신 시리즈를 지원합니다.
  • 동일한 비E2 머신 시리즈 및 CPU 공급업체 내에서도 Compute Engine은 서로 다른 CPU 플랫폼 또는 VM별 CPU 기능 세트를 사용하여 VM을 프로비저닝할 수 있습니다. CPU 기능이 일치하지 않는 노드에 포드가 예약된 경우 whole-pod 범위로 스냅샷을 복원하면 실패합니다.
• 멀티 인스턴스 GPU (MIG)를 사용한 GPU 공유는 지원되지 않습니다.
• Cloud Storage FUSE CSI 드라이버 사이드카 컨테이너는 포드 스냅샷에서 지원되지 않습니다.
• 포드 스냅샷은 TPU를 지원하지 않습니다.

다음 단계

• 포드 스냅샷 준비 방법 알아보기