自己用 kubeadm 装过 K8s 的人，大概都经历过这样一轮：三台机器装容器运行时，配 etcd 集群，处理证书过期，调 kube-proxy 的转发模式，最后发现集群是起来了，但没有任何人敢在上面跑生产业务。
托管 K8s 的价值不在于"帮你少敲几条命令"，而在于把控制面这件最容易出事、又最不产生业务价值的事情接走。阿里云容器服务 Kubernetes 版（ACK）就是这一类产品。这篇文章按实操顺序写：先做三个决定，再按清单建集群，接着把应用跑起来，最后把账单拆开看钱到底花在哪一段。
一、先看清楚：自建和托管差在哪
| 维度 | 自建（kubeadm 起步） | ACK 托管集群 |
|---|---|---|
| 控制面 | 至少 3 台 master，自己装 etcd、apiserver | 阿里云托管，Pro 版为多可用区控制面 |
| 服务保障 | 无 SLA，出问题自己扛 | Pro 版提供带赔付标准的 SLA |
| 版本升级 | 自己处理版本兼容与组件顺序 | 一键升级，组件跟随生命周期维护 |
| 网络 | 自己挑插件并调参 | Terway 或 Flannel 二选一，开通即用 |
| 存储 | 自己写 CSI 对接云盘 | 云盘、NAS、OSS 标准 CSI 直接可用 |
| 账单结构 | 只有 ECS 账单，容易误判成本 | 管理费、节点、网络分开列，成本看得清 |
最后一行值得单独说。自建集群的"省钱"经常是假象：控制面那三台机器照常付钱，运维人力不体现在账单上，但真实存在。托管之后多出一笔明确的集群管理费，反而把成本摆到了台面上。
二、建集群前的三个决定
决定一：选哪种集群形态
| 形态 | 控制面 | 节点 | 集群管理费 | 适用 |
|---|---|---|---|---|
| ACK 托管集群 Pro 版 | 托管、多可用区、按 SLA 赔付 | 自购 ECS 组成节点池 | 0.64 元/小时/集群 | 生产环境、有稳定性要求 |
| ACK 托管集群 基础版 | 托管 | 自购 ECS 组成节点池 | 不收取 | 测试、学习、临时验证 |
| ACK Serverless | 全托管 | 不买节点，Pod 按配置的 vCPU / 内存计费 | Pro 版公测期间免费，基础版不收费（底层 Pod 走 ECI 计费） | 突发流量、低频任务 |
判断标准很简单：要对外承诺可用性、要写进 SLA 的，选 Pro；只是自己练手或者跑个内部工具，基础版就够。Serverless 的边界在"没有稳定负载"——如果你的应用 7×24 常驻并且吃满资源，长期看还是买节点更划算；反过来，一天只跑几个小时的批处理，Serverless 优势明显。
决定二：网络插件选 Terway 还是 Flannel
| 对比项 | Flannel | Terway |
|---|---|---|
| Pod IP 来源 | 从集群的 Pod 网段里切分 | 由 VPC 交换机通过 ENI 直接分配 |
| 与 VPC 内其他资源互通 | 需要额外路由配置 | Pod IP 就是 VPC 内地址，天然可达 |
| IP 容量 | 取决于规划的 Pod 网段大小 | 受交换机可用 IP 数量限制 |
| 网络性能 | 满足一般场景 | 官方称针对阿里云做过优化，性能优于普通方案约 20% |
经验判断：Pod 需要直接访问 RDS、Redis 这类 VPC 内服务，或者对网络性能敏感，选 Terway；只是想先跑通一个 demo，Flannel 配置更简单。选 Terway 时要注意一件事——Pod IP 从交换机里扣，交换机的网段别只留个 /28，几十个 IP 很快就会见底。
决定三：Pod 网段怎么划
这一项是整篇最重要的一条，因为它创建后不可修改。
container_cidr必须是私有网段：10.0.0.0/8、172.16.0.0/12到172.31.0.0/16、192.168.0.0/16及其子网；- 不能与 VPC 自身网段重复，也不能与 VPC 内已有集群用过的网段重复；
- 使用 Flannel 时该字段必填。
建议在 VPC 规划阶段就单独切一段给 Pod 用，比如 VPC 用 10.0.0.0/16、Pod 用 172.20.0.0/16，两边互不侵占。已经规划过 VPC 的读者，可以直接沿用之前的网段划分思路——VPC 主网段同样是建完不能改的，这两个坑本质上是同一个。
三、建集群：按清单勾一遍
控制台上创建集群，配置项集中在几个区块。下面这张表是我认为需要停下来想清楚的项，其余保持默认即可。
| 配置项 | 建议取值 | 理由 |
|---|---|---|
| 地域与可用区 | 与业务 ECS 同地域；节点池跨至少 2 个可用区 | 跨可用区才有真正的容灾能力，同地域内网访问也不走公网 |
| 集群规格 | 生产选 Pro 版（ack.pro.small 起） |
Pro 版才有多可用区控制面与 SLA |
| Kubernetes 版本 | 选次新版本，不选最老版本 | 老版本会先进入停止维护，升级窗口被动 |
| VPC 与交换机 | 为 Pod 单独划交换机 | 避免和业务网段抢 IP |
| 网络插件 | 生产 Terway，测试 Flannel | 见上一节 |
| 节点池 | 至少两个节点池，跨可用区，按需付费起步 | 后续按负载调整实例规格 |
| 系统盘 | ESSD，容量不低于 120 GiB | 镜像层、容器日志、临时文件都在这里 |
| 日志组件 | 开启 | 不装则没有集群审计日志，事后排查无从下手 |
顺带说一个容易被忽略的默认项：集群创建时会自动创建并关联一个负载均衡实例给 API Server 使用。这个实例是必选项，删掉会导致集群不可用，不要在清理资源时顺手删了。
四、连上集群并验证
集群创建完成后，在控制台的「集群信息 → 连接信息」里下载 kubeconfig，覆盖本地的 ~/.kube/config，然后跑四条命令确认状态：
# 1. 确认当前 context 指向新集群
kubectl config get-contexts
# 2. 节点是否都 Ready，版本与可用区是否符合预期
kubectl get nodes -o wide
# 3. 系统组件是否健康
kubectl get pods -n kube-system
# 4. 资源水位（需已安装 metrics 组件）
kubectl top nodes
get nodes 的输出要重点看两件事：状态是不是 Ready，以及可用区是否按预期分布。只有一台节点 Ready，说明另一个可用区的节点池没起来或者实例库存不足。
五、跑起第一个应用
先用一个无状态服务验证调度、网络、镜像拉取三个环节都通：
kubectl create namespace demo
kubectl -n demo create deployment web \
--image=registry.cn-hangzhou.aliyuncs.com/acs/nginx:latest \
--replicas=2
kubectl -n demo expose deployment web --port=80 --target-port=80
kubectl -n demo get deploy,pod -o wide
kubectl -n demo describe pod <pod-name>
两个副本如果落在同一台节点，可以给 Deployment 加一条反亲和规则，让它们分散到不同可用区，这一步在生产环境是必需的。对外提供访问时，内网调试用 kubectl port-forward 就够；要给公网访问，就走 Ingress 加一个 SLB 实例，不要给节点绑公网 IP——节点直接暴露在公网，安全上的风险和收益完全不成比例。
六、账单：钱到底花在哪
ACK 的费用是"集群管理费 + 一堆关联云产品"的组合，逐项拆开：
| 计费项 | 计费口径 | 注意事项 |
|---|---|---|
| 集群管理费 | 仅 Pro 版收取，0.64 元/小时/集群，按整点对齐计费周期 | 集群创建后的第一个计费周期与释放后的最后一个周期不计费；不同地域单价可能不同 |
| ECS 节点 | 按所选实例的计费方式（包年包月 / 按量 / 节省计划） | 托管集群只有 Worker 节点计费，控制面由阿里云承担 |
| API Server 的负载均衡 | 随集群自动创建 | 2024-12 起新建 CLB 不再支持包年包月，并新增实例费 |
| 出网流量 | NAT 网关 + EIP | 拉公网镜像、装依赖、调用外部接口都走这里 |
| 存储 | 云盘、NAS、OSS 按各自规则计费 | PVC 用到多少算多少 |
| 日志与监控 | SLS、Prometheus 按量计费 | 事件中心的 Logstore 在 90 天内免费 |
按一个小团队三节点的场景粗算：Pro 版管理费约 0.64 × 24 × 30 ≈ 460 元/月；三台 4 核 8G 的节点，价格随规格与计费方式浮动，具体以官方页面实时展示为准；再加一个 SLB 和一个 NAT 网关的固定费用与流量费。
这里有个判断值得说：集群管理费在整体账单里通常只占一到两成，真正的大头是节点规格和出网流量。所以优化成本的方向不是纠结那 460 元，而是把节点规格选对、把不需要的副本数减下来、把公网流量尽量改成内网或走 CDN。
七、一份避坑清单
- Pod 网段创建后不可修改，规划时按未来两年的规模预留，别只够现在用。
container_cidr不能与 VPC 网段重叠，重叠会导致创建直接失败或网络异常。- API Server 关联的负载均衡不能删，删了集群就失去控制入口。
- 删除集群不等于删除资源，ECS 节点、SLB、NAT、EIP 要单独清理，否则继续计费。
- 不要给 Worker 节点绑定公网 IP，出网统一走 NAT 网关，入口统一走 Ingress 或 SLB。
- 系统盘别省，镜像层叠加容器日志，小盘节点跑几个月就会触发磁盘压力。
- 选 Terway 时给交换机留足 IP，Pod IP 从交换机扣，网段过小会限制可调度 Pod 数。
- 生产选 Pro 版，多可用区控制面和赔付标准 SLA 是生产与测试的分界线。
- 日志组件要开，否则审计日志缺失，出问题只能靠猜。
- 注意欠费影响：Pro 版欠费后 15 天内集群进入不活跃状态、无法访问 API Server，超过 15 天集群会被删除。
最后
托管 K8s 把控制面这一层交出去了，但它并没有替你决定"节点买多大、网段怎么划、账怎么控"。这三件事仍然需要动手前想清楚，而它们恰好也是用错之后最难改回来的部分。
集群建好、镜像跑通只是第一步。真要上生产，还需要把节点池的自动伸缩、健康检查探针、Ingress 的证书与灰度策略、以及审计日志的留存策略补齐——这些可以按需逐项加，不必一次全上。阿里云容器服务 ACK 的产品页在 这里，节点规格与计费口径以官方页面实时展示为准；节点的实例选型可以参考 云服务器 ECS 的规格说明，按 CPU 与内存比反查更省事。
