Istio 与 Knative 踩坑实录

• 语言: 中文（简体）
• 格式: .pdf
• 来源: github.com/servicemesher

摘要

文档主要讲述了在生产环境中使用Istio和Knative的实际经验和遇到的问题。Istio在工程架构上的收益高于性能资源损耗，适用于超大规模应用，但仍有一些架构问题需要社区或业界进一步解决。Knative作为Serverless基础设施在实践中表现出冷启动时间较长（约3.6秒）、内存占用较高（30~60 MB）等问题。文档还详细描述了在使用过程中遇到的镜像源问题、RevisionUnknown状态、Queue-proxy内存增长以及Activator重复创建并占用大量资源等具体问题。

AI总结

# 《Istio 与 Knative 踩坑实录》总结

## Istio 的价值与问题
1. **稳定性**：Istio 已经可以稳定应用于生产环境，为工程架构带来显著收益。
2. **资源损耗**：存在一定的性能资源损耗，推广或改造需根据组织和业务情况灵活调整，新旧体系可并存。
3. **架构问题**：在超大规模应用中，部分架构问题仍需社区或业界进一步解决。

## Knative 的实践与瓶颈
1. **实践数据**：
- 平均冷启动时间：3.6 秒。
- 内存占用：30~60 MB（不包含 Istio-proxy）。
- 业务类型：基于 Go 或 Node.js 的简单接口。
2. **踩过的坑**：
- **镜像源问题**：镜像拉取或构建过程中出现异常。
- **RevisionUnknown 状态**：0.8 版本中 Revision 处于未知状态。
- **Queue-proxy 内存增长**：0.8 版本中 Queue-proxy 内存占用持续增加。
- **Activator 资源占用**：Activator 重复创建并占用大量资源。
3. **当前瓶颈**：
- 尚未发布 Production-ready 版本。
- Queue-proxy 过重，资源占用较高。
- 冷启动时间亟待优化。
- 是否支持代码级更新仍需探索。

## 总结
酷家乐在服务网格（Service Mesh）和无服务器架构（FAAS）方向上的实践表明，Istio 和 Knative 分别在流量管理和服务无化方面具有潜力，但也面临性能、资源和架构上的挑战。未来需要结合业务需求，进一步优化和探索解决方案。