k8s 托管平台与生产部署

导读
Kubernetes 集群的运维成本集中在控制平面与底层组件的升级、证书轮转、etcd 备份等环节,托管平台将这些负担转移给云厂商,让团队聚焦业务负载的编排与发布。选型的核心矛盾在于控制权与运维成本的权衡,不同规模和合规要求的团队会走向截然不同的方案。本文梳理自建与托管的技术边界,对比国际云、国内云、私有化 PaaS 三类平台的特性差异,并给出从本地集群迁移到生产托管的实操路径。
核心概念
自建集群(如 kubeadm、k3s)要求团队自行部署并维护控制平面的全部组件,包括 kube-apiserver、etcd、controller-manager、scheduler,同时承担证书管理、版本升级、安全补丁的全部责任。托管集群则由云厂商接管控制平面的部署与运维,用户只拥有工作节点(Node)的管理权,按节点数量或控制平面实例时长付费。两者在数据平面(Pod 调度、网络、存储)上的职责边界一致,差异集中在控制平面的归属。
图 1 展示了两类集群在控制平面归属上的根本差异。左侧自建场景中,用户的运维范围覆盖控制平面与工作节点,任何组件故障都需要团队介入排查;右侧托管场景中,云厂商负责控制平面的可用性与版本演进,用户只管理工作节点的扩缩容与镜像分发。这种职责切分直接决定了团队的运维人力配置与故障响应流程。
托管平台的共性能力体现在四个方面。第一是控制平面的高可用托管,云厂商在多可用区部署 apiserver 与 etcd,SLA 通常承诺 99.9% 以上。第二是自动升级,托管平台提供原地升级与蓝绿升级两种策略,用户只需选择升级窗口。第三是集成生态,存储(CSI)、网络(CNI)、监控(如 CloudWatch、Stackdriver)与日志组件开箱即用。第四是按量计费,GKE 按集群管理费加节点资源计费,EKS 按控制平面小时费加 EC2 实例计费,ACK 按节点规格包年包月或按量计费。
图解原理
平台选型没有标准答案,需要结合团队规模、运维能力、合规要求、成本预算四个维度综合判断。团队规模决定了能否养得起专职 SRE,运维能力决定了能否处理 etcd 损坏或证书过期这类深水区故障,合规要求决定了数据能否出境或跨可用区,成本预算决定了控制平面管理费能否接受。
图 2 给出的决策树并非绝对,但能覆盖多数团队的选型路径。当团队缺乏专职 K8s 运维且无强制本地化要求时,托管方案能显著降低故障面;当合规要求强制数据不出境时,私有化 PaaS 是唯一选择;当预算敏感且团队具备深度运维能力时,自建 kubeadm 能拿到最大控制权与最低长期成本。
国际云三家托管平台的差异主要体现在网络模型与生态集成上。
| 维度 | Google GKE | AWS EKS | Azure AKS |
|---|---|---|---|
| 控制平面计费 | 按集群约 0.10 美元/小时 | 按集群约 0.10 美元/小时 | 免费 |
| 网络模型 | VPC-native Alias IP | VPC CNI / Calico | Azure CNI / Kubenet |
| 默认 CNI | VPC-native | Amazon VPC CNI | Azure CNI |
| 升级方式 | 自动或手动,Surge 升级 | 自动或手动,原地升级 | 自动或手动,节点镜像升级 |
| 集成监控 | Cloud Operations | CloudWatch | Azure Monitor |
| 私有镜像仓库 | Artifact Registry | ECR | ACR |
| 典型优势 | 升级最平滑,K8s 原生度最高 | 生态最全,IAM 与 VPC 深度集成 | 与 Azure 资源无缝联动,控制平面免费 |
国内云三家在合规与本地化服务上具有天然优势,特性差异集中在容器网络与 Serverless 节点上。
| 维度 | 阿里云 ACK | 腾讯云 TKE | 华为云 CCE |
|---|---|---|---|
| 网络模型 | Terway / Flannel | Global Router / VPC-CNI | VPC 网络 / Tub 网络 |
| 托管节点池 | 支持,按量或包年包月 | 支持,支持超级节点 | 支持,按需或包周期 |
| Serverless | ACK Serverless ASK | TKE Serverless | CCE Turbo 弹性容器实例 |
| 集成监控 | 阿里云监控 + Prometheus | 云监控 + Prometheus | AOM 应用运维管理 |
| 镜像服务 | ACR | TCR | SWR |
| 典型优势 | 生态最全,与阿里云中间件深度集成 | 与微信及游戏生态联动 | 混合云与边缘场景支持强 |
私有化 PaaS 三家的定位差异明显,分别面向多集群管理、企业级增强、全栈平台三个方向。
| 维度 | Rancher | OpenShift | KubeSphere |
|---|---|---|---|
| 核心定位 | 多集群统一管理 | 企业级 PaaS 增强 | 全栈容器平台 |
| K8s 发行版 | RKE2 / K3s | OKD / OCP | 基于 upstream K8s |
| 商业模式 | 开源 + 商业版 | 开源社区版 + 订阅 | 开源 + 企业版 |
| 内置组件 | 较精简,按需启用 | 内置 CI/CD、镜像仓库、监控 | 内置 DevOps、监控、日志、告警 |
| 多租户 | 项目与命名空间级 | 强隔离,内置 RBAC 与 SCC | 企业空间与项目与 DevOps 工程 |
| 典型场景 | 跨云多集群纳管 | 金融与政企强合规 | 一站式私有云 PaaS |
动手实操
各平台的集群创建命令差异较大,但底层都封装了控制平面部署与节点注册的流程。以下示例覆盖国际云、国内云、私有化三类平台的快速创建路径。
创建 GKE 集群,使用 Autopilot 模式让 Google 全托管节点池:
gcloud container clusters create-auto my-gke-cluster \
--region=asia-east1 \
--network=my-vpc \
--subnetwork=my-subnet创建 EKS 部署,使用 eksctl 工具快速拉起控制平面与受管节点组:
eksctl create cluster \
--name=my-eks-cluster \
--region=ap-northeast-1 \
--node-type=m5.large \
--nodes=3 \
--managed创建 AKS 集群,指定虚拟网络与节点规模,控制平面免费:
az aks create \
--resource-group=my-rg \
--name=my-aks-cluster \
--node-count=3 \
--node-vm-size=Standard_D2s_v3 \
--network-plugin=azure \
--enable-managed-identity创建阿里云 ACK 托管集群,使用阿里云 CLI:
aliyun cs POST /clusters \
--header "Content-Type=application/json" \
--body '{
"name": "my-ack-cluster",
"cluster_type": "ManagedKubernetes",
"region_id": "cn-hangzhou",
"vpcid": "vpc-xxx",
"vswitch_ids": ["vsw-xxx"],
"node_num": 3,
"instance_type": "ecs.g6.large",
"container_cidr": "172.20.0.0/16",
"service_cidr": "172.21.0.0/20"
}'创建腾讯云 TKE 托管集群,使用 tccli:
tccli tke CreateCluster \
--ClusterType MANAGED_CLUSTER \
--ClusterName my-tke-cluster \
--VpcId vpc-xxx \
--ClusterCIDRSettings '{"ClusterCIDR":"10.244.0.0/16","ServiceCIDR":"10.247.0.0/16"}'创建华为云 CCE 集群,使用 hcloud CLI:
hcloud CCE CreateCluster \
--cluster.type VirtualMachine \
--cluster.name my-cce-cluster \
--cluster.flavor cce.s2.large \
--cluster.hostNetwork.vpcId xxx \
--cluster.hostNetwork.subnetId xxx使用 Rancher 创建 RKE2 下游集群,通过自定义资源声明节点池规格:
kubectl apply -f - <<EOF
apiVersion: provisioning.cattle.io/v1
kind: Cluster
metadata:
name: my-rke2-cluster
namespace: fleet-default
spec:
rkeConfig:
machinePools:
- name: pool-1
replicas: 3
kubernetesVersion: v1.28.5+rke2r1
EOF从本地 kubeadm 集群迁移到托管平台,核心步骤是工作负载与数据的迁移。导出当前集群的资源清单:
kubectl get deployments,sts,svc,configmap,secret -n app-ns -o yaml > app-resources.yaml在托管集群中应用资源前,先调整存储类与镜像仓库地址。迁移有状态服务时,使用 Velero 备份并恢复到目标集群:
velero backup create app-backup --include-namespaces app-ns
velero restore create --from-backup app-backup --namespace-mappings app-ns:app-ns常见问题与避坑
托管控制平面的版本与工作节点镜像版本必须匹配,版本偏差超过一个 minor 版本会导致 API 调用异常。升级时先升级控制平面,再分批升级节点池,避免节点 kubelet 版本高于 apiserver。
云厂商托管的 CNI 插件(如 Amazon VPC CNI、Azure CNI)会占用节点主网段的 IP 地址,每个 Pod 直接占用 VPC IP,节点子网 IP 容量会成为扩容瓶颈。规划时按 Pod 密度预留足够的子网 CIDR,避免业务高峰时节点无法拉起。
EKS 与 AKS 的控制平面 endpoint 默认公网暴露,生产集群应配置私有 endpoint 并通过 PrivateLink 或对等连接访问,否则 apiserver 会暴露在公网攻击面下。
OpenShift 默认不允许容器以 root 运行,直接迁移普通 K8s 部署清单会因 SCC 策略被拒。迁移前需调整 SecurityContext 或为命名空间绑定合适的 SCC。
托管集群的 etcd 由云厂商管理,用户无法直接 kubectl exec 进入 etcd 容器,需要通过云厂商提供的备份接口或 Velero 间接完成数据备份。建议在迁移前验证备份恢复链路的完整性。
小结与进阶
托管平台用控制平面管理费换取运维人力的释放,选型的关键在于合规边界与团队运维深度的匹配。下一篇将聚焦 GitOps 与持续交付,探讨如何在托管集群上构建声明式的应用发布流水线。