引言
面试的时候问到了很多次，但是回答的不是很全面，尽管有时候面试官听着还可以，但是自己知道回答还不够全面，所以我们就深入了解下。
如果文章哪里有问题，还望指出。
最后有相关的学习群，有兴趣可以加入。
开始
Kubernetes的部署方式决定了集群的底层架构、可维护性及扩展能力。二进制部署与kubeadm的差异远不止于“手动vs自动”，而是涉及架构设计、生命周期管理、安全模型等多个维度。本文将从技术本质出发，结合企业真实场景，解析两者的核心区别与选型策略。
一、技术本质与核心差异
1. 组件交互与启动流程
二进制部署
• 核心机制：每个Kubernetes组件（如kube-apiserver、kubelet）以独立进程运行，直接通过本地systemd或自定义脚本管理。
• 关键步骤：
1） 证书手动生成：使用cfssl或openssl手动创建CA、服务端/客户端证书，需精确配置SAN（Subject Alternative Name）。
2）组件参数配置：
• kube-apiserver需显式指定--etcd-servers、--service-cluster-ip-range。
• kubelet需配置--kubeconfig、--pod-infra-container-image（如pause容器）。
3）依赖服务部署：
• 独立部署etcd集群（3节点或5节点），配置TLS双向认证。
• 手动安装CNI插件（如Calico的calicoctl与calico-node）。
• 典型问题：
1）证书过期需手动轮换，否则导致集群不可用。
2）组件启动顺序错误（如etcd未就绪时启动kube-apiserver）会引发雪崩故障。
kubeadm部署
• 核心机制：kubeadm通过 Phases（阶段化流程） 自动化完成集群初始化，隐藏底层细节。
• 关键步骤：
1. 证书自动生成：
• kubeadm init自动创建CA及各类证书（有效期1年），存储于/etc/kubernetes/pki。
• 支持kubeadm certs renew自动续期。
2. 组件容器化：
• 控制平面组件（如kube-apiserver）以静态Pod形式运行，由kubelet托管。
• 配置文件统一存储在/etc/kubernetes/manifests。
3. 依赖服务集成：
• 默认使用kubeadm内置的etcd静态Pod（可通过--external-etcd覆盖）。
• 通过kubeadm init --pod-network-cidr自动配置CNI插件（如Flannel）。
• 典型问题：
1）默认证书有效期可能导致生产环境安全隐患。
2）对非标准CNI插件（如Cilium+BGP）支持需手动干预。
2. 高可用架构实现对比
二进制部署
• 负载均衡设计：
API Server高可用：需部署外部负载均衡器（如HAProxy + Keepalived），配置TCP健康检查。
etcd集群：手动部署跨机房的3/5节点集群，配置--initial-cluster参数与TLS证书。
• 故障恢复：
节点故障时需手动替换证书和配置，复杂度高。
支持精细化调优（如etcd的--heartbeat-interval和--election-timeout）。
kubeadm部署
• 高可用模式：
控制平面：通过kubeadm init --control-plane-endpoint <LB_IP>指定负载均衡器，多个Master节点通过kubeadm join加入。
etcd集群：默认使用Stacked etcd（每个Master节点运行etcd Pod），或通过--external-etcd连接独立集群。
• 局限性：
Stacked etcd模式下，网络分区可能导致控制平面与etcd同时不可用。
负载均衡器配置需企业自行维护（如AWS ELB、Nginx Ingress Controller）。
3. 升级与维护差异
二进制部署
• 升级流程：
1）从GitHub下载新版本二进制文件（如kube-apiserver-v1.28.0）。
2）逐个节点替换旧版本，滚动重启组件。
3）验证API兼容性（如kubectl convert检查资源版本）。
• 挑战：
跨大版本升级（如1.24→1.26）需处理废弃API（如PodSecurityPolicy）。
需手动备份etcd数据（etcdctl snapshot save）。
kubeadm部署
• 升级流程：
1）执行kubeadm upgrade plan检查可升级版本。
2）kubeadm upgrade apply v1.28.0更新控制平面。
3）工作节点通过kubeadm upgrade node完成升级。
• 优势：
1）自动处理证书续期与配置文件更新。
2）支持kubeadm reset快速回滚（需配合etcd备份）。
4. 安全模型对比
安全维度 | 二进制部署 | kubeadm部署 |
证书管理 | 手动生成、轮换，可自定义CA根证书 | 自动生成，CA默认存储在Master节点 |
审计日志 | 通过 | 需手动修改静态Pod定义文件以启用审计 |
Secret加密 | 可集成Vault等外部系统 | 依赖Kubernetes原生 |
节点认证 | 灵活选择TLS bootstrap或手动分发kubeconfig | 默认使用TLS bootstrap，通过 |
二、企业选型策略：场景驱动的决策框架
1. 选择二进制部署的典型场景
• 场景1：超大规模集群（>1000节点）
• 需求：极致性能调优，如：
1）修改kube-apiserver的--max-requests-inflight参数应对高并发。
2）调整etcd的--snapshot-count优化写入性能。
• 案例：某头部电商在黑色星期五期间通过二进制部署优化API Server的QPS从5k提升至20k。
• 场景2：混合云/边缘计算
• 需求：异构硬件支持，如：
在ARM边缘节点上编译定制版kubelet以节省资源。
为边缘环境优化kube-proxy的iptables规则生成逻辑。
• 案例：某智慧工厂在边缘网关部署轻量化Kubernetes，二进制包体积减少40%。
• 场景3：强合规与审计要求
• 需求：
使用国密算法（SM2/SM3）替换默认TLS证书。
将审计日志直接写入自研SIEM系统，绕过Kubernetes审计功能。
案例：某金融机构通过二进制部署实现等保三级合规。
2. 选择kubeadm的典型场景
• 场景1：快速原型验证与CI/CD集成
需求：在Pipeline中自动创建测试集群，如：
• 优势：通过Ansible或Terraform封装kubeadm，实现集群即代码（IaC）。
• 场景2：标准化多集群管理
• 需求：统一管理多个云厂商的集群，如：
使用Cluster API在AWS/GCP/Azure批量创建kubeadm集群。
通过Rancher Fleet同步集群配置。
• 案例：某SaaS公司管理200+个kubeadm集群，平均部署时间<10分钟。
• 场景3：有限运维资源的中小团队
• 需求：降低学习曲线，如：
依赖kubeadm upgrade自动化处理版本升级。
使用kubeadm certs renew all简化证书管理。
案例：某初创企业仅1名运维人员管理50节点生产集群。
3. 混合架构：平衡灵活性与效率
• 模式1：核心+边缘分层部署
设计：
核心Master节点：二进制部署，优化etcd与API Server性能。
边缘Worker节点：kubeadm部署，通过kubeadm join批量接入。
优势：核心层保障稳定性，边缘层快速扩展。
• 模式2：渐进式迁移
步骤：
1. 初期使用kubeadm快速上线业务。
2. 随着规模增长，逐步替换关键组件（如将kubeadm的etcd迁移至独立二进制集群）。
3. 最终完全过渡到二进制部署，保留kubeadm作为灾备方案。
三、企业选型的7个关键考量维度
1. 团队技能储备
• 二进制部署要求团队熟悉：
Kubernetes组件通信协议（如API Server的REST API、etcd的gRPC）。
操作系统级调优（如systemd的CPUAccounting和MemoryLimit）。
2. 基础设施规模
• 小规模（<50节点）：kubeadm性价比最高。
• 中大规模（50-500节点）：需评估是否需要定制调度器或网络插件。
• 超大规模（>500节点）：二进制部署几乎成为必选项。
3. 合规与安全要求
• 金融、政务等行业通常需要二进制部署以满足审计颗粒度要求。
4. 生命周期管理
• 频繁集群创建/销毁（如测试环境）优先选择kubeadm。
5. 云生态集成
• 若深度依赖云厂商托管服务（如AWS EKS Anywhere），kubeadm更易集成。
6. 成本模型
• 二进制部署的隐性成本：
人力成本：资深Kubernetes运维工程师薪资通常比普通运维高30%-50%。
时间成本：手动升级一个50节点集群可能需要2人天。
7. 灾备与可恢复性
• 二进制部署需自定义备份方案（如etcd快照+组件二进制版本库）。
• kubeadm可结合Velero实现标准化灾备。
四、实战建议：企业落地步骤
步骤1：明确需求与约束
• 制作检查清单：
步骤2：技术验证（PoC）
• 二进制部署PoC重点：
• 测试跨版本升级（如1.26→1.27）的兼容性。
• 模拟etcd节点故障，验证恢复流程。
• kubeadm PoC重点：
• 验证与CNI插件的兼容性（如Cilium Hubble是否正常）。
• 测试kubeadm upgrade的稳定性。
步骤3：制定标准化流程
• 二进制部署规范：
使用Ansible Role固化组件启动参数。
建立证书轮换日历（如每90天更新一次）。
• kubeadm部署规范：
• 通过kubeadm config文件统一配置模板。
• 集成Arkade或kurl实现离线部署。
步骤4：监控与优化
• 关键监控指标：
二进制部署：关注kube-apiserver的goroutine泄漏、etcd写入延迟。
kubeadm部署：监控kubelet的容器启动延迟、证书过期时间。
• 优化案例：某企业通过二进制部署调优kube-controller-manager的--concurrent-deployment-syncs，将部署回滚时间从5分钟缩短至30秒。
五、总结：没有“最佳方案”，只有“最适方案”
• 二进制部署是“手术刀”，适合需要精细控制的企业，但要求团队具备极强的手术能力。
• kubeadm部署是“瑞士军刀”，开箱即用但难以应对极端场景。
最终建议：
• 从kubeadm起步，随着业务复杂度提升逐步引入二进制组件。
• 无论选择哪种方式，必须建立完善的可观测性体系与混沌工程验证流程。
企业应根据实际场景动态调整——技术选型的终极目标不是追求“纯粹性”，而是让基础设施成为业务创新的坚实底座。
