Kubernetes 已经是很多团队做容器编排的常规选择，但自己搭建和维护集群很费人力。阿里云容器服务 ACK 把控制平面交给平台托管，团队可以把时间花在业务上。这篇文章讲阿里云 K8s 怎么选形态、怎么部署，以及上生产前常见的坑。
怎么选形态
自建集群要自己管控制平面、etcd 备份、版本升级和证书轮转。其中任何一环出错，都可能拖累整个业务。ACK 把控制平面交给平台，你主要管工作节点和应用。
阿里云 K8s 的产品形态大致有三类：
- ACK 托管版：控制平面由阿里云保障高可用，大多数在线业务选它就够用。
- ACK Serverless 版：不用管节点，按 Pod 资源计费。流量忽高忽低或者有批量任务时比较省心。
- ACK 专有版：部署在你自己的专有云环境里，适合合规和隔离要求高的行业。
选之前可以先问三个问题：业务对延迟敏不敏感，流量有没有明显的峰谷，团队有没有能力运维集群。三个答案基本就能定下形态。
网络和节点池要早规划
阿里云 K8s 基于 VPC 网络。Pod 网段和 Service 网段必须与 VPC 网段错开，否则扩容时容易出现地址冲突。比如 VPC 使用 10.0.0.0/8 中的一段，Service 网段设为 172.21.0.0/20，Pod 网段按节点规模预留足够地址。网段一旦定下来再改，代价很大，创建集群前就要想清楚。
节点池也应该早拆。某电商团队在大促前吃过亏：所有业务共用一个节点池，批处理任务把 CPU 占满后，在线接口的响应明显变慢。之后他们拆成在线服务池、离线计算池和系统组件池三个，用污点（Taint）和容忍（Toleration）做调度隔离，问题就解决了。
部署时资源和探针怎么配
以一个 Web 服务为例，核心部署清单如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: order-service
namespace: prod
spec:
replicas: 3
selector:
matchLabels:
app: order-service
template:
metadata:
labels:
app: order-service
spec:
containers:
- name: order-service
resources:
requests:
cpu: "500m"
memory: "512Mi"
limits:
cpu: "1"
memory: "1Gi"
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 30
periodSeconds: 20
这份清单有两点要注意。第一，requests 和 limits 必须写明。没有设置时，调度器无法合理分配资源，节点在内存超卖时容易触发驱逐。第二，就绪探针和存活探针要分开调。就绪探针决定流量能不能接入，存活探针决定容器要不要重启。两者的 initialDelaySeconds 和检测周期应根据应用的启动速度单独设置，不要照抄。
镜像拉取也值得优化。把镜像推送到同地域的容器镜像服务 ACR，并用 VPC 内网地址拉取，扩容时的启动会快不少。某团队把拉取地址从公网切到内网后，单次滚动发布的耗时从约八分钟缩短到两分钟左右。
弹性伸缩和成本
阿里云 K8s 常用两种弹性方式。HPA 根据 CPU、内存或自定义指标调整 Pod 副本数，Cluster Autoscaler 根据待调度的 Pod 增减节点。只用其中一个，链路是不完整的。Pod 扩出来却没有节点可放，或者节点加了而副本没增，都会卡住。
成本上，可以组合使用按量、抢占式和包年包月实例。无状态、可中断的离线任务适合抢占式实例，在线核心服务则保留包年包月的常驻节点作为基线。某数据团队这样组合后，在保证稳定的前提下，计算成本下降了约三成。这个数字来自特定团队的负载，换到你的业务未必一样，建议自己算一遍账。
监控、日志和排障
阿里云 K8s 与云监控、日志服务已经打通。节点和 Pod 的资源指标可以直接在控制台查看，容器标准输出和应用日志可以通过 SLS 采集。建议集群建好就开启这些能力，别等出了问题再补，那时往往已经没有历史数据可查。
排障按下面的顺序走，会快一些：
- 用 kubectl get pod 看状态，重点关注 CrashLoopBackOff、ImagePullBackOff 这类异常标记。
- 用 kubectl describe pod 看事件。调度失败或探针失败的原因，通常直接写在这里。
- 用 kubectl logs 看应用日志。容器刚重启过的话，加上 –previous 参数可以拿到上一次的输出，这一步很容易漏。
- 检查节点资源和网络策略，确认是资源不足，还是安全组拦截了流量。
有个案例很典型。某服务反复重启，日志里没有明显报错。最后发现是存活探针的超时时间设得太短，高峰期 JVM 的 GC 停顿较长，探针被误判为失败。调大 timeoutSeconds 并优化 JVM 参数后，问题消失。探针配置也是代码的一部分，改动同样要经过 review。
安全和版本升级
安全上，有四件事值得先做：
- 用 RAM 角色和 RBAC 做细粒度授权，别让所有人共用管理员凭证。
- 用网络策略限制 Pod 之间能访问的范围。
- 镜像上线前做漏洞扫描。
- 敏感配置放进 Secret 或用 KMS 管理，不要明文写进 ConfigMap。
版本升级也不能拖。K8s 社区每个版本的维护周期有限，长期停在旧版本，安全补丁和兼容性都会出问题。建议先在测试集群验证，再分批滚动到生产环境，回滚方案提前备好。
选形态看业务特征，网络和节点池提前规划，资源和探针配置到位，监控和日志尽早开启。这些环节做扎实，阿里云 K8s 上生产时踩的坑会少很多。
