故障现象 服务挂上rbd正常读写，经过很长时间之后再次发布就会出现timeout的错误，导致服务无法启动，但是如果强制把服务缩容到0，然后再发布改成1，这样就能启动成功，短时间内再次进行发布操作，rbd...挂载 卸载又很正常了，故障再不会出现了 故障表现 rbd map进程卡住无法正常退出 rbd map rbd19 --id admin -m xxxx --key=xxxxx 应用启动报错 timeout...expired waiting for volumes to attach or mount for pod 挂载rbd超时 故障的原因 ceph版本小于ceph version 12.2.8-291...rbd map进程卡住之后，kubelet迟迟等不到进程的正常返回，进而判断map超时，于是就是打印'timeout expired waiting for volumes to attach or mount...for pod' 解决办法 升级ceph-common
排查思路 先检查Pod 启动的阶段发生了什么问题: kubectl describe po -n {namespace} 发现是挂在pv超时 `Unable to mount volumes for pod...“xxx-test-xx-0_ns-prj57r7d-1091927-test(52bcf47a-2354-11eb-a92c-525400b26555)”: timeout expired waiting...for volumes to attach or mount for pod “ns-prj57r7d-1091927-test”/“xxx-test-xx-0”. list of unmounted...volumes=pretty. list of unattached volumes=pretty cgroup shm xx filebeatdata applogdata filebeatconfig...default-token-lgrlv 在pod启动流程里，在pod启动先挂载pv，块存储的pv 会有2个动作一个是attach 一个mount, attach阶段是调用cbs 去挂载磁盘到node节点
节点发生故障时，在 40 秒内（由 Controller Manager 的 --node-monitor-grace-period 参数指定），节点进入 NotReady 状态，经过 5 分钟（由 --pod-eviction-timeout...Multi-Attach error for volume "pvc-2de7d17c-04c6-11eb-b22b-5254002d96de" Volume is already used by pod...volumes for pod "sleep-6f7c8cc954-5hptw_default(9d6caec9-04d1-11eb-afd2-525400c74ddd)": timeout expired...waiting for volumes to attach or mount for pod "default"/"sleep-6f7c8cc954-5hptw". list of unmounted...\/pods\/([0-9a-z-]+)\/volumes.*?
到这些node上的volumes。...的事件可以看出来：ad controller认为cbs attach成功了，然后kubelet没有mount成功。...manager的dsw缓存中获取要被mount的volumes（volumesToMount的podsToMount ） 然后遍历，验证每个volumeToMount是否已经attach了 这个volumeToMount...timeout expired 的报错 所以接下来主要需要看为什么ad controller那边没有更新node.Status.VolumesAttached。...pod所有的volume attach和mount成功时，就超时了(现象中的另一个报错timeout expired wating...)。
or mount volumes: unmounted volumes=[registry-data], unattached volumes=[default-token-phjbz registry-data...or mount volumes: unmounted volumes=[registry-data], unattached volumes=[registry-htpasswd registry-config...Warning FailedMount 5m21s (x2 over 16m) kubelet, k8s03 Unable to attach or mount...FailedMount 3m5s (x2 over 9m55s) kubelet, k8s03 Unable to attach or mount volumes...or mount volumes: unmounted volumes=[registry-data], unattached volumes=[registry-data registry-root-certificate
volumes for pod "tspms-5c97cb47bc-jzhkd_ts-development(8b986f57-ff44-lle8-93d9-Oa587f800f51)": timeout...expired waiting for volumes to a ttach or mount for pod "ts-development'7"tspms-5c97cb47bc-jzhkd".list...of unmounted volumes=[runtimeJ.list of unattached volumes=[runtime default-token-wfhg7) 由于之前有过历史的问题是...runtime 之前有询问过得出的nfs 挂载格式： v4： mount -t nfs4 vip:/ /localdir v3: mount -t nfs -o vers=3 vip:/fsid /localdir...在yaml文件的体现为： volumes: - name: runtime nfs: path: /8pw2jq8u/tspms/ts-development/runtime
上的 volumes。...5.1 案例初步分析 从 pod 的事件可以看出来：ad controller认为 cbs attach 成功了，然后 kubelet 没有 mount 成功。...此时会先从 volume manager 的 dsw 缓存中获取要被 mount 的 volumes（volumesToMount的podsToMount ）； 然后遍历，验证每个volumeToMount...timeout expired 的报错。...status 之后 kubelet 的syncPod在等待 pod 所有的 volume attach 和 mount 成功时，就超时了(现象中的另一个报错timeout expired wating
,并且该Pod挂载了数据卷(volume)，阻碍了Kubelet对孤儿Pod正常的回收清理，所以我们要清理该孤儿pod。...volumes for pod "tspms-5c97cb47bc-jzhkd_ts-development(8b986f57-ff44-lle8-93d9-Oa587f800f51)": timeout...expired waiting for volumes to a ttach or mount for pod "ts-development'7"tspms-5c97cb47bc-jzhkd".list...of unmounted volumes=[runtimeJ.list of unattached volumes=[runtime default-token-wfhg7) 问题描述：挂载NFS...v3版本 一定要加上fsid nfs 挂载格式： v4： mount -t nfs4 vip:/ /localdir v3: mount -t nfs -o vers=3 vip:/fsid /localdir
Warning FailedMount 62s kubelet, 10.0.0.1 Unable to mount volumes for pod "nginx...-7b4d5d9fd-bmc8g_default(bb5501ca-9fea-11ea-9730-5254002f7cc9)": timeout expired waiting for volumes...to attach or mount for pod "default"/"nginx-7b4d5d9fd-nqgfz". list of unmounted volumes=[nginx-data]....volume detach操作，其它母机上的pod如果使用相同的volume会被挂住，最终导致容器创建一直阻塞并报错： Multi-Attach error for volume "pvc-7f68c087...=0 之后，对于新创建的pod，attachDetachController会在6mins(代码写死)后强制detach volume，并正常attach，如下： W0811 04:01:25.024422
Warning FailedMount 62s kubelet, 10.0.0.1 Unable to mount volumes for pod "nginx-...7b4d5d9fd-bmc8g_default(bb5501ca-9fea-11ea-9730-5254002f7cc9)": timeout expired waiting for volumes to...attach or mount for pod "default"/"nginx-7b4d5d9fd-nqgfz". list of unmounted volumes=[nginx-data]. list...volume detach操作，其它母机上的pod如果使用相同的volume会被挂住，最终导致容器创建一直阻塞并报错： Multi-Attach error for volume "pvc-7f68c087...=0 之后，对于新创建的pod，attachDetachController会在6mins(代码写死)后强制detach volume，并正常attach，如下： W0811 04:01:
{ if cs.State.Waiting !...%v", format.Pod(pod), err) return err } // 如果该pod没有被终止，那么需要等待attach/mount volumes if !...kl.podIsTerminated(pod) { // Wait for volumes to attach/mount if err := kl.volumeManager.WaitForAttachAndMount...mount volumes: %v", err) klog.Errorf("Unable to attach or mount volumes for pod %q: %v; skipping...； 校验网络插件是否已准备好，如果没有，直接返回； 如果该pod的cgroups不存在，那么就创建cgroups； 为静态pod创建镜像； 创建pod的文件目录，等待volumes attach/mount
volumes for pod "mysql-p3mcj_default(b949a085-ba8a-11ea-af28-000c2919d52d)": timeout expired waiting...for volumes to attach/mount for pod "default"/"mysql-p3mcj". list of unattached/unmounted volumes=[data..., skipping: timeout expired waiting for volumes to attach/mount for pod "default"/"mysql-p3mcj". list...)": timeout expired waiting for volumes to attach/mount for pod "default"/"mysql-njrhc". list of unattached...Error syncing pod, skipping: timeout expired waiting for volumes to attach/mount for pod "default
整个流程流程分别三个阶段：Provision/Delete、Attach/Detach、Mount/Unmount，不过不是每个存储方案都会经历这三个阶段，比如 NFS 就没有 Attach/Detach...下面分别详细分析一下 Provision、Attach、Mount 三个阶段。 Provision 先来看 Provision 阶段，整个过程如上图所示。...Mount 最后一步将 volume 挂载到 pod 里的过程涉及到 kubelet。...kl.podIsTerminated(pod) { // Wait for volumes to attach/mount if err := kl.volumeManager.WaitForAttachAndMount...or mount volumes: %v", err) klog.Errorf("Unable to attach or mount volumes for pod %q: %v; skipping
) apiVersion: v1 kind: Pod metadata: name: test-volumes spec: volumes: - name: nfs persistentVolumeClaim...我们只是在 volumes 中指定了我们上面创建的 PVC 对象，当这个 Pod 被创建之后， kubelet 就会把这个 PVC 对应的这个 NFS 类型的 Volume（PV）挂载到这个 Pod...： /var/lib/kubelet/pods//volumes/kubernetes.io~/ 比如上面我们创建的 Pod 对应的 Volume.../kubernetes.io~csi/pvc-c8861c23-c03d-47aa-96f6-73c4d4093109/mount 这里我们就经过了 Attach 和 Mount 两个阶段完成了 Volume...，当然和节点相关的操作比如 Mount/Unmount 也是在这个 Pod 里面执行的，其他的比如 Provision、Attach 都是在另外的 csi-rbdplugin-provisioner-xxx
整个流程流程分别三个阶段：Provision/Delete、Attach/Detach、Mount/Unmount，不过不是每个存储方案都会经历这三个阶段，比如 NFS 就没有 Attach/Detach...完成： func (kl *Kubelet) syncPod(o syncPodOptions) error { ... // Volume manager will not mount volumes...kl.podIsTerminated(pod) { // Wait for volumes to attach/mount if err := kl.volumeManager.WaitForAttachAndMount...attach or mount volumes: %v", err) klog.Errorf("Unable to attach or mount volumes for pod...，mount pod 才会被删除。
Volumes 介绍 Pod Volumes 场景一：如果 pod 中的某一个容器在运行时异常退出，被 kubelet 重新拉起之后，如何保证之前容器产生的重要数据没有丢失？...我们知道，同一个 pod 中多个容器想共享数据，可以借助 Pod Volumes 来解决；当多个 pod 想共享数据时，Pod Volumes 就很难去表达这种语义； 不同场景使用不同级别的资源...这个 attach 操作就是将存储 attach到 pod 将会运行的 node 上面。...mount 阶段：发生在kubelet 创建 pod的过程中，它在创建 pod 的过程中，首先要去做一个 mount，这里的 mount 操作是为了将已经attach到这个 node 上面那块盘，进一步...mount 到 pod 可以使用的一个具体路径，之后 kubelet 才开始创建并启动容器。
mount Attach a filesystem mount to the container --name string...a volume --volume-driver string Optional volume driver for the container --volumes-from...list Mount volumes from the specified container(s) -w, --workdir string...127.0.0.1', 5000) sk = socket.socket() sk.bind(ip_port) sk.listen(5) while True: print('server waiting...'0.0.0.0', 5000) sk = socket.socket() sk.bind(ip_port) sk.listen(5) while True: print('server waiting
一个是创建一个容器使用目标容器的ipc, pid, network, etc, filesystem，源码在这里 // CreateContainer create new container and attach...= "" { ctx, cancel := cli.withContent(cli.config.Timeout) info, err := cli.client.ContainerInspect...i.RW, }) } } if options.volumes !...= nil { // -v bind mount if mounts == nil { mounts = []mount.Mount{} } for _, m := range options.volumes...另外，还发现类似的工具kube-debug，以后诊断pod中的问题方便多了。
volume to node -> Mount volume to pod 这篇文章关注 Out-Of-Tree 的 FlexVolume/CSI FlexVolume/CSI 位于什么位置 [image...FlexVolume/CSI Plugin K8s挂载卷的基本过程（涉及的组件）： [image] 用户创建Pod包含一个PVC Pod被分配到节点NodeA Kubelet等待Volume Manager.../Detach controller或者Volume Manager通过Volume Plugin实现块设备挂载(Attach) Volume Manager等待设备挂载完成，将卷挂载到节点指定目录(mount...(un)mount: Kubelet 调用, Mount the volume at the mount dir. CSI CSI 的执行流程 正在上传图片......- -c - ls /data volumeMounts: - name: test mountPath: /data volumes
就能够像使用 hostPath 等常规类型的 Volume 一样，在自己的 YAML 文件里声明使用这个 PVC 了，如： Pod 可以在 volumes 字段里声明自己要使用的 PVC 名字 接下来.../pods//volumes/kubernetes.io~/ 1.4.1.1 Attach 如果 Volume 类型是远程块存储，那么...中，我们把这个阶段称为 Attach Kubernetes 提供的可用参数是 nodeName，即宿主机的名字 1.4.1.2 Mount Attach 阶段完成后，为了能够使用这个远程磁盘，kubelet...里的容器挂载这个“持久化”的 Volume 了 其实，这一步相当于执行了如下所示的命令：docker run -v /var/lib/kubelet/pods//volumes/kubernetes.io...和 Mount 三个阶段 其中，Privision 等价于“创建远程磁盘块”，Attach 等价于“注册磁盘到虚拟机”，Mount 等价于“将该磁盘格式化后，挂载在 Volume 的宿主机目录上” 当
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
