所谓“二进制部署 Kubernetes”，是指管理员自行下载和配置 etcd、kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy 等组件，而不是让 kubeadm 或其他工具完成引导。
它能提供高度控制，但也把证书、配置、升级、回滚和一致性责任全部交给运维团队。生产环境不应把一份旧脚本复制到新服务器上直接执行。
一、先判断是否真的需要手工部署
适合评估二进制部署的场景包括：
1. 需要深入学习组件交互。
2. 有严格的系统集成或定制控制面要求。
3. 团队拥有成熟自动化、测试和长期维护能力。
如果目标只是稳定运行集群，优先评估 kubeadm、Kubespray、Cluster API、kOps 或托管 Kubernetes。手工部署不天然更安全，也不天然性能更好。
二、核心组件与职责
etcd：保存 Kubernetes API 状态，需要奇数成员、稳定低延迟存储、TLS、监控和快照。
kube-apiserver：所有 API 请求入口，负责认证、授权、准入、对象校验，并与 etcd 通信。
kube-controller-manager：运行 Deployment、Node、EndpointSlice、证书等控制循环。
kube-scheduler：为未调度 Pod 选择节点。
kubelet：运行在每个节点，连接容器运行时并维护 Pod 生命周期。
kube-proxy 或替代数据面：实现 Service 流量转发。
CoreDNS：提供集群 DNS。
CNI：提供 Pod 网络；CSI 提供持久化存储集成。
三、生产拓扑设计
高可用控制面通常需要：
1. 多个 API Server 后端。
2. 稳定的控制面负载均衡地址和 DNS。
3. 奇数个 etcd 成员并保持 quorum。
4. 控制面节点跨故障域分布。
5. 工作节点与控制面容量隔离。
6. 独立监控、日志和备份路径。
三个 API Server 并不自动等于高可用。如果它们共用单节点 etcd、单个负载均衡器或同一故障域，系统仍有单点。
四、版本和二进制来源
所有组件必须来自可信发布渠道，并校验 checksum 和签名。应记录：
1. Kubernetes 与 etcd 版本。
2. 下载地址和校验值。
3. 构建架构。
4. 组件启动参数。
5. 配置模板版本。
6. 容器运行时和 CNI/CSI 版本。
不同组件之间要遵守版本偏差策略。不要把多年以前的 kube-apiserver、etcd 和 kubelet 参数直接用于当前版本。
五、PKI 和身份设计
Kubernetes 组件间大量使用双向 TLS。通常需要：
1. Kubernetes CA。
2. etcd CA。
3. front-proxy CA。
4. API Server 服务端证书。
5. API Server 到 kubelet、etcd 的客户端证书。
6. etcd server、peer 和 healthcheck 证书。
7. controller-manager、scheduler、kubelet 和管理员 kubeconfig。
8. ServiceAccount 签名密钥。
证书必须包含正确的 CN、组织、Key Usage 和 SAN。CA 私钥不应长期散落在所有节点；签发流程应最小化接触面、记录审计并支持轮换。
真实私钥、Token 和 kubeconfig 不能写进安装脚本仓库。可以使用受控 PKI、秘密管理系统或离线签发流程。
六、etcd 先行
部署控制面前先建立健康 etcd 集群：
1. 每个成员使用唯一 name、peer URL 和数据目录。
2. peer 和 client 通信启用 TLS。
3. 磁盘满足低延迟要求。
4. 成员数量和初始集群配置一致。
5. 建立 endpoint health、leader、fsync 延迟和空间监控。
6. 定期生成并恢复验证快照。
etcd 数据目录不能放在临时盘，也不能用普通文件复制代替一致性快照。
七、配置 API Server
API Server 需要正确配置：
1. etcd endpoints 与客户端证书。
2. service-cluster-ip-range。
3. client CA 和 TLS 证书。
4. ServiceAccount issuer、签名和验证密钥。
5. kubelet客户端证书。
6. RBAC 授权模式。
7. Admission 插件和审计策略。
8. requestheader/front-proxy 参数。
9. 加密配置和 API Priority and Fairness。
多个 API Server 的关键配置必须一致。负载均衡器要使用可靠健康检查，而不是仅判断 TCP 端口打开。
八、配置 Controller Manager 和 Scheduler
两个组件都应使用独立、最小权限 kubeconfig，并启用 leader election。
Controller Manager 还涉及：
1. cluster-cidr 与 ServiceAccount 密钥。
2. 集群签发 CA 与证书生命周期。
3. Node CIDR、云控制器和路由模式。
Scheduler 需要与目标版本 API 兼容，并根据需要使用独立配置文件管理插件和调度策略。
九、配置节点
每个节点需要：
1. 符合 CRI 的容器运行时。
2. 与运行时匹配的 cgroup 驱动。
3. kubelet配置与节点身份。
4. TLS bootstrap 或受控的节点证书。
5. CNI 二进制和配置。
6. Service 数据面组件。
7. 内核模块、转发和防火墙规则。
8. 时间同步、日志轮转和磁盘监控。
节点证书 CN 必须与 Node 名称一致，并通过 Node Authorizer 和 NodeRestriction 控制权限。
十、安装集群插件
控制面启动后还不是完整集群，至少要规划：
1. CNI 网络和 NetworkPolicy。
2. CoreDNS。
3. kube-proxy 或替代实现。
4. CSI 驱动和 StorageClass。
5. Ingress/Gateway 实现。
6. Metrics、日志、审计和告警。
7. 镜像仓库和凭据管理。
8. Pod 安全、准入策略和运行时防护。
每个插件都有独立版本兼容矩阵，不应把所有 YAML 固定多年不更新。
十一、systemd 与配置管理
二进制组件通常以 systemd 服务运行。Unit 文件需要：
1. 明确的配置文件路径。
2. 合理的 Restart 和 RestartSec。
3. 启动依赖和文件权限。
4. 日志输出与轮转策略。
5. 资源和安全限制。
6. 配置变更后的验证与回滚。
手工 SSH 修改十台机器很容易产生漂移。即使采用二进制部署，也应使用配置管理或声明式自动化，保证每台节点可重复构建。
十二、验收清单
kubectl get --raw='/readyz?verbose'
kubectl get nodes -o wide
kubectl get pods -A
kubectl get events -A \
--sort-by=.metadata.creationTimestamp
继续验证：
1. 创建和删除 Pod。
2. Pod 跨节点通信。
3. Service 与 DNS。
4. NetworkPolicy。
5. PVC 动态供给和挂载。
6. Ingress/Gateway 与 TLS。
7. 节点重启和控制面成员故障。
8. etcd 快照恢复。
9. 证书到期监控与轮换。
10. 逐节点升级和回滚演练。
十三、升级责任
二进制部署没有 kubeadm upgrade 帮你统一生成静态清单。升级时必须按兼容顺序处理 etcd、API Server、Controller Manager、Scheduler、kubectl 和 kubelet，并同步升级 CNI、CSI、Webhook 和 CRD。
每次升级都要保留二进制、配置、证书和数据备份，并在测试环境验证。跳过 minor 版本和同时升级所有节点都是高风险做法。
总结
二进制部署的价值是完全理解并控制 Kubernetes 组件，但它要求成熟的 PKI、自动化、监控、备份、升级和安全能力。真正完成部署的标准不是 kubectl get nodes 显示 Ready，而是集群能经受节点故障、证书轮换、etcd 恢复和滚动升级。
参考资料：
https://kubernetes.io/docs/setup/production-environment/
https://kubernetes.io/docs/setup/production-environment/tools/
https://kubernetes.io/docs/setup/best-practices/certificates/