您好,欢迎来到海东市亚博APP安全有保障有限公司

您当前的位置:首页 > 新闻中心 > 行业行动

Kubernetes中Pod间共享内存方案

发布者: 亚博app发布时间:2021-04-07

本文摘要:概要:一些公共服务组件在执着性能过程中,与业务耦合太紧,导致在制作基础镜像时,都会把这些基础组件都包进来,因此当业务镜像启动后,容器里面一大堆进程,这让Kubernetes对Pod的管理不存在相当大隐患。

亚博app安全有保障

概要:一些公共服务组件在执着性能过程中,与业务耦合太紧,导致在制作基础镜像时,都会把这些基础组件都包进来,因此当业务镜像启动后,容器里面一大堆进程,这让Kubernetes对Pod的管理不存在相当大隐患。为了让业务容器瘦身,堪称为了基础组件自身的管理更加独立国家和便利,将基础组件从业务镜像中挤压并DaemonSet容器化部署。然而一些基础组件Agent与业务Pod之间通过共享内存的方式展开通信,同一Node中横跨Pod的共享内存方案是首先要解决问题的问题。

目录:一、为什么要将公共基础组件Agent展开DaemonSet部署二、Linux共享内存机制三、同一Node上弗Pod的共享内存方案四、灰度上线一、为什么要将公共基础组件Agent展开DaemonSet部署自研的公共基础组件,比如服务路由组件、安全性组件等,一般来说以进程方式部署在Node上并同时为Node上所有的业务获取服务,微服务及容器化之后,服务数量成百上千的快速增长,如果以sidecar或者包到业务Image中之后PerPodPerAgent的方式部署,那么基础组件的Server端的压力有可能也不会成百上千的快速增长,风险是相当大的。因此,我们期望能以DaemonSet方式部署这些组件的Agents。

再行说道说道Kubernetes大行其道的今天,如果不将这些基础组件从业务Pod中挤压,不存在哪些问题:业务容器中不存在一大堆进程,我们在为Pod申请人资源(cpu/memrequestandlimit)时,不仅要考虑到业务应用于本身的资源消耗,还要考虑到这些基础组件的资源消耗。而且一旦某些Agent有Bug,比如内存外泄,这将造成Pod株连被修复,甚至CgroupOOM在kill进程时,有可能将业务进程kill了。违反了Kubernetes&微服务的部署最佳实践中:PerProcessPerContaienr,并且业务进程在前台运营,使其与容器共生死,不然这将造成Kubernetes无法根据业务进程状态关联到容器状态,进而展开低能用管理。

一个Node上运营10个Pod,那么就不会有x10的基础组件数量在Node上。没容器化之前,一个Node只要部署一个组件进程才可,容器化之后,集群中组件Agents数量要几十倍的快速增长,如果业务展开了微服务合并,这个指数不会更大,这些基础组件服务端否能忍受比以往低几十倍上百倍的通信催促,这是不得而知的。如果你要全网升级某个基础组件Agent,那你可能会疯掉,你必须新的打所有业务镜像,然后全网业务要展开灰度升级。

因为一个Agent的升级,造成你被迫修复业务Pod。你可能会说道,基础组件Agents都会有自己的热升级方案,我们通过它们的方案升级就好了呀,那你将引进相当大困难:Agents的热升级因为无法被Kubernetes感官,将引起Kubernetes中集群中的数据不完全一致问题,那就知道要返回虚拟机或者物理机部署的玩法了。

亚博app

当然,这样的市场需求,我们也想要过通过Operator也构建,但代价过于大了,而且很不CloudNative!将基础组件Agents从业务Pod中挤压,以上的问题都能解决问题了,架构上的解法耦带给的益处需要多言。而且我们可以通过Kubernetes管理这些基础组件Agents了,享用其治愈、滑动升级等益处。二、Linux共享内存机制然而,理想很幸福,现实很残忍。

首先要解决问题的问题是,有些组件Agent与业务Pod之间是通过共享内存通信的,这跟Kubernetes&微服务的最佳实践中背道而驰。大家都告诉,Kubernetes单个Pod内是分享IPC的,并且可以通过挂架Medium为Memory的EmptyDirVolume分享同一块内存Volume。

首先我们来理解一下Linux共享内存的两种机制:POSIX共享内存(shm_open()、shm_unlink())SystemV共享内存(shmget()、shmat()、shmdt())其中,SystemV共享内存历史悠久,一般的UNIX系统上都有这套机制;而POSIX共享内存机制模块更为便利易懂,一般是融合内存同构mmap用于。mmap和SystemV共享内存的主要区别在于:sysvshm是长久简化的,除非被一个进程具体的移除,否则它一直不存在于内存里,直到系统关机mmap同构的内不存在不是长久简化的,如果进程重开,同构旋即过热,除非事前早已同构到了一个文件上/dev/shm是Linux下sysv共享内存的配置文件挂架点POSIX共享内存是基于tmpfs来构建的。实质上,更进一步,不仅PSM(POSIXsharedmemory),而且SSM(SystemVsharedmemory)在内核也是基于tmpfs构建的。

从这里可以看见tmpfs主要有两个起到:用作SYSV共享内存,还有电子邮件内存同构;这部分由内核管理,用户不可见用作POSIX共享内存,由用户负责管理mount,而且一般mount到/dev/shm;依赖CONFIG_TMPFS虽然SystemV与POSIX共享内存都是通过tmpfs构建,但是不受的容许却不完全相同。也就是说/proc/sys/kernel/shmmax只不会影响SYSV共享内存,/dev/shm只不会影响Posix共享内存。

亚博app

实质上,SystemV与Posix共享内存本来就是用于的两个有所不同的tmpfs实例(instance)。SYSV共享内存需要用于的内存空间只不受/proc/sys/kernel/shmmax容许;而用户通过挂架的/dev/shm,配置文件为物理内存的1/2。总结一下:POSIX共享内存与SYSV共享内存在内核都是通过tmpfs构建,但对应两个有所不同的tmpfs实例,互相独立国家。

通过/proc/sys/kernel/shmmax可以容许SYSV共享内存的最大值,通过/dev/shm可以容许POSIX共享内存的最大值(所有之和)。三、同一Node上弗Pod的共享内存方案基础组件AgentsDaemonSet部署后,Agents和业务Pod分别在同一个Node上有所不同的Pod,那么Kubernetes该如何反对这两种类型的共享内存机制呢?当然,安全性上作出了壮烈牺牲,但在非容器化之前IPC的隔绝也是没的,所以这一点是可以拒绝接受的。


本文关键词:亚博app,亚博app安全有保障
返回首页


下一篇:CME比特币期权上线,很可能影响未来市场走向_亚博app安全有保障 上一篇:美国西北大学多材料3D打印仿生螺旋结构|亚博app安全有保障