然而，理想很美好，現實很殘酷。首先要解決的問題是，有些組件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的灰度上線。