为 Kuscia 新增《如何使用 Kuscia API 运行一个 SecretFlow 作业》教程文档

[Candicepan]

此 ISSUE 为 隐语开源共建计划（SecretFlow Open Source Contribution Plan，简称 SF OSCP）第二期任务 ISSUE，欢迎社区开发者参与共建～
若有感兴趣想要认领的任务，但还未报名，辛苦先完成报名进行哈～

任务介绍

• 任务名称：为 Kuscia 新增《如何使用 Kuscia API 运行一个 SecretFlow 作业》教程文档
• 技术方向：Kuscia/docs
• 任务难度：进阶🌟🌟

详细要求

在文档 《如何运行一个 SecretFlow 作业》 中介绍了如何使用 K8s API 来执行作业，在 K8s API 的基础上，Kuscia 还封装了一层 Kuscia API 。希望你可以参考 《如何运行一个 SecretFlow 作业》 文档的内容新增一篇 “如何使用 Kuscia API 运行一个 SecretFlow 作业” 的教程文档，包括以下部分：

• 介绍如何使用 Kuscia API 发起创建作业（KusciaJob）的请求
• 介绍如何使用 Kuscia API 发起查询作业（KusciaJob）详细状态的请求
• 介绍如何使用 Kuscia API 发起查询作业中某个任务（KusciaTask）的详细状态的请求
• 介绍如何使用 Kuscia API 发起删除作业（KusciaJob）的请求

同时需要保证内容正确性，包括：

• 在 Kuscia 根目录使用 make docs 命令编译成功
• 用浏览器打开 docs/_build/html/index.html 查看新增的文档渲染正常
• 按照文档中的步骤可以成功运行一个 Secretflow 作业

其他说明：

• 文档规范：输出文档时，请遵循《文档规范》
• 提交说明：关联该 ISSUE 并提交代码至 https://github.com/secretflow/kuscia/tree/main/docs/tutorial

能力要求

• 了解基本 git 操作
• 了解 RESTful API
• 对 Kuscia 有一定了解

操作说明

• 参考内容：KusciaJob 接口文档参考
• Kuscia API 服务部署在 Master 容器中，默认监听 8082 端口
• 访问 Kuscia API 服务需要使用 /home/kuscia/etc/certs 目录中的 MTLS 证书: ca.crt，kusciaapi-client.key，kusciaapi-client.crt

[AgravicCastle]

AgravicCastle Give it to me

[AgravicCastle]

部署后发现${user}-kuscia-master节点没有与主机的端口映射，需要进入到master节点容器里面curl Kuscia API。
想咨询下，对于Kuscia来说，在主机上用http客户端访问master容器是一个有价值的场景吗？

[longshan-ant]

第一次发布，我们注重了首次体验上（包括同时体验中心化场景和P2P场景），所以并没有暴露出端口（以免冲突），理论上只需要调整一下部署脚本就可以把Master的端口暴露出来的，实际生产场景也需要这么干，所以你使用上不方便的话，可以调整一下start_standalone.sh脚本（L555），增加上端口映射即可，这样就可以本地curl http://127.0.0.1:暴露端口 访问kuscia-api了
对于kuscia来说，客户可以直接提供K8s相关的API（例如业务使用client-go接入），但是有些客户对K8s并不熟悉，接入K8s Api成本稍高一点，所以我们也暴露了一个简单的Http/GRPC接口来给客户接入，这样客户可以直接基于这套API系统搭建他自己的业务系统。

[AgravicCastle]

https://www.secretflow.org.cn/docs/kuscia/latest/zh-Hans/reference/apis/kusciajob_cn
似乎没有能够查询当前节点运行了哪些KusciaJob的接口，类似kubectl get kj命令。
这样的话，使用api的用户需要自行维护KusciaJob列表，或者命令与api混用，有些不方便。

[AgravicCastle]

更新任务执行进度：API教程文档已基本完成，目前正在校对、润色。进度无风险

[longshan-ant]

https://www.secretflow.org.cn/docs/kuscia/latest/zh-Hans/reference/apis/kusciajob_cn 似乎没有能够查询当前节点运行了哪些KusciaJob的接口，类似kubectl get kj命令。 这样的话，使用api的用户需要自行维护KusciaJob列表，或者命令与api混用，有些不方便。

这个问题是一个非常好的观察；没有提供的原因是我们暂时还没有想得非常清晰，或者从目前的角度来讲，我们期望kuscia-api最简洁。一般在业务系统上，一般会有自己更多关于任务信息的记录，比如这个任务发起人是谁，谁审批的等信息，那么业务系统会自己有一个db的table来记录任务的信息，所以list本身他是直接从db中可以拿到的，并不一定需要kuscia-api提供；甚至白屏页面上，一般可能还要支持任务搜索等功能，这些接口太业务了，如果都由kuscia来提供，需要做的工作量太大，而且也不一定做的比业务更好。那么不如先交由业务来实现，我们只提供最核心的create/status/stop接口。

[AgravicCastle]

pull request
#48