平安银行 SKE 客户测试需求分析记录

结论

平安银行案例是 SKE 进入客户测试阶段暴露出的生产底座能力清单。该需求发生在约两个月前，当前一线尚未收到完整反馈，同时 SmartX 也在客户侧测试，说明该客户处于竞品并行验证阶段。

从需求内容看，平安银行关注的重点是金融客户容器平台生产化能力：跨 AZ 集群部署、StatefulSet 固定 IP、IPAM、企业级存储接入、节点滚动升级、运维审计、统一观测、南北向流量和网络安全控制。

该案例对 SKE 规划的价值在于，它从金融客户测试侧补充了一个独立证据：SKE 在金融客户面前的竞争焦点包括 K8s 生产底座成熟度、网络/存储生态适配、可运维性和与客户既有平台的对接能力。这与光大银行的 AI 平台底座需求、温医附一医院的医疗核心业务承载需求形成互相印证。

一、来源事实整理

二、原始需求与当前判断

三、模块分析

1. 跨 AZ 集群部署

平安银行提出 controlplaneEndpoint 访问入口改造适配，说明客户测试场景已经进入跨 AZ 高可用与控制面入口稳定性验证。该需求与光大银行提出的单 AZ 高可用、跨 AZ 容灾架构存在关联，但平安银行的要求更聚焦"访问入口可用性"和跨 AZ 集群部署适配。

后续需要明确 SKE 对跨 AZ 控制面、API Server 访问入口、负载均衡、故障切换和证书/域名的支持边界。

2. IPAM/静态 IP

StatefulSet 固定 IP、Pod 重建后 IP 不变、IP Reserve 和跨 AZ 分配 IP，反映客户存在强状态业务、固定访问地址或网络白名单诉求。该需求在金融客户中常见，属于网络模型、IPAM、状态应用、跨 AZ 地址规划和运维稳定性的组合能力。

3. 存储能力

客户关注 LocalPV、iSCSI、FC SAN、NAS/NFS 等多类存储。金融客户测试会把既有企业存储生态适配作为容器平台准入能力。SKE 需要明确哪些存储通过 CSI 导入，哪些纳入产品支持矩阵。

4. 滚动升级

K8s 节点版本滚动升级是生产运维成熟度能力。该能力与光大银行关注的在线升级、漏洞修复、补丁能力属于同一类生产运维诉求。

5. 运维审计

涵盖生命周期 API、可观测性、日志/监控、LB/Ingress 和安全策略，实际是多团队能力集合。金融客户会要求容器平台对接客户既有运维平台、观测平台和安全策略系统。

6. 自研 CNI 导入（废弃）

自研 CNI 导入需求已废弃。后续可支持标准 CNI/IPAM/NetworkPolicy 能力评估，但不承诺导入客户自研 CNI 作为通用产品能力。

四、与其他客户案例的关系

平安银行补充的是金融客户测试现场的细粒度工程需求。与光大银行相比，平安银行更偏 K8s 网络、存储和运维准入；光大银行更偏 AI 平台底座、GPU/NPU 和统一运营。两者共同说明金融客户对 SKE 的期待已经从"能部署容器"推进到"可生产化承载、可对接既有平台、可被审计和运维治理"。

五、建议反馈路径

六、当前判断

平安银行案例应作为 SKE 金融客户生产底座能力证据纳入 AI HCI Planning。它说明金融客户在测试阶段会直接验证跨 AZ、固定 IP、存储 CSI、节点升级、审计、观测和网络安全策略等工程能力。

该案例与光大银行、温医附一医院共同支持一个判断：SKE 后续规划的价值主张应围绕"关键行业核心业务底座"展开，具体能力包括高可用/容灾、网络与存储生态、统一运维观测、权限审计、资源治理和存量平台平滑演进。

关联分析文档

• 光大银行 SKE 重点缺口工作量粗估（SKE TL 对齐版）光大银行 SKE 重点缺口工作量粗估（SKE TL 对齐版）
• 光大银行全量特性工作量粗估（SKE TL 对齐版）
• 温州医科大学附属第一医院 HCI+SKE 项目 PPT 材料整理