Azure Kubernetes Service 백업이란?
AKS(Azure Kubernetes Service) 백업은 AKS 클러스터에서 실행되는 컨테이너화된 애플리케이션 및 데이터를 백업하고 복원하는 데 사용할 수 있는 간단한 클라우드 기반 프로세스입니다. CSI 드라이버 기반 Azure Disk Storage의 영구 볼륨에 저장된 클러스터 상태 및 애플리케이션 데이터에 대한 예약된 백업을 구성할 수 있습니다. 이 솔루션은 Blob 컨테이너에 디스크 스냅샷으로 백업을 로컬로 저장하여 백업 또는 복원할 특정 네임스페이스 또는 전체 클러스터를 선택할 수 있는 세부적인 제어 기능을 제공합니다. 운영 복구, 개발자/테스트 환경 복제, 클러스터 업그레이드 시나리오를 포함한 엔드투엔드 시나리오에 AKS 백업을 사용할 수 있습니다.
AKS 백업은 Azure의 Backup 센터와 통합되어 대규모 백업을 제어, 모니터링, 운영 및 분석하는 데 도움이 되는 단일 보기를 제공합니다. 백업은 Azure Portal에서 AKS 인스턴스에 대한 서비스 메뉴의 설정 아래에서도 사용할 수 있습니다.
AKS 백업은 어떻게 작동하나요?
AKS 백업을 사용하여 AKS 클러스터에 배포된 AKS 워크로드 및 영구 볼륨을 백업합니다. 이 솔루션을 사용하려면 AKS 클러스터 내에 Backup 확장을 설치해야 합니다. Backup 자격 증명 모음은 확장과 통신하여 백업 및 복원과 관련된 작업을 완료합니다. Backup 확장은 반드시 사용해야 하며 클러스터에 대한 백업 및 복원을 사용하도록 설정하려면 AKS 클러스터 내에 확장을 설치해야 합니다. AKS 백업을 구성할 때 스토리지 계정 및 백업이 저장되는 Blob 컨테이너에 대한 값을 추가합니다.
Backup 확장과 함께 사용자 ID(확장 ID라고 함)가 AKS 클러스터의 관리되는 리소스 그룹에 만들어집니다. 이 확장 ID는 Blob 컨테이너에 백업이 저장되는 스토리지 계정에 대해 스토리지 계정 기여자 역할이 할당됩니다.
공용, 프라이빗 및 승인된 IP 기반 클러스터를 지원하려면 AKS 백업에서 AKS 클러스터와 Backup 자격 증명 모음 간에 신뢰할 수 있는 액세스를 사용하도록 설정해야 합니다. 신뢰할 수 있는 액세스를 통해 Backup 자격 증명 모음은 백업 작업에 대해 할당된 특정 권한 때문에 AKS 클러스터에 액세스할 수 있습니다. AKS 신뢰할 수 있는 액세스에 대한 자세한 내용은 신뢰할 수 있는 액세스를 사용하여 Azure 리소스가 AKS 클러스터에 액세스하도록 설정을 참조하세요.
참고 항목
AKS 백업을 사용하면 운영 계층에 백업을 저장할 수 있습니다. 운영 계층은 로컬 데이터 저장소입니다(테넌트에서 스냅샷으로 사용). 이제 하루에 하나의 복구 지점을 이동하고 AKS 백업을 사용하여 자격 증명 모음 계층(테넌트 외부)에 Blob으로 저장할 수 있습니다. Backup 자격 증명 모음을 사용하여 백업을 관리할 수도 있습니다.
Backup 확장이 설치되고 신뢰할 수 있는 액세스가 사용하도록 설정되면 백업 정책에 따라 클러스터에 대해 예약된 백업을 구성할 수 있습니다. 또한 백업을 원본 클러스터 또는 동일한 구독 및 지역에 있는 대체 클러스터로 복원할 수 있습니다. 특정 작업을 설정할 때 특정 네임스페이스 또는 전체 클러스터를 백업 및 복원 구성으로 선택할 수 있습니다.
백업 솔루션을 사용하면 클러스터에 배포된 AKS 데이터 원본 및 클러스터의 영구 볼륨에 저장된 데이터에 대해 백업 작업을 수행하고 Blob 컨테이너에 백업을 저장할 수 있습니다. 디스크 기반 영구 볼륨은 스냅샷 리소스 그룹에서 디스크 스냅샷으로 백업됩니다. Blob의 스냅샷과 클러스터 상태가 모두 조합되어 운영 계층이라는 테넌트에 저장된 복구 지점을 형성합니다. 운영 계층에서 백업(일, 주, 월 또는 연도의 첫 번째로 성공한 백업)을 Blob으로 변환한 다음, 하루에 한 번 자격 증명 모음(테넌트 외부)으로 이동할 수도 있습니다.
참고 항목
현재 Azure Backup은 CSI 드라이버 기반 Azure Disk Storage에서 영구 볼륨만 지원합니다. 백업하는 동안 솔루션은 Azure 파일 공유 및 Blob 등의 다른 영구 볼륨 유형을 건너뜁니다. 또한 자격 증명 모음 계층에 대한 보존 규칙을 정의한 경우 영구 볼륨의 크기가 1TB보다 작거나 같은 경우에만 백업을 자격 증명 모음으로 이동할 수 있습니다.
백업 구성
AKS 클러스터에 대한 백업을 구성하려면 먼저 Backup 자격 증명 모음을 만듭니다. 자격 증명 모음은 서로 다른 데이터 원본에서 구성된 백업에 대한 통합 보기를 제공합니다. AKS 백업은 운영 계층 및 자격 증명 모음 계층 백업을 모두 지원합니다.
참고 항목
- 백업 또는 복원하려는 Backup 자격 증명 모음 및 AKS 클러스터는 동일한 지역 및 구독에 있어야 합니다.
- Backup 자격 증명 모음 스토리지 중복 설정(LRS/GRS)은 자격 증명 모음 계층에 저장된 백업에만 적용됩니다. 재해 복구에 백업을 사용하려면 지역 간 복원을 사용하도록 설정한 GRS로 스토리지 중복성을 설정합니다.
AKS 백업은 예약된 백업 작업을 자동으로 트리거합니다. 이 작업은 클러스터 리소스를 Blob 컨테이너에 복사하고 백업 빈도에 따라 디스크 기반 영구 볼륨의 증분 스냅샷을 만듭니다. 백업은 백업 정책에 정의된 보존 기간에 따라 운영 계층 및 자격 증명 모음 계층에 유지되며 기간이 끝나면 삭제됩니다.
참고 항목
AKS 백업을 사용하여 백업 인스턴스마다 다른 백업 구성을 사용하여 단일 AKS 클러스터에 대한 여러 백업 인스턴스를 만들 수 있습니다. 그러나 AKS 클러스터의 각 백업 인스턴스는 다른 백업 자격 증명 모음에서 만들거나 동일한 백업 자격 증명 모음에서 별도의 백업 정책을 사용하여 만들어야 합니다.
백업 관리
AKS 클러스터에 대한 백업 구성이 완료되면 백업 자격 증명 모음에 백업 인스턴스가 만들어집니다. Azure Portal의 AKS 인스턴스에 대한 Backup 섹션에서 클러스터에 대한 백업 인스턴스를 볼 수 있습니다. 해당 백업 인스턴스를 통해 복원 시작, 모니터링, 보호 중지 등과 같은 인스턴스에 대한 모든 백업 관련 작업을 수행할 수 있습니다.
AKS 백업은 Backup 센터와 직접 통합되어 다른 모든 백업 지원 워크로드와 함께 모든 AKS 클러스터의 보호를 중앙에서 관리할 수 있도록 합니다. Backup 센터는 작업, 백업/복원 상태 모니터링과 같은 모든 백업 요구 사항에 대한 단일 보기입니다. Backup 센터는 규정 준수 및 거버넌스를 보장하고, 백업 사용을 분석하고, 데이터 백업 및 복원을 위한 중요한 작업을 수행하는 데 도움이 됩니다.
AKS 백업은 관리 ID를 사용하여 다른 Azure 리소스에 액세스합니다. AKS 클러스터의 백업을 구성하고 이전 백업에서 복원하려면 Backup 자격 증명 모음의 관리 ID에 AKS 클러스터 및 스냅샷이 만들어지고 관리되는 스냅샷 리소스 그룹에 대한 권한 집합이 필요합니다. 현재 AKS 클러스터에는 스냅샷 리소스 그룹에 대한 권한 집합이 필요합니다. 또한 Backup 확장은 사용자 ID를 만들고 백업이 Blob에 저장되는 스토리지 계정에 액세스할 수 있는 권한 집합을 할당합니다. Azure RBAC(역할 기반 액세스 제어)를 사용하여 관리 ID에 권한을 부여할 수 있습니다. 관리 ID는 Azure 리소스에만 사용할 수 있는 특수 형식의 서비스 주체입니다. 관리 ID에 대해 자세히 알아보세요.
백업에서 복구
복구 지점이 있는 특정 시점부터 데이터를 복원할 수 있습니다. 복구 지점은 백업 인스턴스가 보호된 상태일 때 만들어지고 백업 정책에 의해 보존될 때까지 데이터를 복원하는 데 사용할 수 있습니다.
Azure Backup은 백업되는 모든 항목을 복원하거나 세분화된 제어에서 네임스페이스 및 기타 사용 가능한 필터를 선택하여 백업에서 특정 항목을 선택할 수 있는 옵션을 제공합니다. 또한 원래 AKS 클러스터(백업된 클러스터) 또는 대체 AKS 클러스터에서 복원을 수행할 수 있습니다. 운영 및 자격 증명 모음 계층에 저장된 백업을 동일하거나 다른 구독의 클러스터로 복원할 수 있습니다. 자격 증명 모음 계층에 저장된 백업만 다른 지역(Azure 쌍으로 연결된 지역)의 클러스터로 복원하는 데 사용할 수 있습니다.
자격 증명 모음 계층에 저장된 백업을 복원하려면 백업 데이터가 하이드레이션되는 스테이징 위치를 제공해야 합니다. 이 스테이징 위치에는 복원을 위한 대상 클러스터와 동일한 지역 및 구독 내에 리소스 그룹 및 스토리지 계정이 포함됩니다. 복원하는 동안 특정 리소스(Blob 컨테이너, 디스크 및 디스크 스냅샷)가 하이드레이션의 일부로 만들어지고 복원 작업이 완료된 후 지워집니다.
AKS용 Azure Backup은 현재 리소스 충돌이 발생할 때 복원 작업을 수행하는 경우 다음 두 가지 옵션을 지원합니다(백업된 리소스 이름은 대상 AKS 클러스터의 리소스와 동일함). 복원 구성을 정의할 때 이러한 옵션 중 하나를 선택할 수 있습니다.
건너뛰기: 이 옵션은 기본적으로 선택되어 있습니다. 예를 들어 pvc-azuredisk라는 PVC를 백업하고 이름이 같은 PVC가 있는 대상 클러스터에서 복원하는 경우 백업 확장은 백업된 PVC(영구 볼륨 클레임) 복원을 건너뜁니다. 이러한 시나리오에서는 클러스터에서 리소스를 삭제한 다음, 백업된 항목을 클러스터에서만 사용할 수 있고 건너뛰지 않도록 복원 작업을 수행하는 것이 좋습니다.
패치: 이 옵션을 사용하면 대상 클러스터의 리소스에 있는 백업된 리소스에서 변경 가능한 변수를 패치할 수 있습니다. 대상 클러스터의 복제본 수를 업데이트하려는 경우 패치를 작업으로 선택할 수 있습니다.
참고 항목
AKS 백업은 현재, 리소스가 이미 있는 경우 대상 클러스터에서 리소스를 삭제한 후 다시 만들지 않습니다. 원래 위치에서 영구 볼륨을 복원하려는 경우 기존 영구 볼륨을 삭제한 다음 복원 작업을 수행합니다.
백업 및 복원에 사용자 지정 후크 사용
사용자 지정 후크를 사용하여 컨테이너화된 워크로드로 배포된 데이터베이스에 사용되는 볼륨의 애플리케이션 일치 스냅샷을 만들 수 있습니다.
사용자 지정 후크란?
AKS 백업을 사용하여 백업 및 복원 작업의 일부로 사용자 지정 후크를 실행할 수 있습니다. 후크는 백업 작업 중 또는 복원 후에 컨테이너 아래의 Pod에서 실행할 하나 이상의 명령을 실행하도록 구성된 명령입니다. 이러한 후크를 사용자 지정 리소스로 정의하고 백업 또는 복원하려는 AKS 클러스터에 배포합니다. 필요한 네임스페이스의 AKS 클러스터에 사용자 지정 리소스를 배포하는 경우 백업 및 복원을 구성하는 흐름에 대한 입력으로 세부 정보를 제공합니다. Backup 확장은 YAML 파일에 정의된 대로 후크를 실행합니다.
참고 항목
후크는 컨테이너의 셸에서 실행되지 않습니다.
AKS의 백업에는 다음 두 가지 유형의 후크가 있습니다.
- 백업 후크
- 복원 후크
백업 후크
백업 후크에서 사용자 지정 작업 처리 전(사전 후크) 또는 모든 사용자 지정 작업이 완료되고 사용자 지정 작업으로 지정된 모든 추가 항목이 백업된 후(사후 후크) 후크를 실행하도록 명령을 구성할 수 있습니다.
예를 들어 백업 후크를 사용하여 배포할 사용자 지정 리소스에 대한 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 클러스터에 백업을 복원하는 동안 리소스 수정
리소스 수정 기능을 사용하면 JSON 패치를 AKS 클러스터에 배포된 configmap으로 지정하여 복원 중에 백업된 Kubernetes 리소스를 수정할 수 있습니다.
복원 중에 리소스 한정자 configmap 만들기 및 적용
리소스 수정을 만들고 적용하려면 다음 단계를 따릅니다.
리소스 한정자 configmap을 만듭니다.
리소스 한정자를 정의한 YAML 파일에서 원하는 네임스페이스에 하나의 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은 네임스페이스 표시줄과 이름이
mysql및match label foo: bar로 시작하는 foo의 모든 영구 볼륨 복사본에 JSON 패치를 적용합니다. JSON 패치는storageClassName을premium으로 바꾸고 영구 볼륨 복사본에서test레이블을 제거합니다. - 여기서 네임스페이스는 백업된 리소스의 원래 네임스페이스이며 리소스가 복원될 새 네임스페이스가 아닙니다.
- 특정 리소스에 대해 여러 JSON 패치를 지정할 수 있습니다. 패치는 configmap에 지정된 순서에 따라 적용됩니다. 후속 패치가 순서대로 적용됩니다. 동일한 경로에 대해 여러 패치가 지정된 경우 마지막 패치가 이전 패치를 재정의합니다.
- configmap에 여러 개의
resourceModifierRules를 지정할 수 있습니다. 규칙은 configmap에 지정된 순서에 따라 적용됩니다.
- 위의 configmap은 네임스페이스 표시줄과 이름이
복원 구성에서 리소스 한정자 참조 만들기
복원 작업을 수행할 때 ConfigMap 이름과 복원 구성의 일부로 배포되는 네임스페이스를 제공합니다. 이러한 세부 정보는 리소스 한정자 규칙에 제공되어야 합니다.
리소스 한정자에서 지원하는 작업
추가
추가 작업을 사용하여 리소스 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에서 키를 제거할 수 있습니다. 아래 예제에서 작업은 테스트가 키로 포함된 레이블을 제거합니다.
version: v1 resourceModifierRules: - conditions: groupResource: persistentvolumeclaims resourceNameRegex: "^mysql.*$" namespaces: - bar - foo labelSelector: matchLabels: foo: bar patches: - operation: remove path: "/metadata/labels/test"Replace
바꾸기 작업을 사용하여 대체 경로에 언급된 경로의 값을 바꿀 수 있습니다. 아래 예제에서 작업은 영구 볼륨 클레임의 storageClassName을 프리미엄으로 바꿉니다.
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"Test
테스트 작업을 사용하여 리소스에 특정 값이 있는지 확인할 수 있습니다. 값이 있으면 패치가 적용됩니다. 값이 없으면 패치가 적용되지 않습니다. 아래 예제에서 작업은 영구 볼륨 클레임에 StorageClassName으로 프리미엄이 있는지 여부를 확인하고 표준인 경우 true로 바꿉니다.
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 패치
이 configmap은 기본적으로 네임스페이스의 모든 배포와 ``nginx
with the name that starts withnginxdep`에 JSON 패치를 적용합니다. JSON 패치는 이러한 모든 배포에 대해 복제본 수를 12로 업데이트합니다.version: v1 resourceModifierRules: - conditions: groupResource: deployments.apps resourceNameRegex: "^nginxdep.*$" namespaces: - default - nginx patches: - operation: replace path: "/spec/replicas" value: "12"JSON 병합 패치
이 구성 맵은 이름이 nginxdep로 시작하는 네임스페이스 default 및 nginx의 모든 배포에 JSON 병합 패치를 적용합니다. JSON 병합 패치는 "nginx1" 값으로 "app" 레이블을 추가/업데이트합니다.
version: v1 resourceModifierRules: - conditions: groupResource: deployments.apps resourceNameRegex: "^nginxdep.*$" namespaces: - default - nginx mergePatches: - patchData: | { "metadata" : { "labels" : { "app" : "nginx1" } } }전략적 병합 패치
이 구성 맵은 이름이 nginx로 시작하는 네임스페이스 default의 모든 Pod에 전략적 병합 패치를 적용합니다. 전략적 병합 패치는 컨테이너 nginx의 이미지를 mcr.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 클러스터에 설치된 Backup 확장은 먼저 CSI 드라이버를 통해 볼륨 스냅샷을 만들어 백업을 수행하고 클러스터 상태를 사용자 고유의 테넌트에 있는 Blob 컨테이너에 저장합니다. 이 계층은 두 백업 사이에 4시간의 최소 기간을 유지하는 더 낮은 RPO를 지원합니다. 또한 Azure 디스크 기반 볼륨의 경우 운영 계층은 더 빠른 복원을 지원합니다.
자격 증명 모음 표준 계층: 스냅샷보다 저렴한 비용으로 백업 데이터를 더 오래 저장하기 위해 AKS 백업은 자격 증명 모음 표준 데이터 저장소를 지원합니다. 백업 정책에 설정된 보존 규칙에 따라 첫 번째 성공적인 백업(일, 주, 월 또는 연도)이 테넌트 외부의 Blob 컨테이너로 이동됩니다. 이 데이터 저장소는 더 긴 보존을 허용할 뿐만 아니라 랜섬웨어 보호도 제공합니다. 또한 Backup 자격 증명 모음에서 지역 중복 및 지역 간 복원을 사용하도록 설정하여 복구를 위해 자격 증명 모음에 저장된 백업을 다른 지역(Azure 쌍으로 연결된 지역)으로 이동할 수도 있습니다.
참고 항목
보존 규칙을 정의하여 Backup 정책을 통해 자격 증명 모음 표준 데이터 저장소에 백업 데이터를 저장할 수 있습니다. 하루에 하나의 예약된 복구 지점만 중요 보관소 계층으로 이동됩니다. 그러나 선택한 규칙에 따라 원하는 수의 주문형 백업을 자격 증명 모음으로 이동할 수 있습니다.
가격 책정 이해
다음에 대해 요금이 부과됩니다.
보호된 인스턴스 요금: AKS용 Azure Backup은 매월 네임스페이스당 보호된 인스턴스 요금을 청구합니다. AKS 클러스터에 대한 백업을 구성하면 보호된 인스턴스가 만들어집니다. 각 인스턴스에는 백업 구성에 정의된 대로 백업되는 특정 수의 네임스페이스가 있습니다. AKS 백업 가격 책정에 대한 자세한 내용은 클라우드 백업 가격 책정을 참조하고 Azure Kubernetes Service를 워크로드로 선택합니다.
스냅샷 요금: AKS용 Azure Backup은 Azure 구독의 리소스 그룹에 저장된 스냅샷을 만들어 디스크 기반 영구 볼륨을 보호합니다. 이러한 스냅샷에는 스냅샷 스토리지 요금이 발생합니다. 스냅샷이 Backup 자격 증명 모음에 복사되지 않기 때문에 백업 스토리지 비용이 적용되지 않습니다. 스냅샷 가격 책정에 대한 자세한 내용은 관리 디스크 가격 책정을 참조하세요.
백업 스토리지 요금: AKS용 Azure Backup은 자격 증명 모음 계층에 백업 저장도 지원합니다. 이는 백업 정책에서 자격 증명 모음 표준에 대한 보존 규칙을 정의하여 수행할 수 있으며, 하루에 하나의 복원 지점이 자격 증명 모음으로 이동할 수 있습니다. 자격 증명 모음 계층에 저장된 복원 지점에는 백업 자격 증명 모음에 저장된 총 데이터(GB) 및 중복성 유형에 따라 Backup Storage 요금이라는 별도의 요금이 청구됩니다.