从零开始构建 Kubernetes

从源代码构建 Kubernetes 适合研究或测试经过修改的组件。生产集群还需要受支持的升级路径、证书轮换、备份恢复、网络、存储、监控和事件处理流程。

对象模型和 API 路径 #

Kubernetes 将集群操作建模为对资源执行 CRUD。每个对象都有 UID、类型、该类型范围内的唯一名称、用于索引选择的标签，以及用于非标识元数据的注释。

资源分组到 API 组中：

• 核心组通过 /api/v1 暴露；
• 命名组通过 /apis/<group>/<version> 暴露。

GET /api、GET /apis 和 /openapi/v3 等发现端点描述集群支持哪些资源。资源列表项公开规范名称、kind、命名空间作用域、动词，以及 pvc 等短名称。

常用动词映射到 HTTP 方法：

• get、list 和 watch 使用 GET；
• create 使用 POST；
• update 使用 PUT；
• patch 使用 PATCH；
• delete 和 deletecollection 使用 DELETE。

对象模型解释了为什么 Service 是由许多 Pod 支持的稳定端点，而 Pod 本身仍然是短暂的，重新创建时会获得新的网络身份。

构建并记录二进制文件 #

使用文档规定的 Go 工具链，从带标签的 Kubernetes 源代码修订版本构建。记录每个二进制文件的源代码提交、工具链版本、构建标志和校验和。使用 make WHAT=... 构建选定命令，或使用发布构建流程；不要将任意二进制文件下载到控制平面主机。

建立控制平面 #

奇数规模的 etcd 法定人数存储 API 状态。使用 TLS 保护对等方和客户端流量，测试快照恢复，并限制直接客户端访问。按依赖顺序启动控制平面：

1. 建立 etcd、证书、服务账户签名密钥和网络可达性。
2. 使用服务证书、etcd 客户端凭据、服务 CIDR、准入配置和审计策略启动 kube-apiserver。
3. 使用独立身份启动 kube-controller-manager 和 kube-scheduler。
4. 仅为初始引导配置管理员 kubeconfig。
5. 安装 CNI 实现，然后加入 kubelet。

kubelet 需要节点身份、API 端点、兼容 CRI 的运行时、CNI 配置以及匹配的 Pod CIDR 假设。服务路由由 kube-proxy 或替代数据平面实现。

控制平面组件的职责各不相同：

• etcd 存储集群状态；
• kube-apiserver 是所有经过身份验证的请求的入口；
• kube-controller-manager 将期望状态协调为实际状态；
• kube-scheduler 为待处理 Pod 选择节点；
• kubelet 使一个节点与 API 服务器保持一致；
• kube-proxy 在每个节点上实现 Service 路由。

保护 API 请求 #

API 服务器接受 HTTPS 请求。请求路径如下：

1. 身份验证：通过客户端证书、服务账户令牌或 OIDC，将请求关联到用户名、UID、组和可选的额外属性；
2. 授权：评估身份、动词、资源、命名空间和名称；
3. 准入：验证或修改请求；
4. 当请求改变集群状态时，将其持久化到 etcd。

除非设计了有意的替代方案，否则启用 Node 和 RBAC 授权。禁用匿名访问，避免静态令牌文件，分离组件身份，并将私钥保存在源代码控制之外。在认为集群可运行之前，验证 /readyz、DNS、Service 路由、资源限制、节点丢失、证书续订和 etcd 恢复。