One release per three weeks
| Release | Target Date | Contents | Comments |
|---|---|---|---|
| alpha1 | June 5 | rust-agent + ttrpc | repository consolidation half done |
| alpha2 | June 26 | repository consolidation + ci | |
| alpha3 | July 17 | close rust-agent feature gaps + image pulling inside sandbox (optional feature) + packaging release pipeline | |
| alpha4 | August 7 | observability/events/debuggability |
VM templates provides 38.68% speedup for kata containers when running with containerd shimv2.
| boot speed | |
|---|---|
| no-vm-template avg | 0.8199s |
| with-vm-template avg | 0.5028s |
| speedup | 38.68% |
CMD to run the test:
Hi if you are reading this document you may also want to create a kata Containers Release.
The Kata Containers Release Process is defined in the follwoing documents.
https://github.com/kata-containers/documentation/blob/master/Releases.md
To simply the process of read each release we have created a checklist for it.
Even if we ignore the time consumed by kata-runtime, docker still uses on average 0.629s (0.5526s, 0.684s, 0.588s, 0.69s) to create a new container. So we can claim that docker/containerd architecture makes docker(runc) always slower than hypercontainer now.
All above tests were done with kata persistent storage put in tmpfs. But it does not increate bootup speed. So kata runtime metadata plugin may not help performance either.
The most time consuming operation is kata-runtime create and it needs
syntax = "proto3";
package specs;
message Spec {
string Version = 1;
Process Process = 2;
string Hostname = 4;
docker在当一个volume的mountpoint在image里原本有数据的情况下,会把image的数据populate到volume中.这个行为在volume被mount到 多个mountpoint的时候,在不同的docker版本行为有差别.
[lear@~]$docker volume create --name foobar
foobar
[lear@~]$docker run --rm -t -v foobar:/vol/data1 -v foobar:/vol/data2 bergwolf/test ls /vol/data1 /vol/data2
| package main | |
| import ( | |
| "crypto/tls" | |
| "fmt" | |
| "github.com/bergwolf/goftp" | |
| ) | |
| func main() { |