Jimmy Song
GitHub
commit
901fef8584
|
|
@ -1,6 +1,6 @@
|
|||
# CRI - Container Runtime Interface（容器运行时接口）
|
||||
|
||||
CRI中定义了**容器**和**镜像**的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，因此需要定义两个服务。该接口使用[Protocol Buffer](https://developers.google.com/protocol-buffers/)，基于[gRPC](https://grpc.io/)，在kubernetes v1.7+版本中是在[pkg/kubelet/apis/cri/v1alpha1/runtime](https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/apis/cri/v1alpha1/runtime)的`api.proto`中定义的。
|
||||
CRI中定义了**容器**和**镜像**的服务的接口，因为容器运行时与镜像的生命周期是彼此隔离的，因此需要定义两个服务。该接口使用[Protocol Buffer](https://developers.google.com/protocol-buffers/)，基于[gRPC](https://grpc.io/)，在Kubernetes v1.10+版本中是在[pkg/kubelet/apis/cri/runtime/v1alpha2](https://github.com/kubernetes/kubernetes/tree/master/pkg/kubelet/apis/cri/runtime/v1alpha2)的`api.proto`中定义的。
|
||||
|
||||
## CRI架构
|
||||
|
||||
|
|
@ -10,7 +10,7 @@ Container Runtime实现了CRI gRPC Server，包括`RuntimeService`和`ImageServi
|
|||
|
||||
## 启用CRI
|
||||
|
||||
除非集成了rktnetes，否则CRI都是被默认启用了，kubernetes1.7版本开始旧的预集成的docker CRI已经被移除。
|
||||
除非集成了rktnetes，否则CRI都是被默认启用了，从Kubernetes1.7版本开始，旧的预集成的docker CRI已经被移除。
|
||||
|
||||
要想启用CRI只需要在kubelet的启动参数重传入此参数：`--container-runtime-endpoint`远程运行时服务的端点。当前Linux上支持unix socket，windows上支持tcp。例如：`unix:///var/run/dockershim.sock`、 `tcp://localhost:373`，默认是`unix:///var/run/dockershim.sock`，即默认使用本地的docker作为容器运行时。
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ Container Runtime实现了CRI gRPC Server，包括`RuntimeService`和`ImageServi
|
|||
|
||||
## CRI接口
|
||||
|
||||
Kubernetes1.9中的CRI接口在`api.proto`中的定义如下：
|
||||
Kubernetes 1.9中的CRI接口在`api.proto`中的定义如下：
|
||||
|
||||
```protobuf
|
||||
// Runtime service defines the public APIs for remote container runtimes
|
||||
|
|
@ -115,20 +115,21 @@ service ImageService {
|
|||
|
||||
这其中包含了两个gRPC服务：
|
||||
|
||||
- **RuntimeService**：容器和Sandbox运行时管理
|
||||
- **RuntimeService**：容器和Sandbox运行时管理。
|
||||
- **ImageService**：提供了从镜像仓库拉取、查看、和移除镜像的RPC。
|
||||
|
||||
## 当前支持的CRI后端
|
||||
|
||||
我们最初在使用Kubernetes时通常会默认使用Docker作为容器运行时，其实从Kubernetes1.5开始已经开始支持CRI，目前是处于Alpha版本，通过CRI接口可以指定使用其它容器运行时作为Pod的后端，目前支持 CRI 的后端有：
|
||||
我们最初在使用Kubernetes时通常会默认使用Docker作为容器运行时，其实从Kubernetes 1.5开始已经开始支持CRI，目前是处于Alpha版本，通过CRI接口可以指定使用其它容器运行时作为Pod的后端，目前支持 CRI 的后端有：
|
||||
|
||||
- [cri-o](https://github.com/kubernetes-incubator/cri-o)：同时兼容OCI和CRI的容器运行时
|
||||
- [cri-containerd](https://github.com/containerd/cri-containerd)：基于[Containerd](https://github.com/containerd/containerd)的Kubernetes CRI 实现
|
||||
- [rkt](https://coreos.com/rkt/)：由于CoreOS主推的用来跟docker抗衡的容器运行时
|
||||
- [frakti](https://github.com/kubernetes/frakti)：基于hypervisor的CRI
|
||||
- [docker](https://www.docker.com)：kuberentes最初就开始支持的容器运行时，目前还没完全从kubelet中解耦，docker公司同时推广了[OCI](https://www.opencontainers.org/)标准
|
||||
- [clear-containers](https://github.com/clearcontainers)：由Intel推出的同时兼容OCI和CRI的容器运行时
|
||||
- [kata-containers](https://katacontainers.io/)：符合OCI规范同时兼容CRI
|
||||
- [Clear Containers](https://github.com/clearcontainers)：由Intel推出的同时兼容OCI和CRI的容器运行时
|
||||
- [Kata Containers](https://katacontainers.io/)：符合OCI规范同时兼容CRI
|
||||
- [gVisor](https://github.com/google/gvisor)：由谷歌推出的容器运行时沙箱(Experimental)
|
||||
|
||||
CRI是由[SIG-Node](https://kubernetes.slack.com/archives/sig-node)来维护的。
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue