摘要：一些公共服務組件在追求性能過程中，與業務耦合太緊，造成在制作基礎鏡像時，都會把這些基礎組件都打包進去，因此當業務鏡像啟動後，容器裏面一大堆進程，這讓Kubernetes對Pod的管理存在很大隱患。為了讓業務容器瘦身，更是為了基礎組件自身的管理更獨立和方便，將基礎組件從業務鏡像中剝離並DaemonSet容器化部署。然而一些基礎組件Agent與業務Pod之間通過共享內存的方式進行通信，同一Node中跨Pod的共享內存方案是首先要解決的問題。

為什麽要將公共基礎組件Agent進行DaemonSet部署
自研的公共基礎組件，比如服務路由組件、安全組件等，通常以進程方式部署在Node上並同時為Node上所有的業務提供服務，微服務及容器化之後，服務數量成百上千的增長，如果以sidecar或者打包到業務Image中繼續Per Pod Per Agent的方式部署, 那麽基礎組件的Server端的壓力可能也會成百上千的增長，風險是很大的。因此，我們希望能以DaemonSet方式部署這些組件的Agents。

先說說Kubernetes大行其道的今天，如果不將這些基礎組件從業務Pod中剝離，存在哪些問題：

業務容器中存在一大堆進程，我們在為Pod申請資源(cpu/mem request and limit)時，不僅要考慮業務應用本身的資源消耗，還要考慮這些基礎組件的資源消耗。而且一旦某些Agent有Bug，比如內存泄漏，這將導致Pod牽連被重建，甚至Cgroup OOM在kill進程時，可能將業務進程kill了。

違背了Kubernetes&微服務的部署最佳實踐：Per Process Per Contaienr，並且業務進程在前臺運行，使其與容器共生死，不然這將導致Kubernetes無法根據業務進程狀態關聯到容器狀態，進而進行高可用管理。

一個Node上運行10個Pod，那麽就會有x10的基礎組件數量在Node上。沒有容器化之前，一個Node只要部署一個組件進程即可，容器化之後，集群中組件Agents數量要幾十倍的增長,如果業務進行了微服務拆分，這個指數會更大，這些基礎組件服務端是否能承受比以往高幾十倍上百倍的通信請求，這是未知的。

如果你要全網升級某個基礎組件Agent，那你可能會瘋掉，你需要重新打所有業務鏡像，然後全網業務要進行灰度升級。因為一個Agent的升級，導致你不得不重建業務Pod。你可能會說，基礎組件Agents都會有自己的熱升級方案，我們通過它們的方案升級就好了呀，那你將引入很×××煩：Agents的熱升級因為無法被Kubernetes感知，將引發Kubernetes中集群中的數據不一致問題，那就真的要回到虛擬機或者物理機部署的玩法了。當然，這樣的需求，我們也想過通過Operator也實現，但代價太大了，而且很不CloudNative！

將基礎組件Agents從業務Pod中剝離，以上的問題都能解決了，架構上的解耦帶來的好處無需多言。而且我們可以通過Kubernetes管理這些基礎組件Agents了，享受其自愈、滾動升級等好處。

Linux共享內存機制
然而，理想很美好，現實很殘酷。首先要解決的問題是，有些組件Agent與業務Pod之間是通過共享內存通信的，這跟Kubernetes&微服務的最佳實踐背道而馳。

大家都知道，Kubernetes單個Pod內是共享IPC的，並且可以通過掛載Medium為Memory的EmptyDir Volume共享同一塊內存Volume。

首先我們來了解一下Linux共享內存的兩種機制：

POSIX共享內存（shm_open()、shm_unlink()）

System V共享內存（shmget()、shmat()、shmdt()）

其中，System V共享內存歷史悠久，一般的UNIX系統上都有這套機制；而POSIX共享內存機制接口更加方便易用，一般是結合內存映射mmap使用。

mmap和System V共享內存的主要區別在於：

sysv shm是持久化的，除非被一個進程明確的刪除，否則它始終存在於內存裏，直到系統關機；

mmap映射的內存在不是持久化的，如果進程關閉，映射隨即失效，除非事先已經映射到了一個文件上。

/dev/shm 是Linux下sysv共享內存的默認掛載點。

POSIX共享內存是基於tmpfs來實現的。實際上，更進一步，不僅PSM(POSIX shared memory)，而且SSM(System V shared memory)在內核也是基於tmpfs實現的。

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

用於SYSV共享內存，還有匿名內存映射；這部分由內核管理，用戶不可見；

用於POSIX共享內存，由用戶負責mount，而且一般mount到/dev/shm ；依賴於CONFIG_TMPFS;

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

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

概括一下：

POSIX共享內存與SYS V共享內存在內核都是通過tmpfs實現，但對應兩個不同的tmpfs實例，相互獨立。

通過/proc/sys/kernel/shmmax可以限制SYS V共享內存的最大值，通過/dev/shm可以限制POSIX共享內存的最大值(所有之和)。

同一Node上誇Pod的共享內存方案
基礎組件Agents DaemonSet部署後，Agents和業務Pod分別在同一個Node上不同的Pod，那麽Kubernetes該如何支持這兩種類型的共享內存機制呢？

當然，安全性上做出了犧牲，但在非容器化之前IPC的隔離也是沒有的，所以這一點是可以接受的。

灰度上線
對於集群中的存量業務，之前都是將Agents與業務打包在同一個docker image，因此需要有灰度上線方案，以保證存量業務不受影響。

首先創建好對應的Kubernetes ClusterRole, SA, ClusterRoleBinding, PSP Object。

在集群中任意選擇部分Node，給Node打上Label（AgentsDaemonSet:YES）和Taint(AgentsDaemonSet=YES:NoSchedule)。

$ kubectl label node $nodeName AgentsDaemonSet=YES
$ kubectl taint node $nodeName AgentsDaemonSet=YES:NoSchedule

部署Agent對應的DaemonSet（註意DaemonSet需要加上對應的NodeSelector和Toleration, Critical Pod Annotations), Sample as follows：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: demo-agent
  namespace: kube-system
  labels:
    k8s-app: demo-agent
spec:
  selector:
    matchLabels:
      name: demo-agent
  template:
    metadata:
      annotations:
        scheduler.alpha.kubernetes.io/critical-pod: ""
      labels:
        name: demo-agent
    spec:
      tolerations:
      - key: "AgentsDaemonSet"
        operator: "Equal"
        value: "YES"
        effect: "NoSchedule"
      hostNetwork: true
      hostIPC: true
      nodeSelector:
        AgentsDaemonSet: "YES"
      containers:
      - name: demo-agent
        image: demo_agent:1.0
        volumeMounts:
        - mountPath: /dev/shm
          name: shm
        resources:
          limits:
            cpu: 200m
            memory: 200Mi
          requests:
            cpu: 100m
            memory: 100Mi
      volumes:
      - name: shm
        hostPath:
          path: /dev/shm
          type: Directory

在該Node上部署不包含基礎組件Agent的業務Pod，檢查所有基礎組件和業務是否正常工作，如果正常，再分批次選擇剩余Nodes，加上Label（AgentsDaemonSet:YES）和Taint(AgentsDaemonSet=YES:NoSchedule)，DaemonSet Controller會自動在這些Nodes創建這些DaemonSet Agents Pod。如此逐批次完成集群中基礎組件Agents的灰度上線。
總結
在高並發業務下，尤其還是以C/C++代碼實現的基礎組件，經常會使用共享內存通信機制來追求高性能，本文給出了Kubernetes Pod間Posix/SystemV共享內存方式的折中方案，以犧牲一定的安全性為代價，請知悉。當然，如果微服務/容器化改造後，基礎服務的Server端確定不會有壓力，那麽建議以SideCar Container方式將基礎服務的Agents與業務Container部署在同一Pod中，利用Pod的共享IPC特性及Memory Medium EmptyDir Volume方式共享內存。

Kubernetes中Pod間共享內存方案