Google Kubernetes Engine (GKE) 워크로드의 시작 지연 시간을 줄이기 위해 실행 중인 포드의 스냅샷을 생성하고 이 스냅샷에서 새 포드를 복원할 수 있습니다. 이 문서에서는 워크로드에서 또는 수동으로 포드 스냅샷 정책을 만들고 스냅샷을 트리거하는 방법을 보여줍니다. 포드 스냅샷 작동 방식에 대한 자세한 내용은 GKE 포드 스냅샷 정보를 참조하세요.
플랫폼 관리자, 운영자, 애플리케이션 개발자는 이 문서를 사용하여 스냅샷 정책을 구성하고 스냅샷을 트리거할 수 있습니다. Cloud de Confiance by S3NS콘텐츠에서 참조하는 일반적인 역할과 예시 태스크에 대한 자세한 내용은 일반 GKE 사용자 역할 및 태스크를 참조하세요.
시작하기 전에
시작하기 전에 다음 태스크를 수행했는지 확인합니다.
- Google Kubernetes Engine API를 사용 설정합니다. Google Kubernetes Engine API 사용 설정
- 이 태스크에 Google Cloud CLI를 사용하려면 gcloud CLI를 설치한 후 초기화합니다. 이전에 gcloud CLI를 설치했으면
gcloud components update명령어를 실행하여 최신 버전을 가져옵니다. 이전 gcloud CLI 버전에서는 이 문서의 명령어를 실행하지 못할 수 있습니다.
- 기본 요건을 완료하고 클러스터에서 포드 스냅샷을 사용 설정합니다. 클러스터 및 스토리지 준비에 대한 자세한 내용은 포드 스냅샷 준비를 참조하세요.
스냅샷 정책 만들기
포드에 스냅샷을 사용 설정하려면 포드의 라벨과 일치하는 선택기로 PodSnapshotPolicy 커스텀 리소스를 만듭니다.
다음 매니페스트를
example-pod-snapshot-policy.yaml로 저장합니다. 이 예시에서는app: my-app라벨이 있는 포드에 적용되는 정책을 만듭니다. 이 정책은 포드 스냅샷 준비에서 만든example-pod-snapshot-storage-configPodSnapshotStorageConfig 커스텀 리소스를 사용하여 스냅샷 스토리지 위치를 정의합니다.apiVersion: podsnapshot.gke.io/v1 kind: PodSnapshotPolicy metadata: name: example-pod-snapshot-policy namespace: NAMESPACE spec: storageConfigName: example-pod-snapshot-storage-config selector: matchLabels: app: my-app triggerConfig: type: TRIGGER_TYPE postCheckpoint: resume다음을 바꿉니다.
NAMESPACE: 포드의 네임스페이스입니다. 포드 스냅샷 준비에서 Cloud Storage 액세스 권한을 부여한 것과 동일한 네임스페이스를 사용합니다.TRIGGER_TYPE: 트리거 유형입니다. 지원되는 값은 워크로드 기반 트리거의 경우workload이고 주문형 스냅샷의 경우manual입니다.
이 예시에서
postCheckpoint: resume설정은 GKE가 스냅샷을 생성한 후 포드를 계속 실행합니다.구성할 수 있는 필드의 전체 목록은 PodSnapshotPolicy 사양을 참조하세요.
매니페스트를 적용합니다.
kubectl apply -f example-pod-snapshot-policy.yaml
추가 포드 스냅샷 정책 설정 구성
PodSnapshotPolicy 커스텀 리소스는 필수 선택기, 스토리지 구성, 트리거 외에도 선택적 설정을 지원합니다. 이러한 추가 설정은 각 스냅샷이 캡처하는 항목, GKE가 스냅샷을 보관하는 기간, GKE가 복원을 위해 스냅샷을 그룹화하는 방법을 제어합니다.
스냅샷 범위: 스냅샷에서 캡처할 포드 상태 부분을 지정하려면
spec.snapshotScope필드를 구성합니다. 지원되는 값은whole-pod(기본값) 및rootfs-only입니다.whole-pod범위는 애플리케이션 상태, 메모리, 파일 시스템을 포함한 전체 포드를 캡처합니다.rootfs-only범위는 컨테이너 루트 파일 시스템만 캡처합니다.rootfs-only범위에는 GKE 버전 1.35.3-gke.1031000 이상이 필요합니다.자동 정리: 이전 PodSnapshot 커스텀 리소스를 자동으로 정리하려면
spec.retentionConfig필드를 사용하여 보관 정책을 구성합니다.lastAccessTimeout필드를 사용하여 기간을 지정할 수 있습니다(예:7d). 이 기간이 경과하면 GKE가 스냅샷을 삭제합니다.스냅샷 그룹화: 비슷한 환경에서 다른 컨텍스트로 촬영된 스냅샷을 격리하려면
spec.snapshotGroupingRules필드에 그룹화 라벨을 지정합니다. 예를 들어 기본 포드가 모든 사용자에 대해 동일한 멀티 테넌트 시나리오에서는 사용자 또는 그룹별로 스냅샷을 격리할 수 있습니다. 복원 중에 GKE는 동일한 라벨 그룹에서만 스냅샷을 선택합니다. 이 그룹화가 복원 중 호환성 일치에 미치는 영향에 대한 자세한 내용은 그룹화 규칙 일치를 참조하세요.
스냅샷 범위, 보관, 그룹화 설정을 독립적으로 구성할 수 있습니다. 다음 예시에서는 PodSnapshotPolicy 커스텀 리소스의 세 가지 설정을 모두 보여줍니다.
# Multiple lines are omitted here
spec:
snapshotScope: rootfs-only
retentionConfig:
lastAccessTimeout: 7d
snapshotGroupingRules:
groupByLabelValue:
labels: ["tenant", "environment"]
groupRetentionPolicy:
maxSnapshotCountPerGroup: 5
구성할 수 있는 필드의 전체 목록은 PodSnapshotPolicy 사양을 참조하세요.
스냅샷 크기 최적화
스냅샷이 클수록 저장하고 복원하는 데 시간이 더 오래 걸립니다. 스냅샷을 트리거하기 전에 GKE가 스냅샷에서 포드를 복원한 후 애플리케이션에 필요하지 않은 임시 파일이나 애플리케이션 상태를 삭제하여 크기를 줄입니다.
기본 whole-pod 스냅샷 범위를 사용하면 GKE Sandbox는 다음을 포함하여 모든 컨테이너의 전체 상태를 캡처합니다.
- 메모리 및 레지스터와 같은 애플리케이션 상태
- 루트 파일 시스템 및
tmpfs마운트 (emptyDir볼륨 포함) 변경사항 - 열린 파일 설명자, 스레드, 소켓과 같은 커널 상태
스냅샷 크기 최적화는 대규모 언어 모델 (LLM)과 같은 워크로드에 특히 중요합니다. LLM 서버는 모델 가중치를 GPU에 로드하기 전에 로컬 스토리지 (rootfs 또는 tmpfs)에 다운로드하는 경우가 많습니다. 스냅샷을 만들면 GKE Sandbox에서 GPU 상태와 모델 가중치 파일을 모두 저장합니다.
이 시나리오에서 모델이 100GB이면 결과 스냅샷은 약 200GB입니다 (모델 파일 100GB와 GPU 상태를 나타내는 100GB). 애플리케이션이 모델 가중치를 GPU에 로드한 후에는 실행하기 위해 파일 시스템의 파일이 필요하지 않은 경우가 많습니다. 스냅샷을 트리거하기 전에 이러한 모델 파일을 삭제하면 스냅샷 크기를 절반으로 줄이고 지연 시간을 크게 줄여 애플리케이션을 복원할 수 있습니다.
스냅샷 트리거
다음 방법 중 하나를 선택하여 스냅샷을 트리거합니다.
워크로드 트리거: 초기화가 완료된 후와 같이 스냅샷 준비가 완료되었음을 알리도록 애플리케이션을 수정할 수 있는 경우 이 메서드를 사용합니다. 이 방법은 수평 확장 워크로드의 시작 지연 시간을 개선하는 데 가장 적합합니다. 워크로드 트리거는 워크로드 주기에서 한 번만 실행됩니다.
수동 트리거: 준비 상태를 알리도록 애플리케이션을 수정할 수 없거나 특정 포드의 주문형 스냅샷을 원하는 경우 이 방법을 사용합니다. 수동 트리거는 필요한 만큼 만들 수 있습니다.
워크로드에서 스냅샷 트리거
애플리케이션 코드 내에서 스냅샷을 트리거하려면 스냅샷을 만들 준비가 되었을 때 신호를 보내도록 애플리케이션을 구성합니다. 준비 상태를 알리려면 /proc/gvisor/checkpoint 파일에 1 값을 작성합니다(예: echo 1 > /proc/gvisor/checkpoint 명령어 실행). 쓰기 작업은 스냅샷 프로세스를 비동기식으로 시작하고 즉시 반환합니다.
동일한 파일 설명자에서 읽으면 스냅샷 또는 복원 작업이 완료되고 워크로드를 재개할 준비가 될 때까지 읽기 프로세스가 차단됩니다.
워크로드에서 스냅샷을 트리거하기 전에 스냅샷 정책에서 포드를 선택하는지 확인합니다. 해당 정책의 triggerConfig.type 필드 값은 workload로 설정해야 합니다.
정확한 사용법은 애플리케이션에 따라 다르지만 다음 예시에서는 Python 애플리케이션의 스냅샷 트리거를 보여줍니다. 이 예시 워크로드에서 스냅샷을 트리거하려면 다음 단계를 따르세요.
다음 매니페스트를
my-app.yaml로 저장합니다. 이 예시에서app: my-app라벨은 예시 스냅샷 정책의 선택기와 일치하며runtimeClassName: gvisor설정은 GKE Sandbox에서 포드를 실행합니다.apiVersion: v1 kind: Pod metadata: name: my-app namespace: NAMESPACE labels: app: my-app spec: serviceAccountName: SERVICEACCOUNT_NAME runtimeClassName: gvisor containers: - name: my-container image: python:3.10-slim command: ["python3", "-c"] args: - | import time def trigger_snapshot(): try: with open("/proc/gvisor/checkpoint", "r+") as f: f.write("1") res = f.read().rstrip() print(f"GKE Pod Snapshot: {res}") except FileNotFoundError: print("GKE Pod Snapshot file does not exist -- " "Pod Snapshots is disabled") return i = 0 while True: print(f"Count: {i}", flush=True) if (i == 20): # Simulate readiness at the 20th count trigger_snapshot() i += 1 time.sleep(1) resources: limits: cpu: "500m" memory: "512Mi" requests: cpu: "250m" memory: "256Mi"다음을 바꿉니다.
NAMESPACE: 포드의 네임스페이스입니다.SERVICEACCOUNT_NAME: 포드 스냅샷 준비에서 Cloud Storage 액세스 권한을 부여한 ServiceAccount 객체의 이름입니다.
애플리케이션을 배포합니다.
kubectl apply -f my-app.yaml애플리케이션이 시작되고 준비되었다는 신호를 보내면 GKE Sandbox가 스냅샷을 만듭니다. 스냅샷이 성공했는지 확인하려면 스냅샷 확인을 참조하세요.
수동으로 스냅샷 트리거
스냅샷을 수동으로 트리거하기 전에 대상 포드가 실행 중이고 스냅샷 정책이 포드를 선택하는지 확인합니다. 해당 정책의 triggerConfig.type 필드 값은 manual로 설정해야 합니다.
특정 포드에 대해 주문형 스냅샷을 수동으로 트리거하려면 다음 단계에 따라 PodSnapshotManualTrigger 커스텀 리소스를 만듭니다.
다음 매니페스트를
example-manual-trigger.yaml로 저장합니다. 이 예시에서는my-pod이라는 포드의 스냅샷을 트리거합니다.apiVersion: podsnapshot.gke.io/v1 kind: PodSnapshotManualTrigger metadata: name: example-manual-trigger namespace: NAMESPACE spec: targetPod: my-podNAMESPACE를 포드의 네임스페이스로 바꿉니다.매니페스트를 적용합니다.
kubectl apply -f example-manual-trigger.yaml스냅샷이 성공적으로 트리거되었는지 확인하려면 PodSnapshotManualTrigger 커스텀 리소스의
status섹션을 확인합니다.kubectl get podsnapshotmanualtriggers.podsnapshot.gke.io \ example-manual-trigger \ --namespace NAMESPACE -o yamlNAMESPACE를 포드의 네임스페이스로 바꿉니다.트리거가 성공하면
status.conditions필드에 체크포인트가 완료되었음이 표시되고status.snapshotCreated필드에 생성된 PodSnapshot 커스텀 리소스의 이름이 표시됩니다.
스냅샷 확인
GKE가 스냅샷을 만들었는지 확인하려면 GKEPodSnapshotting 이벤트의 활동 내역을 확인합니다.
kubectl get events \
-o custom-columns=NAME:involvedObject.name,CREATIONTIME:.metadata.creationTimestamp,REASON:.reason,MESSAGE:.message \
--namespace NAMESPACE \
--field-selector involvedObject.name=POD_NAME,reason=GKEPodSnapshotting
다음을 바꿉니다.
NAMESPACE: 포드의 네임스페이스입니다.POD_NAME: 포드의 이름입니다.
출력은 다음과 비슷합니다.
NAME CREATIONTIME REASON MESSAGE
default/5b449f9c7c-bd7pc 2025-11-05T16:25:11Z GKEPodSnapshotting Successfully checkpointed the pod to PodSnapshot
MESSAGE 열에 Successfully checkpointed the pod to PodSnapshot가 표시되어 GKE가 포드 상태를 PodSnapshot 커스텀 리소스에 저장했음을 확인합니다. PodSnapshot 커스텀 리소스를 보고 관리하려면 스냅샷 관리를 참조하세요.