如何理解Kubernetes中Pod間共享內(nèi)存-創(chuàng)新互聯(lián)

如何理解Kubernetes中Pod間共享內(nèi)存，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

長(zhǎng)白網(wǎng)站建設(shè)公司成都創(chuàng)新互聯(lián)公司,長(zhǎng)白網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為長(zhǎng)白近千家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站制作要多少錢(qián)，請(qǐng)找那個(gè)售后服務(wù)好的長(zhǎng)白做網(wǎng)站的公司定做！

一些公共服務(wù)組件在追求性能過(guò)程中，與業(yè)務(wù)耦合太緊，造成在制作基礎(chǔ)鏡像時(shí)，都會(huì)把這些基礎(chǔ)組件都打包進(jìn)去，因此當(dāng)業(yè)務(wù)鏡像啟動(dòng)后，容器里面一大堆進(jìn)程，這讓Kubernetes對(duì)Pod的管理存在很大隱患。為了讓業(yè)務(wù)容器瘦身，更是為了基礎(chǔ)組件自身的管理更獨(dú)立和方便，將基礎(chǔ)組件從業(yè)務(wù)鏡像中剝離并DaemonSet容器化部署。然而一些基礎(chǔ)組件Agent與業(yè)務(wù)Pod之間通過(guò)共享內(nèi)存的方式進(jìn)行通信，同一Node中跨Pod的共享內(nèi)存方案是首先要解決的問(wèn)題。

一、為什么要將公共基礎(chǔ)組件Agent進(jìn)行DaemonSet部署

自研的公共基礎(chǔ)組件，比如服務(wù)路由組件、安全組件等，通常以進(jìn)程方式部署在Node上并同時(shí)為Node上所有的業(yè)務(wù)提供服務(wù)，微服務(wù)及容器化之后，服務(wù)數(shù)量成百上千的增長(zhǎng)，如果以sidecar或者打包到業(yè)務(wù)Image中繼續(xù)Per Pod Per Agent的方式部署, 那么基礎(chǔ)組件的Server端的壓力可能也會(huì)成百上千的增長(zhǎng)，風(fēng)險(xiǎn)是很大的。因此，我們希望能以DaemonSet方式部署這些組件的Agents。

先說(shuō)說(shuō)Kubernetes大行其道的今天，如果不將這些基礎(chǔ)組件從業(yè)務(wù)Pod中剝離，存在哪些問(wèn)題：

  • 業(yè)務(wù)容器中存在一大堆進(jìn)程，我們?cè)跒镻od申請(qǐng)資源(cpu/mem request and limit)時(shí)，不僅要考慮業(yè)務(wù)應(yīng)用本身的資源消耗，還要考慮這些基礎(chǔ)組件的資源消耗。而且一旦某些Agent有Bug，比如內(nèi)存泄漏，這將導(dǎo)致Pod牽連被重建，甚至Cgroup OOM在kill進(jìn)程時(shí)，可能將業(yè)務(wù)進(jìn)程kill了。

  • 違背了Kubernetes&微服務(wù)的部署最佳實(shí)踐：Per Process Per Contaienr，并且業(yè)務(wù)進(jìn)程在前臺(tái)運(yùn)行，使其與容器共生死，不然這將導(dǎo)致Kubernetes無(wú)法根據(jù)業(yè)務(wù)進(jìn)程狀態(tài)關(guān)聯(lián)到容器狀態(tài)，進(jìn)而進(jìn)行高可用管理。

  • 一個(gè)Node上運(yùn)行10個(gè)Pod，那么就會(huì)有x10的基礎(chǔ)組件數(shù)量在Node上。沒(méi)有容器化之前，一個(gè)Node只要部署一個(gè)組件進(jìn)程即可，容器化之后，集群中組件Agents數(shù)量要幾十倍的增長(zhǎng),如果業(yè)務(wù)進(jìn)行了微服務(wù)拆分，這個(gè)指數(shù)會(huì)更大，這些基礎(chǔ)組件服務(wù)端是否能承受比以往高幾十倍上百倍的通信請(qǐng)求，這是未知的。

  • 如果你要全網(wǎng)升級(jí)某個(gè)基礎(chǔ)組件Agent，那你可能會(huì)瘋掉，你需要重新打所有業(yè)務(wù)鏡像，然后全網(wǎng)業(yè)務(wù)要進(jìn)行灰度升級(jí)。因?yàn)橐粋€(gè)Agent的升級(jí)，導(dǎo)致你不得不重建業(yè)務(wù)Pod。你可能會(huì)說(shuō)，基礎(chǔ)組件Agents都會(huì)有自己的熱升級(jí)方案，我們通過(guò)它們的方案升級(jí)就好了呀，那你將引入很大麻煩：Agents的熱升級(jí)因?yàn)闊o(wú)法被Kubernetes感知，將引發(fā)Kubernetes中集群中的數(shù)據(jù)不一致問(wèn)題，那就真的要回到虛擬機(jī)或者物理機(jī)部署的玩法了。當(dāng)然，這樣的需求，我們也想過(guò)通過(guò)Operator也實(shí)現(xiàn)，但代價(jià)太大了，而且很不CloudNative！

將基礎(chǔ)組件Agents從業(yè)務(wù)Pod中剝離，以上的問(wèn)題都能解決了，架構(gòu)上的解耦帶來(lái)的好處無(wú)需多言。而且我們可以通過(guò)Kubernetes管理這些基礎(chǔ)組件Agents了，享受其自愈、滾動(dòng)升級(jí)等好處。

二、Linux共享內(nèi)存機(jī)制

然而，理想很美好，現(xiàn)實(shí)很殘酷。首先要解決的問(wèn)題是，有些組件Agent與業(yè)務(wù)Pod之間是通過(guò)共享內(nèi)存通信的，這跟Kubernetes&微服務(wù)的最佳實(shí)踐背道而馳。

大家都知道，Kubernetes單個(gè)Pod內(nèi)是共享IPC的，并且可以通過(guò)掛載Medium為Memory的EmptyDir Volume共享同一塊內(nèi)存Volume。

首先我們來(lái)了解一下Linux共享內(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ū)別在于：

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

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

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

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

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

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

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

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

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

概括一下：

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

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

三、同一Node上夸Pod的共享內(nèi)存方案

基礎(chǔ)組件Agents DaemonSet部署后，Agents和業(yè)務(wù)Pod分別在同一個(gè)Node上不同的Pod，那么Kubernetes該如何支持這兩種類(lèi)型的共享內(nèi)存機(jī)制呢？

如何理解Kubernetes中Pod間共享內(nèi)存

當(dāng)然，安全性上做出了犧牲，但在非容器化之前IPC的隔離也是沒(méi)有的，所以這一點(diǎn)是可以接受的。

四、灰度上線

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

  • 首先創(chuàng)建好對(duì)應(yīng)的Kubernetes ClusterRole, SA, ClusterRoleBinding, PSP Object。關(guān)于PSP 的內(nèi)容，請(qǐng)參考官方文檔介紹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)可左右滑動(dòng)查看全部代碼）

  • 部署Agent對(duì)應(yīng)的DaemonSet（注意DaemonSet需要加上對(duì)應(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會(huì)自動(dòng)在這些Nodes創(chuàng)建這些DaemonSet Agents Pod。如此逐批次完成集群中基礎(chǔ)組件Agents的灰度上線。

在高并發(fā)業(yè)務(wù)下，尤其還是以C/C++代碼實(shí)現(xiàn)的基礎(chǔ)組件，經(jīng)常會(huì)使用共享內(nèi)存通信機(jī)制來(lái)追求高性能，小編給出了Kubernetes Pod間Posix/SystemV共享內(nèi)存方式的折中方案，以犧牲一定的安全性為代價(jià)，請(qǐng)知悉。當(dāng)然，如果微服務(wù)/容器化改造后，基礎(chǔ)服務(wù)的Server端確定不會(huì)有壓力，那么建議以SideCar Container方式將基礎(chǔ)服務(wù)的Agents與業(yè)務(wù)Container部署在同一Pod中，利用Pod的共享IPC特性及Memory Medium EmptyDir Volume方式共享內(nèi)存。

關(guān)于如何理解Kubernetes中Pod間共享內(nèi)存問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道了解更多相關(guān)知識(shí)。

本文題目：如何理解Kubernetes中Pod間共享內(nèi)存-創(chuàng)新互聯(lián)
轉(zhuǎn)載源于：http://bm7419.com/article14/dseige.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供品牌網(wǎng)站建設(shè)、服務(wù)器托管、定制網(wǎng)站、做網(wǎng)站、關(guān)鍵詞優(yōu)化、App設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)

成都定制網(wǎng)站建設(shè)