github/containerd
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 2 Wiki Activity

Cleanup releases directory

Browse Source 
Remove pre-release files which do not match the recommended
release process. This will prevent confusion when using
previous releases for reference.

Signed-off-by: Derek McGowan <derek@mcgstyle.net>
This commit is contained in:
Derek McGowan 2019-02-05 09:29:24 -08:00
parent 5ba368748b
commit 823b7a8a05
No known key found for this signature in database
GPG Key ID: F58C5D0A4405ACDB
6 changed files with 0 additions and 634 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

103
releases/v1.0.0-beta.2.toml
View File

@ -1,103 +0,0 @@
# commit to be tagged for new release
commit = "HEAD"
project_name = "containerd"
github_repo = "containerd/containerd"
# previous release
previous = "v1.0.0-beta.1"
pre_release = true
preface = """\
This release rounds out much of the remaining feature set for the 1.0 release
time frame. In addition to a large number of bugfixes and utility additions,
services and methods have been added to the GRPC API to meet production use
cases. The highlight is garbage collection, along with database migrations,
plugin introspection and rich PID listing."""
# notable prs to include in the release notes, 1234 is the pr number
[notes]
[notes.gc]
title = "Garbage Collection"
description = """\
Full garbage collection support for cleaning up content, snapshots and metadata
for containerd resources. The implementation is based on well-known concurrent
mark and sweep and the approach allows for extensibility in collection
policies.
The GC is triggered `Container.Delete and Image.Delete. Note that images may
need to be re-pulled for proper support."""
[notes.migrations]
title = "Migrations"
description = """\
A lightweight migration framework is now part of containerd. This allows us to
safely evolve the schema between releases with the groundwork laid early.
As part of this release, a migration will be run to add back references in
support of garbage collection."""
[notes.introspection]
title = "Introspection API"
description = """\
The new introspection API allows for querying the state of containerd. The
`Plugins` method lists the state and exports of all initialized plugins in use
in a containerd instance.
```console
$ ctr plugins
TYPE ID PLATFORM STATUS
io.containerd.content.v1 content - ok
io.containerd.metadata.v1 bolt - ok
io.containerd.differ.v1 walking linux/amd64 ok
io.containerd.grpc.v1 containers - ok
io.containerd.grpc.v1 content - ok
io.containerd.grpc.v1 diff - ok
io.containerd.grpc.v1 events - ok
io.containerd.grpc.v1 healthcheck - ok
io.containerd.grpc.v1 images - ok
io.containerd.grpc.v1 namespaces - ok
io.containerd.snapshotter.v1 btrfs linux/amd64 error
io.containerd.snapshotter.v1 overlayfs linux/amd64 ok
io.containerd.grpc.v1 snapshots - ok
io.containerd.monitor.v1 cgroups linux/amd64 ok
io.containerd.runtime.v1 linux linux/amd64 ok
io.containerd.grpc.v1 tasks - ok
io.containerd.grpc.v1 version - ok
```"""
[notes.listpids]
title = "Rich ListPIDs"
description = """\
Listing PIDs through the task service can now provide runtime specific metadata
through the API. This is particularly interesting on the windows platform. The
following is an example of a Windows container `ps` output:
```console
$ ctr tasks ps <container-id>
PID INFO
3716 {ImageName:smss.exe CreatedAt:2017-10-10T17:51:45.1552607Z KernelTime_100Ns:156250 MemoryCommitBytes:348160 MemoryWorkingSetPrivateBytes:217088 MemoryWorkingSetSharedBytes:946176 ProcessID:3716 UserTime_100Ns:0}
5404 {ImageName:csrss.exe CreatedAt:2017-10-10T17:51:45.1848844Z KernelTime_100Ns:0 MemoryCommitBytes:606208 MemoryWorkingSetPrivateBytes:339968 MemoryWorkingSetSharedBytes:1560576 ProcessID:5404 UserTime_100Ns:0}
3628 {ImageName:wininit.exe CreatedAt:2017-10-10T17:51:45.1974386Z KernelTime_100Ns:156250 MemoryCommitBytes:983040 MemoryWorkingSetPrivateBytes:610304 MemoryWorkingSetSharedBytes:3448832 ProcessID:3628 UserTime_100Ns:0}
8576 {ImageName:services.exe CreatedAt:2017-10-10T17:51:45.2091635Z KernelTime_100Ns:468750 MemoryCommitBytes:2048000 MemoryWorkingSetPrivateBytes:1437696 MemoryWorkingSetSharedBytes:4182016 ProcessID:8576 UserTime_100Ns:0}
7892 {ImageName:lsass.exe CreatedAt:2017-10-10T17:51:45.2177712Z KernelTime_100Ns:937500 MemoryCommitBytes:2666496 MemoryWorkingSetPrivateBytes:1982464 MemoryWorkingSetSharedBytes:7561216 ProcessID:7892 UserTime_100Ns:312500}
6384 {ImageName:svchost.exe CreatedAt:2017-10-10T17:51:45.3676107Z KernelTime_100Ns:468750 MemoryCommitBytes:1896448 MemoryWorkingSetPrivateBytes:1277952 MemoryWorkingSetSharedBytes:4730880 ProcessID:6384 UserTime_100Ns:156250}
4904 {ImageName:svchost.exe CreatedAt:2017-10-10T17:51:45.5431743Z KernelTime_100Ns:312500 MemoryCommitBytes:1781760 MemoryWorkingSetPrivateBytes:1331200 MemoryWorkingSetSharedBytes:4952064 ProcessID:4904 UserTime_100Ns:0}
2092 {ImageName:svchost.exe CreatedAt:2017-10-10T17:51:45.5838844Z KernelTime_100Ns:156250 MemoryCommitBytes:2486272 MemoryWorkingSetPrivateBytes:2117632 MemoryWorkingSetSharedBytes:5668864 ProcessID:2092 UserTime_100Ns:312500}
6576 {ImageName:svchost.exe CreatedAt:2017-10-10T17:51:45.727607Z KernelTime_100Ns:156250 MemoryCommitBytes:1818624 MemoryWorkingSetPrivateBytes:1417216 MemoryWorkingSetSharedBytes:6684672 ProcessID:6576 UserTime_100Ns:156250}
2412 {ImageName:svchost.exe CreatedAt:2017-10-10T17:51:46.0427889Z KernelTime_100Ns:468750 MemoryCommitBytes:5570560 MemoryWorkingSetPrivateBytes:3915776 MemoryWorkingSetSharedBytes:5963776 ProcessID:2412 UserTime_100Ns:0}
5472 {ImageName:svchost.exe CreatedAt:2017-10-10T17:51:46.0827893Z KernelTime_100Ns:312500 MemoryCommitBytes:2625536 MemoryWorkingSetPrivateBytes:1908736 MemoryWorkingSetSharedBytes:7532544 ProcessID:5472 UserTime_100Ns:312500}
8756 {ImageName:svchost.exe CreatedAt:2017-10-10T17:51:46.1108672Z KernelTime_100Ns:312500 MemoryCommitBytes:1843200 MemoryWorkingSetPrivateBytes:1466368 MemoryWorkingSetSharedBytes:4612096 ProcessID:8756 UserTime_100Ns:0}
1508 {ImageName:svchost.exe CreatedAt:2017-10-10T17:51:46.1522136Z KernelTime_100Ns:2812500 MemoryCommitBytes:4816896 MemoryWorkingSetPrivateBytes:3600384 MemoryWorkingSetSharedBytes:9281536 ProcessID:1508 UserTime_100Ns:468750}
4612 {ImageName:svchost.exe CreatedAt:2017-10-10T17:51:46.2212148Z KernelTime_100Ns:937500 MemoryCommitBytes:3063808 MemoryWorkingSetPrivateBytes:2265088 MemoryWorkingSetSharedBytes:8667136 ProcessID:4612 UserTime_100Ns:156250}
5936 {ImageName:CExecSvc.exe CreatedAt:2017-10-10T17:51:46.2224031Z KernelTime_100Ns:0 MemoryCommitBytes:983040 MemoryWorkingSetPrivateBytes:737280 MemoryWorkingSetSharedBytes:3723264 ProcessID:5936 UserTime_100Ns:0}
4416 {ImageName:cmd.exe CreatedAt:2017-10-10T17:51:46.5943846Z KernelTime_100Ns:0 MemoryCommitBytes:1564672 MemoryWorkingSetPrivateBytes:356352 MemoryWorkingSetSharedBytes:2174976 ProcessID:4416 UserTime_100Ns:0}
8700 {ImageName:powershell.exe CreatedAt:2017-10-10T17:51:46.6120645Z KernelTime_100Ns:2343750 MemoryCommitBytes:24522752 MemoryWorkingSetPrivateBytes:19853312 MemoryWorkingSetSharedBytes:27156480 ProcessID:8700 UserTime_100Ns:10156250}
```
"""
[breaking]
[breaking.metrics]
pr = 1235
description = """ """

0
releases/v1.0.0-beta.3.toml → releases/v1.0.0-beta.toml
View File

81
releases/v1.0.0-rc.0.toml
View File

@ -1,81 +0,0 @@
# commit to be tagged for new release
commit = "HEAD"
project_name = "containerd"
github_repo = "containerd/containerd"
# previous release
previous = "v1.0.0-beta.3"
pre_release = true
preface = """\
The final 1.0 release stretch has been reached after 7 alphas and 4 betas full
of stability fixes, hardening, and API improvements. This release candidate
continues that pattern in including stability fixes, usability improvements and
performance optimizations.
As part of the preparation for supporting the release of Containerd 1.0, the
governance model has been updated. The same as in previous versions, the day to
day management of the project is taken care of by the maintainers. The roles
of chief maintainer and BDFL have been removed and a technical steering
committee has been added as an escalation point when consensus cannot be reached
among maintainers. See https://github.com/moby/tsc."""
# notable prs to include in the release notes, 1234 is the pr number
[notes]
[notes.ctr]
title= "Shim Memory Improvements"
description = """\
The shim memory usage has been identified as a key component to optimize. The
shim gets run for every container making memory usage multiplied by the
number of containers on a machine, requiring lower memory usage in order to
increase density.
In profiling the memory usage of the shim, it was discovered that the HTTP2
and GRPC stacks were accounting for a majority of the usage. Since the RPC
requests to the shim are fairly simple and there is no need for handling many
clients, a simpler protocol is now used with much less overhead. In order to
avoid changing the client or server code, ttrpc is used to generate code
similar to GRPC using the same protocol definitions, but using the lighter
weight protocol. This had the effect of drastically reducing the memory
usage of the shim.
Memory improvements over beta 2...
```
RSS CMD
3644 containerd-shim -namespace default -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/default/test10 -address /run/containerd/containerd.sock -containerd-binary /usr/local/bin/containerd -debug
15320 docker-containerd-shim --namespace moby --workdir /var/lib/docker/containerd/daemon/io.containerd.runtime.v1.linux/moby/ffa219303c1419b179393a1123f176bb4268337432b0ca7945bc7ac66db73cad --address /var/run/docker/containerd/docker-containerd.sock --runtime-root /var/run/docker/
```
See [ttrpc repository](https://github.com/stevvooe/ttrpc) for implementation."""
[notes.gc]
title= "Garbage Collector Improvements"
description = """\
Garbage collection is now scheduled by a background process which watches
changes and tracks the amount of time garbage collection is taking. It is able
to use that information to schedule garbage collection based on configuration
options. The default configuration option aims to limit the amount of time the
metadata store is locked for garbage collection to 20ms of every second.
Additionally image removal now has an option to synchronously cleanup all
referenced resources (such as snapshots). This option immediately schedules a
garbage collection and waits for it to complete before returning to the client.
Since the time to remove a snapshot depends on the size of the snapshot, the
time to synchronously remove an image cannot be consistent. For faster and
more consistent removals, images should be deleted asynchronously whenever
possible. Asynchronous remains the default."""
[breaking]
[breaking.api]
pr = 1797
description = "The snapshots GRPC service was renamed from snapshot."
[breaking.shim]
pr = 1767
description = """\
The shim protocol has changed to use ttrpc. The new protocol does not use
http2 and is not compatible with previous shim versions using grpc."""

150
releases/v1.1.0-rc.0.toml
View File

@ -1,150 +0,0 @@
# commit to be tagged for new release
commit = "HEAD"
project_name = "containerd"
github_repo = "containerd/containerd"
# previous release
previous = "v1.0.0"
pre_release = true
preface = """\
`containerd` provides a daemon for managing running containers.
1.1 is the second major release for `containerd` with added support for CRI, the
Kubernetes [Container Runtime Interface](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md).
CRI is a new plugin which allows connecting the containerd daemon directly to a
Kubernetes kubelet to be used as the container runtime. The CRI GRPC interface
listens on the same socket as the containerd GRPC interface and runs in the same
process.
In addition to all of the stability and bug fixes backported to 1.0,
1.1 includes...
- CRI plugin
- ZFS and AUFS snapshotter
- Improvements to the `ctr` tool
- Better support for multiple platforms
- Cross namespace content sharing
- Better mount cleanup
- Support for disabling plugins
- TCP debug address for remote debugging
- Update to Go 1.10
- Improvements to the garbage collector
## CRI Plugin
This release of `cri` is a native plugin of `containerd`. It is built into
`containerd` v1.1 and CRI services are enabled by default.
You can now use Kubernetes, with `containerd` directly, without having to use
the intermediate `cri-containerd` daemon. The `cri-containerd` daemon is
end-of-life.
*Note: Please [drain your node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) before
upgrading from older versions of `cri-containerd` to `containerd` v1.1.*
You can [use a containerd config file to configure the `cri` plugin](https://github.com/containerd/cri/blob/v1.0/docs/config.md).
### Untrusted Workload Runtime
To run an untrusted pod on a runtime for untrusted workload, such as
[Kata Containers](https://katacontainers.io/) or
[Clear Containers](https://clearlinux.org/containers), you can:
1. Configure a runtime for untrusted workload [with the config option `plugins.cri.containerd.untrusted_workload_runtime`](https://github.com/containerd/cri/blob/v1.0/docs/config.md).
2. Create an untrusted pod by setting the annotation `io.kubernetes.cri.untrusted-workload` to `true`, for example:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
annotations:
io.kubernetes.cri.untrusted-workload: true
spec:
containers:
- name: nginx
image: nginx
```
By default, `cri` will run pods with the default runtime. However, if a pod has
the `io.kubernetes.cri.untrusted-workload` annotation, the `cri` plugin will run
the pod with the runtime for untrusted workloads.
Unless configured otherwise, the default runtime is set to
[runc](https://github.com/opencontainers/runc).
### Container Runtime Interface v1alpha2
The supported CRI (Container Runtime Interface) version for Kubernetes v1.10 is
now `v1alpha2.` This release of `cri` has been updated to use CRI `v1alpha2`, so
**it only works with Kubernetes v1.10+.**
New CRI features added in `v1alpha2` are all supported:
* Container log rotation: Kubelet rotates container logs.
* Shared pid namespace: Support sharing pid namespace inside a pod.
### Registry Mirror
You can now setup registry configurations with the config option
`plugins.cri.registry`.
Currently only the `mirrors` option is supported. With it, you can specify
registry mirrors and secure/insecure connections.
([doc](https://github.com/containerd/cri/blob/v1.0/docs/registry.md))
### End-To-End Test
In terms of testing, we've passed:
* ALL CRI validation tests
* ALL node e2e tests
* ALL e2e tests
The containerd test coverage on GCE is equivalent with Docker now.
All the test results are public: https://k8s-testgrid.appspot.com/sig-node-containerd.
### Performance
We significantly improved pod start latency and cpu/memory usage of `cri` plugin
this release.
The continuous benchmark result is published on http://node-perf-dash.k8s.io/.
Job `ci-kubernetes-node-kubelet-benchmark` is for Docker 17.03, and
`ci-cri-containerd-node-e2e-benchmark` is for containerd with `cri` plugin.
All metrics of containerd are either better or comparable with Docker 17.03.
## Try It Out
If you would like to try containerd, please download the binaries included on
this release. If you are using Docker, this version of containerd will be used
in the next major release of Docker.
To set up containerd with Kubernetes...
* For a production quality cluster on GCE brought up with `kube-up.sh`, see [here](https://github.com/kubernetes-incubator/cri-containerd/blob/v1.0/docs/kube-up.md).
* For a multi-node cluster installer and bring up steps using ansible and kubeadm, see [here](https://github.com/kubernetes-incubator/cri-containerd/blob/v1.0/contrib/ansible/README.md).
* For creating a cluster from scratch on Google Cloud, see [Kubernetes the Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way).
* For a custom installation from release tarball, see [here](https://github.com/kubernetes-incubator/cri-containerd/blob/v1.0/docs/installation.md).
* To install use LinuxKit on a local VM, see [here](https://github.com/linuxkit/linuxkit/tree/master/projects/kubernetes).
## Support
The [_support horizon_](https://github.com/containerd/containerd/blob/master/RELEASES.md#support-horizon)
for containerd has been updated to include the 1.1 release. With the addition of
the CRI plugin, we are expanding the support horizon for 1.1 to include the
entire lifespan of Kubernetes 1.10. The containerd 1.1 release train will be
considered an active branch with new patches until March 23, 2019 at the
earliest, when 1.2 is released, or until Kubernetes 1.10 reaches end of life.
The 1.1 containerd API is completely compatible with 1.0, any client using 1.0
can safely upgrade to 1.1 without any incompatibilies. The CRI interface
included with the CRI plugin is only supported for Kubernetes 1.10. The CRI
interface is still considered alpha and will only be supported for Kubernetes
1.10. The CRI plugin in containerd 1.1 will also only be supported for
Kubernetes 1.10.
"""
# notable prs to include in the release notes, 1234 is the pr number
[notes]
[breaking]

150
releases/v1.1.0-rc.1.toml
View File

@ -1,150 +0,0 @@
# commit to be tagged for new release
commit = "HEAD"
project_name = "containerd"
github_repo = "containerd/containerd"
# previous release
previous = "v1.0.0"
pre_release = true
preface = """\
`containerd` provides a daemon for managing running containers.
1.1 is the second major release for `containerd` with added support for CRI, the
Kubernetes [Container Runtime Interface](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md).
CRI is a new plugin which allows connecting the containerd daemon directly to a
Kubernetes kubelet to be used as the container runtime. The CRI GRPC interface
listens on the same socket as the containerd GRPC interface and runs in the same
process.
In addition to all of the stability and bug fixes backported to 1.0,
1.1 includes...
- CRI plugin
- ZFS and AUFS snapshotter
- Improvements to the `ctr` tool
- Better support for multiple platforms
- Cross namespace content sharing
- Better mount cleanup
- Support for disabling plugins
- TCP debug address for remote debugging
- Update to Go 1.10
- Improvements to the garbage collector
## CRI Plugin
This release of `cri` is a native plugin of `containerd`. It is built into
`containerd` v1.1 and CRI services are enabled by default.
You can now use Kubernetes, with `containerd` directly, without having to use
the intermediate `cri-containerd` daemon. The `cri-containerd` daemon is
end-of-life.
*Note: Please [drain your node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) before
upgrading from older versions of `cri-containerd` to `containerd` v1.1.*
You can [use a containerd config file to configure the `cri` plugin](https://github.com/containerd/cri/blob/v1.0/docs/config.md).
### Untrusted Workload Runtime
To run an untrusted pod on a runtime for untrusted workload, such as
[Kata Containers](https://katacontainers.io/) or
[Clear Containers](https://clearlinux.org/containers), you can:
1. Configure a runtime for untrusted workload [with the config option `plugins.cri.containerd.untrusted_workload_runtime`](https://github.com/containerd/cri/blob/v1.0/docs/config.md).
2. Create an untrusted pod by setting the annotation `io.kubernetes.cri.untrusted-workload` to `true`, for example:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
annotations:
io.kubernetes.cri.untrusted-workload: true
spec:
containers:
- name: nginx
image: nginx
```
By default, `cri` will run pods with the default runtime. However, if a pod has
the `io.kubernetes.cri.untrusted-workload` annotation, the `cri` plugin will run
the pod with the runtime for untrusted workloads.
Unless configured otherwise, the default runtime is set to
[runc](https://github.com/opencontainers/runc).
### Container Runtime Interface v1alpha2
The supported CRI (Container Runtime Interface) version for Kubernetes v1.10 is
now `v1alpha2.` This release of `cri` has been updated to use CRI `v1alpha2`, so
**it only works with Kubernetes v1.10+.**
New CRI features added in `v1alpha2` are all supported:
* Container log rotation: Kubelet rotates container logs.
* Shared pid namespace: Support sharing pid namespace inside a pod.
### Registry Mirror
You can now setup registry configurations with the config option
`plugins.cri.registry`.
Currently only the `mirrors` option is supported. With it, you can specify
registry mirrors and secure/insecure connections.
([doc](https://github.com/containerd/cri/blob/v1.0/docs/registry.md))
### End-To-End Test
In terms of testing, we've passed:
* ALL CRI validation tests
* ALL node e2e tests
* ALL e2e tests
The containerd test coverage on GCE is equivalent with Docker now.
All the test results are public: https://k8s-testgrid.appspot.com/sig-node-containerd.
### Performance
We significantly improved pod start latency and cpu/memory usage of `cri` plugin
this release.
The continuous benchmark result is published on http://node-perf-dash.k8s.io/.
Job `ci-kubernetes-node-kubelet-benchmark` is for Docker 17.03, and
`ci-cri-containerd-node-e2e-benchmark` is for containerd with `cri` plugin.
All metrics of containerd are either better or comparable with Docker 17.03.
## Try It Out
If you would like to try containerd, please download the binaries included on
this release. If you are using Docker, this version of containerd will be used
in the next major release of Docker.
To set up containerd with Kubernetes...
* For a production quality cluster on GCE brought up with `kube-up.sh`, see [here](https://github.com/kubernetes-incubator/cri-containerd/blob/v1.0/docs/kube-up.md).
* For a multi-node cluster installer and bring up steps using ansible and kubeadm, see [here](https://github.com/kubernetes-incubator/cri-containerd/blob/v1.0/contrib/ansible/README.md).
* For creating a cluster from scratch on Google Cloud, see [Kubernetes the Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way).
* For a custom installation from release tarball, see [here](https://github.com/kubernetes-incubator/cri-containerd/blob/v1.0/docs/installation.md).
* To install use LinuxKit on a local VM, see [here](https://github.com/linuxkit/linuxkit/tree/master/projects/kubernetes).
## Support
The [_support horizon_](https://github.com/containerd/containerd/blob/master/RELEASES.md#support-horizon)
for containerd has been updated to include the 1.1 release. With the addition of
the CRI plugin, we are expanding the support horizon for 1.1 to include the
entire lifespan of Kubernetes 1.10. The containerd 1.1 release train will be
considered an active branch with new patches until April 4, 2019 at the
earliest, when 1.2 is released, or until Kubernetes 1.10 reaches end of life.
The 1.1 containerd API is completely compatible with 1.0, any client using 1.0
can safely upgrade to 1.1 without any incompatibilies. The CRI interface
included with the CRI plugin is only supported for Kubernetes 1.10. The CRI
interface is still considered alpha and will only be supported for Kubernetes
1.10. The CRI plugin in containerd 1.1 will also only be supported for
Kubernetes 1.10.
"""
# notable prs to include in the release notes, 1234 is the pr number
[notes]
[breaking]

150
releases/v1.1.0-rc.2.toml
View File

@ -1,150 +0,0 @@
# commit to be tagged for new release
commit = "HEAD"
project_name = "containerd"
github_repo = "containerd/containerd"
# previous release
previous = "v1.0.0"
pre_release = true
preface = """\
`containerd` provides a daemon for managing running containers.
1.1 is the second major release for `containerd` with added support for CRI, the
Kubernetes [Container Runtime Interface](https://github.com/kubernetes/community/blob/master/contributors/devel/container-runtime-interface.md).
CRI is a new plugin which allows connecting the containerd daemon directly to a
Kubernetes kubelet to be used as the container runtime. The CRI GRPC interface
listens on the same socket as the containerd GRPC interface and runs in the same
process.
In addition to all of the stability and bug fixes backported to 1.0,
1.1 includes...
- CRI plugin
- ZFS and AUFS snapshotter
- Improvements to the `ctr` tool
- Better support for multiple platforms
- Cross namespace content sharing
- Better mount cleanup
- Support for disabling plugins
- TCP debug address for remote debugging
- Update to Go 1.10
- Improvements to the garbage collector
## CRI Plugin
This release of `cri` is a native plugin of `containerd`. It is built into
`containerd` v1.1 and CRI services are enabled by default.
You can now use Kubernetes, with `containerd` directly, without having to use
the intermediate `cri-containerd` daemon. The `cri-containerd` daemon is
end-of-life.
*Note: Please [drain your node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) before
upgrading from older versions of `cri-containerd` to `containerd` v1.1.*
You can [use a containerd config file to configure the `cri` plugin](https://github.com/containerd/cri/blob/v1.0/docs/config.md).
### Untrusted Workload Runtime
To run an untrusted pod on a runtime for untrusted workload, such as
[Kata Containers](https://katacontainers.io/) or
[Clear Containers](https://clearlinux.org/containers), you can:
1. Configure a runtime for untrusted workload [with the config option `plugins.cri.containerd.untrusted_workload_runtime`](https://github.com/containerd/cri/blob/v1.0/docs/config.md).
2. Create an untrusted pod by setting the annotation `io.kubernetes.cri.untrusted-workload` to `"true"`, for example:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
annotations:
io.kubernetes.cri.untrusted-workload: "true"
spec:
containers:
- name: nginx
image: nginx
```
By default, `cri` will run pods with the default runtime. However, if a pod has
the `io.kubernetes.cri.untrusted-workload` annotation, the `cri` plugin will run
the pod with the runtime for untrusted workloads.
Unless configured otherwise, the default runtime is set to
[runc](https://github.com/opencontainers/runc).
### Container Runtime Interface v1alpha2
The supported CRI (Container Runtime Interface) version for Kubernetes v1.10 is
now `v1alpha2.` This release of `cri` has been updated to use CRI `v1alpha2`, so
**it only works with Kubernetes v1.10+.**
New CRI features added in `v1alpha2` are all supported:
* Container log rotation: Kubelet rotates container logs.
* Shared pid namespace: Support sharing pid namespace inside a pod.
### Registry Mirror
You can now setup registry configurations with the config option
`plugins.cri.registry`.
Currently only the `mirrors` option is supported. With it, you can specify
registry mirrors and secure/insecure connections.
([doc](https://github.com/containerd/cri/blob/v1.0/docs/registry.md))
### End-To-End Test
In terms of testing, we've passed:
* ALL CRI validation tests
* ALL node e2e tests
* ALL e2e tests
The containerd test coverage on GCE is equivalent with Docker now.
All the test results are public: https://k8s-testgrid.appspot.com/sig-node-containerd.
### Performance
We significantly improved pod start latency and cpu/memory usage of `cri` plugin
this release.
The continuous benchmark result is published on http://node-perf-dash.k8s.io/.
Job `ci-kubernetes-node-kubelet-benchmark` is for Docker 17.03, and
`ci-cri-containerd-node-e2e-benchmark` is for containerd with `cri` plugin.
All metrics of containerd are either better or comparable with Docker 17.03.
## Try It Out
If you would like to try containerd, please download the binaries included on
this release. If you are using Docker, this version of containerd will be used
in the next major release of Docker.
To set up containerd with Kubernetes...
* For a production quality cluster on GCE brought up with `kube-up.sh`, see [here](https://github.com/kubernetes-incubator/cri-containerd/blob/v1.0/docs/kube-up.md).
* For a multi-node cluster installer and bring up steps using ansible and kubeadm, see [here](https://github.com/kubernetes-incubator/cri-containerd/blob/v1.0/contrib/ansible/README.md).
* For creating a cluster from scratch on Google Cloud, see [Kubernetes the Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way).
* For a custom installation from release tarball, see [here](https://github.com/kubernetes-incubator/cri-containerd/blob/v1.0/docs/installation.md).
* To install use LinuxKit on a local VM, see [here](https://github.com/linuxkit/linuxkit/tree/master/projects/kubernetes).
## Support
The [_support horizon_](https://github.com/containerd/containerd/blob/master/RELEASES.md#support-horizon)
for containerd has been updated to include the 1.1 release. With the addition of
the CRI plugin, we are expanding the support horizon for 1.1 to include the
entire lifespan of Kubernetes 1.10. The containerd 1.1 release train will be
considered an active branch with new patches until April 13, 2019 at the
earliest, when 1.2 is released, or until Kubernetes 1.10 reaches end of life.
The 1.1 containerd API is completely compatible with 1.0, any client using 1.0
can safely upgrade to 1.1 without any incompatibilies. The CRI interface
included with the CRI plugin is only supported for Kubernetes 1.10. The CRI
interface is still considered alpha and will only be supported for Kubernetes
1.10. The CRI plugin in containerd 1.1 will also only be supported for
Kubernetes 1.10.
"""
# notable prs to include in the release notes, 1234 is the pr number
[notes]
[breaking]