AKS(Azure Kubernetes Service) 백업은 AKS 클러스터에서 실행되는 컨테이너화된 애플리케이션 및 데이터를 백업하고 복원하는 데 사용할 수 있는 간단한 클라우드 네이티브 프로세스입니다. CSI(Container Storage 인터페이스) 드라이버 기반 Azure Disk Storage의 Kubernetes 영구 볼륨에 저장된 클러스터 상태 및 애플리케이션 데이터에 대해 예약된 백업을 구성할 수 있습니다.
솔루션은 세분화된 제어를 제공합니다. Blob 컨테이너 및 디스크 스냅샷으로 로컬로 백업을 저장하여 특정 네임스페이스 또는 전체 클러스터를 백업하거나 복원할 수 있습니다. 운영 복구, 개발자 또는 테스트 환경 복제, 클러스터 업그레이드 시나리오 등 엔드투엔드 시나리오에 AKS 백업을 사용할 수 있습니다.
AKS 백업은 Azure의 Backup 센터와 통합되어 대규모 백업을 제어, 모니터링, 운영 및 분석하는 데 도움이 되는 단일 보기를 제공합니다. 백업은 AKS 인스턴스에 대한 서비스 메뉴의 설정 아래 Azure Portal에서도 사용할 수 있습니다.
AKS 백업은 어떻게 작동하나요?
AKS 백업을 사용하여 AKS 클러스터에 배포된 AKS 워크로드 및 영구 볼륨을 백업할 수 있습니다. 이 솔루션을 사용하려면 AKS 클러스터 내에 Backup 확장을 설치해야 합니다. 백업 보관소는 확장 프로그램과 통신하여 백업 및 복원 작업을 완료합니다. 백업 확장을 사용하는 것은 필수입니다. 클러스터에 대한 백업 및 복원을 사용하도록 설정하려면 AKS 클러스터 내에 확장을 설치해야 합니다. AKS 백업을 구성할 때 스토리지 계정 및 백업이 저장되는 Blob 컨테이너에 대한 값을 추가합니다.
Backup 확장과 함께 사용자 ID(확장 ID라고 함)가 AKS 클러스터의 관리되는 리소스 그룹에 만들어집니다. 확장 ID에는 백업이 Blob 컨테이너에 저장되는 스토리지 계정에 스토리지 계정 기여자 역할이 할당됩니다.
공용, 프라이빗 및 권한 있는 IP 기반 클러스터를 지원하려면 AKS 백업을 사용하려면 AKS 클러스터와 Backup 자격 증명 모음 간에 신뢰할 수 있는 액세스 기능을 사용하도록 설정해야 합니다. 신뢰할 수 있는 액세스를 사용하면 백업 작업을 위해 특정 권한이 할당되므로 Backup 자격 증명 모음에서 AKS 클러스터에 액세스할 수 있습니다. AKS 신뢰할 수 있는 액세스에 대한 자세한 내용은 신뢰할 수 있는 액세스를 사용하여 Azure 리소스가 AKS 클러스터에 액세스하도록 설정을 참조하세요.
AKS 백업을 사용하면 운영 티어와 볼트 티어 모두에 백업을 저장할 수 있습니다. 운영 계층은 로컬 데이터 저장소입니다(백업은 테넌트에 스냅샷으로 저장됨). 이제 AKS 백업을 사용하여 하루에 하나의 복구 지점을 이동하여 테넌트 외부의 Blob으로 공동 저장소 계층에 저장할 수 있습니다. Vault 계층에 저장된 백업을 사용하여 Azure 연결이 된 보조 지역에서 데이터를 복원할 수도 있습니다.
백업 확장을 설치하고 신뢰할 수 있는 액세스를 사용하도록 설정한 후 백업 정책에 따라 클러스터에 대해 예약된 백업을 구성할 수 있습니다. 백업을 원래 클러스터 또는 동일한 구독 및 지역의 다른 클러스터로 복원할 수도 있습니다. 특정 작업을 설정할 때 백업 및 복원 구성으로 특정 네임스페이스 또는 전체 클러스터를 선택할 수 있습니다.
AKS 백업을 사용하면 클러스터에 배포된 AKS 데이터 원본에 대한 백업 작업을 수행할 수 있습니다. 또한 클러스터의 영구 볼륨에 저장된 데이터에 대한 백업 작업을 사용하도록 설정합니다. 그런 다음, Blob 컨테이너에 백업을 저장합니다. 디스크 기반 영구 볼륨은 스냅샷 리소스 그룹에서 디스크 스냅샷으로 백업됩니다. Blob의 스냅샷과 클러스터 상태가 결합하여 테넌트에 저장되는 복구 지점인 운영 계층을 형성합니다. 운영 계층에서 백업(일, 주, 월 또는 연도의 첫 번째 성공적인 백업)을 Blob으로 변환한 다음 하루에 한 번 자격 증명 모음(테넌트 외부)으로 이동할 수도 있습니다.
참고
현재 Azure Backup은 CSI 드라이버 기반 Azure Disk Storage에서 영구 볼륨만 지원합니다. 백업하는 동안 솔루션은 Azure Files 공유 및 Blob과 같은 다른 영구 볼륨 유형을 건너뜁니다. 또한 Vault 계층에 대해 정의된 보존 규칙을 설정한 경우, 영구 볼륨이 1TB 이하일 때에만 백업이 Vault로 이동할 수 있습니다.
백업 구성
AKS 클러스터에 대한 백업을 구성하려면 먼저 Backup 자격 증명 모음을 만듭니다. 저장소는 다양한 데이터 소스에 걸쳐 구성된 백업의 통합 보기를 제공합니다. AKS 백업은 운영 계층과 자격 증명 모음 계층 모두에 대한 백업을 지원합니다.
백업 볼트 스토리지 중복 설정(로컬 중복 스토리지 또는 지리적 중복 스토리지)은 볼트 계층에 저장된 백업에만 적용됩니다. 재해 복구에 백업을 사용하려면 지역 간 복원을 사용하도록 설정된 GRS로 스토리지 중복성을 설정합니다.
참고
백업 또는 복원하려는 Backup 자격 증명 모음 및 AKS 클러스터는 동일한 지역 및 구독에 있어야 합니다.
AKS 백업은 예약된 백업 작업을 자동으로 트리거합니다. 작업은 클러스터 리소스를 Blob 컨테이너에 복사하고 백업 빈도에 따라 디스크 기반 영구 볼륨의 증분 스냅샷을 만듭니다. 백업은 백업 정책에 정의된 보존 기간에 따라 운영 계층 및 Vault 계층에 저장됩니다. 기간이 끝나면 백업이 삭제됩니다.
AKS 백업을 사용하여 백업 인스턴스마다 다른 백업 구성을 사용하여 단일 AKS 클러스터에 대한 여러 백업 인스턴스를 만들 수 있습니다. 그러나 다음 두 가지 방법 중 하나로 AKS 클러스터의 각 백업 인스턴스를 만드는 것이 좋습니다.
- 다른 백업 보관소에서
- 별도의 백업 정책을 사용하여 동일한 Backup 볼트에서
백업 관리
AKS 클러스터에 대한 백업 구성이 완료되면 백업 자격 증명 모음에 백업 인스턴스가 만들어집니다. Azure Portal의 AKS 인스턴스에 대한 Backup 섹션에서 클러스터에 대한 백업 인스턴스를 볼 수 있습니다. 해당 백업 인스턴스를 통해 복원 시작, 모니터링, 보호 중지 등과 같은 인스턴스에 대한 모든 백업 관련 작업을 수행할 수 있습니다.
또한 AKS 백업은 Backup 센터와 직접 통합되어 모든 AKS 클러스터 및 기타 백업 지원 워크로드에 대한 보호를 중앙에서 관리할 수 있습니다. 백업 센터는 모니터링 작업 및 백업 및 복원 상태와 같은 모든 백업 요구 사항에 대한 단일 보기를 제공합니다. Backup 센터는 규정 준수 및 거버넌스를 보장하고, 백업 사용을 분석하고, 데이터 백업 및 복원을 위한 중요한 작업을 수행하는 데 도움이 됩니다.
AKS 백업은 관리 ID를 사용하여 다른 Azure 리소스에 액세스합니다. AKS 클러스터의 백업을 구성하고 이전 백업에서 복원하려면 Backup 자격 증명 모음의 관리 ID에 AKS 클러스터에 대한 사용 권한 집합이 필요합니다. 또한 스냅샷이 만들어지고 관리되는 스냅샷 리소스 그룹에 대한 권한 집합이 필요합니다. 현재 AKS 클러스터에는 스냅샷 리소스 그룹에 대한 권한 집합이 필요합니다.
또한 Backup 확장은 사용자 ID를 만들고 백업이 Blob에 저장되는 스토리지 계정에 액세스할 수 있는 권한 집합을 할당합니다. Azure 역할 기반 액세스 제어를 사용하여 관리 ID에 권한을 부여할 수 있습니다. 관리 ID는 Azure 리소스에만 사용할 수 있는 특수 형식의 서비스 주체입니다. 관리 ID에 대해 자세히 알아보세요.
백업에서 복구
복구 지점이 있는 특정 지점에서 데이터를 복원할 수 있습니다. 백업 인스턴스가 보호된 상태일 때 복구 지점이 만들어집니다. 백업 정책이 데이터를 유지할 때까지 데이터를 복원하는 데 사용할 수 있습니다.
Azure Backup은 백업된 모든 항목을 복원하거나 세분화된 컨트롤을 사용하여 네임스페이스 및 기타 필터 옵션을 사용하여 백업에서 특정 항목을 선택하는 옵션을 제공합니다. 또한 원래 AKS 클러스터(백업된 클러스터) 또는 대체 AKS 클러스터에서 복원을 수행할 수 있습니다. 운영 계층 및 자격 증명 모음 계층에 저장된 백업을 동일하거나 다른 구독의 클러스터로 복원할 수 있습니다. 저장소 계층에 위치한 백업만 다른 지역(Azure 연동 지역)의 클러스터로 복원하는 데 사용할 수 있습니다.
Vault 계층에 저장된 백업을 복원하려면 백업 데이터를 복구할 스테이징 위치를 제공해야 합니다. 이 준비 위치에는 복원을 위한 대상 클러스터와 동일한 지역 및 구독 내의 리소스 그룹 및 스토리지 계정이 포함됩니다. 복원하는 동안 특정 리소스(Blob 컨테이너, 디스크 및 디스크 스냅샷)가 하이드레이션 프로세스의 일부로 생성됩니다. 복원 작업이 완료된 후에 지워집니다.
AKS용 Azure Backup은 현재 리소스 충돌이 발생하는 시나리오에 대해 다음 두 가지 옵션을 지원합니다. 백업된 리소스의 이름이 대상 AKS 클러스터의 리소스와 동일한 경우 리소스 충돌이 발생합니다. 복원 구성을 정의할 때 이러한 옵션 중 하나를 선택할 수 있습니다.
건너뛰기: 이 옵션은 기본적으로 선택되어 있습니다. 예를 들어 명명된
pvc-azurediskPVC(영구 볼륨 클레임)를 백업하고 이름이 같은 PVC가 있는 대상 클러스터에서 복원하는 경우 백업 확장은 백업된 PVC의 복원을 건너뜁니다. 이러한 시나리오에서는 클러스터에서 리소스를 삭제하는 것이 좋습니다. 그런 다음 백업된 항목이 클러스터에서만 사용할 수 있고 건너뛰지 않도록 복원 작업을 수행합니다.패치: 이 옵션을 사용하면 대상 클러스터의 리소스에 있는 백업된 리소스에서 변경 가능한 변수를 패치할 수 있습니다. 대상 클러스터의 복제본 수를 업데이트하려는 경우 패치를 작업으로 선택할 수 있습니다.
참고
AKS 백업은 현재 대상 클러스터에 이미 있는 경우 리소스를 삭제하고 다시 만들지 않습니다. 원래 위치에서 영구 볼륨을 복원하려는 경우 기존 영구 볼륨을 삭제한 다음, 복원 작업을 수행합니다.
백업 및 복원에 사용자 지정 후크 사용
사용자 지정 후크를 사용하여 컨테이너화된 워크로드로 배포된 데이터베이스에 사용되는 볼륨의 애플리케이션 일치 스냅샷을 만들 수 있습니다.
사용자 지정 후크란?
AKS 백업을 사용하여 백업 및 복원 작업의 일부로 사용자 지정 후크를 실행할 수 있습니다. 후크는 백업 작업 중 또는 복원 후 컨테이너 아래의 Pod에서 실행하도록 하나 이상의 명령을 실행하도록 구성됩니다.
이러한 후크를 사용자 지정 리소스로 정의하고 백업 또는 복원하려는 AKS 클러스터에 배포합니다. 필요한 네임스페이스의 AKS 클러스터에 사용자 지정 리소스를 배포하는 경우 백업 및 복원을 구성하는 흐름에 대한 입력으로 세부 정보를 제공합니다. Backup 확장은 YAML 파일에 정의된 대로 후크를 실행합니다.
참고
후크는 컨테이너의 셸에서 실행되지 않습니다.
AKS의 백업에는 다음 두 가지 유형의 후크가 있습니다.
- 백업 후크
- 복원 후크
백업 후크
백업 후크를 사용하는 경우 사용자 지정 작업 처리(PreHooks)전에 후크를 실행하도록 명령을 구성할 수 있습니다. 또한 모든 사용자 지정 작업이 완료되고 사용자 지정 작업으로 지정된 추가 항목이 백업(PostHooks)된 후크를 실행할 수도 있습니다.
예를 들어 백업 후크를 사용하여 배포할 사용자 지정 리소스에 대한 YAML 템플릿은 다음과 같습니다.
apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: BackupHook
metadata:
# BackupHook CR Name and Namespace
name: bkphookname0
namespace: default
spec:
# BackupHook is a list of hooks to execute before and after backing up a resource.
backupHook:
# BackupHook Name. This is the name of the hook that will be executed during backup.
# compulsory
- name: hook1
# Namespaces where this hook will be executed.
includedNamespaces:
- hrweb
excludedNamespaces:
labelSelector:
# PreHooks is a list of BackupResourceHooks to execute prior to backing up an item.
preHooks:
- exec:
# Container is the container in the pod where the command should be executed.
container: webcontainer
# Command is the command and arguments to execute.
command:
- /bin/uname
- -a
# OnError specifies how Velero should behave if it encounters an error executing this hook
onError: Continue
# Timeout is the amount of time to wait for the hook to complete before considering it failed.
timeout: 10s
- exec:
command:
- /bin/bash
- -c
- echo hello > hello.txt && echo goodbye > goodbye.txt
container: webcontainer
onError: Continue
# PostHooks is a list of BackupResourceHooks to execute after backing up an item.
postHooks:
- exec:
container: webcontainer
command:
- /bin/uname
- -a
onError: Continue
timeout: 10s
복원 후크
복원 후크 스크립트에서 사용자 지정 명령 또는 스크립트는 복원된 AKS Pod의 컨테이너에서 실행되도록 작성됩니다.
복원 후크를 통해 배포되는 사용자 지정 리소스에 대한 YAML 템플릿은 다음과 같습니다.
apiVersion: clusterbackup.dataprotection.microsoft.com/v1alpha1
kind: RestoreHook
metadata:
name: restorehookname0
namespace: default
spec:
# RestoreHook is a list of hooks to execute after restoring a resource.
restoreHook:
# Name is the name of this hook.
- name: myhook-1
# Restored Namespaces where this hook will be executed.
includedNamespaces:
excludedNamespaces:
labelSelector:
# PostHooks is a list of RestoreResourceHooks to execute during and after restoring a resource.
postHooks:
- exec:
# Container is the container in the pod where the command should be executed.
container: webcontainer
# Command is the command and arguments to execute from within a container after a pod has been restored.
command:
- /bin/bash
- -c
- echo hello > hello.txt && echo goodbye > goodbye.txt
# OnError specifies how Velero should behave if it encounters an error executing this hook
# default value is Continue
onError: Continue
# Timeout is the amount of time to wait for the hook to complete before considering it failed.
execTimeout: 30s
# WaitTimeout defines the maximum amount of time Velero should wait for the container to be ready before attempting to run the command.
waitTimeout: 5m
AKS 백업 중에 후크를 사용하는 방법을 알아봅니다.
복원하는 동안 백업 확장은 컨테이너가 올 때까지 기다린 다음 복원 후크에 정의된 exec 명령을 실행합니다.
백업된 동일한 네임스페이스로 복원을 수행하는 경우 복원 후크가 실행되지 않습니다. 새로 생성된 컨테이너만을 찾습니다. 이 결과는 건너뛰기 또는 패치 정책을 사용하는지 여부에 관계없이 발생합니다.
AKS 클러스터에 백업을 복원하는 동안 리소스 수정
리소스 수정 기능을 사용하여 AKS 클러스터에 배포된 JSONconfigmap 패치를 지정하여 복원 중에 백업된 Kubernetes 리소스를 수정할 수 있습니다.
복원 중에 리소스 한정자 configmap 만들기 및 적용
리소스 수정을 만들고 적용하려면 다음 단계를 따릅니다.
리소스 한정자를 만듭니다
configmap.당신이 선호하는 네임스페이스에 리소스 한정자를 정의한
configmap파일로부터 하나의 을(를) 만들어야 합니다.명령을 만드는 예제:
version: v1 resourceModifierRules: - conditions: groupResource: persistentvolumeclaims resourceNameRegex: "^mysql.*$" namespaces: - bar - foo labelSelector: matchLabels: foo: bar patches: - operation: replace path: "/spec/storageClassName" value: "premium" - operation: remove path: "/metadata/labels/test"- 이전
configmap에서는 막대의 모든 영구 볼륨 복사본에namespaces패치를 적용하고, 이름이foo및mysql으로 시작하는match label foo: bar에 적용합니다. JSON 패치는 영구 볼륨 복사본에서storageClassName을premium으로 대체하고test레이블을 제거합니다. - 여기서는
namespace리소스가 복원될 새 네임스페이스가 아니라 백업된 리소스의 원래 네임스페이스입니다. - 특정 리소스에 대해 여러 JSON 패치를 지정할 수 있습니다. 패치는 에 지정된
configmap순서에 따라 적용됩니다. 다음 패치가 순서대로 적용됩니다. 동일한 경로에 대해 여러 패치가 지정된 경우 마지막 패치가 이전 패치를 재정의합니다. -
resourceModifierRules에서 여러configmap를 지정할 수 있습니다. 규칙은 에 지정된configmap순서에 따라 적용됩니다.
- 이전
복원 구성에서 리소스 한정자 참조 만들기
복원 작업을 수행할 때, 복원 구성의 일환으로 배포되는 위치인
ConfigMap name및namespace을 제공합니다. 이러한 세부 정보는 리소스 한정자 규칙에 제공되어야 합니다.
리소스 한정자가 지원하는 작업
추가
추가 작업을 사용하여 리소스 JSON에 새 블록을 추가할 수 있습니다. 다음 예제에서 작업은 배포를 사용하여 사양에 새 컨테이너 세부 정보를 추가합니다.
version: v1 resourceModifierRules: - conditions: groupResource: deployments.apps resourceNameRegex: "^test-.*$" namespaces: - bar - foo patches: # Dealing with complex values by escaping the yaml - operation: add path: "/spec/template/spec/containers/0" value: "{\"name\": \"nginx\", \"image\": \"nginx:1.14.2\", \"ports\": [{\"containerPort\": 80}]}"제거
제거 작업을 사용하여 리소스 JSON에서 키를 제거할 수 있습니다. 다음 예제에서는
test키를 가진 레이블을 제거하는 작업이 수행됩니다.version: v1 resourceModifierRules: - conditions: groupResource: persistentvolumeclaims resourceNameRegex: "^mysql.*$" namespaces: - bar - foo labelSelector: matchLabels: foo: bar patches: - operation: remove path: "/metadata/labels/test"바꾸기
바꾸기 작업을 사용하여 대체 경로에 언급된 경로의 값을 바꿀 수 있습니다. 다음 예제에서 작업은 PVC의
storageClassName를premium로 바꿉니다.version: v1 resourceModifierRules: - conditions: groupResource: persistentvolumeclaims resourceNameRegex: "^mysql.*$" namespaces: - bar - foo labelSelector: matchLabels: foo: bar patches: - operation: replace path: "/spec/storageClassName" value: "premium"복사
복사 작업을 사용하여 정의된 리소스의 한 경로에서 다른 경로로 값을 복사할 수 있습니다.
version: v1 resourceModifierRules: - conditions: groupResource: deployments.apps resourceNameRegex: "^test-.*$" namespaces: - bar - foo patches: - operation: copy from: "/spec/template/spec/containers/0" path: "/spec/template/spec/containers/1"테스트
테스트 작업을 사용하여 리소스에 특정 값이 있는지 확인할 수 있습니다. 값이 있으면 패치가 적용됩니다. 값이 없으면 패치가 적용되지 않습니다. 다음 예제에서는 작업이 PVC가
premium처럼StorageClassName로 되어 있는지 확인하고, 조건이 참이면 그것을standard로 바꿉니다.version: v1 resourceModifierRules: - conditions: groupResource: persistentvolumeclaims resourceNameRegex: ".*" namespaces: - bar - foo patches: - operation: test path: "/spec/storageClassName" value: "premium" - operation: replace path: "/spec/storageClassName" value: "standard"JSON 패치
기본적으로 네임스페이스 내의 모든 배포에 JSON 패치를 적용하며, 이름이
configmap로 시작하는 경우에는nginx를 사용합니다. JSON 패치는 이러한 모든 배포에12대한 복제본 수를 업데이트합니다.version: v1 resourceModifierRules: - conditions: groupResource: deployments.apps resourceNameRegex: "^nginxdep.*$" namespaces: - default - nginx patches: - operation: replace path: "/spec/replicas" value: "12"JSON 병합 패치
이
configmap는 JSON 병합 패치를 네임스페이스 default와nginx의,nginxdep로 시작하는 이름을 가진 모든 배포에 적용합니다. JSON 병합 패치는 레이블app을 값nginx1으로 추가하거나 업데이트합니다.version: v1 resourceModifierRules: - conditions: groupResource: deployments.apps resourceNameRegex: "^nginxdep.*$" namespaces: - default - nginx mergePatches: - patchData: | { "metadata" : { "labels" : { "app" : "nginx1" } } }전략적 병합 패치
네임스페이스 default에 있는 모든 Pod에 전략적 병합 패치를 적용하며, 이름이
configmap로 시작하는 Pod들에 적용됩니다. 전략적 병합 패치는 컨테이너nginxmcr.microsoft.com/cbl-mariner/base/nginx:1.22이미지를 업데이트합니다.version: v1 resourceModifierRules: - conditions: groupResource: pods resourceNameRegex: "^nginx.*$" namespaces: - default strategicPatches: - patchData: | { "spec": { "containers": [ { "name": "nginx", "image": "mcr.microsoft.com/cbl-mariner/base/nginx:1.22" } ] } }
AKS 백업은 어떤 백업 스토리지 계층을 지원하나요?
AKS용 Azure Backup은 다음 두 개의 스토리지 계층을 백업 데이터 저장소로 지원합니다.
운영 계층: AKS 클러스터에 설치된 백업 확장은 먼저 CSI 드라이버를 통해 볼륨 스냅샷을 만들어 백업을 수행합니다. 그런 다음 클러스터 상태를 사용자 고유의 테넌트에 있는 Blob 컨테이너에 저장합니다. 이 계층은 두 백업 사이의 최소 4시간 동안의 낮은 RPO(복구 지점 목표)를 지원합니다. 또한 Azure 디스크 기반 볼륨의 경우 운영 계층은 더 빠른 복원을 지원합니다.
보관소 계층: 스냅샷보다 저렴한 비용으로 더 긴 기간 동안 백업 데이터를 저장하려면 AKS 백업은 보관소 표준 데이터 저장소를 지원합니다. 백업 정책에 설정된 보존 규칙에 따라 첫 번째 성공적인 백업(일, 주, 월 또는 연도)이 테넌트 외부의 Blob 컨테이너로 이동됩니다. 이 데이터 저장소는 더 긴 보존을 허용할 뿐만 아니라 랜섬웨어 보호도 제공합니다. 백업 보관소에서 지리적 중복 및 지역 간에 복원을 사용하도록 설정하여 복구를 위해 보관소에 저장된 백업을 다른 지역(Azure 페어링 지역)으로 이동할 수도 있습니다.
참고
보존 규칙을 정의하여 Backup 정책을 통해 자격 증명 모음 표준 데이터 저장소에 백업 데이터를 저장할 수 있습니다. 하루에 하나의 예약된 복구 지점만 보관소 계층으로 이동됩니다. 그러나 선택한 규칙에 따라 임의의 수의 주문형 백업을 저장소로 이동할 수 있습니다.
가격 책정 이해
다음에 대해 요금이 부과됩니다.
보호된 인스턴스 요금: AKS용 Azure Backup은 매월 네임스페이스당 보호된 인스턴스 요금을 청구합니다. AKS 클러스터에 대한 백업을 구성하면 보호된 인스턴스가 만들어집니다. 각 인스턴스에는 백업 구성에 정의된 대로 백업되는 특정 수의 네임스페이스가 있습니다. AKS 백업 가격 책정에 대한 자세한 내용은 Azure 백업에 대한 가격 책정 을 참조하고 워크로드로 Azure Kubernetes Service를 선택합니다.
스냅샷 요금: AKS용 Azure Backup은 Azure 구독의 리소스 그룹에 저장된 스냅샷을 만들어 디스크 기반 영구 볼륨을 보호합니다. 이러한 스냅샷에는 스냅샷 스토리지 요금이 발생합니다. 스냅샷이 백업 볼트에 복사되지 않으므로 백업 스토리지 비용은 적용되지 않습니다. 스냅샷 가격 책정에 대한 자세한 내용은 Managed Disks 가격 책정을 참조하세요.
백업 스토리지 요금: AKS용 Azure Backup은 보관 계층에 백업 저장도 지원합니다. 백업 정책에서 표준 볼트에 대한 보존 규칙을 정의하여 볼트 계층에 백업을 저장할 수 있으며, 하루에 하나의 복원 지점이 볼트로 이동할 수 있습니다. 보관 계층에 저장된 복구 지점에는 백업 보관함에 저장된 총 데이터(기가바이트 단위)와 활성화된 중복 방식의 유형에 따라 별도의 요금(백업 스토리지 요금)이 청구됩니다.