关于istio:Istio是什么-还不知道你就out了一文40分钟快速理解

@[toc]

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

Istio 概念、服务网格、流量治理、istio 架构（Envoy、Sidecar、Istiod）
虚构服务(VirtualService)、路由规定、指标规定(DestinationRule)
网关(Gateway)、网络弹性和测试（超时、重试、熔断器、故障注入）

Istio 是什么？
Istio 是一个开源的 服务网格 ，通明的接入到 分布式服务 中。它也是一个平台，集成任何 日志、遥测和策略零碎 的 API 接口。
Istio 胜利高效地运行 散布式微服务架构 ，并提供 爱护、连贯和监控 微服务的对立办法。
Istio 有助于升高 DevOps 压力、开发团队 的压力。

组成 微服务网络
实现 服务之间的交互

服务发现、负载平衡、故障复原、度量和监控
A/B 测试、金丝雀公布、速率限度、访问控制和端到端认证

服务网格是通过 sidecar（边车）代理服务实现， 管制立体 次要是对 sidecar 的配置和治理，这包含：

为 HTTP、gRPC、WebSocket 和 TCP 流量 主动负载平衡。
通过丰盛的 路由规定、重试、故障转移和故障注入 对流量行为进行细粒度管制。
可插拔的策略层和配置 API，反对 访问控制、速率限度和配额。
集群内（包含集群的入口和进口）所有流量的 自动化度量、日志记录 和追踪。
在具备弱小的基于 身份验证和受权 的集群中实现平安的服务间通信。

Istio 还 反对扩大，满足你部署需要！

Istio 流量路由规定能够很容易的 管制服务之间的流量 和API 调用 。能实现A/ B 测试、金丝雀公布、 基于 流量百分比 公布。
开箱即用的 故障复原 个性，有助于 加强利用的健壮性，从而更好地应答被依赖的服务或网络产生故障的状况。
Istio 的流量治理由 Envoy 代理服务提供。网格内服务 发送和接管的所有流量 都由 Envoy 代理 解决，让管制网格内的流量变得异样简略，不须要对服务做更改。

为了在网格中导流，Istio 须要晓得 endpoint 在哪和属于哪个服务。为了定位到service registry(服务注册核心)，Istio 会连贯到一个服务发现零碎。例如，如果您在 Kubernetes 集群上装置了 Istio，那么它将自动检测该集群中的服务和 endpoint（端点）。

应用此服务注册核心，Envoy 代理 能够将流量定向到相干服务。大多数基于 微服务的应用程序 ，每个服务的工作负载都有多个实例来解决流量，称为 负载平衡池。默认状况下，Envoy 代理基于轮询调度在服务的负载平衡池内散发流量，按程序申请发送给池中每个成员，一旦所有服务实例均接管过一次申请后，从新回到第一个池成员。

这些 API 也应用 Kubernetes 的自定义资源定义（CRDs）来申明，能够 应用 YAML 进行配置。

Istio 服务网格逻辑上分为 数据立体 和管制立体

数据立体 ：Envoy 代理被部署为sidecar，负责 协调和管制微服务 之间的通信，收集和报告所有网格流量的遥测数据。
管制立体：治理并配置Envoy 代理

Envoy
C++ 开发 的高性能代理，用于协调服务网格中所有服务的 入站和出站流量 。Envoy 代理是 惟一与数据立体流量交互 的 Istio 组件。

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

动静服务发现
负载平衡
TLS 终端
HTTP/2 与 gRPC 代理
熔断器
健康检查
基于百分比流量宰割的分阶段公布
故障注入
丰盛的指标

容许 Istio 能够执行 策略决策 ，提取丰盛的 遥测数据 ，接着将这些数据发送到 监视系统 以提供整个网格行为的信息。
Sidecar 代理还容许 向 Istio 增加性能，不须要从新设计架构或重写代码。

Istiod 提供 服务发现、配置和证书 治理。
Istiod 将 管制流量 的高级路由规定 转换为 Envoy 特定的配置，并在运行时流传给 Sidecar。
Istiod 平安通过内置的 身份和凭证 治理，实现了弱小的 服务对服务和终端用户 认证。
Istiod 充当证书 受权（CA），生成证书以容许在数据立体中进行 mTLS 通信。

虚构服务(VirtualService)
配置 申请流量 到服务, 基于 连通性和服务发现 能力。
每个虚构服务蕴含 一组路由规定 。能够实现 负载平衡 、基于 不同版本流量百分比 路由。

虚构服务在加强 Istio 流量治理方面，施展着至关重要的作用，通过对 客户端申请与实在响应申请 的指标工作负载 进行解耦来实现。
基于不同服务版本的 流量百分比 路由，实现A/B 测试、金丝雀公布。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

hosts字段

虚构服务的主机，客户端申请 或路由规定 的指标地址。
虚构服务主机名能够是 IP 地址、DNS 名称 ，或者依赖于 平台的一个简称 （Kubernetes 服务的短名称）也能够应用通配符（“*”） 前缀

http 字段蕴含虚构服务的 路由规定 ，用来形容 匹配条件和路由行为 ，它们把 HTTP/1.1、HTTP2 和 gRPC 等流量发送到 hosts 字段指定的指标
一个路由规定蕴含了申请要流向哪个指标地址，具备 0 或多个匹配条件，取决于您的应用场景。

示例中的第一个路由规定有一个条件，因而以 match 字段开始。在本例中，您心愿此路由利用于来自 ”jason“用户 的所有申请，所以应用 headers、end-user 和 exact 字段抉择适当的申请。

- match:
   - headers:
       end-user:
         exact: jason

route 局部的 destination 字段指合乎此条件的流量的理论指标地址。
与虚构服务的 hosts 不同，destination 的 host 必须是存在于 Istio 服务注册核心 的理论指标地址，否则 Envoy 不晓得该将申请发送到哪里。

route:
- destination:
    host: reviews
    subset: v2

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

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

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

- route:
  - destination:
      host: reviews
      subset: v3

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

匹配条件：

能够将虚构服务视为将流量如何路由到指标地址，而后指标规定来配置该指标的流量。虚构服务路由规定之后，指标规定将利用于流量的“实在”指标地址。

简略来说：虚构服务通过指标规定后，达到指标地址（服务）

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

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
spec:
  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

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

Istio 默认应用轮询的负载平衡策略，Istio 同时反对如下的负载平衡模型，能够在 DestinationRule 中为指定：

随机：申请以随机的形式转到池中的实例。
权重：申请依据指定的百分比转到实例。
起码申请：申请被转到起码被拜访的实例。

网关(Gateway)
治理入站和出站流量，网关配置网格边界的独立 Envoy 代理，而不是服务工作负载的 sidecar 代理。
Istio 网关能够配置 4-6 层的负载平衡属性，如对外裸露的端口、TLS 设置等
网关次要用于治理进入的流量
Istio 提供了事后配置的网关代理（istio-ingressgateway 和 istio-egressgateway）

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: ext-host-gwy
spec:
  selector:
    istio: ingressgateway  # use istio default controller
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - ext-host.example.com
    tls:
      mode: SIMPLE
      serverCertificate: /tmp/tls.crt
      privateKey: /tmp/tls.key

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

如上面的示例所示，应用虚构服务的 gateways 字段进行设置：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: virtual-svc
spec:
  hosts:
  - ext-host.example.com
  gateways:
    - ext-host-gwy

而后就能够为进口流量配置带有路由规定的虚构服务。

默认状况下，Istio 让每个 Envoy 代理都能够拜访和它关联工作负载的所有端口的申请，而后转发到对应的工作负载。

能够应用 sidecar 配置做：

微调 Envoy 代理承受的 端口和协定集。
限度 Envoy 代理能够 拜访的服务汇合。

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

能够指定将 sidecar 配置利用于特定命名空间中的所有工作负载，或者应用 workloadSelector 抉择特定的工作负载

例如，上面的 sidecar 配置将 bookinfo 命名空间中的所有服务配置为，仅能拜访运行在雷同命名空间和 Istio 管制立体中的服务：

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: default
  namespace: bookinfo
spec:
  egress:
  - hosts:
    - "./*"
    - "istio-system/*"

除了网格导流外，Istio 还提供了 故障复原和故障注入 性能，您能够在运行时动静配置这些性能。应用这些个性能够让您的应用程序 运行稳固 ，确保服务网格可能 容忍故障节点，并避免部分故障级联影响到其余节点。

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

为了找到 最佳超时设置，Istio 容许应用虚构服务，按服务轻松地动静调整超时，而不用批改您的业务代码。

栗子：

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

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    timeout: 10s

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

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

利用场景：与超时一样，Istio 默认的重试行为在提早方面可能不适宜您的应用程序需要（对失败的服务进行过多的重试会升高速度）或可用性。

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

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
    retries:
      attempts: 3
      perTryTimeout: 2s

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

作用：应用 熔断模式 能够疾速失败而不用让客户端尝试连贯到 过载或有故障 的主机。

熔断实用于在 负载平衡池 中的“实在”网格指标地址，能够在指标规定中配置熔断器阈值，让配置实用于服务中的每个主机。

栗子：

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

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
    trafficPolicy:
      connectionPool:
        tcp:
          maxConnections: 100

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

为什么应用：故障注入是一种将谬误引入零碎以确保零碎可能接受并从 谬误条件 中复原的测试方法。

作用：应用故障注入特地有用，能确保 故障复原策略 不至于不兼容或者太严格，这会导致要害服务不可用。

能够注入两种故障，都应用虚构服务配置：

提早：提早是工夫故障。它们模仿减少的网络提早或一个超载的上游服务。
终止：终止是解体失败。他们模拟上游服务的失败。终止通常以 HTTP 错误码或 TCP 连贯失败的模式呈现。

栗子：

千分之一拜访ratings 服务的申请，配置了一个 5 秒的提早：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - fault:
      delay:
        percentage:
          value: 0.1
        fixedDelay: 5s
    route:
    - destination:
        host: ratings
        subset: v1

Istio 故障复原 性能对应用程序来说是 齐全通明 的。在返回响应之前，应用程序不晓得 Envoy sidecar 代理是否正在 解决被调用服务的故障。这意味着，如果在利用程序代码中设置了故障复原策略，那么您须要记住这两个策略都是独立工作的，否则会发生冲突。

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

尽管 Istio 故障复原个性进步了网格中服务的 可靠性和可用性 ，但应用程序必须解决故障或谬误并采取适当的回退操作。例如，当负载平衡中的所有实例都失败时，Envoy 返回一个HTTP 503 代码。应用程序必须实现回退逻辑来解决 HTTP 503 错误代码。

这篇破费了不少精力，还望博友们反对反对新人！！！

前期会公布一篇实际操作，期待大家继续关注！！！

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

关于istio:Istio是什么-还不知道你就out了一文40分钟快速理解

前言

Istio 是什么？

服务网格是什么？

利用场景

为什么应用 Istio？

流量治理介绍

istio 架构

Envoy

Sidecar

Istiod

虚构服务(VirtualService)

为什么应用虚构服务？

栗子

路由规定

匹配条件

Destination

路由规定优先级

路由规定的更多内容

指标规定(DestinationRule)

负载平衡选项

网关(Gateway)

栗子

Sidecar

网络弹性和测试

超时

重试

栗子

熔断器

故障注入

和您的应用程序一起运行

总结