쿠버네티스 일반/Kasten

Kube 백업 - Veeam Kasten 테스트 내역 공유

Jerry_이정훈 2021. 6. 23. 04:12
728x90

Kubernetes 백업 솔루션 Veeam Kasten 검증한 내용 공유해 드립니다. Kube PVC 백업은 아직 많이 사용 안 하시거나 오픈소스 Velero 혹은 다른 상용 솔루션 사용하시는 것 같은데, Kasten은 나름 장점이 있는 솔루션 같습니다. 

 

라이선스는 커뮤니티 에디션이 있어 무료로 사용도 가능합니다. Enterprise 라이선스 구매하는 경우 저희가 파트너라 기술 지원이 가능합니다.

 

참고로 Kasten 구매하시면 저희가 Kube 교육도 가능합니다. ^^

https://jerryljh.tistory.com/12

 

00. Kube 교육 - 개요 및 목차

Why Kube 교육 제가 생각하기에 기업 환경의 Kubernetes 도입의 핵심은 내재화 입니다. 기존 상용 Solution 혹은 SI Project 처럼 ‘명령어는 업체가 고객은 지시만(라고 쓰고 갈구기)’ 하면 100% 망합니다.

jerryljh.tistory.com

솔루션 공식 홈페이지 : https://www.kasten.io/veeam

 

Veeam

Kasten joins Veeam. Together, we offer enterprise operations teams an easy-to-use, scalable, & secure system for Kubernetes backup & application mobility.

www.kasten.io

TL;DR

  • 별도 백업 서버 없이 Kube Cluster 내 kasten-io Namespace로 설치되어 비용 및 보안, 속도 측면에서 우위 
  • StorageClass Snapshot 기반으로 백업 및 복구 속도 월등한 향상
  • Public Cloud to On-Prem(또는 반대), AWS to Naver/NHN 등 클라우드 간 Migration 용도로 적합
    : PVC 뿐만 아니라 Kube 전체 Object(Secret, CM, RBAC 등 전체) 복구 가능
  • 편리한 GUI로 별도 사용자 교육 없이 백업 정책 생성 및 복구 작업 수행 가능 

대시보드

  • 직관적으로 현재 백업 현황 Summary, 백업/복구 작업 리스트 및 소요 시간, Snapshot Schedule 및 보관 주기 설정 등을 작업을 별도 사용자 교육 없이 빠르게 실행 가능

 

 

먼저, Kasten은 StorageClass(또는 SC)의 Snapshot 기능을 활용합니다. 따라서 Snapshot을 지원하는 SC를 사용하시는 것을 권고합니다. (Snapshot이 지원하지 않는 경우 Sidecar 방식 generic 백업 옵션을 사용합니다.)

 

설치에 앞서 먼저 StorageClass에서 Snapshot 지원 여부를 확인해 보겠습니다. 저는 아래 StorageClass 중 오픈소스인 rook-ceph-block을 사용 하였습니다. (처음 cstor-csi 사용하였으나 백업은 정상적이나 복구가 안되었습니다.) 만약, 기존 사용하시는 상용 스토리지가 CSI Snapshot을 지원하지 않으면 오픈소스 rook-ceph 사용을 권고합니다. (필요하면 저희가 rook-ceph 기술 지원 가능합니다.)

[spkr@erdia22 01.rollout (ubuns:kasten-io)]$ k get sc
NAME                        PROVISIONER                                                RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
cstor-csi                   cstor.csi.openebs.io                                       Delete          Immediate              true                   24h
openebs-device              openebs.io/local                                           Delete          WaitForFirstConsumer   false                  4d23h
openebs-hostpath            openebs.io/local                                           Delete          WaitForFirstConsumer   false                  4d23h
openebs-jiva-default        openebs.io/provisioner-iscsi                               Delete          Immediate              false                  4d23h
openebs-snapshot-promoter   volumesnapshot.external-storage.k8s.io/snapshot-promoter   Delete          Immediate              false                  4d23h
rook-ceph-block             rook-ceph.rbd.csi.ceph.com                                 Delete          Immediate              true                   4h54m

Kasten 지원 가능한 Kube Storage 리스트 입니다.  

https://docs.kasten.io/latest/install/storage.html

 

Storage Integration — K10 4.0.5 documentation

For each CSI driver, ensure that a VolumeSnapshotClass has been added with K10 annotation (k10.kasten.io/is-snapshot-class: "true"). Note that CSI snapshots are not durable. In particular, CSI snapshots have a namespaced VolumeSnapshot object and a non-nam

docs.kasten.io

(오픈 소스 rook-ceph 설치 관련 내용은 다른 포스팅에서 설명 드리 겠습니다.)

 

Ceph 설치 후 VolumeSnapshotClass YAML 파일에 k10 관련 annotation을 추가 합니다. 향후 Kasten에서 해당 snapshot class를 이용 snapshot을 생성하는 용도로 사용 합니다.

[spkr@erdia22 05.volume (ubuns:kasten-io)]$ k get volumesnapshotclasses.snapshot.storage.k8s.io csi-rbdplugin-snapclass -o yaml |k neat > ceph-snapclass.yml
(k neat tool 없으신 경우 생략하셔도 됩니다.)

YAML 파일 Annotation 추가

apiVersion: snapshot.storage.k8s.io/v1
deletionPolicy: Delete
driver: rook-ceph.rbd.csi.ceph.com
kind: VolumeSnapshotClass
metadata:
  name: csi-rbdplugin-snapclass
  annotations:
    k10.kasten.io/is-snapshot-class: "true"
    snapshot.storage.kubernetes.io/is-default-class: "true"
parameters:
  clusterID: rook-ceph
  csi.storage.k8s.io/snapshotter-secret-name: rook-csi-rbd-provisioner
  csi.storage.k8s.io/snapshotter-secret-namespace: rook-ceph
  • metadata.annotations 부분을 추가하고 적용(apply) 합니다.
[spkr@erdia22 k10-4.0.3 (ubuns:kasten-io)]$ k apply -f ceph-snapclass.yml 

snapshotClass Annotation 정상 적용 여부는 kasten에서 제공하는 사전 확인 스크립트로 검증합니다.

[spkr@erdia22 01.rollout (ubuns:kasten-io)]$  curl https://docs.kasten.io/tools/k10_primer.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  6072  100  6072    0     0   1028      0  0:00:05  0:00:05 --:--:--  1383
Namespace option not provided, using default namespace
Checking for tools
 --> Found kubectl
 --> Found helm
Checking if the Kasten Helm repo is present
 --> The Kasten Helm repo was found
Checking for required Helm version (>= v3.0.0)
 --> No Tiller needed with Helm v3.6.0

(생략)

rook-ceph.rbd.csi.ceph.com:
  Is a CSI Provisioner  -  OK
  Storage Classes:
    rook-ceph-block
      Valid Storage Class  -  OK
  Volume Snapshot Classes:
    csi-rbdplugin-snapclass
      Has k10.kasten.io/is-snapshot-class annotation set to true  -  OK
      Has deletionPolicy 'Delete'  -  OK
    k10-clone-csi-rbdplugin-snapclass

(생략)

serviceaccount "k10-primer" deleted
clusterrolebinding.rbac.authorization.k8s.io "k10-primer" deleted
job.batch "k10primer" deleted

중간 부문에 annotation check OK가 되어야 정상적으로 복구가 가능합니다. 확인 꼭 해 주세요 ^^
 
 Volume Snapshot Classes:
    csi-rbdplugin-snapclass
      Has k10.kasten.io/is-snapshot-class annotation set to true  -  OK

이제 준비가 완료되었습니다. Helm을 이용하여 kasten 설치합니다.

[spkr@erdia22 66.fioKubestr (spkcluster:default)]$ helm repo add kasten https://charts.kasten.io/
"kasten" has been added to your repositories

[spkr@erdia22 01.rollout (ubuns:kasten-io)]$ helm pull kasten/k10

각 상황에 맞게 Helm Chart의 Values.yml 파일을 수정합니다. 저는 default로 설치 하였습니다.

[spkr@erdia22 k10-4.0.3 (spkcluster:kasten-io)]$ helm install k10 -f my-values.yaml .
NAME: k10
LAST DEPLOYED: Sat Jun  5 05:09:16 2021
NAMESPACE: kasten-io
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing Kasten’s K10 Data Management Platform!

Documentation can be found at https://docs.kasten.io/.

How to access the K10 Dashboard:



The K10 dashboard is not exposed externally. To establish a connection to it use the following `kubectl` command:

`kubectl --namespace kasten-io port-forward service/gateway 8080:8000`

The Kasten dashboard will be available at: `http://127.0.0.1:8080/k10/#/`

대시보드를 외부에서 접속 가능 하도록 gateway service 타입을 Nodeport로 변경 합니다. 

[spkr@erdia22 k10-4.0.3 (ubuns:kasten-io)]$ k get svc -n kasten-io gateway -o yaml |k neat > kasten-gateway-svc.yml

apiVersion: v1
kind: Service
metadata:
  annotations:
    getambassador.io/config: |
      ---
      apiVersion: ambassador/v1
      kind:  AuthService
      name:  authentication
      auth_service: "auth-svc:8000"
      path_prefix: "/v0/authz"
      allowed_request_headers:
      - "x-forwarded-access-token"
      ---
      apiVersion: ambassador/v1
      kind:  Module
      name:  ambassador
      config:
        service_port: 8000
    meta.helm.sh/release-name: k10
    meta.helm.sh/release-namespace: kasten-io
  labels:
    app: k10
    app.kubernetes.io/instance: k10
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: k10
    helm.sh/chart: k10-4.0.3
    heritage: Helm
    release: k10
    service: gateway
  name: gateway
  namespace: kasten-io
spec:
  type: NodePort
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - name: http
    port: 8000
    nodePort: 30800
  selector:
    service: gateway
  • type:NodePort - spec.type을 NodePort(혹은 LoadBalancer) 변경
  • nodePort:30800 - nodePort를 특정 Port로 지정하시면 서비스 재시작 시 동일 Port로 지정되어 편리합니다.

변경 내용 적용합니다.

[spkr@erdia22 k10-4.0.3 (ubuns:kasten-io)]$ k apply -f kasten-gateway-svc.yml

이제 사용자 PC에서 대시보드 접속이 가능합니다.

  • port 번호 및 전체 URL(/k10/#/)까지 붙여 줍니다.

백업 정책 설정에 앞서 백업 및 복구에 사용할 Deployment와 PVC를 생성합니다.

 

default-pvc.yml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: default01-pvc
  namespace: test
spec:
  accessModes:
  - ReadWriteOnce  ## block accessmode 지정 
  resources:
    requests:
      storage: 10Gi
  storageClassName: "rook-ceph-block" 

date-pvc-deploy.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: date-pod
  namespace: test
  labels:
    app: date
spec:
  replicas: 1
  selector:
    matchLabels:
      app: date
  template:    
    metadata:
      labels:
        app: date
    spec:
      containers:
      - name: date-pod
        image: busybox
        command:
        - "/bin/sh"
        - "-c"
        - "while true; do date >> /data/pod-out.txt; cd /data; sync; sync; sleep 30; done"
        volumeMounts:  
        - name: date-vol  # Volume 이름
          mountPath: /data  # Mount 이름 
      volumes:  # 어떤 Volume을 사용할 것인지
      - name: date-vol
        persistentVolumeClaim:
          claimName: default01-pvc   
  • 현재 시간(date)을 /data/pod-out.txt로 출력하여 백업, 복구 정상 여부를 확인하기 위한 간단히 스크립트를 추가 하였습니다. 
[spkr@erdia22 05.volume (ubuns:kasten-io)]$ k create ns test
[spkr@erdia22 05.volume (ubuns:kasten-io)]$ k apply -f default-pvc.yml 
kpersistentvolumeclaim/default01-pvc created
[spkr@erdia22 05.volume (ubuns:kasten-io)]$ k apply -f date-pvc-deploy.yml 

이제, 백업 정책을 설정 하겠습니다. GUI 대시보드 Application 선택하시고 test 네임스페이스를 클릭 합니다.

 

‘Create a Policy’ 클릭하시면 상세 정책 설정이 가능합니다. 화면 중앙 ‘Show Advanced Frequency Options’를 선택하시면 상세 Snapshot 생성 시간 설정이 가능합니다. 

Snapshot 보관 주기 설정 입니다. Snapshot은 변경된 내역 즉 증분 백업만 저장되므로 실제 사용하는 스토리지 용량이 작습니다. 하지만 Primary Storage에 저장되므로 스토리지 용량 설정이 필요합니다. 개별 상황에 맞게 보관 주기를 Default 옵션에서 아래와 같이 조정하시는 것을 권고 합니다. (Export로 옵션을 이용하여 저렴한 외장 NAS 스토리지 저장 역시 가능합니다.)

Application Resource 전체(ConfigMap, ServiceAccount 등 전체 Kube Object)도 가능하고 PVC Volume만 선택도 가능합니다. 

아래 YAML 파일을 클릭하시면 상세 YAML 파일으로 백업 내용 확인 가능합니다.

YAML 역시 직관적입니다. 

‘Create Policy’ 클릭하시면 정상적으로 백업이 적용됩니다. 

대시보드 Policies 에서 해당 작업 내용 확인이 가능합니다.

화면 중간 ‘run once’를 클릭하여 복구 테스트를 진행 하겠습니다.

 

대시보드 화면으로 돌아가서 화면 중간 ‘Actions’를 확인하면 Backup 작업의 상세한 내역을 확인 가능합니다.

  • 성공적으로 Backup 작업이 수행 되었습니다.

이제 복구 테스트를 해 보겠습니다.

 

Applications 클릭하시고 test의 restore 옵션을 선택합니다. (저는 이전 백업 내역이 있어 ‘restore, 15’라고 표시되지만 처음이면 ‘1’ 이라고 표시됩니다.)

복구 시점을 선택하고 복구 작업을 실행 합니다. 지금은 Data만 복구 하므로 ‘Data-Only Restore’ 옵션을 선택 합니다. 

 

 



참고로 원격지 클러스터 마이그레이션 용도 등으로 사용하는 경우 아래와 같이 Namespace 단위 전체 Object 복구 가능합니다. (Kube 클러스터 간 마이그레이션 작업은 다른 포스팅에서 다루겠습니다.)

복구 작업을 실시하면 기존 PVC가 이전 snapshot 상태의 PVC로 변경 됩니다. 따라서 POD도 새로운 PVC 할당을 위하여 같이 내렸다 올라오며 새로운 POD로 실행 됩니다.

 

먼저 PVC가 새롭게 생성됩니다.

[spkr@erdia22 02.django (ubuns:test)]$ k get pvc -n test -w
NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
default01-pvc   Bound    pvc-b2207507-ebb6-44a0-8532-e32b02080dd2   10Gi       RWO            rook-ceph-block   12h
default01-pvc   Terminating   pvc-b2207507-ebb6-44a0-8532-e32b02080dd2   10Gi       RWO            rook-ceph-block   12h
default01-pvc   Terminating   pvc-b2207507-ebb6-44a0-8532-e32b02080dd2   10Gi       RWO            rook-ceph-block   12h
default01-pvc   Pending                                                                            rook-ceph-block   0s
default01-pvc   Pending                                                                            rook-ceph-block   0s
default01-pvc   Pending       pvc-c74fb6ad-2e5a-4817-ad9c-9da4668992cb   0                         rook-ceph-block   1s
default01-pvc   Bound         pvc-c74fb6ad-2e5a-4817-ad9c-9da4668992cb   10Gi       RWO            rook-ceph-block   1s

POD 역시 새로운 PVC를 붙여야 하므로 새롭게 생성됩니다. Application에 따라서 복구 시간은 달라 집니다.

[spkr@erdia22 k10-4.0.3 (ubuns:test)]$ k get pod -n test -w
NAME                        READY   STATUS    RESTARTS   AGE
date-pod-7d6b6bb5cc-995hv   1/1     Running   0          12h

date-pod-7d6b6bb5cc-995hv   1/1     Terminating   0          12h
date-pod-7d6b6bb5cc-995hv   1/1     Terminating   0          12h
date-pod-7d6b6bb5cc-995hv   0/1     Terminating   0          12h
date-pod-7d6b6bb5cc-995hv   0/1     Terminating   0          12h
date-pod-7d6b6bb5cc-995hv   0/1     Terminating   0          12h
date-pod-7d6b6bb5cc-8dtwp   0/1     Pending       0          0s
date-pod-7d6b6bb5cc-8dtwp   0/1     Pending       0          0s
date-pod-7d6b6bb5cc-8dtwp   0/1     Pending       0          2s
date-pod-7d6b6bb5cc-8dtwp   0/1     ContainerCreating   0          2s
date-pod-7d6b6bb5cc-8dtwp   0/1     ContainerCreating   0          6s
date-pod-7d6b6bb5cc-8dtwp   1/1     Running             0          11s

그럼, 데이터가 정상적으로 복구 되었는지 확인해 보겠습니다.

[spkr@erdia22 k10-4.0.3 (ubuns:test)]$ k exec -it date-pod-7d6b6bb5cc-8dtwp -- cat /data/pod-out.txt
(생략)
Tue Jun 22 16:42:26 UTC 2021
Tue Jun 22 16:45:39 UTC 2021

UTC 기준 시간 입니다. 

위와 같이 이전 데이터까지 정상적으로 복구되고 새로운 데이터 역시 정상적으로 저장되는 것을 확인 가능합니다. 

 

이상 Kasten 설치, 백업, 복구에 대하여 알아 보았습니다. 편리한 GUI로 추가 교육 없이 사용자가 편하게 사용 할 수 있다는 것이 경쟁 솔루션 대비 가장 큰 장점 같습니다.

 

Kubernetes 컨설팅, 교육, 기술 지원 문의 : leejunghoon@spkr.co.kr 

반응형