Envoy基礎(chǔ)中如何使用 Unix Domain Socket與上游集群通信

這篇文章將為大家詳細(xì)講解有關(guān)Envoy基礎(chǔ)中如何使用 Unix Domain Socket與上游集群通信，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

Envoy Proxy 在大多數(shù)情況下都是作為 Sidecar 與應(yīng)用部署在同一網(wǎng)絡(luò)環(huán)境中，每個應(yīng)用只需要與 Envoy（localhost）交互，不需要知道其他服務(wù)的地址。然而這并不是 Envoy 僅有的使用場景，它本身就是一個七層代理，通過模塊化結(jié)構(gòu)實(shí)現(xiàn)了流量治理、信息監(jiān)控等核心功能，比如流量治理功能就包括自動重連、熔斷、全局限速、流量鏡像和異常檢測等多種高級功能，因此 Envoy 也常常被用于邊緣代理，比如 Istio 的 Ingress Gateway、基于 Envoy 實(shí)現(xiàn)的 Ingress Controller（Contour、Ambassador、Gloo 等）。

我的博客也是部署在輕量級 Kubernetes 集群上的（其實(shí)是 k3s 啦），一開始使用 Contour 作為 Ingress Controller，暴露集群內(nèi)的博客、評論等服務(wù)。但好景不長，由于我在集群內(nèi)部署了各種奇奇怪怪的東西，有些個性化配置 Contour 無法滿足我的需求，畢竟大家都知道，每抽象一層就會丟失很多細(xì)節(jié)。換一個 Controller 保不齊以后還會遇到這種問題，索性就直接裸用 Envoy 作為邊緣代理，大不了手?jǐn)] YAML 唄。

當(dāng)然也不全是手?jǐn)]，雖然沒有所謂的控制平面，但儀式感還是要有的，我可以基于文件來動態(tài)更新配置啊，具體的方法參考 Envoy 基礎(chǔ)教程：基于文件系統(tǒng)動態(tài)更新配置。

1. UDS 介紹

說了那么多廢話，下面進(jìn)入正題。為了提高博客的性能，我選擇將博客與 Envoy 部署在同一個節(jié)點(diǎn)上，并且全部使用 HostNetwork 模式，Envoy 通過 localhost 與博客所在的 Pod（Nginx） 通信。為了進(jìn)一步提高性能，我盯上了 Unix Domain Socket（UDS，Unix域套接字），它還有另一個名字叫 IPC（inter-process communication，進(jìn)程間通信）。為了理解 UDS，我們先來建立一個簡單的模型。

現(xiàn)實(shí)世界中兩個人進(jìn)行信息交流的整個過程被稱作一次通信（Communication），通信的雙方被稱為端點(diǎn)（Endpoint）。工具通訊環(huán)境的不同，端點(diǎn)之間可以選擇不同的工具進(jìn)行通信，距離近可以直接對話，距離遠(yuǎn)可以選擇打電話、微信聊天。這些工具就被稱為 Socket。

同理，在計(jì)算機(jī)中也有類似的概念：

• 在 Unix 中，一次通信由兩個端點(diǎn)組成，例如 HTTP 服務(wù)端和 HTTP 客戶端。

• 端點(diǎn)之間想要通信，必須借助某些工具，Unix 中端點(diǎn)之間使用 Socket 來進(jìn)行通信。

Socket 原本是為網(wǎng)絡(luò)通信而設(shè)計(jì)的，但后來在 Socket 的框架上發(fā)展出一種 IPC 機(jī)制，就是 UDS。使用 UDS 的好處顯而易見：不需要經(jīng)過網(wǎng)絡(luò)協(xié)議棧，不需要打包拆包、計(jì)算校驗(yàn)和、維護(hù)序號和應(yīng)答等，只是將應(yīng)用層數(shù)據(jù)從一個進(jìn)程拷貝到另一個進(jìn)程。這是因?yàn)椋?strong>IPC 機(jī)制本質(zhì)上是可靠的通訊，而網(wǎng)絡(luò)協(xié)議是為不可靠的通訊設(shè)計(jì)的。

UDS 與網(wǎng)絡(luò) Socket 最明顯的區(qū)別在于，網(wǎng)絡(luò) Socket 地址是 IP 地址加端口號，而 UDS 的地址是一個 Socket 類型的文件在文件系統(tǒng)中的路徑，一般名字以 .sock 結(jié)尾。這個 Socket 文件可以被系統(tǒng)進(jìn)程引用，兩個進(jìn)程可以同時打開一個 UDS 進(jìn)行通信，而且這種通信方式只會發(fā)生在系統(tǒng)內(nèi)核里，不會在網(wǎng)絡(luò)上進(jìn)行傳播。下面就來看看如何讓 Envoy 通過 UDS 與上游集群 Nginx 進(jìn)行通信吧，它們之間的通信模型大概就是這個樣子：

2. Nginx 監(jiān)聽 UDS

首先需要修改 Nginx 的配置，讓其監(jiān)聽在 UDS 上，至于 Socket 描述符文件的存儲位置，就隨你的意了。具體需要修改 listen 參數(shù)為下面的形式：

listen      unix:/sock/hugo.sock;

當(dāng)然，如果想獲得更快的通信速度，可以放在 /dev/shm 目錄下，這個目錄是所謂的 tmpfs，它是 RAM 可以直接使用的區(qū)域，所以讀寫速度都會很快，下文會單獨(dú)說明。

3. Envoy-->UDS-->Nginx

Envoy 默認(rèn)情況下是使用 IP 地址和端口號和上游集群通信的，如果想使用 UDS 與上游集群通信，首先需要修改服務(wù)發(fā)現(xiàn)的類型，將 type 修改為 static：

type: static

同時還需將端點(diǎn)定義為 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 中來達(dá)到共享的目的，當(dāng)然最大的前提是 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: {}

現(xiàn)在你又可以愉快地訪問我的博客了，查看 Envoy 的日志，成功將請求通過 Socket 轉(zhuǎn)發(fā)給了上游集群：

[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/ 目錄下??？別急，還沒結(jié)束呢，先來補(bǔ)充一個背景知識。

4. Linux 共享內(nèi)存機(jī)制

共享內(nèi)存（shared memory），是 Linux 上一種用于進(jìn)程間通信（IPC）的機(jī)制。

進(jìn)程間通信可以使用管道，Socket，信號，信號量，消息隊(duì)列等方式，但這些方式通常需要在用戶態(tài)、內(nèi)核態(tài)之間拷貝，一般認(rèn)為會有 4 次拷貝；相比之下，共享內(nèi)存將內(nèi)存直接映射到用戶態(tài)空間，即多個進(jìn)程訪問同一塊內(nèi)存，理論上性能更高。嘿嘿，又可以改進(jìn)上面的方案了。

共享內(nèi)存有兩種機(jī)制：

• POSIX 共享內(nèi)存（shm_open()、shm_unlink()）

• System V 共享內(nèi)存（shmget()、shmat()、shmdt()）

其中，System V 共享內(nèi)存歷史悠久，一般的 UNIX 系統(tǒng)上都有這套機(jī)制；而 POSIX 共享內(nèi)存機(jī)制接口更加方便易用，一般是結(jié)合內(nèi)存映射 mmap 使用。

mmap 和 System V 共享內(nèi)存的主要區(qū)別在于：

• System V shm 是持久化的，除非被一個進(jìn)程明確的刪除，否則它始終存在于內(nèi)存里，直到系統(tǒng)關(guān)機(jī)。

• mmap 映射的內(nèi)存不是持久化的，如果進(jìn)程關(guān)閉，映射隨即失效，除非事先已經(jīng)映射到了一個文件上。

• /dev/shm 是 Linux 下 sysv 共享內(nèi)存的默認(rèn)掛載點(diǎn)。

POSIX 共享內(nèi)存是基于 tmpfs 來實(shí)現(xiàn)的。實(shí)際上，更進(jìn)一步，不僅 PSM(POSIX shared memory)，而且 SSM(System V shared memory) 在內(nèi)核也是基于 tmpfs 實(shí)現(xiàn)的。

從這里可以看到 tmpfs 主要有兩個作用：

• 用于 System V 共享內(nèi)存，還有匿名內(nèi)存映射；這部分由內(nèi)核管理，用戶不可見。

• 用于 POSIX 共享內(nèi)存，由用戶負(fù)責(zé) mount，而且一般 mount 到 /dev/shm，依賴于 CONFIG_TMPFS。

雖然 System V 與 POSIX 共享內(nèi)存都是通過 tmpfs 實(shí)現(xiàn)，但是受的限制卻不相同。也就是說 /proc/sys/kernel/shmmax 只會影響 System V 共享內(nèi)存，/dev/shm 只會影響 POSIX 共享內(nèi)存。實(shí)際上，System V 與 POSIX 共享內(nèi)存本來就是使用的兩個不同的 tmpfs 實(shí)例。

System V 共享內(nèi)存能夠使用的內(nèi)存空間只受 /proc/sys/kernel/shmmax 限制；而用戶通過掛載的 /dev/shm，默認(rèn)為物理內(nèi)存的 1/2。

概括一下：

• POSIX 共享內(nèi)存與 System V 共享內(nèi)存在內(nèi)核都是通過 tmpfs 實(shí)現(xiàn)，但對應(yīng)兩個不同的 tmpfs 實(shí)例，相互獨(dú)立。

• 通過 /proc/sys/kernel/shmmax 可以限制 System V 共享內(nèi)存的最大值，通過 /dev/shm 可以限制 POSIX 共享內(nèi)存的最大值。

5. Kubernetes 共享內(nèi)存

Kubernetes 創(chuàng)建的 Pod，其共享內(nèi)存默認(rèn) 64MB，且不可更改。

為什么是這個值呢？其實(shí)，Kubernetes 本身是沒有設(shè)置共享內(nèi)存的大小的，64MB 其實(shí)是 Docker 默認(rèn)的共享內(nèi)存的大小。

Docker run 的時候，可以通過 --shm-size 來設(shè)置共享內(nèi)存的大小：

???? → 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 并沒有提供設(shè)置 shm 大小的途徑。在這個 issue 里社區(qū)討論了很久是否要給 shm 增加一個參數(shù)，但是最終并沒有形成結(jié)論，只是有一個 workgroud 的辦法：將 Memory 類型的 emptyDir 掛載到 /dev/shm 來解決。

Kubernetes 提供了一種特殊的 emptyDir：可以將 emptyDir.medium 字段設(shè)置為 "Memory"，以告訴 Kubernetes 使用 tmpfs（基于 RAM 的文件系統(tǒng)）作為介質(zhì)。用戶可以將 Memory 介質(zhì)的 emptyDir 掛到任何目錄，然后將這個目錄當(dāng)作一個高性能的文件系統(tǒng)來使用，當(dāng)然也可以掛載到 /dev/shm，這樣就可以解決共享內(nèi)存不夠用的問題了。

使用 emptyDir 雖然可以解決問題，但也是有缺點(diǎn)的：

• 不能及時禁止用戶使用內(nèi)存。雖然過 1~2 分鐘 Kubelet 會將 Pod 擠出，但是這個時間內(nèi)，其實(shí)對 Node 還是有風(fēng)險的。

• 影響 Kubernetes 調(diào)度，因?yàn)?emptyDir 并不涉及 Node 的 Resources，這樣會造成 Pod “偷偷”使用了 Node 的內(nèi)存，但是調(diào)度器并不知曉。

• 用戶不能及時感知到內(nèi)存不可用。

由于共享內(nèi)存也會受 Cgroup 限制，我們只需要給 Pod 設(shè)置 Memory limits 就可以了。如果將 Pod 的 Memory limits 設(shè)置為共享內(nèi)存的大小，就會遇到一個問題：當(dāng)共享內(nèi)存被耗盡時，任何命令都無法執(zhí)行，只能等超時后被 Kubelet 驅(qū)逐。

這個問題也很好解決，將共享內(nèi)存的大小設(shè)置為 Memory limits 的 50% 就好。綜合以上分析，最終設(shè)計(jì)如下：

1. 將 Memory 介質(zhì)的 emptyDir 掛載到 /dev/shm/。

2. 配置 Pod 的 Memory limits。

3. 配置 emptyDir 的 sizeLimit 為 Memory limits 的 50%。

6. 最終配置

根據(jù)上面的設(shè)計(jì)，最終的配置如下。

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

關(guān)于Envoy基礎(chǔ)中如何使用 Unix Domain Socket與上游集群通信就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。