如果要在原生的 Kubernetes 上部署 Serverless 应用可能会怎么做？

首先需要一个 Deployment 来管理 Workload，还需要通过 Service 对外暴露服务 和实现服务发现的能力。应用有重大变更，新版本发布时可能需要暂停观察，待观察确认没 问题之后再继续增加灰度的比例。这时就要使用两个 Deployment 才能做到。 v1 Deployment 代表旧版本，灰度的时候逐一减少实例数；v2 Deployment 代表 新版本，灰度的时候逐一增加实例数。hpa 代表弹性能力，每一个 Deployment 都有一 个 hpa 管理弹性配置。 这其中其实是有冲突的：假设 v1 Deploymen 原本有三个 pod，灰度的时候升级一 个 pod 到 v2，此时其实是 1/3 的流量会打到 v2 版本上。但当业务高峰到来后，因为 两个版本都配置了 hpa，所以 v2 和 v1 会同时扩容，最终 v1 和 v2 的 pod 数量就不 是最初设置的 1/3 的比例了。 所以传统的这种按照 Deployment 实例数发布的灰度策略和弹性配置天然是冲突的。 而如果按照流量比例进行灰度就不会有这个问题，这可能就要引入 Istio 的能力。引入 Istio 作为 Gateway 组件，Istio 除了管理同一个应用的流量灰度，还能对不同 的应用进行流量管理。