关于golang:通过-xDS-实现-Envoy-动态配置

在云原生时代，容器取代虚拟机成为承载利用工作负载的次要模式。虚拟机生命周期绝对较长，可能有数天，然而容器少则几分钟。这就要求负载均衡器必须能适应这种动态性。

Envoy 通过 xDS 实现了其动静配置，来应答一直变动的基础架构。

Envoy 通过文件系统或查问治理服务器发现其各种动静资源。这些发现服务及其相应的 API 统称为 xDS。

xDS API 中的每个配置资源都有与之关联的类型。资源类型遵循版本控制计划。目前 V2 版本曾经进行开发，不过会有一年的保护期。V3 版本是目前主力版本。

反对以下 v3 xDS 资源类型：

envoy.config.listener.v3.Listener
envoy.config.route.v3.RouteConfiguration
envoy.config.route.v3.ScopedRouteConfiguration
envoy.config.route.v3.VirtualHost
envoy.config.cluster.v3.Cluster
envoy.config.endpoint.v3.ClusterLoadAssignment
envoy.extensions.transport_sockets.tls.v3.Secret
envoy.service.runtime.v3.Runtime

格局为 http://type.googleapis.com/< 资源类型 >–例如，用于集群资源的 type.googleapis.com/envoy.api.v3.Cluster。在来自 Envoy 的各种申请和治理服务器的响应中，都申明了资源类型 URL。

这些 API 实际上通过 proto3 Protocol Buffers 定义。

Envoy 通过订阅（_subscription_）形式来获取资源，如监控指定门路下的文件、启动 gRPC 流或轮询 REST-JSON URL。后两种形式会发送 DiscoveryRequest 申请音讯，发现的对应资源则蕴含在响应音讯 DiscoveryResponse 中。

其中流式 gRPC 订阅是最常应用的。

流式 gRPC 应用的 xDS 传输协定有四种变体：

State of the World (Basic xDS)：SotW，每种资源类型的独自 gRPC 流
增量 xDS：每种资源类型的增量独立 gRPC 流
聚合发现服务（ADS）：SotW，所有资源类型的聚合流
增量 ADS：所有资源类型的增量聚合流

社区提供了两种语言的实现，在咱们编写本人的管制立体时，能够间接应用：

go-control-plane
java-control-plane

比方 go-control-plane 提供了由多个不同管制立体实现共享的根底构造。该库提供的组件是：

API 服务器_：_一种基于 gRPC 的通用 API 服务器，可实现 data-plane-api 中定义的 xDS API。API 服务器负责将配置更新推送到 Envoy。消费者应该可能在生产部署中导入该 go 库并按原样应用 API服务器。
配置缓存_：_该库将在内存中缓存 Envoy 配置，以对 Envoy 提供疾速响应。此库的使用者有责任将数据写入到高速缓存，并在必要时使高速缓存有效。高速缓存将基于预约义的哈希函数进行键控，该哈希函数的键基于 Node 信息。

目前，此存储库将不会解决将平台（例如服务，服务实例等）的特定于资源的示意转换为 Envoy 款式的配置。

上面咱们通过 go-control-plane 实现一个简略的 Envoy 管制立体，并且采纳的是第三种 xDS 变体。

1：数据立体 Envoy 配置

尽管 Envoy 承受管制立体的动静资源，然而 Envoy 的启动须要一些动态配置，也就是引导文件。残缺引导文件如下：

node:
  id: node-1
  cluster: edge-gateway

admin:
  access_log_path: /dev/stdout
  address:
    socket_address: {address: 127.0.0.1, port_value: 9901}

dynamic_resources:
  ads_config:
    # allows limiting the rate of discovery requests.
    # for edge cases with very frequent requests or due to a bug.
    rate_limit_settings:
      max_tokens: 10
      fill_rate: 3
    # we use v3 xDS framing
    transport_api_version: V3
    # over gRPC
    api_type: GRPC
    grpc_services:
      - envoy_grpc:
          cluster_name: xds_cluster
  # Use ADS for LDS and CDS; request V3 clusters and listeners.
  lds_config: {ads: {}, resource_api_version: V3}
  cds_config: {ads: {}, resource_api_version: V3}

static_resources:
  clusters:
  - name: xds_cluster
    connect_timeout: 0.25s
    type: STATIC
    lb_policy: ROUND_ROBIN
    # as we are using gRPC xDS we need to set the cluster to use http2
    http2_protocol_options: {}
    upstream_connection_options:
      # important:
      # configure a TCP keep-alive to detect and reconnect to the admin
      # server in the event of a TCP socket half open connection
      # the default values are very conservative, so you will want to tune them.
      tcp_keepalive: {}
    load_assignment:
      cluster_name: xds_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 9977

引导文件蕴含两个 ConfigSource 音讯，一个批示如何获取侦听器资源，另一个批示如何获取集群资源。它还蕴含一个独自的 ApiConfigSource 音讯，该音讯批示如何与 ADS 服务器通信，只有 ConfigSource 音讯（在引导文件或从治理服务器获取的侦听器或集群资源中）蕴含 AggregatedConfigSource 音讯，就会应用该音讯。

在应用 xDS 的 gRPC 客户端中，仅反对 ADS，并且引导文件蕴含 ADS 服务器的名称，该名称将用于所有资源。侦听器和集群资源中的 ConfigSource 音讯必须蕴含 AggregatedConfigSource 音讯。

那么 Envoy 依照该引导文件启动后，会与 127.0.0.1:9977 通信，获取监听器和集群资源。

2：编写管制立体

本次管制立体要实现的性能是管制 Envoy 实现灰度公布。因为 go-control-plane 曾经帮咱们做了很多事件，所以咱们惟一须要做的就是将灰度相干的设置转换为 Envoy 款式的配置。

因为代码较长，咱们只贴出外围的代码：

func makeRoute(routeName string, weight uint32, clusterName1, clusterName2 string) *route.RouteConfiguration {
    routeConfiguration := &route.RouteConfiguration{
        Name: routeName,
        VirtualHosts: []*route.VirtualHost{{
            Name:    "local_service",
            Domains: []string{"*"},
        }},
    }
    switch weight {
    case 0:
        routeConfiguration.VirtualHosts[0].Routes = []*route.Route{{
            Match: &route.RouteMatch{
                PathSpecifier: &route.RouteMatch_Prefix{Prefix: "/",},
            },
            Action: &route.Route_Route{
                Route: &route.RouteAction{
                    ClusterSpecifier: &route.RouteAction_Cluster{Cluster: clusterName1,},
                    HostRewriteSpecifier: &route.RouteAction_HostRewriteLiteral{HostRewriteLiteral: UpstreamHost,},
                },
            },
        }}

    case 100:
        routeConfiguration.VirtualHosts[0].Routes = []*route.Route{{
            Match: &route.RouteMatch{
                PathSpecifier: &route.RouteMatch_Prefix{Prefix: "/",},
            },
            Action: &route.Route_Route{
                Route: &route.RouteAction{
                    ClusterSpecifier: &route.RouteAction_Cluster{Cluster: clusterName2,},
                    HostRewriteSpecifier: &route.RouteAction_HostRewriteLiteral{HostRewriteLiteral: UpstreamHost,},
                },
            },
        }}
        // canary-roll out:
    default:
        routeConfiguration.VirtualHosts[0].Routes = []*route.Route{{
            Match: &route.RouteMatch{
                PathSpecifier: &route.RouteMatch_Prefix{Prefix: "/",},
            },
            Action: &route.Route_Route{
                Route: &route.RouteAction{
                    ClusterSpecifier: &route.RouteAction_WeightedClusters{
                        WeightedClusters: &route.WeightedCluster{
                            TotalWeight: &wrapperspb.UInt32Value{Value: 100,},
                            Clusters: []*route.WeightedCluster_ClusterWeight{
                                {
                                    Name: clusterName1,
                                    Weight: &wrapperspb.UInt32Value{Value: 100 - weight,},
                                },
                                {
                                    Name: clusterName2,
                                    Weight: &wrapperspb.UInt32Value{Value: weight,},
                                },
                            },
                        },
                    },
                    HostRewriteSpecifier: &route.RouteAction_HostRewriteLiteral{HostRewriteLiteral: UpstreamHost,},
                },
            },
        }}

    }
    return routeConfiguration
}

因为咱们是第三种变体，咱们在变更配置的时候，须要所有资源的变更封装成 cachev3.Snapshot：

func GenerateSnapshot(weight uint32) cachev3.Snapshot {
    version++
    nextversion := fmt.Sprintf("snapshot-%d", version)
    fmt.Println("publishing version:", nextversion)
    return cachev3.NewSnapshot(
        nextversion,        // version needs to be different for different snapshots
        []types.Resource{}, // endpoints
        []types.Resource{makeCluster(ClusterName1), makeCluster(ClusterName2)},
        []types.Resource{makeRoute(RouteName, weight, ClusterName1, ClusterName2)},
        []types.Resource{makeHTTPListener(ListenerName, RouteName)},
        []types.Resource{}, // runtimes
        []types.Resource{}, // secrets
    )
}

咱们的示例比较简单，然而在生产环境，咱们应该思考哪些内容那？

3：生产环境的管制面

生产环境管制面，则须要实现：

外围 xDS 服务接口和实现
解决向服务注册表中注册 / 反注册服务的组件
服务注册表
形容 Envoy 配置的形象对象模型（可选）
数据存储区，用于保留配置

比方 Contour，实际上只有两个组成其管制立体的组件，然而，因为它仅基于 Kubernetes，因而它实际上利用了许多内置的 Kubernetes 设施，例如 Kubernetes API / 存储和 CRD 来驱动配置。

contour 服务器
init-container 疏导程序

Contour 应用 init-container 来为 Envoy 生成一个动态疏导程序配置文件，该文件批示在哪里能够找到 xDS 服务。xDS 服务器是管制立体中的第二个组件。

其实目前诸多基于 Envoy 的我的项目，都是采取管制面 + xDS + envoy 的模式。比方 Apigateway 中的 gloo，ambassador，Service Mesh 中的 istio，app-mesh 等。

各个管制面其实基本上对接各种服务注册核心，而后再依据客户配置的转发规定，转换为 xDS 资源，通过 gRPC 流下发到 Envoy 中。

关于golang:通过-xDS-实现-Envoy-动态配置

xDS 简介

资源类型

流式 gRPC 订阅

如何实现一个简略的管制立体

总结