Istio 基础架构及应用

前几天被问到项目中使用的服务网格核心 Istio 的架构及改进问题，一时语塞！😓

当时项目紧急只顾着调研方案及快速应用了，并未对其清奇骨骼及丰腻肌理进行深入了解，Istio 是怎么进行流量拦截治理的，Istio 架构都包含哪些组件，分别负责什么功能？

本着对行业发展主流技术的好奇和敏感，随即系统性学习了解了下，分享给大家，有不对的地方还望见谅并帮忙批评指正~~

一、服务网格ServiceMesh

作为技术背景，谈论 Istio 之前不能免俗必得谈及服务网格 ServiceMesh。

时下微服务大行其道，单体应用被拆分为较多相对独立的微小服务，单个服务的复杂度及维护成本大幅降低，却碰壁了另外一个难题--众多微服务之间的通信联动管理及监控，如服务发现、负载均衡、版本控制、故障转移、灰度发布、熔断限流及监控追踪等。

业界大牛们解决这个难题也经过了多次架构演进，大致分为服务内嵌代理、代理分离多服务复用、代理和服务一对一匹配(sidecar 边车模式) 三个阶段。

Service Mesh 就是为微服务而生的专用基础设施层，像网格一样连接所有的微服务通信，是一套轻量级高性能网络代理。它提供安全的、快速的、可靠地服务间通讯，与实际应用部署一起，但对应用透明。

二、Istio 核心架构

ServiceMesh 和 sidecar 都是一种架构思想，具体的技术生态比较庞大，Istio、Envoy、MOSN、Linkerd、Kong、Nginxmesh、Jaeger、Zipkin、Kiali、Grafana、Prometheus等等。我们今天不发散，集中看下 Istio。 

Istio 是由 IBM、Google 和 Lyft 开发的一套服务网格的开源实现。目前 Istio 市场占有率70%+，已经算是事实上的服务网格技术标准。

Istio 默认使用 Lyft 的 Envoy 作为数据平面 sidecar 控制器，控制平面控制器则主要包括 Pilot 司令官、Mixer 守护神、安全碉堡 Citadel 、配置中心 Galley 等。（Istio1.5之后整体架构变动较大，将控制平面众多组件合为一体收归Istiod 统一控制，但为了更清楚的讲述我们暂且先分开看）

Envoy数据代理

Envoy 是用 C++ 开发的高性能网络代理，它是 Istio 数据平面的核心组件。

它作为 sidecar 和服务部署在同一个 Pod 中，通过 sidecar-injector 自动注入，通过容器启动时初始化设定一堆 ipatables 规则来拦截代理服务网格中所有服务的入站和出站流量，从而进行相应的服务及流量治理维护，这块的详细内容上一篇文章中已经详细讲述了，可以参见 ?从iptables谈ServiceMesh流量拦截。

istio-iptables -p 15001 -z 15006 -u 1337 -m REDIRECT -i '*' -x "" -b '*'

Pilot司令官

Pilot 是 Istio 控制平面流量管理的核心组件。管理和配置部署在 Istio 服务网格中的所有 Envoy 数据代理实例，允许用户配置 Envoy 代理之间的流量转发路由规则及故障转移恢复如超时重试熔断等。

Pilot-agent 代理守护进程

Pilot-agent 在启动 Envoy 时将 xDS server 信息通过静态资源的方式配置到 Envoy 的初始化配置文件中，Envoy 启动后再通过 xDS server 获取网格中的服务信息、路由规则等动态资源。

$ ps -ef
UID          PID    PPID  C STIME TTY          TIME CMD
istio-p+       1       0  0 Mar25 ?        00:30:10 /usr/local/bin/pilot-agent proxy sidecar --domain bpd-ie.svc
istio-p+      70       1 30 Mar25 ?        16-14:25:11 /usr/local/bin/envoy -c etc/istio/proxy/envoy-rev0.json -
istio-p+      95       0  0 08:24 pts/0    00:00:00 /bin/sh
istio-p+     104      95  0 08:33 pts/0    00:00:00 ps -ef

Mixer守护神

Mixer 是 Istio 中负责执行服务间的访问策略和收集遥测数据的组件。服务间请求转发时，Envoy 会对 Mixer 发起 check 和 report 两次请求执行访问策略与管理配额，并在请求转发后上报遥测数据。我们看到的可视化的日志监控，jaeger、zipkin、kiali、prometheus 等基础设施的数据都是Mixer 通过 Adapter 机制遥测上报的。

Citadel安全碉堡

Citadel 主要负责 Istio 的安全问题。负责证书的颁发及校验，通过内置身份和凭证管理提供强大的服务间和最终用户身份验证。

Galley配置中心

Galley 主要负责用户配置信息的管理，从底层平台接受并验证分发配置信息到其他组件。

Istio1.5 版本后架构变动较大，全面拥抱变化的一个版本，重建了整个控制平面，将各个组件多进程合并打造了全新的部署模式 istiod，降低部署成本；摒弃了拖累系统性能的 Mixer；保证兼容性也不忘持续优化和引入新的功能。在彻底抛弃历史包袱的同时，Istio 团队也用他们的勇气践行了敏捷开发的真谛，并且功能、性能、灵活性等各方面都得到了改进。

三、Istio 应用

接下来结合我们项目中实际应用简单介绍 Istio 的一些规则配置用法，主要包括 Virtualservice、DestinationRule、GateWay、ServiceEntry、Sidecar等。

先看基础服务搭建好（我这里用的是Istio 1.7）以后系统中都有哪些组件（不一定都一样，可以自己选择遥测相关组件）。搭建过程略，大家可以参考官网详细说明。

kubectl get svc -n istio-system --kubeconfig ~/.kube/config.thanos

VirtualService

定义了一组路由规则，当流量进入时逐个规则进行匹配，直到匹配成功后将流量转发给给定的路由地址，同时可以进行灰度发布、超时重试、故障转移、流量镜像等多种服务治理。

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: **-virtualservice
  namespace: **
spec:
  hosts:
    - **.**.svc.cluster.local
    - **.**
  gateways:
    - istio-system/default-gateway
    - mesh
  http:
    - match:   
        - port: 9090   ## rpc走9090端口
      route:
        - destination:
            host: **.**.svc.cluster.local
            port:
              number: 9090
    - route:          ## http默认走8080端口
        - destination:
            host: **.**.svc.cluster.local
            port:
              number: 8080

还可以应用更多治理策略, 下面简单列举几个，具体参见官网规则。

    - match:
        - uri:   ## 流量重定向
            prefix: /checkparam
        rewrite:
            uri: /check
        route:
        - destination:
            host: **
            subset: v1   ##灰度
        timeout: 0.5s  ## 超时重试 重试条件 重试间隔 重试次数等
        retries:
          attempts: 3
          perTryTimeout: 1s
          retryOn: 5xx
        mirror:       ## 流量镜像
          host: **
          subset: v2
        mirror_percent: 100  ##镜像比例

DestinationRule

定义了网格中某个 Service 对外提供服务的策略及规则，这包括负载均衡策略、异常点检测、熔断控制、访问连接池等。负载均衡策略支持简单的负载策略（ROUND_ROBIN、LEAST_CONN、RANDOM、PASSTHROUGH）、一致性 Hash 策略和区域性负载均衡策略。我们服务中用的比较简单这里就不列了。

Gateway

定义了所有 HTTP/TCP 流量进入网格或者从网格中出站的统一入口和出口。它描述了一组对外公开的端口、协议、负载均衡、以及 SNI 配置。Istio Gateway 包括 Ingress Gateway 与 Egress Gateway，分别用来配置网格的入口流量与出口流量。这个可以多服务复用。

ServiceEntry

可以将网格外的服务注册到 Istio 的注册表中去，这样就可以把外部服务当做网格内部的服务一样进行管理和操作。

Sidecar

主要用来定义控制 Envoy 代理转发和接收的端口协议等，并可以限制 Sidecar 出站流量允许到达的目标服务集合。

最终，我们服务通过 Kiali 展示的服务拓扑图如下所示。

相应的 jaeger 和 prometheus 等展示的追踪及监控也都一应俱全，这里就不展示了。

总结

结合服务网格的实际应用，我们一起回顾了微服务治理的架构演进，一起简单探讨了 Istio 的核心架构及1.5版本以后的变革，进而简单介绍了 Istio 服务治理的一些简单应用规则配置。至于单个组件的具体工作深入原理后面有机会我们再逐个探讨。本人也是一边学一边用，过程中如果有什么描述不恰当的地方还请各位看官见谅。

[1]Istio架构 https://istio.io/latest/docs/ops/deployment/architecture/

[2] 《云原生服务网格Istio》      https://cloud.tencent.com/developer/article/1519639?from=article.detail.1519637