<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 5:37 AM Peng Tao <<a href="mailto:tao.peng@linux.alibaba.com">tao.peng@linux.alibaba.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 2020/5/5 21:27, Stefano Brivio wrote:<br>
> Hi,<br>
> <br>
> I mentioned in the architecture call last week two examples of dynamic<br>
> kernel configuration appearing by default with kata-runtime that came<br>
> somewhat as a surprise to me, in particular compared to what we'd get<br>
> with a regular container (e.g. crun). Sorry for the delay in sharing<br>
> details, here they come.<br>
> <br>
> --<br>
> Examples:<br>
> - fq_codel instead of noqueue for default virtio-net interface:<br>
> <br>
>    - crun on Fedora 32:<br>
> <br>
> [root@300cd72baa94 /]# ip li sh eth0<br>
> 3: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default<br>
>      link/ether de:87:26:08:c3:25 brd ff:ff:ff:ff:ff:ff link-netnsid 0<br>
> <br>
>    - kata-runtime:<br>
> <br>
> [root@420e660f3870 /]# ip li sh eth0<br>
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000<br>
>      link/ether 86:ab:39:73:7c:b8 brd ff:ff:ff:ff:ff:ff<br>
> <br>
> This seems to come from<br>
> runtime/vendor/<a href="http://github.com/vishvananda/netlink/qdisc.go" rel="noreferrer" target="_blank">github.com/vishvananda/netlink/qdisc.go</a>. I don't know the<br>
> exact reason, fq_codel might be a sane default choice for almost any<br>
> environment, and I didn't observe any breakage due to this.<br>
> <br>
> - nodad on IPv6 addresses:<br>
> <br>
>    - crun:<br>
> <br>
> [root@300cd72baa94 /]# ip ad sh eth0<br>
> 3: eth0@if11: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default<br>
>      link/ether de:87:26:08:c3:25 brd ff:ff:ff:ff:ff:ff link-netnsid 0<br>
>      inet <a href="http://10.88.0.27/16" rel="noreferrer" target="_blank">10.88.0.27/16</a> brd 10.88.255.255 scope global eth0<br>
>         valid_lft forever preferred_lft forever<br>
>      inet6 fe80::dc87:26ff:fe08:c325/64 scope link<br>
>         valid_lft forever preferred_lft forever<br>
> <br>
>    - kata-runtime:<br>
> <br>
> [root@420e660f3870 /]# ip ad sh eth0<br>
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000<br>
>      link/ether 86:ab:39:73:7c:b8 brd ff:ff:ff:ff:ff:ff<br>
>      inet <a href="http://10.88.0.28/16" rel="noreferrer" target="_blank">10.88.0.28/16</a> brd 10.88.255.255 scope global eth0<br>
>         valid_lft forever preferred_lft forever<br>
>      inet6 fe80::84ab:39ff:fe73:7cb8/64 scope link nodad<br>
>         valid_lft forever preferred_lft forever<br>
> <br>
> This was introduced by:<br>
>       <a href="https://github.com/kata-containers/agent/pull/722/commits/c66b9279cc8ee273973878240c255e9d8fe8e552" rel="noreferrer" target="_blank">https://github.com/kata-containers/agent/pull/722/commits/c66b9279cc8ee273973878240c255e9d8fe8e552</a><br>
> the reason is clearly explained in comments and was also reiterated by<br>
> Archana last week, and totally makes sense to me in the general case. I<br>
> wonder, in this particular case, if we can really assume that any upper<br>
> stack or any environment can actually guarantee DAD is not needed, but<br>
> I also couldn't observe any issue due to this, so far.<br>
> --<br>
> <br>
> My concern is not so much related to networking components themselves<br>
> at this stage, but rather, more in general, to what might happen with<br>
> peculiar choices for other subsystems and userspace expectations. I<br>
> don't have concrete examples about breakages and, again, this is not<br>
> about build-time kernel configuration.<br>
> <br>
> If I understood correctly, bergwolf's proposal from last week goes in<br>
> the direction of having some kind of facility or approach that allows<br>
> us to track divergences introduced in kata-runtime compared to regular<br>
> containers (or to the current configuration of the host kernel), to<br>
> configure those behaviours and to systematically document particular<br>
> behaviours.<br>
Hi Stefano,<br>
<br>
My main concern about making guest kernel behave like the host kernel is <br>
that we might lose the ability to have a customized/optimized kernel <br>
just for container use case. There are a lot of kernel config options <br>
that are not going to be useful for container workload. So instead of <br>
just using the host kernel (for kata containers), I would suggest just <br>
using a minimal guest kernel as a basis and start adding new config <br>
options/modules as we identify new needs. And that is what we have been <br>
doing for Kata Containers in the past years.<br>
<br></blockquote><div><br></div><div>Production wise there is a lot of value in having the same kernel on the host and the guest.</div><div>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. </div><div>Kernel CVEs would also be better managed if the host/guest kernels are the same. </div><div> </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
As far as dynamic kernel options, is it enough to use kernel boot <br>
options + sysctls + kernel modules to meet the requirement? I asked it <br>
in the AC meeting but there was no conclusion yet. Most containers <br>
shouldn't care about specific kernel options. If kernel boot options + <br>
sysctls + kernel modules still cannot satisfy it, that should be a very <br>
specialized workload and IMO such users (who would likely be very <br>
professional at customizing things) can use a customized guest kernel <br>
instead of the standard one shipped with Kata Containers.<br>
<br>
Just my 2 cents...<br>
<br>
Cheers,<br>
Tao<br>
<br>
> <br>
> I'm rather new to this, so I don't have a clear picture of how this<br>
> might apply, in practice, should we choose to start from those two<br>
> cases as examples. Feedback and further input are warmly welcome!<br>
> <br>
<br>
-- <br>
Into something rich and strange.<br>
<br>
_______________________________________________<br>
kata-dev mailing list<br>
<a href="mailto:kata-dev@lists.katacontainers.io" target="_blank">kata-dev@lists.katacontainers.io</a><br>
<a href="http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev" rel="noreferrer" target="_blank">http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev</a><br>
</blockquote></div></div>