Google Summer of Code 2017 Summary

Google Summer of Code 2017 Summary

It is already the final days of GSoC 2017, three months of challenge and coding make it like a flash. Thanks for Google Summer of Code team and CNCF organization give me this opportunity, and of course my dearest memtors, Pengfei Ni and Harry Zhang, ‘s patient guidance. It’s not the first time for me as a opensource project contributor, but it’s the first time for me to work on such large and challenge feature. And I do believe unikernel will play an important role in the post container technology world, which will benefit NFV and IoT scene.

Design

The original proposal could be found here.

Here is the brief description:
Basicaly, I treat unikernel instance as a special VM, so that I build unikernel instance into a VM image(qcow2 format), manage unikernel instance by libvirt. From hypervisor aspect, there is no difference between unikernel instance and traditional virtual machine instance.

For container/sandbox/image life-cycle management, this is what unikshim(what I call this built in unikernel shim in Frakti) should do, and also the core part of what I work in this project. Every pod sandbox contain one container, and hold by one VM instance. More container/sandbox info, please refer the proposal. To support more unikernel type, in the first stage, I can’t build all kinds of them at container creation stage just like described in proposal. So build unikernel image is part of user’s responsibility for now.

At last, in order to support dhcp server and logging feature, I add a VM wrapper to every libvirt managed vm, who’s responsible for dhcp service and get log from VM then write to specified location. Now the call stack is unikshim->libvirt->vmwrapper->qemu.

Related Work

Issues:
1. https://github.com/kubernetes/frakti/issues/99
2. https://github.com/kubernetes/frakti/issues/181
3.
Pull Request:
1. https://github.com/kubernetes/frakti/pull/178
2. https://github.com/kubernetes/frakti/pull/180
3. https://github.com/kubernetes/frakti/pull/189
4. https://github.com/kubernetes/frakti/pull/219
5. https://github.com/kubernetes/frakti/pull/223

Conclusion

Due to some known image management issue, I can’t put unikernel runtime into kubelet-frakti workflow for now. While we can use and test unikernel runtime with CRI validation client and test.

I’ve complete most of stuff listed in scheduled plan expect for some issues and passing CRI validation test. The good news is that we also make linuxkit built image could run on unikshim, and discover the potential that linuxkit unikshim cloud support multiple container per pod.

Further work

Enhance image management

Enhance current image management and support building image at container creation time is important if we want to support all kubernetes features, because it’s not easy to inject user data(user volume/service account/etc.) to a pre-build unikernel image.

Support multiple container per pod

Linuxkit built image has a built-in containerd, this allow us cloud management mutli-container’s life-cycle if we find a way to communication with it. Glad that vsock in qemu is the one cloud help us, while it require linux kernel 4.4+, maybe a little bit difficult to meet by now.

Support flex volume

Traditional kubernetes volume is built on directory mount, but this is not easy for VM based runtime, and impossible for unikernel with virtio-9p support. So a disk attach based flex volume is the final solution for unikernel runtime.