zoukankan      html  css  js  c++  java
  • K8S Pod挂载rook ceph pv报not found in the list of registered CSI drivers异常处理


    系统环境

    • Centos8
    • Kubernetes 1.19.3 集群(  3 master + 3 work)
    • Rook安装ceph集群(3 osd配置在master节点)

    问题描述

            通过指定Pod StorageClass关联动态创建ceph block pv,当Pod实例调度到master节点后一直处于Pending状态,检查Pod日志发现:MountVolume.MountDevice failed for volume "pvc-caaaecd7-4068-4817-ac4e-f2f41bd82aee" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name rook-ceph.rbd.csi.ceph.com not found in the list of registered CSI drivers错误信息。

    解决过程

    问题分析

          根据错误信息可以发现问题是出在pod挂载pv时,因无法找到rook-ceph.rbd.csi.ceph.com驱动。但是这个pod在work节点时是正常运行的,调度到master节点时却产生错误。我们知道k8s master节点因为taints的原因一般情况下常规pod是不会调度到master节点的,我们的pod之所以可以调度在master节点是因为设置了tolerations,那么是不是因为master节点没有运行相关ceph csi相关的pod?

    初步解决

    1、检查csi相关的pod

    kubectl get pod  -n rook-ceph | grep csi
    image

    相关csi的pod共有四个csi-cephfsplugin、csi-cephfsplugin-provisioner、csi-rbdplugin、csi-rbdplugin-provisioner,并且这四个都是运行在work节点。我们使用的是block存储,实际上我们只需要关注csi-rbdplugin和csi-rbdplugin-provisioner。

    2、检查csi-rbdplugin和csi-rbdplugin-provisioner的调度控制器

    kubectl get deployment,daemonset,statefulset -n rook-ceph  | grep csi-rbdplugin

    image

    检查发现csi-rbdplugin-provisioner是deployment控制器,csi-rbdplugin是daemonset控制器,daemonset控制器可以保障每个可调度节点运行一份副本,做为节点csi驱动daemonset相比deployment更适合一些,那么csi-rbdplugin更有可能是csi驱动管理pod,那么我们就先将它调度到master节点试试。

    3、编辑csi-rbdplugin deployment使可以调度到master节点

    kubectl edit daemonset csi-rbdplugin -n rook-ceph

    image

    4、检查csi-rbdplugin调度结果

    kubectl get pod -n rook-ceph -o wide  | grep csi-rbdplugin
    

    image

    csi-rbdplugin的pod实例已经由3个变成了6 ,所有master节点和node节点都运行 起来

    5、检查需要加载ceph pv是master节点pod状态

    kubectl get pod –o wide | grep csirbd-demo

    image

    Pod已经在master节点正常运行,pv看来是正常加载了,那么问题真的解决了吗?

    再起风波

            哎呦,今天解决个小问题,美滋滋的。晚上下班检查并关闭好服务器,回家了。。。第二天早上,到公司开启服务器后习惯性的检测下pod的状态。哟,昨天那个pod又pending了?kubectl logs看下日志,咋还是昨天的错误?赶紧的看下csi-rbdplugin的pod发现主节点上又没运行了,而daemonset配置项中昨天添加的tolerations也没了。。

           好吧,修改过的daemonset竟然恢复了,那么看来rook有一定的恢复机制,那么也只能从rook的配置信息入手了,翻看官方文档当,这个东西只能从rook配置参数入手了。

    最终方案

    1、初步发现

          在rook ceph群集配置文件中发现cluster.yaml文件中有placement用来控制pod的调度。但是经过测试这参数只能控制osd、mgr、mon等pod的调度。再之后发现driveGroups配置参数,但是它只是控制osd的加载及分组。翻看了无数rook ceph相关的文挡,都没有发现有csi相关pod调度的配置信息。无奈只能在github的rook源码中查询所有相关csi的文件了Crying face,最终在operator.yaml文件中找到了CSI_PLUGIN_TOLERATIONS配置项,看来它就是csi tolerations调度的关键了。最重要的是,官方搞了那么多使用方面的文挡而这么重要的配置信息却没有相关文挡?

    2、修改operator.yaml,并执行变更

    image

    kubectl apply -f operator.yaml

    csi-rbdplugin又在master节点上调度运行了,问题也终于解决了。

    3、其它

          operator.yaml实际上最终是要反应在k8s对象中去的,经过排查,我们在operator.yaml中修改的CSI_PLUGIN)TOLERATIONS最终是体现在rook-ceph-operator-config这个configmap配置中,也可以通过直接修改这个达到目地

    image
  • 相关阅读:
    URL中增加BASE64加密的字符串引起的问题(java.net.MalformedURLException:Illegal character in URL)
    读《暗时间》总结
    假设写一个android桌面滑动切换屏幕的控件(一)
    JDBC Connection Reset问题分析
    深度学习工具caffe具体安装指南
    TS2
    TS 函数解析
    typescript
    响应式网页设计:rem、em设置网页字体大小自适应
    一看就懂得移动端rem布局、rem如何换算
  • 原文地址:https://www.cnblogs.com/lswweb/p/13860186.html
Copyright © 2011-2022 走看看