CRI (Container Runtime Interface) consists of a protobuf API, specifications/requirements (to-be-added), and [libraries] (https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/server/streaming) for container runtimes to integrate with kubelet on a node. CRI is currently in Alpha.

In the future, we plan to add more developer tools such as the CRI validation tests.

Prior to the existence of CRI, container runtimes (e.g., docker, rkt) were integrated with kubelet through implementing an internal, high-level interface in kubelet. The entrance barrier for runtimes was high because the integration required understanding the internals of kubelet and contributing to the main Kubernetes repository. More importantly, this would not scale because every new addition incurs a significant maintenance overhead in the main kubernetes repository.

Kubernetes aims to be extensible. CRI is one small, yet important step to enable pluggable container runtimes and build a healthier ecosystem.

1. Start the image and runtime services on your node. You can have a single service acting as both image and runtime services.
2. Set the kubelet flags
   • Pass the unix socket(s) to which your services listen to kubelet: --container-runtime-endpoint and --image-service-endpoint.
   • Enable CRI in kubelet by--experimental-cri=true.
   • Use the "remote" runtime by --container-runtime=remote.

Please see the Status Update section for known issues for each release.

Note that CRI is still in its early stages. We are actively incorporating feedback from early developers to improve the API. Developers should expect occasional API breaking changes.

No, but we are working on it.

The first step is to switch kubelet to integrate with Docker via CRI by default. The current Docker CRI implementation already passes most end-to-end tests, and has mandatory PR builders to prevent regressions. While we are expanding the test coverage gradually, it is difficult to test on all combinations of OS distributions, platforms, and plugins. There are also many experimental or even undocumented features relied upon by some users. We would like to encourage the community to help test this Docker-CRI integration and report bugs and/or missing features to smooth the transition in the near future. Please file a Github issue and include @kubernetes/sig-node for any CRI problem.

Start kubelet with the following flags:

• Use the Docker container runtime by --container-runtime=docker(the default).
• Enable CRI in kubelet by--experimental-cri=true.

Please also see the known issues before trying out.

We plan to add CRI specifications/requirements in the near future. For now, these proposals and design docs are the best sources to understand CRI besides discussions on Github issues.

• Original proposal
• Exec/attach/port-forward streaming requests
• Container stdout/stderr logs
• Networking: The CRI runtime handles network plugins and the setup/teardown of the pod sandbox.

• cri-o
• rktlet
• frakti

• v1alpha1 version of CRI is released.

• #27097: Container metrics are not yet defined in CRI.
• #36401: The new container log path/format is not yet supported by the logging pipeline (e.g., fluentd, GCL).
• CRI may not be compatible with other experimental features (e.g., Seccomp).
• Streaming server needs to be hardened.
  • #36666: Authentication.
  • #36187: Avoid including user data in the redirect URL.

• Docker compatibility: Support only Docker v1.11 and v1.12.
• Network:
  • #35457: Does not support host ports.
  • #37315: Does not support bandwidth shaping.
• Exec/attach/port-forward (streaming requests):
  • #35747: Does not support nsenter as the exec handler (--exec-handler=nsenter).
  • Also see (#cri-1.5-known-issues) for limitations on CRI streaming.

• Email: sig-node (kubernetes-sig-node@googlegroups.com)
• Slack: https://kubernetes.slack.com/messages/sig-node