Kubernetes是一个用于容器编排的开源工具,是应用程序级别的虚拟化技术的必然结果。容器化技术运行单个内核上有多个独立的用户空间实例,这些实例就是容器。容器提供了将应用程序的代码、运行时、系统工具、系统库和配置打包到一个实例中的标准方法,并且容器是共享一个内核的。由于容器技术的兴起,导致大量的容器应用出现,所以出现了一些用来支持应用程序容器化部署和组织的容器编排技术,其中Kubernetes现在已经成为了容器编排领域事实上的一个标准。 **欢迎关注技术手册每日必更新,带你一步步成长为架构师......** ### ![](https://img.kancloud.cn/8a/75/8a753c3f2765cc0f4401286b5382f041_784x418.jpg) ### Kubernetes是一个由Google团队发起的开源项目,旨在管理跨多个主机的容器,用于自动部署、扩展和管理容器化的应用程序。Kubernetes的主要实现语言为Go语言。该项目的理论基础源于Google内部的Borg项目,这使得Kubernetes在理论上比其他开源项目更加先进。Borg系统一直被认为是Google公司内部最强大的“私密武器”,因此Kubernetes的理论基础也非常强大。 ### # 架构 Kubernetes 项目依托着 Borg 项目的理论优势,确定了一个如下图所示的全局架构图: ![](https://img.kancloud.cn/84/c8/84c8a8a0c2c3c5478fbb72ccfffa90a9_965x500.jpg) ### Kubernetes由Master节点和Node节点两种角色组成。Master节点是控制节点,负责管理整个Kubernetes集群的状态和配置信息。Node节点是工作节点,负责运行容器应用。可以将Master节点看作老板,负责管理和控制整个集群的运行状态;将Node节点看作员工,负责实际运行容器应用。这种角色分工使得Kubernetes可以高效地管理和运行容器化应用程序。 ### Kubernetes的Master节点由三个独立的组件组成,它们分别是kube-apiserver、kube-scheduler和kube-controller-manager。 > kube-apiserver是整个集群通信的核心组件,负责接收来自用户和管理员的请求,并将请求转发给其他组件进行处理。 > > kube-scheduler负责容器的调度,将容器应用程序调度到合适的节点上运行**。 > > kube-controller-manager则负责维护整个集群的状态,包括容器的运行状态、节点的状态等**。 整个集群的数据都是通过kube-apiserver保存到etcd数据库中的,其他所有组件之间的通信也都是通过kube-apiserver和etcd数据库进行通信,而不会直接与etcd进行通信。这种架构使得Kubernetes具有高可用性和可扩展性,能够满足各种规模的容器化应用程序的需求。 ### 工作节点(Node节点)上最核心的组件是kubelet,它负责与底层的容器运行时进行通信,比如Docker。Kubernetes将这个通信过程抽象成了一个远程调用接口,称为CRI(Container Runtime Interface)。这个接口定义了容器运行时的所有标准操作,例如创建和删除容器。目前,kubelet内置了Docker关于CRI的实现,因此如果底层使用的是Docker容器,则不需要单独安装CRI实现的组件。但是,其他容器运行时需要提供这样的接口实现组件。因此,Kubernetes不关心所部署的容器运行时是什么,只要它能够实现CRI接口,就可以被Kubernetes管理。这种设计使得Kubernetes具有很强的扩展性和灵活性,可以支持多种不同的容器运行时。 ### kubelet 的另外一个重要功能就是调用网络插件(`CNI`)和存储插件(`CSI`)为容器配置网络和存储功能,同样的 kubelet 也是把这两个重要功能通过接口暴露给外部了,所以如果我们想要实现自己的网络插件,只需要使用 CNI 就可以很方便的对接到 Kubernetes 集群当中去。 ### 可能下面的架构图看上去更清晰一些: ![](https://img.kancloud.cn/28/aa/28aa1d4ff0f7030c5e45128b451cb4c0_1858x1126.png)