k8s 容器 java 应用内存限制不生效

一   k8s java 应用内存限制不生效

回顾:Linux杂谈之java命令    容器环境JVM内存配置最佳实践

namespace负责资源隔离  cgroups负责资源限制    容器JVM最佳实践

Metaspace 是 '非 Heap 内存' 管理空间,那么 Heap 就是'操作'空间

JVM内存模型简介

隔离: 两个进程完全'隔离'

感知: 使用 docker 的时候会感觉'每个容器启动'的应用之间'互不'干扰

从'文件系统、网络、CPU、内存'这些都能完全'隔离'开来,就像两个运行在'不同的服务器中'的应用

补充: 容器在'宿主机'表现为一个'进程'

++++++++++  "分割线"  ++++++++++

限制: CPU、内存、磁盘、带宽等

推荐 JVM 的配置'约等于'容器限制的 '70%~80%'

补充: hpa 设置'不合理' 导致 '频繁重启'

①  问题引入

思考: 如果在'java容器'中 未设置JVM相关参数、或设置不合理导致'不生效'

现象: java 应用 limit是8G,- Xms是6G,但是实际检'监测'到服务跑了7g,但是应用'没有被OOM'

补充: 金融容器,执行 'free -m' 看到的内存使用状况和'宿主机'中的保持一致

云原生时代: JVM '内存机制' 和 Kubernetes '内存管理'

'观测'方式: docker stats 和 kubectl top pods -n 观察 '内存'使用

docker stats --no-stream --format \

"table{{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}\t{{.BlockIO}}\t{{.PIDs}}"

②   jdk版本与jvm参数

-XX:MaxRAMPercentage, -XX:MinRAMPercentage    -Xmx, -Xms

java容器 不同jdk版本验证

细节: jdk '1.8191+ '设置 'Percentage'值时候'不能'为整数,jdk1.10+之后可以'为整数'

  1、在191版本'后',-XX:{Min|Max}RAMFraction 被'弃用'

  2、引入了-XX:MaxRAMPercentage,其值介于0.0到100.0之间,默认值为'25.0'

JVM UserContainerSupport    推荐JVM参数设置

-XX:+UseContainerSupport 允许 JVM 从'主机'读取 cgroup 限制

例如: 可用的 CPU 和 RAM,并进行相应的配置

效果: 这样当容器超过'内存限制'时,会抛出'OOM异常',而'不是'杀死容器

选用jdk版本: jdk 8u191+,推荐'1.8.0_202'

核心JVM参数: -XX:UseContainerSupport  -XX:MaxRAMPercentage=75.0

补充: jdk8u191+ 为 '适配 docker容器' 新增上面'几个'参数 

-Xmx 不受jdk版本限制

-XX:MetaspaceSize 解读

GC JVM参数解读

③  Java启动一些默认行为

'默认'情况下,JVM '自动'分配的 heap 大小取决于'机器'配置

 比如: 我们到一台 '32G' 内存服务器

 java -XX:+PrintFlagsFinal -version | grep -Ei "maxheapsize|maxram"

-Xms: 初始'heap'堆内存,会会立刻'被占用',默认为物理内存的 '1/64'

-Xmx: 最大堆内存,或者说'Heap'堆内存的'上限',默认为物理内存的 '1/4'

一个容器内存分配: 'Heap' + '非Heap [MetaSpace]等' + '容器中其它内存'

细节: 需要在最大'堆空间'、'非堆内存'使用量和 'pod 限制'之间取得平衡

补充: 'ES' 要求 -Xms和-Xmn保持'一致'

++++++++++++++  "分割线"  ++++++++++++++

1、MaxMetaspaceSize的默认值是'无限制',推荐设置'256M'

2、但可以通过'-XX:MetaspaceSize'和'-XX:MaxMetaspaceSize'来设置初始和最大值
​
++++++++++++++  "分割线"  ++++++++++++++

-XX:InitialRAMPercentage=75.0 -XX:MaxRAMPercentage=75.0 \

-XX:MinRAMPercentage=75.0 -XX:+PrintGCDetails -XX:+PrintGCDateStamps \

-XX:+PrintTenuringDistribution -XX:+PrintHeapAtGC -XX:+PrintReferenceGC \

-XX:+PrintGCApplicationStoppedTime -Xloggc:gc-%t.log \

-XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=15 -XX:GCLogFileSize=50M

2C4G --> 配置指定 75% ,相当于设置了 -Xms3g -Xms3g

④  通过LimitRange 做ns内的资源限制

k8s 容器 java的资源限制

将所由的options都放到 -jar 面前才能生效

spring boot 配置环境变量不生效

了解'业务代码' + '线上运维环境' --> '最佳定位'  --> '运维开发'

-XX:UseContainerSupport -XX:MaxRAMPercentage=75.0 -XX:MinRAMPercentage=75.0 

-Xms -Xmn 

++++++++++++ '查看容器对应的宿主机PID' ++++++++++++

docker top container_id 

docker inspect -f '{{.State.Pid}}'  container_id  

 k8s网络之(一)如何调试容器网络nsenter 原创

  • 7
    点赞
  • 11
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Kubernetes (k8s) 是一个流行的容器编排和管理工具,它能够自动部署、扩展和管理容器应用程序。在Kubernetes中,容器一般是通过服务发现的方式来进行通信,在这个过程中,域名解析是至关重要的一环。 容器中的应用程序通常会使用DNS进行域名解析来定位其他容器或外部服务。Nginx作为一个常用的容器化Web服务器,也需要通过DNS解析来将域名转换为IP地址,以便与其他容器或外部服务进行通信。 然而,有时候在Kubernetes集群中,容器的域名解析可能会出现不稳定性的问题。这可能导致Nginx无法解析需要的域名,使得容器间的网络通信出现故障或不可靠。 引起这种不稳定性的原因可能是多种多样的。首先,DNS解析问题可能与Kubernetes集群的配置有关。如果DNS服务配置不正确或不稳定,容器中的Nginx就无法准确地解析域名。 其次,网络问题也可能导致DNS解析不稳定。如果网络延迟高或者网络带宽不足,DNS解析可能会超时或失败,从而影响到Nginx的正常运行。 最后,应用程序本身的问题也可能导致DNS解析的不稳定性。如果应用程序没有正确地处理域名解析失败的情况,可能会导致Nginx无法正常工作。 要解决这个问题,我们可以采取以下措施: 1. 检查Kubernetes集群的DNS配置,确保DNS服务正常运行并配置正确。 2. 检查网络状况,确保网络延迟低、带宽充足,减少DNS解析超时的可能性。 3. 在应用程序中添加域名解析失败的错误处理机制,例如进行重试或回退到备用解析方案。 综上所述,k8s容器中的Nginx DNS解析不稳定的问题可能与Kubernetes集群的配置、网络问题或应用程序本身相关。通过检查和调整配置,优化网络状况以及合理处理解析失败,我们可以提高Nginx DNS解析的稳定性。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值