kubernetes中Istio的示例分析

这篇文章主要介绍kubernetes中Istio的示例分析，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！

一：简介

随着微服务架构的普及，越来越多的应用已经拆分成了微服务的架构。而微服务架构落地的一个难点，就是如何让服务和服务之间进行稳定的通信。

部署微服务之后，如何做服务的负载均衡、容错性、服务监控、日志追踪以及熔断等功能都需要考虑周全。

为了让业务团队返璞归真，将所有精力集中在业务代码而不是配合微服务组件写大量非功能性需求的代码，Istio应运而生。

Istio是谷歌、IBM、Lyft等公司贡献的开源Service Mesh组件。它实现的目标就是让业务开发不再关注微服务之间如何调用、管理、监控等非功能性需求，而是让Istio来处理这些问题。Istio和Kubernetes有天然的支持。

Istio能轻松解决蓝绿发布和金丝雀发布的问题。

Istio能够做到：

HTTP、gRPC、WebSocket和TCP流量的自动负载均衡。

通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。

支持访问控制、速率限制和配额的可拔插策略层和配置API。

自动指标、日志和集群内所有流量的跟踪，包括集群入口和出口。

通过集群中的服务之间的强身份断言来实现服务间的身份验证。

通过在整个环境中部署一个特殊的sidecar代理（辅助容器），您可以将Istio支持添加到服务中。安装了sidecar代理之后，（微）服务之间的所有网络通信都通过这个代理。此外，所有的网络通信都是使用Istio的控制平面功能进行配置和管理的。

二：主要功能

流量管理(Pilot)。控制服务之间的流量和API调用的流向，使得调用更灵活可靠，并使网络在恶劣情况下更加健壮。

可观察性。通过集成zipkin等服务，快速了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。

策略执行(mixer)。将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。

服务身份和安全(Istio-auth)。为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。

除此之外，Istio针对可扩展性进行了设计，以满足不同的部署需要：

平台支持。Istio旨在可以在各种环境中运行，包括跨云、预置环境、Kubernetes、Mesos等。最初专注于Kubernetes，但很快将支持其他环境。

集成和定制。策略执行组件可以扩展和定制，以便与现有的ACL、日志、监控、配额、审核等解决方案集成。

三：整体架构

分为控制平面和数据平面两部分：

控制平面：Pilot, Mixer, Istio-Auth，分别对Istio中的服务做流量管理，策略配置，安全通信等规则配置 

数据平面：所有pod上的Envoy，负责所有规则的执行

主要构成组件：

Envoy：用于调解服务网格中所有服务的所有入站和出站流量。支持例如动态服务发现，负载均衡，故障注入、流量管理等功能。Envoy 以 sidecar 的方式部署在相关的服务的 Pod 中。

Pilot：Pilot 负责收集和验证配置并将其传播到各种 Istio组件。

Mixer：负责在服务网格上执行访问控制和使用策略，并从 Envoy 代理和其他服务收集遥测数据。

Istio-Auth：提供强大的服务间认证和终端用户认证。

四：Istio分布式追踪实现原理

Istio 服务网格的核心是 Envoy，是一个高性能的开源 L7 代理和通信总线。在 Istio 中，每个微服务都被注入了 Envoy Sidecar，该实例负责处理所有传入和传出的网络流量。因此，每个 Envoy Sidecar 都可以监控所有的服务间 API 调用，并记录每次服务调用所需的时间以及是否成功完成。

每当微服务发起外部调用时，客户端 Envoy 会创建一个新的 span。一个 span 代表一组微服务之间的完整交互过程，从请求者（客户端）发出请求开始到接收到服务方的响应为止。

在服务交互过程中，客户端会记录请求的发起时间和响应的接收时间，服务器端 Envoy 会记录请求的接收时间和响应的返回时间。

每个 Envoy 都会将自己的 span 视图信息发布到分布式追踪系统。当一个微服务处理请求时，可能需要调用其他微服务，从而导致因果关联的 span 的创建，形成完整的 trace。这就需要由应用来从请求消息中收集和转发下列 Header。

以上是“kubernetes中Istio的示例分析”这篇文章的所有内容，感谢各位的阅读！希望分享的内容对大家有帮助，更多相关知识，欢迎关注编程网行业资讯频道！