huxiaolong.ant

请参考一下 [集群部署](https://github.com/secretflow/secretflow/blob/beta/DEPLOYMENT.md) 的文档。 需要在ray节点（机器）加入集群的时候，按照文档指明是哪一方，这样在调度的时候会将计算调度到对应的机器；

这个是对应的 [中文文档](https://secretflow.readthedocs.io/zh_CN/latest/getting_started/deployment.html#cluster-mode) 供参考

ray在k8s上部署的方案可能并不直接适用于这里；因为现实中B/C并不会和A在同一个K8S集群中；所以最好的方式，就是你在B/C机器上手动启动ray实例，并按照[中文文档](https://secretflow.readthedocs.io/zh_CN/latest/getting_started/deployment.html#cluster-mode) 声明是哪个party； 如果按照此方案，可以不用管pod_name的事情

目前scql和kuscia的初步设计已经对齐，正在进行细节的设计和开发， 预计11中下旬可以开发完成，敬请关注

@Tiger007x 你好，你们现在使用PIR是什么样的场景？ 因为很多PIR场景其实是可以用PSI替代的， 所以对于PIR的需求，我们一般想了解的更加细致一点

> 看这个方法内部要更新写 `/etc/resolv.conf` 文件，而这个文件是 `root` 用户 `644` 的 这里是说 启动kuscia容器时是非root账号，还是期望启动的kuscia容器内部使用非root账号运行？

关注的非常细致，这部分是因为我们在agent做了配置的渲染， 会把[app_image](https://github.com/secretflow/kuscia/blob/main/scripts/templates/app_image.secretflow.yaml) 中的配置项，渲染出来。 也可以参考这里 https://www.secretflow.org.cn/docs/kuscia/latest/zh-Hans/reference/concepts/appimage_cn 看一下。

kuscia目前采用的运行时是RunC的模式, 介绍可以[参考这里](https://www.secretflow.org.cn/docs/kuscia/latest/zh-Hans/reference/architecture_cn#agent)，所以每一个任务我们都会在kuscia的（docker）容器内拉起一个新的（containerd）容器；这样可以对不同的任务进行资源隔离（包括文件系统隔离），所以直接在kuscia的容器内是看不到这个文件的，如果任务在运行过程中，你可以通过 [这里](https://www.secretflow.org.cn/docs/kuscia/latest/zh-Hans/deployment/operation_cn#id17) 的介绍，查看对应的文件

你的Ubuntu版本是哪个？ 以及是用的WSL方式？ 还有就是你并没有在docker中跑kuscia，直接使用的Ubuntu本地编译kuscia，然后直接执行的模式是吗？

因为安全原因，我们kuscia使用的sf镜像不支持自定义python的下发，只能运行给定的 [组件](https://www.secretflow.org.cn/docs/secretflow/latest/zh-Hans/component/comp_list) 如果一定要运行自定义的代码，可以参考文档 [AppImage](https://www.secretflow.org.cn/docs/kuscia/latest/zh-Hans/reference/concepts/appimage_cn) 和 [KusciaTask](https://www.secretflow.org.cn/docs/kuscia/latest/zh-Hans/reference/concepts/kusciatask_cn) 文档，基于secretflow自定义一个应用（docker），并注册appImage到kuscia中，然后通过kusciatask来提交任务。 目前kuscia这一期核心还是为了体验功能，这部分能力文档不齐全，我们再下一个版本会补充一下。