Kubernetes——kubelet 配置 TLS 客户端证书启动引导流程

TLS 启动引导

　　在一个 Kubernetes 集群中，工作节点上的组件（kubelet 和 kube-proxy）需要与 Kubernetes 主控组件通信，尤其是 kube-apiserver。 为了确保通信本身是私密的、不被干扰，并且确保集群的每个组件都在与另一个 可信的组件通信，我们强烈建议使用节点上的客户端 TLS 证书。

　　启动引导这些组件的正常过程，尤其是需要证书来与 kube-apiserver 安全通信的 工作节点，可能会是一个具有挑战性的过程，因为这一过程通常不受 Kubernetes 控制， 需要不少额外工作。 这也使得初始化或者扩缩一个集群的操作变得具有挑战性。

　　为了简化这一过程，从 1.4 版本开始，Kubernetes 引入了一个证书请求和签名 API 以便简化此过程。该提案可在 这里看到。

　　本文档描述节点初始化的过程，如何为 kubelet 配置 TLS 客户端证书启动引导， 以及其背后的工作原理。

初始化过程 

当工作节点启动时，kubelet 执行以下操作：

1. 寻找自己的 kubeconfig 文件
2. 检索 API 服务器的 URL 和凭据，通常是来自 kubeconfig 文件中的 TLS 密钥和已签名证书
3. 尝试使用这些凭据来与 API 服务器通信

假定 kube-apiserver 成功地认证了 kubelet 的凭据数据，它会将 kubelet 视为 一个合法的节点并开始将 Pods 分派给该节点。

注意，签名的过程依赖于：

• kubeconfig 中包含密钥和本地主机的证书
• 证书被 kube-apiserver 所信任的一个证书机构（CA）所签名

负责部署和管理集群的人有以下责任：

1. 创建 CA 密钥和证书
2. 将 CA 证书发布到 kube-apiserver 运行所在的主控节点上
3. 为每个 kubelet 创建密钥和证书；强烈建议为每个 kubelet 使用独一无二的、 CN 取值与众不同的密钥和证书
4. 使用 CA 密钥对 kubelet 证书签名
5. 将 kubelet 密钥和签名的证书发布到 kubelet 运行所在的特定节点上

本文中描述的 TLS 启动引导过程有意简化甚至完全自动化上述过程，尤其是 第三步之后的操作，因为这些步骤是初始化或者扩缩集群时最常见的操作。

启动引导初始化 

在启动引导初始化过程中，会发生以下事情：

1. kubelet 启动
2. kubelet 看到自己 没有 对应的 kubeconfig 文件
3. kubelet 搜索并发现 bootstrap-kubeconfig 文件
4. kubelet 读取该启动引导文件，从中获得 API 服务器的 URL 和用途有限的 一个“令牌（Token）”
5. kubelet 建立与 API 服务器的连接，使用上述令牌执行身份认证
6. kubelet 现在拥有受限制的凭据来创建和取回证书签名请求（CSR）
7. kubelet 为自己创建一个 CSR，并将其 signerName 设置为 kubernetes.io/kube-apiserver-client-kubelet
8. CSR 被以如下两种方式之一批复：

• 如果配置了，kube-controller-manager 会自动批复该 CSR
• 如果配置了，一个外部进程，或者是人，使用 Kubernetes API 或者使用 kubectl 来批复该 CSR

1. kubelet 所需要的证书被创建

1. 证书被发放给 kubelet
2. kubelet 取回该证书
3. kubelet 创建一个合适的 kubeconfig，其中包含密钥和已签名的证书
4. kubelet 开始正常操作
5. 可选地，如果配置了，kubelet 在证书接近于过期时自动请求更新证书
6. 更新的证书被批复并发放；取决于配置，这一过程可能是自动的或者手动完成

本文的其余部分描述配置 TLS 启动引导的必要步骤及其局限性。