引言
面试的时候问到了许多次，但是回答的不是很全面，尽管有时候面试官听着还可以，但是自己知道回答还不够全面，所以我们就深入了解下。
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）。
典型问题：
- 证书过期需手动轮换，否则导致集群不可用。
- 组件启动顺序错误（如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）。
典型问题：
- 默认证书有效期可能导致生产环境安全隐患。
- 对非标准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完成升级。
- 优势：
自动处理证书续期与配置文件更新。
支持kubeadm reset快速回滚（需配合etcd备份）。
4、安全模型对比
|
安全维度 |
二进制部署 |
kubeadm部署 |
|
证书管理 |
手动生成、轮换，可自定义CA根证书 |
自动生成，CA默认存储在Master节点 |
|
审计日志 |
通过–audit-policy-file自定义策略 |
需手动修改静态Pod定义文件以启用审计 |
|
Secret加密 |
可集成Vault等外部系统 |
依赖Kubernetes原生kms-provider |
|
节点认证 |
灵活选择TLS bootstrap或手动分发kubeconfig |
默认使用TLS bootstrap，通过kubeadm token管理 |
二、企业选型策略：场景驱动的决策框架
1、选择二进制部署的典型场景
场景1：超大规模集群（>1000节点）
- 需求：极致性能调优，如：
修改kube-apiserver的–max-requests-inflight参数应对高并发。
调整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中自动创建测试集群，如：
kubeadm init --config=kubeadm-config.yaml &&
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml- 优势：通过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：明确需求与约束
制作检查清单：
[ ] 是否需要定制Kubernetes组件？
[ ] 集群规模预期增长曲线如何？
[ ] 团队是否有能力维护证书轮换？
[ ] 是否需通过等保/PCI-DSS认证？ 步骤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起步，随着业务复杂度提升逐步引入二进制组件。
无论选择哪种方式，必须建立完善的可观测性体系与混沌工程验证流程。
企业应根据实际场景动态调整——技术选型的终极目标不是追求“纯粹性”，而是让基础设施成为业务创新的坚实底座。
作者丨Jacob
来源丨公众号：云原生运维圈（ID：cloudnativeopscircle）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
暂无评论内容