怎么使用Kubernetes检查点API快速进行容器的备份和恢复呢？

Kubernetes v1.25 引入了容器检查点 API 作为 alpha 特性这提供了一种在不停止容器的情况下备份和恢复运行在 Pod 中的容器的方式此功能主要用于调试分析，但任何 Kubernetes 用户都可以利用常规备份和恢复功能。

接下来，让我们来看看这个特性，并了解如何在我们的集群中启用它，并利用它进行备份和恢复或调试分析 安装 在我们开始对任何容器进行检查点处理之前，我们需要一个 playgroud，在这个 playgroud 上我们可以操作 kubelet 和它的工作负载。

为此，我们将需要一个支持容器检查点处理的 v1.25+ 版本的 Kubernetes集 群和容器运行时环境 这里我们将使用在 Vagrant 中构建的虚拟机内使用 kubeadm 创建一个集群，只需执行vagrant up即可快速启动该集群。

如果你想搭建自己的集群，请确保集群必须启用ContainerCheckpoint功能标志对于 kubeadm 使用以下配置：#kubeadm-config.yaml apiVersion:kubelet.config.k8s.io/v1beta1 kind:KubeletConfigura。

tion featureGates: ContainerCheckpoint:true --- apiVersion:kubeadm.k8s.io/v1beta3 kind:ClusterConfiguration kubernetesVersion:v1.25.0 apiServer: extraArgs: feature-gates:"ContainerCheckpoint=true" controllerManager: extraArgs: feature-gates:"ContainerCheckpoint=true" scheduler: extraArgs: feature-gates:"ContainerCheckpoint=true" netw

orking: podSubnet:10.244.0.0/16 这将向集群组件传递--feature-gates标志此外，我们还需要使用支持检查点的容器运行时撰写本文时，仅CRI-O支持它，而 Containerd 可能很快也会支持（https://github.com/containerd/containerd/pull/6965），。

最新版本的crictl已经支持通过crictl checkpoint创建检查点 要使用 CRI-O 配置集群，请按照文档中的说明安装它，或者使用上述存储库中的脚本（你应该在虚拟机而不是本地运行此脚本）。

另外，我们还需要为 CRI-O 启用CRIU，这是在后台执行实际检查点的工具要启用它，我们需要设置--enable-criu-support=true标志上面的脚本可以为你做到这一点 另外，如果你打算将其恢复到 Pod 中，还需要将--drop-infra-ctr设置为 false，否则您将收到CreateContainerError并显示如下消息：。

kubeletError:podlevelPIDnamespacerequestedforthecontainer,... ...butpodsandboxwasnotsimilarlyconfigured,anddoesnothaveaninfracontainer

在安装了 CRI-O 之后，我们还需要告诉 kubeadm 使用它的 sock 文件，下面的配置将会处理这个问题：apiVersion:kubeadm.k8s.io/v1beta3 kind:InitConfiguration localAPIEndpoint: advertiseAddress:192.168.56.2 bindPort:6443 nodeRegistration: criSocket:"unix:///var/run/crio/crio.sock" ---

然后我们就可以使用以下命令快速启动集群：kubeadminit--config=.../kubeadm-config.yaml--upload-certs|teekubeadm-init.out 这将给我们提供一个单节点集群，如下（注意容器运行时版本）：

$kubectlgetnodes-owide NAMESTATUSROLESAGEVERSION...OS-IMAGEKERNEL-VERSIONCONTAINER-RUNTIME kubemasterReadycontrol-plane82sv1.25.4...Ubuntu20.04.5LTS5.4.0-125-genericcri-o://1.25.0

Checkpointing 集群安装完成后，我们可以尝试创建一个检查点在 Kubernetes 上通常可以使用 kubectl 或者运行 curl 命令来执行常规操作，访问集群 APIServer。

然而，在这里这样做是行不通的，因为检查点 API 只暴露在每个集群节点上的 kubelet 上因此，我们必须前往节点上并直接与 kubelet 交互：$vagrantsshkubemaster $sudosu- #Checkifitsrunning... $systemctlstatuskubelet kubelet.serv

ice-kubelet:TheKubernetesNodeAgent Loaded:loaded(/lib/systemd/system/kubelet.service;enabled;vendorpreset:enabled) Drop-In:/etc/systemd/system/kubelet.service.d └─10-kubeadm.conf Active:active(running)sinceSat2022-11-121029UTC;30sago Docs:https://kubernetes.io/docs/home/ MainPID:29501(kubelet) Tasks:14(limit:2339) Memory:34.7M CGroup:/system.slice/kubelet.service └─29501/usr/bin/kubelet--bootstrap-kubeconfig=...--kubeconfig=...

为了创建检查点，我们还需要一个正在运行的 Pod让我们在 default 命名空间中创建一个 Nginx Pod：$kubectltaintnodes--allnode-role.kubernetes.io/control-plane- $kubectlrunwebserver--image=nginx-ndefault $kubectlgetpods-owide NAMEREADYSTATUSRESTARTSAGEIPNODE webserver1/1Running027s10.85.0.4kubemaster 。

这里我们从节点中删除了污点，这样即使它是控制平面，我们也可以在节点上调度工作负载 接下来，让我们向 kubelet 发出一个示例 API 请求，来查看是否正常：$curl-skv-XGET"https://localhost:10250/pods" --key/etc/kubernetes/pki/apiserver-kubelet-client.key --cacert/etc/kubernetes/pki/ca.crt --cert/etc/kubernetes/pki/apiserver-kubelet-client.crt { "kind":"PodList", "apiVersion":"v1", "metadata":{}, "items":[ { "metadata":{ "name":"webserver", "namespace":"default", ... } } ... } 。

kubelet 默认运行在端口 10250 上，因此我们使用 curl 命令并请求其所有的 Pod我们还需要指定 CA 证书、客户端证书和密钥进行身份验证 接下来就可以创建一个检查点了：$curl-sk-XPOST"https://localhost:10250/checkpoint/default/webserver/webserver" --key/etc/kubernetes/pki/apiserver-kubelet-client.key --cacert/etc/kubernetes/pki/ca.crt --cert/etc/kubernetes/pki/apiserver-kubelet-client.crt #Response: #{"items":["/var/lib/kubelet/checkpoints/checkpoint-webserver_default-webserver-2022-11-12T1013Z.tar"]} #Checkthedirectory: $ls-l/var/lib/kubelet/checkpoints/ total3840 -rw-------1rootroot3931136Nov1210:28checkpoint-webserver_default-webserver-2022-11-12T1013Z.tar #Verifythatoriginalcontainerisstillrunning: $crictlps--namewebserver CONTAINERIMAGECREATEDSTATENAMEATTEMPTPODIDPOD 880ee7ddff7f3docker.io/library/nginx@sha256:...48secondsagoRunningwebserver0d584446dd8d5ewebserver 。

检查点 API 位于.../checkpoint/${NAMESPACE}/${POD}/${CONTAINER}，这里我们使用之前创建的 Pod，此请求在/var/lib/kubelet/checkpoints/checkpoint-

_--.tar中创建了一个存档 运行上述 curl 后，您可能会收到如下错误：checkpointingofdefault/webserver/webserverfailed(CheckpointContainerisonlysupportedintheCRIv1runtimeAPI) #or checkpointingofdefault/webserver/webserverfailed(rpcerror:code=Unknowndesc=checkpoint/restoresupportnotavailable) 。

这意味着您的容器运行时尚不支持检查点功能，或者未正确启用 分析 我们现在有了一个检查点容器存档，所以让我们看看里面有什么：$cd/var/lib/kubelet/checkpoints/ #Renamebecause"tar"doesntlike":"innames $mv"checkpoint-webserver_default-webserver-2022-11-12T1013Z.tar"webserver.tar #Viewcontents: $tar--exclude="*/*"-。

tfwebserver.tar dump.log checkpoint/ config.dump spec.dump rootfs-diff.tar io.kubernetes.cri-o.LogPath #Extract: $tar-xfcheckpoint-webserver_default-webserver-2022-09-04T1037Z.tar $lscheckpoint/ cgroup.imgfdinfo-4.imgids-31.imgmountpoints-13.imgpages-2.imgtmpfs-dev-139.tar.gz.img core-1.imgfiles.imginventory.imgnetns-10.imgpages-3.imgtmpfs-dev-140.tar.gz.img core-30.imgfs-1.imgipcns-var-11.imgpagemap-1.imgpages-4.imgtmpfs-dev-141.tar.gz.img core-31.imgfs-30.imgmemfd.imgpagemap-30.imgpstree.imgtmpfs-dev-142.tar.gz.img descriptors.jsonfs-31.imgmm-1.imgpagemap-31.imgseccomp.imgutsns-12.img fdinfo-2.imgids-1.imgmm-30.imgpagemap-shmem-94060.imgtimens-0.img fdinfo-3.imgids-30.imgmm-31.imgpages-1.imgtmpfs-dev-136.tar.gz.img $catconfig.dump { "id":"880ee7ddff7f3ce11ee891bd89f8a7356c97b23eb44e0f4fbb51cb7b94ead540", "name":"k8s_webserver_webserver_default_91ad1757-424e-4195-9f73-349b332cbb7a_0", "rootf

sImageName":"docker.io/library/nginx:latest", "runtime":"runc", "createdTime":"2022-11-12T1056.460946241Z" } $tar-tfrootfs-diff.tar var/cache/nginx/proxy_temp/ var/cache/nginx/scgi_temp/ var/cache/nginx/uwsgi_temp/ var/cache/nginx/client_temp/ var/cache/nginx/fastcgi_temp/ etc/mtab run/nginx.pid run/secrets/kubernetes.io/ run/secrets/kubernetes.io/serviceaccount/

如果您不需要一个正在运行的 Pod/容器进行分析，那么提取并阅读上面显示的一些文件可能会为您提供必要的信息 恢复 虽然 Checkpointing API 目前更加注重于调试分析，但它仍然可以用于从存档中恢复 Pod/容器。

最简单的方法是从检查点存档创建一个镜像：FROMscratch #NeedtouseADDbecauseitextractsarchives ADDwebserver.tar. 这里我们使用一个空（scratch）镜像，然后向其添加归档文件。

这里需要使用 ADD 命令，因为它会自动解压缩归档文件接下来，我们使用 docker 或 buildah 构建它$cd/var/lib/kubelet/checkpoints/ #Ordockerbuild... $buildahbud --annotation=io.kubernetes.cri-o.annotations.checkpoint.name=webserver -trestore-webserver:latest Dockerfile. $buildahpushlocalhost/restore-webserver:latestdocker.io/martinheinz/restore-webserver:latest

在上面，我们还添加了一个注解，描述了容器的原始可读名称，然后我们将其推送到一些仓库，以便 Kubernetes 可以拉取它最后，我们创建一个Pod，指定之前推送的镜像#pod.yaml apiVers

ion:v1 kind:Pod metadata: name:restore-webserver labels: app:nginx spec: containers: -name:webserver image:docker.io/martinheinz/restore-webserver:latest nodeName:kubemaster

为了测试是否成功，我们可以通过 Service 将 Pod 暴露出来，并使用 curl 命令访问其IP地址$kubectlexposepodrestore-webserver--port=80--target-port=80 $kubectlgetsvc NAMETYPECLUSTER-IPEXTERNAL-IPPORT(S)AGE kubernetesClusterIP10.96.0.1。

443/TCP14m restore-webserverClusterIP10.104.30.9080/TCP17s $curlhttp://10.104.30.90 Welcometonginx!

... 可以看到生效了，我们成功地在不停止它的情况下备份了并恢复一个正在运行的 Pod 总结 Kubernetes 的检查点功能是增强容器化应用程序容错性和弹性的强大工具通过实施良好规划的检查点策略，你可以将停机时间降至最低，改善资源利用情况，并简化应用程序迁移。

优点 增强的容错性——检查点功能使应用程序能够在故障发生时从最后一个已知检查点恢复，减少停机时间，并确保应用程序保持高可用性 简化迁移——检查点功能使将正在运行的应用程序移动到不同主机变得更加容易。

通过保存应用程序的状态，您可以将其迁移到不同的节点，而不会丢失进度或造成中断如果您的应用程序需要很长时间的预热，您可以利用这个功能这将大大减少应用程序的启动时间 改进的扩展性——通过检查点功能，您可以轻松地扩展应用程序以满足波动的需求。

如果一个节点过载了，您可以将应用程序迁移到拥有更多资源的另一个节点，确保最佳性能 高效的资源使用——检查点功能允许您暂停长时间运行的应用程序，释放资源给其他任务使用当再次需要应用程序时，可以从检查点恢复。

Kubernetes 检查点的最佳实践 定期创建检查点——根据应用程序的要求，定期创建检查点，以最小化在故障发生时的数据丢失 监控和管理资源——检查点功能可能消耗大量系统资源，尤其是内存监控集群的资源使用情况，并根据需要调整检查点策略，以避免性能问题。

测试您的检查点策略——定期测试您的检查点过程，确保其按预期工作，并能在故障发生时恢复应用程序 自动化检查点管理——使用像 cron 作业或 Kubernetes Operator 这样的自动化工具，在预定的时间表上创建和管理检查点，确保您的应用程序始终受到保护。

审核编辑：刘清

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。