企业官网建设流程全解析

• 人工智能
• 大模型
• MLOps
• LLMOps
• 模型推理服务
• 云原生
• 后端

本指南以仓库samples/k8s-clusterwide-ssl-demo.md及配套 Notebook（samples/k8s-clusterwide-ssl-demo.ipynb）为主体，完整演示如何在 Kind 集群上以Clusterwide（集群级）模式部署 Seldon Core v2：将控制面安装在seldon-mesh命名空间，而 Runtime 与模型 Server 分布在多个业务命名空间（ns1、ns2），并同时开启控制面（Control Plane）与数据面（Envoy Data Plane）的 TLS/SSL 加密。读完本文，你将掌握：Helm Chart 的安装顺序与--set controller.clusterwide=true的语义、seldon-core-v2-certs证书体系与各 Secret 的用途、TLS 配置文件逐段含义、seldon config系列命令为 CLI 配置 TLS 的方式，以及跨命名空间发起加密推理请求与整体环境清理的完整流程。

一、演示场景概述

Seldon Core v2 的控制面组件（scheduler、modelgateway、pipelinegateway、dataflow、envoy 等）由seldon-core-v2-setupChart 安装，而每个业务命名空间各自持有seldon-core-v2-runtime（运行时组件）与seldon-core-v2-servers（模型 Server：mlserver 与 triton）。默认情况下 controller 只监听安装它的命名空间；通过--set controller.clusterwide=true安装时，controller 会获得 ClusterRole 级别的权限，可跨命名空间管理mlops.seldon.io组下的Model、Pipeline、Server等资源（参见 k8s/helm-charts/seldon-core-v2-setup/templates/_components-deployments.tpl，其中--clusterwide=$(CLUSTERWIDE)参数与seldon-v2-manager-roleClusterRole 的创建均由该开关控制）。

与不带 TLS 的普通多命名空间示例（见 docs-gb/examples/k8s-clusterwide.md）相比，本演示的核心差异在于：安装控制面时额外传入values-tls-dataplane-controlplane-example.yaml，把controlplane 与 envoy 两个安全通道的 protocol 都切到 SSL，并在每个业务命名空间单独安装一套证书。最终效果是：控制面组件间走 mTLS，Envoy 到上游模型 Server 走 mTLS，而外部客户端到 Envoy 的推理入口走单向 TLS（客户端不要求提供证书）。

二、环境准备：创建 Kind 集群与生态组件

演示在 Kind 本地集群上进行，使用仓库ansible目录下的 Playbook 一键创建：

cd ansible && ansible-playbook playbooks/kind-cluster.yaml

ansible/playbooks/kind-cluster.yaml 会调用kind角色，关键变量如下：

• 集群名kind_cluster_name: seldon，默认命名空间seldon-mesh；
• Kind 版本v0.24.0，节点镜像kindest/node:v1.31.0；
• 默认启用 metrics-server（Chart 版本 3.8.3）与MetalLB（Chart 版本 0.13.9）。

其中 MetalLB 对后续演示至关重要：ansible/roles/kind/tasks/metallb.yaml会读取 dockerkind网络的子网，并将x.x.255.1~x.x.255.255分配给 MetalLB 作为 LoadBalancer 地址池。这正是后文中seldon-meshService 能拿到172.21.255.2、172.21.255.4这类集群外可访问 IP 的原因。

随后安装 Seldon Core v2 所依赖的生态组件（Kafka、cert-manager、Prometheus、Grafana、Jaeger、OpenTelemetry 等）：

cd ansible && ansible-playbook playbooks/setup-ecosystem.yaml

ansible/playbooks/setup-ecosystem.yaml 中full_install: yes会同时安装并配置 prometheus、grafana、kafka、certmanager、jaeger、opentelemetry（schema_registry 与 clickhouse 默认关闭）。其中cert-manager是本演示的硬性前置条件——因为seldon-core-v2-certsChart 完全依赖 cert-manager 的Issuer/Certificate资源签发证书。

三、安装 CRD 并创建业务命名空间

首先在seldon-mesh命名空间安装 CRD Chart（mlops.seldon.io/v1alpha1组下的 Model、Pipeline、Server、SeldonConfig 等自定义资源定义）：

helm upgrade --install seldon-core-v2-crds ../k8s/helm-charts/seldon-core-v2-crds -n seldon-mesh

预期输出（REVISION: 2表示此前已安装过，可重复执行）：

Release "seldon-core-v2-crds" has been upgraded. Happy Helming! NAME: seldon-core-v2-crds LAST DEPLOYED: Thu Jun 22 09:11:26 2023 NAMESPACE: seldon-mesh STATUS: deployed REVISION: 2 TEST SUITE: None

CRD 清单由 k8s/helm-charts/seldon-core-v2-crds/templates/seldon-v2-crds.yaml 渲染，全集群只需安装一次。

然后创建两个业务命名空间，用于验证控制面跨命名空间管理模型：

kubectl create namespace ns1 kubectl create namespace ns2

预期输出分别为namespace/ns1 created、namespace/ns2 created。

四、在业务命名空间安装证书

seldon-core-v2-certsChart 会为每个命名空间生成一套自签 CA 与成对的服务端/客户端证书（k8s/helm-charts/seldon-core-v2-certs/templates/certs.yaml），分别在两个命名空间安装：

helm install seldon-v2-certs ../k8s/helm-charts/seldon-core-v2-certs/ -n ns1 helm install seldon-v2-certs ../k8s/helm-charts/seldon-core-v2-certs/ -n ns2

4.1 证书体系拆解

从 Chart 模板源码看，它依次创建如下资源：

所有业务证书的duration均为 2160h（90 天）、renewBefore为 360h（15 天），并同时启用server auth与client auth两种用途，从而一套证书可同时承担服务端与客户端角色。证书签发后以同名 Kubernetes Secret 保存（tls.crt/tls.key/ca.crt），供后续 Helm values 中的secret/clientValidationSecret/serverValidationSecret字段引用。

安装输出示例：

NAME: seldon-v2-certs LAST DEPLOYED: Thu Jun 22 10:00:32 2023 NAMESPACE: ns1 STATUS: deployed REVISION: 1 TEST SUITE: None

五、解读 TLS 配置：控制面与数据面双重加密

在安装控制面前，先查看仓库提供的 TLS 样例配置：

cat ../k8s/samples/values-tls-dataplane-controlplane-example.yaml

security: controlplane: protocol: SSL ssl: server: secret: seldon-controlplane-server clientValidationSecret: seldon-controlplane-client client: secret: seldon-controlplane-client serverValidationSecret: seldon-controlplane-server envoy: protocol: SSL ssl: upstream: server: secret: seldon-upstream-server clientValidationSecret: seldon-upstream-client client: secret: seldon-upstream-client serverValidationSecret: seldon-upstream-server downstream: client: serverValidationSecret: seldon-downstream-server server: secret: seldon-downstream-server

5.1 security 结构总览

security段由seldon-core-v2-setupChart 的 values.yaml（默认全部为PLAINTEXT）扩展而来，完整结构还包含kafka、schemaRegistry子段。每个ssl通道都由server与client两侧组成，每侧又包含自己的secret（本端身份证书）与对方的校验 Secret：

• server.secret：服务端本端身份证书 Secret；
• server.clientValidationSecret：服务端用于校验客户端身份的 CA/证书 Secret（开启 mTLS 时才有值）；
• client.secret：客户端本端身份证书 Secret；
• client.serverValidationSecret：客户端用于校验服务端身份的 CA/证书 Secret。

5.2 controlplane：双向 TLS（mTLS）

controlplane.protocol: SSL表示 scheduler 与 controller、modelgateway、pipelinegateway、dataflow、agent 之间的通信全部加密。两侧都同时配置了本端 Secret 与对端校验 Secret，即双向认证：服务端要求客户端出示证书（clientValidationSecret），客户端也校验服务端（serverValidationSecret）。这与 Helm 模板中 controller Deployment 的环境变量一一对应（CONTROL_PLANE_SECURITY_PROTOCOL、CONTROL_PLANE_CLIENT_TLS_SECRET_NAME、CONTROL_PLANE_SERVER_TLS_SECRET_NAME等，见 k8s/helm-charts/seldon-core-v2-setup/templates/_components-deployments.tpl）。

从模板还可看到 scheduler 容器暴露了scheduler-mtls（9044）与agent-mtls（9055）端口，同时保留普通端口（9004 等），说明组件根据ALLOW_PLAINTXT/CONTROL_PLANE_SECURITY_PROTOCOL运行时决定走明文还是 mTLS 端口。模板中证书是以挂载卷方式注入容器的，values.yaml.template给出了默认挂载路径，例如控制面服务端证书位于/tmp/certs/cps/tls.key、/tmp/certs/cps/tls.crt、/tmp/certs/cps/ca.crt，客户端证书位于/tmp/certs/cpc/，Envoy 上游在/tmp/certs/dus/与/tmp/certs/duc/，Envoy 下游在/tmp/certs/dds/与/tmp/certs/ddc/——本演示的简化 values 省略了这些路径，直接使用默认值。

5.3 envoy upstream：与模型 Server 之间 mTLS

envoy.protocol: SSL且upstream侧server与client都配置了身份与校验 Secret，说明Envoy 与上游模型 Server（mlserver / triton）之间同样是双向 TLS。这要求模型 Server 的 Pod 中也注入seldon-upstream-server/seldon-upstream-client证书，运行时数据面流量在集群内全程加密。

5.4 envoy downstream：对外单向 TLS

downstream段的差异值得注意：client 侧只有serverValidationSecret: seldon-downstream-server，没有本端secret，server 侧也只有本端secret、没有clientValidationSecret。这意味着外部客户端调用推理接口时只做服务端认证（单向 TLS）——客户端需要信任seldon-downstream-server证书，但服务端不校验客户端身份。这正是后文 CLI 配置中skipSSLVerify: true能工作的原因：CLI 无需携带任何客户端证书即可发起 HTTPS 推理请求。

仓库还提供了仅数据面加密的变体values-tls-dataplane-example.yaml（k8s/samples/values-tls-dataplane-example.yaml），其中 controlplane 保持PLAINTEXT、envoy 为SSL，可用于只想保护推理流量、暂不加密控制面的场景，可作为对照参考。

六、安装控制面与各命名空间运行时

6.1 以 Clusterwide 模式安装控制面

helm install seldon-v2 ../k8s/helm-charts/seldon-core-v2-setup/ -n seldon-mesh --set controller.clusterwide=true --values ../k8s/samples/values-tls-dataplane-controlplane-example.yaml

三个关键点：

1. --set controller.clusterwide=true：让 controller 监听并管理集群内所有命名空间（values.yaml 中默认值为false）；
2. --values ...values-tls-dataplane-controlplane-example.yaml：覆盖security.controlplane.protocol与security.envoy.protocol为SSL；
3. Chart 由 seldon-v2-components.yaml 根据useDeploymentsForServers选择渲染 Deployment 版或 StatefulSet 版模板（默认 StatefulSet）。

安装输出示例：

NAME: seldon-v2 LAST DEPLOYED: Thu Jun 22 09:11:40 2023 NAMESPACE: seldon-mesh STATUS: deployed REVISION: 1 TEST SUITE: None

6.2 在 ns1 / ns2 分别安装 Runtime 与 Servers

helm install seldon-v2-runtime ../k8s/helm-charts/seldon-core-v2-runtime -n ns1 helm install seldon-v2-servers ../k8s/helm-charts/seldon-core-v2-servers -n ns1 helm install seldon-v2-runtime ../k8s/helm-charts/seldon-core-v2-runtime -n ns2 helm install seldon-v2-servers ../k8s/helm-charts/seldon-core-v2-servers -n ns2

各 Chart 职责：

• seldon-core-v2-runtime（values.yaml）：在业务命名空间部署 scheduler、envoy、dataflow、modelgateway、pipelinegateway 等运行时副本。注意scheduler.serviceType与envoy.serviceType默认均为LoadBalancer——这正是每个命名空间都会出现一个独立seldon-meshService（带外部 IP）的原因；
• seldon-core-v2-servers（values.yaml）：部署 mlserver 与 triton 两种模型 Server 的 StatefulSet，默认各 1 副本，PVC 保留策略为Retain。

安装全部完成后，分别等待两个命名空间中的 Server 就绪：

kubectl wait --for condition=ready --timeout=300s server --all -n ns1 kubectl wait --for condition=ready --timeout=300s server --all -n ns2

预期输出：

server.mlops.seldon.io/mlserver condition met server.mlops.seldon.io/triton condition met

server.mlops.seldon.io是mlops.seldon.io/v1alpha1组下的 Server 资源类型，该等待命令验证了 server CR 的ready条件。

七、为 Seldon CLI 配置 TLS

模型推理需要通过seldon-mesh的 LoadBalancer 入口进行。先获取两个命名空间各自的入口 IP（使用 Jupyter 魔术命令的 Python 写法，在普通 Shell 中可等价写成kubectl get svc seldon-mesh -n ns1 -o jsonpath='{.status.loadBalancer.ingress[0].ip}'）：

MESH_IP=!kubectl get svc seldon-mesh -n ns1 -o jsonpath='{.status.loadBalancer.ingress[0].ip}' MESH_IP_NS1=MESH_IP[0] import os os.environ['MESH_IP_NS1'] = MESH_IP_NS1 MESH_IP_NS1

输出'172.21.255.2'（该 IP 即第 2 节中 MetalLB 从 Kind 网络子网分配出来的范围）。

MESH_IP=!kubectl get svc seldon-mesh -n ns2 -o jsonpath='{.status.loadBalancer.ingress[0].ip}' MESH_IP_NS2=MESH_IP[0] import os os.environ['MESH_IP_NS2'] = MESH_IP_NS2 MESH_IP_NS2

输出'172.21.255.4'。两个命名空间各自持有独立的 Envoy 入口 IP，是"跨命名空间部署、各自独立暴露推理入口"的直接体现。

随后把仓库提供的 TLS 客户端配置加入 CLI 并激活：

seldon config add tls ${PWD}/config-dataplane-tls.json seldon config activate tls

配置文件内容为（samples/config-dataplane-tls.json）：

{ "dataplane": { "tls": true, "skipSSLVerify": true } }

7.1 CLI 配置机制源码解读

从源码看，CLI 的配置体系位于 operator/pkg/cli/config.go 与 operator/pkg/cli/configs.go：

• SeldonCLIConfig由dataplane、controlplane、kafka三段组成；dataplane支持inferHost、tls、skipSSLVerify、keyPath、crtPath、caPath字段——本演示只用到tls与skipSSLVerify，若需更严格的 mTLS，可补充客户端证书三件套；
• 命名配置清单保存在~/.config/seldon/cli/configs.json，每个名称映射到一个配置文件路径；active字段指向当前生效的配置名；
• seldon config add <name> <path>执行Add(key, configPath)写入映射并持久化；seldon config activate tls执行Activate(key)把active指向tls；
• seldon model infer在发起请求前会通过LoadSeldonCLIConfig()读取当前 active 配置，若dataplane.tls=true则以 HTTPS 连接推理入口（相关命令参数详见 docs-gb/cli/seldon_model_infer.md，如--inference-host默认0.0.0.0:9000、--inference-mode默认rest、--show-headers、--sticky-session等）。

也就是说：启用 TLS 后，seldon model infer仍只需指定--inference-host，握手加密与证书校验行为由 active 配置自动接管，这也是演示中 CLI 命令本身没有任何--tls标志的原因。

八、跨命名空间部署模型并执行加密推理

8.1 模型清单解读

两个命名空间部署的是同一个 sklearn Iris 模型：

kubectl create -f ./models/sklearn-iris-gs.yaml -n ns1

模型清单 内容如下：

apiVersion: mlops.seldon.io/v1alpha1 kind: Model metadata: name: iris spec: storageUri: "gs://seldon-models/scv2/samples/mlserver_1.6.0/iris-sklearn" requirements: - sklearn memory: 100Ki

要点：requirements: [sklearn]让 scheduler 将模型调度到具备sklearn能力标签的 mlserver 上；storageUri指向公共 GCS 存储；memory: 100Ki是模型的内存预留。该资源通过kubectl直接提交到集群，controller 在 clusterwide 模式下会接管并下发调度（集群内管理请优先使用 kubectl/Helm，Seldon CLI 主要用于非 Kubernetes 环境，详见 docs-gb/getting-started/cli.md 的提示）。

创建后等待模型就绪：

kubectl wait --for condition=ready --timeout=300s model --all -n ns1

输出model.mlops.seldon.io/iris condition met。ns2 执行完全相同的两步操作。

8.2 在 ns1 发起加密推理

seldon model infer iris --inference-host ${MESH_IP_NS1}:80 \ '{"inputs": [{"name": "predict", "shape": [1, 4], "datatype": "FP32", "data": [[1, 2, 3, 4]]}]}'

请求体是 KServe/V2 数据平面协议：单个输入张量predict，形状[1,4]，类型FP32。由于dataplane.tls=true已激活，该请求实际通过 HTTPS 访问 Envoy 的 80 端口（skipSSLVerify: true跳过了对自签证书的信任校验，与第 5.4 节分析的"下游单向 TLS、客户端不携带证书"设计吻合）。

响应示例：

{ "model_name": "iris_1", "model_version": "1", "id": "77f21360-b6cf-4c50-a000-1f219f5e9e29", "parameters": {}, "outputs": [ { "name": "predict", "shape": [ 1, 1 ], "datatype": "INT64", "parameters": { "content_type": "np" }, "data": [ 2 ] } ] }

响应中model_name: iris_1表明模型被调度到编号 1 的模型实例；输出为 INT64 标量2（Iris 三分类，[1,2,3,4]四个特征预测为类别 2）。

8.3 在 ns2 发起加密推理

kubectl create -f ./models/sklearn-iris-gs.yaml -n ns2 kubectl wait --for condition=ready --timeout=300s model --all -n ns2 seldon model infer iris --inference-host ${MESH_IP_NS2}:80 \ '{"inputs": [{"name": "predict", "shape": [1, 4], "datatype": "FP32", "data": [[1, 2, 3, 4]]}]}'

输出与 ns1 一致（响应 id 不同，如902b8483-0ede-4136-97be-dbf266f05a0c，data: [2]）。这验证了：同一个模型清单在 ns1、ns2 各部署一份，通过各自命名空间的 Envoy 入口（不同 LoadBalancer IP）在 TLS 加密通道上独立完成推理，控制面则以 clusterwide 方式统一管理两套运行时。

九、环境清理（TearDown）

演示结束后按依赖顺序清理：先删模型与各命名空间内的 release，再删控制面与 CRD，最后删除命名空间。

kubectl delete -f ./models/sklearn-iris-gs.yaml -n ns1 kubectl delete -f ./models/sklearn-iris-gs.yaml -n ns2

预期输出model.mlops.seldon.io "iris" deleted（两次）。

helm delete seldon-v2-servers -n ns1 helm delete seldon-v2-runtime -n ns1 helm delete seldon-v2-certs -n ns1

预期输出：

release "seldon-v2-servers" uninstalled release "seldon-v2-runtime" uninstalled release "seldon-v2-certs" uninstalled

注意原演示在 ns2 清理时重复执行了两次helm delete seldon-v2-runtime -n ns2，第二次会返回Error: uninstall: Release not loaded: seldon-v2-runtime: release: not found——这是 Helm 对重复删除的正常报错，实际只需执行一次：

helm delete seldon-v2-runtime -n ns2 helm delete seldon-v2-certs -n ns2

helm delete seldon-v2 -n seldon-mesh helm delete seldon-core-v2-crds -n seldon-mesh kubectl delete namespace ns1 kubectl delete namespace ns2

预期输出依次为release "seldon-v2" uninstalled、release "seldon-core-v2-crds" uninstalled、namespace "ns1" deleted、namespace "ns2" deleted。若还需要彻底还原环境，可再用ansible-playbook或kind delete cluster销毁 Kind 集群与 Kafka 等生态组件。

十、要点总结与延伸建议

1. 安装顺序不可颠倒：cert-manager（随 setup-ecosystem 安装）→ CRD → 业务命名空间证书 → 控制面（clusterwide + TLS values）→ 各命名空间 runtime/servers → 模型。
2. Clusterwide 的核心开关：controller.clusterwide=true决定 controller 是否跨命名空间管理mlops.seldon.io资源，对应 Helm 模板中 ClusterRole/ClusterRoleBinding 的创建逻辑。
3. TLS 分为三段：控制面 mTLS、Envoy 上游（与模型 Server）mTLS、Envoy 下游（外部客户端）单向 TLS。若需要更高级的客户端认证，可参考 k8s/helm-charts/seldon-core-v2-setup/values.yaml.template 中downstream.client.mtls、keyPath/crtPath/caPath等字段，并为 CLI 配置keyPath/crtPath/caPath后关闭skipSSLVerify。
4. CLI 配置是命名空间级别的"档案"：seldon config add/activate/list/deactivate/remove系列命令管理~/.config/seldon/cli/configs.json下的多套配置档案，可随时切换（参见 docs-gb/cli/seldon_config.md）。
5. 生产环境注意：演示使用自签 CA 与skipSSLVerify，仅用于功能验证；生产环境应替换为企业 CA 或 cert-manager 的 ACME 签发，并落实证书轮换（证书默认 90 天、提前 15 天续期）。

• 人工智能
• 大模型
• MLOps
• LLMOps
• 模型推理服务
• 云原生
• 后端