Envoy基础中如何使用UnixDomainSocket与上游集群通信
这篇文章将为大家详细讲解有关Envoy基础中如何使用 Unix Domain Socket与上游集群通信,文章内容质量较高,因此小编分享给大家做个参考,希望大家阅读完这篇文章后对相关知识有一定的了解。
站在用户的角度思考问题,与客户深入沟通,找到渭源网站设计与渭源网站推广的解决方案,凭借多年的经验,让设计与互联网技术结合,创造个性化、用户体验好的作品,建站类型包括:做网站、成都网站建设、企业官网、英文网站、手机端网站、网站推广、国际域名空间、网站空间、企业邮箱。业务覆盖渭源地区。
Envoy Proxy 在大多数情况下都是作为 Sidecar
与应用部署在同一网络环境中,每个应用只需要与 Envoy(localhost
)交互,不需要知道其他服务的地址。然而这并不是 Envoy 仅有的使用场景,它本身就是一个七层代理,通过模块化结构实现了流量治理、信息监控等核心功能,比如流量治理功能就包括自动重连、熔断、全局限速、流量镜像和异常检测等多种高级功能,因此 Envoy 也常常被用于边缘代理,比如 Istio 的 Ingress Gateway
、基于 Envoy 实现的 Ingress Controller(Contour、Ambassador、Gloo 等)。
我的博客也是部署在轻量级 Kubernetes
集群上的(其实是 k3s
啦),一开始使用 Contour
作为 Ingress Controller
,暴露集群内的博客、评论等服务。但好景不长,由于我在集群内部署了各种奇奇怪怪的东西,有些个性化配置 Contour
无法满足我的需求,毕竟大家都知道,每抽象一层就会丢失很多细节。换一个 Controller 保不齐以后还会遇到这种问题,索性就直接裸用 Envoy
作为边缘代理,大不了手撸 YAML
呗。
当然也不全是手撸,虽然没有所谓的控制平面,但仪式感还是要有的,我可以基于文件来动态更新配置啊,具体的方法参考 Envoy 基础教程:基于文件系统动态更新配置。
1. UDS 介绍
说了那么多废话,下面进入正题。为了提高博客的性能,我选择将博客与 Envoy
部署在同一个节点上,并且全部使用 HostNetwork
模式,Envoy
通过 localhost 与博客所在的 Pod(Nginx
) 通信。为了进一步提高性能,我盯上了 Unix Domain Socket(UDS,Unix域套接字),它还有另一个名字叫 IPC
(inter-process communication,进程间通信)。为了理解 UDS
,我们先来建立一个简单的模型。
现实世界中两个人进行信息交流的整个过程被称作一次通信(Communication
),通信的双方被称为端点(Endpoint
)。工具通讯环境的不同,端点之间可以选择不同的工具进行通信,距离近可以直接对话,距离远可以选择打电话、微信聊天。这些工具就被称为 Socket
。
同理,在计算机中也有类似的概念:
在
Unix
中,一次通信由两个端点组成,例如HTTP
服务端和HTTP
客户端。端点之间想要通信,必须借助某些工具,Unix 中端点之间使用
Socket
来进行通信。
Socket
原本是为网络通信而设计的,但后来在 Socket
的框架上发展出一种 IPC
机制,就是 UDS
。使用 UDS 的好处显而易见:不需要经过网络协议栈,不需要打包拆包、计算校验和、维护序号和应答等,只是将应用层数据从一个进程拷贝到另一个进程。这是因为,IPC 机制本质上是可靠的通讯,而网络协议是为不可靠的通讯设计的。
UDS
与网络 Socket 最明显的区别在于,网络 Socket地址是 IP 地址加端口号,而 UDS
的地址是一个 Socket 类型的文件在文件系统中的路径,一般名字以 .sock
结尾。这个 Socket 文件可以被系统进程引用,两个进程可以同时打开一个 UDS
进行通信,而且这种通信方式只会发生在系统内核里,不会在网络上进行传播。下面就来看看如何让 Envoy
通过 UDS
与上游集群 Nginx
进行通信吧,它们之间的通信模型大概就是这个样子:
2. Nginx 监听 UDS
首先需要修改 Nginx
的配置,让其监听在 UDS
上,至于 Socket
描述符文件的存储位置,就随你的意了。具体需要修改 listen
参数为下面的形式:
listen unix:/sock/hugo.sock;
当然,如果想获得更快的通信速度,可以放在 /dev/shm
目录下,这个目录是所谓的 tmpfs
,它是 RAM
可以直接使用的区域,所以读写速度都会很快,下文会单独说明。
3. Envoy-->UDS-->Nginx
Envoy
默认情况下是使用 IP 地址和端口号和上游集群通信的,如果想使用 UDS
与上游集群通信,首先需要修改服务发现的类型,将 type
修改为 static
:
type: static
同时还需将端点定义为 UDS:
- endpoint: address: pipe: path: "/sock/hugo.sock"
最终的 Cluster 配置如下:
- "@type": type.googleapis.com/envoy.api.v2.Cluster name: hugo connect_timeout: 15s type: static load_assignment: cluster_name: hugo endpoints: - lb_endpoints: - endpoint: address: pipe: path: "/sock/hugo.sock"
最后要让 Envoy
能够访问 Nginx
的 Socket
文件,Kubernetes 中可以将同一个 emptyDir
挂载到两个 Container 中来达到共享的目的,当然最大的前提是 Pod 中的 Container 是共享 IPC 的。配置如下:
spec: ... template: ... spec: containers: - name: envoy ... volumeMounts: - mountPath: /sock name: hugo-socket ... - name: hugo ... volumeMounts: - mountPath: /sock name: hugo-socket ... volumes: ... - name: hugo-socket emptyDir: {}
现在你又可以愉快地访问我的博客了,查看 Envoy
的日志,成功将请求通过 Socket
转发给了上游集群:
[2020-04-27T02:49:47.943Z] "GET /posts/prometheus-histograms/ HTTP/1.1" 200 - 0 169949 1 0 "66.249.64.209,45.145.38.4" "Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.96 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" "9d490b2d-7c18-4dc7-b815-97f11bfc04d5" "fuckcloudnative.io" "/dev/shm/hugo.sock"
嘿嘿,Google
的爬虫也来凑热闹。
你可能会问我:你这里的 Socket 为什么在 /dev/shm/
目录下啊?别急,还没结束呢,先来补充一个背景知识。
4. Linux 共享内存机制
共享内存(shared memory),是 Linux
上一种用于进程间通信(IPC)的机制。
进程间通信可以使用管道,Socket,信号,信号量,消息队列等方式,但这些方式通常需要在用户态、内核态之间拷贝,一般认为会有 4 次拷贝;相比之下,共享内存将内存直接映射到用户态空间,即多个进程访问同一块内存,理论上性能更高。嘿嘿,又可以改进上面的方案了。
共享内存有两种机制:
POSIX
共享内存(shm_open()、shm_unlink()
)System V
共享内存(shmget()、shmat()、shmdt()
)
其中,System V
共享内存历史悠久,一般的 UNIX
系统上都有这套机制;而 POSIX
共享内存机制接口更加方便易用,一般是结合内存映射 mmap
使用。
mmap
和 System V
共享内存的主要区别在于:
System V shm 是持久化的,除非被一个进程明确的删除,否则它始终存在于内存里,直到系统关机。
mmap
映射的内存不是持久化的,如果进程关闭,映射随即失效,除非事先已经映射到了一个文件上。/dev/shm
是 Linux 下 sysv 共享内存的默认挂载点。
POSIX
共享内存是基于 tmpfs
来实现的。实际上,更进一步,不仅 PSM
(POSIX shared memory),而且 SSM
(System V shared memory) 在内核也是基于 tmpfs
实现的。
从这里可以看到 tmpfs
主要有两个作用:
用于
System V
共享内存,还有匿名内存映射;这部分由内核管理,用户不可见。用于
POSIX
共享内存,由用户负责mount
,而且一般 mount 到/dev/shm
,依赖于CONFIG_TMPFS
。
虽然 System V 与 POSIX 共享内存都是通过 tmpfs 实现,但是受的限制却不相同。也就是说 /proc/sys/kernel/shmmax 只会影响 System V 共享内存,/dev/shm 只会影响 POSIX 共享内存。实际上,System V
与 POSIX
共享内存本来就是使用的两个不同的 tmpfs
实例。
System V
共享内存能够使用的内存空间只受 /proc/sys/kernel/shmmax
限制;而用户通过挂载的 /dev/shm
,默认为物理内存的 1/2
。
概括一下:
POSIX
共享内存与System V
共享内存在内核都是通过tmpfs
实现,但对应两个不同的tmpfs
实例,相互独立。通过
/proc/sys/kernel/shmmax
可以限制System V
共享内存的最大值,通过/dev/shm
可以限制POSIX
共享内存的最大值。
5. Kubernetes 共享内存
Kubernetes
创建的 Pod,其共享内存默认 64MB
,且不可更改。
为什么是这个值呢?其实,Kubernetes 本身是没有设置共享内存的大小的,64MB
其实是 Docker
默认的共享内存的大小。
Docker run 的时候,可以通过 --shm-size
来设置共享内存的大小:
???? → docker run --rm centos:7 df -h |grep shm shm 64M 0 64M 0% /dev/shm ???? → docker run --rm --shm-size 128M centos:7 df -h |grep shm shm 128M 0 128M 0% /dev/shm
然而,Kubernetes 并没有提供设置 shm
大小的途径。在这个 issue 里社区讨论了很久是否要给 shm
增加一个参数,但是最终并没有形成结论,只是有一个 workgroud 的办法:将 Memory
类型的 emptyDir
挂载到 /dev/shm
来解决。
Kubernetes 提供了一种特殊的 emptyDir
:可以将 emptyDir.medium
字段设置为 "Memory"
,以告诉 Kubernetes 使用 tmpfs
(基于 RAM 的文件系统)作为介质。用户可以将 Memory 介质的 emptyDir
挂到任何目录,然后将这个目录当作一个高性能的文件系统来使用,当然也可以挂载到 /dev/shm
,这样就可以解决共享内存不够用的问题了。
使用 emptyDir 虽然可以解决问题,但也是有缺点的:
不能及时禁止用户使用内存。虽然过 1~2 分钟
Kubelet
会将Pod
挤出,但是这个时间内,其实对Node
还是有风险的。影响 Kubernetes 调度,因为
emptyDir
并不涉及 Node 的Resources
,这样会造成 Pod “偷偷”使用了 Node 的内存,但是调度器并不知晓。用户不能及时感知到内存不可用。
由于共享内存也会受 Cgroup
限制,我们只需要给 Pod 设置 Memory limits
就可以了。如果将 Pod 的 Memory limits
设置为共享内存的大小,就会遇到一个问题:当共享内存被耗尽时,任何命令都无法执行,只能等超时后被 Kubelet 驱逐。
这个问题也很好解决,将共享内存的大小设置为 Memory limits
的 50%
就好。综合以上分析,最终设计如下:
将 Memory 介质的
emptyDir
挂载到/dev/shm/
。配置 Pod 的
Memory limits
。配置
emptyDir
的sizeLimit
为Memory limits
的 50%。
6. 最终配置
根据上面的设计,最终的配置如下。
Nginx
的配置改为:
listen unix:/dev/shm/hugo.sock;
Envoy
的配置改为:
- "@type": type.googleapis.com/envoy.api.v2.Cluster name: hugo connect_timeout: 15s type: static load_assignment: cluster_name: hugo endpoints: - lb_endpoints: - endpoint: address: pipe: path: "/dev/shm/hugo.sock"
Kubernetes 的 manifest
改为:
spec: ... template: ... spec: containers: - name: envoy resources: limits: memory: 256Mi ... volumeMounts: - mountPath: /dev/shm name: hugo-socket ... - name: hugo resources: limits: memory: 256Mi ... volumeMounts: - mountPath: /dev/shm name: hugo-socket ... volumes: ... - name: hugo-socket emptyDir: medium: Memory sizeLimit: 128Mi
关于Envoy基础中如何使用 Unix Domain Socket与上游集群通信就分享到这里了,希望以上内容可以对大家有一定的帮助,可以学到更多知识。如果觉得文章不错,可以把它分享出去让更多的人看到。
网页题目:Envoy基础中如何使用UnixDomainSocket与上游集群通信
标题路径:http://scyanting.com/article/jdcppi.html