如何理解Kubernetes中Pod間共享內(nèi)存，針對這個問題，這篇文章詳細介紹了相對應(yīng)的分析和解答，希望可以幫助更多想解決這個問題的小伙伴找到更簡單易行的方法。
一些公共服務(wù)組件在追求性能過程中，與業(yè)務(wù)耦合太緊，造成在制作基礎(chǔ)鏡像時，都會把這些基礎(chǔ)組件都打包進去，因此當業(yè)務(wù)鏡像啟動后，容器里面一大堆進程，這讓Kubernetes對Pod的管理存在很大隱患。為了讓業(yè)務(wù)容器瘦身，更是為了基礎(chǔ)組件自身的管理更獨立和方便，將基礎(chǔ)組件從業(yè)務(wù)鏡像中剝離并DaemonSet容器化部署。然而一些基礎(chǔ)組件Agent與業(yè)務(wù)Pod之間通過共享內(nèi)存的方式進行通信，同一Node中跨Pod的共享內(nèi)存方案是首先要解決的問題。
一、為什么要將公共基礎(chǔ)組件Agent進行DaemonSet部署自研的公共基礎(chǔ)組件，比如服務(wù)路由組件、安全組件等，通常以進程方式部署在Node上并同時為Node上所有的業(yè)務(wù)提供服務(wù)，微服務(wù)及容器化之后，服務(wù)數(shù)量成百上千的增長，如果以sidecar或者打包到業(yè)務(wù)Image中繼續(xù)Per Pod Per Agent的方式部署, 那么基礎(chǔ)組件的Server端的壓力可能也會成百上千的增長，風險是很大的。因此，我們希望能以DaemonSet方式部署這些組件的Agents。
先說說Kubernetes大行其道的今天，如果不將這些基礎(chǔ)組件從業(yè)務(wù)Pod中剝離，存在哪些問題：
業(yè)務(wù)容器中存在一大堆進程，我們在為Pod申請資源(cpu/mem request and limit)時，不僅要考慮業(yè)務(wù)應(yīng)用本身的資源消耗，還要考慮這些基礎(chǔ)組件的資源消耗。而且一旦某些Agent有Bug，比如內(nèi)存泄漏，這將導致Pod牽連被重建，甚至Cgroup OOM在kill進程時，可能將業(yè)務(wù)進程kill了。
違背了Kubernetes&微服務(wù)的部署最佳實踐：Per Process Per Contaienr，并且業(yè)務(wù)進程在前臺運行，使其與容器共生死，不然這將導致Kubernetes無法根據(jù)業(yè)務(wù)進程狀態(tài)關(guān)聯(lián)到容器狀態(tài)，進而進行高可用管理。
一個Node上運行10個Pod，那么就會有x10的基礎(chǔ)組件數(shù)量在Node上。沒有容器化之前，一個Node只要部署一個組件進程即可，容器化之后，集群中組件Agents數(shù)量要幾十倍的增長,如果業(yè)務(wù)進行了微服務(wù)拆分，這個指數(shù)會更大，這些基礎(chǔ)組件服務(wù)端是否能承受比以往高幾十倍上百倍的通信請求，這是未知的。
如果你要全網(wǎng)升級某個基礎(chǔ)組件Agent，那你可能會瘋掉，你需要重新打所有業(yè)務(wù)鏡像，然后全網(wǎng)業(yè)務(wù)要進行灰度升級。因為一個Agent的升級，導致你不得不重建業(yè)務(wù)Pod。你可能會說，基礎(chǔ)組件Agents都會有自己的熱升級方案，我們通過它們的方案升級就好了呀，那你將引入很大麻煩：Agents的熱升級因為無法被Kubernetes感知，將引發(fā)Kubernetes中集群中的數(shù)據(jù)不一致問題，那就真的要回到虛擬機或者物理機部署的玩法了。當然，這樣的需求，我們也想過通過Operator也實現(xiàn)，但代價太大了，而且很不CloudNative！
將基礎(chǔ)組件Agents從業(yè)務(wù)Pod中剝離，以上的問題都能解決了，架構(gòu)上的解耦帶來的好處無需多言。而且我們可以通過Kubernetes管理這些基礎(chǔ)組件Agents了，享受其自愈、滾動升級等好處。
二、Linux共享內(nèi)存機制然而，理想很美好，現(xiàn)實很殘酷。首先要解決的問題是，有些組件Agent與業(yè)務(wù)Pod之間是通過共享內(nèi)存通信的，這跟Kubernetes&微服務(wù)的最佳實踐背道而馳。
大家都知道，Kubernetes單個Pod內(nèi)是共享IPC的，并且可以通過掛載Medium為Memory的EmptyDir Volume共享同一塊內(nèi)存Volume。
首先我們來了解一下Linux共享內(nèi)存的兩種機制：
POSIX共享內(nèi)存（shm_open()、shm_unlink()）
System V共享內(nèi)存（shmget()、shmat()、shmdt()）
其中，System V共享內(nèi)存歷史悠久，一般的UNIX系統(tǒng)上都有這套機制；而POSIX共享內(nèi)存機制接口更加方便易用，一般是結(jié)合內(nèi)存映射mmap使用。
mmap和System V共享內(nèi)存的主要區(qū)別在于：
sysv shm是持久化的，除非被一個進程明確的刪除，否則它始終存在于內(nèi)存里，直到系統(tǒng)關(guān)機
mmap映射的內(nèi)存在不是持久化的，如果進程關(guān)閉，映射隨即失效，除非事先已經(jīng)映射到了一個文件上
/dev/shm 是Linux下sysv共享內(nèi)存的默認掛載點
POSIX共享內(nèi)存是基于tmpfs來實現(xiàn)的。實際上，更進一步，不僅PSM(POSIX shared memory)，而且SSM(System V shared memory)在內(nèi)核也是基于tmpfs實現(xiàn)的。
從這里可以看到tmpfs主要有兩個作用：
用于SYSV共享內(nèi)存，還有匿名內(nèi)存映射；這部分由內(nèi)核管理，用戶不可見
用于POSIX共享內(nèi)存，由用戶負責mount，而且一般mount到/dev/shm ；依賴于CONFIG_TMPFS
雖然System V與POSIX共享內(nèi)存都是通過tmpfs實現(xiàn)，但是受的限制卻不相同。也就是說 /proc/sys/kernel/shmmax只會影響SYS V共享內(nèi)存，/dev/shm只會影響Posix共享內(nèi)存 。實際上，System V與Posix共享內(nèi)存本來就是使用的兩個不同的tmpfs實例(instance)。
SYS V共享內(nèi)存能夠使用的內(nèi)存空間只受/proc/sys/kernel/shmmax限制；而用戶通過掛載的/dev/shm，默認為物理內(nèi)存的1/2。
三、同一Node上夸Pod的共享內(nèi)存方案概括一下：
POSIX共享內(nèi)存與SYS V共享內(nèi)存在內(nèi)核都是通過tmpfs實現(xiàn)，但對應(yīng)兩個不同的tmpfs實例，相互獨立。
通過/proc/sys/kernel/shmmax可以限制SYS V共享內(nèi)存的大值，通過/dev/shm可以限制POSIX共享內(nèi)存的大值(所有之和)。
基礎(chǔ)組件Agents DaemonSet部署后，Agents和業(yè)務(wù)Pod分別在同一個Node上不同的Pod，那么Kubernetes該如何支持這兩種類型的共享內(nèi)存機制呢？
當然，安全性上做出了犧牲，但在非容器化之前IPC的隔離也是沒有的，所以這一點是可以接受的。
四、灰度上線對于集群中的存量業(yè)務(wù)，之前都是將Agents與業(yè)務(wù)打包在同一個docker image，因此需要有灰度上線方案，以保證存量業(yè)務(wù)不受影響。
首先創(chuàng)建好對應(yīng)的Kubernetes ClusterRole, SA, ClusterRoleBinding, PSP Object。關(guān)于PSP 的內(nèi)容，請參考官方文檔介紹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（安卓系統(tǒng)可左右滑動查看全部代碼）
部署Agent對應(yīng)的DaemonSet（注意DaemonSet需要加上對應(yīng)的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上部署不包含基礎(chǔ)組件Agent的業(yè)務(wù)Pod，檢查所有基礎(chǔ)組件和業(yè)務(wù)是否正常工作，如果正常，再分批次選擇剩余Nodes，加上Label（AgentsDaemonSet:YES）和Taint(AgentsDaemonSet=YES:NoSchedule)，DaemonSet Controller會自動在這些Nodes創(chuàng)建這些DaemonSet Agents Pod。如此逐批次完成集群中基礎(chǔ)組件Agents的灰度上線。
在高并發(fā)業(yè)務(wù)下，尤其還是以C/C++代碼實現(xiàn)的基礎(chǔ)組件，經(jīng)常會使用共享內(nèi)存通信機制來追求高性能，小編給出了Kubernetes Pod間Posix/SystemV共享內(nèi)存方式的折中方案，以犧牲一定的安全性為代價，請知悉。當然，如果微服務(wù)/容器化改造后，基礎(chǔ)服務(wù)的Server端確定不會有壓力，那么建議以SideCar Container方式將基礎(chǔ)服務(wù)的Agents與業(yè)務(wù)Container部署在同一Pod中，利用Pod的共享IPC特性及Memory Medium EmptyDir Volume方式共享內(nèi)存。
關(guān)于如何理解Kubernetes中Pod間共享內(nèi)存問題的解答就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道了解更多相關(guān)知識。
