Istio学习笔记——DestinationRule解析

istio学习系列请移步：

学一下 (suxueit.com)https://suxueit.com/column/odVbfI0BWZdDRfKqh_3P/

​

一、DestinationRule介绍

DestinationRule用于管理Istio服务网格中的流量路由和负载均衡。它通常与VirtualService一起使用，共同发挥作用，将流量标记分组并路由到具体服务【将一个服务通过subset再次进行分组】。DestinationRule主要用于定义服务的负载均衡方式、服务版本选择、故障恢复策略等，以及优化服务的性能和可靠性。

DestinationRule 的CRD 的关键配置项

type DestinationRule struct {
  // 服务名称，例如 一个web服务的 service是 web-svc，
  // 这里就填 web-svc
  Host string `protobuf:"bytes,1,opt,name=host,proto3" json:"host,omitempty"`
  // 定义默认的流量策略，比如负载均衡策略、
  // 连接池设置、熔断机制，TSL等。
  TrafficPolicy *TrafficPolicy `protobuf:"bytes,2,opt,name=traffic_policy,json=trafficPolicy,proto3" json:"traffic_policy,omitempty"`
  // 定义服务的不同子集，这对于进行金丝雀发布或蓝绿部署特别有用
  // 你可以基于服务版本或其他标签定义子集。
  Subsets []*Subset `protobuf:"bytes,3,rep,name=subsets,proto3" json:"subsets,omitempty"`
  // 规则导出的命名空间，默认是导出到所有的命名空间
  ExportTo []string `protobuf:"bytes,4,rep,name=export_to,json=exportTo,proto3" json:"export_to,omitempty"`
}

二、环境准备

• 创建一个nginx和httpd的deployment，设置lable【server=web，app=nginx或者httpd】

• 创建一个service指向nginx和httpd【后面将通过子集来划分两个应用的流量】，service通过label server: web 进行选择

• 创建一个client，用于验证路由

  nginx deploymen

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  name: nginx
  namespace: test-istio
  spec:
  selector:
  matchLabels:
  app: nginx
  server: web
  replicas: 1
  template:
  metadata:
  labels:
  app: nginx
  server: web
  spec:
  containers:
  - name: nginx
  image: nginx:latest
  ports:
  - containerPort: 80

  httpd deployment

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  labels:
  app: httpd
  name: httpd
  namespace: test-istio
  spec:
  replicas: 1
  selector:
  matchLabels:
  app: httpd
  strategy:
  rollingUpdate:
  maxSurge: 25%
  maxUnavailable: 25%
  type: RollingUpdate
  template:
  metadata:
  labels:
  app: httpd
  server: web
  spec:
  containers:
  - image: httpd:latest
  name: httpd

  service

  apiVersion: v1
  kind: Service
  metadata:
  name: web-svc
  namespace: test-istio
  spec:
  ports:
  - name: port
  port: 80
  protocol: TCP
  targetPort: 80
  selector:
  server: web

  client 端

  apiVersion: apps/v1
  kind: Deployment
  metadata:
  name: client
  namespace: test-istio
  spec:
  selector:
  matchLabels:
  app: client-curl
  replicas: 1
  template:
  metadata:
  labels:
  app: client-curl
  spec:
  containers:
  - name: curl
  image: curlimages/curl:latest
  command:
  - sleep
  - "36000"
  ​

命名空间已经默认进行了 istio的sidecar注入

三、通过子集划分流量

• 创建DestinationRule，DestinationRule 通过标签app={}，选择定义不同子集

• 创建virtualService， 通过子集进行路由，并通过权重进行流量划分【httpd:nginx=9:1】

  DestinationRule

  apiVersion: networking.istio.io/v1alpha3
  kind: DestinationRule
  metadata:
  name: test-dr
  namespace: test-istio
  spec:
  host: web-svc
  subsets:
  # httpd 子集
  - name: httpd
  labels:
  app: httpd
  # nginx 子集
  - name: nginx
  labels:
  app: nginx

  virtualService

  kind: VirtualService
  metadata:
  name: web-vs
  namespace: test-istio
  spec:
  hosts:
  - web-svc
  http:
  - route:
  - destination:
  host: web-svc
  subset: nginx
  weight: 10
  - destination:
  host: web-svc
  subset: httpd
  weight: 90
  ​

连接进入client，访问 web-svc

kubectl -n test-istio  exec -it client-5677675d5-zptgz sh

可以看到流量通过子集的权重进行了划分，多次访问后，nginx：httpd的流量比基本是1：9

这里是将同一个入口的流量进行了划分，在实际应用中，可能是同一个应用的不同版本进行划分子集，【前端接口不变即可访问到不同的版本】，然后为不同版本配置流量策略，这常用于灰度发布

四、配置负载均衡

上面的示例通过 virtualService权重进行了流量分配，下面将通过 DestinationRule的TrafficPolicy进行配置，TrafficPolicy有两类策略

simple策略

• ROUND_ROBIN: 循环方式依次将请求分配给所有可用的服务实例。这是最常见的负载均衡策略之一，确保所有服务实例接收到均等的请求量。

• LEAST_CONN: 将请求分配给连接数最少的服务实例。这种策略试图确保所有服务实例的负载大致相同，适合处理时长不一的请求。

• RANDOM: 随机选择一个服务实例进行请求分配。这种策略简单且能够在一定程度上实现负载均衡。

• PASSTHROUGH: 不对流量进行任何特殊处理，直接将流量传递给目标。这通常用于TCP流量，其中负载均衡决策由客户端或下游服务处理。

consistentHash策略

consistentHash负载均衡策略用于确保具有相同散列值的请求被转发到同一服务实例，这对于会话保持非常有用。consistentHash支持以下几种方式来计算散列值：

• httpHeaderName: 使用HTTP请求头中指定字段的值来计算散列值。

• httpCookie: 使用HTTP cookie中指定名称的cookie值来计算散列值。如果请求中没有该cookie，Istio可以根据提供的ttl自动生成一个cookie。

• useSourceIp: 使用源IP地址来计算散列值，确保来自同一源IP的请求被转发到同一服务实例。

• httpQueryParameterName: 使用HTTP查询参数中指定字段的值来计算散列值

将httpd服务的副本修改为 2，并修改其中一个副本的 index.html文件

kubectl scale deployment httpd --replicas=2
# 修改其中一个pod的index.html
kubectl -n test-istio exec -it httpd-84fdd86756-scdgm
echo "test destinationRule" > htdocs/index.html

调整DestinationRule，负责均衡策略选择ROUND_ROBIN

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: test-dr
  namespace: test-istio
spec:
  host: web-svc
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN
  subsets:
  - name: httpd
    labels:
      app: httpd
  - name: nginx
    labels:
      app: nginx
​

再进行访问

注意：负载均衡，是针对子集内的实例进行，而不是对子集进行负载均衡，例如 有子集 nginx和httpd，设置的负载均衡不是 让负载再nginx和httpd进行，而是作用于子集内部的实例，例如上面演示的httpd子集内的两个实例

最外层设置的策略会作用于所有的子集，当然也可以为子集单独设置流量策略

例如：子集内设置的策略会覆盖上一层的策略

五、TrafficPolicy其他配置

• 连接池(ConnectionPool): 定义了TCP和HTTP连接池的大小和超时，用于控制与服务实例的连接。

  • TCP: 可以配置最大连接数、连接超时等。

  • HTTP: 可以配置HTTP1/HTTP2的最大请求数、请求超时等。

• 断路器(OutlierDetection): 定义了断路器的规则，如检测到多少次连续错误后将实例从负载均衡池中剔除，以及剔除的持续时间。

• TLS设置: 配置流量的TLS要求，包括是否启用自动mTLS。

  apiVersion: networking.istio.io/v1alpha3
  kind: DestinationRule
  metadata:
  name: my-service-destination-rule
  spec:
  host: my-service
  trafficPolicy:
  loadBalancer:
  simple: ROUND_ROBIN
  connectionPool:
  tcp:
  maxConnections: 100
  connectTimeout: 30ms
  http:
  # 等待排队的最大请求数
  http1MaxPendingRequests: 10
  # 最大请求数
  http2MaxRequests: 100
  # 每个连接到后端的最大请求数。将此参数设置为1将禁用保活。默认为0，表示"无限制"，
  maxRequestsPerConnection: 10
  maxRetries: 3
  outlierDetection:
  # 连续错误5次，将把实例从负载次中剔除
  consecutiveErrors: 5
  # 剔除后下次扫描的间隔时间
  interval: 1m
  # 每次剔除实例的时间
  baseEjectionTime: 15m
  # 可以剔除的实例百分比
  maxEjectionPercent: 50
  # 当健康实例低于改值时，outlierDetection将被禁用
  minHealthPercent: 30
  tls:
  mode: ISTIO_MUTUAL # 自动双向TLS

• PortLevelSettings允许你为指定端口上的流量定义不同的策略，如负载均衡策略、连接池大小、断路器参数等。这对于服务监听多个端口，且不同端口上的流量特性不同的情况特别有用。

  trafficPolicy:
  portLevelSettings:
  - port:
  number: 8080
  loadBalancer:
  simple: ROUND_ROBIN
  connectionPool:
  http:
  http1MaxPendingRequests: 10
  maxRequestsPerConnection: 100
  - port:
  number: 9090
  loadBalancer:
  simple: LEAST_CONN
  connectionPool:
  http:
  http2MaxRequests: 100
  maxRetries: 5

​

• Tunnel设置在Istio 1.10及更高版本中引入，它允许在两个服务间建立一个隧道，通过隧道传输流量。目前支持的隧道类型包括H2TUNNEL和CONNECT，这可以用于优化和保护服务间的流量。

  使用隧道可以在服务间建立一个稳定的连接，通过这个连接传输加密的流量。这对于需要保护数据或优化长连接的场景非常有用

  配置在使用时需要考虑目标服务的支持情况，因为并不是所有的服务都能支持通过隧道传输的流量。

参考：

Istio / Destination Rule