DOKS에서 TrilioVault를 사용한 백업 및 복원 수행하는 방법

소개

이 튜토리얼에서는 TrilioVault for Kubernetes (또는 TVK)를 DOKS 클러스터에 배포하는 방법, 백업을 생성하고 백업이 필요할 때 복구하는 방법을 배우게 됩니다. 전체 클러스터를 백업하거나 선택적으로 네임스페이스 또는 레이블 기반의 백업을 선택할 수 있습니다.

Trilio 사용의 장점:

• 클러스터의 완전한 (또는 증분) 백업을 가져오고 데이터 손실이 발생한 경우 복원합니다.
• 하나의 클러스터에서 다른 클러스터로 마이그레이션합니다.
• Helm 릴리스 백업이 지원됩니다.
• 백업 및 복원 작업에 대한 사전 및 사후 후크를 실행합니다.
• 백업 및 복원 작업의 상세한 상태를 검사할 수 있는 웹 관리 콘솔이 있습니다.
• 백업에 대한 보존 정책을 정의합니다.
• 응용 프로그램 라이프사이클 (즉, TVK 자체)은 전용 TrilioVault Operator를 통해 관리할 수 있습니다.
• Velero 통합이 있습니다.
• 연산자 기반 응용 프로그램을 백업하고 복원할 수 있습니다.

자세한 정보는 TVK CRD 공식 문서를 참조하십시오.

목차

• 전제 조건
• 단계 1 – Kubernetes용 TrilioVault 설치
• 단계 2 – 백업을 저장할 TrilioVault 대상 생성
• 단계 3 – TVK 웹 관리 콘솔 살펴보기
• 단계 4 – 네임스페이스 백업 및 복원 예제
• 단계 5 – 클러스터 전체 백업 및 복원 예제
• 단계 6 – 예약된 백업
• 단계 7 – 백업 보유 정책
• 결론

전제 조건

이 튜토리얼을 완료하려면 다음이 필요합니다:

1. A DO Spaces Bucket and access keys. Save the access and secret keys in a safe place for later use.
2. A Git client to clone the Starter Kit repository.
3. Helm, TrilioVault Operator 릴리스 및 업그레이드를 관리하기 위해.
4. Doctl, DigitalOcean API 상호 작용을 위해.
5. Kubectl, Kubernetes 상호 작용을 위해.

TrilioVault가 올바르게 작동하고 PVC를 백업하려면 DOKS를 Container Storage Interface(CSI)를 지원하도록 구성해야 합니다. 기본적으로 드라이버가 이미 설치되어 구성되어 있습니다. 다음 명령을 사용하여 확인할 수 있습니다:

kubectl get storageclass

출력은 다음 스니펫과 유사해야 합니다. 프로비저너가 dobs.csi.digitalocean.com임에 유의하십시오.

NAME                         PROVISIONER                 RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
do-block-storage (default)   dobs.csi.digitalocean.com   Delete          Immediate           true                   10d

TrilioVault 설치에는 또한 volumeSnapshot 사용자 정의 리소스 정의(CRD)가 필요합니다. 성공적인 설치를 위해 다음 명령을 사용하여 확인할 수 있습니다:

kubectl get crd | grep volumesnapshot

출력은 다음 스니펫과 유사해야 합니다. VolumeSnapshot CRD가 설치되지 않은 경우 VolumeSnapshot CRD 설치를 참조하십시오.

volumesnapshotclasses.snapshot.storage.k8s.io         2022-02-01T06:01:14Z
volumesnapshotcontents.snapshot.storage.k8s.io        2022-02-01T06:01:14Z
volumesnapshots.snapshot.storage.k8s.io               2022-02-01T06:01:15Z

또한 CRD가 v1beta1 및 v1 API 버전을 모두 지원하는지 확인하십시오. API 버전을 확인하려면 다음 명령을 실행할 수 있습니다:

kubectl get crd volumesnapshots.snapshot.storage.k8s.io -o yaml

CRD YAML의 끝에는 다음과 같이 storedVersions 목록을 확인해야 합니다. v1beta1 및 v1 값을 모두 포함해야 합니다 (설치되지 않은 경우 VolumeSnapshot CRD 설치를 참조하십시오):

...
- lastTransitionTime: "2022-01-20T07:58:06Z"
    message: approved in https://github.com/kubernetes-csi/external-snapshotter/pull/419
    reason: ApprovedAnnotation
    status: "True"
    type: KubernetesAPIApprovalPolicyConformant
  storedVersions:
  - v1beta1
  - v1

단계 1 – Kubernetes용 TrilioVault 설치

이 단계에서는 TrilioVault를 DOKS에 배포하고 Helm을 통해 TVK 설치를 관리하는 방법을 배우게 됩니다. 백업 데이터는 앞서 준비 사항 섹션에서 만든 DO Spaces 버킷에 저장됩니다.

TrilioVault 애플리케이션을 설치하는 방법은 여러 가지가 있습니다:

• TrilioVault Operator를 통해. 여기서는 TrilioVaultManager CRD를 정의하여 TrilioVault 연산자에게 Trilio 애플리케이션 구성 요소의 설치, 포스트 구성 단계 및 미래 업그레이드 방법을 알려줍니다.
• Helm에 의해 완전히 관리되는 triliovault-operator 차트를 통해(이 튜토리얼에서 다룸).

Helm을 사용하여 TrilioVault 설치

먼저 Starter Kit Git 저장소를 복제하고 로컬 복사본의 디렉토리를 변경하세요:

git clone https://github.com/digitalocean/Kubernetes-Starter-Kit-Developers.git
cd Kubernetes-Starter-Kit-Developers

다음으로, TrilioVault Helm 저장소를 추가하고 사용 가능한 차트를 나열하세요:

helm repo add triliovault-operator http://charts.k8strilio.net/trilio-stable/k8s-triliovault-operator
helm repo update triliovault-operator
helm search repo triliovault-operator

출력은 다음과 유사합니다:

NAME                                            CHART VERSION   APP VERSION     DESCRIPTION
triliovault-operator/k8s-triliovault-operator   2.9.2           2.9.2           K8s-TrilioVault-Operator is an operator designe...

그런 다음, 선호하는 편집기(가능한 경우 YAML lint 지원)를 사용하여 스타터 키트 리포지토리에서 제공하는 TrilioVault Helm 값 파일을 열고 검사합니다.

code 05-setup-backup-restore/assets/manifests/triliovault-values-v2.9.2.yaml

마지막으로 Helm을 사용하여 Kubernetes용 TrilioVault를 설치하세요:

helm install triliovault-operator triliovault-operator/k8s-triliovault-operator \
  --namespace tvk \
  --create-namespace \
  -f 05-setup-backup-restore/assets/manifests/triliovault-values.yaml

installTVK.ComponentConfiguration.ingressController.service.type는 TVK UI에 액세스하는 데 사용할 서비스 유형을 지정합니다. 예: NodePort 또는 LoadBalancer

helm ls -n tvk

이제 TVK 배포를 확인하세요:

NAME                    NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                           APP VERSION
triliovault-manager-tvk tvk             1               2022-06-08 08:30:08.490304959 +0000 UTC deployed        k8s-triliovault-2.9.2           2.9.2
triliovault-operator    tvk             1               2022-06-08 11:32:55.755395 +0300 EEST   deployed        k8s-triliovault-operator-2.9.2  2.9.2

다음 출력은 다음 스니펫과 유사해야합니다(STATUS 열은 deployed로 표시되어야 함):

kubectl get deployments -n tvk

다음으로, TrilioVault가 작동 중인지 확인하십시오:

NAME                                            READY   UP-TO-DATE   AVAILABLE   AGE
k8s-triliovault-admission-webhook               1/1     1            1           83s
k8s-triliovault-control-plane                   1/1     1            1           83s
k8s-triliovault-exporter                        1/1     1            1           83s
k8s-triliovault-ingress-nginx-controller        1/1     1            1           83s
k8s-triliovault-web                             1/1     1            1           83s
k8s-triliovault-web-backend                     1/1     1            1           83s
triliovault-operator-k8s-triliovault-operator   1/1     1            1           4m22s

출력은 다음 스니펫과 유사해야합니다. 모든 배포된 파드는 Ready 상태여야합니다.

출력이 이와 같이 보인다면, TVK를 성공적으로 설치했습니다. 다음으로, 라이선스 유형과 유효성을 확인하는 방법 및 갱신하는 방법을 배우게 될 것입니다.

TrilioVault 응용 프로그램 라이선싱

스타터 키트 예제는 정상적으로 작동하려면 클러스터 라이선스 유형에 의존합니다.

TVK 애플리케이션 라이선스 생성 및 확인

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/tvk_install_license.yaml

다음 명령을 실행하여 클러스터에 새 라이선스를 생성합니다 (라이선스 CRD를 통해 관리됨):

kubectl apply -f <YOUR_LICENSE_FILE_NAME>.yaml -n tvk

Trilio 웹 사이트에서 무료 라이선스를 다운로드하는 경우, 다음 명령을 사용하여 적용하십시오:

kubectl get license -n tvk

라이선스가 설치되어 있는지 및 클러스터에서 Active 상태인지 확인하려면 다음 명령을 실행하십시오.

NAME             STATUS   MESSAGE                                   CURRENT NODE COUNT   GRACE PERIOD END TIME   EDITION     CAPACITY   EXPIRATION TIME        MAX NODES
test-license-1   Active   Cluster License Activated successfully.   1                                            FreeTrial   100000     2023-02-25T00:00:00Z   1

출력은 다음과 유사합니다. STATUS가 Active이어야하며, EDITION 열과 EXPIRATION TIME의 라이선스 유형을주의하십시오.

kubectl describe license test-license-1 -n tvk

라이선스는 특별한 CRD 인 License 개체를 통해 관리됩니다. 다음 명령을 실행하여 확인할 수 있습니다:

Name:         test-license-1
Namespace:    tvk
Labels:       <none>
Annotations:
              generation: 1
              triliovault.trilio.io/creator: system:serviceaccount:tvk:k8s-triliovault
              triliovault.trilio.io/instance-id: b060660d-4851-482b-8e60-4addd260e1d3
              triliovault.trilio.io/updater:
                [{"username":"system:serviceaccount:tvk:k8s-triliovault","lastUpdatedTimestamp":"2022-02-24T06:38:21.418828262Z"}]
API Version:  triliovault.trilio.io/v1
Kind:         License
Metadata:
  Creation Timestamp:  2022-02-24T06:38:21Z
...
Status:
  Condition:
    Message:           License Key changed
    Timestamp:         2022-02-24T06:38:21Z
    Message:           Cluster License Activated successfully.
    Status:            Active
    Timestamp:         2022-02-24T06:38:21Z
  Current Node Count:  1
  Max Nodes:           1
  Message:             Cluster License Activated successfully.
  Properties:
    Active:                        true
    Capacity:                      100000
    Company:                       TRILIO-KUBERNETES-LICENSE-GEN-DIGITALOCEAN-BASIC
    Creation Timestamp:            2022-02-24T00:00:00Z
    Edition:                       FreeTrial
    Expiration Timestamp:          2023-02-25T00:00:00Z
    Kube UID:                      b060660d-4851-482b-8e60-4addd260e1d3
    License ID:                    TVAULT-5a4b42c6-953c-11ec-8116-0cc47a9fd48e
    Maintenance Expiry Timestamp:  2023-02-25T00:00:00Z
    Number Of Users:               -1
    Purchase Timestamp:            2022-02-24T00:00:00Z
    Scope:                         Cluster
...

출력은 다음과 유사합니다. Message 및 Capacity 필드와 Edition을 주의하십시오.

위의 출력은 만료 타임스탬프 필드에 라이선스 만료일을 알려주며 이 경우 범위 (클러스터 기반)를 제공합니다. 클러스터 전체 라이선스 유형이나 네임스페이스 기반 라이선스를 선택할 수 있습니다.

TVK 애플리케이션 라이선스 갱신

kubectl apply -f <YOUR_LICENSE_FILE_NAME>.yaml -n tvk

라이선스를 갱신하려면 Trilio 웹사이트에서 라이선스 페이지로 이동하여 이전 라이선스를 대체할 새 라이선스를 요청해야 합니다. 양식을 작성한 후에는 kubectl을 사용하여 클러스터에 적용할 수 있는 라이선스 YAML 매니페스트를 받게 됩니다. 다음 명령어는 TVK가 기본 tvk 네임스페이스에 설치되어 있다고 가정합니다 (필요한 경우 <> 자리 표시자를 적절히 대체하세요):

그런 다음 이미 배운대로 새 라이선스 상태를 확인할 수 있습니다:
kubectl get license -n tvk

# 우선 `tvk` 네임스페이스에서 사용 가능한 TVK 라이선스 목록 표시
kubectl describe license <YOUR_LICENSE_NAME_HERE> -n tvk

# `tvk` 네임스페이스에서 특정 라이선스에 대한 정보 가져오기

다음 단계에서는 TrilioVault의 백업을 저장하기 위해 저장 백엔드를 정의하는 방법을 배우게 됩니다.

단계 2 – 백업 저장을 위한 TrilioVault 대상 생성

A typical Target definition looks like:

apiVersion: triliovault.trilio.io/v1
kind: Target
metadata:
  name: trilio-s3-target
  namespace: tvk
spec:
  type: ObjectStore
  vendor: Other
  enableBrowsing: true
  objectStoreCredentials:
    bucketName: <YOUR_DO_SPACES_BUCKET_NAME_HERE>
    region: <YOUR_DO_SPACES_BUCKET_REGION_HERE>
    url: 'https://<YOUR_DO_SPACES_BUCKET_ENDPOINT_HERE>'
    credentialSecret:
      name: trilio-s3-target
      namespace: tvk
  thresholdCapacity: 10Gi

TrilioVault는 먼저 백업을 저장할 위치를 알아야 합니다. TrilioVault는 저장 백엔드를 대상 용어를 사용하여 참조하며, 특별한 CRD인 대상을 통해 관리됩니다. 다음 대상 유형이 지원됩니다: S3 및 NFS. 디지털오션과 스타터 키트의 목적을 위해서는 S3 저장 유형을 사용하는 것이 합리적입니다. 이유는 저렴하고 확장 가능하기 때문입니다. 향상된 보호 수준을 누리려면 여러 대상 유형(둘 다 S3 및 NFS)을 생성하여 데이터를 여러 위치에 안전하게 보관할 수 있도록하여 백업 중복성을 달성할 수 있습니다.

• 이 구성에서,
• spec.type: 백업 저장용 대상 유형 (S3는 객체 저장소입니다).
• spec.vendor: 대상을 호스팅하는 제3자 저장 공급업체 (AWS 대신에 Other를 사용해야 함)。
• spec.enableBrowsing: 대상의 브라우징 활성화 여부.
• spec.objectStoreCredentials: 필요한 자격 증명을 정의함 (credentialSecret를 통해)으로써 S3 저장소에 액세스하기 위해 버킷 영역 및 이름과 같은 기타 매개 변수도 정의됨.

spec.thresholdCapacity: 백업 데이터를 저장하는 최대 임계 용량.

apiVersion: v1
kind: Secret
metadata:
  name: trilio-s3-target
  namespace: tvk
type: Opaque
stringData:
  accessKey: <YOUR_DO_SPACES_ACCESS_KEY_ID_HERE> S3 저장소에 액세스하려면 각 대상이 버킷 자격 증명을 알아야 합니다. Kubernetes 시크릿도 생성되어야 합니다:
  secretKey: <YOUR_DO_SPACES_SECRET_KEY_HERE>    # 값은 base64로 인코딩되어야 함

# 값은 base64로 인코딩되어야 함

시크릿 이름이 trilio-s3-target이고 앞에서 설명한 Target CRD의 spec.objectStoreCredentials.credentialSecret 필드에서 참조됩니다. 시크릿은 TrilioVault가 설치된 동일한 네임스페이스에 있을 수도 있습니다(tvk로 기본 설정됨) 또는 선택한 다른 네임스페이스에 있을 수도 있습니다. 단지 네임스페이스를 올바르게 참조하는지 확인하십시오. 반면에, TrilioVault 시크릿을 저장하는 네임스페이스를 보안상의 이유로 RBAC로 보호하는 것이 중요합니다.

TrilioVault를 위한 대상을 생성하는 단계:

cd Kubernetes-Starter-Kit-Developers

먼저, 로컬 머신에 Starter Kit Git 저장소가 복제된 디렉토리로 디렉토리를 변경하십시오:

kubectl create secret generic trilio-s3-target \
  --namespace=tvk \
  --from-literal=accessKey="<YOUR_DO_SPACES_ACCESS_KEY_HERE>" \
  --from-literal=secretKey="<YOUR_DO_SPACES_SECRET_KEY_HERE>"

다음으로, 대상 S3 버킷 자격 증명이 포함된 Kubernetes 시크릿을 생성하십시오 (해당하는 <> 자리 표시자를 교체하십시오):

code 05-setup-backup-restore/assets/manifests/triliovault/triliovault-s3-target.yaml

–from-literal=accessKey=“<여기에 DO 스페이스 액세스 키를 입력하십시오>” \

–from-literal=secretKey=“<여기에 DO 스페이스 비밀 키를 입력하십시오>”

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/triliovault-s3-target.yaml

그런 다음, YAML 린트 지원을 포함한 선택한 편집기를 사용하여 스타터 킷 저장소에 제공된 대상 매니페스트 파일을 열고 검사하십시오.

이제 DO Spaces Trilio 버킷에 대한 <> 자리 표시자를 적절히 교체하십시오. 예를 들어 bucketName, region, url, credentialSecret 등입니다.

kubectl get target trilio-s3-target  -n tvk

마지막으로 매니페스트 파일을 저장하고 kubectl을 사용하여 대상 개체를 만드십시오:

NAME               TYPE          THRESHOLD CAPACITY   VENDOR   STATUS      BROWSING ENABLED
trilio-s3-target   ObjectStore   10Gi                 Other    Available

다음으로, TrilioVault는 S3 버킷을 유효성 검사하는 trilio-s3-target-validator라는 워커 작업을 생성합니다(가용성, 권한 등 확인). 작업이 성공적으로 완료되면 버킷은 건강하거나 사용 가능한 것으로 간주되며 trilio-s3-target-validator 작업 리소스는 이후에 삭제됩니다. 문제가 발생하면 S3 대상 유효성 검사기 작업이 실행 중인 상태로 남아 있어 로그를 검사하고 가능한 문제를 찾을 수 있습니다.

출력은 다음과 유사합니다. STATUS 열 값에 주목하십시오 - 건강한 상태이어야 합니다(Available).
kubectl get pods -n tvk | grep trilio-s3-target-validator

출력이 이와 같은 경우 S3 대상 객체를 성공적으로 구성했습니다.
대상 객체가 건강 상태로 전환되지 못한 경우 trilio-s3-target-validator Pod의 로그를 검사하여 문제를 찾을 수 있습니다:

# 먼저 대상 유효성 검사기를 찾아야합니다
kubectl logs pod/trilio-s3-target-validator-tio99a-6lz4q -n tvk

...
INFO:root:2021-11-24 09:06:50.595166: waiting for mount operation to complete.
INFO:root:2021-11-24 09:06:52.595772: waiting for mount operation to complete.
ERROR:root:2021-11-24 09:06:54.598541: timeout exceeded, not able to mount within time.
ERROR:root:/triliodata is not a mountpoint. We can't proceed further.
Traceback (most recent call last):
  File "/opt/tvk/datastore-attacher/mount_utility/mount_by_target_crd/mount_datastores.py", line 56, in main
    utilities.mount_datastore(metadata, datastore.get(constants.DATASTORE_TYPE), base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 377, in mount_datastore
    mount_s3_datastore(metadata_list, base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 306, in mount_s3_datastore
    wait_until_mount(base_path)
  File "/opt/tvk/datastore-attacher/mount_utility/utilities.py", line 328, in wait_until_mount
    base_path))
Exception: /triliodata is not a mountpoint. We can't proceed further.
...

#trilio-s3-target-validator-tio99a-6lz4q 1/1 실행 중 0 104초

# 이제 로그 데이터를 가져 오세요

결과는 이 예외가됩니다:

다음으로, 백업 및 복원 작업을 쉽게 관리하는 데 유용한 TVK 웹 콘솔을 발견하게됩니다.

단계 3 – TVK 웹 관리 콘솔 알아보기

CLI을 통해 완전히 kubectl 및 CRD를 통해 백업 및 복원 작업을 관리 할 수 있지만, TVK는 GUI를 통해 동일한 작업을 수행하기위한 웹 관리 콘솔을 제공합니다. 관리 콘솔은 클릭하여 일반 작업을 단순화하며 TVK 클러스터 개체를 더 잘 시각화하고 검사 할 수 있도록하며 재해 복구 계획 (또는 DRP)을 만듭니다.

단계 1 – Kubernetes용 TrilioVault 설치에서 다룬 Helm 기반 설치가 웹 관리 콘솔에 필요한 구성 요소를 설치하는 데 이미 신경 썼습니다.

kubectl get svc -n tvk

TVK 웹 관리 콘솔에 액세스하기

NAME                                                            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
k8s-triliovault-admission-webhook                               ClusterIP   10.245.202.17    <none>        443/TCP                      13m
k8s-triliovault-ingress-nginx-controller                        NodePort    10.245.192.140   <none>        80:32448/TCP,443:32588/TCP   13m
k8s-triliovault-ingress-nginx-controller-admission              ClusterIP   10.3.20.89       <none>        443/TCP                      13m
k8s-triliovault-web                                             ClusterIP   10.245.214.13    <none>        80/TCP                       13m
k8s-triliovault-web-backend                                     ClusterIP   10.245.10.221    <none>        80/TCP                       13m
triliovault-operator-k8s-triliovault-operator-webhook-service   ClusterIP   10.245.186.59    <none>        443/TCP                      16m

콘솔에 액세스하여 제공되는 기능을 탐색하려면 TVK의 인그레스 컨트롤러 서비스를 포트 포워딩해야 합니다.

먼저, tvk 네임스페이스에서 ingress-nginx-controller 서비스를 식별해야 합니다:
installTVK:
  ingressConfig:
    host: "tvk-doks.com"

출력은 다음과 유사합니다. k8s-triliovault-ingress-nginx-controller 라인을 찾고, PORT(S) 열에서 포트 80에서 수신 대기하는 것을 주목하세요.

127.0.0.1 tvk-doks.com

TVK는 관리 웹 콘솔 서비스로 트래픽을 라우팅하기 위해 Nginx 인그레스 컨트롤러를 사용합니다. 라우팅은 호스트 기반이며, 호스트 이름은 스타터 키트의 Helm 값 파일에서 정의된 tvk-doks.com입니다:

kubectl port-forward svc/k8s-triliovault-ingress-nginx-controller 8080:80 -n tvk

# TVK 인그레스 nginx 컨트롤러를 통해 웹 콘솔에 액세스할 때 사용할 호스트 이름

위의 정보를 손에 넣었다면, /etc/hosts 파일을 편집하고 다음 항목을 추가하세요:
doctl k8s cluster list

그다음, TVK 인그레스 컨트롤러 서비스를 위한 포트 포워드를 생성하세요:
doctl kubernetes cluster kubeconfig show <YOUR_CLUSTER_NAME_HERE> > config_<YOUR_CLUSTER_NAME_HERE>.yaml

DOKS_CLUSTER_NAME="$(doctl k8s cluster list --no-header --format Name)"
doctl kubernetes cluster kubeconfig show $DOKS_CLUSTER_NAME > config_${DOKS_CLUSTER_NAME}.yaml

# 사용 가능한 클러스터 목록 나열

하나의 클러스터만 있다면 다음 명령을 실행하십시오:

이 단계를 따르면 웹 브라우저에서 콘솔에 액세스할 수 있습니다. 다음으로 이동하십시오: http://tvk-doks.com:8080. kubeconfig 파일이 요청되면 위에서 생성한 파일을 선택하십시오.

생성된 kubeconfig 파일을 안전하게 보관하십시오. 민감한 데이터가 포함되어 있습니다.

• TVK 웹 콘솔 사용자 인터페이스 탐색
• 왼쪽의 각 섹션을 탐색하십시오. 예를 들어:
• 클러스터 관리: 이는 주 클러스터와 다른 TVK 인스턴스를 가진 클러스터의 목록을 보여줍니다. Multi-Cluster Management 기능을 사용하여 주 OVH 클러스터에 추가되었습니다.
• 백업 및 복구: 전체 클러스터의 일반적인 개요를 제공하는 주요 대시보드입니다. 발견된 네임스페이스, 응용 프로그램, 백업 계획 목록, 대상, 후크, 정책 등이 포함됩니다.

모니터링: 이에는 두 가지 옵션이 있습니다- TrilioVault 모니터링 및 Velero 모니터링 사용자가 OVH 클러스터에 Velero를 구성한 경우입니다.

재해 복구: 재해 복구 작업을 관리하고 수행할 수 있습니다.

재해 복구: 재해 복구 작업을 관리하고 수행할 수 있습니다.

또한 이전에 생성된 S3 대상을 볼 수 있습니다. 이를 위해 백업 및 복구 -> 대상 -> <Namespace> 드롭다운에서 tvk로 이동하십시오.

더 나아가서, 대상을 찾아서 오른쪽의 작업 버튼을 클릭한 다음 팝업 메뉴에서 브라우저 실행 옵션을 선택하여 사용 가능한 백업 목록을 볼 수 있습니다. 이를 위해 대상에는 enableBrowsing 플래그가 true로 설정되어 있어야 합니다.

자세한 정보 및 사용 가능한 기능은 TVK 웹 관리 콘솔 사용자 인터페이스 공식 문서를 참조하십시오.

다음으로, 특정 사용 사례에 대한 백업 및 복원 작업 방법을 알아보겠습니다.

단계 4 – 이름 공간화된 백업 및 복원 예시

apiVersion: triliovault.trilio.io/v1
kind: BackupPlan
metadata:
  name: ambassador-helm-release-backup-plan
  namespace: ambassador
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
  backupPlanComponents:
    helmReleases:
      - ambassador

이 단계에서는 DOKS 클러스터에서 전체 네임 스페이스(ambassador 이 경우)에 대한 일회성 백업을 생성하고 후에 복원하는 방법을 배우게 됩니다. 이 과정에서 모든 리소스가 재생성되도록 합니다. TVK에는 네임 스페이스 이상의 더 높은 수준에서 백업을 수행할 수 있는 기능이 있습니다.

• Ambassador Helm 릴리스 백업 생성
• 네임 스페이스(또는 Helm 릴리스)에서 단일 응용 프로그램에 대한 백업을 수행하려면 BackupPlan 다음에 Backup CRD가 필요합니다. BackupPlan은 백업 프로세스의 ‘무엇’, ‘어디’, ‘어디로’, 및 ‘어떻게’를 정의하지만 실제 백업을 수행하지는 않습니다. Backup CRD는 BackupPlan 사양에 따라 실제 백업 프로세스를 트리거합니다.
• 이 구성에서는

A typical Backup CRD looks like below:

apiVersion: triliovault.trilio.io/v1
kind: Backup
metadata:
  name: ambassador-helm-release-full-backup
  namespace: ambassador
spec:
  type: Full
  backupPlan:
    name: ambassador-helm-release-backup-plan
    namespace: ambassador

spec.backupConfig.target.name: 백업을 저장할 대상 이름을 TVK에게 알려줍니다.

• spec.backupConfig.target.namespace: 대상이 생성된 네임 스페이스를 TVK에게 알려줍니다.
• spec.backupComponents: 백업할 리소스 목록을 정의합니다.

이 구성에서,

spec.type: 백업 유형을 지정합니다.

spec.backupPlan: 이 백업이 사용해야 하는 BackupPlan을 지정합니다.

cd Kubernetes-Starter-Kit-Developers

Ambassador Helm 릴리스를 일회성으로 백업하려면 다음 단계를 수행하세요:

code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup-plan.yaml
code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup.yaml

먼저, 클러스터에 Ambassador Edge Stack이 배포되어 있는지 확인하고 Ambassador Ingress 튜토리얼의 단계를 따르세요.

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup-plan.yaml
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-backup.yaml

다음으로, 로컬 머신에서 Starter Kit Git 리포지토리가 복제된 디렉토리로 디렉토리를 변경하세요:

kubectl get backupplan ambassador-helm-release-backup-plan -n ambassador

그런 다음, 선택한 편집기(가능하면 YAML lint 지원이 있는)를 사용하여 Starter Kit 리포지토리에 제공된 Ambassador BackupPlan 및 Backup 매니페스트 파일을 열고 검사하세요.

NAME                                  TARGET             ...   STATUS
ambassador-helm-release-backup-plan   trilio-s3-target   ...   Available

마지막으로, kubectl을 사용하여 BackupPlan 및 Backup 리소스를 생성하세요.

kubectl get backup ambassador-helm-release-full-backup -n ambassador

이제 kubectl을 사용하여 BackupPlan 상태를 검사하세요(대상은 ambassador Helm 릴리스입니다):

NAME                                  BACKUPPLAN                            BACKUP TYPE   STATUS       ...
ambassador-helm-release-full-backup   ambassador-helm-release-backup-plan   Full          InProgress   ...

출력은 다음과 유사합니다. STATUS 열의 값이 Available로 설정되어 있는지 주목하세요.

다음으로, kubectl을 사용하여 Backup 객체 상태를 확인하세요:
NAME                                  BACKUPPLAN                            BACKUP TYPE   STATUS      ...   PERCENTAGE
ambassador-helm-release-full-backup   ambassador-helm-release-backup-plan   Full          Available   ...   100

출력은 다음과 유사합니다. STATUS 열의 값이 InProgress로 설정되어 있는지, 그리고 BACKUP TYPE이 Full로 설정되어 있는지 주목하세요.

s3cmd ls s3://trilio-starter-kit --recursive

대사관 헬름 릴리스 구성 요소가 모두 S3 대상에 업로드를 완료한 후에는 다음과 같은 결과를 얻어야 합니다:

2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/
2021-11-25 07:04          311  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup-namespace.json.manifest.00000004
2021-11-25 07:04          302  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backup.json.manifest.00000004
2021-11-25 07:04          305  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/backupplan.json.manifest.00000004
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/
2021-11-25 07:04           28  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/
2021-11-25 07:04          330  s3://trilio-starter-kit/6c68af15-5392-45bb-a70b-b26a93605bd9/5ebfffb5-442a-455c-b0de-1db98e18b425/custom/metadata-snapshot/metadata.json.manifest.00000002
...

kubectl get pods -n ambassador | grep metamover

ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx   1/1     Running   0          4m32s

kubectl logs pod/ambassador-helm-release-full-backup-metamover-mg9gl0--1-2d6wx -n ambassador -f

...
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=ClusterRoleBinding: [edge-stack]","time":"2022-06-14T06:20:56Z"}
{"component":"meta-mover","file":"pkg/metamover/snapshot/parser/commons.go:1366","func":"github.com/trilioData/k8s-triliovault/pkg/metamover/snapshot/parser.(*Component).ParseForDataComponents","level":"info","msg":"Parsing data components of resource rbac.authorization.k8s.io/v1, Kind=RoleBinding: [edge-stack-agent-config]","time":"2022-06-14T06:20:56Z"}
...

출력은 다음과 유사합니다:

이제 로그 데이터를 가져옵니다:

출력은 다음과 유사합니다.

helm delete ambassador -n ambassador

마지막으로, 백업이 웹 콘솔에서도 사용 가능한지 확인할 수 있습니다. 이를 위해 리소스 관리 -> Ambassador -> 백업 계획으로 이동합니다. 대사관 헬름 릴리스가 Available 상태이고 대사관 헬름 릴리스가 구성 요소 세부 정보 하위 뷰에 백업되었음을 유의하십시오.

kubectl get all -n ambassador

대사관 헬름 릴리스 및 리소스 삭제

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

이제 의도적으로 ambassador 헬름 릴리스를 삭제하여 재해를 시뮬레이트하십시오:

동일한 네임스페이스를 복원하는 경우 원래 응용 프로그램 구성 요소가 제거되었는지 확인하십시오. 특히 응용 프로그램의 PVC가 삭제되었는지 확인하십시오.

apiVersion: triliovault.trilio.io/v1
kind: Restore
metadata:
  name: ambassador-helm-release-restore
  namespace: ambassador
spec:
  source:
    type: Backup
    backup:
      name: ambassador-helm-release-full-backup
      namespace: ambassador
  skipIfAlreadyExists: true

다른 클러스터로 복원하는 경우(이전 시나리오) TrilioVault for Kubernetes가 원격 네임스페이스/클러스터에서 실행되도록합니다. 새 클러스터로 복원하는 경우(백업 CR이 존재하지 않는 곳), source.type을 location으로 설정해야합니다. Custom Resource Definition 복원 섹션을 참조하여 위치별 복원 예제를 확인하십시오.

• ambassador 네임스페이스를 삭제하면 대사 서비스와 관련된 로드 밸런서 리소스도 삭제됩니다. 따라서 ambassador 서비스를 복원할 때 DigitalOcean이 로드 밸런서를 다시 만듭니다. 문제는 LB에 새 IP 주소가 할당된다는 것입니다. 따라서 클러스터에 호스팅된 도메인으로 트래픽을 가져오기 위해 A 레코드를 조정해야합니다.
• 특정 백업을 복원하려면 Restore CRD를 만들어야합니다. 일반적인 복원 CRD는 다음과 같습니다:
• 이 구성에서,

spec.source.type: 어떤 백업 유형을 복원할지 지정합니다.

spec.source.backup: 복원할 백업 개체에 대한 참조를 포함합니다.

code 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-restore.yaml

spec.skipIfAlreadyExists: 복원하려는 리소스가 이미 복원된 네임스페이스에 있으면 복원을 건너뜁니까?

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/ambassador-helm-release-restore.yaml

복원은 애플리케이션의 마지막 성공적인 백업을 복원할 수 있게 합니다. 이는 백업 CRD로 보호된 단일 네임스페이스나 Helm 릴리스를 복원하는 데 사용됩니다. 백업 CRD는 ambassador-helm-release-full-backup이라는 이름으로 식별됩니다.

kubectl get restore ambassador-helm-release-restore -n ambassador

먼저, 스타터 킷 Git 저장소에서 복원 CRD 예제를 검사하십시오:

NAME                              STATUS      DATA SIZE   START TIME             END TIME               PERCENTAGE COMPLETED   DURATION
ambassador-helm-release-restore   Completed   0           2021-11-25T15:06:52Z   2021-11-25T15:07:35Z   100                    43.524191306s

그런 다음 kubectl을 사용하여 복원 리소스를 생성하십시오:

마지막으로, 복원 객체 상태를 검사하십시오:

출력은 다음과 비슷합니다. STATUS 열이 Completed로 설정되어 있고, PERCENTAGE COMPLETED가 100으로 설정되어 있음을 주목하십시오.

kubectl get all -n ambassador

출력이 이와 같은 모습이라면, ambassador Helm 릴리스 복원 프로세스가 성공적으로 완료된 것입니다.

NAME                                    READY   STATUS    RESTARTS   AGE
pod/ambassador-5bdc64f9f6-42wzr         1/1     Running   0          9m58s
pod/ambassador-5bdc64f9f6-nrkzd         1/1     Running   0          9m58s
pod/ambassador-agent-bcdd8ccc8-ktmcv    1/1     Running   0          9m58s
pod/ambassador-redis-64b7c668b9-69drs   1/1     Running   0          9m58s

NAME                       TYPE           CLUSTER-IP       EXTERNAL-IP     PORT(S)                      AGE
service/ambassador         LoadBalancer   10.245.173.90    157.245.23.93   80:30304/TCP,443:30577/TCP   9m59s
service/ambassador-admin   ClusterIP      10.245.217.211   <none>          8877/TCP,8005/TCP            9m59s
service/ambassador-redis   ClusterIP      10.245.77.142    <none>          6379/TCP                     9m59s

NAME                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/ambassador         2/2     2            2           9m59s
deployment.apps/ambassador-agent   1/1     1            1           9m59s
deployment.apps/ambassador-redis   1/1     1            1           9m59s

NAME                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/ambassador-5bdc64f9f6         2         2         2       9m59s
replicaset.apps/ambassador-agent-bcdd8ccc8    1         1         1       9m59s
replicaset.apps/ambassador-redis-64b7c668b9   1         1         1       9m59s

복원 후 응용 프로그램 무결성 확인

kubectl get hosts -n ambassador

ambassador 네임스페이스 리소스가 모두 적절한 위치에 있고 실행 중인지 확인하십시오:

NAME         HOSTNAME                   STATE   PHASE COMPLETED   PHASE PENDING   AGE
echo-host    echo.starter-kit.online    Ready                                     11m
quote-host   quote.starter-kit.online   Ready                                     11m

출력은 다음과 비슷합니다:

kubectl get mappings -n ambassador

ambassador 호스트를 가져옵니다:

NAME                          SOURCE HOST                SOURCE PREFIX                               DEST SERVICE     STATE   REASON
ambassador-devportal                                     /documentation/                             127.0.0.1:8500
ambassador-devportal-api                                 /openapi/                                   127.0.0.1:8500
ambassador-devportal-assets                              /documentation/(assets|styles)/(.*)(.css)   127.0.0.1:8500
ambassador-devportal-demo                                /docs/                                      127.0.0.1:8500
echo-backend                  echo.starter-kit.online    /echo/                                      echo.backend
quote-backend                 quote.starter-kit.online   /quote/                                     quote.backend

출력은 다음과 비슷합니다. STATE는 Ready이어야 하며, HOSTNAME 열은 완전한 호스트 이름을 가리켜야 합니다.

ambassador 매핑을 가져옵니다:

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

출력물은 다음과 유사합니다. echo-backend이 echo.starter-kit.online 호스트 및 /echo/ 소스 접두사에 매핑되어 있는 것을 주목하십시오. quote-backend에 대해서도 동일합니다.

이제 DigitalOcean 로드 밸런서 리소스가 다시 생성되어 새로운 외부 IP가 할당되었으므로 DNS A 레코드를 업데이트해야합니다.

마지막으로 백엔드 응용 프로그램이 HTTP 요청에 응답하는지 확인하십시오. Starter Kit 튜토리얼에서 사용된 백엔드 응용 프로그램에 대해서는 Ambassador Edge Stack 백엔드 서비스 만들기를 참조하십시오.

다음 단계는 전체 클러스터 백업 및 복원을 다룹니다.

단계 5 – 전체 클러스터 백업 및 복원 예제

A typical ClusterBackupPlan manifest targeting multiple namespaces looks like this:

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: starter-kit-cluster-backup-plan
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
  backupComponents:
    - namespace: ambassador
    - namespace: backend
    - namespace: monitoring

이 단계에서는 재해 복구 시나리오를 시뮬레이션합니다. 전체 DOKS 클러스터가 삭제되고 중요한 응용 프로그램이 이전 백업에서 복원됩니다.

DOKS 클러스터 백업 생성

cd Kubernetes-Starter-Kit-Developers

여기의 주요 아이디어는 모든 중요한 애플리케이션 및 구성을 보유하는 모든 중요한 이름 공간을 포함하여 DOKS 클러스터 백업을 수행하는 것입니다.

code 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup-plan.yaml
code 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup.yaml

kube-system(또는 다른 DOKS 클러스터 관련 이름 공간)이 목록에 포함되지 않았음을 주목하십시오. 일반적으로, 특별한 설정이 해당 수준에서 지속되어야하는 특별한 경우를 제외하고는 필요하지 않습니다.

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup-plan.yaml
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/starter-kit-cluster-backup.yaml

먼저, 로컬 머신에 Starter Kit Git 리포지토리가 복제된 디렉토리를 변경하십시오:

kubectl get clusterbackupplan starter-kit-cluster-backup-plan -n tvk

그런 다음, 선택한 편집기(가능하면 YAML 린트 지원이 있는 것이 좋습니다)를 사용하여 Starter Kit 리포지토리에 제공된 ClusterBackupPlan 및 ClusterBackup 매니페스트 파일을 열고 검사하십시오.

NAME                              TARGET             ...   STATUS
starter-kit-cluster-backup-plan   trilio-s3-target   ...   Available

마지막으로, kubectl을 사용하여 ClusterBackupPlan 및 ClusterBackup 리소스를 생성하십시오:

kubectl get clusterbackup starter-kit-cluster-backup -n tvk

이제 kubectl을 사용하여 ClusterBackupPlan 상태를 검사하십시오:

NAME                        BACKUPPLAN                        BACKUP TYPE   STATUS      ...   PERCENTAGE COMPLETE
starter-kit-cluster-backup  starter-kit-cluster-backup-plan   Full          Available   ...   100

출력은 다음과 유사합니다. STATUS 열 값이 Available로 설정되어야 함을 주목하십시오.

출력은 다음과 유사합니다. STATUS 열 값이 Available로 설정되어야하며, PERCENTAGE COMPLETE가 100으로 설정되어 있어야 함을 주목하십시오.

위의 출력이 위와 같은 경우 모든 중요한 애플리케이션 이름 공간이 성공적으로 백업되었습니다.

이름 공간 및 관련 리소스가 포함되는 프로세스에 참여하는 이름 공간 및 관련 리소스의 수에 따라 전체 클러스터 백업이 완료되는 데 시간이 걸릴 수 있습니다.

웹 콘솔의 주요 대시보드를 열고 다중 네임스페이스 백업을 검사할 수도 있습니다(백업된 모든 중요한 네임스페이스가 녹색으로 강조되어 있음을 주목하세요, 꿀벌 모양의 구조로):

doctl kubernetes cluster delete <DOKS_CLUSTER_NAME>

DOKS 클러스터 다시 만들기 및 응용프로그램 복원

기억해야 할 중요한 점은 DOKS 클러스터를 파괴하고 다시 복원할 때마다 TVK가 인그레스 컨트롤러를 복원할 때 새로운 로드 밸런서와 새로운 외부 IP가 생성된다는 것입니다. 따라서 DigitalOcean DNS A 레코드를 적절히 업데이트하십시오.

이제 전체 DOKS 클러스터를 삭제하십시오(<> 플레이스홀더를 적절히 대체하십시오):

다음으로 DigitalOcean Kubernetes 설정에 설명된대로 클러스터를 다시 만듭니다.

복원 작업을 수행하려면 단계 1 – Kubernetes용 TrilioVault 설치에 설명된대로 TVK 애플리케이션을 설치해야 합니다. 동일한 Helm 차트 버전을 사용하는 것이 중요합니다.

설치가 성공적으로 완료되면 백업 데이터가 있는 동일한 S3 버킷을 가리키도록 설명된대로 TVK 대상을 구성하십시오. 또한 대상 브라우징이 활성화되어 있는지 확인하십시오.

다음으로, TrilioVault 애플리케이션 라이선싱 섹션에 설명된대로 새 라이선스를 확인하고 활성화하십시오.

웹 콘솔 사용자 인터페이스에 액세스하려면 TVK 웹 관리 콘솔에 액세스하는 방법 섹션을 참조하십시오.

그런 다음 리소스 관리 -> TVK 네임스페이스 -> 대상으로 이동하십시오(스타터 킷의 경우 TVK 네임스페이스는 tvk입니다):

더 나아가서 대상을 탐색하고 작업 버튼을 클릭하여 사용 가능한 백업 목록을 표시하십시오. 그런 다음 팝업 메뉴에서 브라우저 시작 옵션을 선택하십시오. 이 작업을 수행하려면 대상에 enableBrowsing 플래그가 true로 설정되어 있어야 합니다.

이제 목록에서 starter-kit-cluster-backup-plan 항목을 클릭한 다음 오른쪽 하위 창에서 starter-kit-cluster-backup 항목을 클릭하여 확장하십시오:

kubectl get all --all-namespaces

복원 프로세스를 시작하려면 복원 버튼을 클릭하십시오.

DOKS 클러스터 애플리케이션 상태 확인

curl -Li http://quote.starter-kit.online/quote/
curl -Li http://echo.starter-kit.online/echo/

먼저, 모든 클러스터 Kubernetes 리소스를 확인하십시오.

그런 다음 DNS A 레코드가 새 로드 밸런서 외부 IP를 가리키도록 업데이트되었는지 확인하십시오.

마지막으로, 백엔드 애플리케이션은 HTTP 요청에 응답해야합니다. 스타터 킷 자습서에서 사용하는 백엔드 애플리케이션에 대한 자세한 내용은 대사자 엣지 스택 백엔드 서비스 생성을 참조하십시오.

다음 단계에서는 DOKS 클러스터 애플리케이션에 대한 예약 (또는 자동) 백업을 수행하는 방법을 알아보겠습니다.

kind: Policy
apiVersion: triliovault.trilio.io/v1
metadata:
  name: scheduled-backup-every-5min
  namespace: tvk
spec:
  type: Schedule
  scheduleConfig:
    schedule:
      - "*/5 * * * *" 단계 6 - 예약된 백업

일정에 따라 자동으로 백업을 수행하는 것은 매우 유용한 기능입니다. 시스템을 이전의 작동 상태로 되돌릴 수 있으므로 무언가 잘못되었을 때 시간을 되감을 수 있습니다. 이 섹션에서는 5분 간격으로 자동 백업하는 예제를 제공합니다 (kube-system 네임 스페이스가 선택되었습니다).

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: kube-system-ns-backup-plan-5min-schedule
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
    schedulePolicy:
      fullBackupPolicy:
        name: scheduled-backup-every-5min
        namespace: tvk
  backupComponents:
    - namespace: kube-system
    - namespace: backend

먼저 Linux cron과 동일한 cron 형식으로 백업 일정을 정의하는 Schedule 유형의 Policy CRD를 만들어야 합니다. 일정 정책은 BackupPlan 또는 ClusterBackupPlan CRD에 사용할 수 있습니다. 전형적인 일정 정책 CRD는 아래와 같이 보입니다 (5분 일정을 정의함):

# 매 5분마다 트리거됨

다음으로, 아래에 표시된 예와 같이 ClusterBackupPlan CRD에 일정 정책을 적용할 수 있습니다:

kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/scheduled-backup-every-5min.yaml

기본 ClusterBackupPlan CRD임을 알 수 있습니다. spec.backupConfig.schedulePolicy 필드를 통해 이전에 정의한 Policy CRD를 참조합니다. 전체 또는 점진적 백업용으로 별도의 정책을 만들어 사용할 수 있으므로 fullBackupPolicy 또는 incrementalBackupPolicy를 지정할 수 있습니다.

kubectl get policies -n tvk

이제 시작자 키트 자습서에서 제공된 샘플 매니페스트를 사용하여 일정 Policy를 만들어 주십시오.

NAME                          POLICY     DEFAULT
scheduled-backup-every-5min   Schedule   false

로컬 머신에 스타터 키트 Git 저장소를 복제한 디렉터리로 이동하십시오.

정책 리소스가 생성되었는지 확인하십시오:
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/kube-system-ns-backup-plan-scheduled.yaml

다음과 유사한 출력이 나타납니다. POLICY 유형이 Schedule로 설정되어 있는 것을 주목하십시오.
kubectl apply -f 05-setup-backup-restore/assets/manifests/triliovault/kube-system-ns-backup-scheduled.yaml

마지막으로, kube-system 네임스페이스에 대한 예약된 백업을 위한 리소스를 생성하십시오:

kubectl get clusterbackupplan kube-system-ns-backup-plan-5min-schedule -n tvk

# 먼저 kube-system 네임스페이스용 백업 계획을 생성합니다

NAME                                       TARGET             ...   FULL BACKUP POLICY            STATUS
kube-system-ns-backup-plan-5min-schedule   trilio-s3-target   ...   scheduled-backup-every-5min   Available

# kube-system 네임스페이스에 대한 예약된 백업 생성 및 트리거

kubectl get clusterbackup kube-system-ns-full-backup-scheduled -n tvk

kube-system의 예약된 백업 계획 상태를 확인하십시오:

NAME                                   BACKUPPLAN                                 BACKUP TYPE   STATUS      ...
kube-system-ns-full-backup-scheduled   kube-system-ns-backup-plan-5min-schedule   Full          Available   ...

결과는 다음과 유사합니다. 이전에 생성된 scheduled-backup-every-5min 정책 리소스로 설정된 FULL BACKUP POLICY 값 및 STATUS는 Available 여야 합니다.

kube-system의 예약된 백업 상태를 확인하십시오:

결과는 다음과 유사합니다. 이전에 생성된 백업 계획 리소스로 설정된 BACKUPPLAN 값 및 STATUS는 Available 여야 합니다.

다음 단계에서는 백업 보유 정책을 설정하는 방법을 배우게 됩니다.

단계 7 – 백업 보유 정책

apiVersion: triliovault.trilio.io/v1
kind: Policy
metadata:
  name: sample-policy
spec:
  type: Retention
  retentionConfig:
    latest: 2
    weekly: 1
    dayOfWeek: Wednesday
    monthly: 1
    dateOfMonth: 15
    monthOfYear: March
    yearly: 1

보유 정책을 사용하면 규정 요구 사항에 따라 보유할 백업 수와 백업을 삭제할 주기를 정의할 수 있습니다. 보유 정책 CRD는 일, 주, 월, 년, 최신 등의 용어로 보유할 백업 수를 정의하는 간단한 YAML 사양을 제공합니다.

• 보존 정책 사용하기
• 보존 정책은 BackupPlan 또는 ClusterBackupPlan CRD에 사용될 수 있습니다. Retention 유형의 전형적인 Policy 매니페스트는 다음과 같습니다:
• 위의 보존 정책은 다음과 같이 번역됩니다:
• 매주 수요일마다 하나의 백업 유지합니다.

매월 15일에 하나의 백업을 유지합니다.

A typical ClusterBackupPlan example configuration that has a retention set looks like:

apiVersion: triliovault.trilio.io/v1
kind: ClusterBackupPlan
metadata:
  name: kube-system-ns-backup-plan-5min-schedule
  namespace: tvk
spec:
  backupConfig:
    target:
      name: trilio-s3-target
      namespace: tvk
    retentionPolicy:
      fullBackupPolicy:
        name: ambassador-backups-retention-policy
        namespace: tvk
  backupComponents:
    - namespace: kube-system
    - namespace: backend

매년 3월마다 하나의 백업을 유지합니다.

전체적으로, 최근에는 2개의 백업이 있어야 합니다.

보존 정책 리소스를 생성하는 기본적인 흐름은 예약된 백업과 동일합니다. 보존 정책을 참조하려면 BackupPlan 또는 ClusterBackupPlan CRD가 정의되어야 하며, 그런 다음 프로세스를 트리거할 Backup 또는 ClusterBackup 개체가 있어야 합니다.

apiVersion: triliovault.trilio.io/v1
kind: Policy
metadata:
  name: garbage-collect-policy
spec:
  type: Cleanup
  cleanupConfig:
    backupDays: 5

해당 정책을 참조하기 위해 retentionPolicy 필드를 사용합니다. 물론 예약된 백업을 수행하고 보존 전략을 처리하기 위해 두 유형의 정책이 설정된 백업 계획을 가질 수 있습니다.

정리 정책 사용하기

사용되지 않는 모든 객체를 정리하는 방법이 필요합니다. 이를 위해 Cleanup Policy CRD를 도입해야 합니다:

위의 정리 정책은 TVK 설치 네임스페이스에 정의되어야 합니다. 그런 다음, backupdays 값에 기반하여 매 30분마다 실행되는 크론 작업이 자동으로 생성됩니다.

결론

• 이 튜토리얼에서는 일회성 백업 및 예약된 백업을 수행하는 방법과 모든 것을 복원하는 방법에 대해 배웠습니다.
• 이 튜토리얼에서 설명한 모든 기본 작업 및 작업은 TrilioVault for Kubernetes가 무엇을 할 수 있는지에 대한 기본 소개와 이해를 제공하기 위한 것입니다.
• 자세히 알아보기

Velero를 사용하여 DOKS 데이터 백업 및 복원