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

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

from kuscia.

AgravicCastle Give it to me

from kuscia.

第一次发布，我们注重了首次体验上（包括同时体验中心化场景和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系统搭建他自己的业务系统。

from kuscia.

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接口。

from kuscia.

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

from kuscia.

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

from kuscia.

pull request
#48

from kuscia.