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

0
0
{"value":"云端容器平台如 Amazon EKS 非常适合来运行无状态的应用程序以增强其弹性,但某些场景下我们仍然需要使用 PV 来运行有状态的服务并提供固化存储,如某些中间件应用或其他需要使用轻量化数据库的应用。这些应用通常不支持多副本,且对读写延迟和性能要求较高,因此选择正确的底层存储非常重要。\n\n![image.png](https://dev-media.amazoncloud.cn/83b3ec1fabb245f3ae2e77d855950f97_image.png)\n\n开源社区提供了标准的容器存储接口 (CSI),这是一种将任意块和文件存储系统暴露给 Kubernetes 等容器编排系统上的容器化工作负载的标准。目前 Amazon 已经官方提供了基于 EBS、EFS、FSx for Lustre 的 CSI 驱动程序,提供固化存储给 Amazon EKS 上运行的容器以满足不同场景的需求。\n\nAmazon Elastic Block Stock (Amazon EBS) 是一种块存储服务,提供从 EC2 实例到专用存储卷的直联访问。在这篇文章中,我们将专注于 EBS CSI 驱动程序提供的 Kubernetes 卷快照功能。Kubernetes 卷快照允许您在特定时间点创建 EBS 卷的副本。 您可以使用此副本快速的还原成新的 EBS 卷。与使用标准的 Amazon EBS 快照不同,所有信息和操作将在 Kubernetes 层进行,无需手动在 Amazon 门户或通过 API 手动调用,这将有助于降低在数据恢复时的人工成本并提高安全性。\n\n### **先决条件:**\n完成本示例的先决条件是拥有一个运行 Kubernetes 1.20 或更高版本的有效 Amazon EKS 集群。如果您需要有关如何启动 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 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 CSI 驱动程序**\n在确保第一步所有资源处于正常运行的状态后,就可以开始部署官方提供的 Amazon EBS 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![image.png](https://dev-media.amazoncloud.cn/f822fcaf8b1b42749646e88b90d8fc89_image.png)\n\n此时需在管理门户中确认可以看到与之对应的 EBS 快照:\n\n![image.png](https://dev-media.amazoncloud.cn/4bc2f62ada65489397d98771ffcaf6a6_image.png)\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![image.png](https://dev-media.amazoncloud.cn/cbae9414e3aa42d39b119f288491e5d0_image.png)\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"}
目录
亚马逊云科技解决方案 基于行业客户应用场景及技术领域的解决方案
联系亚马逊云科技专家
亚马逊云科技解决方案
基于行业客户应用场景及技术领域的解决方案
联系专家
0
目录
关闭
contact-us