본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

Trident Protect를 사용하여 vSphere Kubernetes Service 클러스터의 컨테이너 애플리케이션을 백업하고 복원합니다

09/15/2026 기여자

Trident Protect 스냅샷 및 백업을 사용하여 vSphere Kubernetes Service(VKS) 클러스터의 컨테이너 애플리케이션을 백업하고 복원합니다. 이 절차에는 ONTAP S3 오브젝트 스토리지를 사용하여 AppVault를 생성하고, Kubernetes 리소스 오브젝트 및 영구 볼륨을 포함한 애플리케이션 데이터를 캡처하도록 Trident Protect를 구성하고, 필요할 때 데이터를 복원하는 과정이 포함됩니다.

VKS 클러스터에서 실행되는 컨테이너 애플리케이션은 워커 노드 네임스페이스의 Kubernetes 워크로드로 관리됩니다. 애플리케이션 메타데이터와 영구 볼륨을 모두 보호하는 것이 중요합니다. 손실되거나 손상된 경우 복구할 수 있어야 하기 때문입니다.

VKS 애플리케이션의 영구 볼륨은 "Trident CSI"을 사용하여 VKS 클러스터와 통합된 ONTAP 스토리지를 기반으로 할 수 있습니다. 이 절차는 "Trident Protect"를 사용하여 애플리케이션 스냅샷을 생성하며, 스냅샷의 메타데이터는 ONTAP 오브젝트 스토리지에 저장되고 볼륨 스냅샷 데이터는 스토리지 백엔드에 유지됩니다. 또한 백업의 경우 데이터가 ONTAP 오브젝트 스토리지에 복사됩니다. 필요에 따라 스냅샷 또는 백업에서 복원할 수 있습니다.

Trident Protect는 Kubernetes 클러스터에서 실행되는 애플리케이션의 스냅샷, 백업, 복원 및 재해 복구를 지원합니다. Trident Protect로 보호할 수 있는 데이터에는 애플리케이션과 연결된 Kubernetes 리소스 오브젝트 및 해당 영구 볼륨이 포함됩니다.

다음은 이 섹션의 예제에 사용된 다양한 구성 요소의 버전입니다

vSphere Kubernetes Service가 포함된 VMware Cloud Foundation (VCF) 9.1
"Trident 26.06"
"Trident Protect 26.06"
"ONTAP 9.16"

vSphere Kubernetes 클러스터에 Trident Protect 설치

Trident Protect를 설치합니다

Helm을 사용하여 vSphere Kubernetes Service 클러스터에 Trident Protect를 설치합니다. 이 섹션의 예제에서는 tridentctl-protect, Trident Protect CLI를 사용합니다. "Trident Protect CLI 설명서"의 지침에 따라 설치하십시오. Trident Protect를 설치하는 추가 방법은 "Trident Protect 문서"에 설명되어 있습니다.

먼저 trident-protect 네임스페이스를 생성하고 레이블을 지정합니다. enforce=privileged 레이블은 Trident Protect가 권한 있는 워크로드를 실행하기 때문에 필요합니다. 레이블이 없으면 Kubernetes Pod 보안 승인 컨트롤러가 Trident Protect Pod의 시작을 차단합니다.

kubectl create namespace trident-protect
kubectl label namespace trident-protect pod-security.kubernetes.io/enforce=privileged

다음으로 Helm 저장소를 추가하고 Trident Protect를 네임스페이스에 설치합니다.

helm repo add netapp-trident-protect https://netapp.github.io/trident-protect-helm-chart
helm install trident-protect netapp-trident-protect/trident-protect --set clusterName=<name-of-cluster> --version 100.2606.0 --namespace trident-protect

Trident Protect Pod가 PodSecurity 승인 오류와 함께 시작되지 않는 경우, 설치 전에 trident-protect 네임스페이스에 Pod 보안 레이블이 적용되지 않았을 수 있습니다. `--overwrite`을 사용하여 레이블을 다시 적용한 다음 Pod가 시작되는지 확인하십시오.

kubectl label namespace trident-protect pod-security.kubernetes.io/enforce=privileged --overwrite

kubectl get pods -n trident-protect

오브젝트 스토리지용 앱 볼트 생성

AppVault 생성

애플리케이션의 스냅샷 및 백업을 생성하기 전에 Trident Protect에서 오브젝트 스토리지를 구성해야 합니다. 이는 AppVault CR을 생성하여 수행합니다. AppVault CR은 관리자만 생성하고 구성할 수 있습니다.

AppVault 오브젝트는 스토리지 버킷을 Kubernetes 사용자 정의 리소스로 표현한 것입니다. AppVault CR에는 백업, 스냅샷, 복원 작업 및 SnapMirror 복제 등 보호 작업에 버킷을 사용하는 데 필요한 구성이 포함되어 있습니다.

다음 단계에서는 ONTAP S3용으로 구성된 AppVault CR을 생성합니다. . ONTAP 클러스터의 SVM에 S3 오브젝트 스토어 서버를 생성합니다. . 오브젝트 스토어 서버에 버킷을 생성합니다. . SVM에 S3 사용자를 생성합니다. 액세스 키와 비밀 키를 안전한 위치에 보관하십시오.

+ 참고: Trident Protect를 사용하려면 S3 사용자에게 최소한 PutObject, GetObject, ListBucket 및 DeleteObject 권한이 있어야 합니다. 이러한 권한이 없으면 AppVault 백업 및 복원 작업이 액세스 거부 오류와 함께 실패합니다. 자세한 내용은 "Trident Protect AppVault 문서"을 참조하십시오. . VKS 클러스터에서 ONTAP S3 자격 증명을 저장할 시크릿을 생성합니다. . ONTAP S3용 AppVault 오브젝트를 생성합니다.

ONTAP S3용 Trident Protect AppVault 구성

아래 매니페스트는 프로덕션 환경에 필요한 인증서 유효성 검사가 활성화된 HTTPS를 사용합니다. ONTAP S3 엔드포인트가 클러스터에서 이미 신뢰하는 공용 CA에서 서명한 인증서를 사용하는 경우 추가 인증서 구성이 필요하지 않습니다. 자체 서명 인증서 또는 내부 CA 인증서를 사용하는 경우 매니페스트에 표시된 대로 rootCA 필드를 사용하여 사용자 지정 루트 CA 인증서를 제공하십시오. 격리된 비프로덕션 테스트를 위한 HTTP 구성이 필요한 경우 이 섹션 끝에 있는 랩 전용 버전을 참조하십시오.

# alias tp='tridentctl-protect'

# cat appvault-secret.yaml
apiVersion: v1
data:
  accessKeyID: <base64 encoded access key>
  secretAccessKey: <base64 encoded secret access key>
# Alternatively, remove the data section above and use:
# stringData:
#   accessKeyID: "<access key of S3>"
#   secretAccessKey: "<secret access key of S3>"
kind: Secret
metadata:
  name: ontap-s3-appvault-secret1
  namespace: trident-protect
type: Opaque

# cat appvault.yaml
apiVersion: protect.trident.netapp.io/v1
kind: AppVault
metadata:
  name: ontap-s3-appvault1
  namespace: trident-protect
spec:
  providerConfig:
    azure:
      accountName: ""
      bucketName: ""
      endpoint: ""
    gcp:
      bucketName: ""
      projectID: ""
    s3:
      bucketName: trident-protect
      endpoint: <lif for S3 access>
      secure: "true"
      skipCertValidation: "false"
      # If your ONTAP S3 endpoint uses a certificate signed by a public CA
      # already trusted by the cluster, no additional certificate config is needed.
      # If it uses a self-signed or internal CA certificate, provide the
      # root CA certificate:
      # rootCA: <root CA certificate>
  providerCredentials:
    accessKeyID:
      valueFromSecret:
        key: accessKeyID
        name: ontap-s3-appvault-secret1
    secretAccessKey:
      valueFromSecret:
        key: secretAccessKey
        name: ontap-s3-appvault-secret1
  providerType: OntapS3

# kubectl create -f appvault-secret.yaml -n trident-protect
# kubectl create -f appvault.yaml -n trident-protect

랩 전용 변형(HTTP, 인증서 검증 없음)

다음 s3 설정은 민감한 데이터가 없는 격리된 실험실 환경에서만 사용하십시오. 실제 운영 환경에서는 이러한 설정을 사용하지 마십시오.

    s3:
      bucketName: trident-protect
      endpoint: <lif for S3 access>
      secure: "false"
      skipCertValidation: "true"

Trident Protect 애플리케이션 생성

이 예제는 postgres 네임스페이스에 설치된 샘플 PostgreSQL 애플리케이션의 데이터 보호에 대해 설명합니다. 설치에 대한 자세한 내용은 "NetApp 스토리지를 사용하여 VKS 워크로드 배포"을 참조하십시오.

샘플 PostgreSQL PVC는 RWO 액세스 모드를 요청합니다. 액세스 모드는 PVC 매니페스트에 명시적으로 지정해야 합니다. Trident는 스토리지 프로토콜을 기반으로 액세스 모드를 자동으로 선택하지 않습니다. NAS 기반 PVC의 경우 RWX가 지원되며, SAN 기반 PVC는 추가 구성을 통해 RWX를 지원할 수 있습니다. 자세한 내용은 "Trident Protect 문서"을 참조하십시오.

이 예시에서 postgres 네임스페이스에는 하나의 애플리케이션이 있으며, Trident Protect 애플리케이션을 생성할 때 해당 네임스페이스의 모든 리소스가 포함됩니다.

# alias tp='tridentctl-protect'
# tp create app postgres-app --namespaces postgres -n postgres --dry-run > postgres-app.yaml

# cat postgres-app.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Application
metadata:
  name: postgres-app
spec:
  includedNamespaces:
  - namespace: postgres
  resourceFilter: {}
# kubectl create -f postgres-app.yaml -n postgres

백업을 생성하여 앱을 보호합니다

백업 생성

필요에 따라 백업 생성

이전에 생성한 postgres-app의 백업을 생성합니다. 이 백업에는 postgres 네임스페이스의 모든 리소스가 포함됩니다. 백업이 저장될 appvault 이름을 입력하십시오.

# cat postgres-backup-on-demand.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Backup
metadata:
  name: postgres-backup-on-demand
spec:
  appVaultRef: ontap-s3-appvault1
  applicationRef: postgres-app
  cleanupSnapshot: true
  replicateSnapshot: false

kubectl create -f postgres-backup-on-demand.yaml -n postgres

예약된 시간에 백업 생성

백업 일정을 생성하고, 백업의 세분성 및 보존할 백업 개수를 지정하십시오.

# tp create schedule backup-schedule1 --app postgres-app --appvault ontap-s3-appvault1 --granularity Hourly --minute 45 --backup-retention 1 -n postgres --dry-run>postgres-backup-schedule1.yaml

#cat postgres-backup-schedule1.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  name: backup-schedule1
  namespace: postgres
spec:
  appVaultRef: ontap-s3-appvault1
  applicationRef: postgres-app
  backupRetention: "1"
  dayOfMonth: ""
  dayOfWeek: ""
  enabled: true
  granularity: Hourly
  hour: ""
  minute: "45"
  recurrenceRule: ""
  replicationRetention: "0"
  runImmediately: false
  snapshotRetention: "0"
# kubectl create -f postgres-backup-schedule1.yaml -n postgres

백업에서 복원

애플리케이션을 동일한 네임스페이스로 복원합니다

이 예시에서 postgres-backup-on-demand 백업에는 postgres-app의 백업이 포함되어 있습니다.

애플리케이션을 삭제하기 전에 복원하려는 백업이 Completed 상태인지 확인하십시오. 진행 중이거나 실패한 백업은 애플리케이션을 복원하는 데 사용할 수 없습니다.

kubectl get backup -n postgres

백업 상태가 `Completed`인지 확인한 후 postgres 애플리케이션을 삭제하고 "postgres" 네임스페이스에서 PVC 및 Pod 오브젝트가 삭제되었는지 확인하십시오.

이제 제자리 백업 복원 오브젝트를 생성합니다.

# tp create bir postgres-app-restore --backup postgres/postgres-backup-on-demand -n postgres --dry-run>postgres-app-bir.yaml

# cat postgres-app-bir.yaml
apiVersion: protect.trident.netapp.io/v1
kind: BackupInplaceRestore
metadata:
  annotations:
    protect.trident.netapp.io/max-parallel-restore-jobs: "25"
  name: postgres-app-restore
  namespace: postgres
spec:
  appArchivePath: postgres-app_314bbaf6-2ce3-4065-b3c1-ab85c7bb7c7c/backups/postgres-backup-on-demand_63efc9d1-92d7-45ce-84fe-846ce7db7b29
  appVaultRef: ontap-s3-appvault1
  cleanUpAdditionalExecHooks: true
  cleanUpArchivedExecHooks: false
  resourceFilter: {}
  runArchivedExecHooks: true

# kubectl create -f postgres-app-bir.yaml -n postgres

postgres 애플리케이션 배포, 서비스, Pod 및 PVC가 복원되었는지 확인하십시오.

애플리케이션을 다른 네임스페이스로 복원합니다

먼저, 앱을 복원할 새 네임스페이스(이 예에서는 postgres2)를 생성합니다. 예약에 의해 생성된 시간별 백업을 이제 postgres-app에 사용할 수 있습니다. 이 백업을 사용하여 애플리케이션을 새 네임스페이스인 postgres2로 복원합니다.

# tp create backuprestore --appvault ontap-s3-appvault1 --path postgres-app_314bbaf6-2ce3-4065-b3c1-ab85c7bb7c7c/backups/hourly-cbd11-20260831124500_2b57bda9-5cb0-4c8f-ae7a-20f94c23c3b9 --namespace-mapping postgres:postgres2 -n postgres2 --dry-run>postgres-app-postgres2-br.yaml

백업 경로를 얻으려면 명령어 `kubectl get backups <backup-name> -n postgres -o jsonpath='{.status.appArchivePath}'`를 사용하십시오.

apiVersion: protect.trident.netapp.io/v1
kind: BackupRestore
metadata:
  annotations:
    protect.trident.netapp.io/max-parallel-restore-jobs: "25"
  name: postgres-app-z2woek
  namespace: postgres2
spec:
  appArchivePath: postgres-app_314bbaf6-2ce3-4065-b3c1-ab85c7bb7c7c/backups/hourly-cbd11-20260831124500_2b57bda9-5cb0-4c8f-ae7a-20f94c23c3b9
  appVaultRef: ontap-s3-appvault1
  cleanUpAdditionalExecHooks: true
  cleanUpArchivedExecHooks: false
  namespaceMapping:
  - destination: postgres2
    source: postgres
  resourceFilter: {}
  runArchivedExecHooks: true
  skipApplicationCreation: false

# kubectl create -f postgres-app-postgres2-br.yaml -n postgres2

postgres 애플리케이션 오브젝트와 PVC가 새 네임스페이스 postgres2에 생성되었는지 확인하십시오.

스냅샷을 사용하여 앱 보호

스냅샷 생성

필요에 따라 스냅샷 생성 앱의 스냅샷을 생성하고 스냅샷 메타데이터가 저장될 AppVault를 지정합니다. 볼륨 스냅샷 데이터 자체는 오브젝트 스토리지로 복사되지 않고 스토리지 백엔드에 유지됩니다.

# tp create snapshot postgres-app-snapshot-ondemand --app postgres-app --appvault ontap-s3-appvault1 -n postgres --dry-run>postgres-app-snapshot-ondemand.yaml

# cat postgres-app-snapshot-ondemand.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Snapshot
metadata:
  name: postgres-app-snapshot-ondemand
  namespace: postgres
spec:
  appVaultRef: ontap-s3-appvault1
  applicationRef: postgres-app
  cleanupSnapshot: false
  completionTimeout: 0s
  volumeSnapshotsCreatedTimeout: 0s
  volumeSnapshotsReadyToUseTimeout: 0s

# kubectl create -f postgres-app-snapshot-ondemand.yaml
snapshot.protect.trident.netapp.io/postgres-app-snapshot-ondemand created

스냅샷 일정 생성 스냅샷 일정을 생성합니다. 보존할 스냅샷의 세분성 및 개수를 지정합니다.

# tp create schedule snapshot-schedule1 --app postgres-app --appvault ontap-s3-appvault1 --granularity Hourly --minute 55 --snapshot-retention 1 -n postgres --dry-run>postgres-app-snapshot-schedule1.yaml

# cat postgres-app-snapshot-schedule1.yaml
apiVersion: protect.trident.netapp.io/v1
kind: Schedule
metadata:
  name: snapshot-schedule1
  namespace: postgres
spec:
  appVaultRef: ontap-s3-appvault1
  applicationRef: postgres-app
  backupRetention: "0"
  dayOfMonth: ""
  dayOfWeek: ""
  enabled: true
  granularity: Hourly
  hour: ""
  minute: "55"
  recurrenceRule: ""
  replicationRetention: "0"
  runImmediately: false
  snapshotRetention: "1"

# kubectl create -f postgres-app-snapshot-schedule1.yaml
schedule.protect.trident.netapp.io/snapshot-schedule1 created

스냅샷에서 복원

스냅샷에서 애플리케이션을 동일한 네임스페이스로 복원합니다

애플리케이션을 삭제하기 전에 복원하려는 스냅샷이 Completed 상태인지 확인하십시오. 진행 중이거나 실패한 스냅샷으로는 애플리케이션을 복원할 수 없습니다.

kubectl get snapshot -n postgres

스냅샷 상태가 `Completed`인지 확인한 후 postgres 네임스페이스에서 postgres용 애플리케이션 오브젝트와 PVC를 삭제합니다.

스냅샷에서 스냅샷 제자리 복원 오브젝트를 생성합니다.

# tp create sir postgres-restore-from-snapshot --snapshot postgres/hourly-f1dd9-20260831135500 -n postgres --dry-run > postgres-sir.yaml

# cat postgres-sir.yaml
apiVersion: protect.trident.netapp.io/v1
kind: SnapshotInplaceRestore
metadata:
  name: postgres-restore-from-snapshot
  namespace: postgres
spec:
  appArchivePath: postgres-app_314bbaf6-2ce3-4065-b3c1-ab85c7bb7c7c/snapshots/20260831135500_hourly-f1dd9-20260831135500_36c2bd2a-9405-4424-88a7-75e6bbc5b315
  appVaultRef: ontap-s3-appvault1
  cleanUpAdditionalExecHooks: true
  cleanUpArchivedExecHooks: false
  resourceFilter: {}
  runArchivedExecHooks: true

# kubectl create -f postgres-sir.yaml
snapshotinplacerestore.protect.trident.netapp.io/postgres-restore-from-snapshot created

애플리케이션의 오브젝트와 PVC가 postgres 네임스페이스에 생성되었는지 확인하십시오.

스냅샷에서 애플리케이션을 다른 네임스페이스로 복원합니다

이전에 백업에서 복원한 postgres2 네임스페이스의 애플리케이션을 삭제하십시오.

스냅샷에서 스냅샷 복원 오브젝트를 생성하고 네임스페이스 매핑을 제공합니다.

# tp create sr postgres-sr --snapshot postgres/hourly-f1dd9-20260831135500 --namespace-mapping postgres:postgres2 -n postgres2 --dry-run>postgres-sr.yaml

# cat postgres-sr.yaml
apiVersion: protect.trident.netapp.io/v1
kind: SnapshotRestore
metadata:
  name: postgres-sr
  namespace: postgres2
spec:
  appArchivePath: postgres-app_314bbaf6-2ce3-4065-b3c1-ab85c7bb7c7c/snapshots/20260831135500_hourly-f1dd9-20260831135500_36c2bd2a-9405-4424-88a7-75e6bbc5b315
  appVaultRef: ontap-s3-appvault1
  cleanUpAdditionalExecHooks: true
  cleanUpArchivedExecHooks: false
  namespaceMapping:
  - destination: postgres2
    source: postgres
  resourceFilter: {}
  runArchivedExecHooks: true
  skipApplicationCreation: false

# kubectl create -f postgres-sr.yaml
snapshotrestore.protect.trident.netapp.io/postgres-sr created

애플리케이션의 오브젝트와 PVC가 postgres2 네임스페이스에 복원되었는지 확인하십시오.