服务网格数据平面的关键:层层剖析Envoy配置
Envoy是一种高性能C++分布式代理,专为单个服务和应用程序设计。作为Service Mesh中的重要组件,充分理解其配置就显得尤为重要。本文列出了使用Envoy而不用其他代理的原因。并给出了Envoy及其服务的配置,然后对其进行详细解读,帮助读者理解其配置,从而掌握Envoy。
服务网格是微服务设置中的通信层,也就是说往返于每个服务的所有请求都通过网格。服务网格在微服务设置中也成为基础架构层,它能够让服务之间的通信变得安全可靠。关于Service Mesh的基础内容,我们已经在这篇文章中详细介绍过。
每一个服务都有自己的代理服务(sidecars),然后所有代理服务一起形成服务网格。Sidecars处理服务之间的通信,也就是说所有的流量都会通过网格并且该透明层可以控制服务之间如何交互。
服务网格通过由API控制的组件提供可观察性、服务发现以及负载均衡等。
实际上,如果一个服务要调用另一个服务,它不会直接调用目标服务。而是先将请求路由到本地代理,然后代理再将该请求路由到目标服务。这一过程意味着服务实例不会和其他服务直接接触,仅与本地代理进行通信。
根据ThoughtWorks Technology Radar(这是一份半年度的文档,用于评估现有技术和新生技术的风险和收益)指出,“服务网格提供一致的发现、安全性、跟踪(tracing)、监控以及故障处理,而无需共享资源(如API网关或ESB)。一个十分典型的用例是轻量的反向代理进程会与每个服务进程或单独的容器一起部署。”
当谈到服务网格时,不可避免谈到的是“sidecar”——可用于每个服务实例的代理。每个sidecar负责管理一个服务的一个实例。我们将在本文中进一步详细讨论sidecar。
服务网格可以交付什么?
当前,越来越多的企业和组织开始转向微服务架构。这样的企业需要服务网格所提供的上述功能。解耦库的使用或自定义代码的方法无疑是赢家。
为什么使用Envoy?
Envoy不是构建一个服务网格的唯一选择,市面上还有其他的代理如Nginx、Traefik等。我之所以选择Envoy,这个用C++编写的高性能代理,是因为我更喜欢Envoy的轻量、强大的路由,及其提供的可观察性和可扩展性。
让我们首先构建1个包含3个服务的服务网格设置,这是我们正在尝试构建的架构:
Front Envoy
在我们的设置中Front Envoy是一个边缘代理,我们通常在其中执行TLS终止、身份验证、生成请求头等操作。
我们来看看Front Envoy配置:
---
admin:
access_log_path: "/tmp/admin_access.log"
address:
socket_address:
address: "127.0.0.1"
port_value: 9901
static_resources:
listeners:
-
name: "http_listener"
address:
socket_address:
address: "0.0.0.0"
port_value: 80
filter_chains:
filters:
-
name: "envoy.http_connection_manager"
config:
stat_prefix: "ingress"
route_config:
name: "local_route"
virtual_hosts:
-
name: "http-route"
domains:
- "*"
routes:
-
match:
prefix: "/"
route:
cluster: "service_a"
http_filters:
-
name: "envoy.router"
clusters:
-
name: "service_a"
connect_timeout: "0.25s"
type: "strict_dns"
lb_policy: "ROUND_ROBIN"
hosts:
-
socket_address:
address: "service_a_envoy"
port_value: 8786
Envoy配置主要由以下部分组成:
1、 监听器(Listener)
2、 路由
3、 集群
4、 端点
监听器
一个或多个监听器可以在单个Envoy实例中运行。在以上9到36行的代码提到了当前监听器的地址和端口。每个监听器也可以有一个或多个网络过滤器。这些过滤器可以启用路由、tls终止、流量转移等活动。除了envoy.http_connection_manager
使用的是内置过滤器之外,Envoy还有其他几个过滤器。
路 由
22行到34行代码为过滤器配置了路由规范,同时它也指定了我们所接受请求的域以及路由匹配器。路由匹配器可以根据配置的规则匹配每个请求,并将请求转发到适当的集群。
集 群
集群是Envoy将流量路由到的上游服务规范。41行到48行代码定义了“Service A”,这是Front Envoy要通信的唯一上游。“connect_timeout”是在返回503之前建立与上游服务的连接的时间限制。
通常情况下,有多个“Serivce A”实例,并且Envoy支持多种负载均衡算法来路由流量。在本例中,我们使用了一个简单的循环算法。
端 点
“host”指定我们要将流量路由到的Service A的实例。在本例中,我们只有1个实例。
第47行代码没有直接与Service A进行通信,而是与Service A的Envoy代理实例进行通信,该代理将路由到本地Service A实例。
我们还可以利用返回Service A的所有实例的服务名称(如Kubernetes中的headless服务),来执行客户端负载均衡。Envoy缓存Service A的所有host,并每5秒刷新一次host列表。
此外,Envoy还支持主动和被动的健康检查。因此,如果我们要进行主动健康检查,我们需要在集群配置部分对其进行配置。
其 他
第2行到第7行配置了管理服务器,它能够帮助查看配置、更改日志级别、查看统计信息等。
第8行的“static_resources”可以手动加载所有配置。我们将在下文讨论如何动态地执行此操作。
虽然这里描述了许多其他配置,但是我们的目标不是全面介绍所有配置,而是以最少的配置开始。
Service A
这是Service A的Envoy配置:
admin:
access_log_path: "/tmp/admin_access.log"
address:
socket_address:
address: "127.0.0.1"
port_value: 9901
static_resources:
listeners:
-
name: "service-a-svc-http-listener"
address:
socket_address:
address: "0.0.0.0"
port_value: 8786
filter_chains:
-
filters:
-
name: "envoy.http_connection_manager"
config:
stat_prefix: "ingress"
codec_type: "AUTO"
route_config:
name: "service-a-svc-http-route"
virtual_hosts:
-
name: "service-a-svc-http-route"
domains:
- "*"
routes:
-
match:
prefix: "/"
route:
cluster: "service_a"
http_filters:
-
name: "envoy.router"
-
name: "service-b-svc-http-listener"
address:
socket_address:
address: "0.0.0.0"
port_value: 8788
filter_chains:
-
filters:
-
name: "envoy.http_connection_manager"
config:
stat_prefix: "egress"
codec_type: "AUTO"
route_config:
name: "service-b-svc-http-route"
virtual_hosts:
-
name: "service-b-svc-http-route"
domains:
- "*"
routes:
-
match:
prefix: "/"
route:
cluster: "service_b"
http_filters:
-
name: "envoy.router"
-
name: "service-c-svc-http-listener"
address:
socket_address:
address: "0.0.0.0"
port_value: 8791
filter_chains:
-
filters:
-
name: "envoy.http_connection_manager"
config:
stat_prefix: "egress"
codec_type: "AUTO"
route_config:
name: "service-b-svc-http-route"
virtual_hosts:
-
name: "service-b-svc-http-route"
domains:
- "*"
routes:
-
match:
prefix: "/"
route:
cluster: "service_c"
http_filters:
-
name: "envoy.router"
clusters:
-
name: "service_a"
connect_timeout: "0.25s"
type: "strict_dns"
lb_policy: "ROUND_ROBIN"
hosts:
-
socket_address:
address: "service_a"
port_value: 8081
-
name: "service_b"
connect_timeout: "0.25s"
type: "strict_dns"
lb_policy: "ROUND_ROBIN"
hosts:
-
socket_address:
address: "service_b_envoy"
port_value: 8789
-
name: "service_c"
connect_timeout: "0.25s"
type: "strict_dns"
lb_policy: "ROUND_ROBIN"
hosts:
-
socket_address:
address: "service_c_envoy"
port_value: 8790
11行到39行定义了一个监听器来路由流量到实际的Service A实例。在103行到111行中找到service_a
实例的相应集群定义。
Service A与Service B和Service C进行通信,它指向了两个以上的监听器以及集群。在本例中,我们为每个上游(localhost、Service B和Service C)分离了监听器。另一种方法是使用单个监听器,并根据URL或请求头路由到任意上游。
Service B 和 Service C
Service B和Service C处于叶级,除了本地主机服务实例外,不与任何其他上游通信。因此其配置十分简单。
而让事情变得复杂的是上述配置中的单个监听器和单个集群。
配置完成后,我们将此设置部署到Kubernetes或使用docker-compose对其进行测试。你可以运行docker-compose build
和docker-compose up
并点击localhost:8080,以查看请求是否成功通过所有服务和Envoy代理。我们可以使用日志对其进行验证。
Envoy xDS
我们为每个sidecar提供了配置,并且根据不同的服务,服务之间的配置也有所不同。虽然我们可以手动制作和管理sidecar配置,但最初至少要提供2或3个服务,并且随着服务数量的增加,配置会变得十分复杂。此外,每次sidecar配置更改时,你都必须重新启动Envoy实例,以使更改生效。
正如上文所讨论的,我们可以通过使用API server来避免手动配置并加载所有组件:集群(CDS)、端点(EDS)、监听器(LDS)以及路由(RDS)。所以每个sidecar将与API server通信并接收配置。当新配置更新到API server时,它将自动反映在Envoy实例中,从而避免了重新启动。
你可以在以下链接中了解关于动态配置的信息:
https://www.envoyproxy.io/docs/envoy/latest/configuration/overview/v2_overview#dynamic
这有一个简单的xDS server:
https://github.com/tak2siva/Envoy-Pilot
如何在Kubernetes中实现
本部分将讨论如果我们要在Kubernetes中实现所讨论的设置该怎么办。以下是架构图:
因此,将需要更改:
Pod
服务
部署Pod
尽管Pod规范中仅定义了一个容器——按照定义,一个Pod可以容纳一个或多个容器。为了对每个服务实例运行sidecar代理,我们将Envoy容器添加到每个Pod中。为了与外界通信,服务容器将通过localhost与Envoy容器进行对话。
部署文件如下所示:
admin:
access_log_path: "/tmp/admin_access.log"
address:
socket_address:
address: "127.0.0.1"
port_value: 9901
static_resources:
listeners:
-
name: "service-b-svc-http-listener"
address:
socket_address:
address: "0.0.0.0"
port_value: 8789
filter_chains:
-
filters:
-
name: "envoy.http_connection_manager"
config:
stat_prefix: "ingress"
codec_type: "AUTO"
route_config:
name: "service-b-svc-http-route"
virtual_hosts:
-
name: "service-b-svc-http-route"
domains:
- "*"
routes:
-
match:
prefix: "/"
route:
cluster: "service_b"
http_filters:
-
name: "envoy.router"
clusters:
-
name: "service_b"
connect_timeout: "0.25s"
type: "strict_dns"
lb_policy: "ROUND_ROBIN"
hosts:
-
socket_address:
address: "service_b"
port_value: 8082
在容器部分添加了Envoy sidecar,并且在33到39行的configmap中我们挂载了我们的Envoy配置文件。
更改服务
Kubernetes服务负责维护Pod端点列表,该列表可以路由流量。尽管kube-proxy通常处理Pod端点之间的负载均衡,但在本例中,我们将执行客户端负载均衡,并且我们不希望kube-proxy进行负载均衡。此外,我们想要提取Pod端点列表并对其进行负载均衡。为此,我们需要使用“headless服务“来返回端点列表。
如下所示:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: servicea
spec:
replicas: 2
template:
metadata:
labels:
app: servicea
spec:
containers:
- name: servicea
image: dnivra26/servicea:0.6
ports:
- containerPort: 8081
name: svc-port
protocol: TCP
- name: envoy
image: envoyproxy/envoy:latest
ports:
- containerPort: 9901
protocol: TCP
name: envoy-admin
- containerPort: 8786
protocol: TCP
name: envoy-web
volumeMounts:
- name: envoy-config-volume
mountPath: /etc/envoy-config/
command: ["/usr/local/bin/envoy"]
args: ["-c", "/etc/envoy-config/config.yaml", "--v2-config-only", "-l", "info","--service-cluster","servicea","--service-node","servicea", "--log-format", "[METADATA][%Y-%m-%d %T.%e][%t][%l][%n] %v"]
volumes:
- name: envoy-config-volume
configMap:
name: sidecar-config
items:
- key: envoy-config
path: config.yaml
有两件事需要注意。一是第6行使服务变成headless,二是我们不是将Kubernetes服务端口映射到应用程序的服务端口,而是映射到Envoy监听器端口。这意味着,流量首先通向Envoy。即便如此,Kubernetes也可以完美运行。
在本文中,我们看到了如何使用Envoy代理构建服务网格。其中,我们设置了所有通信都将通过网格。因此,现在网格不仅有大量有关流量的数据,而且还具有控制权。
以下链接中你可以获取我们所讨论的配置和代码:
https://github.com/dnivra26/envoy_servicemesh
原文链接:
https://www.thoughtworks.com/insights/blog/building-service-mesh-envoy-0
服务网格数据平面的关键:层层剖析Envoy配置的更多相关文章
- KubeCon 2021|使用 eBPF 代替 iptables 优化服务网格数据面性能
作者 刘旭,腾讯云高级工程师,专注容器云原生领域,有多年大规模 Kubernetes 集群管理及微服务治理经验,现负责腾讯云服务网格 TCM 数据面产品架构设计和研发工作. 引言 目前以 Istio[ ...
- 【连载】微服务网格Istio(一)
Istio基础 服务网格是用于描述构成应用程序的微服务网络以及应用之间的交互,服务网格的功能包括服务发现.负载均衡.故障恢复.指标和监控以及更加复杂的运维工作,例如A/B测试.金丝雀发布.限流.访问控 ...
- 详细教程丨如何利用Rancher和Kong实现服务网格?
服务网格(Service mesh)是当前新兴的架构模式,越来越受到人们的青睐.与Kubernetes一起,服务网格可以形成一个强大的平台,它可以解决在微服务集群或服务基础设施上发现的高度分布式环境中 ...
- 微软开源Kubernetes服务网格项目Open Service Mesh
尽管微服务环境提供可移植性,允许更快更频繁的部署周期,甚至还能让组织创建关注于特定领域的团队,但这也伴随着对于流量管理.安全以及可观测性等需求的增长.在整个生态系统中,针对这些需求的服务网格模式的实现 ...
- Service Mesh服务网格新生代——Istio
Istio 是什么?使用云平台可以为组织提供丰富的好处.然而,不可否认的是,采用云可能会给 DevOps 团队带来压力.开发人员必须使用微服务已满足应用的可移植性,同时运营商管理了极其庞大的混合和多云 ...
- 【译文连载】 理解Istio服务网格(第一章 概述)
书籍英文版下载链接为 https://developers.redhat.com/books/introducing-istio-service-mesh-microservices/,作者 Burr ...
- 服务网格istio概念应知应会
一.背景 最近架构组基于istio开发了服务网格(Service Mesh)平台,借此机会把相关的背景知识做一次学习和记录,方便回头查看. 初版的效果: 二.istio 官方手册:https://is ...
- eBPF会成为服务网格的未来吗?
服务网格现状 服务网格为服务提供了复杂的应用层网络管理,如服务发现.流量路由.弹性(超时/重试/断路).认证/授权.可观察性(日志/度量/追踪)等. 在分布式应用的早期,这些要求是通过直接将所需的逻辑 ...
- 精彩分享 | 欢乐游戏 Istio 云原生服务网格三年实践思考
作者 吴连火,腾讯游戏专家开发工程师,负责欢乐游戏大规模分布式服务器架构.有十余年微服务架构经验,擅长分布式系统领域,有丰富的高性能高可用实践经验,目前正带领团队完成云原生技术栈的全面转型. 导语 欢 ...
随机推荐
- webpack3、4的基本的使用方法
webpack的基本使用 webpack的安装 webpack的使用时需要借助 node 的环境的 在 node 中自动下载了 npm 这个包管理工具,之后的操作我们需要使用npm包管理工具进行相关操 ...
- 力扣(LeetCode)种花问题 个人题解
假设你有一个很长的花坛,一部分地块种植了花,另一部分却没有.可是,花卉不能种植在相邻的地块上,它们会争夺水源,两者都会死去. 给定一个花坛(表示为一个数组包含0和1,其中0表示没种植花,1表示种植了花 ...
- 2018.3.7java 学习第二天
java 学习的第二天,首先我们要学习的是声明变量,在程序中,我们必须先声明变量,然后才可以去使用之,那么变量究竟是什么呢? 在很多课本上,有很多的定义诸如:“变量来源于数学,是计算机语言中能储存计算 ...
- 2016 校招, Android 开发,一个本科应届的坎坷求职之路(转)
转载出处:http://www.nowcoder.com/discuss/3244?type=2&order=0&pos=1&page=1 和大多数的面经不同,我不是大牛,手头 ...
- SpringBoot 整合 Zookeeper 接入Starring微服务平台
背景 最近接的一个项目是基于公司产品Starring做的微服务支付平台,纯后台项目,实现三方支付公司和银行接口来完成用户账户扣款,整合成通用支付接口发布给前端调用. 但是扯蛋了,这边前端什么都不想做, ...
- java Random类详解
java Random类位于java.util包下,主要用来生成随机数,本文详解介绍了Random类的用法,希望能帮到大家 Random类 (java.util) Random类中实现的随机算法是伪随 ...
- 封装扩展Kendo UI Grid
封装后的代码如下: function DataGrid(options) { this.options = { height: "100%", sortable: true, re ...
- 一条数据的HBase之旅,简明HBase入门教程4:集群角色
[摘要] 本文主要介绍HBase与HDFS的关系,一些关键进程角色,以及在部署上的建议 HBase与HDFS 我们都知道HBase的数据是存储于HDFS里面的,相信大家也都有这么的认知: HBase是 ...
- Object类和@Data注解
特别说明:若是有不对的地方欢迎指正 简要概述: Object类是java中所有类默认继承的一个类.下面介绍一下Object类中的一些重要的方法,面试中也是经常会被问到的.尤其是==和equals的区别 ...
- 简单易懂的ftp脚本自动登录教程
我在上上篇<nmon脚本--对Linux服务器的监控>的脚本中,使用了ftp的自动登录.结果有人询问,遂决定专门写一篇简单易懂的博客,来说明如何解决ftp的自动登录问题. 一.Window ...