四、金融级容器平台选型：Kubernetes、OpenShift、Rancher、容器安全考量
容器平台选型，说白了就是给咱们的金融应用选个「家」。这个家得稳当、安全，还得能扛得住监管的检查。我这些年帮几家银行和券商做过选型，踩过不少坑，今天把核心经验摊开来聊聊。
4.1 三大主流平台对比
目前金融圈里，Kubernetes、OpenShift、Rancher 这三家是主力。我个人的习惯是，先看业务场景，再定技术栈。别一上来就追新，稳字当头。
| 维度 | Kubernetes（原生） | OpenShift | Rancher |
|---|---|---|---|
| 开源程度 | 完全开源 | 核心开源，企业版收费 | 开源，企业版收费 |
| 安装复杂度 | 较高，需自行搭建 | 中等，Ansible 自动化 | 低，UI 引导式安装 |
| 安全合规 | 需自行加固 | 内置安全策略（SCC） | 需配置 RBAC + 策略 |
| 多集群管理 | 需第三方工具 | 内置（ACM） | 核心能力，非常强 |
| 金融适用场景 | 自建团队、定制化高 | 大型银行、监管合规严 | 中小金融机构、多云管理 |
我的建议：如果团队有 5 个以上专职运维，选 K8s 原生；如果合规要求极高（比如银保监现场检查），OpenShift 省心；如果团队小但管理多个集群，Rancher 是捷径。
4.2 Kubernetes：金融级落地的关键改造
原生 K8s 在金融场景下，直接拿来用是不行的。我在项目中遇到过几次生产事故，都是因为默认配置太「松」了。
4.2.1 网络策略强制隔离
金融应用讲究「最小权限」。默认的扁平网络，所有 Pod 都能互访，这绝对不行。必须用 NetworkPolicy 做租户隔离。
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: finance-isolate
namespace: prod-bank
spec:
podSelector:
matchLabels:
app: payment
policyTypes:
- Ingress
- Egress
ingress:
- from:
- namespaceSelector:
matchLabels:
tier: frontend
ports:
- protocol: TCP
port: 8080
egress:
- to:
- namespaceSelector:
matchLabels:
tier: database
ports:
- protocol: TCP
port: 3306
避坑指南：我曾经因为没配 Egress 策略，导致支付服务把敏感数据发到了外部测试环境。嗯，从那以后，我要求所有生产 Namespace 必须默认拒绝所有流量，再逐条放行。
4.2.2 资源配额与 LimitRange
金融系统最怕「吵闹邻居」。一个 Pod 把 CPU 吃满，其他业务全挂。必须用 ResourceQuota 和 LimitRange 卡死上限。
apiVersion: v1
kind: ResourceQuota
metadata:
name: payment-quota
namespace: prod-bank
spec:
hard:
requests.cpu: "4"
requests.memory: 8Gi
limits.cpu: "8"
limits.memory: 16Gi
persistentvolumeclaims: "5"
4.3 OpenShift：红帽的金融级「全家桶」
OpenShift 说白了就是 K8s 加上红帽的一堆安全加固。我帮某股份制银行做容器平台时，他们直接指定要用 OpenShift，因为审计好过。
4.3.1 安全上下文约束（SCC）
这是 OpenShift 的杀手锏。默认 Pod 不能以 root 运行，不能挂载宿主机路径。你想想看，这天然就防住了很多提权攻击。
# 查看当前 SCC
oc get scc
# 创建一个受限的 SCC
apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
name: finance-restricted
allowPrivilegedContainer: false
runAsUser:
type: MustRunAsNonRoot
seLinuxContext:
type: MustRunAs
fsGroup:
type: MustRunAs
注意：OpenShift 的 SCC 默认非常严格。我刚开始迁移旧应用时，很多镜像因为用了 root 用户直接启动失败。解决方案是改 Dockerfile，用非 root 用户运行，或者申请自定义 SCC。
4.3.2 内置的 CI/CD 与监控
OpenShift 自带 Jenkins Pipeline 和 Prometheus 监控。对于金融场景，这减少了集成第三方工具的安全风险。我记得有一次，客户要求所有 CI/CD 工具必须通过等保三级，OpenShift 内置的 Pipeline 直接省了我们两周的合规工作。
4.4 Rancher：多集群管理的「瑞士军刀」
Rancher 我最喜欢它的 UI 和集群管理能力。如果你手上有 5 个以上的 K8s 集群（比如开发、测试、预发、生产、灾备），Rancher 能让你少掉不少头发。
4.4.1 统一认证与 RBAC
Rancher 可以对接 LDAP/AD，实现单点登录。我在某券商项目中，用 Rancher 把 3 个环境（测试、UAT、生产）的权限统一管理，运维再也不用记 3 套 kubeconfig 了。
# Rancher 中创建集群角色
apiVersion: management.cattle.io/v3
kind: ClusterRoleTemplateBinding
metadata:
name: finance-admin
roleTemplateName: cluster-admin
userName: "cn=zhangsan,ou=people,dc=bank,dc=com"
4.4.2 应用商店与 Helm 集成
Rancher 的应用商店可以直接部署经过审核的 Helm Chart。对于金融场景，我建议自建私有 Chart 仓库，只允许经过安全扫描的 Chart 上线。
我的经验：Rancher 的监控和告警集成得不错，但默认的告警规则太「吵」了。我一般会关掉 Pod 重启告警，只保留节点不可用、API Server 异常等核心告警。
4.5 容器安全：金融场景的「生命线」
容器安全不是选配，是标配。我见过太多团队只关注编排，忽略了镜像和运行时安全，结果被攻破后追悔莫及。
4.5.1 镜像安全扫描
所有进入生产环境的镜像，必须经过漏洞扫描。我推荐使用 Harbor 作为镜像仓库，它内置了 Clair 或 Trivy 扫描器。
# 使用 Trivy 扫描镜像
trivy image --severity HIGH,CRITICAL registry.bank.com/payment:v1.2.3
# 输出示例
# Total: 3 (HIGH: 2, CRITICAL: 1)
# ┌──────────────┬────────────────┬──────────┬───────────────────┐
# │ Library │ Vulnerability │ Severity │ Installed Version │
# ├──────────────┼────────────────┼──────────┼───────────────────┤
# │ libssl1.1 │ CVE-2023-1234 │ CRITICAL │ 1.1.1k-1 │
# │ openssl │ CVE-2023-5678 │ HIGH │ 1.1.1k-1 │
# └──────────────┴────────────────┴──────────┴───────────────────┘
硬性要求：我建议在 CI 流水线中，一旦发现 CRITICAL 漏洞，直接阻断构建。别想着「先上线再补」，金融系统没有后悔药。
4.5.2 运行时安全：Falco + OPA
镜像安全只是静态的。运行时，容器可能被攻破后执行恶意命令。我推荐用 Falco 做行为监控，OPA 做策略执行。
# Falco 规则：禁止容器内执行 shell
- rule: Terminal shell in container
desc: A shell was spawned in a container
condition: >
spawned_process and container
and shell_procs
and not user_expected_shell
output: >
Shell spawned in container (user=%user.name container_id=%container.id
image=%container.image.repository)
priority: WARNING
tags: [container, shell]
4.5.3 密钥管理：不要硬编码
我见过最离谱的事，有人把数据库密码直接写在 Dockerfile 里。金融场景必须用 Secrets 管理，而且建议用外部密钥服务（如 Vault）。
apiVersion: v1
kind: Secret
metadata:
name: db-credentials
type: Opaque
data:
username: YWRtaW4= # base64 编码
password: cGFzc3dvcmQxMjM=
---
# 使用 Vault 动态密钥
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: vault-database
spec:
provider: vault
parameters:
roleName: "finance-app"
vaultAddress: "https://vault.bank.com:8200"
objects: |
- objectName: "db-password"
secretPath: "secret/data/db/payment"
secretKey: "password"
警告：千万别把 Secret 的 YAML 文件提交到 Git 仓库。我曾经在代码审查时发现有人把生产密钥传到了 GitHub 公开仓库，那场面……嗯，连夜轮换所有密钥。
4.6 选型决策树
说了这么多，到底怎么选？我画了一张图，帮你快速决策。
4.7 我的最终建议
选型没有银弹。我见过用 K8s 原生跑得飞起的城商行，也见过用 OpenShift 还天天出问题的股份制银行。关键看三点：
- 团队能力：别高估自己团队的运维水平。如果连 YAML 都写不利索，别碰原生 K8s。
- 合规压力：如果每年要过等保、银保监现场检查，OpenShift 的审计日志和 SCC 能省很多事。
- 安全底线：不管选哪个平台，镜像扫描、运行时监控、密钥管理这三样必须上。这是金融系统的生命线。
最后说一句：容器平台只是工具，真正的安全在于流程和人的意识。我曾经见过一个团队，用了最贵的商业平台，却把生产密钥贴在办公室白板上……嗯，工具再好，也架不住人犯糊涂。
公众号:蓝海资料掘金营，微信deep3321