Istio_02_Istio流量管理

目录

Traffic Management

流量管理(Traffic Management): 规则/策略管理服务间流量

  1. 目标: 以基础设施的方式提供非侵入的流量治理能力
  2. 流量管理依赖Kubernetes的SVC定义, 且可无服务实例
  3. Istio的服务实例由Kubernetes中的Endpoints映射解析获取
  4. 服务实例可跨Kubernetes集群, 也可是Pod中的容器和虚拟机混合

Sidecar: 服务网格动作的执行体(执行治理)

  1. Inbound/Outbound流量都需被Sidecar代理透明拦截
  2. 只有数据面的Sidecar能和控制面联系

如: Istio流量管理流程

image

  1. 通过kube-apiserver调用Istio的sidecar-injector
    • sidecar-injector负责注入Sidecar代理和Init容器
    • Init容器设置流量拦截规则、Sidecar负责透明管理流量
  2. Init容器通过Iptables规则进行流量拦截
    • Init容器需要NET_ADMIN和Net_RAW权限
    • 拦截Pod所有容器的所有Inbound/Outbound流量
  3. 数据面代理通过Istio的服务发现接口获取所有服务列表
    • 数据面代理基于控制面的服务发现接口EDS动态地更新负载均衡池
  4. 数据面代理根据配置的负责均衡策略选择并转发至服务
    • 数据面代理从Istiod中获取配置流量治理规则, 并执行治理逻辑
    • 数据面代理同时负责双向认证和通道加密等安全策略
  5. Istio通过标准的可观测性接口暴漏不同后端数据
    • 数据面代理根据请求的信息进行监控指标的统计、访问日志和调用链等
  6. Istio在服务网格的入口处Envoy扮演入口网关Ingress-gateway
  7. Istio在服务网格的出口处Envoy扮演出口网关Egress-gateway

Istio流量管理的主要特性:

(1)异常点检查(OutlierDetection): 动态监测服务并隔离故障服务

  1. 本质: 将考察时间段内连续异常次数超过阈值的服务从负载均衡池中移除
  2. 可配置移除比例, 移除数超过比例时将忽略异常点检查(保证整体可用性)
  3. 被移除的服务在隔离时间后, 再次考察服务抉择是否再次移除
  4. 请求超过配置的限制阈值, 也会快速断路请求

(2)故障注入: 服务运行阶段模拟故障

  1. 本质: 服务网格中对特定服务的应用层协议进行故障注入

(3)灰度发布: 不同版本服务按配置划分流量处理

  1. 本质: 数据面代理解析应用协议, 执行控制面的分流配置
  2. 灰度发布方案: A/B测试、蓝绿发布、金丝雀发布

(4)故障转移: 自动无缝完成故障检测和切换

  1. 本质: 数据面代理拦截对故障服务的请求, 并根据控制面的故障转移策略转发
  2. 可对服务分组进行优先级排序(Label匹配得越多优先级越高), 实现比例转发
  3. Istio倾向将流量转发至高优先级的服务, 可能低优先级都无流量

(5)出/入口流量(Egress/Ingress): 统一管理服务网格内部出/入流量

  1. 本质: Envoy代理作为出/入口网关提供七层流量接入
  2. 出/入口网关可提供高级的流量治理功能(重试、重定向和超时等)
  3. 外部服务也可通过ServiceEntry注册成为服务网格的内部服务(也需通过出口网关)

VirtualService

VirtualService(VS): 将流量路由匹配至特定服务的规则

  1. 本质: 满足条件的流量转发到实际服务后端的虚拟服务
  2. VS中根据配置顺序匹配, 匹配到规则即进行处理并结束匹配

VS常用配置清单:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: <String>
  namespace: <String>
spec:
  hosts: <[]String>       # 可路由的服务(可为DNS或IP)
  exportTo: <[]String>    # 跨NS可见性, 默认所有NS可见("."代表当前NS, "*"代表所有NS)
  http: <[]Object>        # HTTP流量处理
  - name: <String>        # 路由名称, 记录在匹配请求的访问日志中
    match: <[]Object>     # 路由匹配条件(数组之间"与", 元素之间"或")
    delegate: <Object>    # 委托其他VS处理, 不能再配置route和redirect等参数(且支持一级委派)
       name: <String>
       namespace: <String>
    route: <[]Object>       # 满足匹配条件的路由目标
    - weight: <Integer>     # 分流权重(百分比)
      headers: <Object>     # 请求头/响应头操作
      destination: <Object> # 路由目标服务
        host: <String>      # 目标服务(spec.hosts字段中指定的)
        subset: <String>    # 目标服务的子集(需在DestinationRule定义)
        port: <Object>      # 目标端口(若目标仅暴漏一个端口, 则可省略)
          number: <Integer>
  tls: <[]Object> # 非终结的TLS和HTTPS流量处理
  tcp: <[]Object> # TCP流量处理
  1. 局部配置覆盖全局配置
  2. spec.hosts以短域名形式配置时, 则解析基于VS所在的NS
  3. spec.http最为丰富的配置和规则, 另外两者配置略有差异和减少
  4. 路由匹配条件时的URI完整格式: scheme:[//[userinfo@]host[:port]]path[?query][#fragment]

HTTP、TLS、TCP路由规则对比:

对比项 HTTP TLS TCP
路由规则 HTTPRoute TLSRoute TCPRoute
流量匹配条件 HTTPMatchRequest TLSMatchAttributes L4MatchAttributes
条件属性 uri、scheme、method
authority、port、queryParams、headers
sourceLabels、sourceNamespace、gateways		 sniHosts、destinationSubnets、port
sourceLabels、sourceNamespace、gateways		 destinationSubnets、port、sourceLabels
sourceNamespace、gateways
流量操作 route、redirect、rewrite、retry
timeout、faultInjection、corsPolicy、mirror		 route route
目标路由定义 HTTPRouteDestination RouteDestination RouteDestination
目标路由属性 destination、weight、headers destination、weight destination、weight

如: VS配置模型

image


DestinationRule

DestinationRule(DR): 定义流量到达特定服务的管理规则

  1. 作用: 定义服务子集、定义流量策略
  2. 常用VS结合使用以实现: 流量路由匹配到特定服务, 并进行指定处理

DR常用配置清单:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: <String>
  namespace: <String>
spec:
  host: <String> # 适用于的服务, 需是预先在Istio服务注册中心注册的
  exportTo: <[]String>
  workloadSelector: <Object>         # 限定管理规则应用的服务
    matchLabels: <Map[String]String> # 从当前资源所在NS匹配Label后端服务端点
  trafficPolicy: <Object>            # 流量管理规则
    loadBalancer: <Object>           # 负载均衡算法配置
    connectionPool: <Object>         # 连接池配置(分为TCP和HTTP)
    outlierDetection: <Object>       # 异常点检查配置(被动型健康检查)
    portLevelSettings: <[]Object>    # 端口流量策略(单独配置端口的流量管理规则)
    tls: <Object>
  subsets: <[]Object>           # 服务子集
  - name: <string>              # 服务子集名称(可被VS引用)
    labels: <Map[String]String> # 从Istio服务注册中心匹配Label后端服务端点
    trafficPolicy: <Object>     # 流量管理规则(和上述配置相同)
  1. 局部配置覆盖全局配置
  2. spec.trafficPolicy.tls证书分为: Istio动态维护、用户手动配置

Gateway

Gateway: 服务网格的网关出/入口

  1. Gateway分为: Ingress、Egress
  2. 本质: 将规则交至特定Envoy执行, 并绑定特定VS处理流量(L7流量处理)
  3. Gateway需配合VS才能实现服务网格的出/入口流量(VS需配置spec.gateways以绑定Gateway)

DR常用配置清单:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: <String>
  namespace: <String>
spec:
  selector: <Map[String]String> # Label匹配执行规则的Envoy负载
  servers: <[]Object>           # 网关允许访问的服务列表
  - name: <String>              # 允许访问服务名称
    hosts: <[]String>           # 服务的FQDN域名(可左侧模糊匹配)
    bind: <String>              # 绑定指定IP/Socket, 常用于内部网关
    tls: <Object>
    port: <Object>       # 网关监听的端口
      name: <String>     # 端口名称
      number: <Integer>  # 端口号
      protocol: <String> # 协议
  1. spec.servers.hosts可包含NS以限定匹配指定NS下的VS, 默认匹配所有NS下的VS
  2. VS的spec.hosts需与Gateway的spec.servers.hosts能匹配, 才能实现绑定

Gateway在TLS处理常见场景分为以下5种(以入口网关举例):

场景 Gateway认证模式 Istio的角色
服务网格内部的HTTP服务直接发布 不涉及 通过Gateway发布入口处的HTTP服务
服务网格内部的HTTPS服务以HTTPS方式发布 PASSTHROUGH 通过Gateway发布入口处的HTTPS服务
(业务程序维护HTTPS相关状态)
服务网格内部的HTTP服务以HTTPS方式发布 SIMPLE Gateway与外部建立并维护HTTPS通道
内部访问仍为HTTP
服务网格内部的HTTP服务以双向HTTPS方式发布 MUTUAL Gateway与外部建立并维护双向HTTPS通道
内部访问仍为HTTP
服务网格内部的HTTP服务以HTTPS方式发布
且内部也以HTTPS方式访问		 SIMPLE Gateway与外部建立并维护HTTPS通道
终结外部TLS, 并单独维护内部HTTPS访问

Sidecar

Sidecar: 服务出入流量控制

  1. 多个Sidecar管理相同服务时, 会出现生效规则不明确问题
  2. Sidecar的精细化配置可解决大规模服务网格中数据面获取全量配置导致的内存暴涨

Sidecar常用配置清单:

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: <String>
  namespace: <String>
spec:
  workloadSelector: <Object>  # Label匹配管理的服务
  ingress: <[]Object>         # 入流量控制
  - defaultEndpoint: <String> # 流量转发的目标地址
    bind: <String>            # 监听器关联的地址
    port: <Object>            # 监听器关联的端口
    captureMode: <String>     # 流量捕获方式(DEFAULT、IPTABLES、NONE)
    connectionPool: <Object>  # 入流量的连接池配置
    tls: <Object>             # TLS配置
  egerss: <[]Object>          # 出流量控制
  - host: <String>            # 监听的服务地址
    bind: <String>
    port: <Object>
    captureMode: <String>
  inboundConnectionPool: <Object> # 入流量的连接池配置
  outboundTrafficPolicy: <Object> # 出流量策略(对服务网络外部服务访问的策略)
  1. 全局Sidecar: 省略spec.workloadSelector应用于所在NS下的所有服务, 仅能有一个
  2. 以spec.workloadSelector匹配管理服务的优先级高于全局Sidecar
  3. 监听服务地址格式(可使用通配符): NS/服务DNS
  4. 出流量策略分为: ALLO_ANY、REGISTRY_ONLY

Register

ServiceEntry

ServiceEntry(SE): 服务网格内的服务注册规则

  1. 本质: 外部服务注册为服务网格的内部服务(便于管理和访问)
  2. SE仅在服务网格注册, 需搭配WE/WG才能实现真正访问外部服务功能

SE常用配置清单:

apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: <String>
  namespace: <String>
spec:
  hosts: <[]String>     # 访问入口
  exportTo: <[]String>
  addresses: <[]String> # 非HTTP、HTTPS和TLS协议时的访问地址
  port: <[]Object>      # 访问入口的端口(访问入口为Socket时, 必须指定)
  - name: <String>
    number: <Integer>
    protocol: <String>
    targetPort: <Integer>
  endpoints: <[]Object>      # 服务实例, 与workloadSelector互斥
  workloadSelector: <Object> # 服务实例选择器, Label动态匹配
    labels: <Map[String]String>
  resolution: <String> # 服务地址解析方式(NONE、STATIC、DNS、DNS_ROUND_ROBIN)
  location: <String>   # 定义外部服务还是内部服务(MESH_EXTERNAL、MESH_INTERNAL)
  1. spec.hosts当协议为HTTP时匹配请求头的Host, 为HTTPS/TLS时匹配SNI
  2. 当协议为TCP时且创建两个相同的SE, 则默认仅先创建的SE有效

WorkloadEntry

WorkloadEntry(WE): 注册和管理固定信息的服务负载

  1. WE常与SE搭配使用, 以将外部服务注册到服务网格内访问
  2. SE可关联多个WE, 由WE权重划分各自的流量比例

WE常用配置清单:

apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
  name: <String>
  namespace: <String>
spec:
  address: <String>           # 服务端点
  labels: <Map[String]String> # 服务标签
  ports: <[]Object>           # 映射服务端口
  - name: <String>
    number: <Integer>
    protocol: <String>
    targetPort: <Integer>
  network: <String>        # 服务所在网络, 不同网络下的服务不可直接访问
  locality: <String>       # 服务在服务网格的位置
  weight: <Integer>        # 流量权重比例
  serviceAccount: <String> # 服务相关联的SA
  1. 服务相关联的SA需创建于WE和SE所在的NS下

WorkloadGroup

WorkloadGroup(WG): 自动注册的服务负载组

  1. 本质: 根据定义模板动态生产WE
  2. WG定义后提交至Istio控制面, 并由控制面动态生成WE

如: SE、WE和WG关系模型

image


WG常用配置清单:

apiVersion: networking.istio.io/v1alpha3
kind: WorkloadEntry
metadata:
  name: <String>
  namespace: <String>
spec:
  metadata: <Object> # 生成的WE元数据信息
  template: <Object> # WE模板(无需配置address和labels)
  probe: <Object>    # 存活探针
  1. spec.metadata其中的Label会自动复制为WE的Label
  2. 存活探针配置与Kubernetes相同, 且仅有通过探针的服务才可注册

posted @ 2024-08-15 10:29  爱和可乐的w  阅读(42)  评论(0)    收藏  举报