Ansible部署K8s时kubelet-serving类型CSR延迟生成疑问

1. kubernetes.io/kubelet-serving 类型CSR的触发时机 #

这类CSR由节点上的kubelet进程主动提交，完整触发链路有严格的先后顺序，不存在随机延迟：

• kubelet启动后首先使用bootstrap令牌申请客户端证书，对应集群中出现kubernetes.io/kube-apiserver-client-kubelet类型的CSR，这类CSR被批准、签发后，kubelet才获得合法的集群访问身份
• kubelet使用拿到的客户端证书完成节点注册，对应集群中创建对应的Node资源对象，kubelet开始正常上报节点状态
• 当kubelet检测到本地不存在受集群CA信任的服务端证书，且启动参数中开启了--rotate-server-certificates=true时，才会构造服务端证书申请，以system:node:<节点名称>的身份提交CSR，也就是目标的serving类型CSR。

注：kubelet在拿到客户端证书后不会立刻提交服务端证书申请，会先完成自身初始化、节点状态上报等前置操作，正常流程下这部分耗时在10-30秒区间。

2. CSR延迟出现的根本原因 #

你观察到的延迟现象完全是Ansible的默认执行机制导致的，和kubelet本身的逻辑无关：

• 你在playbook中配置的「重启kubelet」操作属于Ansible的Handler类型任务，这类任务默认不会在被通知后立刻执行，会在当前Play下所有普通任务全部执行完成后，才会统一批量触发执行。
• 你之前添加的固定时长等待属于普通任务，执行顺序排在Handler队列之前：等待任务运行时，kubelet实际上还没有被重启，整个等待周期属于无效空等。等所有普通任务（包括你加的等待）全部跑完，Ansible才会真正执行kubelet重启操作，之后kubelet才会走证书申请、节点注册、提交serving CSR的完整流程。
• 你的测试数据可以直接印证这个逻辑：未加等待时，客户端CSR和serving CSR的时间差为18秒，是kubelet本身的流程耗时；加了90秒等待后，时间差变为108秒，刚好多出90秒的空等时长，和Ansible的执行时序完全吻合。

可直接落地的修复方案 #

• 不要用默认Handler机制触发kubelet重启：将重启kubelet的操作改为普通任务，在kubelet配置文件下发、服务参数配置完成后立刻执行，不要等全量任务跑完再重启
• 放弃固定时长等待，改用轮询机制等待目标CSR生成：不需要依赖k8s_info模块自带的资源等待能力，直接用Ansible的until循环实现轮询：重启kubelet后每5秒调用一次k8s_info拉取全量CSR列表，本地过滤signerName=kubernetes.io/kubelet-serving的条目，直到过滤后的CSR数量和集群节点数一致再停止轮询，最长等待阈值设置为120秒即可覆盖所有极端场景
• 确认所有目标CSR都存在后，再执行CSR批准、证书分发的后续操作。

内容的提问来源于stack exchange，提问作者홍한석