kube-controller-manager组件故障导致pvc创建异常

一、背景

开发测试环境需求，需为服务挂载卷存储，使用gfs作为存储类，创建pvc指定卷大小；

#pvc的yaml文件样板 apiVersion: v1 kind: PersistentVolumeClaim metadata:   name: my-pvc spec:   accessModes:     - ReadWriteMany   resources:     requests:       storage: *Gi   storageClassName: glusterfs-storage   volumeMode: Filesystem #发现该pvc一直处于pending状态，即无法与pv邦定；后面又查看集群中的heketi组件日志，没有发出创建pv的请求 先说解决方法：修改controller-manager所在节点上的时间，使其恢复CST正常时间

二、排故

$ kubectl describe pvc my-pvc -n default #显示详细信息请查看kube-controller-manager组件 $ kubectl logs controller-manager-* -n kube-system Leaderelection .go:520errorretrieving resourceLockkube -system/kube-controtler-manager https:/**.**/api/Vl /namespaces/kube-system/endpoints/kube-controLler-manager?t1meout-10s:context deadline exceeded #怀疑是controller-manager选主机制出现问题 controller-manager存在选主机制，只有主节点才会调用 StartControllers() 启动所有控制器，而其他从节点则仅执行选主算法（选出的主去不断更新kube-controller-manager的endpoint资源，维护自己的主地位） 个人猜测：由于时间变动（在证书时间范围内，集群节点状态正常），导致管理节点上controller-manager组件无法根据选主算法维护kube-controller-manager的endpoint资源，导致集群内部的controller-manager集群没有主去启动各种控制器（创建或者跟新资源），导致资源创建处于pending状态； pv创建： 图一：pv创建图（个人理解） #pv-controller机制： PV对象主要状态变更 （1）available --> bound：一个pv对象创建出来后，处于available状态。pv controller会为pvc对象寻找合适的pv对象与之绑定，随即pv对象状态变更为bound。 （2）bound --> released：当与pv绑定的pvc对象被删除后，如果回收逻辑为retain，则pv对象状态变更为released。 pvc对象主要状态变更 （1）pending --> bound：一个pvc对象创建出来后，处于pending状态。pv controller会为pvc对象寻找合适的pv对象与之绑定，随即pvc对象状态变更为bound。————>当没有正常创建pv，无法绑定pv就是pending状态 #小tips pvc如何选择合适的pv来绑定？ （1）volumeName匹配：当pvc对象中指定了volumeName属性，则会直接查询名称为该volumeName属性值一致的pv，并与之绑定，当该pv不存在时，该pvc会一直处于pending状态； （2）volumeMode匹配：选择具有与pvc相同的volumeMode的pv（Block/FileSystem）； （3）storageclass匹配：选择具有与pvc相同的stroageclass名称的pv； （4）accessMode匹配：选择具有与pvc相同的accessMode的pv； （5）size检查：选择size大于等于且最接近pvc的size声明的pv。

 三、参考文献

k8s组件机制：3. 核心组件 - 3.4 kube-controller-manager - 《Kubernetes Handbook （Kubernetes指南）(201803)》 - 书栈网 · BookStack

组件选举：Kubernetes 实战-Leader 选举 · Yiran's Blog (zdyxry.github.io)

博客：4.深入k8s：持久卷PV、PVC及其源码分析 - luozhiyun - 博客园 (cnblogs.com)

k8s官网：Kubernetes