使用Velero备份还原Kubernetes集群

Velero之前对应用程序状态进行快照的理想选择。

按需备份

按需备份操作可以将复制的Kubernetes对象的压缩文件上传到云对象存储，或者调用云环境提供的API创建持久卷的磁盘快照我们可以选择指定备份期间要执行的备份挂钩例如，在拍摄快照之前，您可能需要告诉数据库将其内存中的缓冲区刷新到磁盘

计划备份

通过定期操作，我们可以定期备份数据第一次备份将在首次创建计划时执行，后续备份将按计划指定的时间间隔执行，该时间间隔由Cron表达式指定

计划备份保存的名称为—，其中格式为YYYYMMDDhhmmss。

备份还原

通过恢复操作，我们可以从以前创建的备份中恢复所有对象和持久卷此外，我们只能恢复对象和持久卷的子集Velero支持多命名空间重映射例如，在恢复操作中，命名空间abc中的对象可以在命名空间def下重新创建，或者命名空间123中的对象可以在456下重新创建

还原的默认名称为—，格式为YYYYMMDDhhmmss您也可以指定自定义名称恢复的对象还包括带有关键velero.io/restore—name和值的标签

默认情况下，备份存储位置以读写模式创建，但是，在恢复期间，备份存储位置可以配置为只读模式，这将禁用在此存储位置创建和删除备份，这对于确保在恢复方案期间不会无意中创建或删除备份非常有用此外，我们还可以选择指定在恢复资源期间或之后要执行的恢复挂钩，例如，我们可能需要在数据库应用程序容器启动之前执行自定义的数据库恢复操作

备份过程

当执行命令velero backup create test—backup时，将执行以下操作:

Velero客户端调用Kubernetes APIServer来创建备份，这是一个CRD对象，备份控制器会一直监视，直到创建并验证新的备份对象备份控制器开始执行备份，并查询APIServer以获取用于备份的资源收集数据备份控制器调用对象存储服务，例如S3上传备份文件

默认情况下，velero backup create支持任何持久卷的磁盘快照，可以通过指定其他参数来调整这些快照，也可以通过使用— snapshot—volumes=false=false选项来禁用这些快照。

设置备份到期时间。

创建备份时，可以通过添加标志— ttl来指定TTL如果未指定，默认TTL值将为30天

备份资源从云对象存储备份文件所有持久卷快照所有关联的恢复同步对象存储。

备份位置和卷快照位置。

Velero有两个自定义资源，BackupStorageLocation和VolumeSnapshotLocation，用于配置Velero备份及其关联的持久卷快照的存储位置。

BackupStorageLocation:被定义为存储区域，存储所有Velero数据的存储区域中的前缀以及一组其他特定于提供商的字段，这将在下一节中详细描述VolumeSnapshotLocation:完全由提供程序提供的特定字段定义

用户可以预配置一个或多个可能的备份存储位置对象，或者一个或多个卷快照位置对象，并选择创建备份时备份和相关快照的存储位置。

这种配置设计支持许多不同的用途，包括:

在单个Velero备份中创建多个持久卷的快照例如，在同时具有EBS卷和Portworx卷的群集中，数据会备份到不同区域的不同存储中对于支持它的卷提供商来说，一些快照可以存储在本地集群中，而其他快照可以存储在云中进行安装

在Github Release页面下载指定的velero二进制客户端安装包，比如这里我们下载了最新的稳定版本v1.6.3，

将根目录下的velero二进制文件复制到PATH下的:

~ CP velero/usr/local/binamp，是

p，chmod+x/usr/local/bin/velero。~veleroversionClient:Version:v1.6.3Gitcommit:5fe3a50bfddc2becb4c0bd5e2d3d4053a23e95d2

安装 MINIO

这里我们可以使用 minio 来代替云环境的对象存储，在上面解压的压缩包中包含一个 examples/minio/00—minio—deployment.yaml 的资源清单文件，为了测试方便可以将其中的 Service 更改为 NodePort 类型，我们可以配置一个 console—address 来提供一个 console 页面的访问入口，完整的资源清单文件如下所示:

然后直接部署在 Kubernetes 集群中即可:

~kubectlapply—fexamples/minio/00—minio—deployment.yamlnamespace/velerocreateddeployment.apps/miniocreatedservice/miniocreatedjob.batch/minio—setupcreated~kubectlgetpods—nveleroNAMEREADYSTATUSRESTARTSAGEminio—5b96ffddf8—x8s7p1/1Running02m48sminio—setup—rhc4d0/1Completed12m48s

当然如果需要在不同 Kubernetes 和存储池集群备份与恢复数据，需要将 minio 服务端安装在 Kubernetes 集群外，保证在集群发生灾难性故障时，不会对备份数据产生影响，可以通过二进制的方式进行安装。

在待安装 minio 的服务器上下载二进制包

准备对象存储的磁盘，这里我们跳过该步骤，可以使用 systemd 来方便管理 minio 服务，对于使用 systemd init 系统运行系统的人，请创建用于运行 minio 服务的用户和组:

~sudogroupadd——systemminio

为 /data目录提供 minio 用户所有权:

。~sudochown—Rminio:minio/data/

为 minio 创建 systemd 服务单元文件:

创建 minio 环境文件 /etc/default/minio:

#VolumetobeusedforMinioserver.MINIO_VOLUMES="/data"#UseifyouwanttorunMinioonacustomport.MINIO_OPTS="——address:9000"#AccessKeyoftheserver.MINIO_ACCESS_KEY=minio#Secretkeyoftheserver.MINIO_SECRET_KEY=minio123

其中 MINIO_ACCESS_KEY 为长度至少为3个字符的访问密钥，MINIO_SECRET_KEY 为最少8个字符的密钥。重新加载 systemd 并启动 minio 服务:

~sudosystemctldaemon—reload

安装 velero 服务端

我们可以使用 velero 客户端来安装服务端，也可以使用 Helm Chart 来进行安装，比如这里我们用客户端来安装，velero 命令默认读取 kubectl 配置的集群上下文，所以前提是 velero 客户端所在的节点有可访问集群的 kubeconfig 配置。

首先准备密钥文件，在当前目录建立一个空白文本文件，内容如下所示:

aws_access_key_id=aws_secret_access_key=

替换为之前步骤中 minio 的对应 access key id 和 secret access key如果 minio 安装在 kubernetes 集群内时按照如下命令安装 velero 服务端:

由于我们这里准备使用 minio 来作为对象存储，minio 是兼容 S3 的，所以这里我们配置的 provider是 aws，——secret—file 用来提供访问 minio 的密钥，——use—restic 表示使用开源免费备份工具 restic 备份和还原持久卷数据，启用该参数后会部署一个名为 restic 的 DaemonSet 对象，——plugins 使用的 velero 插件，我们使用 AWS S3 兼容插件。

安装完成后 velero 的服务端就部署成功了。

测试

比如现在我们部署一个 mysql 应用，资源清单文件如下所示:

#mysql—deployment.yamlapiVersion:v1kind:PersistentVolumeClaimmetadata:name:mysql—pv—claimlabels:app:mysqlspec:accessModes:—ReadWriteOnceresources:requests:storage:20GiapiVersion:apps/v1kind:Deploymentmetadata:name:mysqllabels:app:mysqlspec:selector:matchLabels:app:mysqltemplate:metadata:labels:app:mysqlspec:containers:—image:mysql:5.6name:mysqlenv:—name:MYSQL_ROOT_PASSWORDvalueFrom:secretKeyRef:name:mysql—passkey:passwordlivenessProbe:tcpSocket:port:3306ports:—containerPort:3306name:mysqlvolumeMounts:—name:mysql—persistent—storagemountPath:/var/lib/mysqlvolumes:—name:mysql—persistent—storagepersistentVolumeClaim:claimName:mysql—pv—claim

直接部署上面的应用:

~kubectlcreatenamespacekube—demo~kubectlcreatesecretgenericmysql—pass——from—literal=password=password321—nkube—demo~kubectlapply—fmysql—deployment.yaml—nkube—demo

比如现在我们创建一个新的数据库 velero:

现在我们来执行一个备份:

。~velerobackupcreatemysql—backup——include—namespaceskube—demo——default—volumes—to—resticBackuprequest"mysql—backup"submittedsuccessfully.Run`velerobackupdescribemysql—backup`or`velerobackuplogsmysql—backup`formoredetails.

其中我们指定的 ——default—volumes—to—restic 参数表示使用 restic 备份持久卷到 minio，——include—namespaces 用来备份该命名空间下的所有资源，不包括集群资源，此外还可以使用 ——include—resources 指定要备份的资源类型 ，——include—cluster—resources 指定是否备份集群资源。

该命令请求创建一个对项目的备份，备份请求发送之后可以用命令查看备份状态，等到 STATUS 列变为 Completed 表示备份完成。

~velerobackupgetNAMESTATUSERRORSWARNINGSCREATEDEXPIRESSTORAGELOCATIONSELECTORmysql—backupCompleted002021—09—1616:58:51+0800CST29ddefault

备份完成后可以去 minio 的 bucket 上查看是否有对应的备份数据:

现在我们删除应用所在的命名空间来模拟生产环境发生灾难或运维错误导致应用失败的场景:

。~kubectldeletenamespacekube—demo

这个时候我们肯定访问不了我们的 MySQL 数据库了，这时候我们可以用一条命令，使用 velero 从 minio 中来恢复应用和数据:

。~velerorestorecreate——from—backupmysql—backupRestorerequest"mysql—backup—20210916172100"submittedsuccessfully.Run`velerorestoredescribemysql—backup—20210916172100`or`velerorestorelogsmysql—backup—20210916172100`formoredetails.

同样我们可以使用 velero restore get 来查看还原的进度，等到 STATUS 列变为 Completed 表示还原完成:

~velerorestoregetNAMEBACKUPSTATUSSTARTEDCOMPLETEDERRORSWARNINGSCREATEDSELECTORmysql—backup—20210916172100mysql—backupCompleted2021—09—1617:21:00+0800CST2021—09—1617:21:22+0800CST002021—09—1617:21:00+0800CST

还原完成后我们再去查看之前我们的 kube—demo 命名空间下面的应用数据是否正确:

可以看到我们的创建的 velero 数据库依然存在，证明已经完全恢复了。

郑重声明：此文内容为本网站转载企业宣传资讯，目的在于传播更多信息，与本站立场无关。仅供读者参考，并请自行核实相关内容。