问题描述
我有进程A和进程B.进程A打开一个文件，调用mmap并写入该文件，进程B进行相同的操作，但在进程A完成写入后读取相同的映射区域.
I have process A and process B. Process A opens a file, calls mmap and write to it, process B do the same but reads the same mapped region when process A has finished writing.
使用mmap，假设进程A尚未调用munmap，则假定进程B从内存而不是磁盘读取文件.
Using mmap, process B is suppossed to read the file from memory instead of disk assuming process A has not called munmap.
如果我想将进程A和进程B部署到Kubernetes的同一容器中的不同容器中，内存映射IO是否应该以与初始示例相同的方式工作?容器B(进程B)是否应该像常规Linux桌面一样从内存中读取文件?
If I would like to deploy process A and process B to diferent containers in the same pod in Kubernetes, is memory mapped IO supposed to work the same way as the initial example? Should container B (process B) read the file from memory as in my regular Linux desktop?
让我们假设两个容器都在同一个容器中，并且正在从相同的持久卷中读取/写入文件.我是否需要考虑特定类型的卷才能实现mmap IO?
Let's assume both containers are in the same pod and are reading/writing the file from the same persistent volume. Do I need to consider a specific type of volume to achieve mmap IO?
如果您有疑问，我将使用Apache Arrow和pyarrow来读写这些文件并实现零拷贝读取.
In case you are courious I am using Apache Arrow and pyarrow to read and write those files and achieve zero-copy reads.
推荐答案
Kubernetes容器是一组部署在同一主机上的容器. (参考).因此，这个问题实际上是关于在同一主机上运行的多个容器会发生什么情况.
A Kubernetes pod is a group of containers that are deployed together on the same host. (reference). So this question is really about what happens for multiple containers running on the same host.
使用多种不同的技术将容器隔离在主机上.这里有两个可能相关. 都不是，它们在映射文件时会阻止来自不同容器的两个进程共享相同的内存.
Containers are isolated on a host using a number of different technologies. There are two that might be relevant here. Neither prevent two processes from different containers sharing the same memory when they mmap a file.
要考虑的两件事是如何隔离文件系统以及如何对内存进行隔离(限制).
The two things to consider are how the file systems are isolated and how memory is ring fenced (limited).
使用的技巧是创建一个 mount名称空间这样其他进程就看不到任何新的挂载点.然后将文件系统安装到目录树中，最后该过程调用 chroot 来设置/作为该目录树的根.
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.
这不会影响处理mmap文件的方式.这只是关于两个不同进程的文件名/文件路径如何工作的聪明技巧.
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.
这是通过 cgroups 完成的. cgroup并没有真正隔离任何东西，它们只是限制了单个进程可以做什么.
This is done through cgroups. cgroups don't really isolate anything, they just put limits on what a single process can do.
但是有一个自然的问题要问，如果两个进程通过cgroup具有不同的内存限制，它们可以共享相同的共享内存吗? 可以！
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!
该参考文献有些晦涩，但描述了内存限制如何应用于此类情况.
The reference is a little obscure, but describes how memory limits are applied to such situations.
两个进程都将同一文件系统中的同一文件映射为同一主机上的不同容器，这两个进程的行为几乎完全相同，就像两个进程位于同一容器中一样.
Two processes both memory mapping the same file from the same file system as different containers on the same host will behave almost exactly the same as if the two processes were in the same container.
这篇关于Kubernetes中Docker容器中的内存映射文件是否与Linux中的常规进程相同?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！