pod可以查看堆内存吗，查看pod中有哪些容器

从OOM到根因:Go应用内存泄漏问题的pprof排查实战

1、OOM原因：程序主要用于解析数据，内存消耗不可避免。在默认的2分钟GC周期内，内存使用量会达到GC阈值。由于GC阈值默认是GC后内存的两倍大小，因此GC阈值会持续扩大，直到接近总内存大小。在总内存大小附近进行GC时，由于GC过程是并发且分多阶段进行，并非所有阶段都完全停顿，因此程序在部分时间内会继续申请内存。

2、在拿到采样文件后，使用go tool pprof加载数据至交互模式控制台，通常会有提示信息展示文件内容类型。在交互式控制台中，使用top命令查看占用内存最多的函数，如发现gorm库中的某个方法导致内存泄露，进一步分析业务逻辑代码。top命令输出列表中，flat和cum值显示函数内存使用情况，sum%表示前几行flat%的总和。

3、NSQ的HTTP API设计简洁，支持调试工具如pprof，为管理员提供了实时监控数据。同时，适应Go语言的更新，管理依赖关系时考虑两种策略，确保了系统的兼容性和稳定性。在测试上，NSQ引入Context结构，解决了全局状态的问题，提高了测试的可靠性。

fabric8获取Pod内存

使用kubectl命令。打开终端并登录到Kubernetes集群的主机。将替换为你想要查询的pod的名称，替换为POD所在的命名空间名称。

可以通过读取 Config 文件来获取 Client 实例，同时也可以通过环境变量、Token 等方式来获取。这些方式在实际操作中类似，具体方法请参考项目文档或示例代码。

创建客户端是使用此库的基础步骤。最简单的方式是使用默认配置，从目录~/.kube/config中读取配置文件。如果需要修改配置，可以通过系统属性和环境变量进行调整，或者通过java来自定义配置。使用fabric8io/kubernetes-client进行资源操作非常灵活。

生产问题(一)k8s内存溢出

1、在Kubernetes（K8S）环境中，当Pod使用的内存超过其限制时，会发生内存溢出（OOM）并被K8S重启。这里讨论的是一个特殊的内存溢出案例，其特殊之处在于问题并非由JAVA虚拟机（JVM）引起。问题背景 Pod内存分配：该服务所在的Pod被设置为2G内存限制，超过此限制将触发K8S的OOM重启机制。

2、在KuberNETes（K8s）中，当Pod发生OOM（Out of Memory，内存溢出）被杀掉时，Pod的名称本身不会因为OOM事件而发生变化。

3、含义：容器内存溢出。可能原因：内存限制设置过小或程序内存泄漏。排查方法：合理设置内存限制，并监控内存使用情况，及时发现并处理内存泄漏问题。SysctlForbidden 状态：含义：Pod 自定义了内核配置，但 kubelet 未能添加或配置不支持的内核参数。可能原因：内核配置与 kubelet 配置不兼容。

4、FLINK 内存分区与 JVM 分区间的关系如下：硬限制分区导致 Flink 报内存不足；JVM 管理的分区内存耗尽时，JVM 会报其所属的 JVM 分区 OOM（如 Java.lang.OutOfMemoryError： Java heap space）；持续内存溢出导致进程总体内存超出容器限制，资源管理器（如 YARN 或 k8s）会杀死该进程。

容器下的内存使用及问题分析总结

1、监控与诊断：容器下内存的分析主要使用/sys/fs/cgroup/memory下的各个文件以及memory.stat进行。不要依赖传统虚拟机下的free和top命令来查看内存使用情况，而应重点关注Cgroup下的内存管理文件。问题排查：对于内存使用异常的问题，应首先分析memory.stat文件，了解各项内存指标的变化情况。

2、Kubernetes OOM（内存不足）问题 Pod 中的每个容器都需要内存才能运行。当容器使用的内存超过其限制时，Linux 内核的 OOM Killer 会终止该进程以回收内存。OOM 的触发条件：容器使用的内存超过其设置的 limits。节点上的内存资源不足，导致 Kubernetes 需要驱逐一些 Pod 以释放内存。

3、内存占用异常高的原因：MySQL容器在Kylin V10环境下启动时，内存占用异常高，无业务运行时也超过16GB。这主要是由于open_files_limit参数的异常设置。open_files_limit参数的作用：该参数控制MySQL同时打开的文件数量，直接占用内存。

4、内存占用：docker守护进程通常占用50MB-100MB内存，具体数值取决于配置和并发操作。容器运行时，轻量级镜像（如Alpine）基础内存占用约为5MB-10MB，而完整镜像（如ubuntu/Debian）基础内存占用则为50MB-100MB。对于运行Java应用等基础镜像的容器，其内存占用会更高。

5、我猜测，这可能与 Kylin V10 和其他操作系统计算 infinity 的方式不同。基于以上发现，我们可以采用以下解决方法：在实际应用中，这个解决方法可以作为一种通用策略，以防止 MySQL 以外的其他容器遇到相同问题。

一次意想不到的pod内存驱逐问题

1、答案：此次Pod驱逐问题的原因是K8S集群中的kubelet服务未正确识别到节点内存扩容后的新配额，导致在内存使用达到原配额上限时触发了Pod驱逐。详细分析：案发现场：客户反馈门户网站无法打开，多个Pod状态为Evicted（驱逐）。

2、以下是三个大厂K8s集群故障案例：案例一：电商平台促销活动Pod驱逐故障问题现象：促销活动期间，超30%的Pod进入Evicted状态，多个Worker节点内存使用率超95%，用户支付失败率从0.1%升至15%。根因分析：节点内存不足触发kubelet主动驱逐机制，recommendation - Service的Pod内存占用异常高且未设置内存限制。

3、在linux系统层面，内存不足导致进程被kill的现象较为常见。通过命令`dMESg | tail -N`，您可以查看近N行系统日志，寻找被kill的进程信息。

4、Kubernetes OOM（内存不足）问题 Pod 中的每个容器都需要内存才能运行。当容器使用的内存超过其限制时，Linux 内核的 OOM Killer 会终止该进程以回收内存。OOM 的触发条件：容器使用的内存超过其设置的 limits。节点上的内存资源不足，导致 Kubernetes 需要驱逐一些 Pod 以释放内存。

如何查看一个pod所有容器的整体利用率

在Kubernetes中，可以使用kubectl top pod命令来查看一个pod所有容器的整体资源利用率。具体步骤和说明如下：确保Metrics Server已启用：Metrics Server是Kubernetes集群中的一个组件，负责收集和提供集群资源（如Pod、Node等）的使用数据。

kubectl logs pod-name -c CONTAINER-name -n nameSpace：查看多容器 Pod 中指定容器的日志。进入 Pod 容器 kubectl exec -it pod-name -n namespace -- /bin/bash：进入指定 Pod 的容器，并启动一个 bash 会话。

修改Pod的配置文件 这是最直接的方式，适用于大多数需要更改的参数。你可以编辑包含Pod定义的YAML文件，更改相应的字段值，如容器的镜像版本、命令、参数等。然后使用kubectl APPly -f [filename].yaml命令来应用更改。Kubernetes将会删除原来的Pod并创建一个新的Pod，新的Pod将会使用更新后的配置信息。

查看单个容器日志 Kubernetes提供了kubectl logs命令来直接访问容器的日志。基本命令：kubectl logs pod-name -c container-name pod-name：要查看日志的Pod的名称。-c container-name：指定Pod中的容器名称（如果Pod中只有一个容器，可以省略此选项）。

将 deployment 回滚到第二个版本，确认镜像为 nginx：18。1 查看 Deployment 的第四个版本详细信息。1 扩展 Deployment 副本数为 5。1 为 Deployment 设置自动拓展策略，当 CPU 利用率达到 80% 时执行拓展，Pod 数在 5 - 10 之间。1 暂停 Deployment 的滚动升级。