第二章 主流PaaS平台对比：Kubernetes、OpenShift、Rancher、阿里云ACK、腾讯云TKE的架构与选型
聊到PaaS平台，很多朋友第一反应就是Kubernetes。没错，K8s确实是事实标准。但实际工作中，你不可能裸用K8s——至少我还没见过哪家公司这么干。大家都会选一个「封装好的K8s」，也就是PaaS平台。
这一章，我就把市面上主流的五个平台掰开揉碎讲清楚。包括它们的架构差异、适用场景，以及我踩过的坑。
2.1 Kubernetes：一切的基础
先聊K8s本身。它不是一个完整的PaaS平台，而是PaaS的「内核」。说白了，K8s只提供了容器编排的基础能力——调度、服务发现、存储编排这些。
但K8s缺什么？缺开发者体验。你想想看，一个开发人员要部署代码，得写一堆YAML，还得理解Pod、Service、Ingress这些概念。这门槛其实挺高的。
K8s的核心架构：
- 控制平面：API Server、Scheduler、Controller Manager、etcd
- 数据平面：kubelet、kube-proxy、容器运行时（Docker/containerd）
- 网络模型：CNI插件（Calico、Flannel、Cilium）
- 存储：CSI插件、PV/PVC体系
我的建议：如果你的团队有足够的K8s运维能力（至少2-3个资深SRE），裸K8s是可以的。否则，选一个封装好的平台更靠谱。
2.2 OpenShift：红帽的企业级K8s
OpenShift是我最早接触的PaaS平台之一。它本质上是「K8s + 一堆红帽自研组件」。我记得2018年第一次部署OpenShift 3.11，那叫一个痛苦——安装就要跑几个小时。
OpenShift的独特之处：
- 内置CI/CD：Source-to-Image（S2I）技术，开发只需提交代码，平台自动构建镜像并部署
- 路由层：用HAProxy做Ingress Controller，比K8s原生的Ingress更成熟
- 安全增强：默认启用SELinux，Pod不能以root运行
- Operator Hub：内置大量红帽认证的Operator
我在项目中遇到过一个问题：OpenShift的默认网络插件是OpenShift SDN，性能不如Calico。后来我们切换到OVN-Kubernetes，才解决了大规模集群的网络瓶颈。
避坑指南：我曾经在OpenShift 4.x上踩过一个坑——升级时etcd版本不兼容，导致集群短暂不可用。建议在生产环境升级前，先在测试集群跑一遍升级流程。
2.3 Rancher：多集群管理利器
Rancher的定位和OpenShift完全不同。它不是一个「重封装」的PaaS，而是一个「多集群管理平台」。你可以用Rancher管理多个K8s集群——不管是自建的、云上的、还是边缘的。
Rancher的架构特点：
- Rancher Server：管理平面，负责认证、RBAC、项目资源配额
- Rancher Agent：部署在每个被管理的集群中，与Server通信
- 应用商店：内置Helm Chart仓库，一键部署常用中间件
- 监控与日志：集成Prometheus和Grafana，开箱即用
我个人习惯用Rancher做开发测试环境的管理。比如我们团队有5个K8s集群——开发、测试、预发、生产、灾备。用Rancher统一管理，省去了来回切换kubeconfig的麻烦。
但Rancher也有短板：它不提供CI/CD能力。你需要自己集成Jenkins、GitLab CI或者ArgoCD。说白了，Rancher只管「跑」，不管「怎么跑上来」。
2.4 阿里云ACK：国内云原生首选
ACK是阿里云托管的K8s服务。它的优势在于和阿里云生态的深度集成。我去年帮一家电商公司做PaaS选型，最终选了ACK，原因很简单——他们大量使用阿里云的RDS、Redis、OSS。
ACK的核心能力：
- 托管控制平面：Master节点由阿里云管理，用户只需关注Worker节点
- 弹性伸缩：支持节点自动伸缩和Pod水平自动伸缩（HPA）
- 网络方案：Terway网络插件，性能优于Flannel
- 存储集成：直接挂载阿里云云盘、NAS、OSS
嗯，这里要注意：ACK的Terway网络插件虽然性能好，但每个Pod会占用一个弹性网卡（ENI）的IP。如果你的集群规模很大（比如上千节点），ENI配额可能不够用。我曾经遇到过这个问题，最后通过申请提高配额才解决。
小技巧：在ACK上部署有状态应用时，建议使用阿里云云盘（SSD）作为存储后端。它的IOPS比普通云盘高3-5倍，对数据库类应用特别友好。
2.5 腾讯云TKE：游戏与社交场景的利器
TKE是腾讯云的K8s服务。它的架构和ACK类似，都是托管控制平面。但TKE在一些特定场景有独特优势——比如游戏、直播、社交。
TKE的特色功能：
- 超级节点：一种Serverless容器能力，Pod直接运行在CVM实例上，无需管理Worker节点
- 应用市场：内置大量腾讯云中间件，如CKafka、TDSQL
- GPU虚拟化：支持GPU共享和隔离，适合AI推理场景
- CLB直通Pod：负载均衡器直接转发到Pod IP，减少网络跳转
我记得有一次帮一个游戏公司做PaaS选型，他们需要处理百万级并发连接。TKE的CLB直通Pod功能正好解决了这个问题——传统方案要经过NodePort转发，延迟高，而CLB直通Pod能降低30%的延迟。
2.6 选型对比表
| 维度 | Kubernetes | OpenShift | Rancher | 阿里云ACK | 腾讯云TKE |
|---|---|---|---|---|---|
| 运维复杂度 | 高 | 中 | 低 | 低 | 低 |
| CI/CD集成 | 需自建 | 内置 | 需自建 | 需自建 | 需自建 |
| 多集群管理 | 需自建 | 有限 | 强 | 有限 | 有限 |
| 安全合规 | 基础 | 强 | 中 | 中 | 中 |
| 云生态集成 | 无 | 弱 | 弱 | 强 | 强 |
| 适合场景 | 有K8s专家团队 | 企业级、金融 | 多集群、边缘 | 阿里云用户 | 腾讯云用户 |
2.7 我的选型建议
说了这么多，到底怎么选？我给出几个实际案例：
- 初创公司（10人以下团队）：选ACK或TKE。托管控制平面，运维成本最低。开发人员只需关注业务代码。
- 中型企业（50-200人团队）：如果团队有K8s基础，选Rancher + 自建K8s。灵活度高，成本可控。
- 大型企业（金融、政府）：选OpenShift。安全合规做得好，有红帽技术支持。
- 多云/混合云场景：选Rancher。它天生就是为多集群管理设计的。
最后说一句：没有完美的平台，只有适合你的平台。选型时不要只看功能列表，要结合团队能力、业务场景、预算来综合判断。我见过太多「为了用K8s而用K8s」的案例，最后运维成本反而比传统架构还高。
下一章，我会讲CI/CD流水线的核心设计原则。包括怎么设计流水线、怎么选工具、怎么保证质量。嗯，到时候我会分享一些我在实际项目中踩过的坑，保证干货满满。