初识kubernetes

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

kubernetes架构

8ee9f2fa987eccb490cfaa91c6484f67
kubernetes 架构图

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

Master 节点

控制节点 Master 节点由三部分组成,分别为 Controller ManagerAPI ServerScheduler ,它们相互紧密协作,每个部分负责不同的工作职责。

  • 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中就没有问题。实现此接口的容器运行时有 runCgVisor。而对于 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 的主要架构,相信以后随着更深入的学习对它们每个组件的理解会更加深刻。

参考资料