Open Stack

On 2020/5/6 19:54, Stefano Brivio wrote:
> On Wed, 6 May 2020 14:11:48 +0800
> Peng Tao <tao.peng at 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 at linux.alibaba.com
>>> <mailto:tao.peng at 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.
> 
As I mentioned, we do provide methods for users to configure to use the 
host kernel for Kata Containers. So the possibility is possible even now.

>> 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.
> 
Yes. Again, it is already possible to use the same kernel for both host 
and guest. So noting is broken for them.

>> 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.

Yes I agree that there is no one-solution-for-all. That is why we have 
so many configuration options. It is just about what we enable by default.

> 
> 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 :)
> 
It is not just about testing burden. We would want users to have a 
minimal kernel memory footprint. That is why Kata Containers shipped 
guest kernel is customized to be very small and only contains what we 
think is necessary for most container workloads. A distribution host 
kernel is more general and tends to enable many kernel options that are 
not going to be useful for a container workload guest.

Speaking of letting distributions validate the guest kernel, if a 
distribution provides a version of kernel that specially targets a cloud 
use case, it would be a much better fit for Kata Containers, although it 
is still a different kernel package than the host one.

Also we do ship kernel binaries. Checkout the repositories on obs [1] ;-)

Cheers,
Tao

[1] 
http://download.opensuse.org/repositories/home:/katacontainers:/releases:/x86_64:/alpha/CentOS_7/x86_64/

-- 
Into something rich and strange.