day26 : k8s backup/restore/migrate with velero(上)

花了将近一个月的时间在k8s上建置各种服务，虽然大部分都是无状态的服务可以随时重建也不影响运行，不过大部分公司还是会希望进行备份，所以在k8s上通常会做到底层的备份、etcd备份，这两种备份是对整个集群状态的备份，如果要细分到pod、namespace就没有办法，因此今天会介绍一套k8s的备份/还原/升级工具velero。

velero是一套k8s的备份还原工具，透过crd的方式将k8s上的资源进行备份和还原作业，安装velero之後将会有以下crd

1. backups.velero.io
2. backupstoragelocations.velero.io
3. deletebackuprequests.velero.io
4. downloadrequests.velero.io
5. podvolumebackups.velero.io
6. podvolumerestores.velero.io
7. resticrepositories.velero.io
8. restores.velero.io
9. schedules.velero.io
10. serverstatusrequests.velero.io
11. volumesnapshotlocations.velero.io

透过crd可以观察到，velero会将备份和还原都视为一种resource，根据resource的定义备份哪些namespace或是pod，同时将备份的资料存到定义的storage(例如s3、minio)，所以如果想要还原，就也要在cluster上安装velero并且连到有备份档案的storage让velero能够restore；而velero 与重新透过yaml或是gitops的方式布署服务来还原其中最大的差异在於restic这个参数，当启用了restic的备份，就可以将pod的实际volume也备份起来(不包含hostpath)，想要观察restic的话，会发现有启用restic的话会有一个restic的daemonset在每个node上运行唷，所以可以知道当velero收到备份的resource时，会像下图一样的流程由一个backup controller把相关的资讯备份上传。

而velero的用处也不仅止於backup / restore，其实他最初的用意是当有升级或是移转的需求时可以用velero将resources转移到新的cluster，所以velero也能够支援异平台的转移，像是地端k8s转移到gke、eks上，openshift转移到gke上，有些会需要用额外的工具达成，而vmware在收购了velero後也有推出许多相关的工具，有兴趣的人也可以研读TMC相关的文件。

但是回归源头，还是希望各位反思，自己是否真的有backup的需求，如果服务都是无状态的并且透过gitops或是有将yaml进行保存，那麽当k8s有发生异常/损毁时，重新布署跟透过velero还原或是etcd还原，到底有没有需要用到velero呢？