k0s 证书体系解析与 Kubernetes CA / SA 密钥对手动更换实战指南

云原生容器编排边缘计算【免费下载链接】k0sk0s - The Zero Friction Kubernetes项目地址https://gitcode.com/gh_mirrors/k0/k0s点击查看免费下载k0s 在集群初始化时自动生成并管理一组 PKI公钥基础设施文件涵盖 Kubernetes 集群通信、etcd 通信与服务账户Service Account令牌签名三大用途。本文以 k0s 官方证书文档为主体结合仓库源码深入剖析 k0s 的证书体系结构、默认生命周期与底层实现并给出在证书到期前手动更换 Kubernetes CA 与 SA 密钥对的完整、可落地的操作步骤帮助运维人员在多节点集群中安全完成 CA 轮换。k0s 管理哪些证书材料两类 CA 与一对 SA 密钥k0s 维护着两个证书颁发机构CA和一对公钥/私钥对它们都在集群初始化期间自动创建默认存放在数据目录的pki子目录下默认数据目录为/var/lib/k0s材料默认路径用途Kubernetes CA/var/lib/k0s/pki/ca.crt、ca.key为 Kubernetes API 通信签发服务端与客户端证书是整个集群信任链的根etcd CA/var/lib/k0s/pki/etcd/ca.crt、ca.key仅在启用 k0s 管理的 etcd 时使用用于保护 etcd 集群内部通信Kubernetes Service AccountSA密钥对/var/lib/k0s/pki/sa.pub、sa.key用于对 Kubernetes 的 Service Account 令牌进行签名与校验这三类材料有以下共同特征初始化时自动生成k0s 首次启动控制器时若发现 CA 文件不存在会自动创建它们无需人工干预。默认有效期 10 年Kubernetes CA 与 etcd CA 默认有效期均为 10 年。通过加入join流程一次性分发CA 材料随 k0s 的 加入流程 分发给所有控制器节点之后各节点上的 CA 保持一致。替换是纯人工操作k0s 目前没有 CA 自动续期机制证书到期或需要轮换时必须按本文流程手动完成。从源码看证书的自动生成与默认生命周期k0s 的证书管理逻辑集中在pkg/certificate/manager.go中核心方法是三个幂等操作EnsureCA(name, cn, expiry)若data-dir/pki/name.key与.crt不存在则生成自签名的 CA 证书。生成时通过 cfssl 的initca.New创建RSA 2048 位密钥对并以原子写入方式落盘私钥使用安全文件权限见constant.CertSecureMode。EnsureCertificate(certReq, ownerID, expiry)检查目标证书是否已存在、且签发者是否为 k0s 管理的 CA通过isManagedByK0s比对签发者 Common Name 是否为kubernetes-ca、kubernetes-front-proxy-ca、etcd-ca等必要时用对应 CA 为组件签发新证书并设置文件属主。CreateKeyPair(name, ...)生成sa.key/sa.pub这样不带证书的 RSA 密钥对用于 SA 令牌签名。控制器启动时实际调用这些方法的组件是cmd/controller/certificates.go中的Certificates.Init它通过 errgroup 并发创建 Kubernetes CACN 为kubernetes-ca、front-proxy CA以及 admin、konnectivity、ccm、scheduler、apiserver-kubelet-client、server、k0s-api 等一系列组件证书与 kubeconfig最后创建 SA 密钥对。CA 与证书的有效期是可配置的定义在pkg/apis/k0s/v1beta1/cert.go中对应集群配置的spec.api.ca字段expiresAfterCA 证书本身的过期时长默认87600h10 年certificatesExpireAfter由该 CA 签发的组件证书server、client 证书等的过期时长默认8760h1 年。也就是说实际中更早到期的是各组件证书默认 1 年而 CA 根证书默认 10 年才到期。k0s 在每次启动时会自动重新生成过期或 SAN 列表变化的组件证书regenerateCert逻辑但根 CA 与 SA 密钥对不会自动轮换——这正是本文需要手动更换它们的根本原因。更换 Kubernetes CA 与 SA 密钥对完整操作手册下面的流程采用先停机、再重生成、后重新分发、最后恢复上线的方式手动更换集群的 Kubernetes CA 和 SA 密钥对。整个过程在默认数据目录/var/lib/k0s下展开如果你的节点使用了自定义数据目录请相应替换所有路径。第 1 步先备份再动手任何对 PKI 的改动都存在把集群改坏的风险动手前务必先做 备份。k0s 的备份机制覆盖 etcd 数据、证书与配置文件可用于失败时回滚。第 2 步停止所有节点上的 k0s在所有 worker 和 controller 节点上停止 k0s 服务确保没有进程正在使用旧的证书材料。第 3 步删除旧的 CA 与 SA 材料在所有控制器数据目录中删除 Kubernetes CA 和 SA 密钥对文件/var/lib/k0s/pki/ca.crt/var/lib/k0s/pki/ca.key/var/lib/k0s/pki/sa.pub/var/lib/k0s/pki/sa.key同时在所有worker数据目录中删除 kubelet 的 kubeconfig 文件和 PKI 目录/var/lib/k0s/kubelet.conf/var/lib/k0s/kubelet/pki注意以--enable-worker标志启动的控制器节点同时扮演 controller 与 worker 两种角色因此在它们身上既要在控制器目录删除 CA/SA 文件也要删除 kubelet.conf 与 kubelet/pki 目录。相关行为可从源码佐证worker 侧 kubelet 使用的认证文件路径即kubelet.conf定义于pkg/config/cfgvars.go的KubeletAuthConfigPath而 bootstrap 依赖的临时 kubeconfig 逻辑在pkg/component/worker/utils.go的BootstrapKubeletClientConfig中。第 4 步重启第一个控制器让 k0s 重新生成 CA从所有控制器中挑一个作为第一个控制器重启它上面的 k0s。如果该控制器没有--enable-worker标志直接重启 k0s 服务即可如果该控制器带--enable-worker标志必须重启整台机器以保证所有进程与 Pod 干净地重新拉起。重启后k0s 检测到pki目录下的 CA 文件已被删除会按第 2 节描述的EnsureCA/CreateKeyPair逻辑自动重新生成一套全新的 Kubernetes CA 和 SA 密钥对。第 5 步把新 CA/SA 材料分发到其余控制器将下面四个文件从第一个控制器复制到其余每一个控制器/var/lib/k0s/pki/ca.crt/var/lib/k0s/pki/ca.key/var/lib/k0s/pki/sa.pub/var/lib/k0s/pki/sa.key复制完成后新 CA 与 SA 密钥对即在所有控制器上就位。然后重启其余控制器上的 k0s——同样地带--enable-worker的控制器需要重启整台机器。为什么必须手动分发而不是让每个控制器各自重新生成因为 k0s 的加入join机制保证所有控制器共享同一套 CA若各控制器独立生成新 CA集群将出现多套信任根API 服务器、kubelet、组件之间的双向认证会全面失效。第 6 步重新加入所有 worker更换 CA 后旧 kubelet 证书已作废所有 worker 节点需要重新执行加入流程。最便捷的方式是使用kubelet-bootstrap.conf引导文件。先在任意控制器上生成一个 join token 并转换为 bootstrap kubeconfig 文件具体命令如下关于 join token 的机制详见 k0s 多节点部署文档中的 join tokens 章节touch /tmp/rejoin-token chmod 0600 /tmp/rejoin-token k0s token create --expiry 1h | base64 -d | gunzip /tmp/rejoin-token命令说明k0s token create --expiry 1h生成一个 1 小时有效的 join token对应cmd/token/create.go中的create子命令--expiry控制令牌有效期token 以 gzip 压缩的 base64 编码输出因此需要先base64 -d解码再gunzip解压得到真正的 kubeconfig 内容重定向到/tmp/rejoin-token并提前用touchchmod 0600保证文件以仅属主可读的权限创建bootstrap kubeconfig 内含私钥材料权限必须收紧。然后把这个 token 文件复制到每个 worker 节点放置为/var/lib/k0s/kubelet-bootstrap.conf之后重启该机器的系统。重启后 k0s worker 进程会读到该引导文件经由 Kubernetes 的 kubelet bootstrap 流程向 API 服务器申请并写入新的 kubelet 证书。这与源码中的引导优先级完全吻合BootstrapKubeletClientConfigpkg/component/worker/utils.go依次检查——若kubelet.conf已存在则直接使用第 1 优先级否则若存在kubelet-bootstrap.conf即我们刚放置的文件则基于它执行bootstrap.LoadClientCert完成证书引导第 2 优先级都没有时才会尝试用 join token 现生成引导文件第 3 优先级。第 7 步清理引导文件与令牌当所有 worker 节点重新上线后可以安全地删除各 worker 节点上的/var/lib/k0s/kubelet-bootstrap.conf——kubelet 此后会使用已引导生成的常规 kubeconfig 与证书即第 3 步删除、现在又重建的kubelet.conf无需等待令牌自然过期可以立即失效它用k0s token list --role worker列出所有 worker 角色的 join token用k0s token invalidate token-id立即注销不再需要的令牌。这样一个全新的 Kubernetes CA 与 SA 密钥对便已覆盖整个集群所有节点都基于新信任根工作且不再残留可用于加入集群的旧令牌。操作要点与常见陷阱务必先备份CA 更换涉及全部控制面信任材料任何一步出错都可能让集群不可用k0s backup见 备份文档是唯一的回滚保障。带--enable-worker的控制器要重启整机仅重启 k0s 服务无法彻底重置 kubelet 及其 Pod容易留下使用旧证书的残留进程。路径按实际数据目录调整本文所有路径均基于默认/var/lib/k0s自定义数据目录时请全局替换。新 CA 不会自动同步到 workerworker 上的 kubelet 证书必须通过 bootstrap 流程重新申请这也是第 6 步放置kubelet-bootstrap.conf并重启的原因。k0s 没有 CA 自动续期CA 到期前必须人工规划轮换窗口相比之下组件证书默认 1 年会在每次启动时由 k0s 自动检查并按需重签。延伸阅读自定义 CA 与预生成加入令牌如果你希望在集群初始化前就准备好 CA例如企业要求使用自管 CA或需要预生成 join token 供批量装机使用k0s 同样支持只需在首次安装前把ca.crt、ca.key、sa.pub、sa.key放到/var/lib/k0s/pkietcd CA 放到pki/etcdk0s 初始化时会直接采用这些现成材料而不是重新生成。具体操作方法、openssl 生成命令示例以及k0s token pre-shared预生成令牌的用法详见 使用自定义 CA 证书安装 k0s。而本文介绍的流程则是面向集群已运行多年、需要换根的场景——两者互为补充构成 k0s 证书管理的完整拼图。赞分享云原生容器编排边缘计算【免费下载链接】k0sk0s - The Zero Friction Kubernetes项目地址https://gitcode.com/gh_mirrors/k0/k0s点击查看免费下载相关推荐k0s 自定义 CA 证书与 SA 密钥对安装指南预置 PKI 与预生成 Join Tokenk0s 自定义 CA 证书与 SA 密钥对安装指南预置 PKI 与预生成 Join Token 导读 k0s 在首次启动时会自动在 data dir /pk云原生容器编排边缘计算Kubernetes CA证书手动轮换指南Kubernetes CA证书手动轮换指南 概述 在Kubernetes集群中证书颁发机构 CA 证书是集群安全的核心组件。本文将详细介绍如何安全地手动轮换K文档教程云原生Kubernetes 手动轮换 CA 证书权威指南Kubernetes 手动轮换 CA 证书权威指南 前言 在 Kubernetes 集群中证书机构 CA 证书是安全通信的基础。随着时间推移出于安全考虑或证文档教程云原生上一篇rpitx快速安装教程10分钟完成树莓派RF发射器部署下一篇Tofu: 一款易用的iOS双因素认证应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考