github/kata-containers
1
0
Fork 1
mirror of https://github.com/kata-containers/kata-containers.git synced 2025-07-02 18:23:12 +00:00
Code Issues Projects Releases Wiki Activity
216 Commits 83 Branches 134 Tags 303 MiB
Rust 57.9%
Go 24.8%
Shell 10%
RPC 5.4%
Makefile 1%
Other 0.9%
07af4edea9
Go to file
Sebastien Boeuf 07af4edea9 cli: Stop the sandbox on a KILL 
The same way a caller of "kata-runtime kill 12345" expects
the container 12345 to be killed, the same call to a container
representing a sandbox should actually kill the sandbox, meaning
it would be stopped after the container has been killed.

This way, the caller knows the VM is stopped after kill returns.
This is an issue raised by Openshift and Kubernetes tests. They
call into delete way after the call to kill has been submitted,
and in the meantime they kill all processes related to the container,
meaning they do kill the VM before we could do it ourselves. In this
case, the delete responsible of stopping the VM comes too late and it
returns an error when trying to destroy the sandbox while trying to
communicate with the agent since the VM is not here anymore.

This commit addresses this issue by letting "kill" call into
StopSandbox() if the command relates to a sandbox instead of
a simple container.

Fixes #246

Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
2018-04-25 09:07:34 -07:00
.ci CI: Use central go test script 2018-03-28 16:53:13 +01:00
.github github: Add issue template 2018-03-22 13:56:43 +00:00
arch SPDX: update cli and arch files to use SPDX 2018-04-17 17:30:44 +01:00
cli cli: Stop the sandbox on a KILL 2018-04-25 09:07:34 -07:00
data scripts: Make collect script hypervisor architecture agnostic 2018-03-22 16:05:12 +00:00
vendor vendor: Vendor github.com/intel/govmm 2018-04-19 10:42:17 -07:00
virtcontainers Merge pull request #218 from bergwolf/sandbox_api 2018-04-24 07:21:36 -07:00
.gitignore gitignore: merge gitignore files 2018-03-23 17:09:54 +08:00
.gitmodules submodules: Remove cc-runtime and runv 2018-03-21 12:10:15 -07:00
.pullapprove.yml CI: Add doc team to pullapprove config 2018-03-22 15:49:27 +00:00
.travis.yml CI: add go_import_path 2018-03-23 17:31:42 +08:00
CODE_OF_CONDUCT.md docs: Add missing standard docs 2018-02-09 14:45:14 +00:00
CONTRIBUTING.md docs: Add missing standard docs 2018-02-09 14:45:14 +00:00
Gopkg.lock vendor: Vendor github.com/intel/govmm 2018-04-19 10:42:17 -07:00
Gopkg.toml vendor: Vendor github.com/intel/govmm 2018-04-19 10:42:17 -07:00
LICENSE Initial commit 2017-11-21 17:03:45 +08:00
Makefile cli: 9p: Add toml configuration for 9p msize 2018-04-17 12:15:23 -07:00
README.md docs: Improve the README 2018-03-27 17:24:35 +01:00
VERSION version: 0.0.1 2018-04-16 18:53:47 -05:00
versions.yaml versions: change newest supported go version 2018-04-24 12:48:55 -05:00

README.md

Build Status Build Status Go Report Card

Runtime

This repository contains the runtime for the Kata Containers project.

For details of the other Kata Containers repositories, see the repository summary.

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:

  • Intel's VT-x technology.
  • ARM's Hyp mode (virtualization extension).

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 root user, 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.

Community

See the community repository.