GithubHelp home page GithubHelp logo

kata-containers / runtime Goto Github PK

View Code? Open in Web Editor NEW
2.1K 117.0 376.0 18.7 MB

Kata Containers version 1.x runtime (for version 2.x see https://github.com/kata-containers/kata-containers).

Home Page: https://katacontainers.io/

License: Apache License 2.0

Makefile 1.35% Shell 1.30% Go 97.32% Dockerfile 0.02%
docker kubernetes k8s qemu container oci kvm virtual-machine virtualization cri-o

runtime's Introduction

CI | Publish Kata Containers payload Kata Containers Nightly CI

Kata Containers

Welcome to Kata Containers!

This repository is the home of the Kata Containers code for the 2.0 and newer releases.

If you want to learn about Kata Containers, visit the main Kata Containers website.

Introduction

Kata Containers is an open source project and community working to build a standard implementation of lightweight Virtual Machines (VMs) that feel and perform like containers, but provide the workload isolation and security advantages of VMs.

License

The code is licensed under the Apache 2.0 license. See the license file for further details.

Platform support

Kata Containers currently runs on 64-bit systems supporting the following technologies:

Architecture Virtualization technology
x86_64, amd64 Intel VT-x, AMD SVM
aarch64 ("arm64") ARM Hyp
ppc64le IBM Power
s390x IBM Z & LinuxONE SIE

Hardware requirements

The Kata Containers runtime provides a command to determine if your host system is capable of running and creating a Kata Container:

$ kata-runtime check

Notes:

  • This command runs a number of checks including connecting to the network to determine if a newer release of Kata Containers is available on GitHub. If you do not wish this to check to run, add the --no-network-checks option.

  • By default, only a brief success / failure message is printed. If more details are needed, the --verbose flag can be used to display the list of all the checks performed.

  • If the command is run as the root user additional checks are run (including checking if another incompatible hypervisor is running). When running as root, network checks are automatically disabled.

Getting started

See the installation documentation.

Documentation

See the official documentation including:

Configuration

Kata Containers uses a single configuration file which contains a number of sections for various parts of the Kata Containers system including the runtime, the agent and the hypervisor.

Hypervisors

See the hypervisors document and the Hypervisor specific configuration details.

Community

To learn more about the project, its community and governance, see the community repository. This is the first place to go if you wish to contribute to the project.

Getting help

See the community section for ways to contact us.

Raising issues

Please raise an issue in this repository.

Note: If you are reporting a security issue, please follow the vulnerability reporting process

Developers

See the developer guide.

Components

Main components

The table below lists the core parts of the project:

Component Type Description
runtime core Main component run by a container manager and providing a containerd shimv2 runtime implementation.
runtime-rs core The Rust version runtime.
agent core Management process running inside the virtual machine / POD that sets up the container environment.
dragonball core An optional built-in VMM brings out-of-the-box Kata Containers experience with optimizations on container workloads
documentation documentation Documentation common to all components (such as design and install documentation).
tests tests Excludes unit tests which live with the main code.

Additional components

The table below lists the remaining parts of the project:

Component Type Description
packaging infrastructure Scripts and metadata for producing packaged binaries
(components, hypervisors, kernel and rootfs).
kernel kernel Linux kernel used by the hypervisor to boot the guest image. Patches are stored here.
osbuilder infrastructure Tool to create "mini O/S" rootfs and initrd images and kernel for the hypervisor.
kata-debug infrastructure Utility tool to gather Kata Containers debug information from Kubernetes clusters.
agent-ctl utility Tool that provides low-level access for testing the agent.
kata-ctl utility Tool that provides advanced commands and debug facilities.
trace-forwarder utility Agent tracing helper.
runk utility Standard OCI container runtime based on the agent.
ci CI Continuous Integration configuration files and scripts.
katacontainers.io Source for the katacontainers.io site.
Webhook utility Example of a simple admission controller webhook to annotate pods with the Kata runtime class

Packaging and releases

Kata Containers is now available natively for most distributions.

General tests

See the tests documentation.

Metrics tests

See the metrics documentation.

Glossary of Terms

See the glossary of terms related to Kata Containers.

runtime's People

Contributors

ace-tang avatar amshinde avatar awprice avatar bergwolf avatar c3d avatar caoruidong avatar chavafg avatar cmaf avatar darfux avatar dgibson avatar egernst avatar fidencio avatar gabyct avatar gnawux avatar grahamwhaley avatar jcvenegas avatar jodh-intel avatar jongwu avatar justin-he avatar lifupan avatar likebreath avatar marcov avatar mcastelino avatar nitkon avatar pennyzct avatar stefanharh avatar teawater avatar vijaydhanraj avatar weizhang555 avatar yutedz avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

runtime's Issues

storage: fio test seems to get 'stuck'

Running:

$(pwd)/storage/fio_job.sh -b 16k -o randread -t "storage IO random read bs 16k"

inspired from https://github.com/clearcontainers/tests/blob/master/.ci/run_metrics_ci.sh#L134
seems to hang up, and never return (nor generates significant output).
For reference, the test works with runc and cc-runtime, and takes something like 3m30s to complete (on my local test machine).

Here is the output from my kata-env. These were components installed from HEAD on 2018-03-16 (Friday), including a HEAD agent installed in the image:

[Meta]
  Version = "1.0.9"

[Runtime]
  Debug = false
  [Runtime.Version]
    Semver = "0.1.0"
    Commit = "de8506d8e5cbcd87b1c40d9121dc24b056d2a26e-dirty"
    OCI = "1.0.1"
  [Runtime.Config]
    Path = "/usr/local/share/defaults/kata-containers/configuration.toml"

[Hypervisor]
  MachineType = "pc"
  Version = "QEMU emulator version 2.7.0, Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers"
  Path = "/usr/bin/qemu-lite-system-x86_64"
  Debug = false
  BlockDeviceDriver = "virtio-scsi"

[Image]
  Path = "/usr/share/kata-containers/kata-containers-2018-03-16-11:36:56.885986052+0000-6899dec"

[Kernel]
  Path = "/usr/share/clear-containers/vmlinuz-4.14.22-86.container"
  Parameters = ""

[Proxy]
  Type = "kataProxy"
  Version = "<<unknown>>"
  Path = "/usr/libexec/kata-containers/kata-proxy"
  Debug = false

[Shim]
  Type = "kataShim"
  Version = "kata-shim version 0.0.1-9745a6a666daaed8d2d0950c52b76ec2799fbcff"
  Path = "/usr/libexec/kata-containers/kata-shim"
  Debug = false

[Agent]
  Type = "kata"
  Version = "<<unknown>>"

[Host]
  Kernel = "4.4.0-104-generic"
  Architecture = "amd64"
  VMContainerCapable = true
  [Host.Distro]
    Name = "Ubuntu"
    Version = "16.04"
  [Host.CPU]
    Vendor = "GenuineIntel"
    Model = "Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz"

random docker failures

Not sure if these failures are related with the runtime or other component, but please let me know if this issue should go somewhere else.

Now that we have some CI jobs running the docker integration tests, I have seen that we have random failures in several tests.
For example:
http://kata-jenkins-ci.westus2.cloudapp.azure.com/job/kata-containers-tests-ubuntu-16-04-PR/24/console
http://kata-jenkins-ci.westus2.cloudapp.azure.com/job/kata-containers-tests-ubuntu-16-04-PR/25/console

I tried to reproduce locally with this steps:

  1. Setup Kata Containers using:

.ci/setup.sh from the kata-containers/tests repository

  1. Run docker integration tests:
    RUNTIME=kata-runtime sudo -E PATH=$PATH make integration also from the tests repository

In this case, the failure was in the docker cp test. Seems like the container was not created, since the kata-proxy log didn't have any information:

• Failure [2.953 seconds]
docker cp
/home/fuentess/go/src/github.com/kata-containers/tests/integration/docker/cp_test.go:16
  check files after a docker cp
  /home/fuentess/go/src/github.com/kata-containers/tests/integration/docker/cp_test.go:34
    should have the corresponding files [It]
    /home/fuentess/go/src/github.com/kata-containers/tests/integration/docker/cp_test.go:35

    Expected
        <string>:
    to contain substring
        <string>: file340338607

    /home/fuentess/go/src/github.com/kata-containers/tests/integration/docker/cp_test.go:49
------------------------------
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

Summarizing 1 Failure:

[Fail] docker cp check files after a docker cp [It] should have the corresponding files
/home/fuentess/go/src/github.com/kata-containers/tests/integration/docker/cp_test.go:49

In the docker logs:

Feb 16 18:01:17 katavm dockerd[1291]: time="2018-02-16T18:01:17.233754121Z" level=debug msg="EnableService 68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65 START"
Feb 16 18:01:17 katavm dockerd[1291]: time="2018-02-16T18:01:17.233798022Z" level=debug msg="EnableService 68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65 DONE"
Feb 16 18:01:17 katavm dockerd[1291]: time="2018-02-16T18:01:17.284932263Z" level=debug msg="bundle dir created" bundle=/var/run/docker/containerd/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65
 module=libcontainerd namespace=moby root=/var/lib/docker/overlay2/65f62d36bec6b267831759e1515daba14085e909637e818bf1e1c0bc3245fd3d/merged
Feb 16 18:01:17 katavm dockerd[1291]: time="2018-02-16T18:01:17Z" level=debug msg="event published" module="containerd/containers" ns=moby topic="/containers/create" type=containerd.events.ContainerCreate
Feb 16 18:01:17 katavm dockerd[1291]: time="2018-02-16T18:01:17.330114730Z" level=debug msg=event module=libcontainerd namespace=moby topic=/containers/create
Feb 16 18:01:17 katavm dockerd[1291]: time="2018-02-16T18:01:17.330134630Z" level=info msg="ignoring event" module=libcontainerd namespace=moby topic=/containers/create type="*events.ContainerCreate"
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="converting /run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/68aa8a952d929510afd23bde2010f2d2cdf7944b97
be33e1d073acfc598c3e65/config.json" source=virtcontainers/oci
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug default-kernel-parameters="init=/usr/lib/systemd/systemd systemd.unit=kata-containers.target systemd.mask=systemd-networkd.s
ervice systemd.mask=systemd-networkd.socket ip=::::::68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65::off::" source=runtime
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="container rootfs: /var/lib/docker/overlay2/65f62d36bec6b267831759e1515daba14085e909637e818bf1e1c0bc3245fd3d/merged" sou
rce=virtcontainers/oci
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="Creating bridges" source=virtcontainers subsystem=qemu
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="Creating UUID" source=virtcontainers subsystem=qemu
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="Could not retrieve anything from storage" source=virtcontainers subsystem=kata_agent
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug default-kernel-parameters="root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro rw rootfstype=ext4 tsc=reliable no
_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k panic=1 console=hvc0 console=hvc1 initcall_debug iommu=off cryptomgr.notests net.ifnames=0
pci=lastbus=0 debug systemd.show_status=true systemd.log_level=debug" source=virtcontainers subsystem=qemu
Feb 16 18:01:18 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:18Z" level=debug msg="Replacing OCI mount (/etc/resolv.conf) source /var/lib/docker/containers/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33
e1d073acfc598c3e65/resolv.conf with /tmp/kata-containers/shared/pods/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65-fa735fe2eeec31c2-resolv.conf" source=virtcontainers subsystem=kata_agent
Feb 16 18:01:18 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:18Z" level=debug msg="Replacing OCI mount (/etc/hostname) source /var/lib/docker/containers/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d
073acfc598c3e65/hostname with /tmp/kata-containers/shared/pods/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65-b98b1dbf8a49a7e2-hostname" source=virtcontainers subsystem=kata_agent
Feb 16 18:01:18 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:18Z" level=debug msg="Replacing OCI mount (/etc/hosts) source /var/lib/docker/containers/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073
acfc598c3e65/hosts with /tmp/kata-containers/shared/pods/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65-c141df73ec2cc1ec-hosts" source=virtcontainers subsystem=kata_agent
Feb 16 18:01:18 katavm kata-runtime-cc[88518]: time="2018-02-16T18:01:18Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:18 katavm kata-runtime-cc[88524]: time="2018-02-16T18:01:18Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:18 katavm kata-runtime-cc[88533]: time="2018-02-16T18:01:18Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88564]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88575]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-shim[88571]: time="2018-02-16T18:01:19.157052053Z" level=warning msg="close stdin failed" error="rpc error: code = Unknown desc = Process 2b545be4-016b-43ca-bd49-c1343e0e8d5b not foun
d (container 68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65)"
Feb 16 18:01:19 katavm kata-runtime-cc[88591]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88604]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88610]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88622]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88627]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88627]: time="2018-02-16T18:01:19Z" level=error msg="Container 68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65 not ready or running, cannot send a signal"
source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88632]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime

From kata-containers-cc log:

Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="converting /run/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/68aa8a952d929510afd23bde2010f2d2cdf7944b97
be33e1d073acfc598c3e65/config.json" source=virtcontainers/oci
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug default-kernel-parameters="init=/usr/lib/systemd/systemd systemd.unit=kata-containers.target systemd.mask=systemd-networkd.s
ervice systemd.mask=systemd-networkd.socket ip=::::::68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65::off::" source=runtime
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="container rootfs: /var/lib/docker/overlay2/65f62d36bec6b267831759e1515daba14085e909637e818bf1e1c0bc3245fd3d/merged" sou
rce=virtcontainers/oci
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="Creating bridges" source=virtcontainers subsystem=qemu
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="Creating UUID" source=virtcontainers subsystem=qemu
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug msg="Could not retrieve anything from storage" source=virtcontainers subsystem=kata_agent
Feb 16 18:01:17 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:17Z" level=debug default-kernel-parameters="root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro rw rootfstype=ext4 tsc=reliable no
_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k panic=1 console=hvc0 console=hvc1 initcall_debug iommu=off cryptomgr.notests net.ifnames=0
pci=lastbus=0 debug systemd.show_status=true systemd.log_level=debug" source=virtcontainers subsystem=qemu
Feb 16 18:01:18 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:18Z" level=debug msg="Replacing OCI mount (/etc/resolv.conf) source /var/lib/docker/containers/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33
e1d073acfc598c3e65/resolv.conf with /tmp/kata-containers/shared/pods/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65-fa735fe2eeec31c2-resolv.conf" source=virtcontainers subsystem=kata_agent
Feb 16 18:01:18 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:18Z" level=debug msg="Replacing OCI mount (/etc/hostname) source /var/lib/docker/containers/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d
073acfc598c3e65/hostname with /tmp/kata-containers/shared/pods/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65-b98b1dbf8a49a7e2-hostname" source=virtcontainers subsystem=kata_agent
Feb 16 18:01:18 katavm kata-runtime-cc[88453]: time="2018-02-16T18:01:18Z" level=debug msg="Replacing OCI mount (/etc/hosts) source /var/lib/docker/containers/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073
acfc598c3e65/hosts with /tmp/kata-containers/shared/pods/68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65-c141df73ec2cc1ec-hosts" source=virtcontainers subsystem=kata_agent
Feb 16 18:01:18 katavm kata-runtime-cc[88518]: time="2018-02-16T18:01:18Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:18 katavm kata-runtime-cc[88524]: time="2018-02-16T18:01:18Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:18 katavm kata-runtime-cc[88524]: time="2018-02-16T18:01:18Z" level=info msg="Pod is started" pod-id=68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65 source=virtcontainers subsystem=
pod
Feb 16 18:01:18 katavm kata-runtime-cc[88533]: time="2018-02-16T18:01:18Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88564]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88575]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88591]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88604]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88610]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88610]: time="2018-02-16T18:01:19Z" level=error msg="Container not running, impossible to signal the container" source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88622]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88627]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88627]: time="2018-02-16T18:01:19Z" level=error msg="Container 68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65 not ready or running, cannot send a signal"
source=runtime
Feb 16 18:01:19 katavm kata-runtime-cc[88632]: time="2018-02-16T18:01:19Z" level=debug msg="loaded configuration" format=TOML source=runtime

Kata-shim log:

Feb 16 18:01:19 katavm kata-shim[88571]: time="2018-02-16T18:01:19.157052053Z" level=warning msg="close stdin failed" error="rpc error: code = Unknown desc = Process 2b545be4-016b-43ca-bd49-c1343e0e8d5b not foun
d (container 68aa8a952d929510afd23bde2010f2d2cdf7944b97be33e1d073acfc598c3e65)"

Kata-proxy log:
nothing logged at this time, previous lines are from other containers executed 20 seconds before.

Facing issue while installing katacontainer runtime.

I was trying to install katacontainer runtime and I got this issue

./configure: line 4360: syntax error near unexpected token `LIBVIRT,'
./configure: line 4360: `       PKG_CHECK_MODULES(LIBVIRT, libvirt >= $LIBVIRT_REQUIRED, , with_libvirt=no)'
Makefile:53: recipe for target 'build' failed
make: *** [build] Error 2

I have no idea how to solve this.

Platform
aws ubuntu instance

KATA_RUNTIME
runv

kata runtime library APIs

Currently, both runv and cc-runtime imports the real runtime implementation from other orgs/repos (runv from hyperhq/runv and cc-runtime from containers/virtcontainers), to provide command line interfaces for kata runtime.

However, there are needs for runtime library APIs as well, e.g., hyperd and frakti make use of the runv library APIs directly rather than jump through command line APIs, which gives hyperd/frakti more functionality and better flexibility.

For kata, we should also define a set of kata runtime library APIs and provide them to users. In the meantime, the real runtime implementations should go in as well. The issue can work as a tracker for such discussions.

cc @gnawux @laijs @sameo @sboeuf @WeiZhang555

OpenStack Zun via DevStack doesn't work with Kata-containers (Could not setup network routes)

Description of problem

When using a relatively recent version of DevStack and replacing the Clear Container 2.x runtime with Kata containers, then when executing "zun run --runtime=cc-runtime cirros ping -c 4 8.8.8.8" it errors out. The logs state that network routes could not be setup

Expected result

The container will start and you can interact with it

Actual result


The container errors out and the logs show ""update routes request failed" arch=amd64 error="rpc error: code = Internal desc = Could not add route dest()/gw(2001:db8::2)/dev(eth0): no route to host" name=kata-runtime pid=20578 resulting-routes="""

A gist on how to setup devstack is at https://gist.github.com/eadamsintel/86bd12acd7052ea061766f9698f69819 Instead of compiling and building the kata runtimes described in this gist just follow the CC 3.0 install instructions for Ubuntu after devstack is setup and replace the cor runtime with cc-runtime at /etc/docker/daemon.json, reload the daemon, and restart docker to enable CC 3.0 in Zun.

Meta details

This is the output from kata-collect-data.sh

Meta details

Running kata-collect-data.sh version 3.0.20 (commit f6cbf170b7c00059454e4543cb00fd0d6d303618) at 2018-03-09.23:47:39.224704942-0800.


Runtime is /usr/local/bin/kata-runtime.

kata-env

Output of "/usr/local/bin/kata-runtime kata-env":

[Meta]
  Version = "1.0.9"

[Runtime]
  Debug = false
  [Runtime.Version]
    Semver = "3.0.20"
    Commit = "f6cbf170b7c00059454e4543cb00fd0d6d303618"
    OCI = "1.0.1"
  [Runtime.Config]
    Path = "/usr/share/defaults/kata-containers/configuration.toml"

[Hypervisor]
  MachineType = "pc"
  Version = "QEMU emulator version 2.7.1(2.7.1+git.d4a337fe91-11.cc), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers"
  Path = "/usr/bin/qemu-lite-system-x86_64"
  Debug = false
  BlockDeviceDriver = "virtio-scsi"

[Image]
  Path = "/usr/share/kata-containers/kata-containers-2018-03-07-23:21:39.346009793-0800-6899dec"

[Kernel]
  Path = "/usr/share/clear-containers/vmlinuz-4.9.60-84.container"
  Parameters = ""

[Proxy]
  Type = "kataProxy"
  Version = "kata-proxy version 0.0.1-baf8b9e191e0647ee6e6c92f15c3a71180b2862a"
  Path = "/usr/libexec/kata-containers/kata-proxy"
  Debug = true

[Shim]
  Type = "kataShim"
  Version = "kata-shim version 0.0.1-00791c06f114173052c9e231e794532de79ce797"
  Path = "/usr/libexec/kata-containers/kata-shim"
  Debug = true

[Agent]
  Type = "kata"
  Version = "<<unknown>>"

[Host]
  Kernel = "4.13.0-36-generic"
  Architecture = "amd64"
  VMContainerCapable = true
  [Host.Distro]
    Name = "Ubuntu"
    Version = "16.04"
  [Host.CPU]
    Vendor = "GenuineIntel"
    Model = "Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz"

Runtime config files

Runtime default config files

/etc/kata-containers/configuration.toml
/usr/share/defaults/kata-containers/configuration.toml

Runtime config file contents

Config file /etc/kata-containers/configuration.toml not found
Output of "cat "/usr/share/defaults/kata-containers/configuration.toml"":

# XXX: WARNING: this file is auto-generated.
# XXX:
# XXX: Source file: "config/configuration.toml.in"
# XXX: Project:
# XXX:   Name: Kata Containers
# XXX:   Type: kata

[hypervisor.qemu]
path = "/usr/bin/qemu-lite-system-x86_64"
kernel = "/usr/share/kata-containers/vmlinuz.container"
image = "/usr/share/kata-containers/kata-containers.img"
machine_type = "pc"

# Optional space-separated list of options to pass to the guest kernel.
# For example, use `kernel_params = "vsyscall=emulate"` if you are having
# trouble running pre-2.15 glibc.
#
# WARNING: - any parameter specified here will take priority over the default
# parameter value of the same name used to start the virtual machine.
# Do not set values here unless you understand the impact of doing so as you
# may stop the virtual machine from booting.
# To see the list of default parameters, enable hypervisor debug, create a
# container and look for 'default-kernel-parameters' log entries.
kernel_params = ""

# Path to the firmware.
# If you want that qemu uses the default firmware leave this option empty
firmware = ""

# Machine accelerators
# comma-separated list of machine accelerators to pass to the hypervisor.
# For example, `machine_accelerators = "nosmm,nosmbus,nosata,nopit,static-prt,nofw"`
machine_accelerators=""

# Default number of vCPUs per POD/VM:
# unspecified or 0                --> will be set to 1
# < 0                             --> will be set to the actual number of physical cores
# > 0 <= number of physical cores --> will be set to the specified number
# > number of physical cores      --> will be set to the actual number of physical cores
default_vcpus = -1


# Bridges can be used to hot plug devices.
# Limitations:
# * Currently only pci bridges are supported
# * Until 30 devices per bridge can be hot plugged.
# * Until 5 PCI bridges can be cold plugged per VM.
#   This limitation could be a bug in qemu or in the kernel
# Default number of bridges per POD/VM:
# unspecified or 0   --> will be set to 1
# > 1 <= 5           --> will be set to the specified number
# > 5                --> will be set to 5
default_bridges = 1

# Default memory size in MiB for POD/VM.
# If unspecified then it will be set 2048 MiB.
#default_memory = 2048

# Disable block device from being used for a container's rootfs.
# In case of a storage driver like devicemapper where a container's 
# root file system is backed by a block device, the block device is passed
# directly to the hypervisor for performance reasons. 
# This flag prevents the block device from being passed to the hypervisor, 
# 9pfs is used instead to pass the rootfs.
disable_block_device_use = false

# Block storage driver to be used for the hypervisor in case the container
# rootfs is backed by a block device. This is either virtio-scsi or 
# virtio-blk.
block_device_driver = "virtio-scsi"

# Enable pre allocation of VM RAM, default false
# Enabling this will result in lower container density
# as all of the memory will be allocated and locked
# This is useful when you want to reserve all the memory
# upfront or in the cases where you want memory latencies
# to be very predictable
# Default false
#enable_mem_prealloc = true

# Enable huge pages for VM RAM, default false
# Enabling this will result in the VM memory
# being allocated using huge pages.
# This is useful when you want to use vhost-user network
# stacks within the container. This will automatically 
# result in memory pre allocation
#enable_hugepages = true

# Enable swap of vm memory. Default false.
# The behaviour is undefined if mem_prealloc is also set to true
#enable_swap = true

# This option changes the default hypervisor and kernel parameters
# to enable debug output where available. This extra output is added
# to the proxy logs, but only when proxy debug is also enabled.
# 
# Default false
enable_debug = true

# Disable the customizations done in the runtime when it detects
# that it is running on top a VMM. This will result in the runtime
# behaving as it would when running on bare metal.
# 
#disable_nesting_checks = true

[proxy.kata]
path = "/usr/libexec/kata-containers/kata-proxy"

# If enabled, proxy messages will be sent to the system log
# (default: disabled)
enable_debug = true

[shim.kata]
path = "/usr/libexec/kata-containers/kata-shim"

# If enabled, shim messages will be sent to the system log
# (default: disabled)
enable_debug = true

[agent.kata]
# There is no field for this section. The goal is only to be able to
# specify which type of agent the user wants to use.

[runtime]
# If enabled, the runtime will log additional debug messages to the
# system log
# (default: disabled)
enable_debug = true
#
# Internetworking model
# Determines how the VM should be connected to the
# the container network interface
# Options:
#
#   - bridged
#     Uses a linux bridge to interconnect the container interface to
#     the VM. Works for most cases except macvlan and ipvlan.
#
#   - macvtap
#     Used when the Container network interface can be bridged using
#     macvtap.
internetworking_model="macvtap"

Logfiles

Runtime logs

Recent runtime problems found in system journal:

time="2018-03-09T23:44:54.901359292-08:00" level=debug msg="Could not retrieve anything from storage" arch=amd64 name=kata-runtime pid=20578 source=virtcontainers subsystem=kata_agent
time="2018-03-09T23:44:55.060928618-08:00" level=debug arch=amd64 default-kernel-parameters="root=/dev/pmem0p1 rootflags=dax,data=ordered,errors=remount-ro rw rootfstype=ext4 tsc=reliable no_timer_check rcupdate.rcu_expedited=1 i8042.direct=1 i8042.dumbkbd=1 i8042.nopnp=1 i8042.noaux=1 noreplace-smp reboot=k console=hvc0 console=hvc1 iommu=off cryptomgr.notests net.ifnames=0 pci=lastbus=0 debug systemd.show_status=true systemd.log_level=debug" name=kata-runtime pid=20578 source=virtcontainers subsystem=qemu
time="2018-03-09T23:44:55.121367393-08:00" level=warning msg="unsupported address" address="2001:db8::7/64" arch=amd64 name=kata-runtime pid=20578 source=virtcontainers subsystem=kata_agent unsupported-address-type=ipv6
time="2018-03-09T23:44:55.121437426-08:00" level=warning msg="unsupported address" address="fe80::f816:3eff:fe3e:6908/64" arch=amd64 name=kata-runtime pid=20578 source=virtcontainers subsystem=kata_agent unsupported-address-type=ipv6
time="2018-03-09T23:44:55.121502655-08:00" level=warning msg="unsupported route" arch=amd64 destination="2001:db8::/64" name=kata-runtime pid=20578 source=virtcontainers subsystem=kata_agent unsupported-route-type=ipv6
time="2018-03-09T23:44:55.121542615-08:00" level=warning msg="unsupported route" arch=amd64 destination="fe80::/64" name=kata-runtime pid=20578 source=virtcontainers subsystem=kata_agent unsupported-route-type=ipv6
time="2018-03-09T23:44:56.134037059-08:00" level=error msg="update routes request failed" arch=amd64 error="rpc error: code = Internal desc = Could not add route dest()/gw(2001:db8::2)/dev(eth0): no route to host" name=kata-runtime pid=20578 resulting-routes="<nil>" routes-requested="[gateway:\"172.24.4.1\" device:\"eth0\"  dest:\"172.24.4.0/24\" device:\"eth0\" source:\"172.24.4.5\" scope:253  gateway:\"2001:db8::2\" device:\"eth0\" ]" source=virtcontainers subsystem=kata_agent
time="2018-03-09T23:44:56.134312085-08:00" level=error msg="rpc error: code = Internal desc = Could not add route dest()/gw(2001:db8::2)/dev(eth0): no route to host" command=create name=kata-runtime pid=20578 source=runtime

Proxy logs

Recent proxy problems found in system journal:

time="2018-03-09T23:44:55.613778526-08:00" level=info msg="[    0.333088] EXT4-fs (pmem0p1): DAX enabled. Warning: EXPERIMENTAL, use at your own risk\n" name=kata-proxy pid=20670 source=agent
time="2018-03-09T23:44:55.614164096-08:00" level=info msg="[    0.333455] EXT4-fs (pmem0p1): mounted filesystem with ordered data mode. Opts: dax,data=ordered,errors=remount-ro\n" name=kata-proxy pid=20670 source=agent
time="2018-03-09T23:44:55.649346786-08:00" level=info msg="[    0.368517] systemd-journald[358]: Failed to open configuration file '/etc/systemd/journald.conf': No such file or directory\n" name=kata-proxy pid=20670 source=agent
time="2018-03-09T23:44:55.651274666-08:00" level=info msg="[\x1b[0;1;31mFAILED\x1b[0m] Failed to mount Temporary Directory (/tmp).\n" name=kata-proxy pid=20670 source=agent
time="2018-03-09T23:44:55.652325952-08:00" level=info msg="[\x1b[0;1;33mDEPEND\x1b[0m] Dependency failed for Network Time Synchronization.\n" name=kata-proxy pid=20670 source=agent
time="2018-03-09T23:44:56.133031809-08:00" level=info msg="time=\"2018-03-10T07:44:56.120047935Z\" level=error msg=\"update Route failed\" error=\"rpc error: code = Internal desc = Could not add route dest()/gw(2001:db8::2)/dev(eth0): no route to host\" name=kata-agent pid=399 source=agent\n" name=kata-proxy pid=20670 source=agent

Shim logs

No recent shim problems found in system journal.


Container manager details

Have docker

Docker

Output of "docker version":

Client:
 Version:	17.12.1-ce
 API version:	1.35
 Go version:	go1.9.4
 Git commit:	7390fc6
 Built:	Tue Feb 27 22:17:40 2018
 OS/Arch:	linux/amd64

Server:
 Engine:
  Version:	17.12.1-ce
  API version:	1.35 (minimum version 1.12)
  Go version:	go1.9.4
  Git commit:	7390fc6
  Built:	Tue Feb 27 22:16:13 2018
  OS/Arch:	linux/amd64
  Experimental:	false

Output of "docker info":

Containers: 20
 Running: 0
 Paused: 0
 Stopped: 20
Images: 21
Server Version: 17.12.1-ce
Storage Driver: overlay2
 Backing Filesystem: extfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host kuryr macvlan null overlay
 Log: awslogs fluentd gcplogs gelf journald json-file logentries splunk syslog
Swarm: inactive
Runtimes: kata-runtime runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 9b55aab90508bd389d7654c4baf173a981477d55
runc version: 9f9c96235cc97674e935002fc3d78361b696a69e
init version: 949e6fa
Security Options:
 apparmor
 seccomp
  Profile: default
Kernel Version: 4.13.0-36-generic
Operating System: Ubuntu 16.04.3 LTS
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 15.56GiB
Name: kata
ID: VKY6:5MUT:XTOJ:BUY7:HLNT:DIZQ:FREY:BMYC:UCKF:PKU4:C6TP:F7KZ
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): true
 File Descriptors: 23
 Goroutines: 41
 System Time: 2018-03-09T23:47:39.297989065-08:00
 EventsListeners: 0
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Cluster Store: etcd://192.168.25.104:2379
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false

WARNING: No swap limit support

Output of "systemctl show docker":

Type=notify
Restart=on-failure
NotifyAccess=main
RestartUSec=100ms
TimeoutStartUSec=infinity
TimeoutStopUSec=1min 30s
RuntimeMaxUSec=infinity
WatchdogUSec=0
WatchdogTimestamp=Fri 2018-03-09 23:24:17 PST
WatchdogTimestampMonotonic=186880955801
FailureAction=none
PermissionsStartOnly=no
RootDirectoryStartOnly=no
RemainAfterExit=no
GuessMainPID=yes
MainPID=19361
ControlPID=0
FileDescriptorStoreMax=0
NFileDescriptorStore=0
StatusErrno=0
Result=success
ExecMainStartTimestamp=Fri 2018-03-09 23:24:16 PST
ExecMainStartTimestampMonotonic=186880482789
ExecMainExitTimestampMonotonic=0
ExecMainPID=19361
ExecMainCode=0
ExecMainStatus=0
ExecStart={ path=/usr/bin/dockerd ; argv[]=/usr/bin/dockerd --config-file=/etc/docker/daemon.json ; ignore_errors=no ; start_time=[Fri 2018-03-09 23:24:16 PST] ; stop_time=[n/a] ; pid=19361 ; code=(null) ; status=0/0 }
ExecReload={ path=/bin/kill ; argv[]=/bin/kill -s HUP $MAINPID ; ignore_errors=no ; start_time=[n/a] ; stop_time=[n/a] ; pid=0 ; code=(null) ; status=0/0 }
Slice=system.slice
ControlGroup=/system.slice/docker.service
MemoryCurrent=1224101888
CPUUsageNSec=17739597183
TasksCurrent=195
Delegate=yes
CPUAccounting=no
CPUShares=18446744073709551615
StartupCPUShares=18446744073709551615
CPUQuotaPerSecUSec=infinity
BlockIOAccounting=no
BlockIOWeight=18446744073709551615
StartupBlockIOWeight=18446744073709551615
MemoryAccounting=no
MemoryLimit=18446744073709551615
DevicePolicy=auto
TasksAccounting=no
TasksMax=18446744073709551615
Environment=HTTP_PROXY= HTTPS_PROXY= NO_PROXY=
UMask=0022
LimitCPU=18446744073709551615
LimitCPUSoft=18446744073709551615
LimitFSIZE=18446744073709551615
LimitFSIZESoft=18446744073709551615
LimitDATA=18446744073709551615
LimitDATASoft=18446744073709551615
LimitSTACK=18446744073709551615
LimitSTACKSoft=8388608
LimitCORE=18446744073709551615
LimitCORESoft=18446744073709551615
LimitRSS=18446744073709551615
LimitRSSSoft=18446744073709551615
LimitNOFILE=1048576
LimitNOFILESoft=1048576
LimitAS=18446744073709551615
LimitASSoft=18446744073709551615
LimitNPROC=18446744073709551615
LimitNPROCSoft=18446744073709551615
LimitMEMLOCK=65536
LimitMEMLOCKSoft=65536
LimitLOCKS=18446744073709551615
LimitLOCKSSoft=18446744073709551615
LimitSIGPENDING=62984
LimitSIGPENDINGSoft=62984
LimitMSGQUEUE=819200
LimitMSGQUEUESoft=819200
LimitNICE=0
LimitNICESoft=0
LimitRTPRIO=0
LimitRTPRIOSoft=0
LimitRTTIME=18446744073709551615
LimitRTTIMESoft=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=50000
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=journal
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SyslogLevel=6
SyslogFacility=3
SecureBits=0
CapabilityBoundingSet=18446744073709551615
AmbientCapabilities=0
MountFlags=0
PrivateTmp=no
PrivateNetwork=no
PrivateDevices=no
ProtectHome=no
ProtectSystem=no
SameProcessGroup=no
UtmpMode=init
IgnoreSIGPIPE=yes
NoNewPrivileges=no
SystemCallErrorNumber=0
RuntimeDirectoryMode=0755
KillMode=process
KillSignal=15
SendSIGKILL=yes
SendSIGHUP=no
Id=docker.service
Names=docker.service
Requires=system.slice docker.socket sysinit.target
Wants=network-online.target
WantedBy=multi-user.target
ConsistsOf=docker.socket
Conflicts=shutdown.target
Before=multi-user.target shutdown.target
After=network-online.target firewalld.service systemd-journald.socket docker.socket basic.target sysinit.target system.slice
TriggeredBy=docker.socket
Documentation=https://docs.docker.com
Description=Docker Application Container Engine
LoadState=loaded
ActiveState=active
SubState=running
FragmentPath=/lib/systemd/system/docker.service
DropInPaths=/etc/systemd/system/docker.service.d/docker.conf
UnitFileState=enabled
UnitFilePreset=enabled
StateChangeTimestamp=Fri 2018-03-09 23:24:17 PST
StateChangeTimestampMonotonic=186880955803
InactiveExitTimestamp=Fri 2018-03-09 23:24:16 PST
InactiveExitTimestampMonotonic=186880482821
ActiveEnterTimestamp=Fri 2018-03-09 23:24:17 PST
ActiveEnterTimestampMonotonic=186880955803
ActiveExitTimestamp=Fri 2018-03-09 23:24:15 PST
ActiveExitTimestampMonotonic=186879433907
InactiveEnterTimestamp=Fri 2018-03-09 23:24:16 PST
InactiveEnterTimestampMonotonic=186880480512
CanStart=yes
CanStop=yes
CanReload=yes
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=no
RefuseManualStop=no
AllowIsolate=no
DefaultDependencies=yes
OnFailureJobMode=replace
IgnoreOnIsolate=no
NeedDaemonReload=no
JobTimeoutUSec=infinity
JobTimeoutAction=none
ConditionResult=yes
AssertResult=yes
ConditionTimestamp=Fri 2018-03-09 23:24:16 PST
ConditionTimestampMonotonic=186880482149
AssertTimestamp=Fri 2018-03-09 23:24:16 PST
AssertTimestampMonotonic=186880482149
Transient=no
StartLimitInterval=60000000
StartLimitBurst=3
StartLimitAction=none

No kubectl


Packages

Have dpkg
Output of "dpkg -l|egrep "(cc-oci-runtime|cc-proxy|cc-runtime|cc-shim|kata-proxy|kata-runtime|kata-shim|clear-containers-image|linux-container|qemu-lite|qemu-system-x86)"":

ii  cc-proxy                                   3.0.19+git.318ac7e-24                        amd64        
ii  cc-runtime                                 3.0.19+git.900d623-24                        amd64        
ii  cc-runtime-bin                             3.0.19+git.900d623-24                        amd64        
ii  cc-runtime-config                          3.0.19+git.900d623-24                        amd64        
ii  cc-shim                                    3.0.19+git.557fe9b-24                        amd64        
ii  clear-containers-image                     20640-47                                     amd64        Clear containers image
ii  linux-container                            4.9.60-84                                    amd64        linux kernel optimised for container-like workloads.
ii  qemu-lite                                  2.7.1+git.d4a337fe91-11                      amd64        linux kernel optimised for container-like workloads.
ii  qemu-system-x86                            1:2.10+dfsg-0ubuntu3.4~cloud0                amd64        QEMU full system emulation binaries (x86)

No rpm


kata-proxy.log
kata-runtime.log
kata-shim.log

Import virtcontainers into Kata Containers runtime

As agreed by the community through issue #33, we have to import virtcontainers into the runtime repo.

Currently the virtcontainers code lives under https://github.com/containers/virtcontainers, and the plan is to move it from there to https://github.com/kata-containers/runtime/virtcontainers/. This will happen gradually:

  1. Import the latest virtcontainers release into kata-containers/runtime
  2. Set the kata-containers/runtime CI to test any kata-containers/runtime/virtcontainers/ change against github.com/clearcontainers/runtime: We can only move virtcontainers upstream if we can guarantee that it does not break Clear Containers.
  3. Make the Clear Containers runtime switch to github.com/kata-containers/runtime/virtcontainers
  4. Stop accepting issues and PRs on https://github.com/containers/virtcontainers
  5. Import all existing virtcontainers issues and PRs into kata-containers/runtime/virtcontainers
  6. Redirect https://github.com/containers/virtcontainers to https://github.com/kata-containers/runtime/

Add pullapprove rules

Add pullapprove and make sure we need 2 approval in order to get a PR considered as merge-able.

Fix CLI and virtcontainers lint errors

Fix the lint failures resulting from the recent merges of:

  • the CLI (#41)
  • virtcontainers (#59)

Also, ensure that the sub-module directories (cc-runtime and runv) are ignored from all lint runs since:

  • they are references to other repos with their own set of checks.
  • they are both soon to be removed from this repository anyway.

Missing runtime Makefile

The runtime repository is missing a top level Makefile for building and (at least for now) selecting one of the 2 runtimes to be installed.

The Makefile installation step should also always create a symbolic link from kata-runtime to the runtime of choice binary name.

For example, in the cc-runtime case:

$ export KATA_RUNTIME=cc
$ make # Calls into make -C cc-runtime build-kata-system
$ make install # Calls into make -C cc-runtime install-kata-system and creates a link from kata-runtime to the cc binary

fix runv build

runv itself is a combination of a runtime library and a command line implementation. It has quite a few packages that import each other, which make it unable to build inside the kata runtime repo as a submodule.

virtcontainers: add support for plugins

Add support for dynamically adding external virtcontainers interface implementations. This allows for a clean way to allow for proprietary kata runtime extensions.

Suggest that we leverage golang's plugin package.
Plugins to call into the virtcontainers plugin API (RegisterPlugin())
Potentially supported plugin types:

  • Hypervisors
  • Metadata backend (For storing/fetching Kata runtime’s metadata)
  • VM caching/cloning

Existing implementations (for example hypervisors) will be registered as plugins but still built-in, while external plugin implementations will be presented as dynamic libraries.

Let's use this issue to define the API. This issue can be closed once the design is documented and plugin framework is merged.

Add support for process-less shim/proxy functionality

Requirement:
Run sandbox without standalone shim/proxy process, nor any IPC that just exists just for message relay/translation.

To support real process-less shim/proxy functionality, we need to:

  1. add configuration options to allow to disable shim/proxy process spawning
  2. support shim functionality related sandbox APIs
  3. support kata agent connection with custom yamux based grpc dialer

Ref: kata-containers/documentation#27 on section Sandbox Relay API and Built-in Shim and Proxy Types and Capabilities.

virtcontainers: Implement Storage hotplug API

To help optimize the container boot process, virtcontainers needs to support hotplugging of storage and network devices. We need to define and implement an API for attaching NICs and storage endpoints to a Pod/Sandbox, such as:

func AddStorage(podID string) error {
        ...
}


AND/OR

func (p VCPod) AddStorage() error {
        ...
}

let's use this issue to define the API for storage hotplug. This should be closed once we have the design documented and implementation merged.

Issues: we should add an 'issue template' for reporting

We should discuss adding an 'issue template' to our repos, so we can request as much relevant information from end users at the time of Issue submission, rather than having to repeatedly ask them for one piece at a time etc.

runtime API revisit

On this week’s meeting, The kata-community discussed the merging and @ganwux made a short presentation.

We compare the API(#32) from the requirement(#31) and the APIs of virtcontainers, they don’t have fundamental conflicts.

The only critical difference is that virtcontainers operations(APIs) are pod-name based. Actually, these operations are mixtures(wrappers) of pure Pod operations and Persistence(resourceStorage) operations. In some cases, the mixture-style APIs are convenient. For example, when these APIs are used on oci-runtime-cli, every new cli command needs to restore sandbox object/interface from Persistence and do the operation which fit to these mixture-style of APIs.

To meet the requirements and to make the APIs to be cleaner, the mixture-style of APIs need to be split into pure sandbox APIs and Persistence(resourceStore) APIs, they will be the two main APIs sets of the library.

Pure sandbox operations(APIs) take Sandbox(golang interface) as its receiver. The user can call them multiple times with or without interacting with Persistence(resourceStorage).

The virtcontainer' resourceStorage(Persistence) interface needs to be exposed and become as a part of the APIs. The user can implement it on database(fratki/hyperd), filesystem(cc-runtime) or even memory.

So the major APIs should be pure sandbox APIs and Persistence APIs.

Another important difference is that, the proposed APIs (#32) have a minimal Storage/Network driver support and operations. It is just because the library should also support qcow2/ceph, enlightened/bridged networks (without net namespace) and some other complex Storage/Network. Like the docker world where Storage/Network driver are not a part of runtime, Storage/Network operations here are not a part of the CreateContainer()/RunContainer() either. The this separation is also important for performance. Drivers’ operations take time, qemu hotplugs take time and guest kernel hotplugs take time, and the separation-style API can make them run parallel: a device can be hotpluged in earlier as soon as it driver’s preparation is done, while the other driver’s preparations can still be ongoing.

Another two differences are the stream IO and detecting exceptions(agent crash, vm crash, qemu crash, proxy crash…). These APIs are very easy to be added later. The operation for detecting exceptions is almost useless on oci-runtime-cli cases, because these is no long running process to call the API. But they are useful for CRI (fratki/hyperd).

The last and the controversial difference is the exposure of the Agent/VM interfaces and the allowing the user to use their own implementations. The exposure makes the library users can configure out the proxy/shim processes which are unneeded in some cases (especially when CRI). The exposure makes the library users can easily add different hypervisors and vm-factories(vm-cache, vm-clone ...). Many people prefer them not to be exposed, we can add many implements in the library instead. I totally admit it as I don’t want this differences blocks our merging progress.

Remove git submodules cc-runtime and runv

Now that both cli and virtcontainers have been merged into the repository, we have the OCI wrapper and the Kata API. There is no need to point to the parent projects anymore.

Runtime merge proposal

Problem Statement

The Kata Containers project is a merge of 2 hardware virtualization based runtimes: Intel’s Clear Containers and Hyper’s runV. As of Feb 13th, 2018, the two runtimes live alongside under the Kata Containers runtime github repository. Having two codebases is confusing the community and impeding potential contributors to really commit to the project.

Although each runtime has its strengths and gaps, the next step for the Kata Containers project should be about combining the two runtimes into a single code base, and merging each runtime feature set into a larger one.

To reach that goal, these two approaches are proposed:

  1. Have the community pick one runtime and then work on filling the feature gaps.
  2. Find a technical way to pick the best components from each runtime and merge them into a single code base.

During the Feb 5th, 2018 Kata Containers Architecture meeting, the community decided to initially go with the first solution, i.e. picking one runtime over the other.
We believe this solution is a little too aggressive and may underestimate the engineering costs of filling the technical gaps of either runtime.

Goals

The goal of this proposal is to show that the second approach is viable and can be implemented. We think by mixing the best of the two runtime components we can accelerate the runtime merging process and reach the Kata Containers 1.0 release sooner.
This proposal aims at:

  • Building a flexible and extensible runtime based on a clean core framework
  • Providing a smooth upgrade path for both runV and Clear Containers users, by keeping all features from both runtimes early in the merge process
  • Accelerating the runtime merge process
  • Providing a base for efficient CRI implementations, for both OCI based CRI shims and native ones

High Level Architecture

By picking the virtcontainers framework that already implements the entire Clear Containers feature set, together with the runV hypervisor drivers, VM factory library and runtime API, we would combine the 2 runtimes features sets. Building the Kata Containers runtime on this combination of components would thus fulfill the Kata Containers runtime requirements.

The Kata Containers runtime would then be based on the following components:

  1. The virtcontainers library would be the core Kata Containers runtime framework.
  2. In order to have a hypervisor and architecture agnostic design, the runV hypervisor drivers for Xen, libvirt and kvm-tool would be added to the virtcontainers library.
  3. The virtcontainers API would be improved and extended in order to support the current runV and Frakti specific requirements.
  4. runV's virtual machine factory.

alt text

virtcontainers: define and implement pod based external API

The existing 1.0 API is designed for an OCI runtime binary's needs. A pod/sandbox is always restored from storage between runtime calls. A CRI serve, however, can keep sandbox pointers in memory
Current API examples:

func StartPod(podID string) (VCPod, error) {}

func StartContainer(podID, containerID string) (VCContainer, error) {}

These calls would be extended to, respectively:

func (p VCPod) StartPod() (error) {}

func (p VCPod) StartContainer(ctr VCContainer) (error) {}

Let's use this issue to define the extended API with respect to pod lifecycle. This should be closed once we have the API documented and implementation merged.

Sub-issues:

  • fetch/release sandbox: #217

docs: Add lifecycle documentation

We need a clear description of the expected "lifecycle" for different use cases (create, start, ...), with one or several diagrams going through the actions we expect from each component.

Avoid the mounting the blockdevice on the host and resulted compromises

It is better to avoid doing mount the block device in the host.

  1. the host might not have the ability to mount it. For example, if the block device is from ceph, and the host doesn't have krbd.ko. And even the host has it, userspace ceph lib + qemu are always the best choice.

  2. Security, if the block device was once mounted inside the vm, the host should not mount it. the code in the vm might hack into the guest kernel, and modify the metadata of the filesystem of the block device. The host kernel might be also broken into when mounting the block device.

  3. Performance: to speed up the starting of the container, host avoids mounting the block device on the host.

Compromises:

  1. access to /etc/passwd in the vm/sandbox, and string user name should be allowed in the agent API.
  2. init the docker-init layer inside the vm/sandbox.
  3. populate the content of the volume in vm/sandbox. (When a path which is not empty is assigned to be a volume, the content of the path should be copied to the volume when initializing the volume.)

virtcontainers: Split virtcontainers into subpackages

This issue follows the discussion started here.
There might be some reasons we want to move to split virtcontainers into smaller packages but I strongly believe that we'll end up modifying everything, which is gonna be very painful, for no effective gain IMO.

Ok, if you think about the way virtcontainers is designed, every interface that does not need to be public is not exported, which is the way it should be. Now if we want smaller packages, let's take an example with Pod and agent. The implementation of pod.go defines the Pod structure, which allows it to access the private fields of the structure Pod, and at the same time, some pod functions needs to interact with the agent by doing agent.createPod(pod) for instance. So, if you want to separate the agent from the pod, you will end up making your agent a public interface (I don't think that's a good idea because there is no reason to expose this to the public, but let's say we do it), now pod.go will have to import the agent as a package. Unfortunately, you will end up with the agent also needing to import virtcontainers (or more specifically what is described in pod.go) because it will need to know about the Pod structure definition. This is a cyclic dependency.
One way to workaround this would be to also move the Pod definition to a separate package, and you would have a pod.goimporting both those pod and agent packages. It works yay ! But is it worth it ??
The entire code will end up being exported (in this case, all fields from Pod will be exported).

I think we need some very good reasons if we want to move this way and which benefits we could get from this. Because this is going to take time and effort.

@sameo @markdryan I might have missed a way to achieve this in a simpler way, please let me know if you think that's the case.

unify command line API, configuration and annotations

Command line APIs, configuration file and annotations are parts of the cli API, they need to be unified. This unification is important for future fusing runv/cc into a single kata-runtime.

command line API

Both command lines of runv/cc are compatible with runc. But there are some differences respectively which should be also compatible with each other.

configuration file

cc has a global configuration file while runv doesn't. runv cli should use a configuration file(/usr/share/defaults/kata-containers/configuration.toml) like cc. But the details of the configuration file should be discussed more.

annotations

runv uses crio annotations, but it doesn't have its own annotations. However, cc has its own annotations with good definitions. To make runv/cc unified on annotations, it is better to rename the annotations of cc/virtcontainers to kata-containers' and make runv use these annotations.

Logging system for kata-containers

Now we have logrus and glog as candidate, both are widely used in the golang world. We all agree the logrus are more flexible and powerful. However, glog is come from Google, and used by most of the kubernetes family projects.

The question is, could we wrapped the log engine, which allows the users could select log engine if they import kata code as vendor?

tty output: May contain 'more data' than cc-runtime

Running:

 docker run -ti --runtime=cc-runtime ubuntu dmesg | wc
   1445   11185  110388

gives a significantly different answer than:

docker run -ti --runtime=kata-runtime ubuntu dmesg | wc
   1364   10516  917504

The line and word counts look similar enough, but the byte count is very different.
Now, it may be that kata is passing some of the control characters out from the dmesg more verbosely or similar, but I've not figured out why yet. If anybody has any ideas, please chip in.

Found this when running https://github.com/clearcontainers/tests/blob/master/metrics/time/launch_times.sh#L101, which failed to find the 'end' of the kernel boot - I suspect as the output is so much larger we may have simply run out of buffer space somewhere in the script/shell.

Import runv and CC runtimes

Based on the discussion in the meeting of architecture committee, it is the time to import both runtime implementations into kata-containers/runtimes repo.

Having merged hyperhq/runv#651, the runV master could work with kata gRPC protocol now. And CC/virt-containers is on the similar stage.

Should we import them as a git submodule firstly? @sameo @tallclair @WeiZhang555

Add support for ephemeral volumes

Hi,

As of now all volumes are created on the host and passed to VM via 9pfs. But k8s allows you to create ephemeral volumes Also, these volumes can be backed by a ramdisk. Ephemeral volumes, as the name indicates, live and die with the pod. There is no reason to use 9pfs for this type of volume.

Kata needs to support these volumes by creating tempfs based volume inside of the VM.

The possible approach that I can think of,

  1. Detect if the volume getting attached is backed by a ramdisk (temfs)
  2. When VM boots, instruct init to create tempfs inside of VM
  3. Use the ramdisk created inside VM in step 2 with the containers of the pod.

Any thoughts?

StartContainer issue with devicemapper storage-driver

This issue is unique with devicemapper storage-driver (overlay works fine). I have a crio daemon with /usr/bin/cc-runtime as its runtime. My code is driving the crio via grpc to operate on VM/containers. Now assuming a VM is running a fedora container and nginx container, I used the command “crictl stop” to stop the fedora container. Below is the steps my code would do after detecting the fedora is gone:

  1. Tried to restart the same container id: failed, which is expected.
    StartContainer gRPC error: 2: failed to start container 4a30e457dc825531644d201206750c19fecbe079b88cf6ba91a08915366a0a7a: '/usr/bin/cc-runtime start 4a30e457dc825531644d201206750c19fecbe079b88cf6ba91a08915366a0a7a' failed: exit status 1

  2. Tried to remove the container: failed but we ignore the failure.
    gRPC error: 2: failed to delete container 4a30e457dc825531644d201206750c19fecbe079b88cf6ba91a08915366a0a7a: '/usr/bin/cc-runtime delete --force 4a30e457dc825531644d201206750c19fecbe079b88cf6ba91a08915366a0a7a' failed: Container not ready or stopped, impossible to delete (exit status 1)

  3. After 10 seconds, tried to create a new container: CreateContainer succeeded.

  4. Tried to start the new container: StartContainer failed, which is unexpected.
    failed to start container 36f685921bded0484871b1a6051554e837fd306b43e1e9d25cc85b94acdd9b20: '/usr/bin/cc-runtime start 36f685921bded0484871b1a6051554e837fd306b43e1e9d25cc85b94acdd9b20' failed: exit status 1

The syslog has this error during that period:
cc-runtime[28819]: time="2018-03-19T15:22:37.854147224-07:00" level=error msg="Failed to start container" arch=amd64 container-id=36f685921bded0484871b1a6051554e837fd306b43e1e9d25cc85b94acdd9b20 error="ERROR received from VM agent, control msg received : Timed out waiting for device vde" pod-id=14347b0d546b45543597c26ff456e5b35f5adca166e2541befcab1cb05fed025 source=virtcontainers subsystem=container

Enable checkcommits

Enable checkcommits which will requires that all PRs have:

  • a Signed-off-by: line.
  • a Fixes #XXX comment where XXX is a github issue number.
  • Requires all commits to have a "sub-system" followed by a colon, followed by a brief description.
  • Requires a blank line after the subsystem.
  • Requires all commits to have a fuller description after the sub-system that will contain the Fixes ### and Signed-off-by: comments.

virtcontainers-setup.sh should not require the user to have a GOPATH set

As no one really sets it any more. From Go 1.8 onwards the Go tool will default to ~/go on linux if GOPATH is not set. As this is where most people store their Go code, no one really bothers setting GOPATH any more. It's a shame to force them to set this variable just to run the setup script. The good news is that there's a quick fix. Rather than using GOPATH from the user's environment, the script should call go env "GOPATH" instead, which will always return the correct location of the user's go code, whether the use has set GOPATH or not.

Handling of non-golang dependency versions

In Clear Containers, we have come to rely quite heavily on a file we maintain called versions.txt:

That file is used to define the versions of various depenencies for Clear Containers. For example:

  • supported version of golang.
  • hypervisor version details.
  • docker version.
  • k8s version.
  • rootfs image version from Clear Linux.

This file avoids hard-coding versions details in lots of different files (which makes maintenance very difficult). It is a simple database file in name=value format (crucially with comments) that can be sourced as a shell script or grep'd.

It's important to state that this file is not only used by the Clear Containers runtime repository: it is also used by the tests and packaging repositories to query version details.

We are going to need an equivalent for Kata Containers, but I'm wondering if we want to consider refining the approach slightly. The current approach is simple and proven, but it doesn't have much structure. A way of grouping variables would be very useful, for example for the CentOS package versions here:

Hence, I think we should consider creating a versions.yaml for Kata. We could then use a tool like https://github.com/mikefarah/yq to query the file:

$ go get github.com/mikefarah/yq
$ yq read versions.yaml centos.deps.glib.version
2.46.2
$ yq read versions.yaml docker.swarm.version
1.12.1

The advantage of YAML over JSON being a lot more flexibility in terms of structure, and -- a "killer" feature -- it supports comments! 😄

What do you think @sameo, @grahamwhaley, @chavafg, @gnawux, @bergwolf ?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.