设计目标
本节概述指导Istio设计的核心原则。
Istio的架构设计中有几个关键目标,这些目标对于使系统能够应对大规模流量和高性能地服务处理至关重要。
- 最大化透明度
若想Istio被采纳,应该让运维和开发人员只需付出很少的代价就可以从中受益。为此,Istio将自身自动注入到服务间所有的网络路径中。Istio使用sidecar代理来捕获流量,并且在尽可能的地方自动编程网络层,以路由流量通过这些代理,而无需对已部署的应用程序代码进行任何改动。在Kubernetes中,代理被注入到pod中,通过编写iptable规则来捕获流量。一旦注入sidecar代理到pod中并且修改路由规则,Istio就能够调解所有流量。这个原则也适用于性能。当将Istio应用于部署时,运维人员可以发现,为提供这些功能而增加的资源开销是很小的。所有组件和API在设计时都必须考虑性能和规模。
- 增量
随着运维人员和开发人员越来越依赖Istio提供的功能,系统必然和他们的需求一起成长。虽然我们期望继续自己添加新功能,但是我们预计最大的需求是扩展策略系统,集成其他策略和控制来源,并将网格行为信号传播到其他系统进行分析。策略运行时支持标准扩展机制以便插入到其他服务中。此外,它允许扩展词汇表,以允许基于网格生成的新信号来执行策略。
- 可移植性
使用Istio的生态系统将在很多维度上有差异。Istio必须能够以最少的代价运行在任何云或预置环境中。将基于Istio的服务移植到新环境应该是轻而易举的,而使用Istio将一个服务同时部署到多个环境中也是可行的(例如,在多个云上进行冗余部署)。
- 策略一致性
在服务间的API调用中,策略的应用使得可以对网格间行为进行全面的控制,但对于无需在API级别表达的资源来说,对资源应用策略也同样重要。例如,将配额应用到ML训练任务消耗的CPU数量上,比将配额应用到启动这个工作的调用上更为有用。因此,策略系统作为独特的服务来维护,具有自己的API,而不是将其放到代理/sidecar中,这容许服务根据需要直接与其集成。