初识kubernetes

对于一个刚刚接触kubernetes(k8s)的新手来说，想好更好的学习它，首先就要对它有一个大概的认知，所以本文我们先以全局观来介绍一个kubernets。

kubernetes架构

kubernetes 架构图

kubernets整体可以分为两大部分，分别为 Master 和 Node ，我们一般称其为节点，这两种角色分别对应着控制节点和计算节点，根据我们的经验可以清楚的知道 Master 是控制节点。

Master 节点

控制节点 Master 节点由三部分组成，分别为 Controller Manager 、 API Server 和 Scheduler ，它们相互紧密协作，每个部分负责不同的工作职责。

• controller-manager 全称为 kube-controler-manager，主要用来负责容器编排。如一个容器(实际上是pod，pod是最基本的调度单元。一般一个pod里会部署一个容器服务)服务可以指定副本数量，如果实际运行的副本数据与期望的不一致，则会自动再启动几个容器副本，最终实现期望的数量。
• api server 负责api服务，负责与etcd注册中心进行通讯
• scheduler 负责调度。如一个容器存放到k8s集群中的哪个node节点最为合适

实际上这三个节点的功能远远多于我们描述的。

Node 节点

对于计算节点node，一般我们可以理解为一台物理机或者vm服务器。同样node也是由多个组件组成，其中最为重要的一个就是 kubelet 组件。它负责与容器运行时(如 docker 项目)打交道。

这里有几个关键的接口

• CNI Container Networking Interface 负责 kubelet 与 网络(Network) 通讯。
• CRI Container Runtime Interface 负责 kubelet 与 运行时(Container Runtime) 通讯。定义了容器运行时的一些关键操作，如启动容器时需要的所有参数。
• CSI Container Storage Interface 负责 kubelet 与 存储(Volume Plugin) 通讯，
• OCI Open Container Initiative 可以看作是一个容器运行时标准。负责 运行时 Runtime 与 操作系统OS 通讯。即把CRI 请求转换成对Linux 操作系统的调用（如 namespace 和 cgroups)

对于CRI 和 OCI 接口的关系变成为下图所示

CRI / OCI

对于 CNI 接口来讲，不管你使用的什么容器技术，只要你可以通过 CNI 接口接入到k8s中就没有问题。实现此接口的容器运行时有 runC 和 gVisor。而对于 docker 项目来讲则需要借助 docker-shim 组成来实现，这也就导致了 《Kubernetes 将弃用 Docker 》。

docker 运行时

上图可以看出 docker 并没有实现 CRI 接口，而 k8s 项目中的 kubelet 又要使用这个接口通讯，所以只能使用 docker-shim 组件作为桥接服务，将 CRI 接口指令转换成 docker api，然后与 docker 进行通讯，官方不打算继续维护 docker-shim组件，也正是导致 docker 被 k8s 弃用的主要原因。

kubelet 组件还通过gRPC 协议与 Device Plugin 插件进行通讯, 实现k8s项目管理GPU等物理设备核心硬件。

而 kubelet 的另一个重要功能，则是调用网络插件和存储插件为容器配置网络和持久化存储。

由此可以看出 kubelet 组件在 Node 节点的重要性，每个 Node 节点也只有一个 kubelet 组件。

本文主要从全局观来讲了一个 kubernetes 的主要架构，相信以后随着更深入的学习对它们每个组件的理解会更加深刻。

参考资料

• K8s、Docker、CRI、OCI 之间的爱恨情仇
• 为什么 Kubernetes 要替换 Docker

原文：https://blog.haohtml.com/archives/30007