用户不必备份容器中的所有内容, 但在发生灾难时备份运行和管理容器的配置是很重要的.
用户的容器基础设施需要某种类型的备份. Kubernetes 和 Docker 在灾难之后不会自己构建. 用户无需备份每个容器的运行状态, 但是需要备份用于运行和管理容器的配置.
以下是用户需要备份的内容.
配置和所需状态信息
Dockerfile 用于构建镱像以及这些文件的所有版本
从 Dockerfile 创建并用于运行每个容器的镜像
Kubernetes etcd 和其他有关集群状态的 K8s 数据库
Deployments 用于描述每个部署的 YAML 文件
容器创建或更改的持久数据
持久卷
数据库
Dockerfiles
Docker 容器从镜像运行, 其镜像从 Dockerfiles 构建. 正确的 Docker 配置将首先使用某种存储库 (例如 GitHub) 作为所有 Dockerfile 的版本控制系统. 不要使用从临时 Dockerfile 构建的临时镜像创建临时容器. 所有 Dockerfile 都应存储在存储库中, 如果当前版本存在问题, 该存储库将允许用户提取这个 Dockerfile 的历史版本.
用户还应该具有存储与每个 K8s 部署关联的 YAML 文件的某种存储库, 这些是可以从版本控制系统中受益的文本文件.
然后需要备份这些存储库. GitHub 是比较受欢迎的存储库之一, 它提供了许多备份存储库的方法. 有多种脚本使用提供的 API 来下载存储库的当前备份. 用户还可以使用第三方商业工具来备份 GitHub 或用户正在使用的任何存储库.
如果没有遵循上述建议, 而是根据不再具有 Dockerfile 的镜像运行容器, 则可以使用 Docker 镜像历史命令或 dfimage 之类的工具从当前镜像创建 Dockerfile. 将这些 Dockerfile 放入存储库中, 然后开始备份. 但是不要陷入这种情况, 应该始终存储和备份用于创建环境的 Dockerfile 和 YAML 文件.
Docker 镜像
用于运行容器的当前镜像也应存储在存储库中 (当然, 如果用户正在 Kubernetes 中运行 Docker 镜像, 那么已经在这样做了). 用户可以使用私有存储库(例如 Docker 注册表) 或公共存储库(例如 Dockerhub). 云计算提供商还可以为用户提供私人存储库来存储镜像. 然后应备份该回购的内容. 诸如 "Dockerhub 备份" 之类的简单搜索就可以产生令人惊讶的众多选择.
如果用户没有用于运行容器的当前镜像, 则可以使用 docker commit 命令创建一个. 然后, 使用 Docker 镜像历史记录或工具 dfimage 从该镜像创建 Dockerfile.
Kubernetes etcd
Kubernetes etcd 数据库非常重要, 应使用 etcdctl snapshot save db 命令进行备份. 这将在当前目录中创建文件 snapshot.db. 然后应将该文件备份到外部存储.
如果使用的是商业备份软件, 则可以在创建 snapshot.db 的目录备份之前轻松触发 etcdctl snapshot save 命令. 这是将备份集成到商业备份环境中的一种方法.
持久卷
容器可以通过多种方式访问持久性存储, 而持久性存储可用于存储或创建数据. 传统的 Docker 卷位于 Docker 配置的子目录中. 绑定挂载只是 Docker 主机上安装在容器内 (使用 bind mount 命令) 的任何目录. 出于多种原因, Docker 社区首先选择传统卷, 但出于备份目的, 传统卷和绑定安装实质上是相同的. 用户还可以将网络文件系统 (NFS) 目录或对象从对象存储系统作为卷装入容器中.
用于备份持久卷的方法将基于用于容器的上述选项. 但是, 它们都会有相同的问题: 如果数据正在更改, 则需要处理该问题才能获得一致的备份.
一种方法是关闭使用该特定卷的任何容器. 这种做法虽然有些过时, 但这是容器世界所面临的挑战之一, 因为在容器中放置备份代理的典型方法并不是一种很好的选择. 一旦关闭, 便可以备份该卷. 如果它是传统的 Docker 卷, 则可以通过将其挂载到另一个在备份时不会更改其数据的容器中进行备份, 然后在绑定安装的卷中创建该卷的 tar 镜像, 然后使用备份系统使用的任何方法进行备份.
但是, 这在 Kubernetes 中确实很难做到. 这是有状态信息最好存储在数据库而不是文件系统中的原因之一. 而在设计 K8s 基础设施时, 需要考虑此问题.
另外, 如果用户使用绑定安装目录, NFS 安装文件系统或对象存储系统作为持久性存储系统, 则可以使用优秀的方法来备份该存储系统. 这可能是快照, 然后是复制, 或者只是在该系统上运行商业备份软件. 与相同卷的典型文件级备份相比, 这些方法可能提供更加一致的备份.
数据库
下一个备份挑战是容器使用数据库存储其数据. 这些数据库需要以保证其完整性的方式进行备份. 根据数据库的不同, 上述方法可能会起作用: 关闭访问数据库的容器, 然后备份存储其文件的目录. 但是, 这种方法所需的停机时间可能不合适.
另一种方法是直接连接到数据库引擎本身, 并要求它运行到文件的备份, 然后可以对其进行备份. 如果数据库在容器内运行, 则首先需要使用绑定安装来附加一个可以备份的卷, 因此其备份可以存在于容器外部. 然后运行数据库使用的命令 (例如 mysqldump) 创建备份. 然后确保使用备份系统创建的文件.
如果用户不知道哪些容器正在使用什么样的存储或什么样的数据库怎么办? 一种解决方案可能是使用 docker ps 命令列出正在运行的容器, 然后使用 docker inspect 命令显示每个容器的配置. 有一个名为 "挂载" 的部分, 它将告诉用户将哪些卷挂载在何处. 任何绑定安装也将在用户提交给 Kubernetes 的 YAML 文件中指定.
商业备份解决方案
有各种各样的商业备份解决方案可以保护上述部分或全部数据. 以下是一个非常简短的摘要:
Commvault 的虚拟服务器代理可以充当备份容器及其镜像的代理.
Cohenity 为 K8s 命名空间提供数据保护.
Heptio(现为 VMware 公司)提供为 K8s 设计的 Velero 备份.
Contino,Datacore 和 Portworx 提供专为 K8 和容器设计的存储, 并且还支持备份该信息.
鉴于 K8 和 Docker 的配置方式多种多样, 很难涵盖所有内容. 但是希望提供一些思考的机会, 或者可以帮助用户备份一些应该但尚未备份的东西.
来源: http://www.tuicool.com/articles/6bUvauq