@
目录这篇文章属于纯理论,所含内容如下,按需阅读:
Istio概念、服务网格、流量管理、istio架构(Envoy、Sidecar 、Istiod)
虚拟服务(VirtualService)、路由规则、目标规则(DestinationRule)
网关(Gateway)、网络弹性和测试(超时、重试、熔断器、故障注入)
Istio是一个开源的服务网格
,透明的接入到分布式服务
中。它也是一个平台,集成任何日志、遥测和策略系统
的 API 接口。
Istio 成功高效地运行分布式微服务架构
,并提供保护、连接和监控
微服务的统一方法。
Istio 有助于降低 DevOps
压力、开发团队
的压力。
微服务网络
服务之间的交互
服务发现、负载均衡、故障恢复、度量和监控
A/B 测试、金丝雀发布、速率限制、访问控制和端到端认证
服务网格是通过sidecar
(边车)代理服务实现,控制平面
主要是对sidecar
的配置和管理,这包括:
HTTP、gRPC、WebSocket
和 TCP 流量
自动负载均衡。路由规则、重试、故障转移和故障注入
对流量行为进行细粒度控制。访问控制、速率限制和配额
。自动化度量、日志记录
和追踪
。身份验证和授权
的集群中实现安全的服务间通信。Istio还支持扩展
,满足你部署需求!
Istio流量路由规则可以很容易的控制服务之间的流量
和API调用
。能实现A/B测试、金丝雀发布、
基于流量百分比
发布。
开箱即用的故障恢复
特性,有助于增强应用的健壮性
,从而更好地应对被依赖的服务或网络发生故障的情况。
Istio 的流量管理由Envoy
代理服务提供。网格内服务发送和接收的所有流量
都由 Envoy 代理
处理,让控制网格内的流量变得异常简单,不需要对服务做更改。
为了在网格中导流,Istio 需要知道 endpoint 在哪和属于哪个服务
。为了定位到service registry(服务注册中心)
,Istio 会连接到一个服务发现系统。例如,如果您在 Kubernetes 集群上安装了 Istio,那么它将自动检测该集群中的服务和 endpoint(端点)。
使用此服务注册中心,Envoy 代理
可以将流量定向到相关服务。大多数基于微服务的应用程序
,每个服务的工作负载都有多个实例来处理流量,称为负载均衡池
。默认情况下,Envoy 代理基于轮询调度在服务的负载均衡池内分发流量,按顺序请求发送给池中每个成员,一旦所有服务实例均接收过一次请求后,重新回到第一个池成员。
这些 API 也使用 Kubernetes 的自定义资源定义(CRDs)来声明,可以使用 YAML 进行配置
。
Istio 服务网格 逻辑上分为数据平面
和控制平面
数据平面
:Envoy代理被部署为sidecar
,负责协调和控制微服务
之间的通信,收集和报告所有网格流量的遥测数据。
控制平面
:管理并配置Envoy代理
C++ 开发
的高性能代理,用于协调服务网格中所有服务的入站和出站流量
。Envoy 代理是唯一与数据平面流量交互
的 Istio 组件。Envoy 代理被部署为服务的 Sidecar
,在逻辑上为服务增加了 Envoy 的许多内置特性,例如:
动态服务发现
负载均衡
TLS 终端
HTTP/2 与 gRPC 代理
熔断器
健康检查
基于百分比流量分割的分阶段发布
故障注入
丰富的指标
策略决策
,提取丰富的遥测数据
,接着将这些数据发送到监视系统
以提供整个网格行为的信息。向 Istio 添加功能
,不需要重新设计架构或重写代码。服务发现、配置和证书
管理。控制流量
的高级路由规则
转换为 Envoy 特定的配置,并在运行时传播给 Sidecar。身份和凭证
管理,实现了强大的服务对服务和终端用户
认证。授权(CA)
,生成证书以允许在数据平面中进行 mTLS 通信
。配置请求流量
到服务,基于连通性和服务发现
能力。
每个虚拟服务包含一组路由规则
。可以实现负载均衡
、基于不同版本流量百分比
路由。
虚拟服务在增强 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
字段指定的目标示例中的第一个路由规则有一个条件,因此以 match
字段开始。在本例中,您希望此路由应用于来自 ”jason“ 用户
的所有请求,所以使用 headers
、end-user
和 exact
字段选择适当的请求。
- match: - headers: end-user: exact: jason
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 等内容上设置匹配条件
匹配条件:
可以将虚拟服务视为将流量如何路由到目标地址,然后目标规则来配置该目标的流量。虚拟服务路由规则之后,目标规则将应用于流量的“真实”目标地址。
简单来说:虚拟服务通过目标规则后,到达目标地址(服务)
应用场景:整个目的地服务或特定服务子集时定制 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
中为指定:
管理入站和出站流量,网关配置网格边界的独立 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
然后就可以为出口流量配置带有路由规则的虚拟服务。
默认情况下,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」