istio部署模型
Istio的部署模型介绍目录
部署模型当配置一个生产级别的Istio时,需要解决一些问题:如网格是单集群使用,还是跨集群使用?所有的服务会放到一个完全可达的网络中,还是需要网关来连接跨网络的服务?使用一个控制面(可能会跨集群共享一个控制面),还是使用多个控制面来实现高可用(HA)?所有的集群都连接到一个多集群服务网格,还是联合成一个多网格形态。 所有这些问题,以及他外因素,都代表了Istio部署的各个配置维度。
上述条件可以任意组合(虽然有些组合相比其他更加普遍,有些则不那么受欢迎,如单集群中的多网格场景)。 在一个涉及多集群的生产环境中,可以混合使用部署模型。例如,可以使用多个控制面来做到HA。在一个3集群环境中,可以将两个集群共享一个控制面,然后给第三个集群在不同的网络中添加另外一个控制面。然后配置三个集群共享各自的控制面,这样所有的集群就可以使用2个控制面来做到HA。 实际使用中,需要根据隔离性,性能,以及HA要求来选择合适的部署模型。本章将描述部署Istio时的各种选择和考量。 集群模式该模式下,应用的负载会运行在多个集群中。为了隔离,性能或高可用,可以限定集群的可用zone和region。 取决于具体要求,生产系统可以跨多个zone或region的多个集群运行,利用云负载均衡器来处理诸如本地性,zonal 或regional故障转移之类的事情。 大多数场景下,集群表示配置和终端发现的边界。例如,每个kubernetes集群都有一个API Server来管理集群的配置,以及提供服务终端的信息,如pod的启停等。由于kubernetes的这种配置行为是基于单个集群的,因此会将潜在的错误(如配置错误)限制在其所在的集群中。 使用Istio可以在任意个集群上配置一个服务网格。 单集群在最简单的场景中,可以在单个集群中部署单Istio网格。一个集群通常会运行在一个独立的网络中,但具体取决于基础设施提供商。包含一个网络的单集群模型会包含一个控制面,这就是istio最简单的部署模型: 单集群的部署比较简单,但同时也缺少一些特性,如故障隔离和转移。如果需要高可用,则应该使用多集群模式。 多集群一个网格可以包含多个集群。使用多集群部署可以在一个网格中提供如下功能。
多集群部署提供了更大的隔离性和可靠性,但同时也增加了复杂性。如果系统需要高可用,则集群可能会跨多个zone和region。 可以通过金丝雀配置来在单个集群中修改或使用新的二进制版本,这样配置变更仅会影响一小部分的用户流量。如果一个集群出现问题,可以临时把流量路由到临近的集群(直到问题解决)。 此外,可以根据网络和云提供商支持的选项配置集群间的通信。例如,如果两个集群使用了相同的底层网络,那么就可以通过简单的防火墙规则实现集群间的通信。 网络模型很多生产系统需要多个网络或子网来实现隔离和高可用。Istio支持将一个服务网格部署到多种类型的网络拓扑中。通过这种方式选择符合现有网络拓扑的网络模型。 单网络在最简单场景下,服务网格会运行在一个完全连接的网络上,在单网络模型下,所有的负载示例能够在没有Istio网格的情况下实现互联。 单个网络使Istio能够在网格中以统一的方式配置服务使用者,并具有直接处理工作负载实例的能力。 多网络多网络提供了如下新功能:
这种模式下,不同网络中的负载实例只能通过一个或多个Istio网关进行互联。Istio使用分区服务发现来为使用者提供service endpoints的不同视图。视图取决于使用者的网络。 控制面模型Istio网格使用控制面来配置网格内负载实例之间的通信。通过复制控制面,工作负载可以连接到任何控制面来获取配置。 最简单的场景下,可在单集群中运行网格的控制面: 像这样具有自己的本地控制平面的集群被称为主集群。 多集群部署可以共享相同的控制面实例。这种情况下,控制面实例可以位于一个或多个主集群中。没有自己的控制面的集群称为远端集群。 一个完全由远程集群组成的服务网格可以通过外部控制面进行控制,而不需要通过运行在主集群中的控制面进行控制。通过这种方式将istio在管理上进行了隔离,即将控制面和数据面服务进行了完全分割。
为了高可用,控制面可能需要跨多集群,zone和region来部署。下图中的服务网格在每个region中都使用了一个控制面。 使用上述模型具有如下优势:
可以通过故障转移来提升控制面的可靠性。当一个控制面实例变为不可用时,负载实例可以连接到其他可用的控制面实例上。集群,zone和region中都可能发生故障迁移。下图可以看到,当左侧的控制面出问题后,由右侧的控制面托管了Envoy代理(虚线)。 以下列表按可用性对控制平面的部署进行了排序:
身份和信任模型当在一个服务网格中创建负载实例时,istio会赋予该负载一个身份。 CA( certificate authority)会为网格中使用的身份创建和颁发证书,后续就可以使用CA为该身份创建和颁发证书时使用的公钥对消息发送端进行校验。trust bundle是Istio网格使用的所有CA公钥的集合。任何人都可以使用网格的trust bundle校验来自网格的服务。 网格中的信任在单istio网格中,istio保证每个负载实例都有一个标识其身份的证书,使用trust bundle来识别网格和联邦网格中的所有身份。CA仅负责为这些身份创建和签发证书。该模型允许网格中的负载实例互联。下图展示了一个具有 certificate authority的服务网格。 网格之间的信任如果一个网格中的服务需要调用另外一个网格中的服务,此时需要在两个网格之间使用联邦身份。为了实现联邦身份的信任,需要交换网格的trust buncles(可以通过手动或自动方式,如SPIFFE Trust Domain Federation来交换trust bundles) 网格模型Istio支持在一个网格或联邦网格(也被称为多网格)中部署所有的应用。 单网格单网格是部署Istio的最简单的方式。在一个网格中,服务名是唯一的。例如,一个 单网格可以部署在一个或多个集群中,以及一个或多个网络上。在一个网格中,命名空间用于tenancy(见下)。 多网格多网格是网格联邦的结果。 多网格提供了如下功能:
可以使用中间网格来连接网格联邦。当使用联邦时,每个网格都可以暴露一组所有参与的网格都能识别的服务和身份。 为了避免服务名冲突,可以给每个网格分配一个全局唯一的网格ID,来保证每个服务的fully qualified domain name (FQDN)是有效的。 当联邦中两个网格没有使用相同的信任域时,必须对这两个网格的身份和trust bundles进行联邦。查看Multiple Trust Domains。 租户模式在Istio中,租户是一个共享用户组,共享一组已部署的工作负载的访问权限和特权。通常需要从网络配置和策略层面来为不同的租户隔离负载实例。 可以配置租户模式来满足组织的隔离需求:
Istio支持两种类型的租户:
Namespace tenancy在一个网格中,Istio使用命名空间作为租户的单位。Istio也可以运行在没有实现命名空间租户的环境中。在实现命名空间租户的环境中,可以保证仅允许一个团队将负载部署在一个给定的命名空间或一组命名空间中。默认情况下,多个租户命名空间中的服务都可以互联。 为了提升隔离性,可以选择暴露到其他命名空间中的服务。通过授权策略来暴露服务或限制访问。 当使用多集群时,每个集群中的相同名称的命名空间被看作是相同的命名空间。例如, Cluster tenancyIstio支持以集群作为租户的单位。这种情况下,可以给每个团队指定特定的集群或一组集群来部署负载,并授权团队成员。可以给成员分配不同的角色,如:
为了在Istio中使用集群租户,需要将每个集群作为独立的网格。此外,可以使用Istio将一组集群作为单租户。这样每个团队就可以拥有一个或多个集群,而不是将所有的集群配置为单网格。为了连接不同团队的网格,可以将这些将这些网格联邦为多网格。下图展示了使用两个集群和命名空间来隔离服务网格。 由于网格由不同的团队或组织进行操作,因此服务命名很少会不同。例如, 当每个团队都有各自的网格后,就可以使用多网格模型跨网格进行通信。 性能和可靠性Istio使用丰富的路由,负载均衡,服务到服务的认证,监控等简化了部署服务的网络,且不需要修改应用代码。Istio力争使用最少的资源开销来提供这些便利,以及在增加最小的延迟下支撑更大规模的网格和更高的请求率。 Istio数据面组件,Envoy代理会处理流经系统的数据。Istio的控制面组件,Pilot,Galley和Citadel来配置数据面。数据面和控制面都有明显的性能问题。 1.7的性能摘要Istio负载测试网格包含1000个服务和2000个sidecar,每秒70000个网格范围的请求。在对Istio1.7测试之后,得出如下结果:
控制面性能Pilot会根据用户的配置文件和系统的当前状态配置sidecar代理。在Kubernetes环境中,CRD和deployment构成了配置和系统状态。Istio配置对象,如gateway和virtual service等提供了用户可编辑的配置。为了生成代理的配置,Pilot处理来自Kubernetes环境和用户配置的组合配置以及系统状态。 控制平面支持成千上万的服务,这些服务分布在成千上万个Pod中,并使用类似数量的由用户编写的virtual services和其他配置对象。Pilot的CPU和内存会随着配置数据的变化和系统状态而变化。CPU的使用包含如下因素:
但这部分是支持水平扩展的。 当启用命名空间租户时,使用1vCPU和1.5GB内存的单个Pilot可以支持1000个服务,2000个sidecar。可以通过增加Pilot的数量来降低配置所有代理的时间。 数据面性能数据面性能依赖很多因素,如:
延迟,吞吐量以及代理的CPU和内存消耗均根据上述因素进行衡量。 CPU和内存由于sidecar代理会在数据路径上做一些额外的工作,因此会消耗CPU和内存。如Istio 1.1中,在每秒1000个请求的情况下,一个代理会消耗0.6 vCPU。 代理的内存消耗取决于代理保存的总配置状态。大量listeners,clusters和routes可能会增加内存消耗。Istio 1.1引入了命名空间隔离来限制发送到一个代理的配置。在一个大的命名空间中,一个代理大概会消耗50 MB的内存。 由于代理通常不会缓存通过的数据,因此请求率不会影响内存消耗。
延迟由于Istio在数据路径上注入了sidecar代理,因此延迟是一个需要重点考虑的因素。Istio会将身份验证和Mixer过滤器添加到代理,每个额外的过滤器都会增加代理内部的路径长度,并影响到延迟。 Envoy代理会收在客户端接收到响应之后采集原始的遥测数据。对采集请求的遥测数据的时间不会计算在总的完成请求所需要的时间内。但由于worker忙于处理请求,因此worker可能不会立即处理下一个请求。这种处理会增加请求在队列中等待的时间,并影响到平均值和尾部延迟。实际的尾部延迟取决于流量状况。 Istio 1.7的延迟在网格中,请求会通过客户端的代理,然后到达服务端。1.7的默认配置中(即,telemetry V2),这两个代理在基准数据平面延迟的90百分位和99百分位延迟上分别增加了大约3.12ms 和3.13ms。通过Istio benchmarks的 在即将发布的Istio版本中,将把Istio策略和Istio遥测功能作为TelemetryV2添加到代理中。通过这种方式来减少流经系统的数据量,从而减少CPU使用量和延迟。 ? P90 latency vs client connections without jitter ? P99 latency vs client connections without jitter ? P90 latency vs client connections with jitter ? P99 latency vs client connections with jitter
Benchmarking 工具Istio使用如下工具来进行benchmarking:
Pods 和Services作为网格的一部分,kubernetes的pod和service必须满足如下要求:
要求的pod capabilities如果集群使用了pod安全策略,除非使用了Istio CNI插件,否则pod必须允许 为了校验pod是否允许 使用如下命令可以列出一个service accout的capabilities,替换
例如可以使用如下命令来校验
如果在capabilities列表中看到 (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |