在 Amazon EKS 上使用 k8s Snapshot 备份和恢复 EBS PV 卷

{"value":"云端容器平台如 [Amazon EKS](https://aws.amazon.com/cn/eks/?trk=cndc-detail) 非常适合来运行无状态的应用程序以增强其弹性，但某些场景下我们仍然需要使用 PV 来运行有状态的服务并提供固化存储，如某些中间件应用或其他需要使用轻量化数据库的应用。这些应用通常不支持多副本，且对读写延迟和性能要求较高，因此选择正确的底层存储非常重要。\n\n\n\n开源社区提供了标准的容器存储接口 (CSI)，这是一种将任意块和文件存储系统暴露给 Kubernetes 等容器编排系统上的容器化工作负载的标准。目前 Amazon 已经官方提供了基于 EBS、EFS、FSx for Lustre 的 CSI 驱动程序，提供固化存储给 [Amazon EKS](https://aws.amazon.com/cn/eks/?trk=cndc-detail) 上运行的容器以满足不同场景的需求。\n\nAmazon Elastic Block Stock ([Amazon EBS](https://aws.amazon.com/cn/ebs/?trk=cndc-detail)) 是一种块存储服务，提供从 EC2 实例到专用存储卷的直联访问。在这篇文章中，我们将专注于 EBS CSI 驱动程序提供的 Kubernetes 卷快照功能。Kubernetes 卷快照允许您在特定时间点创建 EBS 卷的副本。 您可以使用此副本快速的还原成新的 EBS 卷。与使用标准的 [Amazon EBS](https://aws.amazon.com/cn/ebs/?trk=cndc-detail) 快照不同，所有信息和操作将在 Kubernetes 层进行，无需手动在 Amazon 门户或通过 API 手动调用，这将有助于降低在数据恢复时的人工成本并提高安全性。\n\n### **先决条件：**\n完成本示例的先决条件是拥有一个运行 Kubernetes 1.20 或更高版本的有效 [Amazon EKS](https://aws.amazon.com/cn/eks/?trk=cndc-detail) 集群。如果您需要有关如何启动 EKS 集群的说明，请参阅 [Amazon EKS 文档](https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html)。\n\n另请注意，Kubernetes 卷快照功能是在 Kubernetes 1.17 版本开始 Beta 测试，并在 Kubernetes 1.20 版本 GA，如果您的 EKS 集群介于这两个版本之间，相关的API版本请使用 v1beta1。有关该功能的GA信息请参阅[此文档](https://kubernetes.io/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga):\n\n#### **Step1: 部署 CSI Snapshotter 驱动程序**\nCSI Snapshotter 是容器存储接口 (CSI) 在 Kubernetes 实现的一部分。它包含了使用快照所必须的资源，且必须在安装 [Amazon EBS](https://aws.amazon.com/cn/ebs/?trk=cndc-detail) CSI driver 前部署完毕。\n\n它包含如下内容：\n\n- Kubernetes 标准 CRD 配置定义文件\n\tvolumesnapshotclasses\n\n\tvolumesnapshots\n\n\tvolumesnapshotcontents\n\n- RBAC 相关配置定义文件\n- Controller Deployment 配置定义文件\n\n有关于此的详情信息，请参阅 [GitHub](https://github.com/kubernetes-csi/external-snapshotter)：\n\n部署完成后，默认将创建2个名为 snapshot-controller 的容器：\n\n```\\n\$ kubectl get pod -n kube-system | grep snapshot\\nsnapshot-controller-75fd799dc8-8tj4w \\t1/1 Running \\nsnapshot-controller-75fd799dc8-q4fm8 \\t1/1 Running\\n```\n \n请确保它们的状态为 “Running“。\n\n#### **Step2: 部署 [Amazon EBS](https://aws.amazon.com/cn/ebs/?trk=cndc-detail) CSI 驱动程序**\n在确保第一步所有资源处于正常运行的状态后，就可以开始部署官方提供的 [Amazon EBS](https://aws.amazon.com/cn/ebs/?trk=cndc-detail) CSI 驱动程序了。目前，官方已经支持通过管理门户一键安装，您也可以按照[官方文档](https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html)的标准步骤进行手动部署。\n\n该驱动程序包含两组容器：\n\n- ebs-csi-controller\n— 默认运行副本数为 2\n\n- ebs-csi-node\n— 该组容器需要确保运行在每个 worker 节点上\n\n使用下面的命令确保相关的容器已经正常运行：\n\n```\\n\$ kubectl get pod -n kube-system | grep ebs\\nebs-csi-controller-6d5b894ddc-wfvk4 6/6 Running \\nebs-csi-controller-6d5b894ddc-xppg9 6/6 Running \\nebs-csi-node-22xzl \\t3/3 Running \\nebs-csi-node-f69hs \\t\\t3/3 Running\\nebs-csi-node-rgqlr \\t3/3 Running \\nebs-csi-node-sp9hx \\t3/3 Running \\n…\\n```\n\n#### **Step3：创建 EBS 快照**\n首先，与创建基于 EBS 的 Storage Class 类似，我们需要创建一个叫做 VolumeSnapshotClass 的 Kubernetes 自定义资源。该资源在第一步部署 CRD 时已经创建，如果创建有问题，此处会报找不到定义的错误。此外，如果您的 Amazone EKS 集群使用 Kubernetes 1.17 ~ 1.19 版本，请将 API 切换成 v1beta1。\n\n++**VolumeSnapshotClass 定义文件：**++\n\n```\\napiVersion: snapshot.storage.k8s.io/v1\\nkind: VolumeSnapshotClass\\nmetadata:\\n name: csi-aws-vsc\\ndriver: ebs.csi.aws.com\\ndeletionPolicy: Delete\\n```\n\n确认相关资源已经创建完成：\n\n```\\n\$kubectl get VolumeSnapshotClass\\nNAME DRIVER DELETIONPOLICY AGE\\ncsi-aws-vsc ebs.csi.aws.com Delete 4d23h\\n```\n\n在本次示例中，我们将使用如下的 Pod 定义通过输出 date 的方式来记录时间戳信息到 /data/out.txt ：\n\n```\\napiVersion: v1\\nkind: Pod\\nmetadata:\\n name: app-restore\\nspec:\\n containers:\\n - name: app-restore\\n image: centos\\n command: [\\"/bin/sh\\"]\\n args: [\\"-c\\", \\"while true; do echo \$(date -u) >> /data/out.txt; sleep 5; done\\"]\\n volumeMounts:\\n - name: persistent-storage\\n mountPath: /data\\n volumes:\\n - name: persistent-storage\\n persistentVolumeClaim:\\n claimName: ebs-claim\\n```\n\n创建完成后，确保 /data/out.txt 可以正常写入时间戳信息。之后就可以为对应的 PVC：ebs-claim 创建快照。相关定义文件参考如下。如果您的 EKS 集群使用 Kubernetes 1.17 ~ 1.19 版本，请将 API 切换成 v1beta1。\n\n \n\n++**VolumeSnapshot定义文件：**++\n\n```\\napiVersion: snapshot.storage.k8s.io/v1\\nkind: VolumeSnapshot\\nmetadata:\\n name: ebs-volume-snapshot\\nspec:\\n volumeSnapshotClassName: <volumesnapshotclass_name>\\n source:\\npersistentVolumeClaimName: <pvc_name>\\n```\n\n等待 volumesnapshot 的可用状体变为: True\n\n\n\n此时需在管理门户中确认可以看到与之对应的 EBS 快照：\n\n\n\n#### **Step4：恢复 EBS 快照**\n++**从 VolumeSnapShot 创建 PVC 的定义文件：**++\n\n```\\napiVersion: v1\\nkind: PersistentVolumeClaim\\nmetadata:\\n name: ebs-snapshot-restored-claim\\nspec:\\n accessModes:\\n - ReadWriteOnce\\n storageClassName: ebs-sc\\n resources:\\n requests:\\n storage: 4Gi\\n dataSource:\\n name: ebs-volume-snapshot\\n kind: VolumeSnapshot\\napiGroup: snapshot.storage.k8s.io\\n```\n\n++**挂载恢复后 PVC 的 Pod 定义文件：**++\n\n```\\napiVersion: v1\\nkind: Pod\\nmetadata:\\n name: app-restore\\nspec:\\n containers:\\n - name: app-restore\\n image: centos\\n command: [\\"/bin/sh\\"]\\n args: [\\"-c\\", \\"while true; do echo \$(date -u) >> /data/out-restore.txt; sleep 5; done\\"]\\n volumeMounts:\\n - name: persistent-storage\\n mountPath: /data\\n volumes:\\n - name: persistent-storage\\n persistentVolumeClaim:\\n claimName: ebs-snapshot-restored-claim\\n```\n\n等待 PVC 和 Pod 可用后，使用 \$kubectl exec 在 Pod 内部运行命令来检查相关的数据是否被正确的保存和恢复。可以看到原有日志 out.txt 的输出中包含快照前的数据，且日志的最新时间戳记录与 EBS 快照生成的时间一致。\\n\\n\\n\\n至此，EBS 快照的创建和恢复操作完成。\\n\\n### **总结：**\\n快照被视为保护有状态工作负载数据的关键功能。在此功能推出之前，管理员需要在 EBS 层对 PVC 对应的卷进行手动操作来创建和恢复快照，恢复后的卷还需要以静态卷的方式创建到 EKS 集群中，在使用 CSI 和 动态卷 的场景下，管理员还需要花费精力对比每个相关的 ID 信息避免出现错误。\\n\\n通过提供在 Kubernetes API 中触发快照操作的方法，管理员现在可以直接在 Kubernetes 层创建和管理快照。在管理层面这可以有效减少运维成本，在安全层面也可以进一步控制 EKS 运维人员在 Amazone 管理门户 和 API 中的权限，满足安全的最佳实践。\\n\\n我们希望这篇文章对您使用 Amazon EKS 和 EBS 卷有所帮助。 如果您有任何问题或建议，请随时发表评论。谢谢。\\n\\n#### **本篇作者**\\n**王志达**\\nAmazon 解决方案架构师，主要负责基础架构如计算、存储的云端设计、改造和优化方案。有多年存储、容器平台和 Devops 运维经验。","render":"<p>云端容器平台如 Amazon EKS 非常适合来运行无状态的应用程序以增强其弹性，但某些场景下我们仍然需要使用 PV 来运行有状态的服务并提供固化存储，如某些中间件应用或其他需要使用轻量化数据库的应用。这些应用通常不支持多副本，且对读写延迟和性能要求较高，因此选择正确的底层存储非常重要。</p>\\n<p><img src=\\"https://dev-media.amazoncloud.cn/83b3ec1fabb245f3ae2e77d855950f97_image.png\\" alt=\\"image.png\\" /></p>\\n<p>开源社区提供了标准的容器存储接口 (CSI)，这是一种将任意块和文件存储系统暴露给 Kubernetes 等容器编排系统上的容器化工作负载的标准。目前 Amazon 已经官方提供了基于 EBS、EFS、FSx for Lustre 的 CSI 驱动程序，提供固化存储给 Amazon EKS 上运行的容器以满足不同场景的需求。</p>\\n<p>Amazon Elastic Block Stock (Amazon EBS) 是一种块存储服务，提供从 EC2 实例到专用存储卷的直联访问。在这篇文章中，我们将专注于 EBS CSI 驱动程序提供的 Kubernetes 卷快照功能。Kubernetes 卷快照允许您在特定时间点创建 EBS 卷的副本。 您可以使用此副本快速的还原成新的 EBS 卷。与使用标准的 Amazon EBS 快照不同，所有信息和操作将在 Kubernetes 层进行，无需手动在 Amazon 门户或通过 API 手动调用，这将有助于降低在数据恢复时的人工成本并提高安全性。</p>\\n<h3><a id=\\"_8\\"></a><strong>先决条件：</strong></h3>\\n<p>完成本示例的先决条件是拥有一个运行 Kubernetes 1.20 或更高版本的有效 Amazon EKS 集群。如果您需要有关如何启动 EKS 集群的说明，请参阅 <a href=\\"https://docs.aws.amazon.com/eks/latest/userguide/create-cluster.html\\" target=\\"_blank\\">Amazon EKS 文档</a>。</p>\\n<p>另请注意，Kubernetes 卷快照功能是在 Kubernetes 1.17 版本开始 Beta 测试，并在 Kubernetes 1.20 版本 GA，如果您的 EKS 集群介于这两个版本之间，相关的API版本请使用 v1beta1。有关该功能的GA信息请参阅<a href=\\"https://kubernetes.io/blog/2020/12/10/kubernetes-1.20-volume-snapshot-moves-to-ga\\" target=\\"_blank\\">此文档</a>:</p>\\n<h4><a id=\\"Step1__CSI_Snapshotter__13\\"></a><strong>Step1: 部署 CSI Snapshotter 驱动程序</strong></h4>\\n<p>CSI Snapshotter 是容器存储接口 (CSI) 在 Kubernetes 实现的一部分。它包含了使用快照所必须的资源，且必须在安装 Amazon EBS CSI driver 前部署完毕。</p>\\n<p>它包含如下内容：</p>\\n<ul>\\n<li>\\n<p>Kubernetes 标准 CRD 配置定义文件<br />\\nvolumesnapshotclasses</p>\\n<p>volumesnapshots</p>\\n<p>volumesnapshotcontents</p>\\n</li>\\n<li>\\n<p>RBAC 相关配置定义文件</p>\\n</li>\\n<li>\\n<p>Controller Deployment 配置定义文件</p>\\n</li>\\n</ul>\\n<p>有关于此的详情信息，请参阅 <a href=\\"https://github.com/kubernetes-csi/external-snapshotter\\" target=\\"_blank\\">GitHub</a>：</p>\\n<p>部署完成后，默认将创建2个名为 snapshot-controller 的容器：</p>\\n<pre><code class=\\"lang-\\">\$ kubectl get pod -n kube-system | grep snapshot\nsnapshot-controller-75fd799dc8-8tj4w \t1/1 Running \nsnapshot-controller-75fd799dc8-q4fm8 \t1/1 Running\n</code></pre>\n<p>请确保它们的状态为 “Running“。</p>\n<h4><a id=\\"Step2__Amazon_EBS_CSI__40\\"></a><strong>Step2: 部署 Amazon EBS CSI 驱动程序</strong></h4>\\n<p>在确保第一步所有资源处于正常运行的状态后，就可以开始部署官方提供的 Amazon EBS CSI 驱动程序了。目前，官方已经支持通过管理门户一键安装，您也可以按照<a href=\\"https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html\\" target=\\"_blank\\">官方文档</a>的标准步骤进行手动部署。</p>\\n<p>该驱动程序包含两组容器：</p>\n<ul>\\n<li>\\n<p>ebs-csi-controller<br />\\n— 默认运行副本数为 2</p>\n</li>\\n<li>\\n<p>ebs-csi-node<br />\\n— 该组容器需要确保运行在每个 worker 节点上</p>\n</li>\\n</ul>\n<p>使用下面的命令确保相关的容器已经正常运行：</p>\n<pre><code class=\\"lang-\\">\$ kubectl get pod -n kube-system | grep ebs\\nebs-csi-controller-6d5b894ddc-wfvk4 6/6 Running \\nebs-csi-controller-6d5b894ddc-xppg9 6/6 Running \\nebs-csi-node-22xzl \\t3/3 Running \\nebs-csi-node-f69hs \\t\\t3/3 Running\\nebs-csi-node-rgqlr \\t3/3 Running \\nebs-csi-node-sp9hx \\t3/3 Running \\n…\\n</code></pre>\\n<h4><a id=\\"Step3_EBS__64\\"></a><strong>Step3：创建 EBS 快照</strong></h4>\\n<p>首先，与创建基于 EBS 的 Storage Class 类似，我们需要创建一个叫做 VolumeSnapshotClass 的 Kubernetes 自定义资源。该资源在第一步部署 CRD 时已经创建，如果创建有问题，此处会报找不到定义的错误。此外，如果您的 Amazone EKS 集群使用 Kubernetes 1.17 ~ 1.19 版本，请将 API 切换成 v1beta1。</p>\n<p><ins><strong>VolumeSnapshotClass 定义文件：</strong></ins></p>\n<pre><code class=\\"lang-\\">apiVersion: snapshot.storage.k8s.io/v1\\nkind: VolumeSnapshotClass\\nmetadata:\\n name: csi-aws-vsc\\ndriver: ebs.csi.aws.com\\ndeletionPolicy: Delete\\n</code></pre>\\n<p>确认相关资源已经创建完成：</p>\n<pre><code class=\\"lang-\\">\$kubectl get VolumeSnapshotClass\\nNAME DRIVER DELETIONPOLICY AGE\\ncsi-aws-vsc ebs.csi.aws.com Delete 4d23h\\n</code></pre>\\n<p>在本次示例中，我们将使用如下的 Pod 定义通过输出 date 的方式来记录时间戳信息到 /data/out.txt ：</p>\n<pre><code class=\\"lang-\\">apiVersion: v1\\nkind: Pod\\nmetadata:\\n name: app-restore\\nspec:\\n containers:\\n - name: app-restore\\n image: centos\\n command: [&quot;/bin/sh&quot;]\\n args: [&quot;-c&quot;, &quot;while true; do echo \$(date -u) &gt;&gt; /data/out.txt; sleep 5; done&quot;]\\n volumeMounts:\\n - name: persistent-storage\\n mountPath: /data\\n volumes:\\n - name: persistent-storage\\n persistentVolumeClaim:\\n claimName: ebs-claim\\n</code></pre>\\n<p>创建完成后，确保 /data/out.txt 可以正常写入时间戳信息。之后就可以为对应的 PVC：ebs-claim 创建快照。相关定义文件参考如下。如果您的 EKS 集群使用 Kubernetes 1.17 ~ 1.19 版本，请将 API 切换成 v1beta1。</p>\n<p><ins><strong>VolumeSnapshot定义文件：</strong></ins></p>\n<pre><code class=\\"lang-\\">apiVersion: snapshot.storage.k8s.io/v1\\nkind: VolumeSnapshot\\nmetadata:\\n name: ebs-volume-snapshot\\nspec:\\n volumeSnapshotClassName: &lt;volumesnapshotclass_name&gt;\\n source:\\npersistentVolumeClaimName: &lt;pvc_name&gt;\\n</code></pre>\\n<p>等待 volumesnapshot 的可用状体变为: True</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/f822fcaf8b1b42749646e88b90d8fc89_image.png\\" alt=\\"image.png\\" /></p>\n<p>此时需在管理门户中确认可以看到与之对应的 EBS 快照：</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/4bc2f62ada65489397d98771ffcaf6a6_image.png\\" alt=\\"image.png\\" /></p>\n<h4><a id=\\"Step4_EBS__133\\"></a><strong>Step4：恢复 EBS 快照</strong></h4>\\n<p><ins><strong>从 VolumeSnapShot 创建 PVC 的定义文件：</strong></ins></p>\n<pre><code class=\\"lang-\\">apiVersion: v1\\nkind: PersistentVolumeClaim\\nmetadata:\\n name: ebs-snapshot-restored-claim\\nspec:\\n accessModes:\\n - ReadWriteOnce\\n storageClassName: ebs-sc\\n resources:\\n requests:\\n storage: 4Gi\\n dataSource:\\n name: ebs-volume-snapshot\\n kind: VolumeSnapshot\\napiGroup: snapshot.storage.k8s.io\\n</code></pre>\\n<p><ins><strong>挂载恢复后 PVC 的 Pod 定义文件：</strong></ins></p>\n<pre><code class=\\"lang-\\">apiVersion: v1\\nkind: Pod\\nmetadata:\\n name: app-restore\\nspec:\\n containers:\\n - name: app-restore\\n image: centos\\n command: [&quot;/bin/sh&quot;]\\n args: [&quot;-c&quot;, &quot;while true; do echo \$(date -u) &gt;&gt; /data/out-restore.txt; sleep 5; done&quot;]\\n volumeMounts:\\n - name: persistent-storage\\n mountPath: /data\\n volumes:\\n - name: persistent-storage\\n persistentVolumeClaim:\\n claimName: ebs-snapshot-restored-claim\\n</code></pre>\\n<p>等待 PVC 和 Pod 可用后，使用 \$kubectl exec 在 Pod 内部运行命令来检查相关的数据是否被正确的保存和恢复。可以看到原有日志 out.txt 的输出中包含快照前的数据，且日志的最新时间戳记录与 EBS 快照生成的时间一致。</p>\n<p><img src=\\"https://dev-media.amazoncloud.cn/cbae9414e3aa42d39b119f288491e5d0_image.png\\" alt=\\"image.png\\" /></p>\n<p>至此，EBS 快照的创建和恢复操作完成。</p>\n<h3><a id=\\"_182\\"></a><strong>总结：</strong></h3>\\n<p>快照被视为保护有状态工作负载数据的关键功能。在此功能推出之前，管理员需要在 EBS 层对 PVC 对应的卷进行手动操作来创建和恢复快照，恢复后的卷还需要以静态卷的方式创建到 EKS 集群中，在使用 CSI 和 动态卷 的场景下，管理员还需要花费精力对比每个相关的 ID 信息避免出现错误。</p>\n<p>通过提供在 Kubernetes API 中触发快照操作的方法，管理员现在可以直接在 Kubernetes 层创建和管理快照。在管理层面这可以有效减少运维成本，在安全层面也可以进一步控制 EKS 运维人员在 Amazone 管理门户 和 API 中的权限，满足安全的最佳实践。</p>\n<p>我们希望这篇文章对您使用 Amazon EKS 和 EBS 卷有所帮助。 如果您有任何问题或建议，请随时发表评论。谢谢。</p>\n<h4><a id=\\"_189\\"></a><strong>本篇作者</strong></h4>\\n<p><strong>王志达</strong><br />\\nAmazon 解决方案架构师，主要负责基础架构如计算、存储的云端设计、改造和优化方案。有多年存储、容器平台和 Devops 运维经验。</p>\n"}