批准 csr 需先确认其状态为 pending，再执行 kubectl certificate approve ；成功后状态变为 approved,issued，但需手动提取证书并更新客户端配置（如 kubeconfig 或 kubelet 证书路径），且依赖 kube-controller-manager 的 –cluster-signing-duration 参数控制有效期。
如何用 kubectl certificate approve 批准 CSR？
批准 CSR 的核心就是让 kubernetes API Server 把待签名的证书请求转给证书颁发组件（通常是 kube-controller-manager 的 csrapproving controller）。只有状态为 Pending 的 CSR 才能被批准。
- 先用
kubectl get csr确认 CSR 名称和状态，避免误批已批准或失败的请求 - 执行
kubectl certificate approve <csr-name></csr-name>，成功后状态变为Approved,Issued - 批准后不会自动下载证书——需手动用
kubectl get csr <name> -o jsonpath='{.status.certificate}' | base64 -d > client.crt</name>提取 - 如果报错
Error: the server doesn't have a Resource type "certificatesigningrequests"，说明集群未启用 CSR API（Kubernetes
为什么 kubectl certificate approve 后证书没生效？
批准只是第一步，证书真正生效依赖客户端能否加载并使用新证书，常见断点在 kubeconfig 或服务端信任链。
- 批准后，kubelet 或客户端仍用旧证书连接 API Server？检查其配置是否指向了新证书路径，比如
kubeconfig中的client-certificate-data是否已更新 - kubelet 的证书轮换默认开启（
--rotate-certificates=true），但首次批准 CSR 后，它不会立即重载——需重启 kubelet 或等待下一次轮换周期（默认 70% 到期时间） - API Server 不会主动推送新证书给客户端；若用自建 CA，确保客户端信任该 CA 根证书（如
ca.crt已写入kubeconfig的certificate-authority-data） - 批准 CSR 后，
kubectl get node仍显示NotReady？查kubelet日志是否有x509: certificate has expired or is not yet valid——说明旧证书已过期，但新证书还没被加载
怎么清理过期的 CSR 和证书？
Kubernetes 不自动清理 CSR，尤其长期运行的集群里积压大量 Failed 或 Approved,Issued 的旧 CSR，既干扰排查，又可能触发 etcd 存储压力。
- 删过期/无效 CSR：
kubectl delete csr $(kubectl get csr -o jsonpath='{range .items[?(@.status.phase=="Failed")]}{.metadata.name}{"n"}{end}')，注意别误删Pending请求 - 清理已签发但不再使用的证书：CSR 本身不能“撤回”，只能删 CSR 对象；真正要清理的是客户端本地的过期证书文件（如
/var/lib/kubelet/pki/kubelet-client-current.pem），删前确认对应服务已停或证书已轮换完成 - 批量清理 30 天前的 CSR：
kubectl get csr -o=jsonpath='{range .items[?(@.metadata.creationTimestamp，注意 shell 时间格式兼容性（不同系统 <code>date参数略有差异） - etcd 中 CSR 对象默认不设 TTL，不清理就一直存在；建议配合 cronjob 定期扫描 + 删除，而不是等出问题再手动救火
CSR 签发后证书为何 1 年就过期？能改吗？
默认有效期由 kube-controller-manager 的 --cluster-signing-duration 参数控制，v1.22+ 默认是 1 年（8760h），且无法通过 CSR 对象字段覆盖。
- 修改有效期必须重启 kube-controller-manager，并传入新参数，例如
--cluster-signing-duration=4380h（半年） - 该参数影响所有由 CSR 流程签发的证书（包括 kubelet、bootstrapping client），但不影响静态配置的证书（如 API Server 自己的
--tls-cert-file） - 调短有效期会增加轮换频率，但提升安全性；调太长（如 10 年）则违背最小权限和定期轮换原则
- 注意：即使你把 duration 设得很长，kubelet 自身的
--rotate-server-certificates（服务端证书轮换）默认是关的，且只对客户端证书有效——服务端证书仍需手动替换
CSR 生命周期管理不是“批准完就结束”，关键在批准后的证书落地、旧证书清理节奏、以及集群级参数对所有签发行为的隐式约束。最容易被忽略的是：批准 CSR 和客户端实际切换到新证书之间存在延迟，而这个延迟常常被当成“批准没生效”。