小编给大家分享一下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提供了一套开箱即用，可选的故障恢复功能，对应用中的服务大有裨益。这些功能包括：
-
超时
-
具备超时预算，并能够在重试之间进行可变抖动(间隔)的有限重试功能
-
并发连接数和上游服务请求数限制
-
对负载均衡池中的每个成员进行主动（定期）运行健康检查
-
细粒度熔断器（被动健康检查）-适用于负载均衡池中的每个实例
-
这些功能可以使用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流量管理有什么好处”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注云搜网行业资讯频道！