pod，限制了内存2G，1G和不做限制，但是观察下来内存使用率不做限制的反而使用率最低

在 Kubernetes 中，Pod 的内存使用情况受到多种因素的影响，包括应用程序的实际需求、容器的内存限制配置以及 Linux 内存管理机制。您观察到的现象——不受限制的 Pod 实际内存使用率反而最低，可能与以下几个方面有关：

1. 内存限制的作用：当为 Pod 设置了内存限制时（如2G或1G），Kubernetes 会通过 cgroups (Control Groups) 来限制容器可使用的内存资源。这实际上给容器设定了一个“天花板”，一旦达到这个上限，容器的行为将受到控制，比如被 OOM Killer（Out Of Memory killer）终止。因此，如果应用设计得当，它会在接近但不触达这个限制时进行自我调节，避免触发 OOM。

2. 缓存和内存回收：Linux 系统会积极地利用空闲内存作为磁盘缓存，以加速文件读写操作。当系统需要更多内存给其他进程使用时，这部分缓存是可以被快速回收的。不做内存限制的 Pod 可能因为系统有更充足的内存空间用于缓存，导致 kubectl top pod 显示的内存使用（包含cache）看起来较低。但实际上，这部分内存是随时可以释放给其他真正需要它的进程的。

3. 应用程序行为：某些应用程序可能会根据可用内存量动态调整其内存使用策略。例如，一些内存敏感的应用在检测到大量可用内存时，可能会预先加载数据或分配更多内存以提高性能，而当内存受限时，则会更加保守地使用内存。

4. 测量时间点：内存使用是一个动态变化的过程，kubectl top pod 显示的是采样时刻的值，可能没有完全反映出应用在整个周期内的内存使用模式。如果在不同限制条件下采集数据的时间点不同，或者应用处于不同的工作负载状态，也可能导致观测结果的差异。

综上所述，不做内存限制的 Pod 内存使用率看似最低，可能是由于系统缓存策略、应用程序对内存的自适应行为以及测量时机等多种因素共同作用的结果。为了更准确地评估应用的实际内存需求，建议结合监控长期趋势、考虑峰值使用情况，并适当调整内存限制以达到资源优化和保障应用稳定性的目的。