Kubernetes 中的 Docker 容器中的内存映射文件与 Linux 中的常规进程中的内存映射文件的工作方式相同吗？

Question

我有进程 A 和进程 B。进程 A 打开一个文件，调用 mmap 并写入它，进程 B 执行相同的操作，但当进程 A 完成写入时读取相同的映射区域。

使用 mmap，进程 B 应该从内存而不是磁盘读取文件，假设进程 A 没有调用 munmap。

如果我想将进程 A 和进程 B 部署到 Kubernetes 中同一 Pod 中的不同容器，内存映射 IO 的工作方式是否应该与初始示例相同？容器 B（进程 B）是否应该像在常规 Linux 桌面中一样从内存中读取文件？

假设两个容器位于同一个 Pod 中，并且从同一个持久卷读取/写入文件。我是否需要考虑特定类型的卷来实现 mmap IO？

如果您好奇的话，我正在使用 Apache Arrow 和 pyarrow 来读取和写入这些文件并实现零复制读取。

Answer 1

Kubernetes Pod 是一组部署在同一主机上的容器。（参考）。所以这个问题实际上是关于在同一主机上运行的多个容器会发生什么。

使用多种不同的技术将容器隔离在主机上。有两个可能与这里相关。 两者都不能阻止来自不同容器的两个进程在映射文件时共享相同的内存。

The two things to consider are how the file systems are isolated and how memory is ring fenced (limited).

How the file systems are isolated

The trick used is to create a mount namespace so that any new mount points are not seen by other processes. Then file systems are mounted into a directory tree and finally the process calls chroot to set / as the root of that directory tree.

No part of this affects the way processes mmap files. This is just a clever trick on how file names / file paths work for the two different processes.

Even if, as part of that setup, the same file system was mounted from scratch by the two different processes the result would be the same as a bind mount. That means the same file system exists under two paths but it is *the same file system, not a copy.

Any attempt to mmap files in this situation would be identical to two processes in the same namespace.

How are memory limits applied?

This is done through cgroups. cgroups don't really isolate anything, they just put limits on what a single process can do.

But there is a natuarl question to ask, if two processes have different memory limits through cgroups can they share the same shared memory? Yes they can!

Note: file and shmem may be shared among other cgroups. In that case, mapped_file is accounted only when the memory cgroup is owner of page cache.

该参考资料有点晦涩，但描述了如何将内存限制应用于此类情况。

结论

两个进程都将来自同一文件系统的同一文件内存映射为同一主机上的不同容器，其行为几乎完全相同，就好像这两个进程位于同一容器中一样。