Kubernetes中Pod間共享記憶體方案

然而，理想很美好，現實很殘酷。首先要解決的問題是，有些元件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共享記憶體的最大值(所有之和)。

基礎元件Agents DaemonSet部署後，Agents和業務Pod分別在同一個Node上不同的Pod，那麼Kubernetes該如何支援這兩種型別的共享記憶體機制呢？

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

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

• 首先建立好對應的Kubernetes ClusterRole, SA, ClusterRoleBinding, PSP Object。關於PSP 的內容，請參考官方文件介紹pod-security-policy。

• 在叢集中任意選擇部分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的灰度上線。