[Istio是什么？] 还不知道你就out了,一文40分钟快速理解

@toc

这篇文章属于纯理论，所含内容如下，按需阅读：

服务网格是通过sidecar（边车）代理服务实现，控制平面主要是对sidecar的配置和管理，这包括：

Istio还支持扩展，满足你部署需求！

为了在网格中导流，Istio 需要知道 endpoint 在哪和属于哪个服务。为了定位到service registry(服务注册中心)，Istio 会连接到一个服务发现系统。例如，如果您在 Kubernetes 集群上安装了 Istio，那么它将自动检测该集群中的服务和 endpoint（端点）。

使用此服务注册中心，Envoy 代理可以将流量定向到相关服务。大多数基于微服务的应用程序，每个服务的工作负载都有多个实例来处理流量，称为负载均衡池。默认情况下，Envoy 代理基于轮询调度在服务的负载均衡池内分发流量，按顺序请求发送给池中每个成员，一旦所有服务实例均接收过一次请求后，重新回到第一个池成员。

这些 API 也使用 Kubernetes 的自定义资源定义（CRDs）来声明，可以使用 YAML 进行配置。

Istio 服务网格 逻辑上分为数据平面和控制平面

在这里插入图片描述

Envoy 代理被部署为服务的 Sidecar，在逻辑上为服务增加了 Envoy 的许多内置特性，例如：

虚拟服务在增强 Istio 流量管理方面，发挥着至关重要的作用，通过对客户端请求与真实响应请求的目标工作负载进行解耦来实现。

基于不同服务版本的流量百分比路由，实现A/B 测试、金丝雀发布。

<code class="shell">apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: reviewsspec:  hosts:  - reviews  http:  - match:    - headers:        end-user:          exact: jason    route:    - destination:        host: reviews        subset: v2  - route:    - destination:        host: reviews        subset: v3</code>

**hosts字段**

一个路由规则包含了请求要流向哪个目标地址，具有 0 或多个匹配条件，取决于您的使用场景。

示例中的第一个路由规则有一个条件，因此以 match 字段开始。在本例中，您希望此路由应用于来自”jason“ 用户的所有请求，所以使用 headers、end-user 和 exact 字段选择适当的请求。

<code class="shell">- match:   - headers:       end-user:         exact: jason</code>

<code class="shell">route:- destination:    host: reviews    subset: v2</code>

destination 片段还指定了 Kubernetes 服务的子集，将符合此规则条件的请求转入其中，本例中子集名称是 v2。

路由规则按从上到下的顺序选择，虚拟服务中定义的第一条规则有最高优先级，不满足第一个路由规则的流量均流向一个默认的目标。

本例中：第二条规则没有 match 条件，直接将流量导向 v3 子集。

<code class="shell">- route:  - destination:      host: reviews      subset: v3</code>

可以在流量端口、header 字段、URI 等内容上设置匹配条件

匹配条件：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

可以将虚拟服务视为将流量如何路由到目标地址，然后目标规则来配置该目标的流量。虚拟服务路由规则之后，目标规则将应用于流量的“真实”目标地址。

简单来说：虚拟服务通过目标规则后，到达目标地址（服务）

应用场景：整个目的地服务或特定服务子集时定制 Envoy 的流量策略，负载均衡模型、TLS 安全模式或熔断器设置。

<code class="shell">apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata:  name: my-destination-rulespec:  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</code>

每个子集都是基于一个或多个 labels 定义的，标签应用于kubernetes集群中deployment控制器metadata字段来识别不同版本。

Istio 默认使用轮询的负载均衡策略，Istio 同时支持如下的负载均衡模型，可以在 DestinationRule 中为指定：

<code class="shell">apiVersion: networking.istio.io/v1alpha3kind: Gatewaymetadata:  name: ext-host-gwyspec:  selector:    istio: ingressgateway  # use istio default controlle  servers:  - port:      number: 443      name: https      protocol: HTTPS    hosts:    - ext-host.example.com    tls:      mode: SIMPLE      serverCertificate: /tmp/tls.crt      privateKey: /tmp/tls.key</code>

这个网关配置让 HTTPS 流量从 ext-host.example.com 通过 443 端口流入网格，但没有为请求指定任何路由规则。为想要工作的网关指定路由，您必须把网关绑定到虚拟服务上。

如下面的示例所示，使用虚拟服务的 gateways 字段进行设置：

<code class="shell">apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: virtual-svcspec:  hosts:  - ext-host.example.com  gateways:    - ext-host-gwy</code>

然后就可以为出口流量配置带有路由规则的虚拟服务。

默认情况下，Istio 让每个 Envoy 代理都可以访问和它关联工作负载的所有端口的请求，然后转发到对应的工作负载。

可以使用 sidecar配置做：

在较庞大的应用程序中限制 sidecar 可达性，配置每个代理能访问网格中的任意服务，可能会因为高内存使用量而影响网格的性能。

知了zKnown

知了zKnown：致力于信息降噪 / 阅读提效的个人知识助手。

65

查看详情

可以指定将 sidecar 配置应用于特定命名空间中的所有工作负载，或者使用 workloadSelector 选择特定的工作负载

例如，下面的 sidecar 配置将 bookinfo 命名空间中的所有服务配置为，仅能访问运行在相同命名空间和 Istio 控制平面中的服务：

<code class="shell">apiVersion: networking.istio.io/v1alpha3kind: Sidecametadata:  name: default  namespace: bookinfospec:  egress:  - hosts:    - "./\*"    - "istio-system/\*"</code>

除了网格导流外，Istio 还提供了故障恢复和故障注入功能，您可以在运行时动态配置这些功能。使用这些特性可以让您的应用程序运行稳定，确保服务网格能够容忍故障节点，并防止局部故障级联影响到其他节点。

超时是 Envoy 代理等待来自给服务答复的时间，确保服务不会因为等待答复而无限期的挂起。HTTP 请求的默认超时时间是15 秒，这意味着如果服务在 15 秒内没有响应，调用将失败。

为了找到最佳超时设置，Istio 允许使用虚拟服务，按服务轻松地动态调整超时，而不必修改您的业务代码。

栗子：

一个虚拟服务，对 ratings 服务的 v1 子集的调用，指定 10 秒超时时间

<code class="shell">apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: ratingsspec:  hosts:  - ratings  http:  - route:    - destination:        host: ratings        subset: v1    timeout: 10s</code>

服务为初始调用失败，Envoy 代理尝试连接服务的最大次数。确保调用不会因为临时过载的服务或网络等问题而永久失败。

重试之间的间隔（25ms+）是可变的，HTTP 请求的默认重试行为是在返回错误之前重试两次。

应用场景：与超时一样，Istio 默认的重试行为在延迟方面可能不适合您的应用程序需求（对失败的服务进行过多的重试会降低速度）或可用性。

配置了在初始调用失败后,最多重试 3 次来连接到服务子集，每个重试都有 2 秒的超时。

<code class="shell">apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: ratingsspec:  hosts:  - ratings  http:  - route:    - destination:        host: ratings        subset: v1    retries:      attempts: 3      perTryTimeout: 2s</code>

熔断器中，设置一个对服务中单个主机调用的限制，例如并发连接的数量或对该主机调用失败的次数。一旦限制被触发，熔断器就会“跳闸”并停止连接到该主机。

作用：使用熔断模式可以快速失败而不必让客户端尝试连接到过载或有故障的主机。

熔断适用于在负载均衡池中的“真实”网格目标地址，可以在目标规则中配置熔断器阈值，让配置适用于服务中的每个主机。

栗子：

将 v1 子集的reviews服务工作负载的并发连接数限制为 100：

<code class="shell">apiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata:  name: reviewsspec:  host: reviews  subsets:  - name: v1    labels:      version: v1    trafficPolicy:      connectionPool:        tcp:          maxConnections: 100</code>

是什么：可以使用 Istio 的故障注入机制来为整个应用程序测试故障恢复能力。

为什么使用：故障注入是一种将错误引入系统以确保系统能够承受并从错误条件中恢复的测试方法。

作用：使用故障注入特别有用，能确保故障恢复策略不至于不兼容或者太严格，这会导致关键服务不可用。

可以注入两种故障，都使用虚拟服务配置：

栗子：

千分之一访问ratings 服务的请求，配置了一个 5 秒的延迟：

<code class="shell">apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:  name: ratingsspec:  hosts:  - ratings  http:  - fault:      delay:        percentage:          value: 0.1        fixedDelay: 5s    route:    - destination:        host: ratings        subset: v1</code>

Istio 故障恢复功能对应用程序来说是完全透明的。在返回响应之前，应用程序不知道 Envoy sidecar 代理是否正在处理被调用服务的故障。这意味着，如果在应用程序代码中设置了故障恢复策略，那么您需要记住这两个策略都是独立工作的，否则会发生冲突。

例如，假设您设置了两个超时，一个在虚拟服务中配置，另一个在应用程序中配置。应用程序为服务的 API 调用设置了 2 秒超时。而您在虚拟服务中配置了一个 3 秒超时和重试。在这种情况下，应用程序的超时会先生效，因此 Envoy 的超时和重试尝试会失效。

虽然 Istio 故障恢复特性提高了网格中服务的可靠性和可用性，但应用程序必须处理故障或错误并采取适当的回退操作。例如，当负载均衡中的所有实例都失败时，Envoy 返回一个HTTP 503代码。应用程序必须实现回退逻辑来处理HTTP 503错误代码。

这篇花费了不少精力，还望博友们支持支持新人！！！

后期会发布一篇实际操作，期待大家持续关注！！！

学习不走弯路，关注v「yeTechLog」

以上就是[Istio是什么？] 还不知道你就out了,一文40分钟快速理解的详细内容，更多请关注php中文网其它相关文章！