Ray 集群 TLS 认证配置指南基于 KubeRay 手动管理证书的完整实践【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址: https://gitcode.com/gh_mirrors/ra/rayRay 在默认情况下客户端client、Head 进程与 Worker 进程之间的 gRPC 通道是明文传输的。通过为 Ray 配置 TLSTransport Layer Security可以让这些通道在握手阶段完成双向身份认证并对其间交换的数据进行加密。本文以 KubeRay 场景为背景基于 tls.md 的核心流程完整讲解如何用 OpenSSL 生成 CA 与节点证书、通过 init 容器为每个 Pod 动态签发证书以及如何设置RAY_USE_TLS等环境变量启用认证并最终验证加密通道是否生效。读完本文你将掌握一套可直接复制的 KubeRay TLS 手工配置方案同时理解 Ray 底层 gRPC 对 TLS 凭据的实际加载逻辑。TLS 认证的背景与适用场景Ray 支持在其 gRPC 通道上启用 TLS相关说明见 Ray 核心配置文档。启用后连接 Ray Head 需要提供合适的凭据证书客户端、Head、Worker 各进程之间交换的数据会被加密使用自签名证书即可实现内网集群的身份互认也可以选择使用公共可信 CA 签发的证书。TLS 利用私钥private key与公钥public key完成加解密密钥持有者保管私钥公钥则通过数字证书公开。证书颁发机构CA负责证明公钥持有者的身份证书中携带公钥、持有者身份信息与有效期。若不希望向 CA 申请证书可以使用 OpenSSL 等工具生成自签名证书。Ray 在握手阶段要求额外完成双向认证mutual authentication因此需要为集群中的每个节点准备独立证书。注意启用 TLS 会带来额外开销。双向认证与加解密在小型负载下开销占比较高在大型负载下相对占比会变小具体开销取决于工作负载特性。前置知识在继续之前建议先理解以下概念详见 tls.md私钥 / 公钥private/public keyCA证书颁发机构Certificate AuthorityCSR证书签名请求Certificate Signing Request自签名证书self-signed certificate快速上手TL;DR本文方案面向 KubeRay 0.5.0 及以上版本。更早版本的配置方式可能不适用或需要额外修改。KubeRay 社区提供了示例清单ray-cluster.tls.yaml它一次性完成了本文的 Step 1Step 3# 安装 KubeRay operator按官方安装流程执行 # 下载 ray-cluster.tls.yaml curl -LO https://raw.githubusercontent.com/ray-project/kuberay/v1.7.0/ray-operator/config/samples/ray-cluster.tls.yaml # 创建 RayCluster kubectl apply -f ray-cluster.tls.yaml # 跳转到 Step 4 Verify TLS authentication 验证连接该清单会创建以下资源一个 Kubernetes Secret包含 CA 的私钥ca.key和自签名证书ca.crt——对应 Step 1一个 Kubernetes ConfigMap包含脚本gencert_head.sh与gencert_worker.sh用于让 Head 与 Worker Pod 在启动时生成各自的私钥tls.key和自签名证书tls.crt——对应 Step 2一个 RayCluster带有一组合法的 TLS 环境变量配置——对应 Step 3。证书体系的工作方式每个 Pod 的证书tls.crt使用 CA 私钥ca.key签发加密所有 Pod 都持有 CA 公钥ca.crt因此任意 Pod 都能验证来自其他 Pod 的证书。安全警告ray-cluster.tls.yaml仅用于演示。切勿在生产环境中将 CA 私钥存入 Kubernetes Secret否则任何能读取该 Secret 的人都可冒充集群中的任意节点。Step 1生成 CA 的私钥与自签名证书本方案使用自签名证书但读者也可以选择公共可信 CA 签发的证书用于生产环境。# Step 1-1为 CA 生成自签名证书与新的私钥文件 openssl req -x509 \ -sha256 -days 3650 \ -nodes \ -newkey rsa:2048 \ -subj /CN*.kuberay.com/CUS/LSan Francisco \ -keyout ca.key -out ca.crt # Step 1-2检查自签名证书中的 CA 公钥 openssl x509 -in ca.crt -noout -text # Step 1-3将证书内容写入 Kubernetes Secret # 方法一使用 cat $FILENAME | base64 编码 ca.key 与 ca.crt # 然后把编码后的字符串粘贴到 ray-cluster.tls.yaml 的 Kubernetes Secret 中。 # 方法二使用 kubectl 自动编码并创建 Secret # 注意使用此方法时需注释掉 ray-cluster.tls.yaml 中已有的 Secret kubectl create secret generic ca-tls --from-fileca.key --from-fileca.crt生成的产物ca.keyCA 私钥必须严格保密ca.crtCA 自签名证书向集群所有节点公开。该步骤是可选的ray-cluster.tls.yaml中已经内置了演示用的ca.key与ca.crt直接 apply 即可跳过此步。但在生产环境中请务必自行生成并妥善保管密钥切勿复用演示凭据。Step 2为 Head 与 Worker Pod 分别生成私钥和自签名证书为什么每个 Pod 需要独立的证书在ray-cluster.tls.yaml中每个 PodHead 与 Worker都在自己的 init 容器内生成独立的私钥文件tls.key和自签名证书文件tls.crt。原因是Worker Pod 没有确定性的 DNS 名称无法在多个 Pod 间复用同一张证书因此必须逐 Pod 签发。清单中的 ConfigMap 名为tls内含两个 Shell 脚本gencert_head.sh为 Ray Head Pod 生成证书gencert_worker.sh为 Ray Worker Pod 生成证书。另一种做法是把这两个脚本直接预置prebake进 init 容器使用的 Docker 镜像中从而摆脱对 ConfigMap 的依赖。脚本内部的三个步骤两个脚本的逻辑一致均按以下顺序执行生成 2048 位 RSA 私钥保存到/etc/ray/tls/tls.key使用私钥tls.key和csr.conf配置文件生成证书签名请求CSR使用 CA 私钥ca.key对 CSR 签名生成自签名证书tls.crt。注意configure.rst 中对第 3 步的描述为“使用 CA 密钥对ca.key与ca.crt与 CSR 生成证书”实际操作中签名所需的是 CA 私钥CA 证书用于在验证端校验签名链路。请参见 Ray 核心配置文档。两个脚本的唯一区别[alt_names]gencert_head.sh与gencert_worker.sh的唯一差异在于csr.conf和cert.conf中的[alt_names]段。Worker 使用 Head Kubernetes Service 的**完全限定域名FQDN**来连接 Head Pod因此 Head 的证书必须把该 FQDN 写入 SANSubject Alternative Name而 Head 侧则通过$POD_IP与 Worker 通信。# gencert_head.sh 中的 [alt_names] [alt_names] DNS.1 localhost DNS.2 $FQ_RAY_IP IP.1 127.0.0.1 IP.2 $POD_IP # gencert_worker.sh 中的 [alt_names] [alt_names] DNS.1 localhost IP.1 127.0.0.1 IP.2 $POD_IP其中$FQ_RAY_IP是 Head Kubernetes Service 的 FQDN形如service-ray-head.default.svc.cluster.local$POD_IP由 init 容器动态读取。在 Kubernetes 网络模型中一个 Pod 看到自身的 IP 与其它 Pod 看到的该 Pod 的 IP 是相同的这正是 Pod 能够“自行注册证书”的前提——每个 Pod 只需要知道自己的 IP就能生成一张可被集群内其它 Pod 验证的证书。Step 3为 Ray 配置 TLS 环境变量要在 Ray 集群中启用 TLS 认证需要为 Head 与 Worker 进程设置以下环境变量变量定义见 Ray 核心配置文档环境变量含义示例值RAY_USE_TLS是否启用 TLS1启用、0关闭。设为1时以下所有变量必须同时设置。默认值01RAY_TLS_SERVER_CERT向其它端点出示的证书文件路径用于实现双向认证/etc/ray/tls/tls.crtRAY_TLS_SERVER_KEY私钥文件路径用于向其它端点证明你是该证书的合法持有者/etc/ray/tls/tls.keyRAY_TLS_CA_CERTCA 证书文件路径用于校验对端证书是否由正确的 CA 签发/etc/ray/tls/ca.crt在 KubeRay 的 YAML 清单中这些变量通常通过env段注入到 Head 与 Worker 容器证书文件则由 init 容器生成后写入共享的 emptyDir 卷/etc/ray/tls。Step 4验证 TLS 认证# 登录 Worker Pod kubectl exec -it ${WORKER_POD} -- bash # Worker 通过 Head Service 地址连接 Head。 # Head 证书的 SAN 中包含 $FQ_RAY_IP因此 TLS 校验成功。 # ray health-check 命令的退出码应为 0。 ray health-check --address $FQ_RAY_IP:6379 echo $? # 0 # Head 证书的 SAN 中不包含 $RAY_IP因此 TLS 校验失败。 # 会看到 TLS 校验错误错误信息会提示 Pod IP$RAY_IP不在证书中。 ray health-check --address $RAY_IP:6379 # 若在 gencert_head.sh 的 [alt_names] 中补充 DNS.3 $RAY_IP # 重新生成的 Head 证书就会包含 $RAY_IP 对应的 SAN 条目。 # # 对于 KubeRay 0.5.0 之前的版本该步骤是必需的因为早期版本的 # Ray Worker 使用 $RAY_IP 连接 Head。验证思路的核心是连接地址必须落在对端证书的 SAN 范围内。连接成功退出码 0说明双向 TLS 握手完整通过连接失败并报“not in certificate”类错误恰恰证明 TLS 校验在真实生效——证书与地址不匹配时连接会被拒绝。源码视角Ray 如何加载 TLS 凭据理解了运维侧的配置再来看 Ray 的 Python 侧是如何消费这四个环境变量的。核心实现位于 python/ray/_common/tls_utils.pyload_certs_from_env()L85-L99读取RAY_TLS_SERVER_CERT、RAY_TLS_SERVER_KEY、RAY_TLS_CA_CERT三个变量指向的文件内容若RAY_USE_TLS已开启但三者缺一会抛出RuntimeError提示“If the environment variable RAY_USE_TLS is set to true then RAY_TLS_SERVER_CERT, RAY_TLS_SERVER_KEY and RAY_TLS_CA_CERT must also be set.”——这印证了文档中“三个变量必须同时设置”的约束。add_port_to_grpc_server()L70-L82根据RAY_USE_TLS取值1或true视为开启决定创建安全端口还是非安全端口。开启时使用grpc.ssl_server_credentials加载服务端证书链与私钥并把 CA 证书作为root_certificates同时设置require_client_authTrue强制客户端也出示证书——这正是“双向认证mTLS”的机制来源。该模块还提供了generate_self_signed_tls_certs()L14-L67可用cryptography库在测试场景中快速生成 2048 位 RSA 密钥与包含localhost、本机 IP 等 SAN 的自签名证书对方便在本地验证 TLS 行为。从源码结构可以推断只要这些环境变量在 Ray 进程ray start/ray.init()启动前就绪Head、Worker 以及客户端如 Python 驱动建立的 gRPC 通道都会自动套用加密与双向认证逻辑无需在业务代码中做任何改动。性能影响与取舍启用 TLS 的代价来自双向认证与加密的开销加密/解密进程间流量会产生额外 CPU 开销对通信密集型负载影响最明显尤其是频繁的大对象传输和高调用频率的小任务对以计算为主、数据移动较少的负载开销可以忽略。因此在决定是否启用 TLS 时需要根据集群网络信任边界与工作负载特征综合权衡。对于跨公网或不可信网络部署的场景TLS 是必要的安全基线对于纯内网、负载高度敏感的场景可以评估收益与开销后决定。进阶方案KubeRay 自动化 mTLS本文介绍的是手工管理证书的方式。KubeRay v1.7 起引入了RayClusterMTLSfeature gate通过 cert-manager 自动签发并轮换证书可以免去手动生成 CA、编写 init 脚本等全部工作。两种方案的关系如下手动方式本文完全掌控 CA 与证书生命周期适合已有自建 CA 或强合规要求的场景自动方式mTLS设置spec.tlsOptions.enabled: true即可operator 会自动创建Issuer、Certificate等资源并注入 TLS 环境变量适合希望降低运维负担的场景。自动方式的完整配置与验证步骤见 kuberay-mtls.md。总结本文完整覆盖了在 KubeRay 上为 Ray 配置 TLS 认证的四个核心步骤生成 CA 密钥对、通过 init 容器为每个 Pod 动态签发证书、注入四个 TLS 环境变量、使用ray health-check验证双向认证是否生效。同时从 tls_utils.py 的源码层面解释了 Ray 如何读取环境变量、构造 gRPC 安全凭据并强制客户端认证。生产部署时请牢记两条原则不要将 CA 私钥存入 Secret、确保连接地址始终落在对端证书的 SAN 内。若希望进一步降低证书管理的运维成本可参考 kuberay-mtls.md 改用 cert-manager 自动化方案。【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址: https://gitcode.com/gh_mirrors/ra/ray创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Ray 集群 TLS 认证配置指南：基于 KubeRay 手动管理证书的完整实践
Ray 集群 TLS 认证配置指南基于 KubeRay 手动管理证书的完整实践【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址: https://gitcode.com/gh_mirrors/ra/rayRay 在默认情况下客户端client、Head 进程与 Worker 进程之间的 gRPC 通道是明文传输的。通过为 Ray 配置 TLSTransport Layer Security可以让这些通道在握手阶段完成双向身份认证并对其间交换的数据进行加密。本文以 KubeRay 场景为背景基于 tls.md 的核心流程完整讲解如何用 OpenSSL 生成 CA 与节点证书、通过 init 容器为每个 Pod 动态签发证书以及如何设置RAY_USE_TLS等环境变量启用认证并最终验证加密通道是否生效。读完本文你将掌握一套可直接复制的 KubeRay TLS 手工配置方案同时理解 Ray 底层 gRPC 对 TLS 凭据的实际加载逻辑。TLS 认证的背景与适用场景Ray 支持在其 gRPC 通道上启用 TLS相关说明见 Ray 核心配置文档。启用后连接 Ray Head 需要提供合适的凭据证书客户端、Head、Worker 各进程之间交换的数据会被加密使用自签名证书即可实现内网集群的身份互认也可以选择使用公共可信 CA 签发的证书。TLS 利用私钥private key与公钥public key完成加解密密钥持有者保管私钥公钥则通过数字证书公开。证书颁发机构CA负责证明公钥持有者的身份证书中携带公钥、持有者身份信息与有效期。若不希望向 CA 申请证书可以使用 OpenSSL 等工具生成自签名证书。Ray 在握手阶段要求额外完成双向认证mutual authentication因此需要为集群中的每个节点准备独立证书。注意启用 TLS 会带来额外开销。双向认证与加解密在小型负载下开销占比较高在大型负载下相对占比会变小具体开销取决于工作负载特性。前置知识在继续之前建议先理解以下概念详见 tls.md私钥 / 公钥private/public keyCA证书颁发机构Certificate AuthorityCSR证书签名请求Certificate Signing Request自签名证书self-signed certificate快速上手TL;DR本文方案面向 KubeRay 0.5.0 及以上版本。更早版本的配置方式可能不适用或需要额外修改。KubeRay 社区提供了示例清单ray-cluster.tls.yaml它一次性完成了本文的 Step 1Step 3# 安装 KubeRay operator按官方安装流程执行 # 下载 ray-cluster.tls.yaml curl -LO https://raw.githubusercontent.com/ray-project/kuberay/v1.7.0/ray-operator/config/samples/ray-cluster.tls.yaml # 创建 RayCluster kubectl apply -f ray-cluster.tls.yaml # 跳转到 Step 4 Verify TLS authentication 验证连接该清单会创建以下资源一个 Kubernetes Secret包含 CA 的私钥ca.key和自签名证书ca.crt——对应 Step 1一个 Kubernetes ConfigMap包含脚本gencert_head.sh与gencert_worker.sh用于让 Head 与 Worker Pod 在启动时生成各自的私钥tls.key和自签名证书tls.crt——对应 Step 2一个 RayCluster带有一组合法的 TLS 环境变量配置——对应 Step 3。证书体系的工作方式每个 Pod 的证书tls.crt使用 CA 私钥ca.key签发加密所有 Pod 都持有 CA 公钥ca.crt因此任意 Pod 都能验证来自其他 Pod 的证书。安全警告ray-cluster.tls.yaml仅用于演示。切勿在生产环境中将 CA 私钥存入 Kubernetes Secret否则任何能读取该 Secret 的人都可冒充集群中的任意节点。Step 1生成 CA 的私钥与自签名证书本方案使用自签名证书但读者也可以选择公共可信 CA 签发的证书用于生产环境。# Step 1-1为 CA 生成自签名证书与新的私钥文件 openssl req -x509 \ -sha256 -days 3650 \ -nodes \ -newkey rsa:2048 \ -subj /CN*.kuberay.com/CUS/LSan Francisco \ -keyout ca.key -out ca.crt # Step 1-2检查自签名证书中的 CA 公钥 openssl x509 -in ca.crt -noout -text # Step 1-3将证书内容写入 Kubernetes Secret # 方法一使用 cat $FILENAME | base64 编码 ca.key 与 ca.crt # 然后把编码后的字符串粘贴到 ray-cluster.tls.yaml 的 Kubernetes Secret 中。 # 方法二使用 kubectl 自动编码并创建 Secret # 注意使用此方法时需注释掉 ray-cluster.tls.yaml 中已有的 Secret kubectl create secret generic ca-tls --from-fileca.key --from-fileca.crt生成的产物ca.keyCA 私钥必须严格保密ca.crtCA 自签名证书向集群所有节点公开。该步骤是可选的ray-cluster.tls.yaml中已经内置了演示用的ca.key与ca.crt直接 apply 即可跳过此步。但在生产环境中请务必自行生成并妥善保管密钥切勿复用演示凭据。Step 2为 Head 与 Worker Pod 分别生成私钥和自签名证书为什么每个 Pod 需要独立的证书在ray-cluster.tls.yaml中每个 PodHead 与 Worker都在自己的 init 容器内生成独立的私钥文件tls.key和自签名证书文件tls.crt。原因是Worker Pod 没有确定性的 DNS 名称无法在多个 Pod 间复用同一张证书因此必须逐 Pod 签发。清单中的 ConfigMap 名为tls内含两个 Shell 脚本gencert_head.sh为 Ray Head Pod 生成证书gencert_worker.sh为 Ray Worker Pod 生成证书。另一种做法是把这两个脚本直接预置prebake进 init 容器使用的 Docker 镜像中从而摆脱对 ConfigMap 的依赖。脚本内部的三个步骤两个脚本的逻辑一致均按以下顺序执行生成 2048 位 RSA 私钥保存到/etc/ray/tls/tls.key使用私钥tls.key和csr.conf配置文件生成证书签名请求CSR使用 CA 私钥ca.key对 CSR 签名生成自签名证书tls.crt。注意configure.rst 中对第 3 步的描述为“使用 CA 密钥对ca.key与ca.crt与 CSR 生成证书”实际操作中签名所需的是 CA 私钥CA 证书用于在验证端校验签名链路。请参见 Ray 核心配置文档。两个脚本的唯一区别[alt_names]gencert_head.sh与gencert_worker.sh的唯一差异在于csr.conf和cert.conf中的[alt_names]段。Worker 使用 Head Kubernetes Service 的**完全限定域名FQDN**来连接 Head Pod因此 Head 的证书必须把该 FQDN 写入 SANSubject Alternative Name而 Head 侧则通过$POD_IP与 Worker 通信。# gencert_head.sh 中的 [alt_names] [alt_names] DNS.1 localhost DNS.2 $FQ_RAY_IP IP.1 127.0.0.1 IP.2 $POD_IP # gencert_worker.sh 中的 [alt_names] [alt_names] DNS.1 localhost IP.1 127.0.0.1 IP.2 $POD_IP其中$FQ_RAY_IP是 Head Kubernetes Service 的 FQDN形如service-ray-head.default.svc.cluster.local$POD_IP由 init 容器动态读取。在 Kubernetes 网络模型中一个 Pod 看到自身的 IP 与其它 Pod 看到的该 Pod 的 IP 是相同的这正是 Pod 能够“自行注册证书”的前提——每个 Pod 只需要知道自己的 IP就能生成一张可被集群内其它 Pod 验证的证书。Step 3为 Ray 配置 TLS 环境变量要在 Ray 集群中启用 TLS 认证需要为 Head 与 Worker 进程设置以下环境变量变量定义见 Ray 核心配置文档环境变量含义示例值RAY_USE_TLS是否启用 TLS1启用、0关闭。设为1时以下所有变量必须同时设置。默认值01RAY_TLS_SERVER_CERT向其它端点出示的证书文件路径用于实现双向认证/etc/ray/tls/tls.crtRAY_TLS_SERVER_KEY私钥文件路径用于向其它端点证明你是该证书的合法持有者/etc/ray/tls/tls.keyRAY_TLS_CA_CERTCA 证书文件路径用于校验对端证书是否由正确的 CA 签发/etc/ray/tls/ca.crt在 KubeRay 的 YAML 清单中这些变量通常通过env段注入到 Head 与 Worker 容器证书文件则由 init 容器生成后写入共享的 emptyDir 卷/etc/ray/tls。Step 4验证 TLS 认证# 登录 Worker Pod kubectl exec -it ${WORKER_POD} -- bash # Worker 通过 Head Service 地址连接 Head。 # Head 证书的 SAN 中包含 $FQ_RAY_IP因此 TLS 校验成功。 # ray health-check 命令的退出码应为 0。 ray health-check --address $FQ_RAY_IP:6379 echo $? # 0 # Head 证书的 SAN 中不包含 $RAY_IP因此 TLS 校验失败。 # 会看到 TLS 校验错误错误信息会提示 Pod IP$RAY_IP不在证书中。 ray health-check --address $RAY_IP:6379 # 若在 gencert_head.sh 的 [alt_names] 中补充 DNS.3 $RAY_IP # 重新生成的 Head 证书就会包含 $RAY_IP 对应的 SAN 条目。 # # 对于 KubeRay 0.5.0 之前的版本该步骤是必需的因为早期版本的 # Ray Worker 使用 $RAY_IP 连接 Head。验证思路的核心是连接地址必须落在对端证书的 SAN 范围内。连接成功退出码 0说明双向 TLS 握手完整通过连接失败并报“not in certificate”类错误恰恰证明 TLS 校验在真实生效——证书与地址不匹配时连接会被拒绝。源码视角Ray 如何加载 TLS 凭据理解了运维侧的配置再来看 Ray 的 Python 侧是如何消费这四个环境变量的。核心实现位于 python/ray/_common/tls_utils.pyload_certs_from_env()L85-L99读取RAY_TLS_SERVER_CERT、RAY_TLS_SERVER_KEY、RAY_TLS_CA_CERT三个变量指向的文件内容若RAY_USE_TLS已开启但三者缺一会抛出RuntimeError提示“If the environment variable RAY_USE_TLS is set to true then RAY_TLS_SERVER_CERT, RAY_TLS_SERVER_KEY and RAY_TLS_CA_CERT must also be set.”——这印证了文档中“三个变量必须同时设置”的约束。add_port_to_grpc_server()L70-L82根据RAY_USE_TLS取值1或true视为开启决定创建安全端口还是非安全端口。开启时使用grpc.ssl_server_credentials加载服务端证书链与私钥并把 CA 证书作为root_certificates同时设置require_client_authTrue强制客户端也出示证书——这正是“双向认证mTLS”的机制来源。该模块还提供了generate_self_signed_tls_certs()L14-L67可用cryptography库在测试场景中快速生成 2048 位 RSA 密钥与包含localhost、本机 IP 等 SAN 的自签名证书对方便在本地验证 TLS 行为。从源码结构可以推断只要这些环境变量在 Ray 进程ray start/ray.init()启动前就绪Head、Worker 以及客户端如 Python 驱动建立的 gRPC 通道都会自动套用加密与双向认证逻辑无需在业务代码中做任何改动。性能影响与取舍启用 TLS 的代价来自双向认证与加密的开销加密/解密进程间流量会产生额外 CPU 开销对通信密集型负载影响最明显尤其是频繁的大对象传输和高调用频率的小任务对以计算为主、数据移动较少的负载开销可以忽略。因此在决定是否启用 TLS 时需要根据集群网络信任边界与工作负载特征综合权衡。对于跨公网或不可信网络部署的场景TLS 是必要的安全基线对于纯内网、负载高度敏感的场景可以评估收益与开销后决定。进阶方案KubeRay 自动化 mTLS本文介绍的是手工管理证书的方式。KubeRay v1.7 起引入了RayClusterMTLSfeature gate通过 cert-manager 自动签发并轮换证书可以免去手动生成 CA、编写 init 脚本等全部工作。两种方案的关系如下手动方式本文完全掌控 CA 与证书生命周期适合已有自建 CA 或强合规要求的场景自动方式mTLS设置spec.tlsOptions.enabled: true即可operator 会自动创建Issuer、Certificate等资源并注入 TLS 环境变量适合希望降低运维负担的场景。自动方式的完整配置与验证步骤见 kuberay-mtls.md。总结本文完整覆盖了在 KubeRay 上为 Ray 配置 TLS 认证的四个核心步骤生成 CA 密钥对、通过 init 容器为每个 Pod 动态签发证书、注入四个 TLS 环境变量、使用ray health-check验证双向认证是否生效。同时从 tls_utils.py 的源码层面解释了 Ray 如何读取环境变量、构造 gRPC 安全凭据并强制客户端认证。生产部署时请牢记两条原则不要将 CA 私钥存入 Secret、确保连接地址始终落在对端证书的 SAN 内。若希望进一步降低证书管理的运维成本可参考 kuberay-mtls.md 改用 cert-manager 自动化方案。【免费下载链接】rayRay is an AI compute engine. Ray consists of a core distributed runtime and a set of AI Libraries for accelerating ML workloads.项目地址: https://gitcode.com/gh_mirrors/ra/ray创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考