0


【云原生 | 从零开始学istio】二、Istio核心特性与架构

在这里插入图片描述

istio核心特性

Istio 核心特性

1、流控(traffic management)
断路器(circuit breakers)、超时、重试、多路由规则、AB 测试、灰度发布、按照百分比分配流量等。

2、安全(security)
加密、身份认证、服务到服务的权限控制、K8S 里容器到容器的权限控制等。

3、可观察(observability)
追踪、监控、数据收集,通过控制后台全面了解上行下行流量,服务链路情况,服务运行情况,系统性能情况,国内微服务架构体系,这一块做得比较缺乏。

4、平台无关系(platform support)
K8s,物理机,自己的虚机都没问题。

5、集成与定制(integration and customization)
可定制化扩展功能。

断路器

举个生活中的例子解释断路器

当电路发生故障或异常时,伴随着电流不断升高,并且升高的电流有可能能损坏电路中的某些重要器件,也有可能烧毁电路甚至造成火灾。若电路中正确地安置了保险丝,那么保险丝就会在电流异常升高到一定的高度和热度的时候,自身熔断切断电流,从而起到保护电路安全运行的作用。

很多技术都是来源生活的,随着社会进步,科技发展,断路器也称为服务熔断,在多个服务调用的时候,服务 A 依赖服务 B,服务 B 依赖服务 C,如果服务C 响应时间过长或者不可用,则会让服务 B 占用太多系统资源,而服务 A 也依赖服 B,同时也在占用大量的系统资源,造成系统雪崩的情况出现。 Istio 断路器通过网格中的边车对流量进行拦截判断处理,避免了在代码中侵入控制逻辑,非常方便的就实服务熔断的能力。

在这里插入图片描述

在微服务架构中,在高并发情况下,如果请求数量达到一定极限(可以自己设置阈值),超出了设置的阈值,断路器会自动开启服务保护功能,然后通过服务降级的方式返回一个友好的提示给客户端(非计算机专业可能看不懂504这种错误码)。假设当 10 个请求中,有 10%失败时,熔断器就会打开,此时再调用此服务,将会直接返回失败,不再调远程服务。直到 10s 钟之后,重新检测该触发条件,判断是否把熔断器关闭,或者继续打开。

服务降级(提高用户体验效果)

比如电商平台,在针对 618、双 11 的时候会有一些秒杀场景,秒杀的时候请求量大,可能会返回报错标志“当前请求人数多,请稍后重试”等,如果使用服务降级,无法提供服务的时候,消费者会调用降级的操作,返回服务不可用等信息,或者返回提前准备好的静态页面写好的信息。

超时

什么时候需要用到超时?

在生产环境中经常会碰到由于调用方等待下游的响应过长,堆积大量的请求阻塞了自身服务,造成雪崩的情况,通过超时处理来避免由于无限期等待造成的故障,进而增强服务的可用性。通过例子来理解

在这里插入图片描述

nginx 服务设置了超时时间为 3 秒,如果超出这个时间就不在等待,返回超时错误
httpd 服务设置了响应时间延迟 5 秒,任何请求都需要等待 5 秒后才能返回
client 通过访问 nginx 服务去反向代理 httpd 服务,由于 httpd 服务需要 5 秒后才能返回,但 nginx 服务只等待 3 秒,所以客户端会提示超时错误。

重试

istio 重试机制就是如果调用服务失败,Envoy 代理尝试连接服务的最大次数。而默认情况下,Envoy 代理在失败后并不会尝试重新连接服务。
举个例子:

在这里插入图片描述

客户端调用 nginx,nginx 将请求转发给 tomcat。tomcat 通过故障注入而中止对外服务,nginx 设置如果访问 tomcat 失败则会重试 3 次。

多路由规则

1、HTTP 重定向(HTTPRedirect)

2、HTTP 重写(HTTPRewrite)

3、HTTP 重试(HTTPRetry)

4、HTTP 故障注入(HTTPFaultInjection)

5、HTTP 跨域资源共享(CorsPolicy)

Istio 架构

istio 服务网格从逻辑上分为数据平面和控制平面。

在这里插入图片描述

1、数据平面由一组以 Sidecar(边车)方式部署的智能代理(Envoy+Polit-agent)组成。这些代理承载并控制微服务之间的所有网络通信,管理入口和出口流量,类似于一线员工。 Sidecar 一般和业务容器绑定在一起(在 Kubernets 中以自动注入的方式注入到到业务 pod 中),来劫持业务应用容器的流量,并接受控制面组件的控制,同时会向控制面输出日志、跟踪及监控数据,Envoy 和 pilot-agent 打在同一个镜像中,即 sidecar Proxy。

2、control plane 控制平面负责管理和配置代理来路由流量。
istio1.5+中使用了一个全新的部署模式,重建了控制平面,将原有的多个组件整合为一个单体结构istiod,这个组件是控制平面的核心,管理 Istio 的所有功能,主要包括 Pilot、Mixer、Citadel 等服务组件。

istiod 是新版本中最大的变化,以一个单体组件替代了原有的架构,降低了复杂度和维护难度,但原有的多组件并不是被完全移除,而是在重构后以模块的形式整合在一起组成了 istiod。

结合下图我们来理解 Istio 的各组件的功能及相互之间的协作方式。

在这里插入图片描述

  1. 自动注入:在创建应用程序时自动注入 Sidecar 代理 Envoy 程序。在 Kubernetes 中创建 Pod 时,Kube-apiserver 调用控制面组件的 Sidecar-Injector 服务,自动修改应用程序的描述信息并注入Sidecar。在真正创建 Pod 时,在创建业务容器的 Pod 中同时创建 Sidecar 容器。
  2. 流量拦截:在 Pod 初始化时设置 iptables 规则,基于配置的 iptables 规则拦截业务容器的 Inbound 流量和 Outbound 流量到 Sidecar 上。而应用程序感知不到 Sidecar 的存在,还以原本的方式进行互相访问。上图中,流出 frontend 服务的流量会被frontend 服务侧的 Envoy 拦截,而当流量到达 forecast 容器时,Inbound 流量被 forecast 服务侧的 Envoy 拦截。
  3. 服务发现:服务发起方的 Envoy 调用控制面组件 Pilot 的服务发现接口获取目标服务的实例列表。上图中,frontend 服务侧的 Envoy 通过 Pilot 的服务发现接口得到 forecast 服务各个实例的地址。
  4. 负载均衡:服务发起方的 Envoy 根据配置的负载均衡策略选择服务实例,并连接对应的实例地址。上图中,数据面的各个 Envoy 从 Pilot 中获取 forecast 服务的负载均衡配置,并执行负载均衡动作。
  5. 流量治理:Envoy 从 Pilot 中获取配置的流量规则,在拦截到 Inbound(入境) 流量和 Outbound 流量时执行治理逻辑。上图中, frontend 服务侧的 Envoy 从 Pilot 中获取流量治理规则,并根据该流量治理规则将不同特征的流量分发到 forecast 服务的 v1 或 v2 版本。
  6. 访问安全:在服务间访问时通过双方的 Envoy 进行双向认证和通道加密,并基于服务的身份进行授权管理。上图中,Pilot 下发安全相关配置,在 frontend 服务和 forecast 服务的 Envoy 上自动加载证书和密钥来实现双向认证,其中的证书和密钥由另一个管理面组件 Citadel 维护。
  7. 服务监测:在服务间通信时,通信双方的 Envoy 都会连接管理面组件 Mixer 上报访问数据,并通过 Mixer 将数据转发给对应的监控后端。上图中,frontend 服务对 forecast 服务的访问监控指标、日志和调用链都可以通过这种方式收集到对应的监控后端。
  8. 策略执行:在进行服务访问时,通过 Mixer 连接后端服务来控制服务间的访问,判断对访问是放行还是拒绝。上图中,Mixer 后端可以对接一个限流服务对从 frontend 服务到 forecast 服务的访问进行速率控制等操作。
  9. 外部访问:在网格的入口处有一个 Envoy 扮演入口网关的角色。上图中,外部服务通过 Gateway 访问入口服务 frontend,对 frontend 服务的负载均衡和一些流量治理策略都在这个 Gateway 上执行。

sidecar 和 proxy 相生相伴,就像汽车与车轮。未来,sidecar 和 proxy 就指微服务进程解耦成两个进程之后,提供基础能力的那个代理进程。

写在最后

创作不易,如果觉得内容对你有帮助,麻烦给个三连关注支持一下我!如果有错误,请在评论区指出,我会及时更改!

目前正在更新的系列:从零开始学istio

感谢各位的观看,文章掺杂个人理解,如有错误请联系我指出~

标签: 云原生 istio 架构

本文转载自: https://blog.csdn.net/qq_45400861/article/details/127401388
版权归原作者 是泡泡 所有, 如有侵权,请联系我们删除。

“【云原生 | 从零开始学istio】二、Istio核心特性与架构”的评论:

还没有评论