Linux 如果内核库发生变化，Docker如何允许可移植容器

如果我的程序依赖于内核库的某个函数，而该函数又有一系列依赖项，那么docker如何保持小型和可移植性，而不拍摄所有内核库的快照（并在函数而不是库级别管理依赖项问题）？换言之，它是如何将自己与内核库从一个版本到下一个版本的变化隔离开来的，它是在库或函数的粒度上做到这一点的

另外，如果我的应用程序有一个软件堆栈，其中一个函数与内核库a的未来版本兼容，而使用内核库a的第二个函数不再兼容，该怎么办。换言之：

函数1和2都依赖于内核库A版本1.0中的函数并与之配合使用

函数1适用于liba版本1.1 函数2与liba版本1.1中断（函数2仍然需要liba版本1.0）

---

我对Docker了解不多，所以这是一个新手问题。

没有“内核库”这样的东西。与您描述的内容最接近的是：

• libc

  ，它是容器映像的一部分，因此不会更改

• Linux内核ABI，它大部分是常量。虽然偶尔会对内核ABI进行一些更改，但这是尽可能少的-内核开发人员尽一切可能保持向后兼容性。在进行更改的地方，通常是在与容器中运行的应用程序无关的组件中（例如，音频/视频输出、动态设备管理等）

---

libc和Linux内核是紧密交织在一起的。您运行的内核是用特定的libc编译的。您编译的libc只支持特定版本以上的内核。如果你只更新一个而不更新另一个，你可能会陷入痛苦的境地。我相信OP是指由不同版本的内核支持的系统调用。这些与libc高度相关。那么，容器是否以某种方式欺骗并使用基本系统的libc呢？如果某些软件试图直接调用基本内核中不支持的系统调用，您会遇到麻烦吗？glibc作为常规文件提供（例如

/usr/lib/x86_64-linux-gnu/libc-2.28.so

），因此是docker映像的一部分。因此，映像中的glibc可能与主机内核不兼容（请参阅有关glibc/linux兼容性的一些文字）。如果glibc生成主机内核尚未实现的syscal，则会出现严重问题。这件事发生在我身上。