I have production servers that run applications compatible with different Debian versions (bullseye and bookworm). I would like to move all these applications on a single machine, and for that, I thought of containerizing them.
But from what I understand, you can't just run any container image on any kernel. This post explains that the software you want to run must be "compatible enough" or problems will arise.
That's why I'm looking for some kind of compatibility matrix that would tell me which Debian version could run fine as guest on which kernels versions.
Since I can't find such a matrix, I guess I'm missing something or not understanding something about containers. Is it on a per-application basis? Is what I'm trying to do simply not advised, and I should keep on going with one server per Debian version?
TLDR, this should not be a concern for most software. Don't think too hard about it, unless your OS or container image is truly ancient.
Userspace software depend on kernel APIs (i.e. system calls) to do many things. If a piece of software is built against the APIs of one kernel, but is then run on a different kernel, it might try to perform some syscalls that the older kernel does not support. Or perhaps an API has had breaking changes between versions. In these cases you will get a ENOSYS or EINVAL and your userspace program will likely crash.
In the context of containerisation, because containers share the host's kernel, there could be a version mismatch between the kernel the software was built against and the kernel it's actually running on.
For this problem to manifest, the userspace program has to make an invalid syscall. But due to the maturity and policies of the Linux kernel, this is actually a pretty unlikely circumstance.
First, Linux kernel has the stated policy of "never break userspace". In practice, this means that old kernel APIs are seldom (or even never; I'm not sure) removed or have breaking changes introduced. This policy has such importance that often times "technically buggy" behaviours are intentionally kept. This means it is all but guaranteed that software built against an older kernel will work on a newer one. If not, it's considered a regression bug.
Second, Linux as a project has had 30+ years of history at this point, which means that the most commonly used APIs have been stable for a long long time. Therefore the vast majority of software will run just fine on any reasonably modern kernel unless it actually uses a very new kernel API. And for the few pieces of software that do, their developers are often aware of this and have implemented safe fallbacks for older kernels.