On Wed, 6 May 2020 14:11:48 +0800 Peng Tao <tao.peng@linux.alibaba.com> wrote:
On 2020/5/6 13:25, Ariel Adam wrote:
On Wed, May 6, 2020 at 5:37 AM Peng Tao <tao.peng@linux.alibaba.com <mailto:tao.peng@linux.alibaba.com>> wrote:
My main concern about making guest kernel behave like the host kernel is that we might lose the ability to have a customized/optimized kernel just for container use case. There are a lot of kernel config options that are not going to be useful for container workload. So instead of just using the host kernel (for kata containers), I would suggest just using a minimal guest kernel as a basis and start adding new config options/modules as we identify new needs. And that is what we have been doing for Kata Containers in the past years.
Production wise there is a lot of value in having the same kernel on the host and the guest. For example, taking a workload that has been run as a vanila container and then running it on a kata container could require a testing/certification process from scratch if the host/guest kernels are different. Kernel CVEs would also be better managed if the host/guest kernels are the same.
From production experience, it is much easier to upgrade a guest kernel than waiting for the host kernel to be upgraded. So I would suggest that we do not bind Kata Containers kernel to a host's running kernel.
I think nobody is suggesting that they should be forcefully bound, but still I see that usage as a very reasonable possibility (especially for the reasons Ariel mentioned), and that already works to a very good extent.
Also feature-wise, we can use a newer kernel to run Kata Containers on hosts that are running older kernels. So users running their good old kernels can still make use of new kernel features with Kata Containers.
Well, there is actually a reason why they're running older (or newer!) kernels, and that might apply to kata-runtime as well.
And it makes sense to ship the same kernel for different distributions in order to provide same user experience. And we only need to validate and maintain one guest kernel for all distributions, which is much easier than validating each kernel for each distribution version.
While I understand the reasoning behind this, it won't apply in every situation. For example, if there's a security flaw in the kernel, this would have the obvious drawback of requiring two packages (from a distribution perspective) to be upgraded at the same time. There are specific advantages and degrees of consistency both ways. Also mind that Kata Containers doesn't really ship a kernel (neither binary nor source). It ships (useful!) configuration fragments and a script, but you can't control the compiler or the toolchain, or even whether "-g nvidia" or "-g intel" is passed to build-kernel.sh, so, while the scripting undoubtedly takes some burden off the testing effort, I don't see much value going beyond that. This is not the kind of "validation" a distribution does -- which by the way makes perfect sense to me. Let the distribution do that :) -- Stefano