深入理解Istio服务网格数据平面Envoy

一、服务网格概述(service mesh)

在传统的微服务架构中，服务间的调用，业务代码需要考虑认证、熔断、服务发现等非业务能力，在某种程度上，表现出了一定的耦合性
在这里插入图片描述
服务网格追求高级别的服务流量治理能力，认证、熔断、服务发现这些能力更多的是平台测的能力。将业务测和平台测能力解耦，开发人员只关心业务测的能力。每个服务实例都有一个代理，服务的入站流量、出站流量都先经过代理，代理不进行业务处理，只做流量转发，因此，传统微服务架构，服务到服务间的调用，转成了proxy到proxy的调用。
在这里插入图片描述
Proxy通常是一种反向代理软件，有强大的流量转发能力。我们前面讲kube-proxy做负载均衡，是利用Linux内核配置iptables规则，做的L4负载均衡，实际上是能力比较弱的负载均衡。由于所有的流量都经过Proxy,基于此，很容易做到监控、熔断、重试、超时处理、负载均衡、认证等能力。

二、Istio架构

在这里插入图片描述
基于Istio的流量治理，控制平面是其istiod组件，而这个proxy角色就是反向代理软件Envoy。istiod负责生成并下发Envoy的配置。通过丰富的路由规则，对流量行为进行细粒度的控制。

三、Envoy

3.1 优势

Envoy在L4和L7都提供了丰富的Filter能力，并且还提供一组可以通过控制平面管理的API(XDS API)。云原生是一个动态的系统，pod的ip并不是固定的，传统的基于静态配置文件加载的方式并不适用。因此Envoy的API可配置性具有很大的优势，控制平面监听到配置需要变更时，控制平面可以主动下发envoy配置，而envoy不需要重新启动，支持hot reload。

3.2 Envoy典型配置

在这里插入图片描述
listener定义了本机监听ip和端口，route_config配置了转发规则，cluster对应的是service，endpoint对应的是转发的pod。

3.3 Envoy架构

在这里插入图片描述
Main Thread通过XDS API接收控制平面下发的配置，然后将listener、route_config、cluster等各配置项下发至Worker Thread，Worker Thread负责真正接收处理请求流量。

3.4 发布应用

1、创建envoy的配置configmap

kubectl create configmap envoy-config --from-file=envoy.yaml

envoy.yaml:

admin:
  address:
    socket_address: { address: 127.0.0.1, port_value: 9901 }

static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address: { address: 0.0.0.0, port_value: 10000 }
      filter_chains:
        - filters:
            - name: envoy.filters.network.http_connection_manager
              typed_config:
                "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
                stat_prefix: ingress_http
                codec_type: AUTO
                route_config:
                  name: local_route
                  virtual_hosts:
                    - name: local_service
                      domains: ["*"]
                      routes:
                        - match: { prefix: "/" }
                          route: { cluster: some_service }
                http_filters:
                  - name: envoy.filters.http.router
  clusters:
    - name: some_service
      connect_timeout: 0.25s
      type: LOGICAL_DNS
      lb_policy: ROUND_ROBIN
      load_assignment:
        cluster_name: some_service
        endpoints:
          - lb_endpoints:
              - endpoint:
                  address:
                    socket_address:
                      address: httpserver-svc
                      port_value: 80

2、部署envoy，并将configmap mount进去
envoy-deploy.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: envoy
  name: envoy
spec:
  replicas: 1
  selector:
    matchLabels:
      run: envoy
  template:
    metadata:
      labels:
        run: envoy
    spec:
      containers:
        - image: envoyproxy/envoy:v1.21.5
          name: envoy
          volumeMounts:
            - name: envoy-config
              mountPath: "/etc/envoy"
              readOnly: true
      volumes:
        - name: envoy-config
          configMap:
            name: envoy-config