@[toc]前言本文纯理论，内容如下。点播阅读：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需要知道端点在哪里以及它属于哪个服务。为了找到服务注册表，Istio连接到服务发现系统。例如，如果您在Kubernetes集群上安装Istio，它将自动检测该集群中的服务和端点。使用此服务注册表，Envoy代理可以将流量定向到相关服务。在大多数基于微服务的应用程序中，每个服务工作负载都有多个实例来处理流量，称为负载平衡池。默认情况下，Envoy代理根据循环调度在服务的负载均衡池中分配流量，按顺序向池中的每个成员发送请求，并在所有服务实例都收到请求后返回到第一个池成员。这些API也使用Kubernetes自定义资源定义(CRD)声明，可以使用YAML配置。istio架构Istio服务网格在逻辑上分为数据平面和控制平面数据平面：Envoyproxy作为sidecar部署，负责协调和控制微服务之间的通信，收集和上报所有网格流量的遥测数据。控制平面：管理和配置Envoy代理EnvoyC++开发了一个高性能代理，用于协调服务网格中所有服务的入站和出站流量。Envoy代理是唯一与数据平面流量交互的Istio组件。Envoy代理部署为服务的sidecar，逻辑上为服务增加了很多Envoy内置的特性，例如：动态服务发现负载均衡TLS终端HTTP/2和gRPC代理断路器健康检查分阶段发布失败关于百分比流量拆分将丰富的指标注入sidecar允许Istio执行策略决策，提取丰富的遥测数据，然后将此数据发送到监控系统以提供有关整个网格行为的信息。Sidecar代理还允许向Istio添加功能，而无需重新架构或重写代码。IstiodIstiod提供服务发现、配置和证书管理。Istiod将管理流量的高级路由规则转换为特定于Envoy的配置，这些配置在运行时传播到边车。IstiodSecurity通过内置身份和凭证管理实现强大的服务到服务和最终用户身份验证。Istiod充当证书颁发机构(CA)，生成证书以允许在数据平面中进行mTLS通信。虚拟服务（VirtualService）根据连接和服务发现能力配置请求流量到服务。每个虚拟服务都包含一组路由规则。可以根据不同版本的流量百分比实现负载均衡和路由。为什么要使用虚拟服务？虚拟服务通过将客户端请求与响应请求的实际目标工作负载分离，在增强Istio流量管理方面发挥着至关重要的作用。根据不同服务版本的流量百分比进行路由，实现A/B测试和金丝雀发布。ChestnutapiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:reviewsspec:hosts:-reviewshttp:-match:-headers:end-user:exact:jasonroute:-destination:host:reviewssubset:v2-路由：-destination:host:reviewssubset:v3hosts字段是虚拟服务的主机，客户端请求或路由规则的目标地址。虚拟服务主机名可以是IP地址、DNS名称或平台相关的短名称（Kubernetes服务的短名称），也可以使用通配符（“*”）作为前缀。routingrulehttp字段包含虚拟服务的路由规则，描述匹配条件和路由行为，将HTTP/1.1、HTTP2、gRPC等流量发送到hosts字段指定的目标。一条路由规则包含请求应该流向哪个目标地址，有0个或多个匹配条件，取决于你的使用场景。匹配条件示例中的第一条路由规则具有条件，因此以匹配字段开头。在此示例中，您希望此路由应用于来自“jason”用户的所有请求，因此使用标头、最终用户和确切字段来选择适当的请求。-match:-headers:end-user:exact:jasonDestinationroute部分的目标字段是指匹配此条件的流量的实际目标地址。与虚拟服务主机不同，目标主机必须是存在于Istio服务注册表中的实际目标地址，否则Envoy将不知道将请求发送到哪里。route:-destination:host:reviewssubset:v2destination片段还指定了Kubernetes服务的子集，满足此规则条件的请求将转移到该子集。在此示例中，子集名称是v2。路由规则优先级路由规则按照从上到下的顺序被选择。虚拟服务中定义的第一条规则具有最高优先级，不满足第一条路由规则的流量将流向默认目的地。在此示例中：第二条规则没有匹配条件，直接将流量定向到v3子集。-route:-destination:host:reviewssubset:更多v3路由规则内容可以在流量端口、头字段、URI等上设置匹配条件匹配条件：目的地规则（DestinationRule）可以把虚拟服务当作流量如何路由到目标地址，然后是目标规则以配置该目标的流量。在虚拟服务路由规则之后，目标规则将应用于流量的“真实”目标地址。简单来说：虚拟服务通过目标规则后，到达目标地址（服务）应用场景：为整个目的服务或特定服务定制Envoy的流量策略、负载均衡模型、TLS安全模式或断路器设置子集。apiVersion:networking.istio.io/v1alpha3kind:DestinationRulemetadata:name:my-destination-rulespec:host:my-svctrafficPolicy:loadBalancer:simple:RANDOM#随机负载均衡器子集:-name:v1labels:version:v1-name:v2labels:version:v2trafficPolicy:loadBalancer:simple:ROUND_ROBIN#Roundrobinloadbalancer-name:v3labels:version:v3的每个子集都基于一个或多个标签定义，标签应用于kubernetes中的部署clusterController元数据字段来标识不同的版本。负载均衡选项Istio默认使用循环负载均衡策略。Istio还支持以下负载均衡模型，可以在DestinationRule中指定：Random：请求随机转移到池中的实例。权重：请求根据指定的百分比转到实例。最少请求：请求被路由到访问最少的实例。网关（Gateway）管理入站和出站流量。Gateway在网格边缘配置独立的Envoy代理，而不是服务于工作负载的sidecar代理。Istio网关可以配置4-6层的负载均衡属性，比如对外暴露的端口、TLS设置等。网关主要用于管理传入的流量。Istio提供预配置的网关代理（istio-ingressgateway和istio-egressgateway）栗子apiVersion:networking.istio.io/v1alpha3kind:Gatewaymetadata:name:ext-host-gwyspec:selector:istio:ingressgateway#使用istio默认控制器服务器：-端口：编号：443名称：https协议：HTTPS主机：-ext-host.example.comtls：模式：SIMPLEserverCertificate：/tmp/tls.crtprivateKey：/tmp/tls.key此网关配置允许来自ext的HTTPS流量-host.example.com在端口443上流入网格，但不指定任何路由规则。要指定网关工作的路由，您必须将网关绑定到虚拟服务。使用虚拟服务的网关字段设置，如下例所示：apiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:virtual-svcspec:hosts:-ext-host.example.comgateways:-ext-host-gwy然后你可以为出口流量配置一个带有路由规则的虚拟服务。Sidecar默认情况下，Istio允许每个Envoy代理访问与其工作负载关联的所有端口的请求，然后将它们转发到相应的工作负载。您可以使用sidecar配置做什么：微调Envoy代理接受的端口和协议集。限制Envoy代理可以访问的服务集。限制大型应用程序中的sidecar可达性，将每个代理配置为能够访问网格中的任何服务，可能会由于高内存使用率而影响网格性能。您可以指定sidecar配置应用于特定命名空间中的所有工作负载，或使用workloadSelector选择特定工作负载。例如，以下sidecar配置将bookinfo命名空间中的所有服务配置为只能访问在同一命名空间中运行的服务和Istio控制平面中的服务：apiVersion:networking.istio.io/v1alpha3kind:Sidecarmetadata:name:defaultnamespace:bookinfospec:egress:-hosts:-"./*"-"istio-system/*"网络弹性和测试除了网格导流之外，Istio还提供了故障恢复和故障注入能力，你可以在运行时动态配置。使用这些功能可以使您的应用程序稳定，确保服务网格可以容忍故障节点，并防止局部故障级联到其他节点。超时超时是Envoy代理等待服务回复的时间，确保服务不会无限期挂起等待回复。HTTP请求的默认超时时间是15秒，这意味着如果服务在15秒内没有响应，调用就会失败。为了找到最佳的超时设置，Istio允许使用虚拟服务在每个服务的基础上轻松动态地调整超时，而无需修改您的业务代码。Chestnut：一个虚拟服务，调用ratings服务的v1子集，指定超时时间为10秒:ratingssubset:v1timeout:10s如果初始调用失败，Envoy代理将尝试连接服务的最大次数。确保通话不会因临时超载服务或网络问题而永久失败。重试间隔(25ms+)是可变的，HTTP请求的默认重试行为是在返回错误之前重试两次。用例：与超时一样，Istio的默认重试行为可能不适合您的应用程序在延迟（失败服务的重试次数过多会减慢）或可用性方面的需求。Chestnut配置为在初始调用失败后最多重试3次以连接到服务子集，每次重试有2秒超时。apiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:ratingsspec:hosts:-ratingshttp:-route:-destination:host:ratingssubset:v1retries:attempts:3perTryTimeout:2sfuse熔断，设置一个限制在对服务中单个主机的调用，例如并发连接数或对该主机的失败调用数。一旦触发限制，保险丝就会“跳闸”并停止连接到该主机。作用：使用断路器模式快速失败，而无需客户端尝试连接到过载或故障主机。断路器适用于负载均衡池中“真实”的网格目标地址，可以在目标规则中配置断路器阈值，使配置适用于服务中的每台主机。栗子：限制v1子集的reviews服务工作负载并发连接数为100：apiVersion:networking.istio.io/v1alpha3kind:DestinationRulemetadata:name:reviewsspec:host:reviewssubsets:-name:v1labels:version:v1trafficPolicy:connectionPool:tcp:maxConnections:100什么是故障注入：Istio的故障注入机制可以用来测试整个应用的故障恢复能力。为什么使用：故障注入是一种将错误引入系统以确保系统能够承受错误情况并从中恢复的测试方法。作用：使用故障注入对于确保故障恢复策略不会不兼容或过于严格会导致关键服务不可用特别有用。可以注入两种类型的故障，均使用虚拟服务进行配置：延迟：延迟是一种时间故障。它们模拟增加的网络延迟或过载的上游服务。终止：终止是崩溃失败。它们模仿上游服务的故障。终止通常以HTTP错误代码或TCP连接失败的形式出现。栗子：千分之一请求访问ratings服务，配置5秒延迟：apiVersion:networking.istio.io/v1alpha3kind:VirtualServicemetadata:name:ratingsspec:hosts:-ratingshttp:-fault:delay:percentage:value:0.1fixedDelay:5sroute:-destination:host:ratingssubset:v1使用你的应用程序运行Istio故障转移功能对应用程序是完全透明的。在返回响应之前，应用程序不知道Envoysidecar代理是否正在处理被调用服务的故障。这意味着如果您在应用程序代码中设置了故障恢复策略，您需要记住这两个策略是独立工作的，否则就会发生冲突。例如，假设您设置了两个超时，一个在虚拟服务中配置，另一个在应用程序中配置。应用程序为服务的API调用设置2秒超时。相反，您在虚拟服务中配置了3秒超时并重试。在这种情况下，应用程序的超时首先生效，因此Envoy的超时和重试尝试失败。虽然Istio的故障转移功能提高了网格中服务的可靠性和可用性，但应用程序必须处理故障或错误并采取适当的回退操作。例如，当负载均衡器中的所有实例都失败时，Envoy会返回一个HTTP503代码。应用程序必须实施回退逻辑来处理HTTP503错误代码。花了很多精力总结这篇文章，希望博主多多支持，支持新人！！！稍后会放出实战操作，期待您的持续关注！！！学习不走弯路，关注v「yeTechLog」
