私有化云应用/云函数需求

层

方案：

• 将用户上传的层代码，使用stretch空镜像+用户代码，打成docker image
• 层的管理增删改查，对应docker image的操作。
• 当用户将业务代码和层绑定时候，对应多阶段构建镜像的方式打包。

实现：

• 定义clustertask，使用kaniko基础镜像，再用miniclient下载s3代码，然后docker 打包。Push到用户的私有仓库
• 使用docker client sdk进行image的增删改查操作

使用mysql维护用户代码和层的绑定关系，并且记录优先顺序。用户构建版本时，取出用户业务代码中的dockerfile文件，在from或者workdir之后，按顺序追加多个from镜像，每一步copy到当前目录（或者和用户约定目录位置），多阶段构建的方式。然后使用现有的clustertask模版，直接构建新镜像即可。

• 用户下载层代码，对应从docker image复制出镜像（或者使用cos再存储一份，然后从cos下载。需要保持两者代码一致）

优点：

• 层镜像在本地，即便是第一次拉取，也是在内网docker私有仓库，不会收到网络情况影响，速度快，且稳定。

缺点：

• 用户下载层代码的时候，会稍微复杂一些，因为层代码以及打包到image镜像，这个不知道好不好解析出来代码，而如果使用s3存储的话，那么就需要保持s3的代码和docker image的代码一致。事务操作。代码逻辑会稍微复杂些。

流量分配

方案：

使用knative原生支持header tag匹配的方式分配流量 Example： You should see the following block which indicates the tag rev1 is successfully added to the first Revision.

- revisionName: tag-header-revision-1
  percent: 100
  key1: value1
- revisionName: tag-header-revision-2
  percent: 100
  key2: value2

但是我们配置的都是url中k=v的方式匹配，因此这里可以在scf-api或者是前端，直接将用户设置的url k=v添加到header中，scf-api或者invoker收到请求后，按照设置的百分比进行不通版本流量的配置。

云函数根据微信uin固定打到某一个pod上

方案：

这里的实现方式和上面类似，都是使用knative的原生header tag匹配的方式。 You should see the following block which indicates the tag rev1 is successfully added to the first Revision.

- revisionName: tag-header-revision-1
  percent: 0
  uin: 1
- revisionName: tag-header-revision-2
  uin: 2

不过这里稍微有点儿不同，tag是一系列版本数量取余的余数。 对用户uin按照pod数量取余，然后按照设置的header 匹配就可以，

环境间的云应用云函数pod访问隔离

方案：

Kubernetes原生支持namespace网络隔离，可以直接使用k8s的网络特性直接设置，不用编码。