GKE 포드 스냅샷 정보

표준

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

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

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

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

포드 스냅샷 작동 방식

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

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

스냅샷 콘텐츠

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

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

커스텀 리소스 정의

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

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

스냅샷 트리거

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

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

스냅샷 일치

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

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

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

metadata:
- annotations: dev.gvisor.* 프리픽스로 시작하는 주석과 같이 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는 스냅샷에서 새 포드를 복원합니다. 호환되는 스냅샷이 없으면 포드가 정상적으로 시작됩니다.

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

포드가 스냅샷에서 복원되면 일반적으로 몇 초가 걸리는 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과 동일합니다.

제한사항 및 요구사항

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

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

다음 단계

포드 스냅샷을 사용하는 방법은 포드 스냅샷에서 복원을 참조하세요.