Update readme for containerd
This commit is contained in:
parent
9dea9654bd
commit
5f757c914c
1 changed files with 34 additions and 20 deletions
54
README.md
54
README.md
|
@ -1,6 +1,16 @@
|
||||||
# containerkit
|
# containerd
|
||||||
|
|
||||||
containerkit is a collection of components for building a fully featured container runtime, storage, and distribution layers in high level projects.
|
containerd is a daemon for managing images and containers on a single host.
|
||||||
|
It is built to be multi-tenant and handle multiple clients for container runtime needs.
|
||||||
|
|
||||||
|
## Features
|
||||||
|
|
||||||
|
* OCI Image Spec support
|
||||||
|
* OCI Runtime Spec support
|
||||||
|
* Image push and pull support
|
||||||
|
* Container runtime and lifecycle support
|
||||||
|
* Network primitives for creation, modification, and deletion of interfaces
|
||||||
|
* Multi-tenant supported with CAS storage for global images
|
||||||
|
|
||||||
## Scope and Principles
|
## Scope and Principles
|
||||||
|
|
||||||
|
@ -9,38 +19,42 @@ These following criteria will be used when reviewing pull requests, features, an
|
||||||
|
|
||||||
### Components
|
### Components
|
||||||
|
|
||||||
containerkit is a collection of components.
|
Components should not have tight dependencies on each other so that they are unable to be used independently.
|
||||||
These components can be used independently or together.
|
The APIs for images and containers should be designed in a way that when used together the components have a natural flow but still be useful independently.
|
||||||
They should not have tight dependencies on each other so that they are unable to be used independently but should be designed in a way that when used together the components have a natural flow to the APIs.
|
|
||||||
|
|
||||||
An example for this design can be seen with the overlay filesystems and the container execution layer.
|
An example for this design can be seen with the overlay filesystems and the container execution layer.
|
||||||
The execution layer and overlay filesystems can be used independently but if you were to use both, they share a common `Mount` struct that the filesystems produce and the execution layer consumes to start a container inside a root filesystem.
|
The execution layer and overlay filesystems can be used independently but if you were to use both, they share a common `Mount` struct that the filesystems produce and the execution layer consumes.
|
||||||
|
|
||||||
|
|
||||||
### Primitives
|
### Primitives
|
||||||
|
|
||||||
containerkit should expose primitives to solve problems instead of building high level abstractions.
|
containerd should expose primitives to solve problems instead of building high level abstractions in the API.
|
||||||
A common example of this is how build is implemented.
|
A common example of this is how build would be implemented.
|
||||||
Instead of having a build API in containerkit we should expose the lower level primitives that allow things like build to work.
|
Instead of having a build API in containerd we should expose the lower level primitives that allow things required in build to work.
|
||||||
Breaking up the filesystem APIs to allow snapshots, copy functionality, and mounts allow people implementing build at the higher levels more flexibility.
|
Breaking up the filesystem APIs to allow snapshots, copy functionality, and mounts allow people implementing build at the higher levels more flexibility.
|
||||||
|
|
||||||
|
|
||||||
### Extensibility and Defaults
|
### Extensibility and Defaults
|
||||||
|
|
||||||
For the various components in containerkit there should be defined extension points where implementations can be swapped for alternatives.
|
For the various components in containerd there should be defined extension points where implementations can be swapped for alternatives.
|
||||||
The best example of this is that containerkit will use `runc` from OCI as the default runtime in the execution layer but for other runtimes conforming to the OCI Runtime specification they can be easily added to contianerkit.
|
The best example of this is that containerd will use `runc` from OCI as the default runtime in the execution layer but other runtimes conforming to the OCI Runtime specification they can be easily added to containerd.
|
||||||
|
|
||||||
containerkit will come with a default implementation for the various components.
|
containerd will come with a default implementation for the various components.
|
||||||
These defaults will be chosen my the maintainers of the project and should not change unless better tech for that component comes out.
|
These defaults will be chosen my the maintainers of the project and should not change unless better tech for that component comes out.
|
||||||
Additional implementations will not be accepted into the core repository and should be developed in a separate repository not maintained by the containerkit maintainers.
|
Additional implementations will not be accepted into the core repository and should be developed in a separate repository not maintained by the containerd maintainers.
|
||||||
|
|
||||||
### Stability
|
### Releases
|
||||||
|
|
||||||
|
Containerd will be released with a 1.0 when feature complete and this version will be supported for 1 year with security and bug fixes applied and released.
|
||||||
|
|
||||||
|
The upgrade path for containerd is that the 0.0.x patch relases are always backward compatible with its major and minor version.
|
||||||
|
Minor (0.x.0) version will always be compatible with the previous minor release. i.e. 1.2.0 is backwards compatible with 1.1.0 and 1.1.0 is compatible with 1.0.0.
|
||||||
|
There is no compatiability guarentes with upgrades from two minor relases. i.e. 1.0.0 to 1.2.0.
|
||||||
|
|
||||||
|
There are not backwards compatability guarentes with upgrades to major versions. i.e 1.0.0 to 2.0.0.
|
||||||
|
Each major version will be supported for 1 year with bug fixes and security patches.
|
||||||
|
|
||||||
### Scope
|
### Scope
|
||||||
|
|
||||||
The following table specifies the various components of containerkit and general features of container runtimes.
|
The following table specifies the various components of containerd and general features of container runtimes.
|
||||||
The table specifies whether or not the feature/component is in or out of scope.
|
The table specifies whether or not the feature/component is in or out of scope.
|
||||||
|
|
||||||
| Name | Description | In/Out | Reason |
|
| Name | Description | In/Out | Reason |
|
||||||
|
@ -49,14 +63,14 @@ The table specifies whether or not the feature/component is in or out of scope.
|
||||||
| cow filesystem | Built in functionality for overlay, aufs, and other copy on write filesystems for containers | in | |
|
| cow filesystem | Built in functionality for overlay, aufs, and other copy on write filesystems for containers | in | |
|
||||||
| distribution | Having the ability to push, pull, package, and sign images | in | |
|
| distribution | Having the ability to push, pull, package, and sign images | in | |
|
||||||
| networking | Providing network functionality to containers along with configuring their network namespaces | in | |
|
| networking | Providing network functionality to containers along with configuring their network namespaces | in | |
|
||||||
| build | Building images as a first class API | out | Build is a higher level tooling feature and can be implemented in many different ways on top of containerkit |
|
| build | Building images as a first class API | out | Build is a higher level tooling feature and can be implemented in many different ways on top of containerd |
|
||||||
| volumes | Provide primitives for volumes and persistent storage | | |
|
| volumes | Provide primitives for volumes and persistent storage | | |
|
||||||
|
|
||||||
containerkit is scoped to a single host.
|
containerd is scoped to a single host.
|
||||||
It can be used to builds things like a node agent that launches containers but does not have any concepts of a distributed system.
|
It can be used to builds things like a node agent that launches containers but does not have any concepts of a distributed system.
|
||||||
|
|
||||||
Also things like service discovery are out of scope even though networking is in scope.
|
Also things like service discovery are out of scope even though networking is in scope.
|
||||||
containerkit should provide the primitives to create, add, remove, or manage network interfaces for a container but ip allocation, discovery, and DNS should be handled at higher layers.
|
containerd should provide the primitives to create, add, remove, or manage network interfaces for a container but ip allocation, discovery, and DNS should be handled at higher layers.
|
||||||
|
|
||||||
### How is the scope changed?
|
### How is the scope changed?
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue