什么时候需要 Kubernetes

先问哪些运行问题，再讨论Kubernetes？

把“需要集群”换成可以检查的业务条件。企业是否需要跨节点运行，是否有多个独立发布的应用，节点维护时希望哪些业务继续工作，谁负责网络、存储和证书。若这些问题还没有明确答案，先把现有部署、备份与恢复做清楚，比直接引入新的平台更容易建立可管理的运行边界。

Kubernetes可以组织容器工作负载，但应用业务是否正确仍由自身设计和运行检查决定。Kubernetes 编排方案基于源码定制（¥900 / 人天），需求确认后给固定总价。当前交付资料范围仍为：现有服务器发行目录针对内网或 VPN 体验部署，包含单入口网关与后端、PC、数据库和对象存储配置；正式生产需单独沟通。

单体应用能否运行在集群上？

应用架构与运行平台是两个维度。一个单体可以作为容器运行，微服务也可以先使用较简单的容器组织方式。是否运行多个副本，要继续检查会话、任务、上传文件和写入行为；不能只因为镜像能够启动，就将副本数量调大并宣布高可用完成。

BoolMall现有单体装配情况为：当前单体在 单体应用 中装配 UMS、PMS、OMS、CMS；四域保留各自迁移与公开类型，共享单体数据源和本地事务管理器。 多副本运行分别验证会话、任务与写入协调。沟通时逐条寻找运行状态的归属：保存在进程里的内容怎样处理，哪些操作必须统一执行，业务竞争能否被数据库规则正确约束。没有证据的部分列为改造或验证任务。

团队需要具备哪些运维条件？

条件	已准备时应有的资料	尚未准备时的处理
集群归属	维护岗位、升级安排、权限与入口	先确定平台维护责任，不让应用团队临时承包全部运维
网络和域名	服务访问、外部入口、证书及回调规则	在隔离环境逐段验证访问链
持久存储	存储类型、故障影响、快照与恢复方法	区分应用副本与数据副本，补恢复方案
配置与秘密	分发方式、访问权限、轮换和留痕	不将开发环境秘密复制进公开配置
日志与指标	收集范围、保留规则、告警岗位	补业务定位能力，避免只有容器事件
发布与恢复	产物记录、发布批准、数据兼容检查	先建立可回退的程序与结构变更流程

如果企业已有平台团队，商城可以依照现有平台规范接入，而不重新建设重复设施。如果企业没有这类团队，则需要估算平台日常维护、升级与故障定位的工作，并与应用实施分开列范围。平台有人负责只是前提，业务验收仍需要商城与渠道团队参与。

编排平台能自动处理数据库故障吗？

应用进程被重新调度，不等于数据库和对象存储已经恢复。持久数据可能由企业托管服务提供，也可能需要单独设计存储与恢复。数据库复制、结构迁移、备份和跨节点访问都有独立的配置与限制，不能用应用容器的健康状态代表数据完整性。

恢复时还要核对保护资料与应用版本，确保程序能够读取原有密文和业务状态。节点故障后如果应用重新启动，但所需文件仍只存在原节点，本质问题并未解决。测试应包含节点变化后的合法读取、私有附件访问和关键业务查询，而不只是查看新容器出现在列表中。

根据Kubernetes官方概述（核对日期2026-10-03），应用构建、数据库以及日志和监控方案并不是由平台统一替客户包办。

健康探测怎样避免错误重启？

探测要明确测量对象：进程是否仍有响应、当前实例是否能接收请求、启动是否已经完成。把外部渠道短暂超时直接当作进程死亡，可能让平台反复重启健康的应用，加重业务中断。需要根据接口行为和依赖关系设计探测，确定失败后应该停止接流量还是重启。

网关和应用健康的边界可以从交付技术说明进一步核对。应用配置公开 health 与 info 端点并关闭健康详情展示；网关健康不能代替后端和业务链路检查。 对关键交易另设业务观察，检查订单与付款是否能被解释。健康探测路径的网络与授权范围也要审查，不能为方便平台探测而公开所有运行详情。

多副本上线之前应验证哪些竞争行为？

检查并发提交、重复回调、后台任务和补偿动作，确认同一业务结果不会因为请求落到不同副本而重复执行。测试资料要带可追踪业务编号，分别观察应用与数据库结果；仅看返回码无法判断是否重复付款、发放或状态推进。库存与财务的权威来源仍应清楚。

若某个后台任务依赖单实例假设，应先决定协调机制、执行归属和故障恢复，再讨论扩容。不要把定时任务关闭在某些副本里当作没有记录的临时惯例；升级和节点变化后这种惯例容易失效。配置、程序和运维说明要能够共同解释当前执行位置。

平台发布回退和业务回退有什么区别？

平台能够重新运行旧程序，不代表数据库结构、外部请求和新版本写入的数据一并恢复。发布前须检查新旧接口与结构兼容，约定后台任务和消费者链路的切换方法。跨系统已经产生的业务影响可能需要对账和补救，不能用镜像回退代替这些处理。

保持发行材料不可变，发布记录绑定确切产物与配置版本。验证失败后先保留日志和业务编号，再由负责人按计划暂停或恢复。若数据库结构存在不可逆变化，应在上线窗口前明确恢复和前进修复条件，而不是让运行人员在故障现场猜测旧程序是否可用。

什么时候继续使用更简单的部署方式？

业务和团队边界清楚、节点与发布频率有限、已有恢复方式能够满足实际要求时，可以先采用较简单的部署组织方式。这样仍须做好镜像校验、持久资料、秘密管理和业务检查；“简单”不意味着跳过安全和验收。有关方法见Compose检查点。

如果主要难题是业务规则、接口质量或历史资料，增加运行平台不能直接解决它们。先比较问题的原因和改造收益，再决定是否扩展平台范围。采购团队也应把人员、升级和支持责任计入整体方案，避免只比较程序服务器数量而忽略长期维护。

怎样形成可以评审的选择结论？

结论应列出当前问题、目标运行能力、平台前提、应用改造、数据恢复、验证场景和负责岗位。每项说明证据或假设，并标出不采用集群时的风险与替代处理。若采用集群，先在隔离环境验证关键路径，再确定发布和运行安排；没有实测结果时写“尚未验证”，不填写虚构的可用性或扩容效果。

使用商城选型对比表整理比较，结合技术体检服务核对应用状态，再回到私有化部署专题串联环境、入口与业务验收。选择平台的目的在于解决明确的运行问题，结论应能由客户团队长期维护和复查。