手搓 K8s 还是 kubeadm 开箱即用？聊聊企业级部署的真实选择

$MossGlenFalls,VT,USA$

每日语录： You must expect failure as part of your journey of success, failure and success go hand in hand, you cannot have one without the other.

$引言$

面试的时候问到了很多次，但是回答的不是很全面，尽管有时候面试官听着还可以，但是自己知道回答还不够全面，所以我们就深入了解下。

如果文章哪里有问题，还望指出。

最后有相关的学习群，有兴趣可以加入。

$开始$

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 指定负载均衡器，多个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起步，随着业务复杂度提升逐步引入二进制组件。
• 无论选择哪种方式，必须建立完善的可观测性体系与混沌工程验证流程。

企业应根据实际场景动态调整——技术选型的终极目标不是追求“纯粹性”，而是让基础设施成为业务创新的坚实底座。

$结语$

以上就是我们今天的内容，希望可以帮助到大家。

---

$往期回顾$

• 面试官：说说四层和七层代理的本质区别？——从 OSI 模型到千万级集群的拆解指南

• 当面试官让你对比 CNI 插件时，他到底在考察什么？

• K8s 老鸟的配置管理避雷手册

• 镜像漏洞清零计划：Trivy + 自动化修复流水线实战

• 开发运维不再互怼：GitOps 如何终结部署冲突？