新一代Serverless平台 Knative的应用实践

作者：佚名 2021-09-06 16:00:39

云计算 Knative对于Serverless平台的标准化意义重大；Knative当前正逐步成熟但大规模应用还需要进一步完善；Knative的发展前景广阔，有望成为未来的主流无服务架构管理平台

 业务介绍
1. 单品API服务是当当网技术平台中核心的基础服务之一
2. 由一系列与商品相关的API服务构成
3. 单品API完成大量后台API的接口聚合并实现接口性能的加速
4. 单品API为所有相关上游服务提供高效可靠的底层服务支持。
技术现状
1. 开发语言构成有PHP、JAVA。
2. 以K8S原生方式部署运行。

运行环境
• Knative: v0.8.0
• Istio: v1.3.0
• Kubernetes：v1.14.4
• Docker: v18.06.3
• Centos：v7.5
• Promethues v2.2.1
• Grafana v5.0.3
• Tekton Pipelines: v0.8.0
• Server: 8cores /32G mem/500GB HD

用户容器的构建与编排

1. 编写用户容器相应的dockerfile

用户容器的构建与编排
1. 编写用户容器相应的dockerfile
2. Tekton构建代码打包运行时容器推送到私有镜像仓库

用户容器的构建与编排

1. 编写用户容器相应的dockerfile
2. Tekton构建代码打包运行时容器推送到私有镜像仓库
3. 编写knative的service.yaml 配置文件

Blue/Green部署
…
traffic: – tag: current
revisionName: productapi
-v1
percent: 100
– tag: candidate
revisionName: productapi
-v2
percent: 0
– tag: latest
latestRevision: true
percent: 0

性能测试
评估Knative平台对应用代码的性能影响
请求总并发：200
Knative环境每个POD并发数：40
Knative环境启动POD数：6个
K8s环境启用POD数：6个
 

问题与后续改进
性能问题：
• Queue Proxy
1. 负责所有用户容器流量的转发
2. 向Autoscaler报告客户端指标
• 带来的问题：
调用链中增加了一层代理，在我们的测试场景中，QueueProxy带来了27ms的延迟以及约120m的CPU
资源消耗。
• 未来可能的解决方案
直接使用Istio的sidecar(envoy)来替换Queue Proxy，但这样有可能会带来对service mesh层的耦合。

运维工具
• 日志中心：EFK
• 监控：Promethues & Grafana
• 服务网格可视化： Istio & Kiali，Jaeger(调用链跟踪)

服务可视化工具
服务网格的可视化工具- Kiali
1. 服务拓扑图
2. 健康检查
3. 分布式跟踪
4. 指标度量收集
5. 配置校验

监控工具
 

性能优化（一）
降低冷启动延迟的解决方案
• 保留服务最小副本数避免冷启延迟
autoscaling.knative.dev/minScale: “n” // n 为1或者对应业务估算的最小副本数
• 微服务化优化服务启动速度
A. 减小用户容器镜像的大小，方便快速分发
B. 减少用户容器的启动时间

性能优化（二）
对可预见的高并发场景的解决方案
为服务预设预期最小所需副本数
例如：autoscaling.knative.dev/minScale: “200”
为服务预设最大所需副本数避免资源过度分配
例如：autoscaling.knative.dev/maxScale: “500″
为服务的每个POD设置最大并发请求数上限保障POD的可用性
例如：autoscaling.knative.dev/target: “100”

后续发展与改进
支持更多弹性伸缩指标
• 当前支持的metrics
HPA： CPU使用率，不支持缩容到0
KPA： 并发请求数， 支持缩容到0
• 新版本新增Metrics：
KPA: RPS/QPS/OPS

结论
• Knative对于Serverless平台的标准化意义重大。
• Knative当前正逐步成熟但大规模应用还需要进一步完善。
• Knative的发展前景广阔，有望成为未来的主流无服务架构管理平台。