云时代运维转型必读：容器运维模式的五大场景

当我们在Kubernetes里用kubectl执行各种命令时，这一切是通过Kubernetes工作节点里所谓“容器运行时”的软件在起作用。大家最熟悉的容器运行时软件当然是Docker，然而Docker只是Kubernetes支持的容器运行时技术的一种。

为了让Kubernetes不和某种特定的容器运行时(Docker)技术绑死，而是能无需重新编译源代码就能够支持多种容器运行时技术的替换，和我们面向对象设计中引入接口作为抽象层一样，在Kubernetes和容器运行时之间我们引入了一个抽象层，即容器运行时接口。以后就算Docker不再流行了，甚至有了Eocker、Focker等等，就可以通过CRI接口无缝地融入Kubernetes体系。

2)CSI (Container Storage Interface，容器存储接口)

CSI 代表容器存储接口，CSI 试图建立一个行业标准接口的规范，借助 CSI 容器编排系统(CO)可以将任意存储系统暴露给自己的容器工作负载。

类似于 CRI，CSI 也是基于 gRPC 实现。CSI 卷类型是一种 in-tree(即跟其它存储插件在同一个代码路径下，随 Kubernetes 的代码同时编译的) 的 CSI 卷插件，用于 Pod 与在同一节点上运行的外部 CSI 卷驱动程序交互。部署 CSI 兼容卷驱动后，用户可以使用 csi 作为卷类型来挂载驱动提供的存储。

3)CNI (Container Network Interface，容器存储接口)

CNI(Container Network Interface)是CNCF旗下的一个项目，由一组用于配置Linux容器的网络接口的规范和库组成，同时还包含了一些插件。CNI仅关心容器创建时的网络分配，和当容器被删除时释放网络资源。

Kubernetes 网络的发展方向是希望通过插件的方式来集成不同的网络方案， CNI 就是这一努力的结果。CNI只专注解决容器网络连接和容器销毁时的资源释放，提供一套框架，所以CNI可以支持大量不同的网络模式，并且容易实现。

CNI的接口中包括以下几个方法：

type CNI interface { 
    AddNetworkList(net *NetworkConfigList, rt *RuntimeConf) (types.Result, error) 
    DelNetworkList(net *NetworkConfigList, rt *RuntimeConf) error 
    AddNetwork(net *NetworkConfig, rt *RuntimeConf) (types.Result, error) 
    DelNetwork(net *NetworkConfig, rt *RuntimeConf) error 
} 

有四个方法：添加网络、删除网络、添加网络列表、删除网络列表。

5、Master-Node模式与Api-server

Kubernetes有几个核心组件：kube-apiserver、kube-controller-manager、kube-scheduler、kubelet、kube-proxy、CRI(一般是docker)等等。

它们分别是运行在Master或者Node节点上面，我把Master和Node称为物理组件，因为它们是运行于物理环境的，如物理机或者虚拟机。其中Master提供集群的管理控制中心，而Node是真正接受执行任务的工作节点，可以拟人化地理解为：Master是用人经理，Node是工作人员。

而Etcd是用于存储配置信息或者其他需要持久化的数据，独立于Master和Node节点，一般也是三副本的方式运行。

1)Master

区别于物理组件，逻辑组件是指在程序内的虚拟概念，例如运行在Master的逻辑组件有kube-apiserver、kube-controller-manager、kube-scheduler。

kube-apiserver用于暴露Kubernetes API。任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行。

kube-controller-manager运行管理控制器，它们是集群中处理常规任务的后台线程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成单个二进制文件，并在单个进程中运行。

kube-scheduler监视新创建没有分配到Node的Pod，为Pod选择一个Node。

这几个组件的用途不作特别展开，我们后面将详细聊聊Apiserver。

2)Node

Node是Kubernetes中的工作节点，最开始被称为minion。一个Node可以是VM或物理机。每个Node(节点)具有运行pod的一些必要服务，并由Master组件进行管理。

然后介绍运行于Node节点的组件：kubelet、kube-proxy、CRI(一般是docker)。

kubelet是主要的节点代理，它会监视已分配给节点的pod，具体功能如：安装Pod所需的volume;下载Pod的Secrets;Pod中运行的docker(或experimentally，rkt)容器;定期执行容器健康检查等等。

kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务抽象。

Docker等容器运行时，作用当然就是用于运行容器。

对于以上的Kubernetes的Master和Node的节点模式，在很多支持分布式架构的软件中都是类似的，如Hadoop等。他们的Master节点往往需要有3个以上，以实现高可用架构。很多软件架构也采取了这样的设计方式，都是为了生产环境所需的高可用性服务。

3)Api-server

（编辑：威海站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!