istio各组件详解 istio架构

一. Service Mesh

假设我们部署一个web 应用的服务，除了应用本身的功能之外， 可能还需要监控，日志采集，服务间的通讯等功能，如果将这些功能统一放到一个容器中，web应用的体积会变得很大，不便于维护，这种情况下， 我们可以将监控，日志采集，服务间的通讯等功能单独部署在这个Pod 中的另外一个container（容器）中， 这种将应用程序的功能划分为单独的进程可以被视为 Sidecar 模式，Sidecar 在软件系统架构中特指边车模式，这个模式的灵感来源于我们生活中的边三轮：即在两轮摩托车的旁边添加一个边车的方式扩展现有的服务和功能。这个模式的精髓在于实现了数据面（业务逻辑）和控制面的解耦：原来两轮摩托车的驾驶者集中注意力跑赛道，边车上的领航员专注周围信息和地图，专注导航。随着微服务越来越多，sidecar也就越来越多，自然就形成了一个网格，即service mesh。

二. Istio 架构

Istio是一个Service Mesh开源项目（serviceMesh理解抽象概念，istio实现这种概念）

1. istio能力

灰度发布：灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B测试，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度，降低风险。

故障注入：一种可靠性验证技术，通过受控实验向系统中刻意引入故障，并观察系统中存在故障时的行为。

2. istio和kubernetes的互补

Kubernetes 具有强大的容器编排与调度能力，但是他的服务治理能力极其有限。istio很好的补充了k8s的缺陷，使二者进行了完美的互补（两者都属于谷歌，完美互补也很正常）

名称和图标：istio(起航) kubernetes(领航员)

3. Istio架构

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

istio-proxy：istio 的sidecar（istio-proxy）是开源项目envoy的扩展版，Envoy是用C++开发的非常有影响力的轻量级高性能开源服务代理。作为服务网格的数据面，是istio架构中唯一的数据面组件， Envoy 提供了动态服务发现、负载均衡、TLS , HTTP/2 及gRPC 代理、熔断器、健康检查、流量拆分、灰度发布、故障注入等功能。

pilot: 是istio的控制中枢, 有两个作用，一是服务发现，获取被调用服务的实例，二是负责将各种规则转换成Envoy 可识别的格式，下发给Envoy。

Mixer：负责在服务网格上执行访问控制和使用策略，给代理返回允许访问还是拒绝。可以对接如配额、授权、黑白名单等不同的控制后端，对服务间的访问进行可扩展的控制，并从 Envoy 代理和其他服务收集遥测数据，作为监控。

Citadel： 服务之间访问的安全性，像证书之类的。

4. istio和k8s的融合

三. Istio配置

1. Envoy

外部架构：服务间都是通过Envoy串联起来的，Envoy是它们间的高速公路，Envoy的作用就是在各部分间转发读写请求

内部架构：外部架构展示了Envoy的作用，但无法窥见它是如何实现的，Envoy的内部结构展示出了它的实现原理。

如果将Envoy看成黑盒，则它所处位置可定义成如下图所示：

根据架构熟悉配置：

（1）静态配置：

##Envoy进程的管理配置: 通过admin可以查询到大量的配置、监控和运维等数据
admin:                                     
  access_log_path: /tmp/admin_access.log    #Envoy进程的日志
  address:
    socket_address: { address: 0.0.0.0, port_value: 9901 }  #Envoy进程的管理地址和端口  
##静态配置，定义静态资源
static_resources:
  listeners: #定义监听器，服务下游
  - name: listener_0 #定义监听器名称
    address: #定义监听器的监听地址和端口
      socket_address:
        address: 127.0.0.1 #监听地址
        port_value: 10000 #监听端口
    filter_chains: #定义过滤器（Filter）链，这是最核心和最复杂的部分
    - filters: # 过滤器数组
      - name: envoy.http_connection_manager # 过滤器名
        config:
          stat_prefix: ingress_http
          route_config: # 路由配置
            name: local_route # 路由配置名
            virtual_hosts: # 虚拟主机数组
            - name: local_service
              domains: ["*"] # 需代理的域名数组
              routes: # 定义路由
              - match:
                  prefix: "/" # 匹配规则
                route:
                  cluster: docker-project-service  # 上游集群名，通过它找到上游集群的配置
          http_filters:
          - name: envoy.router

  clusters: #定义上游集群，Envoy最基础的功能即是将来自下游的请求转发给上游
    - name: docker-project-service #上游集群名
	  connect_timeout: 0.25s #连接下游的超时时长
	  type: STATIC #集群类型，如STATIC(缺省值，在集群中列出所有可代理的主机)、其他动态类型下面会讲到
	  lb_policy: ROUND_ROBIN  #负载均衡策略：ROUND_ROBIN(轮询) LEAST_REQUEST(请求最少) RING_HASH(环形哈希) RANDOM(随机) MAGLEV(一致性哈希算法) CLUSTER_PROVIDED(定制)
	  hosts: [
	  { socket_address: { address: 10.244.2.107, port_value: 8080}},
      { socket_address: { address: 10.244.2.115, port_value: 8080}}
     ]  #上游服务的ip地址和端口(写死了)

在上面的例子中，我们配置了一个 envoy实例，监听 127.0.0.1:10000，支持 http 协议访问， 当监听到有流程的时候，将接收到的所有http流量，经过过滤器链，路由到了IP地址为10.244.2.107/10.244.2.115的docker-project-service服务。 而docker-project-service服务中 hosts 是写死的，如果IP地址有变动的话，就需要修改hosts，并且重启envoy代理服务，不利于扩展。

（2）动态配置：

静态配置不利于扩展，那我们能不能动态的实时去查找对应的服务的ip地址呢？Envoy 支持不同的模块进行动态配置：

a.基于EDS的部分动态配置

##Envoy进程的管理配置: 通过admin可以查询到大量的配置、监控和运维等数据	  
admin:                                     
  access_log_path: /tmp/admin_access.log    #Envoy进程的日志
  address:
    socket_address: { address: 0.0.0.0, port_value: 9901 }  #Envoy进程的管理地址和端口  	
#静态配置，定义静态资源	
static_resources: 
  listeners: #定义监听器，服务下游
  - name: listener_0 #定义监听器名称
    address: #定义监听器的监听地址和端口
      socket_address:
        protocol: TCP
        address: 0.0.0.0 # 监听地址
        port_value: 8080 # 监听端口
    filter_chains: #定义过滤器（Filter）链，这是最核心和最复杂的部分
    - filters: # 过滤器数组
      - name: envoy.http_connection_manager # 过滤器名
        config:
          stat_prefix: ingress_http
          route_config: # 路由配置
            name: local_route # 路由配置名
            virtual_hosts: # 虚拟主机数组
            - name: local_service
              domains: ["*"] # 需代理的域名数组
              routes: # 定义路由
              - match:
                  prefix: "/" # 匹配规则
                route:
                  cluster: docker-project-service  # 上游集群名，通过它找到上游集群的配置
          http_filters:
          - name: envoy.router
  #定义上游集群，Envoy最基础的功能即是将来自下游的请求转发给上游
  clusters:
  - name: docker-project-service   #上游集群名
    connect_timeout: 0.25s    #连接下游的超时时长
    lb_policy: ROUND_ROBIN        #负载均衡策略
    type: EDS    #集群类型
    eds_cluster_config:
      eds_config:
        api_config_source:
          api_type: GRPC
          cluster_names: [xds_cluster]  #通过xds_cluster拿到some_service服务的实例的IP地址
  - name: xds_cluster 
    connect_timeout: 0.25s
    type: STATIC
    lb_policy: ROUND_ROBIN
    http2_protocol_options: {}
    hosts: [{ socket_address: { address: 172.16.133.96, port_value: 6443 }}] #获取EndPoint的地址

通过命令获取endPoint

通过api获取endPoint

这样就实现docker-project-service这个 cluster 的 hosts 的动态配置了。新的配置中，docker-project-service这个 cluster 的 hosts 是 EDS(Endpoint Discovery Service) 的返回值决定的，就是说 EDS 会返回 docker-project-service 这个 cluster 的 hosts 的列表。新配置中，EDS 服务的地址定义在 xds_cluster 这个 cluster中。