青岛开发区做网站,郑州建设网,淮北建设银行官方网站,宣传网站设计一、Istio 流量管理
Istio是一个开源的服务网格#xff0c;它为分布式微服务架构提供了网络层的抽象。它使得服务之间的通信变得更为可靠、安全#xff0c;并且提供了细粒度的流量管理、监控和策略实施功能。Istio通过在服务之间插入一个透明的代理#xff08;Envoy#x…一、Istio 流量管理
Istio是一个开源的服务网格它为分布式微服务架构提供了网络层的抽象。它使得服务之间的通信变得更为可靠、安全并且提供了细粒度的流量管理、监控和策略实施功能。Istio通过在服务之间插入一个透明的代理Envoy来拦截所有网络通信从而实现这些功能。这样开发者就可以专注于业务逻辑而不必处理服务发现、负载均衡、故障恢复、安全性等网络问题。
Istio和k8s之间的关系非常紧密。它可以利用k8s的强大功能来管理和部署服务网格。当Istio部署在k8s集群中时它会自动检测到集群中的服务并为它们提供网络层的抽象。这样开发者就可以使用Istio来管理服务之间的通信同时利用k8s来管理服务的部署和扩展。这种结合使得开发者可以更容易地构建、部署和管理复杂的微服务架构。
Istio 的流量路由规则可以让您很容易的控制服务之间的流量和 API 调用。 Istio 简化了服务级别属性的配置比如熔断器、超时和重试并且能轻松的设置重要的任务 如 A/B 测试、金丝雀发布、基于流量百分比切分的分阶段发布等。它还提供了开箱即用的故障恢复特性 有助于增强应用的健壮性从而更好地应对被依赖的服务或网络发生故障的情况。
Istio的流量管理是其最核心的功能之一它能够让网络层的操作变得更加简单和灵活。以下是Istio流量管理的核心组件和概念的详细介绍 Envoy代理 Envoy是一个高性能C分布式代理专为单个服务和应用程序设计以及为大型微服务“服务网格”体系结构。它作为边车sidecar与服务容器一起部署拦截所有出入流量从而无需对服务代码进行任何更改。Envoy支持HTTP/2、gRPC 等协议并提供了断路器、异常值检测、速率限制等功能以确保网络稳定性和可靠性。 Pilot Pilot为Istio提供了服务发现功能它将服务目录中的服务配置转换为Envoy代理的配置并确保这些配置在运行时动态地分发到所有的Envoy代理。Pilot抽象了各种服务发现系统如Kubernetes、Consul等允许Istio在不同的环境中运行。 Mixer Mixer负责在服务网格中实施访问控制和使用策略。它允许服务在执行操作之前验证请求的属性并收集遥测数据如日志、指标和配额。Mixer通过适配器与后端的各种基础设施后端进行通信如Prometheus、StatsD、MySQL等。 Citadel Citadel负责Istio的安全功能包括证书管理、密钥管理以及服务之间的安全通信。它为服务网格中的工作负载提供了自动化的密钥和证书轮换确保端到端通信的安全。 Virtual Service Virtual Service是一个Istio配置资源它允许用户定义路由规则以控制服务之间的流量路由。通过Virtual Service用户可以设置条件匹配如基于路径或HTTP头并将流量重定向到不同的版本或服务。 Destination Rule Destination Rule与Virtual Service配合使用用于定义服务版本之间的流量策略例如负载均衡策略、连接池大小、熔断器设置等。 Gateway Gateway是一个Istio配置资源用于管理进出服务网格的入口和出口流量。它允许用户为服务网格配置负载均衡器以处理来自外部网络的流量。 Service Entry Service Entry用于将外部服务添加到Istio的服务目录中使网格内的服务能够访问外部服务同时仍然可以利用Istio的流量管理功能。 通过这些核心组件和概念Istio提供了一种统一的方式来管理、保护和监控微服务之间的流量从而使开发人员可以专注于业务逻辑而不是网络问题。
官方介绍文档如下 https://istio.io/latest/zh/docs/concepts/traffic-management/ 1.1 Istio 环境安装
下载 istioctl 客户端工具
curl -L https://istio.io/downloadIstio | sh -将 istioctl 客户端工具添加到环境变量
cd istio-1.21.2/
export PATH$PWD/bin:$PATH测试环境查看 istioctl 的版本
istioctl version使用 istioctl 安装 istio 环境前提当前机器中已经有了 k8s 环境。
istioctl install --set profiledemo -y其中 profile 可选项如下
default根据 IstioOperator API 的默认设置启动组件。 建议用于生产部署和 Multicluster Mesh 中的 Primary Cluster。您可以运行 istioctl profile dump 命令来查看默认设置。demo这一配置具有适度的资源需求旨在展示 Istio 的功能。 它适合运行 Bookinfo 应用程序和相关任务。 此配置文件启用了高级别的追踪和访问日志因此不适合进行性能测试。minimal与默认配置文件相同但只安装了控制平面组件。 它允许您使用 Separate Profile 配置控制平面和数据平面组件(例如 Gateway)。remote配置 Multicluster Mesh 的 Remote Cluster。empty不部署任何东西。可以作为自定义配置的基本配置文件。preview预览文件包含的功能都是实验性。这是为了探索 Istio 的新功能。不确保稳定性、安全性和性能使用风险需自负。
安装成功后查看 Istio 的 pod
kubectl get pods -n istio-system状态都为 Running 为正常可以看到安装了入口和出口网关。这两个网关实际都运行了一个 Envoy 代理实例它们在网格的边缘作为负载均衡器运行。入口网关接收入站的连接而出口网关接收从集群出去的连接。
创建一个命名空间后面所有操作均在该命名空间下操作
kubectl create ns test给该命名空间添加标签指示在部署应用的时候自动注入 Envoy 边车代理
kubectl label namespace test istio-injectionenabled1.2 Istio 环境测试
在 Istio 服务网格中可以通过 VirtualService定义流量路由规则通过 GateWay 接入流量下面使用一个案例测试环境是否正常。
启动一个 Nginx 作为服务的目标并构建了/、/buy、/order 、err 接口分别用于后面不同场景的测试
vi nginx-v1.ymlapiVersion: v1
kind: Service
metadata:name: nginx-v1namespace: testlabels:app: nginx-v1
spec:type: ClusterIPports:- port: 80targetPort: 80selector:app: nginx-v1---
apiVersion: v1
kind: ConfigMap
metadata:name: nginx-v1-confignamespace: test
data:nginx.conf: |-events {use epoll;worker_connections 65535;}http {include mime.types;server_tokens off;client_max_body_size 50m;server {listen 80;server_name localhost;proxy_buffering off;autoindex on;add_header Access-Control-Allow-Origin *;proxy_connect_timeout 1800s;proxy_send_timeout 1800s;proxy_read_timeout 1800s;location / {return 200 This is V1 Nginx.;}location /buy {return 200 This is V1 Nginx, Current Uri /buy .;}location /order {return 200 This is V1 Nginx, Current Uri /order .;}location /err {return 500 This is V1 Nginx, Current Uri /err .;}}}
---
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-v1namespace: test
spec:selector:matchLabels:app: nginx-v1replicas: 1template:metadata:labels:app: nginx-v1name: nginxversion: v1spec:containers:- name: nginx-v1image: nginx:1.20.1ports:- containerPort: 80volumeMounts:- name: nginx-configmountPath: /etc/nginx/nginx.confsubPath: nginx.confvolumes:- name: nginx-configconfigMap:name: nginx-v1-configkubectl apply -f nginx-v1.yml查看 Pod 这里有两个容器是因为一个是 sidecar 一个是 nginx 目标服务。
下面创建 Gateway 和 VirtualService 测试流量转发
vi nginx-gwvs.ymlapiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:name: nginx-gwnamespace: test
spec:selector:istio: ingressgateway # use istio default controllerservers:- port:number: 80name: httpprotocol: HTTPhosts:- *
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- * gateways: #绑定 gateway- nginx-gwhttp:- route: #路由- destination:host: nginx-v1.test.svc.cluster.localport:number: 80kubectl apply -f nginx-gwvs.yml查看入口 gateway nodeport 的端口
kubectl get svc -n istio-system访问 http://{node ip}:30868/ 通过下面指令可以查看 ingressgateway 的日志情况
kubectl logs -f -n istio-system -l istioingressgateway下面开始更详细的使用介绍。
二、VirtualService 流量管理
Istio 中的 VirtualService 是一个核心的配置资源它允许用户通过定义一组流量路由规则来控制服务网格中的数据流。这些规则可以根据请求的属性如路径、标头、查询参数等将流量路由到不同的服务版本或目的地同时支持重定向、重写、故障注入、超时、重试策略、流量镜像等功能。通过这些特性可以使得在复杂的微服务环境中实现细粒度的流量管理变得简单而灵活。
下面是 VirtualService 中的重要的配置项说明
配置项说明spec.hosts定义路由规则关联一组的 hosts可以是带有通配符的 DNS 名称或者 IP 地址。spec.gateways定义应用路由规则的来源流量可以是一个或多个网关或网格内部的 sidecar指定方式为 gateway namespace/gateway namespec.http.match定义路由的匹配规则列表单个匹配规则项内所有条件是且关系列表中多个匹配规则之间为或关系spec.http.route定义路由转发目的地列表一条 HTTP 路由可以是重定向或转发默认转发的目的地可以是一个或多个服务服务版本。同时也可以配置权重、header 操作等行为spec.http.redirect定义路由重定向一条 HTTP 路由可以是重定向或转发默认spec.http.rewrite定义重写不能与重定向同时配置重写操作会在转发前执行spec.http.timeout定义 HTTP 请求的超时时间spec.http.retries定义 HTTP 请求的重试策略spec.http.fault定义 HTTP 流量的故障注入策略开启时超时和重试策略不会开启spec.http.mirror定义将 HTTP 流量复制到另一个指定的目的端spec.http.mirrorPercent定义流量镜像的复制百分比缺省时复制100%的流量。最大值为100spec.http.corsPolicy定义 CORS 策略spec.http.headers定义 header 操作规则可以更新 request 和 response 的 header进行增加移除操作
2.1 限制请求域名
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:name: nginx-gwnamespace: test
spec:selector:istio: ingressgateway # use istio default controllerservers:- port:number: 80name: httpprotocol: HTTPhosts:- www.xbc.com
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: #绑定 gateway- nginx-gwhttp:- route: #路由- destination:host: nginx-v1.test.svc.cluster.localport:number: 80更新配置
kubectl apply -f nginx-gwvs.yml 再次使用 http://{node ip}:30868/ 访问 此时返回 404 了在 hosts 中添加域名映射
11.0.1.144 www.xbc.com使用域名后可以访问成功 2.2 match 规则匹配
支持对 uri、scheme、method、authority 类型的操作每种类型都支持 exact、prefix和regex三种模式的匹配 。
例如
2.2.1 根据 uri 前缀路由
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- uri:prefix: /buyroute:- destination:host: nginx-v1.test.svc.cluster.localport:number: 80当 uri 以 buy 为前缀时可以正常访问 如果访问 order 接口此时访问不通 2.2.2 根据 header 参数路由
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- headers:userid:exact: testroute:- destination:host: nginx-v1.test.svc.cluster.localport:number: 80只有 header 中带有 useridtest 的请求才可以访问如果不加 header 参数访问会返回 404 带上 header 参数访问可以正常访问 2.2.3 同时混合使用多种规则
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- headers:userid:exact: testuri:prefix: /buy- headers:userid:exact: adminroute:- destination:host: nginx-v1.test.svc.cluster.localport:number: 80
上面意思表示header 中 userid 的值为 test 并且 uri 的前缀是 buy 可以访问或者是 header 中 userid 的值为 admin 也可以访问。
当uri以buy为前缀但headr中userid 的值是其他时访问为 404 当uri以buy为前缀但headr中userid 的值是test时正常访问 当 uri 以 order 为前缀 header中的值是 test 时访问为 404 当 uri 以 order 为前缀 header中的值是 admin 时正常访问 2.3 route 流量转移
上面已经简单使用 route 指定目标服务了在 route 还有更多功能例如实现负载均衡、灰度发布、流量转移等等主要有三个配置destination请求目标、weight权重、和 headers其中 destination 是必须的。
这里为了方便测试目标路由再部署一个 nginx v2 版本
vi nginx-v2.ymlapiVersion: v1
kind: Service
metadata:name: nginx-v2namespace: testlabels:app: nginx-v2
spec:type: ClusterIPports:- port: 80targetPort: 80selector:app: nginx-v2---
apiVersion: v1
kind: ConfigMap
metadata:name: nginx-v2-confignamespace: test
data:nginx.conf: |-events {use epoll;worker_connections 65535;}http {include mime.types;server_tokens off;client_max_body_size 50m;server {listen 80;server_name localhost;proxy_buffering off;autoindex on;add_header Access-Control-Allow-Origin *;proxy_connect_timeout 1800s;proxy_send_timeout 1800s;proxy_read_timeout 1800s;location / {return 200 This is V2 Nginx.;}location /buy {return 200 This is V2 Nginx, Current Uri /buy .;}location /order {return 200 This is V2 Nginx, Current Uri /order .;}location /err {return 500 This is V2 Nginx, Current Uri /err .;}}}---
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-v2namespace: test
spec:selector:matchLabels:app: nginx-v2replicas: 1template:metadata:labels:app: nginx-v2name: nginxversion: v2spec:containers:- name: nginx-v2image: nginx:1.20.1ports:- containerPort: 80volumeMounts:- name: nginx-configmountPath: /etc/nginx/nginx.confsubPath: nginx.confvolumes:- name: nginx-configconfigMap:name: nginx-v2-configkubectl apply -f nginx-v2.yml2.3.1 基于权重的流量转移
通过配置 weight 参数将流量按比例分配到不同的目标服务中。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- uri:prefix: /route:- destination:host: nginx-v1.test.svc.cluster.localport:number: 80weight: 50- destination:host: nginx-v2.test.svc.cluster.localport:number: 80weight: 50上面两个版本服务各分配 50% 的流量访问应该可以感觉出负载均衡轮训的效果 2.3.2 添加/修改 header
可以添加或修改 request 或 response 中的 header 信息
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- uri:prefix: /route:- destination:host: nginx-v1.test.svc.cluster.localport:number: 80headers:response:add:test: xbcset:content-type: application/json发起请求后可以在返回的 header 中看到添加和修改的参数 2.4 redirect 重定向
可以从一个uri重定向到另一个 uri返回服务调用方 302 状态码以及 header 中 location 重定向后的地址。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- uri:prefix: /buy-v2redirect:uri: /buyroute:- destination:host: nginx-v1.test.svc.cluster.localport:number: 80 上面配置了访问 /buy-v2 的话自动重定向到 /buy 接口 2.5 rewrite 重写
和重定向配置类似但重写对用户不可见在服务端进行。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- uri:prefix: /buy-v2rewrite:uri: /buyroute:- destination:host: nginx-v1.test.svc.cluster.localport:number: 80 上面配置了访问 /buy-v2 的话自动重写到 /buy 接口 对服务调用者无感知 2.5 retries 请求重试
当请求失败时可以通过重试策略重新发起尝试以提高服务的质量。
主要包括三个参数attempts、perTryTimeout、retryOn
attempts重试的次数比需的参数。perTryTimeout重试超时时间ms、s、m、hretryOn重试策略多个以逗号分隔 策略包括 5xx服务返回5xx状态码或没有返回时。gateway-error类似于5xx异常但只针对对502、503、504 。connect-failure在连接目标服务失败时 。retriable-4xx在目标服务返回 4xx 时。refused-stream在目标服务使用REFUSED_STREAM错误码重置时。cancelledgRPC应答的Header中状态码是cancelled时。deadline-exceededgRPC应答的Header中状态码是deadline-exceeded时。internalgRPC应答的Header中状态码是internal时。resource-exhaustedgRPC应答的Header中状态码是resource-exhausted时。unavailablegRPC应答的Header中状态码是unavailable时。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- uri:prefix: /route:- destination:host: nginx-v1.test.svc.cluster.localport:number: 80 retries:attempts: 3perTryTimeout: 3sretryOn: 5xx,connect-failure上面定义了当目标服务返回 5xx 或 连接失败时进行重试一共重试3次每次重试的超时时间 3s 。
这里可以提前查看下 nginx-v1 的日志
kubectl logs -f nginx-v1-dbf758949-bhbdr -n test下面访问 /err 接口一次会返回 500 错误码
通过 nginx-v1 的日志可以看到被访问了4次其中包括重试的 3 次 。 2.6 mirror 流量镜像
流量镜像可以将流量转发到目标服务的同时也将流量给到另外一个服务非常利于新版本环境的上线前测试其配置的参数和 destination 相同
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- uri:prefix: /route:- destination:host: nginx-v1.test.svc.cluster.localport:number: 80 mirror:host: nginx-v2.test.svc.cluster.localport: number: 80上面将请求同时转发到 nginx v1 的同时也向 nginx-v2 服务发送一份请求
这里可以提前查看下 nginx-v2 的日志
kubectl logs -f nginx-v1-dbf758949-bhbdr -n test从 nginx-v2 的日志中可以看出也被请求了 2.7 故障注入
故障注入是一种服务网格中的测试手段它允许在系统中引入特定的故障以模拟网络延迟或服务中断的情况。这样做的目的是测试和提高微服务架构的弹性和稳定性确保系统能够在遇到真实世界的各种问题时仍能正确处理请求。
注意故障注入应该谨慎使用尽量在测试环境中进行以避免对生产环境造成不必要的影响。
故障注入主要包括 delay 和 abort 两种类型
delay用于模拟网络延迟或服务响应延迟。通过引入延迟可以测试服务或系统的超时处理、重试机制和整体性能。abort用于模拟服务中断通过返回特定的HTTP状态码来模拟服务失败。这可以用来测试服务的错误处理能力、断路器和其他故障恢复机制。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- uri:prefix: /route:- destination:host: nginx-v1.test.svc.cluster.localport:number: 80 fault:delay: percentage:value: 10fixedDelay: 5sabort:percentage:value: 10httpStatus: 500上面配置了 10% 的请求产生 5 秒的延时10% 的请求直接中止返回 500 状态码 2.8 跨域配置
VirtualService 提供了 allowOrigin、allowMethods、allowHeader、exposeHeader、maxAge、allowCredentials 参数来允许我们灵活的配置跨域。
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- uri:prefix: /route:- destination:host: nginx-v1.test.svc.cluster.localport:number: 80 corsPolicy:allowOrigin: - www.xbc.comallowMethods:- GET- POST- PUT- DELETEmaxAge: 24h三、 DestinationRule 流量管理策略
DestinationRule 是 Istio 服务网格中的一种配置资源它用于定义到达特定服务时的路由规则以及与该服务通信时的流量策略。DestinationRule 通常与 VirtualService 一起使用当 VirtualService 和 DestinationRule 都指定了相同的主机名和子集时生效。
下面是 DestinationRule 中的重要的配置项说明
配置项说明spec.host关联 destination.host 服务名称spec.subsets服务子集spec.trafficPolicy流量策略包括负载均衡、连接池、健康检查、TLS 策略spec.trafficPolicy.loadBalancer负载均衡算法支持轮训、最小连接、随机等spec.trafficPolicy.connectionPool连接池配置spec.trafficPolicy.outlierDetection熔断配置
下面我们将 Gateway 和 VirtualService 的配置保持指定为下面内容后面主要配置DestinationRule 的信息
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:name: nginx-gwnamespace: test
spec:selector:istio: ingressgateway # use istio default controllerservers:- port:number: 80name: httpprotocol: HTTPhosts:- www.xbc.com
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.comgateways: - nginx-gwhttp:- match:- uri:prefix: /route:- destination:host: nginx.test.svc.cluster.localport:number: 803.1 流量转移 - 负载均衡
在 k8s 中 Service 本身也提供了一种负载均衡机制而 DestinationRule 提供了更高级的负载均衡功能和流量控制方法允许对一个服务的多个版本进行流量的划分比如负载均衡中的轮询算法、最少连接算法、随机等等还可以针对不同版本转移不同权重的流量。
这里再创建一个 Service 指向 nginx-v1 和 nginx-v2 两个版本的 Pod
vi nginx-svc.ymlapiVersion: v1
kind: Service
metadata:name: nginxnamespace: testlabels:app: nginx
spec:type: ClusterIPports:- port: 80targetPort: 80selector:name: nginxkubectl apply -f nginx-svc.yml配置负载均衡主要有两种选择 simple简单负载均衡 和 consistentHash一致性Hash 算法
simple 包括
ROUND_ROBIN: 轮询默认的策略。LEAST_CONN:最少连接选择一个活动请求数相对少的目标服务。RANDOM: 随机选择一个。PASSTHROUGH:直接转发到目标服务不做任何策略。
consistentHash 包括
httpHeaderName: 基于 Header 计算 Hash。httpCookie: 基于Cookie 计算 Hash。useSourceIp:基于IP地址计算 Hash。minimumRingSize: 哈希环上虚拟节点数的最小值节点数越多则分布越均衡。
新建一个 DestinationRule 配置
vi nginx-dr.ymlapiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: nginx-drnamespace: test
spec:host: nginx.test.svc.cluster.localtrafficPolicy:loadBalancer:simple: ROUND_ROBIN #负载均衡算法subsets:- name: v1labels:version: v1- name: v2labels:version: v2kubectl apply -f nginx-dr.yml通过测试可以感觉出负载均衡的效果 3.2 流量转移 - 同一服务不同版本流量转移
上面在 VirtualService 中介绍了基于权重的流量分发但是针对不同的 host 的结合DestinationRule 可以针对一个 host 中多个版本更细力度的控制分发比如控制 80% 的流量到 v1 20% 的流量到 v2 。
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: nginx-drnamespace: test
spec:host: nginx.test.svc.cluster.localsubsets:- name: v1labels:version: v1- name: v2labels:version: v2apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:name: nginx-vsnamespace: test
spec:hosts:- www.xbc.com gateways: - nginx-gwhttp:- match:- uri:prefix: /route:- destination:host: nginx.test.svc.cluster.localport:number: 80subset: v1weight: 80- destination:host: nginx.test.svc.cluster.localport:number: 80subset: v2weight: 20可以在控制台循环10次请求
for /l %i in (1,1,10) do curl http://www.xbc.com:30868/通过结果可以看出v1 服务获得了 80% 的流量。 3.3 连接池
连接池可以用于控制发送到目标服务的连接数量包括 TCP 连接和 HTTP 连接两种。
TCP 连接参数 maxConnections: 最大连接数默认是 1024也适用 HTTP/1.1HTTP/2 会对每个主机都使用单个连接。 connectTimeout: 连接超时时间。 tcpKeepalive: Istio1.1后新支持的配置定期给对目标服务发送一个keepalive探测包判断连接是否可用。
HTTP 连接参数
http1MaxPendingRequests: 最大等待请求数默认值是 1024只适用于HTTP/1.1 的服务。http2MaxRequests: 最大请求数默认是1024。只适用于HTTP/2服务。maxRequestsPerConnection: 每个连接的最大请求数。HTTP/1.1和HTTP/2都遵循此参数。如果没有设置表示没有限制。设置为1表示每个连接只处理一个请求也就是禁用了Keep-alive 。maxRetries:最大重试次数默认是3。idleTimeout: 空闲超时在这个时间内没有活动该请求将关闭连接。
trafficPolicy 控制可以具体到某个子集
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: nginx-drnamespace: test
spec:host: nginx.test.svc.cluster.localtrafficPolicy: connectionPool: tcp:maxConnections: 1024connectTimeout: 30stcpKeepalive:probes: 5time: 3600interval: 60shttp: http1MaxPendingRequests: 2048http2MaxRequests: 2048maxRequestsPerConnection: 10maxRetries: 3idleTimeout: 60ssubsets:- name: v1labels:version: v1trafficPolicy: connectionPool: http: http1MaxPendingRequests: 1024http2MaxRequests: 1024maxRequestsPerConnection: 10maxRetries: 3idleTimeout: 60s- name: v2labels:version: v2trafficPolicy: connectionPool: http: http1MaxPendingRequests: 1024http2MaxRequests: 1024maxRequestsPerConnection: 10maxRetries: 3idleTimeout: 60s
3.2 熔断
熔断是服务网格Istio中的一种保护机制用于防止系统雪崩和确保服务稳定性。Istio熔断机制通过对服务进行实时监控当检测到某个服务出现连续失败、延迟过高或异常响应时会自动触发熔断阻止进一步的请求发送到该服务。这样可以避免无效的请求占用系统资源同时给故障服务留出恢复的时间和空间。
Istio 的熔断功能主要通过 DestinationRule 中的 outlierDetection 配置项来实现主要包括如下配置
consecutiveErrors表示在 interval 时间内如果一个服务实例连续返回错误的次数达到或超过这个值该实例将被认为是异常的并触发熔断。默认值为 5。interval用于定义 consecutiveErrors 的统计时间窗口。在这个时间窗口内如果服务实例的失败次数达到 consecutiveErrors 的阈值实例将被标记为异常。默认值为 10 秒。baseEjectionTime表示一个异常实例被驱逐的最短时间。实例被驱逐后即使它变得可用也必须等待至少这个时间才能重新加入负载均衡池。默认值为 30 秒。maxEjectionPercent用于限制在同一时间内可以被驱逐的最大实例比例。这个配置可以防止所有实例同时被驱逐从而保证服务有一定的可用性。默认值为 10%。
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:name: nginx-drnamespace: test
spec:host: nginx.test.svc.cluster.localtrafficPolicy: connectionPool: tcp:maxConnections: 100http: http1MaxPendingRequests: 100http2MaxRequests: 100outlierDetection: consecutiveErrors: 5interval: 1mbaseEjectionTime: 1mmaxEjectionPercent: 100subsets:- name: v1labels:version: v1- name: v2labels:version: v2上面配置了当在 1分钟内如何发生异常出现 5 次将进行熔断熔断时长 1分钟并且允许驱逐到全部的服务。
下面使用控制台并发访问 20次 /err 接口
for /l %i in (1,1,20) do start curl http://www.xbc.com:30868/err执行之后通过 PostMan 访问 /err 接口测试 如果此时访问其他接口/buy 也是访问不通的因为整个目标服务都被驱逐了 等待 1 分钟后再次访问接口返回正常
