Merge pull request #2978 from dmcgowan/cleanup-releases
Cleanup releases directory
This commit is contained in:
Phil Estes
GitHub
commit
a410405f5d
@ -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 = """ """
|
|
||||||
@ -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."""
|
|
||||||
@ -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]
|
|
||||||
@ -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]
|
|
||||||
@ -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]
|
|
||||||
Loading…
Reference in New Issue
Block a user