Kubernetes 백업 솔루션 Veeam Kasten 검증한 내용 공유해 드립니다. Kube PVC 백업은 아직 많이 사용 안 하시거나 오픈소스 Velero 혹은 다른 상용 솔루션 사용하시는 것 같은데, Kasten은 나름 장점이 있는 솔루션 같습니다.
라이선스는 커뮤니티 에디션이 있어 무료로 사용도 가능합니다. Enterprise 라이선스 구매하는 경우 저희가 파트너라 기술 지원이 가능합니다.
참고로 Kasten 구매하시면 저희가 Kube 교육도 가능합니다. ^^
https://jerryljh.tistory.com/12
솔루션 공식 홈페이지 : https://www.kasten.io/veeam
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
(오픈 소스 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
'쿠버네티스 일반 > Kasten' 카테고리의 다른 글
Kasten - Kubernetes 백업 및 복구 Demo (1) | 2021.08.05 |
---|---|
Kasten - Grafana 및 EKS MySQL 서비스 복구 검증 (0) | 2021.07.15 |
Veeam Kasten - On-Prem to Azure AKS 이전 (0) | 2021.06.28 |