[Istio是什么?] 还不知道你就out了,一文40分钟快速理解
作者:互联网
@
目录前言
这篇文章属于纯理论,所含内容如下,按需阅读:
Istio概念、服务网格、流量管理、istio架构(Envoy、Sidecar 、Istiod)
虚拟服务(VirtualService)、路由规则、目标规则(DestinationRule)
网关(Gateway)、网络弹性和测试(超时、重试、熔断器、故障注入)
Istio是什么?
-
Istio是一个开源的
服务网格
,透明的接入到分布式服务
中。它也是一个平台,集成任何日志、遥测和策略系统
的 API 接口。 -
Istio 成功高效地运行
分布式微服务架构
,并提供保护、连接和监控
微服务的统一方法。 -
Istio 有助于降低
DevOps
压力、开发团队
的压力。
服务网格是什么?
- 组成
微服务网络
- 实现
服务之间的交互
应用场景
服务发现、负载均衡、故障恢复、度量和监控
A/B 测试、金丝雀发布、速率限制、访问控制和端到端认证
为什么使用Istio?
服务网格是通过sidecar
(边车)代理服务实现,控制平面
主要是对sidecar
的配置和管理,这包括:
- 为
HTTP、gRPC、WebSocket
和TCP 流量
自动负载均衡。 - 通过丰富的
路由规则、重试、故障转移和故障注入
对流量行为进行细粒度控制。 - 可插拔的策略层和配置 API,支持
访问控制、速率限制和配额
。 - 集群内(包括集群的入口和出口)所有流量的
自动化度量、日志记录
和追踪
。 - 在具有强大的基于
身份验证和授权
的集群中实现安全的服务间通信。
Istio还支持扩展
,满足你部署需求!
流量管理介绍
-
Istio流量路由规则可以很容易的
控制服务之间的流量
和API调用
。能实现A/B测试、金丝雀发布、
基于流量百分比
发布。 -
开箱即用的
故障恢复
特性,有助于增强应用的健壮性
,从而更好地应对被依赖的服务或网络发生故障的情况。 -
Istio 的流量管理由
Envoy
代理服务提供。网格内服务发送和接收的所有流量
都由Envoy 代理
处理,让控制网格内的流量变得异常简单,不需要对服务做更改。
为了在网格中导流,Istio 需要知道 endpoint 在哪和属于哪个服务
。为了定位到service registry(服务注册中心)
,Istio 会连接到一个服务发现系统。例如,如果您在 Kubernetes 集群上安装了 Istio,那么它将自动检测该集群中的服务和 endpoint(端点)。
使用此服务注册中心,Envoy 代理
可以将流量定向到相关服务。大多数基于微服务的应用程序
,每个服务的工作负载都有多个实例来处理流量,称为负载均衡池
。默认情况下,Envoy 代理基于轮询调度在服务的负载均衡池内分发流量,按顺序请求发送给池中每个成员,一旦所有服务实例均接收过一次请求后,重新回到第一个池成员。
这些 API 也使用 Kubernetes 的自定义资源定义(CRDs)来声明,可以使用 YAML 进行配置
。
istio架构
Istio 服务网格 逻辑上分为数据平面
和控制平面
-
数据平面
:Envoy代理被部署为sidecar
,负责协调和控制微服务
之间的通信,收集和报告所有网格流量的遥测数据。 -
控制平面
:管理并配置Envoy代理
Envoy
C++ 开发
的高性能代理,用于协调服务网格中所有服务的入站和出站流量
。Envoy 代理是唯一与数据平面流量交互
的 Istio 组件。
Envoy 代理被部署为服务的 Sidecar
,在逻辑上为服务增加了 Envoy 的许多内置特性,例如:
动态服务发现
负载均衡
TLS 终端
HTTP/2 与 gRPC 代理
熔断器
健康检查
基于百分比流量分割的分阶段发布
故障注入
丰富的指标
Sidecar
- 允许 Istio 可以执行
策略决策
,提取丰富的遥测数据
,接着将这些数据发送到监视系统
以提供整个网格行为的信息。 - Sidecar 代理还允许
向 Istio 添加功能
,不需要重新设计架构或重写代码。
Istiod
- Istiod 提供
服务发现、配置和证书
管理。 - Istiod 将
控制流量
的高级路由规则
转换为 Envoy 特定的配置,并在运行时传播给 Sidecar。 - Istiod 安全通过内置的
身份和凭证
管理,实现了强大的服务对服务和终端用户
认证。 - Istiod 充当证书
授权(CA)
,生成证书以允许在数据平面中进行mTLS 通信
。
虚拟服务(VirtualService)
-
配置
请求流量
到服务,基于连通性和服务发现
能力。 -
每个虚拟服务包含
一组路由规则
。可以实现负载均衡
、基于不同版本流量百分比
路由。
为什么使用虚拟服务?
虚拟服务在增强 Istio 流量管理方面,发挥着至关重要的作用,通过对客户端请求与真实响应请求
的目标工作负载
进行解耦来实现。
基于不同服务版本的流量百分比
路由,实现A/B 测试、金丝雀发布
。
栗子
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v3
hosts
字段
-
虚拟服务的主机,
客户端请求
或路由规则
的目标地址。 -
虚拟服务主机名可以是
IP 地址、DNS 名称
,或者依赖于平台的一个简称
(Kubernetes 服务的短名称)也可以使用通配符(“*”)
前缀
路由规则
http
字段包含虚拟服务的路由规则
,用来描述匹配条件和路由行为
,它们把HTTP/1.1、HTTP2 和 gRPC
等流量发送到hosts
字段指定的目标
一个路由规则包含了请求要流向哪个目标地址,具有 0 或多个匹配条件,取决于您的使用场景。
匹配条件
示例中的第一个路由规则有一个条件,因此以 match
字段开始。在本例中,您希望此路由应用于来自 ”jason“ 用户
的所有请求,所以使用 headers
、end-user
和 exact
字段选择适当的请求。
- match:
- headers:
end-user:
exact: jason
Destination
-
route 部分的
destination
字段指符合此条件的流量的实际目标地址。 -
与虚拟服务的
hosts
不同,destination
的 host 必须是存在于Istio 服务注册中心
的实际目标地址,否则 Envoy 不知道该将请求发送到哪里。
route:
- destination:
host: reviews
subset: v2
destination 片段还指定了 Kubernetes 服务的子集,将符合此规则条件的请求转入其中,本例中子集名称是 v2。
路由规则优先级
路由规则按从上到下
的顺序选择,虚拟服务中定义的第一条规则有最高优先级
,不满足第一个路由规则的流量均流向一个默认的目标
。
本例中:第二条规则没有 match 条件,直接将流量导向 v3 子集。
- route:
- destination:
host: reviews
subset: v3
路由规则的更多内容
可以在流量端口、header 字段、URI 等内容上设置匹配条件
匹配条件:
目标规则(DestinationRule)
可以将虚拟服务视为将流量如何路由到目标地址,然后目标规则来配置该目标的流量。虚拟服务路由规则之后,目标规则将应用于流量的“真实”目标地址。
简单来说:虚拟服务通过目标规则后,到达目标地址(服务)
应用场景:整个目的地服务或特定服务子集时定制 Envoy 的流量策略,负载均衡模型、TLS 安全模式或熔断器设置。
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: my-destination-rule
spec:
host: my-svc
trafficPolicy:
loadBalancer:
simple: RANDOM # 随机负载均衡器
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN # 轮询负载均衡器
- name: v3
labels:
version: v3
每个子集都是基于一个或多个 labels
定义的,标签应用于kubernetes集群中deployment控制器metadata字段来识别不同版本。
负载均衡选项
Istio 默认使用轮询的负载均衡策略,Istio 同时支持如下的负载均衡模型,可以在 DestinationRule
中为指定:
- 随机:请求以随机的方式转到池中的实例。
- 权重:请求根据指定的百分比转到实例。
- 最少请求:请求被转到最少被访问的实例。
网关(Gateway)
-
管理入站和出站流量,网关配置网格边界的独立 Envoy 代理,而不是服务工作负载的 sidecar 代理。
-
Istio 网关可以配置 4-6 层的负载均衡属性,如对外暴露的端口、TLS 设置等
-
网关主要用于管理进入的流量
-
Istio 提供了预先配置的网关代理(
istio-ingressgateway
和istio-egressgateway
)
栗子
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: ext-host-gwy
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 443
name: https
protocol: HTTPS
hosts:
- ext-host.example.com
tls:
mode: SIMPLE
serverCertificate: /tmp/tls.crt
privateKey: /tmp/tls.key
这个网关配置让 HTTPS 流量从 ext-host.example.com
通过 443 端口流入网格,但没有为请求指定任何路由规则。为想要工作的网关指定路由,您必须把网关绑定到虚拟服务上。
如下面的示例所示,使用虚拟服务的 gateways
字段进行设置:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: virtual-svc
spec:
hosts:
- ext-host.example.com
gateways:
- ext-host-gwy
然后就可以为出口流量配置带有路由规则的虚拟服务。
Sidecar
默认情况下,Istio 让每个 Envoy 代理都可以访问和它关联工作负载的所有端口的请求,然后转发到对应的工作负载。
可以使用 sidecar配置做:
微调
Envoy 代理接受的端口和协议集
。限制
Envoy 代理可以访问的服务集合
。
在较庞大的应用程序中限制 sidecar 可达性
,配置每个代理能访问网格中的任意服务,可能会因为高内存使用量
而影响网格的性能。
可以指定将 sidecar 配置应用于特定命名空间中的所有工作负载,或者使用 workloadSelector
选择特定的工作负载
例如,下面的 sidecar 配置将 bookinfo
命名空间中的所有服务配置为,仅能访问运行在相同命名空间和 Istio 控制平面中的服务:
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: bookinfo
spec:
egress:
- hosts:
- "./*"
- "istio-system/*"
网络弹性和测试
除了网格导流外,Istio 还提供了故障恢复和故障注入
功能,您可以在运行时动态配置这些功能。使用这些特性可以让您的应用程序运行稳定
,确保服务网格能够容忍故障节点
,并防止局部故障级联影响到其他节点。
超时
超时是 Envoy 代理
等待来自给服务答复
的时间,确保服务不会因为等待答复而无限期的挂起
。HTTP 请求的默认超时时间
是 15 秒
,这意味着如果服务在 15 秒内没有响应,调用将失败。
为了找到最佳超时设置
,Istio 允许使用虚拟服务,按服务轻松地动态调整超时,而不必修改您的业务代码。
栗子:
一个虚拟服务,对 ratings 服务的 v1 子集的调用,指定 10 秒超时
时间
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- route:
- destination:
host: ratings
subset: v1
timeout: 10s
重试
服务为初始调用失败
,Envoy 代理
尝试连接服务的最大次数
。确保调用不会因为临时过载
的服务或网络等问题而永久失败。
重试之间的间隔(25ms+)
是可变的,HTTP 请求的默认重试行为是在返回错误之前重试两次
。
应用场景:与超时一样,Istio 默认的重试行为在延迟方面可能不适合您的应用程序需求(对失败的服务进行过多的重试会降低速度)或可用性。
栗子
配置了在初始调用失败
后,最多重试 3 次
来连接到服务子集,每个重试都有 2 秒的超时。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- route:
- destination:
host: ratings
subset: v1
retries:
attempts: 3
perTryTimeout: 2s
熔断器
熔断器中,设置一个对服务中单个主机调用的限制
,例如并发连接的数量或对该主机调用失败的次数
。一旦限制被触发,熔断器就会“跳闸”
并停止连接到该主机。
作用:使用熔断模式
可以快速失败而不必让客户端尝试连接到过载或有故障
的主机。
熔断适用于在负载均衡池
中的“真实”网格目标地址,可以在目标规则中配置熔断器阈值,让配置适用于服务中的每个主机。
栗子:
将 v1 子集的reviews
服务工作负载的并发连接数限制为 100:
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
subsets:
- name: v1
labels:
version: v1
trafficPolicy:
connectionPool:
tcp:
maxConnections: 100
故障注入
是什么:可以使用 Istio 的故障注入
机制来为整个应用程序测试故障恢复能力
。
为什么使用:故障注入是一种将错误引入系统以确保系统能够承受并从错误条件
中恢复的测试方法。
作用:使用故障注入特别有用,能确保故障恢复策略
不至于不兼容或者太严格,这会导致关键服务不可用。
可以注入两种故障,都使用虚拟服务配置:
延迟
:延迟是时间故障。它们模拟增加的网络延迟或一个超载的上游服务。终止
:终止是崩溃失败。他们模仿上游服务的失败。终止通常以 HTTP 错误码或 TCP 连接失败的形式出现。
栗子:
千分之一访问ratings
服务的请求,配置了一个 5 秒的延迟:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: ratings
spec:
hosts:
- ratings
http:
- fault:
delay:
percentage:
value: 0.1
fixedDelay: 5s
route:
- destination:
host: ratings
subset: v1
和您的应用程序一起运行
Istio 故障恢复
功能对应用程序来说是完全透明
的。在返回响应之前,应用程序不知道 Envoy sidecar 代理是否正在处理被调用服务的故障
。这意味着,如果在应用程序代码中设置了故障恢复策略,那么您需要记住这两个策略都是独立工作的,否则会发生冲突。
例如,假设您设置了两个超时,一个在虚拟服务中配置,另一个在应用程序中配置。应用程序为服务
的 API 调用设置了 2 秒超时。而您在虚拟服务
中配置了一个 3 秒超时和重试。在这种情况下,应用程序的超时会先生效,因此 Envoy 的超时和重试尝试会失效。
虽然 Istio 故障恢复特性提高了网格中服务的可靠性和可用性
,但应用程序必须处理故障或错误并采取适当的回退操作。例如,当负载均衡中的所有实例都失败时,Envoy 返回一个HTTP 503
代码。应用程序必须实现回退逻辑来处理HTTP 503
错误代码。
总结
这篇花费了不少精力,还望博友们支持支持新人!!!
后期会发布一篇实际操作,期待大家持续关注!!!
学习不走弯路,关注v「yeTechLog」
标签:负载,服务,Envoy,Istio,40,流量,路由,out 来源: https://www.cnblogs.com/yetechlog/p/16180391.html