789dbca6d6
Here is an interesting case I have been debugging. I was trying to understand why a "kubeadm reset" was not working for kata-runtime compared to runc. In this case, the only pod started with Kata is the kube-dns pod. For some reasons, when this pod is stopped and removed, its containers receive some signals, 2 of them being SIGTERM signals, which seems the way to properly stop them, but the third container receives a SIGCONT. Obviously, nothing happens in this case, but apparently CRI-O considers this should be the end of the container and after a few seconds, it kills the container process (being the shim in Kata case). Because it is using a SIGKILL, the signal does not get forwarded to the agent because the shim itself is killed right away. After this happened, CRI-O calls into "kata-runtime state", we detect the shim is not running anymore and we try to stop the container. The code will eventually call into agent.RemoveContainer(), but this will fail and return an error because inside the agent, the container is still running. The approach to solve this issue here is to send a SIGKILL signal to the container after the shim has been waited for. This call does not check for the error returned because most of the cases, regular use cases, will end up returning an error because the shim itself not being there actually represents the container inside the VM has already terminated. And in case the shim has been killed without the possibility to forward the signal (like described in first paragraph), the SIGKILL will work and will allow the following call to agent.stopContainer() to proceed to the removal of the container inside the agent. Fixes #274 Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
Runtime
This repository contains the runtime for the Kata Containers project.
For details of the other Kata Containers repositories, see the repository summary.
- Introduction
- License
- Platform support
- Quick start for developers
- Configuration
- Logging
- Debugging
- Community
Introduction
kata-runtime, referred to as "the runtime", is the Command-Line Interface
(CLI) part of the Kata Containers runtime component. It leverages the
virtcontainers
package to provide a high-performance standards-compliant runtime that creates
hardware-virtualized containers.
The runtime is both OCI-compatible and CRI-O-compatible, allowing it to work seamlessly with both Docker and Kubernetes respectively.
License
The code is licensed under an Apache 2.0 license.
See the license file for further details.
Platform support
Kata Containers currently works on systems supporting the following technologies:
Hardware requirements
The runtime has a built-in command to determine if your host system is capable of running a Kata Container:
$ kata-runtime kata-check
Note:
If you run the previous command as the
rootuser, further checks will be performed (e.g. it will check if another incompatible hypervisor is running):$ sudo kata-runtime kata-check
Quick start for developers
See the developer guide.
Configuration
The runtime uses a TOML format configuration file called configuration.toml.
The file contains comments explaining all options.
Note:
The initial values in the configuration file provide a good default configuration. You might need to modify this file if you have specialist needs.
Since the runtime supports a
stateless system,
it checks for this configuration file in multiple locations, two of which are
built in to the runtime. The default location is
/usr/share/defaults/kata-containers/configuration.toml for a standard
system. However, if /etc/kata-containers/configuration.toml exists, this
takes priority.
The command below lists the full paths to the configuration files that the runtime attempts to load. The first path that exists is used:
$ kata-runtime --kata-show-default-config-paths
Aside from the built-in locations, it is possible to specify the path to a
custom configuration file using the --kata-config option:
$ kata-runtime --kata-config=/some/where/configuration.toml ...
The runtime will log the full path to the configuration file it is using. See the logging section for further details.
To see details of your systems runtime environment (including the location of the configuration file being used), run:
$ kata-runtime kata-env
Logging
The runtime provides --log= and --log-format= options. However, the
runtime always logs to the system log (syslog or journald).
To view runtime log output:
$ sudo journalctl -t kata-runtime
For detailed information and analysis on obtaining logs for other system components, see the documentation for the kata-log-parser tool.
Debugging
See the debugging section of the developer guide.