|
副问题[/!--empirenews.page--]
Kubernetes 已经成为容器编排调治规模的究竟尺度，其精良的架构不只担保了富厚的容器编排调治成果，同时也提供了各个条理的扩展接口以满意用户的定制化需求。个中，容器运行时作为 Kubernetes 打点和运行容器的要害组件，虽然也提供了轻盈易用的扩展接口，也就是 CRI(Container Runtime Interface)。
本文将先容 CRI 的由来、演进以及将来瞻望，首要内容分为四个部门：Kubernetes架构简介、容器运行时接口的根基道理、容器运行时的演进以及将来的瞻望。
Kubernetes 简介
我们知道，Kubernetes是一个开源的容器集群打点体系，它的成长很是敏捷，已经成为最风行和最活泼的容器编排体系。
从架构上来说，Kubernetes 的组件可以分为 Master 和 Node 两部门，个中 Master 是整个集群的大脑，全部的编排、调治、API 会见等都由 Master 来认真。
详细的来说，Master 包罗以下几个组件：
- etcd 生涯了整个集群的状态。
- kube-apiserver 提供了资源操纵的独一进口，并提招供证、授权、会见节制、API 注册和发明等机制。
- kube-controller-manager 认真维护集群的状态，包罗许多资源的节制器，是担保 Kubernetes 声明式 API 事变的大脑。
- kube-scheduler 认真资源的调治，凭证预定的调治计策将 Pod 调治到响应的 Node 上;
而 Node 则是认真运行详细的容器，并为容器提供存储、收集等须要的成果：
- kubelet 认真维持容器的生命周期，同时也认真 Volume(CSI)和收集(CNI)的打点;
- Container runtime 认真镜像打点以及 Pod 和容器的真正运行。Kubelet 默认的容器运行时为 Docker;
- kube-proxy 认真为 Service 提供 cluster 内部的处事发明和负载平衡
- Network plugin 也就基于 CNI(Container Network Internface)认真为容器设置收集。
除了这些焦点的组件以外，Kubernetes 虽然还包括了许多富厚的成果，这些都是通过扩展(Addon)的方法来陈设的。好比 kube-dns 和 metrics-server 等，都是以容器的方法陈设在集群内里，并提供 API 给其他组件挪用。
提醒：在 Kubernetes 中，凡是你可以听到两种差异范例的扩展 Kubernetes 成果的方法：1) 第一种是扩展(Addon)，好比 dashboard、EFK、Prometheus、各类 Operator 等，这些扩展不必要 Kubernetes 提供尺度的接口，可是都为 Kubernetes 增进了新的成果特征;2) 尚有一种方法则是插件(Plugin)，好比 CNI、CRI、CSI、Device Plugin 等，这些都是 Kubernetes 各个焦点组件提供了尺度的内置接口，而外部插件则是实现这些接口，从而将 Kubernetes 扩展到更多的用例场景中。
Kubelet 架构
适才提到，Kubelet 认真维持容器的生命周期。除此之外，它也共同 kube-controller-manager 打点容器的存储卷，并共同 CNI 打点容器的收集。下面就是 Kubelet 的简朴架构表示图：
你可以发明，Kubelet 也是有许多组件组成，包罗
- Kubelet Server 对外提供 API，供 kube-apiserver、metrics-server 等处事挪用。好比 kubectl exec 必要通过 Kubelet API /exec/{token} 与容器举办交互。
- Container Manager 打点容器的各类资源，好比 cgroups、QoS、cpuset、device 等。
- Volume Manager 打点容器的存储卷，好比名目化磁盘、挂载到 Node 当地、最后再将挂载路径传给容器。
- Eviction 认真容器的遣散，好比在资源不敷时遣散优先级低的容器，担保高优先级容器的运行。
- cAdvisor 认真为容器提供 metrics 数据源。
- Metrics 和 stats 提供容器和节点的怀抱数据，好比 metrics-server 通过 /stats/summary 提取的怀抱数据是 HPA 自动扩展的依据。
- 再向下就是 Generic Runtime Manager，这是容器运行时的打点者，认真跟 CRI 交互，完成容器和镜像的打点。
- 在 CRI 之下，包罗两种容器运行时的实现
- 一个是内置的 dockershim，实现了 docker 容器引擎的支持以及 CNI 收集插件(包罗 kubenet)的支持
- 另一个就是外部的容器运行时，用来支持 runc、containerd、gvisor 等外部容器运行时。
Kubelet 通过 CRI 接口跟外部容器运行时交互，而上图右侧就是 CRI 容器运行时的架构。它凡是包罗以下几个组件：
- CRI Server，这是 CRI gRPC server，监听在 unix socket 上面。在接头容器运行时的时辰，这个 Server 也凡是成为 CRI shim(夹在容器引擎和Kubelet之间的一层)。
- Streaming Server，提供 streaming API，用在 Exec、Attach、Port Forward 等流式接口上。
- 容器和镜像的打点，好比拉取镜像、建设和启动容器等。
- CNI 收集插件的支持，用于给容器设置收集。
- 最后是容器引擎(Container Engine)的打点，好比支持 runc 、containerd 可能支持多个容器引擎。
这样，Kubernetes 中的容器运行时凭证差异的成果就可以分为三个部门：
- 第一个是 Kubelet 中容器运行时的打点模块 Generic Runtime Manager，它通过 CRI 来打点容器和镜像。
- 第二个是容器运行时接口，是 Kubelet 与外部容器运行时的通讯接口。
- 第三个是详细的容器运行时实现，包罗 Kubelet 内置的 dockershim 以及外部的容器运行时(如 cri-o、cri-containerd 等)。
容器运行时接口(CRI)
容器运行时接口(CRI)，顾名思义，用来在 Kubernetes 扩展容器运行时，从而用户可以选择本身喜好的容器引擎。
（编辑：河北网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
