GKE 포드 스냅샷 정보

Autopilot Standard

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

이 문서에서는 GKE 포드 스냅샷의 개념 개요를 제공합니다. 이 기능을 사용 설정하고 사용하려면 다음 문서를 참고하세요.

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

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

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

포드 스냅샷 작동 방식

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

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

스냅샷 콘텐츠

다음 표에서는 포드 스냅샷에 포함되는 항목과 포함되지 않는 항목을 설명합니다.

카테고리	스냅샷에 포함됨	스냅샷에 포함되지 않음
애플리케이션 상태	애플리케이션 상태 전체: 모든 열린 파일 설명자, 스레드, CPU 레지스터, 메모리
파일 시스템	컨테이너 루트 파일 시스템 (rootfs), EmptyDir 볼륨, tmpfs 마운트	이전 열에서 다루지 않은 모든 항목 특히 영구 볼륨 은 체크포인트되지 않습니다.
네트워킹	루프백 연결, 수신 대기 소켓, Unix 도메인 소켓	외부 연결은 복원되지 않습니다 (복원 시 종료됨). iptables 또는 nftables와 같은 사용자가 추가한 규칙과 경로는 복원되지 않습니다.

CustomResourceDefinitions

포드 스냅샷은 다음 CRD로 선언적으로 구성됩니다.

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

스냅샷 트리거

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

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

스냅샷 일치 및 호환성

스냅샷이 복원된 워크로드와 호환되도록 GKE는 원래 체크포인트된 포드와 대상 포드 간에 호환성 일치를 수행합니다.

호환성은 다음 규칙에 따라 결정됩니다.

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

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

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

1. 증류된 사양 해시: GKE는 포드 사양의 필수 런타임 필드를 기반으로 고유한 해시를 생성합니다. 복원이 성공하려면 대상 포드가 증류된 사양에서 동일한 해시를 생성해야 합니다. 이 검사를 통해 체크포인트된 포드와 복원된 포드의 런타임 구성이 동일한지 확인할 수 있습니다.

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

   • 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

2. 하드웨어 호환성: 대상 포드는 원래 체크포인트된 포드와 동일한 머신 시리즈 및 CPU 아키텍처가 있는 노드에서 실행되어야 합니다 (예: N2에서 N2 또는 G2에서 G2).

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

rootfs-only 범위 일치

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

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

그룹화 규칙 일치

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

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

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

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

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

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

GPU 상태

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

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

복원된 포드의 고려사항

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

복원 후 다음 상태 변경사항을 고려하세요.

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

멀티 테넌시 및 ID

포드 스냅샷을 사용하려면 각 포드의 Kubernetes ServiceAccount (KSA)가 Cloud Storage에 액세스할 수 있도록 수동 IAM 바인딩이 필요합니다. 수동 IAM 바인딩은 전파하는 데 시간이 걸릴 수 있으며, 포드를 만든 직후에 스냅샷을 생성해야 하는 경우 문제가 될 수 있습니다.

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

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

제한사항 및 요구사항

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

• 포드 스냅샷은 GKE Sandbox에서 제공하는 gVisor 컨테이너 런타임에 종속되므로 포드는 GKE Sandbox에서 실행되어야 합니다.
• 포드 스냅샷은 기본 whole-pod 스냅샷 범위를 사용할 때 E2 머신 유형을 지원하지 않습니다. 파일 시스템 스냅샷 (rootfs-only)은 E2 머신 유형을 지원합니다.
• 포드 스냅샷의 GPU 지원에는 다음과 같은 요구사항 및 제한사항이 있습니다.
  • 단일 GPU 포드는 단일 GPU 노드와 멀티 GPU 노드 모두에서 지원됩니다.
  • 멀티 GPU 포드는 L4 GPU (g2-standard-* 머신 유형)에서만 지원됩니다.
  • 멀티 인스턴스 GPU (MIG)를 사용한 GPU 공유는 지원되지 않습니다.
  • GKE 버전 1.35.0-gke.1738000 이하에서는 멀티 GPU 노드에서 실행되는 포드가 해당 노드에서 사용 가능한 모든 GPU를 사용해야 합니다. 버전 1.35.0-gke.1738000 이상에서는 포드가 노드의 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개)
• Cloud Storage FUSE CSI 드라이버 사이드카 컨테이너는 포드 스냅샷에서 지원되지 않습니다.
• 포드 스냅샷은 TPU 머신 유형을 지원하지 않습니다.

다음 단계

• 포드 스냅샷을 준비하는 방법을 알아보세요.