48aa077e8c
Enabling full-featured QEMU NVDIMM support on ARM with DAX enabled causes a
kernel panic in caches_clean_inval_pou (see below, different issue from
33b1f07), so we disable DAX in that environment.
[ 1.222529] EXT4-fs (pmem0p1): mounted filesystem e5a4892c-dac8-42ee-ba55-27d4ff2f38c3 ro with ordered data mode. Quota mode: disabled.
[ 1.222695] VFS: Mounted root (ext4 filesystem) readonly on device 259:1.
[ 1.224890] devtmpfs: mounted
[ 1.225175] Freeing unused kernel memory: 1920K
[ 1.226102] Run /sbin/init as init process
[ 1.226164] with arguments:
[ 1.226204] /sbin/init
[ 1.226235] with environment:
[ 1.226268] HOME=/
[ 1.226295] TERM=linux
[ 1.230974] Internal error: synchronous external abort: 0000000096000010 [#1] SMP
[ 1.231963] CPU: 0 UID: 0 PID: 1 Comm: init Tainted: G M 6.18.5 #1 NONE
[ 1.232965] Tainted: [M]=MACHINE_CHECK
[ 1.233428] pstate: 43400005 (nZcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
[ 1.234273] pc : caches_clean_inval_pou+0x68/0x84
[ 1.234862] lr : sync_icache_aliases+0x30/0x38
[ 1.235412] sp : ffff80008000b9a0
[ 1.235842] x29: ffff80008000b9a0 x28: 0000000000000000 x27: 00000000019a00e1
[ 1.236912] x26: ffff80008000bc08 x25: ffff80008000baf0 x24: fffffdffc0000000
[ 1.238064] x23: ffff000001671ab0 x22: ffff000001663480 x21: fffffdffc23401c0
[ 1.239356] x20: fffffdffc23401c0 x19: fffffdffc23401c0 x18: 0000000000000000
[ 1.240626] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[ 1.241762] x14: ffffaae8f021b3b0 x13: 0000000000000000 x12: ffffaae8f021b3b0
[ 1.242874] x11: ffffffffffffffff x10: 0000000000000000 x9 : 0000ffffbb53c000
[ 1.244022] x8 : 0000000000000000 x7 : 0000000000000012 x6 : ffff55178f5e5000
[ 1.245157] x5 : ffff80008000b970 x4 : ffff00007fa4f680 x3 : ffff00008d007000
[ 1.246257] x2 : 0000000000000040 x1 : ffff00008d008000 x0 : ffff00008d007000
[ 1.247387] Call trace:
[ 1.248056] caches_clean_inval_pou+0x68/0x84 (P)
[ 1.248923] __sync_icache_dcache+0x7c/0x9c
[ 1.249578] insert_page_into_pte_locked+0x1e4/0x284
[ 1.250432] insert_page+0xa8/0xc0
[ 1.251080] vmf_insert_page_mkwrite+0x40/0x7c
[ 1.251832] dax_iomap_pte_fault+0x598/0x804
[ 1.252646] dax_iomap_fault+0x28/0x30
[ 1.253293] ext4_dax_huge_fault+0x80/0x2dc
[ 1.253988] ext4_dax_fault+0x10/0x3c
[ 1.254679] __do_fault+0x38/0x12c
[ 1.255293] __handle_mm_fault+0x530/0xcf0
[ 1.255990] handle_mm_fault+0xe4/0x230
[ 1.256697] do_page_fault+0x17c/0x4dc
[ 1.257487] do_translation_fault+0x30/0x38
[ 1.258184] do_mem_abort+0x40/0x8c
[ 1.258895] el0_ia+0x4c/0x170
[ 1.259420] el0t_64_sync_handler+0xd8/0xdc
[ 1.260154] el0t_64_sync+0x168/0x16c
[ 1.260795] Code: d2800082 9ac32042 d1000443 8a230003 (d50b7523)
[ 1.261756] ---[ end trace 0000000000000000 ]---
Signed-off-by: Aurélien Bombo <abombo@microsoft.com>
Runtime
Binary names
This repository contains the following components:
| Binary name | Description |
|---|---|
containerd-shim-kata-v2 |
The shimv2 runtime |
kata-runtime |
utility program |
kata-monitor |
metrics collector daemon |
For details of the other Kata Containers repositories, see the repository summary.
Introduction
The containerd-shim-kata-v2 binary is the Kata
Containers shimv2 runtime. It leverages the
virtcontainers
package to provide a high-performance standards-compliant runtime that creates
hardware-virtualized Linux containers running on Linux hosts.
The runtime is OCI-compatible, CRI-O-compatible, and Containerd-compatible, allowing it to work seamlessly with both Docker and Kubernetes respectively.
Download and install
See the installation guides available for various operating systems.
Architecture overview
See the architecture overview for details on the Kata Containers design.
Configuration
The runtime uses a TOML format configuration file called configuration.toml.
The file is divided into sections for settings related to various
parts of the system including the runtime itself, the agent and
the hypervisor.
Each option has a comment explaining its use.
Note:
The initial values in the configuration file provide a good default configuration. You may need to modify this file to optimise or tailor your system, or if you have specific requirements.
Configuration file location
Runtime configuration file location
The shimv2 runtime looks for its configuration in the following places (in order):
-
The
io.data containers.config.config_pathannotation specified in the OCI configuration file (config.jsonfile) used to create the pod sandbox. -
The containerd shimv2 options passed to the runtime.
-
The value of the
KATA_CONF_FILEenvironment variable.
Utility program configuration file location
The kata-runtime utility program looks for its configuration in the
following locations (in order):
-
The path specified by the
--configcommand-line option. -
The value of the
KATA_CONF_FILEenvironment variable.
Note: For both binaries, the first path that exists will be used.
Drop-in configuration file fragments
To enable changing configuration without changing the configuration file
itself, drop-in configuration file fragments are supported. Once a
configuration file is parsed, if there is a subdirectory called config.d in
the same directory as the configuration file its contents will be loaded
in alphabetical order and each item will be parsed as a config file. Settings
loaded from these configuration file fragments override settings loaded from
the main configuration file and earlier fragments. Users are encouraged to use
familiar naming conventions to order the fragments (e.g. config.d/10-this,
config.d/20-that etc.).
Non-existent or empty config.d directory is not an error (in other words, not
using configuration file fragments is fine). On the other hand, if fragments
are used, they must be valid - any errors while parsing fragments (unreadable
fragment files, contents not valid TOML) are treated the same as errors
while parsing the main configuration file. A config.d subdirectory affects
only the configuration.toml in the same directory. For fragments in
config.d to be parsed, there has to be a valid main configuration file in
that location (it can be empty though).
Hypervisor specific configuration
Kata Containers supports multiple hypervisors so your configuration.toml
configuration file may be a symbolic link to a hypervisor-specific
configuration file. See
the hypervisors document for further details.
Stateless systems
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 below command lists the full paths to the configuration files that the runtime attempts to load. The first path that exists will be used:
$ kata-runtime --show-default-config-paths
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 env
Logging
For detailed information and analysis on obtaining logs for other system
components, see the documentation for the
kata-log-parser
tool.
Kata containerd shimv2
The Kata containerd shimv2 runtime logs through containerd, and its logs will be sent
to wherever the containerd logs are directed. However, the
shimv2 runtime also always logs to the system log (syslog or journald) using the kata identifier.
Note: Kata logging requires containerd debug to be enabled.
To view the shimv2 runtime logs:
$ sudo journalctl -t kata
Debugging
See the debugging section of the developer guide.
Limitations
See the limitations file for further details.
Community
Contact
See how to reach the community.
Further information
See the project table of contents and the documentation repository.
Additional packages
For details of the other packages contained in this repository, see the package documentation.