企业官网建设流程全解析

Kubernetes 风控服务隔离：不同业务线的风控模型互不干扰

一、同一集群上的资源争抢：支付风控和信贷风控不能做邻居

一个典型的风控平台往往同时支撑多条业务线：支付风控拦截盗刷，信贷风控评估多头借贷，保险风控识别骗保。不同业务线的风控模型差异巨大：支付风控的模型延迟敏感度极高，需要独占 CPU 和 GPU；信贷风控的模型计算密集但离线批处理为主，对延迟不敏感。

如果把这些模型部署在同一个 Kubernetes 集群但未做隔离，会发生什么？支付风控的 Pod 在高峰期抢占 CPU，导致信贷风控的批处理任务超时。更糟糕的是，某个业务线的模型内存泄漏可能触发节点 OOM Killer，连带 kill 了其他业务线的风控服务。一次实际事故是：信贷风控的灰度模型加载了过大的特征表，触发节点 memory cgroup 限制，同一节点上的支付风控 Pod 被驱逐，线上拦截率瞬间下降了 15%。

基础设施不需要漂亮话。多租户环境下的风控服务隔离，不能只依赖"大家自觉规划好资源"。Kubernetes 提供了 Namespace + ResourceQuota + Node Affinity 的组合能力，但把它们用对、用到位，需要系统化的架构设计。

二、节点级隔离：用 NodeSelector 和 Taint/Toleration 把风控模型绑定到专属节点

最彻底的隔离是物理隔离：不同业务线的风控模型跑在不同的节点上。Kubernetes 提供了三种策略来实现。

NodeSelector 是最简单的方式：给节点打上业务标签，在 Deployment 的 Pod 模板中指定 nodeSelector。但它的限制是不支持反亲和——不能表达"确保支付风控的 Pod 不调度到信贷风控的节点"。

更精确的做法是 Taint/Toleration：给支付风控节点打上risk-type=payment:NoSchedule污点，同时为支付风控的 Pod 添加对应的 Toleration。这样即使其他 Pod 被误配了 nodeSelector，也无法调度到支付风控的节点上。

# 支付风控节点：独占 CPU 节点，拒绝其他业务调度 apiVersion: v1 kind: Node metadata: name: payment-risk-node-01 labels: risk.business/type: payment risk.node/group: low-latency spec: taints: - key: risk.business/dedicated value: payment effect: NoSchedule --- # 支付风控 Deployment：显式 Toleration + NodeSelector 双重保障 apiVersion: apps/v1 kind: Deployment metadata: name: payment-risk-engine namespace: ns-payment-risk spec: template: spec: tolerations: - key: risk.business/dedicated value: payment effect: NoSchedule nodeSelector: risk.business/type: payment containers: - name: risk-engine resources: requests: cpu: "4" memory: "8Gi" limits: cpu: "8" memory: "16Gi"

双重保障（Taint + NodeSelector）是第一道防线：即使 NodeSelector 因配置漂移失效，Taint 仍能阻止错误调度。

三、网络策略与流量隔离：风控服务间的东西向流量必须受控

"模型划分在不同节点上"并不等于"服务之间不会互相影响"。如果某个业务线的风控服务出现性能问题，它发起的对外部数据源的高频调用可能耗尽集群内的 Service Mesh Sidecar 资源，间接影响其他业务线。

NetworkPolicy 可以将 Pod 间通信限制在最小必要范围内。支付风控服务只允许访问支付风控的特征存储和数据通道，不能访问信贷风控的任何内部接口。

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: risk-service-isolation namespace: ns-payment-risk spec: podSelector: {} policyTypes: - Ingress - Egress ingress: - from: - namespaceSelector: matchLabels: risk.tenant: payment egress: - to: - podSelector: matchLabels: app: feature-store - namespaceSelector: matchLabels: risk.tenant: payment ports: - port: 6379 protocol: TCP

关键点是 Egress 规则的白名单化：只允许风控服务访问明确声明的目标。如果某条错误配置导致服务尝试访问不该访问的外部地址，NetworkPolicy 会在内核层面直接拦截，不会产生任何网络开销。

四、隔离的代价与边界：什么时候"完全隔离"反而不划算

节点级隔离虽然安全，但带来了资源利用率问题。如果支付风控的节点在凌晨低峰期只有 5% 的使用率，这些闲置资源就被浪费了。按平均 Load 来看，物理隔离的集群利用率通常只有 30-40%。

一种折中方案是混合部署 + 优先级控制：在同一节点上同时运行多个业务线的风控服务，但给关键业务线配置 Guaranteed QoS Class（requests==limits），非关键业务线配置 Burstable。当节点资源紧张时，Kubernetes 会优先驱逐低优先级的 Pod。结合 PriorityClass，可以保证支付风控的 Pod 在资源竞争时不被驱逐。

另一种方案是利用 Vertical Pod Autoscaler (VPA) 动态调整资源限制。VPA 根据历史使用数据推荐合理的 requests 和 limits，避免因为人工评估不准导致的过度配置或配置不足。但要注意 VPA 会触发 Pod 重启，不适合不能接受重启的风控服务——可以只开 recommendation mode，人工确认后再应用变更。

五、总结

Kubernetes 风控服务的多租户隔离本质是"在共享基础设施上建立软墙"。核心要点：

• 物理隔离最安全但成本最高。NodeSelector + Taint/Toleration 绑定专属节点，适用于支付风控等延迟敏感业务。
• NetworkPolicy 是易被忽略的防线。东西向流量的 Egress 白名单化可以堵住 90% 的误配置风险。
• 资源配额是硬约束，优先级是软策略。ResourceQuota 限制单个 Namespace 的资源上限，PriorityClass 决定在资源紧张时谁先被牺牲。
• 利用率与隔离度的权衡需要数据驱动。通过监控每一组节点的实际利用率和业务 SLA 达标情况，动态调整隔离策略。

落地建议：先做 Namespace + ResourceQuota 的命名空间级隔离，再逐步引入节点级隔离和 NetworkPolicy。不要一上来就追求完美，过度隔离既抬高成本又增加运维复杂度。