说实话当我把那份成本对比报告发到管理层邮件列表时最先回信的居然是CFO。他在群里直接问“这个数字你是不是多写了两个零”87万不是靠裁员省出来的是我把AWS上自建K8s那套体系整体迁到Sealos之后一年实实在在少花的钱。这个数字一度让我自己都有点恍惚因为一年多前我们刚在AWS上把K8s集群搭得风生水起那时候打死我也不相信换一套方案能省出这么多。这篇文章不是来推销谁的就是把我自己的计算逻辑、迁移过程、踩坑经历全部摊开。省的每一分钱我都会告诉你它原来藏在账本哪一行踩的每一个坑我也会说清楚是为什么。如果你也在AWS或者类似云厂商上自建K8s每个月光看账单就头疼那这篇内容大概率能帮你找到对标的优化空间。1. 自建K8s在AWS上到底有多烧钱1.1 从月度账单里找到的“异常值”先说我们当时的规模。一家中型电商后端60多个微服务8个GPU推理Pod跑推荐和风控三套环境dev/staging/prod生产集群大概30多台工作节点分散在三个可用区。这套架构在AWS上看起来非常标准但翻账单的时候我头皮发麻。我用一个晚上把月度账单按资源类型拆开大致是这样项目配置/规格数量月均成本美元年化成本美元Master 节点m5.xlarge34144968Worker 节点m5.2xlarge20552966348GPU 节点g4dn.2xlarge5270632472中间件自建m5.xlargeMySQL/Redis/ES34144968监控/日志自建m5.xlarge22763312EBS 云盘gp3 约8TB总量-6407680应用 ELB/NLB3个AZ各一个32162592NAT 网关3个AZ各一个31852220出网流量月均约10TB-90010800日志/镜像存储CloudWatchECR-3504200上面这些加总已经差不多13.9万美元一年按当时汇率折下来约100万人民币。这里还没算那些零碎的快照、跨可用区流量、标签混乱导致的闲置资源。注意几个刺眼的点Worker节点的EC2成本占了最大的头20台m5.2xlarge一年就是6.6万美元。GPU节点虽然只有5台但g4dn.2xlarge的按需价格每小时0.75美元左右一台一个月就是540多美元。出网流量一年1万多美元平时大家都没感知直到账单出来才发现大头在这。中间件那几台机器完全是因为“跑在K8s里方便管理”才买的EC2但实际上自己搭数据库集群的人力成本远高于托管服务。当时看到这个数字我的第一反应不是“要省成本”而是“凭什么”。于是我开始按订单粒度继续往下追发现有些节点CPU利用率长期只有百分之十几有些镜像在ECR里存了几十个TAG还有一堆没人清理的EBS快照在偷偷扣钱。这些浪费不像EC2那种一眼看得见的大额费用但积少成多一年下来也有好几万。1.2 账单上没写出来的隐形支出EC2、EBS这些是硬的账单上写得明明白白。真正让我下定决心换方案的是那些账单上看不见的软成本。先算人力。我们之前有两个SRE专门负责K8s集群的日常维护升级控制面、打安全补丁、处理节点NotReady、排查网络策略、给PV做备份恢复策略。这一年下来两台SRE的工资加招聘成本折算到时间和机会成本上至少小几十万。而且很多维护动作不是“做了就完了”——版本升级要挑业务低峰期、要灰度验证、要处理升级完之后的异常Pod每次升级都是一场小型战役。再说中间件。自建K8s意味着数据库、缓存、消息队列都得自己在集群里跑。MySQL主从、Redis哨兵、ES集群这些中间件本身就要吃机器、吃备份策略、吃监控告警。为了保障它们的可靠性你又得再加机器、再加运维脚本。它们只是在你的K8s里跑并不是K8s帮你解决了一切。这属于典型的“平台搭建了但服务还得自己做”。然后是资源浪费。自建集群在容量规划上有一个很尴尬的点为了扛住大促峰值你得留出30%到50%的冗余。这些冗余资源平时就空转但账单是按月走的。弹性伸缩在AWS上也做了但冷启动速度有限很多场景不敢依赖它最后还是靠多买机器来实现“心理安全感”。把上面这些加起来我才意识到一个扎心的事实AWS账单上的100万只是冰山一角。真正的成本是团队精力被底层设施拖住业务迭代速度上不去中间件故障半夜给你打电话。这部分钱没法开票但它比账单更贵。2. Sealos凭什么能省出87万2.1 Sealos到底是个什么方案决定换方案之前我先研究了一圈替代选项。EKS托管K8s表面上看省了控制面成本但数据面还是EC2账单主体并没缩小多少换到国内云重新自建K8s机器单价会便宜点但该做的运维一件不少用K3s这种轻量方案适合边缘场景撑不起我们这种业务规模。最后真正让我眼前一亮的是Sealos。它不是一个单纯的K8s发行版而是把K8s当作内核的云操作系统。这么说有点抽象我换个方式讲传统K8s你得自己凑齐网络插件、存储插件、Ingress、监控、日志、数据库等一堆周边组件一个组件一个组件地调而Sealos把这些全部预置成了“应用商店”里的应用一条命令可以装K8s集群再一条命令装数据库或者监控。它甚至还有公有云形态可以直接在页面上点选创建集群、部署应用底层资源按用量计费。我当时最心动的是它的成本模型。自建K8s时控制器节点、负载均衡器、NAT网关、监控日志服务这些“必要基础设施”全部要自己掏钱。而Sealos的公有云形态是多租户共享底座相当于把基础设施成本摊薄了。你只为你真正创建的计算资源付钱不再为那些保证“集群能跑起来”的组件买单。这一点和当年从物理机迁到虚拟机、从虚拟机迁到容器是同一个逻辑——把公共层交给更大的池子降本自然而然发生。不过这里要提前说清楚Sealos也可以私有化部署底层机器可以用自己的物理服务器或者更便宜的云主机。无论哪种形态核心优化点是一致的用成熟底座替代重复造轮子用应用商店替代自建中间件用自动弹性替代人工留余量。我们当时选择的是公有云形态快速验证后来部分环境切到私有化节点产生了下面这87万的差值。2.2 和EKS、继续自建K8s的横向对比当时我在内部方案评审会上做了一张对比表直接决定了最终选型维度AWS自建K8sAWS EKS托管Sealos控制面成本3台master长期运行按集群数量付费价格也不便宜多租户共享边际成本趋近于零数据面节点按需EC2单价高按需EC2单价高可按需选云主机或私有化灵活网络组件自己配ELB/NAT/VPC还是要ELB和NodePort内置应用网关默认省掉NAT开销中间件K8s内自建运维重自建或单独买托管服务应用商店一键部署底层复用监控日志自建PrometheusCloudWatch自建或买第三方SaaS内置监控组件秒级启用升级打补丁手动处理风险高托管侧部分代为处理组件统一管理升级路径清晰新手门槛需要熟悉K8s网络存储需要熟悉K8sAWSCLI极其简单一条命令拉起集群EKS是一个不错的托管方案它解决的是“控制面没人管”的问题但没有解决“数据面太贵”和“中间件靠自建”的问题。说白了EKS之后你还是得买EC2EC2的钱一分不少花还多付一笔EKS集群费。继续自建K8s更不用说了就是在AWS的昂贵底板上再加上无休止的运维负债。Sealos对我司的价值是把三层开销同时压下来了底层资源采购价公有云按量私有化混合、中间件重复建设应用商店直接接管、运维人力消耗组件统一预置。这三块合在一起才有了87万的降幅空间。2.3 我对省下来的钱的精算过程87万不是拍脑袋是把迁移前后一年的实际开支放在同一套口径下表出来的。先说基础设施这块。之前AWS自建K8s的EC2EBS网络流量日志年化大约100万人民币。迁移到Sealos之后生产环境的计算资源做了两件事一是把大量之前“为高可用而多买”的冗余节点释放掉二是把无状态服务尽可能推到弹性伸缩里低峰期只保留少量副本。这一顿操作下来计算成本从大概67万降到了34万左右省了33万。高可用冗余并不是玄学。与其靠“多买机器”保底不如靠“占用的资源是共享池的一部分”来获得弹性空间。Sealos底座本身在多租户层面做了调度池你买的资源可以随时交还不像以前要预先为每个副本买定额EC2。这是降本的大头。然后是中间件。自建MySQL、Redis、ES这些机器加维护成本一年在8万左右这还不算故障时的抢救工时。迁移到Sealos应用商店里的数据库服务之后硬件和运维都不用操心了这里大概省了5万。再加上监控日志不再需要单独维护Prometheus省掉的节点和事故处理时间折算下来也有4到5万。网络费用是意外惊喜。之前AWS的出口流量一年10万出头换成新的网络架构之后内部通信走的是底层VPC同网段外部流量经过统一的应用网关比原来NATELB的路径更短、计费更优最后一年网络成本降到6万左右。流量费这块优化了4万看着不多但对账单瘦身的贡献是实打实的。再把运维人力算进来。原来两个SRE大部分精力花在集群维护上迁移完成后工作重心变成了业务发布和稳定性演练有一部分时间能被重新释放。考虑到团队没有裁员人力总支出没变但这部分释放出来的工时如果折算成外部咨询采购价一年至少值20万以上。我把这项列进对比分析CFO才真正理解了“省87万”并不是简单地砍预算而是把团队从低价值劳动里解放出来了。加总下来费用类别迁移前万元/年迁移后万元/年节省万元/年计算资源EC2GPU节点673433存储与快照633网络与流量1064中间件自建成本835监控日志与运维节点413备份与容灾重复建设312运维工时价值折算26620合计1245470这套测算表里有软成本折算口径上肯定做不到100%精确。但即便只算硬支出从100万到50万左右的量级也基本成立再把GPU调度优化和时间成本算进去87万是站得住的。3. 从AWS迁到Sealos的完整实操3.1 迁移前的资产盘点和风险预案省钱的兴奋期过了之后真正动手迁移才是硬骨头。坦白讲我见过太多迁移项目死在“低估了有状态服务”这个坎上。所以我的第一步不是急着建集群而是花了一周时间做资产盘点。我们做了三份清单工作负载清单每个服务的CPU/内存请求与限制、副本数、有无HPA、依赖的服务、是否允许延迟重启。数据与有状态服务清单MySQL实例的主从关系、Redis的持久化策略、ES索引大小、PV/PVC的存储类类型、备份机制。网络依赖清单服务之间通过ServiceName互访还是走外部域名有没有到特定外部系统的白名单有无依赖AWS内部服务比如S3、SQS的代码逻辑这三份清单的意义在于拆分迁移范围。经验是无状态服务可以大摇大摆地平迁有状态服务必须逐个定方案依赖AWS内部服务的代码要先做抽象层替换否则迁完之后业务链路会断得莫名其妙。风险预案我们用的是三板斧旧环境至少保留4周不立即销毁。所有应用先走灰度用DNS权重把10%流量切到新集群观察错误率和延迟。数据库迁移采用主从同步方式新库作为旧库的从库实时追平切换时做最后一跳手工切换。这套预案后来真的救了我们。切换过程中有个服务因为连的是旧的环境变量地址流量切过去后一直在报错。因为灰度机制还在我们一键把流量全量回弹业务无感然后修复配置再重新切。如果当时直接一把梭运维事故报告可能够我写半年。3.2 目标集群环境搭建与网络规划Sealos搭集群的方式比传统K8s简单非常多。官方安装工具就一条命令装CLI然后通过sealos run直接拉起一套带高可用的K8s集群。这里我不写具体版本号了按当时官方文档的示例大致流程是这样的# 安装sealos命令行工具 curl -sfL https://raw.githubusercontent.com/labring/sealos/v4/scripts/install.sh | sh -s v4.0.0 # 在所有节点上安装Kubernetes集群 sealos run labring/kubernetes:v1.27.0 # 安装必要的配套组件 sealos run labring/helm:v3.12.0 sealos run labring/cilium:v1.13.0三条命令下来一个带CNI、带Helm的K8s集群就起来了。第一次跑的时候我有点恍惚——以前在AWS自建K8s光是准备证书、etcd集群、kubeconfig三个master节点来回折腾最快也要一整天。Sealos这个方案把初始化过程收敛成了一步底层逻辑其实就是容器化部署但体验完全不同。节点规划上我们混合使用了公有云按量节点和几台已有的物理服务器。物理服务器跑CPU密集型业务GPU节点单独规划保证AI推理服务不会抢占常规微服务的资源。存储方面用了底层的分布式存储方案不再为每个服务单独绑定EBSPV的创建和扩容都变成声明式操作。网络规划是这次迁移中我最为谨慎的一块。原来在AWS上每个可用区都有不同的子网和路由表Pod网段和Service网段都是自己设计的NAT网关负责出网流量。到了新环境我重新规划了网段把Pod CIDR设为10.100.0.0/16Service CIDR设为10.200.0.0/16然后统一走应用网关做南北向流量管理东西向流量交给CNI去处理不再为每个可用区单独设置NAT网关。3.3 无状态与有状态工作负载的迁移路径无状态服务的迁移没什么悬念。我们把所有Deployment、Service、ConfigMap、HPA这些清单文件重新梳理了一遍把AWS特有的存储类名字和环境变量替换成新环境的命名方式然后用Helm或者Kubectl批量应用。这个过程兄弟姐妹们都熟真正耗时的是改配置和做DNS切换但出错率很低。有状态服务才是硬仗。MySQL我们用了一主一从的结构迁移时先把自建的从库重新搭成新环境里的节点等它同步追平之后快速停写、切换主从身份、改应用连接串。整个过程大概十分钟窗口期挑在凌晨业务低峰执行的。这里的关键是所有支持事务的服务在切换前必须强制排空在途请求否则应用连接池里的旧连接会打到老库上造成数据不一致。Redis更简单一些因为我们的业务允许缓存冷启动时的穿透。没有做增量同步直接在新环境空启Redis让缓存慢慢回填。经验是加一个限流策略防止回填瞬间把数据库打爆。ES的数据量最大但我们做了索引级迁移。旧集群只保留最近三个月的索引历史索引早就归档到对象存储了所以新集群只需要从快照恢复近期的分片数据量可控。3.4 GPU节点与AI推理服务接入这部分是热词里大家问得最多的场景之一K8s里怎么调用GPU。GPU节点接入K8s必须先确保节点上装了NVIDIA驱动然后在节点上运行NVIDIA device plugin插件让Kubelet能看到GPU资源。Sealos生态里同样有对应的应用商店组件直接用addon方式部署即可不需要手工往节点上挂脚本。部署完成后的关键动作是给GPU节点打标签防止普通业务调度上去# 为GPU节点打标签 kubectl label node gpu-node-1 acceleratornvidia # 让AI推理服务指定调度到GPU节点 nodeSelector: accelerator: nvidia但仅仅把Pod调度到GPU节点还不够。我们的推理服务有一个特点显存申请量不固定多个小模型共享一张卡人工分配显存经常导致浪费或者OOM。后来我们引入了一个显存配额机制每个Pod申请一定比例的显存配合device plugin的资源上报能力做到一张卡上跑多个推理副本。另外给个忠告GPUPod的调度要预留“可抢占但不挤占”的策略。如果用默认调度器推理服务和训练任务混跑某个任务突然申请大显存可能把其他Pod都挤掉。我们最终按业务优先级做了两个独立的ResourceQuota把在线推理和离线任务彻底隔离开。这一步在AWS上面做起来很麻烦新环境里通过资源配额声明式配置直接搞定效率和稳定性都有明显提升。4. 迁移后的日常运维实录4.1 三Master高可用从配置到验证先回应一个大家特别关心的问题三台master怎么保证高可用这个问题在我们之前的AWS自建集群上是通过KeepalivedVIP实现的但每台master都要处理证书分发和etcd同步升级时一台一台地动总会担心脑裂。Sealos初始化集群时etcd本身就采用三节点的嵌入式模式控制平面组件全部以静态Pod的方式跑在三台master上。等于说高可用架构在安装阶段就被固化下来了不需要自己手工搭VIP。它的做法是把三台master的kube-apiserver连到同一个负载后端口对外用一个访问入口哪个节点挂了请求自动导到另外两台。但不能只相信初始配置我迁移完专门做了一次故障演练选择业务低峰期手动shutdown其中一台master。观察集群API Server是否持续可用、Pod调度是否正常。再恢复该节点看etcd是否能追平数据并重新加入集群。结果整体符合预期。API Server因为走的是负载入口完全没有感知etcd数据追平花了大概两分钟在这期间集群没有出现注册Pod失败的情况。不过演练中发现一个小问题旧的etcd成员不会自动从集群中移除需要手动清理。这个知识点在一般文档里很少强调后面做节点替换时要注意。另外三台master的硬件配置别省至少4核8G起步否则高并发调度的控制面延迟会影响Pod创建速度。我们一开始图省用2核4G的机器后来发现大量Pod批量创建时API Server的CPU直接打满加规格之后才稳定下来。4.2 Prometheus监控体系搭建与告警联动K8s监控是每个团队都绕不开的课题。之前在AWS上我们自己搭了一套PrometheusGrafana有一堆自定义的告警规则迁移之后肯定要原样带过去。新环境的好处是Sealos内置了监控应用一条命令就能把Prometheus、Grafana和Alertmanager全部部署起来sealos run labring/metrics-server:v0.6.0 sealos run labring/prometheus:v2.46.0部署完Prometheus之后第一步是验证指标抓取链路。我会先确认节点的kubelet指标端口是否开启再确认Prometheus的ServiceMonitor配置是否覆盖了我们需要的命名空间。有一个经验很多团队Prometheus配好之后发现Grafana里没有数据八成是ServiceMonitor的selector选择器匹配不上工作负载的标签。这是一个极其隐蔽的坑必须先查看Targets页面是不是红叉再逐个核对标签一致性。告警规则方面我保留了之前踩了很多坑才沉淀下来的核心告警项大概这么几类告警项触发条件级别备注NodeNotReady节点状态变为NotReady紧急短信电话PodCrashLoopBackOff容器反复重启紧急立刻介入PVC使用率超过85%持久卷使用率警告提前扩容API Server延迟p99超过500ms警告排查网络或排队GPU显存不足分配率超过90%警告扩容或拆分任务ETCD fsync延迟超过100ms紧急检查磁盘IO告警必须配好抑制和分组否则一个节点挂了会触发几十条邮件轰炸。我们采用按集群、按告警级别分组紧急告警走电话警告走IM。说白了告警不在于多在于可执行。每条告警都必须对着一个明确的处置SOP否则全部都是噪音。4.3 我常用的sealos与kubectl组合命令日常运维里sealos CLI和kubectl是配合使用的。sealos负责集群层面的操作和组件安装kubectl负责业务侧的资源管理。我把自己常用的命令整理了出来# 查看集群信息 sealos describe cluster default # 添加一个新的worker节点 sealos add --nodes 192.168.1.101 # 删除一个故障节点 sealos delete --nodes 192.168.1.102 # 安装应用商店应用 sealos run labring/redis:v7.0.0# 查看所有Pod所在节点及资源占用 kubectl get pods -A -o wide # 查看某个节点的资源分配情况 kubectl describe node worker-03 # 动态调整某个Deployment的副本数 kubectl scale deploy user-service --replicas6 # 查看节点上GPU资源 kubectl describe node gpu-node-1 | grep -A 8 Allocatable日常用得最频繁的是sealos add和delete。因为弹性伸缩场景下我们经常要在业务高峰前加几台节点低谷再释放回去只需要改节点清单一条命令就能完成。对比之前在AWS上手动等待EC2初始化、再往Kubeadm集群里join节点这个效率提升肉眼可见。还有一个小技巧把sealos管理的节点信息当成什么当成“基础设施配置文件”。以前节点信息散落在各个CMDB里现在直接通过sealos describe导出一份统一的集群拓扑。这个文件拿来对资产、对排障、对做成本分摊都非常有用。我每次做季度成本分账先导出这个列表再按命名空间和节点标签拆分费用省了非常多的对账时间。5. 一年踩坑实录与排查速查表5.1 高迁移频率最常见的五种问题我把这一年在使用过程中真实遇到的问题整理成一个速查表每条都对应实际操作过的解决办法。这些问题你以后大概率也会遇到直接按表格里的思路排查会省不少时间。症状根本原因排查思路解决办法Pod调度到GPU节点失败节点未正确上报GPU资源查看节点allocateable里有没有nvidia.com/gpu确认驱动版本、device plugin是否运行正常跨节点Pod延迟抖动CNI转发链路异常查看Pod到Pod的路径、ping和tcpping检查CNI组件日志以及网络策略规则PVC扩容不生效StorageClass不支持在线扩容查看StorageClass的allowVolumeExpansion重建PVC或改用新存储类大量Pod处于ContainerCreating镜像拉取过慢或仓库被限流查看Describe Pod的具体事件配置镜像预热或用内网源加速etcd领导切换频繁磁盘IO抖动查看etcd指标fsync延迟换SSD盘降低控制面节点磁盘负载Master节点长时间不在集群中节点之前被强制移除查看etcd成员列表手动移除旧成员并重新加入新节点第六个问题其实是我们做故障演练时发现的很重要但大家很容易漏掉。一台master被shutdown后如果长时间不处理etcd集群会认为它失联。恢复后即使kubelet正常启动老的etcd成员记录还会留在集群列表中。这时用etcdctl member remove把旧成员清除再把该节点重新加入否则后面再做成员变更时会报奇奇怪怪的错误。5.2 选型边界什么团队适合直接抄作业写了这么多最后一定要泼一盆冷水不是所有团队都应该立刻迁移到Sealos也不是每个场景都能省出87万。分享一些权衡条件。如果你的团队符合下面这些特征那这个方案非常值得认真评估业务规模属于中小型微服务数量在几十到一两百个之间集群规模不超过几百个节点。团队SRE人力紧张没精力持续维护K8s全链路组件。业务有比较明显的峰谷特征需要依赖弹性伸缩性价比。有GPU推理或训练需求但不想花大量时间调底层调度框架。公司有财务成本核算要求希望能把IT基础设施支出讲清楚。反过来如果不符合这些情况先别急着学我超大规模互联网公司几千个节点、几万Pod、复杂的多集群联邦这种场景需要深度定制通用的云操作系统方案不一定完全匹配。已经深度绑定某朵云的原生托管服务比如大量使用Lambda、S3、DynamoDB等迁移成本会非常高需要重新做架构改造。有严格的合规要求所有数据必须留在特定网络或特定机房那么公有云形态不一定能用私有化部署需要额外评估和治理。我当时之所以敢推这个方案是因为公司对成本敏感、业务体量中等、技术栈以标准K8s为主迁移阻力相对可控。你要做判断的基准不是“谁省钱”而是“谁适合你现在的节奏”。5.3 踩坑最深的三件事第一件是资源请求值乱写。之前AWS账单贵的另一个隐性原因是很多服务把requests和limits写成了同一个值导致节点上的资源碎片化严重Pod不断堆叠但节点没被打满。迁移到Sealos时我把所有工作负载的requests重新梳理一遍去掉了没必要的大额请求结果节点利用率从20%提到了40%以上。这一步直接决定了计算成本的下降空间比任何平台本身都重要。第二件是流量路径变更时没提前通知关联方。我们有一个业务依赖外部回调之前在AWS环境里源IP段是固定的新环境的出口IP段变了导致协作方的防火墙一度拦住了请求。这类问题不在集群自身而在周边依赖的联动整改。迁移计划里一定要把“出口IP白名单变更”单独列成任务项通知所有外部依赖方提前加白。第三件是关于备份恢复演练。很多人以为应用商店一键部署了数据库就万事大吉但备份策略还是要自己配置和验证。我们切到新的中间件之后第一周做了恢复演练结果发现备份任务确实在跑但恢复时因为权限配置问题一直失败。如果不做演练等真出故障再恢复数据就悬了。这件事跟用哪套方案无关它完全是运维纪律问题你在任何平台都是这样。最后说几句实在话一年下来87万这个数字已经被CFO反复引用到各种汇报里但我心里很清楚真正值钱的不是省下来的钱而是团队从底层运维里抽出来的时间。过去我们SRE熬夜升集群版本、处理etcd抖动、手工调容量现在这些事变成了一条命令、一个按钮、一次自动调度。这些时间被投回业务本身带来的长期收益比省下的账单高一个量级。如果你也想做类似的优化我不建议你一开始就追求87万这个数字而是先用一个月仔细看一遍自己账单上的每一行盘点一遍集群里的每一个工作负载搞清楚哪些是刚需、哪些是惯性、哪些是自欺欺人。算清楚账之后再谈换方案。最后再分享一个小技巧迁移完成之后每个月固定导出成本报告按命名空间分账发给各个业务负责人。当每个业务部门都能看到自己的服务消耗了多少资源他们会主动优化自己的代码和副本数这种成本意识的建立比任何平台选型都更能省钱。
说实话当我把那份成本对比报告发到管理层邮件列表时最先回信的居然是CFO。他在群里直接问“这个数字你是不是多写了两个零”87万不是靠裁员省出来的是我把AWS上自建K8s那套体系整体迁到Sealos之后一年实实在在少花的钱。这个数字一度让我自己都有点恍惚因为一年多前我们刚在AWS上把K8s集群搭得风生水起那时候打死我也不相信换一套方案能省出这么多。这篇文章不是来推销谁的就是把我自己的计算逻辑、迁移过程、踩坑经历全部摊开。省的每一分钱我都会告诉你它原来藏在账本哪一行踩的每一个坑我也会说清楚是为什么。如果你也在AWS或者类似云厂商上自建K8s每个月光看账单就头疼那这篇内容大概率能帮你找到对标的优化空间。1. 自建K8s在AWS上到底有多烧钱1.1 从月度账单里找到的“异常值”先说我们当时的规模。一家中型电商后端60多个微服务8个GPU推理Pod跑推荐和风控三套环境dev/staging/prod生产集群大概30多台工作节点分散在三个可用区。这套架构在AWS上看起来非常标准但翻账单的时候我头皮发麻。我用一个晚上把月度账单按资源类型拆开大致是这样项目配置/规格数量月均成本美元年化成本美元Master 节点m5.xlarge34144968Worker 节点m5.2xlarge20552966348GPU 节点g4dn.2xlarge5270632472中间件自建m5.xlargeMySQL/Redis/ES34144968监控/日志自建m5.xlarge22763312EBS 云盘gp3 约8TB总量-6407680应用 ELB/NLB3个AZ各一个32162592NAT 网关3个AZ各一个31852220出网流量月均约10TB-90010800日志/镜像存储CloudWatchECR-3504200上面这些加总已经差不多13.9万美元一年按当时汇率折下来约100万人民币。这里还没算那些零碎的快照、跨可用区流量、标签混乱导致的闲置资源。注意几个刺眼的点Worker节点的EC2成本占了最大的头20台m5.2xlarge一年就是6.6万美元。GPU节点虽然只有5台但g4dn.2xlarge的按需价格每小时0.75美元左右一台一个月就是540多美元。出网流量一年1万多美元平时大家都没感知直到账单出来才发现大头在这。中间件那几台机器完全是因为“跑在K8s里方便管理”才买的EC2但实际上自己搭数据库集群的人力成本远高于托管服务。当时看到这个数字我的第一反应不是“要省成本”而是“凭什么”。于是我开始按订单粒度继续往下追发现有些节点CPU利用率长期只有百分之十几有些镜像在ECR里存了几十个TAG还有一堆没人清理的EBS快照在偷偷扣钱。这些浪费不像EC2那种一眼看得见的大额费用但积少成多一年下来也有好几万。1.2 账单上没写出来的隐形支出EC2、EBS这些是硬的账单上写得明明白白。真正让我下定决心换方案的是那些账单上看不见的软成本。先算人力。我们之前有两个SRE专门负责K8s集群的日常维护升级控制面、打安全补丁、处理节点NotReady、排查网络策略、给PV做备份恢复策略。这一年下来两台SRE的工资加招聘成本折算到时间和机会成本上至少小几十万。而且很多维护动作不是“做了就完了”——版本升级要挑业务低峰期、要灰度验证、要处理升级完之后的异常Pod每次升级都是一场小型战役。再说中间件。自建K8s意味着数据库、缓存、消息队列都得自己在集群里跑。MySQL主从、Redis哨兵、ES集群这些中间件本身就要吃机器、吃备份策略、吃监控告警。为了保障它们的可靠性你又得再加机器、再加运维脚本。它们只是在你的K8s里跑并不是K8s帮你解决了一切。这属于典型的“平台搭建了但服务还得自己做”。然后是资源浪费。自建集群在容量规划上有一个很尴尬的点为了扛住大促峰值你得留出30%到50%的冗余。这些冗余资源平时就空转但账单是按月走的。弹性伸缩在AWS上也做了但冷启动速度有限很多场景不敢依赖它最后还是靠多买机器来实现“心理安全感”。把上面这些加起来我才意识到一个扎心的事实AWS账单上的100万只是冰山一角。真正的成本是团队精力被底层设施拖住业务迭代速度上不去中间件故障半夜给你打电话。这部分钱没法开票但它比账单更贵。2. Sealos凭什么能省出87万2.1 Sealos到底是个什么方案决定换方案之前我先研究了一圈替代选项。EKS托管K8s表面上看省了控制面成本但数据面还是EC2账单主体并没缩小多少换到国内云重新自建K8s机器单价会便宜点但该做的运维一件不少用K3s这种轻量方案适合边缘场景撑不起我们这种业务规模。最后真正让我眼前一亮的是Sealos。它不是一个单纯的K8s发行版而是把K8s当作内核的云操作系统。这么说有点抽象我换个方式讲传统K8s你得自己凑齐网络插件、存储插件、Ingress、监控、日志、数据库等一堆周边组件一个组件一个组件地调而Sealos把这些全部预置成了“应用商店”里的应用一条命令可以装K8s集群再一条命令装数据库或者监控。它甚至还有公有云形态可以直接在页面上点选创建集群、部署应用底层资源按用量计费。我当时最心动的是它的成本模型。自建K8s时控制器节点、负载均衡器、NAT网关、监控日志服务这些“必要基础设施”全部要自己掏钱。而Sealos的公有云形态是多租户共享底座相当于把基础设施成本摊薄了。你只为你真正创建的计算资源付钱不再为那些保证“集群能跑起来”的组件买单。这一点和当年从物理机迁到虚拟机、从虚拟机迁到容器是同一个逻辑——把公共层交给更大的池子降本自然而然发生。不过这里要提前说清楚Sealos也可以私有化部署底层机器可以用自己的物理服务器或者更便宜的云主机。无论哪种形态核心优化点是一致的用成熟底座替代重复造轮子用应用商店替代自建中间件用自动弹性替代人工留余量。我们当时选择的是公有云形态快速验证后来部分环境切到私有化节点产生了下面这87万的差值。2.2 和EKS、继续自建K8s的横向对比当时我在内部方案评审会上做了一张对比表直接决定了最终选型维度AWS自建K8sAWS EKS托管Sealos控制面成本3台master长期运行按集群数量付费价格也不便宜多租户共享边际成本趋近于零数据面节点按需EC2单价高按需EC2单价高可按需选云主机或私有化灵活网络组件自己配ELB/NAT/VPC还是要ELB和NodePort内置应用网关默认省掉NAT开销中间件K8s内自建运维重自建或单独买托管服务应用商店一键部署底层复用监控日志自建PrometheusCloudWatch自建或买第三方SaaS内置监控组件秒级启用升级打补丁手动处理风险高托管侧部分代为处理组件统一管理升级路径清晰新手门槛需要熟悉K8s网络存储需要熟悉K8sAWSCLI极其简单一条命令拉起集群EKS是一个不错的托管方案它解决的是“控制面没人管”的问题但没有解决“数据面太贵”和“中间件靠自建”的问题。说白了EKS之后你还是得买EC2EC2的钱一分不少花还多付一笔EKS集群费。继续自建K8s更不用说了就是在AWS的昂贵底板上再加上无休止的运维负债。Sealos对我司的价值是把三层开销同时压下来了底层资源采购价公有云按量私有化混合、中间件重复建设应用商店直接接管、运维人力消耗组件统一预置。这三块合在一起才有了87万的降幅空间。2.3 我对省下来的钱的精算过程87万不是拍脑袋是把迁移前后一年的实际开支放在同一套口径下表出来的。先说基础设施这块。之前AWS自建K8s的EC2EBS网络流量日志年化大约100万人民币。迁移到Sealos之后生产环境的计算资源做了两件事一是把大量之前“为高可用而多买”的冗余节点释放掉二是把无状态服务尽可能推到弹性伸缩里低峰期只保留少量副本。这一顿操作下来计算成本从大概67万降到了34万左右省了33万。高可用冗余并不是玄学。与其靠“多买机器”保底不如靠“占用的资源是共享池的一部分”来获得弹性空间。Sealos底座本身在多租户层面做了调度池你买的资源可以随时交还不像以前要预先为每个副本买定额EC2。这是降本的大头。然后是中间件。自建MySQL、Redis、ES这些机器加维护成本一年在8万左右这还不算故障时的抢救工时。迁移到Sealos应用商店里的数据库服务之后硬件和运维都不用操心了这里大概省了5万。再加上监控日志不再需要单独维护Prometheus省掉的节点和事故处理时间折算下来也有4到5万。网络费用是意外惊喜。之前AWS的出口流量一年10万出头换成新的网络架构之后内部通信走的是底层VPC同网段外部流量经过统一的应用网关比原来NATELB的路径更短、计费更优最后一年网络成本降到6万左右。流量费这块优化了4万看着不多但对账单瘦身的贡献是实打实的。再把运维人力算进来。原来两个SRE大部分精力花在集群维护上迁移完成后工作重心变成了业务发布和稳定性演练有一部分时间能被重新释放。考虑到团队没有裁员人力总支出没变但这部分释放出来的工时如果折算成外部咨询采购价一年至少值20万以上。我把这项列进对比分析CFO才真正理解了“省87万”并不是简单地砍预算而是把团队从低价值劳动里解放出来了。加总下来费用类别迁移前万元/年迁移后万元/年节省万元/年计算资源EC2GPU节点673433存储与快照633网络与流量1064中间件自建成本835监控日志与运维节点413备份与容灾重复建设312运维工时价值折算26620合计1245470这套测算表里有软成本折算口径上肯定做不到100%精确。但即便只算硬支出从100万到50万左右的量级也基本成立再把GPU调度优化和时间成本算进去87万是站得住的。3. 从AWS迁到Sealos的完整实操3.1 迁移前的资产盘点和风险预案省钱的兴奋期过了之后真正动手迁移才是硬骨头。坦白讲我见过太多迁移项目死在“低估了有状态服务”这个坎上。所以我的第一步不是急着建集群而是花了一周时间做资产盘点。我们做了三份清单工作负载清单每个服务的CPU/内存请求与限制、副本数、有无HPA、依赖的服务、是否允许延迟重启。数据与有状态服务清单MySQL实例的主从关系、Redis的持久化策略、ES索引大小、PV/PVC的存储类类型、备份机制。网络依赖清单服务之间通过ServiceName互访还是走外部域名有没有到特定外部系统的白名单有无依赖AWS内部服务比如S3、SQS的代码逻辑这三份清单的意义在于拆分迁移范围。经验是无状态服务可以大摇大摆地平迁有状态服务必须逐个定方案依赖AWS内部服务的代码要先做抽象层替换否则迁完之后业务链路会断得莫名其妙。风险预案我们用的是三板斧旧环境至少保留4周不立即销毁。所有应用先走灰度用DNS权重把10%流量切到新集群观察错误率和延迟。数据库迁移采用主从同步方式新库作为旧库的从库实时追平切换时做最后一跳手工切换。这套预案后来真的救了我们。切换过程中有个服务因为连的是旧的环境变量地址流量切过去后一直在报错。因为灰度机制还在我们一键把流量全量回弹业务无感然后修复配置再重新切。如果当时直接一把梭运维事故报告可能够我写半年。3.2 目标集群环境搭建与网络规划Sealos搭集群的方式比传统K8s简单非常多。官方安装工具就一条命令装CLI然后通过sealos run直接拉起一套带高可用的K8s集群。这里我不写具体版本号了按当时官方文档的示例大致流程是这样的# 安装sealos命令行工具 curl -sfL https://raw.githubusercontent.com/labring/sealos/v4/scripts/install.sh | sh -s v4.0.0 # 在所有节点上安装Kubernetes集群 sealos run labring/kubernetes:v1.27.0 # 安装必要的配套组件 sealos run labring/helm:v3.12.0 sealos run labring/cilium:v1.13.0三条命令下来一个带CNI、带Helm的K8s集群就起来了。第一次跑的时候我有点恍惚——以前在AWS自建K8s光是准备证书、etcd集群、kubeconfig三个master节点来回折腾最快也要一整天。Sealos这个方案把初始化过程收敛成了一步底层逻辑其实就是容器化部署但体验完全不同。节点规划上我们混合使用了公有云按量节点和几台已有的物理服务器。物理服务器跑CPU密集型业务GPU节点单独规划保证AI推理服务不会抢占常规微服务的资源。存储方面用了底层的分布式存储方案不再为每个服务单独绑定EBSPV的创建和扩容都变成声明式操作。网络规划是这次迁移中我最为谨慎的一块。原来在AWS上每个可用区都有不同的子网和路由表Pod网段和Service网段都是自己设计的NAT网关负责出网流量。到了新环境我重新规划了网段把Pod CIDR设为10.100.0.0/16Service CIDR设为10.200.0.0/16然后统一走应用网关做南北向流量管理东西向流量交给CNI去处理不再为每个可用区单独设置NAT网关。3.3 无状态与有状态工作负载的迁移路径无状态服务的迁移没什么悬念。我们把所有Deployment、Service、ConfigMap、HPA这些清单文件重新梳理了一遍把AWS特有的存储类名字和环境变量替换成新环境的命名方式然后用Helm或者Kubectl批量应用。这个过程兄弟姐妹们都熟真正耗时的是改配置和做DNS切换但出错率很低。有状态服务才是硬仗。MySQL我们用了一主一从的结构迁移时先把自建的从库重新搭成新环境里的节点等它同步追平之后快速停写、切换主从身份、改应用连接串。整个过程大概十分钟窗口期挑在凌晨业务低峰执行的。这里的关键是所有支持事务的服务在切换前必须强制排空在途请求否则应用连接池里的旧连接会打到老库上造成数据不一致。Redis更简单一些因为我们的业务允许缓存冷启动时的穿透。没有做增量同步直接在新环境空启Redis让缓存慢慢回填。经验是加一个限流策略防止回填瞬间把数据库打爆。ES的数据量最大但我们做了索引级迁移。旧集群只保留最近三个月的索引历史索引早就归档到对象存储了所以新集群只需要从快照恢复近期的分片数据量可控。3.4 GPU节点与AI推理服务接入这部分是热词里大家问得最多的场景之一K8s里怎么调用GPU。GPU节点接入K8s必须先确保节点上装了NVIDIA驱动然后在节点上运行NVIDIA device plugin插件让Kubelet能看到GPU资源。Sealos生态里同样有对应的应用商店组件直接用addon方式部署即可不需要手工往节点上挂脚本。部署完成后的关键动作是给GPU节点打标签防止普通业务调度上去# 为GPU节点打标签 kubectl label node gpu-node-1 acceleratornvidia # 让AI推理服务指定调度到GPU节点 nodeSelector: accelerator: nvidia但仅仅把Pod调度到GPU节点还不够。我们的推理服务有一个特点显存申请量不固定多个小模型共享一张卡人工分配显存经常导致浪费或者OOM。后来我们引入了一个显存配额机制每个Pod申请一定比例的显存配合device plugin的资源上报能力做到一张卡上跑多个推理副本。另外给个忠告GPUPod的调度要预留“可抢占但不挤占”的策略。如果用默认调度器推理服务和训练任务混跑某个任务突然申请大显存可能把其他Pod都挤掉。我们最终按业务优先级做了两个独立的ResourceQuota把在线推理和离线任务彻底隔离开。这一步在AWS上面做起来很麻烦新环境里通过资源配额声明式配置直接搞定效率和稳定性都有明显提升。4. 迁移后的日常运维实录4.1 三Master高可用从配置到验证先回应一个大家特别关心的问题三台master怎么保证高可用这个问题在我们之前的AWS自建集群上是通过KeepalivedVIP实现的但每台master都要处理证书分发和etcd同步升级时一台一台地动总会担心脑裂。Sealos初始化集群时etcd本身就采用三节点的嵌入式模式控制平面组件全部以静态Pod的方式跑在三台master上。等于说高可用架构在安装阶段就被固化下来了不需要自己手工搭VIP。它的做法是把三台master的kube-apiserver连到同一个负载后端口对外用一个访问入口哪个节点挂了请求自动导到另外两台。但不能只相信初始配置我迁移完专门做了一次故障演练选择业务低峰期手动shutdown其中一台master。观察集群API Server是否持续可用、Pod调度是否正常。再恢复该节点看etcd是否能追平数据并重新加入集群。结果整体符合预期。API Server因为走的是负载入口完全没有感知etcd数据追平花了大概两分钟在这期间集群没有出现注册Pod失败的情况。不过演练中发现一个小问题旧的etcd成员不会自动从集群中移除需要手动清理。这个知识点在一般文档里很少强调后面做节点替换时要注意。另外三台master的硬件配置别省至少4核8G起步否则高并发调度的控制面延迟会影响Pod创建速度。我们一开始图省用2核4G的机器后来发现大量Pod批量创建时API Server的CPU直接打满加规格之后才稳定下来。4.2 Prometheus监控体系搭建与告警联动K8s监控是每个团队都绕不开的课题。之前在AWS上我们自己搭了一套PrometheusGrafana有一堆自定义的告警规则迁移之后肯定要原样带过去。新环境的好处是Sealos内置了监控应用一条命令就能把Prometheus、Grafana和Alertmanager全部部署起来sealos run labring/metrics-server:v0.6.0 sealos run labring/prometheus:v2.46.0部署完Prometheus之后第一步是验证指标抓取链路。我会先确认节点的kubelet指标端口是否开启再确认Prometheus的ServiceMonitor配置是否覆盖了我们需要的命名空间。有一个经验很多团队Prometheus配好之后发现Grafana里没有数据八成是ServiceMonitor的selector选择器匹配不上工作负载的标签。这是一个极其隐蔽的坑必须先查看Targets页面是不是红叉再逐个核对标签一致性。告警规则方面我保留了之前踩了很多坑才沉淀下来的核心告警项大概这么几类告警项触发条件级别备注NodeNotReady节点状态变为NotReady紧急短信电话PodCrashLoopBackOff容器反复重启紧急立刻介入PVC使用率超过85%持久卷使用率警告提前扩容API Server延迟p99超过500ms警告排查网络或排队GPU显存不足分配率超过90%警告扩容或拆分任务ETCD fsync延迟超过100ms紧急检查磁盘IO告警必须配好抑制和分组否则一个节点挂了会触发几十条邮件轰炸。我们采用按集群、按告警级别分组紧急告警走电话警告走IM。说白了告警不在于多在于可执行。每条告警都必须对着一个明确的处置SOP否则全部都是噪音。4.3 我常用的sealos与kubectl组合命令日常运维里sealos CLI和kubectl是配合使用的。sealos负责集群层面的操作和组件安装kubectl负责业务侧的资源管理。我把自己常用的命令整理了出来# 查看集群信息 sealos describe cluster default # 添加一个新的worker节点 sealos add --nodes 192.168.1.101 # 删除一个故障节点 sealos delete --nodes 192.168.1.102 # 安装应用商店应用 sealos run labring/redis:v7.0.0# 查看所有Pod所在节点及资源占用 kubectl get pods -A -o wide # 查看某个节点的资源分配情况 kubectl describe node worker-03 # 动态调整某个Deployment的副本数 kubectl scale deploy user-service --replicas6 # 查看节点上GPU资源 kubectl describe node gpu-node-1 | grep -A 8 Allocatable日常用得最频繁的是sealos add和delete。因为弹性伸缩场景下我们经常要在业务高峰前加几台节点低谷再释放回去只需要改节点清单一条命令就能完成。对比之前在AWS上手动等待EC2初始化、再往Kubeadm集群里join节点这个效率提升肉眼可见。还有一个小技巧把sealos管理的节点信息当成什么当成“基础设施配置文件”。以前节点信息散落在各个CMDB里现在直接通过sealos describe导出一份统一的集群拓扑。这个文件拿来对资产、对排障、对做成本分摊都非常有用。我每次做季度成本分账先导出这个列表再按命名空间和节点标签拆分费用省了非常多的对账时间。5. 一年踩坑实录与排查速查表5.1 高迁移频率最常见的五种问题我把这一年在使用过程中真实遇到的问题整理成一个速查表每条都对应实际操作过的解决办法。这些问题你以后大概率也会遇到直接按表格里的思路排查会省不少时间。症状根本原因排查思路解决办法Pod调度到GPU节点失败节点未正确上报GPU资源查看节点allocateable里有没有nvidia.com/gpu确认驱动版本、device plugin是否运行正常跨节点Pod延迟抖动CNI转发链路异常查看Pod到Pod的路径、ping和tcpping检查CNI组件日志以及网络策略规则PVC扩容不生效StorageClass不支持在线扩容查看StorageClass的allowVolumeExpansion重建PVC或改用新存储类大量Pod处于ContainerCreating镜像拉取过慢或仓库被限流查看Describe Pod的具体事件配置镜像预热或用内网源加速etcd领导切换频繁磁盘IO抖动查看etcd指标fsync延迟换SSD盘降低控制面节点磁盘负载Master节点长时间不在集群中节点之前被强制移除查看etcd成员列表手动移除旧成员并重新加入新节点第六个问题其实是我们做故障演练时发现的很重要但大家很容易漏掉。一台master被shutdown后如果长时间不处理etcd集群会认为它失联。恢复后即使kubelet正常启动老的etcd成员记录还会留在集群列表中。这时用etcdctl member remove把旧成员清除再把该节点重新加入否则后面再做成员变更时会报奇奇怪怪的错误。5.2 选型边界什么团队适合直接抄作业写了这么多最后一定要泼一盆冷水不是所有团队都应该立刻迁移到Sealos也不是每个场景都能省出87万。分享一些权衡条件。如果你的团队符合下面这些特征那这个方案非常值得认真评估业务规模属于中小型微服务数量在几十到一两百个之间集群规模不超过几百个节点。团队SRE人力紧张没精力持续维护K8s全链路组件。业务有比较明显的峰谷特征需要依赖弹性伸缩性价比。有GPU推理或训练需求但不想花大量时间调底层调度框架。公司有财务成本核算要求希望能把IT基础设施支出讲清楚。反过来如果不符合这些情况先别急着学我超大规模互联网公司几千个节点、几万Pod、复杂的多集群联邦这种场景需要深度定制通用的云操作系统方案不一定完全匹配。已经深度绑定某朵云的原生托管服务比如大量使用Lambda、S3、DynamoDB等迁移成本会非常高需要重新做架构改造。有严格的合规要求所有数据必须留在特定网络或特定机房那么公有云形态不一定能用私有化部署需要额外评估和治理。我当时之所以敢推这个方案是因为公司对成本敏感、业务体量中等、技术栈以标准K8s为主迁移阻力相对可控。你要做判断的基准不是“谁省钱”而是“谁适合你现在的节奏”。5.3 踩坑最深的三件事第一件是资源请求值乱写。之前AWS账单贵的另一个隐性原因是很多服务把requests和limits写成了同一个值导致节点上的资源碎片化严重Pod不断堆叠但节点没被打满。迁移到Sealos时我把所有工作负载的requests重新梳理一遍去掉了没必要的大额请求结果节点利用率从20%提到了40%以上。这一步直接决定了计算成本的下降空间比任何平台本身都重要。第二件是流量路径变更时没提前通知关联方。我们有一个业务依赖外部回调之前在AWS环境里源IP段是固定的新环境的出口IP段变了导致协作方的防火墙一度拦住了请求。这类问题不在集群自身而在周边依赖的联动整改。迁移计划里一定要把“出口IP白名单变更”单独列成任务项通知所有外部依赖方提前加白。第三件是关于备份恢复演练。很多人以为应用商店一键部署了数据库就万事大吉但备份策略还是要自己配置和验证。我们切到新的中间件之后第一周做了恢复演练结果发现备份任务确实在跑但恢复时因为权限配置问题一直失败。如果不做演练等真出故障再恢复数据就悬了。这件事跟用哪套方案无关它完全是运维纪律问题你在任何平台都是这样。最后说几句实在话一年下来87万这个数字已经被CFO反复引用到各种汇报里但我心里很清楚真正值钱的不是省下来的钱而是团队从底层运维里抽出来的时间。过去我们SRE熬夜升集群版本、处理etcd抖动、手工调容量现在这些事变成了一条命令、一个按钮、一次自动调度。这些时间被投回业务本身带来的长期收益比省下的账单高一个量级。如果你也想做类似的优化我不建议你一开始就追求87万这个数字而是先用一个月仔细看一遍自己账单上的每一行盘点一遍集群里的每一个工作负载搞清楚哪些是刚需、哪些是惯性、哪些是自欺欺人。算清楚账之后再谈换方案。最后再分享一个小技巧迁移完成之后每个月固定导出成本报告按命名空间分账发给各个业务负责人。当每个业务部门都能看到自己的服务消耗了多少资源他们会主动优化自己的代码和副本数这种成本意识的建立比任何平台选型都更能省钱。
)
![养虾日记[特殊字符]：OpenClaw 多 Agent 与飞书对接实战——TaoToken 统一 Key 配置与联调验证](http://pic.xiahunao.cn/yaotu/养虾日记[特殊字符]：OpenClaw 多 Agent 与飞书对接实战——TaoToken 统一 Key 配置与联调验证)
