kubernetes中实现Istio流量管理有什么好处

小编给大家分享一下kubernetes中实现Istio流量管理有什么好处,相信大部分人都还不怎么了解,因此分享这篇文章给大家参考一下,希望大家阅读完这篇文章后大有收获,下面让我们一起去了解一下吧!

一:简介

Istio流量管理的核心组件是Pilot,它管理和配置部署在特定Istio服务网格中的所有Envoy代理实例。它允许您指定在Envoy代理之间使用什么样的路由流量规则,并配置故障恢复功能,如超时,重试和熔断器。它还维护了网格中所有服务的规范模型,并使用这个模型通过发现服务让Envoy了解网格中的其它实例。每个Envoy实例都会维护负载均衡信息,负载均衡信息是基于从Pilo获得的信息,以及其负载均衡池中的其它实例的定期健康检查。从而允许其在目标实例之间智能分配流量,同时遵循其指定的路由规则。

二:流量管理的好处

使用 Istio 的流量管理模型,本质上是将流量与基础设施扩容解耦,让运维人员可以通过 Pilot 指定流量遵循什么规则,而不是执行哪些 pod/VM 应该接收流量——Pilot 和智能 Envoy 代理会帮我们搞定。因此,例如,您可以通过 Pilot 指定特定服务的 5% 流量可以转到金丝雀版本,而不必考虑金丝雀部署的大小,或根据请求的内容将流量发送到特定版本

将流量从基础设施扩展中解耦,这样就可以让 Istio 提供各种流量管理功能,这些功能在应用程序代码之外。除了 A/B 测试的动态请求路由,逐步推出和金丝雀发布之外,它还使用超时、重试和熔断器处理故障恢复,最后还可以通过故障注入来测试服务之间故障恢复策略的兼容性。这些功能都是通过在服务网格中部署的 Envoy sidecar/代理来实现的。

Pilot 负责部署在 Istio 服务网格中的 Envoy 实例的生命周期管理。

如上图所示,Pilot维护了网格中的服务的规范表示,这个表示是独立于底层平台的。Pilot中的平台特定适配器负责适当填充此规范模型。例如,Pilot中的Kubernetes适配器实现必要的控制器来监控Kubernetes API server中pod注册信息,Ingress资源以及用于存储流量管理规则的第三方资源的更改。该数据被翻译成规范表示。Envoy特定配置是基于规范表示生成的。

Pilot公开了用于服务发现,负载均衡池和路由表的动态更新的API。这些API将Envoy从平台特有的细微差别中解脱出来,简化了设计并提升了跨平台的可移植性。

运维人员可以通过Pilot的Rules API指定高级流量管理规则。这些规则被翻译成低级配置,并通过discovery API分发到Envoy实例。

三:请求路由

如Pilot所述,特定网格中的服务的规范由Pilot维护。服务的Istio模型和在底层平台(Kubernetes,Mesos以及Cloud Foundry等)中的表达无关。特定平台的适配器负责从各自平台中获取元数据的各种字段,然后对服务模型进行填充。Istio引入服务版本的概念,可以通过版本(v1,v2)或环境(staging,prod)对服务进行进一步的细分。这些版本不一定是不同的API版本:它们可能是部署在不同环境(prod,staging或者dev等)中的同一服务的不同迭代。使用这种方式的常见场景包括A/B测试或金丝雀部署。Istio的流量路由规则可以根据服务版本来对服务之间流量进行附加控制。

四:服务之间的通信

如上图所示,服务的客户端不知道服务不同版本间的差异。他们可以使用服务的主机名或者 IP 地址继续访问服务。Envoy sidecar/代理拦截并转发客户端和服务器之间的所有请求和响应。

运维人员使用 Pilot 指定路由规则,Envoy 根据这些规则动态地确定其服务版本的实际选择。该模型使应用程序代码能够将它从其依赖服务的演进中解耦出来,同时提供其他好处(参见 Mixer)。路由规则让 Envoy 能够根据诸如 header、与源/目的地相关联的标签和/或分配给每个版本的权重等标准来进行版本选择。

Istio 还为同一服务版本的多个实例提供流量负载均衡。可以在服务发现和负载均衡中找到更多信息。

Istio 不提供 DNS。应用程序可以尝试使用底层平台(kube-dns,mesos-dns 等)中存在的 DNS 服务来解析 FQDN。

五:服务发现和负载均衡

服务注册:Istio假定存在服务注册表,以跟踪应用程序中服务的pod/vm. 它还假设服务的新实例自动注册到服务注册表,并且不健康的实例将会被自动删除。诸如kubernetes,mesos等平台已经为基于容器的应用程序提供了这样的功能。

服务发现:Pilot使用来自服务注册的信息,并提供与平台无关的服务发现接口。网格中的Envoy实例执行服务发现,并相应地动态更新其负载均衡池。

如上图所示,网格中的服务使用其 DNS 名称访问彼此。服务的所有 HTTP 流量都会通过 Envoy 自动重新路由。Envoy 在负载均衡池中的实例之间分发流量。虽然 Envoy 支持多种复杂的负载均衡算法,但 Istio 目前仅允许三种负载平衡模式:轮循、随机和带权重的最少请求。

除了负载均衡外,Envoy 还会定期检查池中每个实例的运行状况。Envoy 遵循熔断器风格模式,根据健康检查 API 调用的失败率将实例分类为不健康或健康。换句话说,当给定实例的健康检查失败次数超过预定阈值时,它将从负载均衡池中弹出。类似地,当通过的健康检查数超过预定阈值时,该实例将被添加回负载均衡池。您可以在处理故障中了解更多有关 Envoy 的故障处理功能。

服务可以通过使用 HTTP 503 响应健康检查来主动减轻负担。在这种情况下,服务实例将立即从调用者的负载均衡池中删除。

六:故障处理

Envoy提供了一套开箱即用,可选的故障恢复功能,对应用中的服务大有裨益。这些功能包括:

  1. 超时

  2. 具备超时预算,并能够在重试之间进行可变抖动(间隔)的有限重试功能

  3. 并发连接数和上游服务请求数限制

  4. 对负载均衡池中的每个成员进行主动(定期)运行健康检查

  5. 细粒度熔断器(被动健康检查)-适用于负载均衡池中的每个实例

  6. 这些功能可以使用Istio的流量管理规则在运行时进行动态配置

七:微调

Istio 的流量管理规则允许运维人员为每个服务/版本设置故障恢复的全局默认值。然而,服务的消费者也可以通过特殊的 HTTP 头提供的请求级别值覆盖超时和重试的默认值。在 Envoy 代理的实现中,对应的 Header 分别是 x-envoy-upstream-rq-timeout-ms 和 x-envoy-max-retries。

八:故障注入

虽然 Envoy sidecar/proxy 为在 Istio 上运行的服务提供了大量的故障恢复机制,但测试整个应用程序端到端的故障恢复能力依然是必须的。错误配置的故障恢复策略(例如,跨服务调用的不兼容/限制性超时)可能导致应用程序中的关键服务持续不可用,从而破坏用户体验。

Istio 能在不杀死 Pod 的情况下,将协议特定的故障注入到网络中,在 TCP 层制造数据包的延迟或损坏。我们的理由是,无论网络级别的故障如何,应用层观察到的故障都是一样的,并且可以在应用层注入更有意义的故障(例如,HTTP 错误代码),以检验和改善应用的弹性。

运维人员可以为符合特定条件的请求配置故障,还可以进一步限制遭受故障的请求的百分比。可以注入两种类型的故障:延迟和中断。延迟是计时故障,模拟网络延迟上升或上游服务超载的情况。中断是模拟上游服务的崩溃故障。中断通常以 HTTP 错误代码或 TCP 连接失败的形式表现。

以上是“kubernetes中实现Istio流量管理有什么好处”这篇文章的所有内容,感谢各位的阅读!相信大家都有了一定的了解,希望分享的内容对大家有所帮助,如果还想学习更多知识,欢迎关注云搜网行业资讯频道!