For investors
股价:
5.36 美元 %For investors
股价:
5.36 美元 %认真做教育 专心促就业
容器化技术随着互联网的不断发展而被越来越多的程序员掌握,今天我们就通过案例分析来简单了解一下,容器化技术应用原理分析。
容器的原理
在解决这个问题之前还是先简单了解下容器的运行原理,因为在k8s中所有的应用都是运行在容器中的,而容器本质上也是运行在宿主机上的一个个经常而已。
但我们使用Docker的时候会感觉每个容器启动的应用之间互不干扰,从文件系统、网络、CPU、内存这些都能完全隔离开来,就像两个运行在不同的服务器中的应用。
其实这一点也不是啥黑科技,Linux早就支持2.6.x的版本就已经支持namespace隔离了,使用namespace可以将两个进程完全隔离。
仅仅将资源隔离还不够,还需要限制对资源的使用,比如CPU、内存、磁盘、带宽这些也得做限制;这点也可以使用cgroups进行配置。
它可以限制某个进程的资源,比如宿主机是4核CPU,8G内存,为了保护其他容器,必须给这个容器配置使用上限:1核CPU,2G内存。
不同的OOM
回到本次的问题,可以确认是容器发生了OOM从而导致被k8s重启,这也是我们配置limits的作用。
k8s内存溢出导致容器退出会出现exitcode137的一个event日志。
因为该应用的JVM内存配置和容器的配置大小是一样的,都是8GB,但Java应用还有一些非JVM管理的内存,比如堆外内存之类的,这样很容易就导致容器内存大小超过了限制的8G了,也就导致了容器内存溢出。
云原生背景的优化
因为这个应用本身使用的内存不多,所以建议将堆内存限制到4GB,这样就避免了容器内存超限,从而解决了问题。
当然之后我们也会在应用配置栏里加上建议:推荐JVM的配置小于容器限制的2/3,预留一些内存。
其实本质上还是开发模式没有转变过来,以传统的Java应用开发模式甚至都不会去了解容器的内存大小,因为以前大家的应用都是部署在一个内存较大的虚拟机上,所以感知不到容器内存的限制。
从而误以为将两者画了等号,这一点可能在Java应用中尤为明显,毕竟多了一个JVM;甚至在老版本的JDK中如果没有设置堆内存大小,无法感知到容器的内存限制,从而自动生成的Xmx大于了容器的内存大小,以致于OOM。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!请读者仅作参考。更多内容请加抖音太原达内IT培训学习了解。