公有云托管集群的控制面不能完全免运维，但可大幅降低风险；云厂商接管etcd、apiserver等核心组件的高可用、升级与自愈，用户仍需负责节点os、网络/存储插件、监控链路等。
公有云托管集群的控制面是否真能“免运维”？
不能完全免，但可大幅降低风险。云厂商（如 EKS、GKE、AKS、TKE）确实接管了 etcd、kube-apiserver、kube-controller-manager 等核心组件的高可用部署、证书轮换、版本升级和故障自愈——这些在自建中需人工介入或依赖复杂脚本。
但你仍需对以下部分负责：
-
node节点生命周期：OS 补丁、内核更新、容器运行时（containerd）升级需自行维护 - 网络插件（如
calico、cilium）配置与排障，云厂商不兜底 - 存储插件（如
ebs-csi-driver、csi-qingcloud）的权限策略、性能调优 - 监控告警链路中非云原生组件（如自定义
Prometheusexporter）的稳定性
典型误判是认为“用了 EKS 就不用管 Kubernetes 了”，结果在 calico-node 崩溃导致 Pod 无法通信时手足无措。
自建 kubeadm 集群在哪些场景下反而更可控？
当你的基础设施存在强约束时，自建不是“为了炫技”，而是不得不选。比如：
- 金融/政务类客户要求控制面组件必须部署在国产 ARM 服务器上，且禁止连接公网（
kubeadm init --upload-certs+ 离线镜像包可满足） - 边缘场景需将
control-plane和worker合并在单节点（kubeadm init --control-plane-endpoint+taint控制调度） - 审计要求完整记录所有
kubelet启动参数、etcdWAL 日志路径及加密方式，而托管服务仅提供有限日志导出接口
注意：kubeadm 默认不生成 kubeconfig 给普通用户，需手动执行 kubeadm alpha kubeconfig user 或用 kubectl --kubeconfig 指定；这点常被忽略，导致 CI/CD 流水线连不上集群。
成本差异真正在哪？别只看 hourly rate
托管服务的账单看似透明，但隐性支出容易失控：
- CLB / ALB 实例按规格计费，但若未配置健康检查超时时间，会导致大量 502 错误并触发自动扩容，费用翻倍
- TKE 的“原生节点增值服务费”对 GPU 虚拟机只收 10%，但若用裸金属节点跑 AI 训练，
5%增值费叠加CBS高 IOPS 云盘费用，总成本可能超过自建物理机三年折旧 - 自建集群的 etcd 存储若未定期
etcdctl defrag，半年后写入延迟飙升，运维人力成本远高于托管服务每月多付的几百元管理费
一个 50 节点集群，TKE L50 规格约 0.73 元/小时，但若同时启用日志采集、全链路追踪、WAF 集成等增值模块，实际支出常是标价的 2–3 倍。
混合部署不是折中，而是分层责任切分
真实生产环境极少二选一。更常见的做法是：
- 核心业务用托管集群（EKS），利用其跨 AZ 自愈能力保障 SLA
- CI/CD 构建节点、灰度测试环境用
k3s自建在边缘机房，规避公有云带宽费用 - 敏感数据处理模块通过
ServiceMesh（如 Istio）统一注入 sidecar，屏蔽底层是托管还是自建
关键点在于：API Server 地址、RBAC 权限模型、网络策略（NetworkPolicy）必须保持一致。否则 kubectl config use-context 切换集群时，RoleBinding 可能因 namespace 名称冲突静默失效。
