企业官网建设流程全解析

找人合伙做网站平台,可以免费做演播的听书网站,wordpress 4.70漏洞,外贸网站租用外国服务器好还是自己装一个服务器好服务部署在K8s上#xff0c;运行一段时间后Pod就会重启。看日志没有异常#xff0c;但Pod状态显示OOMKilled。 一开始以为是代码内存泄漏#xff0c;排查了一周#xff0c;最后发现是K8s资源配置的问题。 问题现象 监控告警#xff1a;Pod重启次数过多 kubectl get pod…服务部署在K8s上运行一段时间后Pod就会重启。看日志没有异常但Pod状态显示OOMKilled。一开始以为是代码内存泄漏排查了一周最后发现是K8s资源配置的问题。问题现象监控告警Pod重启次数过多kubectl get pods NAME READY STATUS RESTARTS AGE order-service-5d4f6c7b8-abc 1/1 Running 15 2d2天重启了15次。查看Pod详情kubectl describe pod order-service-5d4f6c7b8-abc Last State: Terminated Reason: OOMKilled Exit Code: 137OOMKilledExit Code 137 被系统因为内存超限杀掉了。排查过程Step 1先看资源配置kubectl get pod order-service-5d4f6c7b8-abc -o yaml | grep -A 10 resources resources: limits: cpu: 2 memory: 2Gi requests: cpu: 1 memory: 1Gi配置了limits.memory 2Gi。Step 2看实际内存使用kubectl top pod order-service-5d4f6c7b8-abc NAME CPU(cores) MEMORY(bytes) order-service-5d4f6c7b8-abc 500m 1950Mi内存用了1950Mi接近2Gi的限制了。Step 3进容器看详情kubectl exec -it order-service-5d4f6c7b8-abc -- /bin/sh # 查看容器看到的内存限制 cat /sys/fs/cgroup/memory/memory.limit_in_bytes # 2147483648 (2GB) # 查看当前使用 cat /sys/fs/cgroup/memory/memory.usage_in_bytes # 1900000000 (约1.9GB)确实快到上限了。Step 4分析JVM内存这是个Java服务看看JVM配置# 查看JVM参数 ps aux | grep java java -Xms1g -Xmx2g -jar app.jar问题来了JVM的-Xmx设成了2G和容器limits一样大问题根因Java在容器中的内存计算容器的内存限制 ≠ 只给JVM用的内存容器总内存 JVM堆内存 JVM非堆内存 操作系统开销 具体来说 - 堆内存-Xmx - Metaspace - 线程栈每个线程1MB左右 - 直接内存DirectByteBuffer - JNI - GC开销 - 容器内其他进程如果-Xmx2Gcontainer limit也是2G那堆刚满的时候加上其他内存总量就超过2G了触发OOMKilled。数据验证我们服务的实际内存组成组成部分大小说明堆内存实际使用1.5G没到-Xmx上限Metaspace150M类加载线程栈200M约200个线程直接内存100MNIO使用其他100MGC、JNI等合计约2G超过limit堆内存还没满但总内存已经超限了。解决方案方案一调整limits推荐resources: limits: memory: 3Gi # 给足够的余量 requests: memory: 2Gi一般建议limits.memory Xmx 500M ~ 1G方案二调整JVM参数# 按容器限制的75%设置堆内存 java -Xms1g -Xmx1536m -jar app.jar # 或者用容器感知参数JDK 8u191 java -XX:MaxRAMPercentage75.0 -jar app.jarMaxRAMPercentage会自动读取容器的内存限制按比例设置堆大小。方案三限制非堆内存java \ -Xms1g -Xmx1536m \ -XX:MaxMetaspaceSize256m \ -XX:MaxDirectMemorySize256m \ -Xss512k \ -jar app.jar-XX:MaxMetaspaceSize限制Metaspace-XX:MaxDirectMemorySize限制直接内存-Xss减小线程栈大小最终配置# deployment.yaml resources: limits: cpu: 2 memory: 2560Mi # 2.5G requests: cpu: 1 memory: 2Gi # JVM参数 java \ -XX:MaxRAMPercentage75.0 \ -XX:InitialRAMPercentage50.0 \ -XX:MaxMetaspaceSize256m \ -jar app.jar改完后再也没重启过。几个相关的坑坑1requests和limits差太多# 不推荐 requests: memory: 512Mi limits: memory: 4Girequests太小会被调度到资源紧张的节点然后因为实际用量超过节点剩余资源被OOM。建议requests设成实际使用量limits设成峰值余量。坑2不设limits# 危险 resources: requests: memory: 1Gi # 没有limits不设limits意味着可以无限使用可能把节点撑爆影响其他Pod。坑3老版本JDK不认容器限制JDK 8u131之前的版本不认识cgroup的内存限制会读取物理机的内存。解决升级到JDK 8u191或JDK 11或手动设置-Xmx。监控和告警查看Pod历史事件kubectl describe pod pod-name | grep -A 20 Events查看节点内存压力kubectl describe node node-name | grep -A 5 ConditionsPrometheus监控# 告警规则 - alert: PodOOMKilled expr: kube_pod_container_status_last_terminated_reason{reasonOOMKilled} 1 for: 0m labels: severity: warning annotations: summary: Pod {{ $labels.pod }} OOMKilled远程排查线上K8s集群通常在内网出问题需要VPN或跳板机。我用组网工具提前把笔记本和跳板机组好在外面也能快速kubectl连上去看情况。比每次找运维开VPN快多了。排查命令总结# 查看Pod状态和重启次数 kubectl get pods # 查看重启原因 kubectl describe pod pod-name # 查看实时资源使用 kubectl top pod pod-name # 进入容器看cgroup限制 kubectl exec -it pod-name -- cat /sys/fs/cgroup/memory/memory.limit_in_bytes # 查看JVM内存Java容器 kubectl exec -it pod-name -- jcmd 1 VM.native_memory summary # 查看OOMKilled事件 kubectl get events --field-selector reasonOOMKilling总结场景配置建议Java服务limits Xmx 500M~1G推荐做法用MaxRAMPercentage75%requests设成实际使用量limits设成峰值余量K8s的OOMKilled不一定是代码内存泄漏很可能是资源配置不合理。先看limits和JVM参数是否匹配。