Add Kata Containers spec
Story: 2010765 Task: 48073 Signed-off-by: mpaulool <Marcos.PauloOliveiraSilva@windriver.com> Change-Id: I42e9b827f276252eb686bb161e4fe3d88336e78f
This commit is contained in:
mpaulool
parent
f46bb1a5b4
commit
0ddff3a798
|
|
@ -0,0 +1,199 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License. http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
========================================
|
||||
Reintegrate Kata Containers into StarlingX
|
||||
========================================
|
||||
|
||||
Storyboard: https://storyboard.openstack.org/#!/story/2010765
|
||||
https://storyboard.openstack.org/#!/story/2010781
|
||||
|
||||
This story reintegrates Kata Containers into StarlingX. When the migration
|
||||
to Debian was made, the Kata containers support wasn't ported. Then, this story
|
||||
aims to port it.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
Kata Containers is an open source community working to build a secure
|
||||
container runtime with lightweight virtual machines that feel and perform
|
||||
like containers, but provide stronger workload isolation using hardware
|
||||
virtualization technology as a second layer of defense.[0]
|
||||
|
||||
This story try to reintegrate Kata Containers into StarlingX, to address
|
||||
customer's concern for the security of container.
|
||||
|
||||
Due to there is still performance gap between Kata Containers and conventional
|
||||
containers [1], and Kubernetes cluster system cannot completely run on Kata
|
||||
Containers [2], Kata Containers is not used in default unless explicitly
|
||||
requirement is found in the Kubernetes's pod configuration file. Or in other
|
||||
words, regardless Kata Containers is enabled or not by this story, containers
|
||||
currently we have in StarlingX will not use kata container runtime in default,
|
||||
unless extra change is made.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
With Kata Containers supported in StarlingX, System developers, testers,
|
||||
operators, administrators could choose container runtime to use when run
|
||||
a container image, based on their needs. Such as if there is security concern
|
||||
for the pod/container, it could be selected to run with kata container. For the
|
||||
default case, runc will be selected as default low-level container runtime,
|
||||
which is the default low-level runtime for Kubernetes.
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
|
||||
To be done
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
None. This story does not change any existing data models.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
None. This story does not change any existing REST APIs.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
There is no sensitive data touch for this feature, except containerd need
|
||||
touch certificate/key for local secure registry "registry.local".
|
||||
Kata Containers could help enhance system's security by "Runs in a dedicated
|
||||
kernel, providing isolation of network, I/O and memory and can utilize
|
||||
hardware-enforced isolation with virtualization VT extensions." [0]
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
With this feature implemented, users are able to run containers with
|
||||
kata-runtime.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
For containers doesn't use kata-runtime, the performance should be the same as
|
||||
previous.
|
||||
For containers use kata-runtime, some performance drop is expected. Per Kata
|
||||
Containers website:"Delivers consistent performance as standard Linux
|
||||
containers; increased isolation with the performance tax of standard virtual
|
||||
machines."[0]
|
||||
Also there is a report of "I/O performance of Kata Containers". [1]
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
There is no change for the StarlingX deploy process.
|
||||
In node installation stage, a few debs for Kata Containers will be installed
|
||||
automatically in each node in order to support Kata Containers.
|
||||
In node configuration stage, docker and Kubernetes will be auto configured to
|
||||
support kata container runtime.
|
||||
After deployment, users need to update application tarball file to select kata
|
||||
runtime if want to use kata-runtime. Current application tarball will still
|
||||
work with runc runtime, just the same as before.
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None. This story does not impact the development at all.
|
||||
|
||||
Upgrade impact
|
||||
--------------
|
||||
|
||||
This feature will introduce several new debs for kata container. Kubernetes may
|
||||
be initialized with another container runtime during upgrade. Per my test,
|
||||
container runtime selection is per node. It means it is independent for the
|
||||
container runtime for each node. So this feature implementation should not
|
||||
affect upgrade.
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
Davi Barros Frossard
|
||||
David Liu
|
||||
|
||||
Repos Impacted
|
||||
--------------
|
||||
|
||||
* stx-integ - add kata container support and some fixes
|
||||
* stx-virt - upgrade qemu from 5.2 to 7.2
|
||||
* stx-root - remove the qemu from the debian-image list
|
||||
* stx-metal - remove qemu dependency from mtce-compute and mtce-control
|
||||
* stx-tools - add qemu dependencies
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
Add kata container
|
||||
* Add kata container support
|
||||
|
||||
Add the support in StarlingX for Kata Containers. The prebuilt runtime
|
||||
binaries are downloaded and modified to provide customization support.
|
||||
|
||||
Upgrade QEMU from version 5.2 to version 7.2
|
||||
* Upgrade QEMU and port patches
|
||||
|
||||
To avoid any kind of incompatibility with Kata Containers 3.1.x version,
|
||||
the QEMU upgrade to version 7.2 is necessary.
|
||||
Currently, the QEMU version on the host has WRO-specific patches which
|
||||
will need to be ported to the new version.
|
||||
|
||||
* Update QEMU required dependencies
|
||||
|
||||
Upgrade meson to 1.0.1-5 and add libasound2 libraries required by QEMU 7.2.
|
||||
|
||||
* Fix systemd after meson upgrade
|
||||
|
||||
Fixes the systemd after the meson (QEMU dependency) upgrade.
|
||||
The new version not allow anymore combining booleans with "+" operator
|
||||
and now requires the logical operator "and".
|
||||
|
||||
* Remove QEMU dependency from mtce-compute and mtce-control
|
||||
|
||||
That dependency is required only on CentOS.
|
||||
|
||||
|
||||
Besides upper work items, there are other work items maybe need added during
|
||||
implementation of this story. Please check the story link in the beginning of
|
||||
this spec to get the full work item list.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
This specification depends upon the open source upstream:
|
||||
|
||||
https://github.com/kata-containers/kata-containers
|
||||
https://github.com/qemu/qemu
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
To be done
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
To be done
|
||||
|
||||
References
|
||||
==========
|
||||
[0]: https://katacontainers.io/
|
||||
[1]: https://www.stackhpc.com/kata-io-1.html
|
||||
[2]: https://github.com/kata-containers/runtime/issues/1853
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
.. list-table:: Revisions
|
||||
:header-rows: 1
|
||||
|
||||
* - Release Name
|
||||
- Description
|
||||
* - stx-9.0
|
||||
- Introduced
|
||||
Loading…
Reference in New Issue