注意：本文旨在向初学者简要介绍k8s（Kubernetes )架构，让初学者有一个整体的印象，不至于被k8s复杂的结构吓晕，特别是没有容器，pod等基本概念的时候。

1. 什么是k8s?

可以看看Kubernetes的中文维基百科。

Kubernetes（常简称为K8s）是用于自动部署、扩展和管理“容器化（containerized）应用程序”的开源系统。该系统由Google设计并捐赠给Cloud Native Computing Foundation（今属Linux基金会）来使用。

也就是说k8s是一个可以管理容器化应用程序的系统。初学者可能往往不清楚容器，docker，Kubernetes等这些基础的概念和它们之间的关系，可以参考我写的一篇博客：
什么是k8s以及k8s中的几个基本概念的关系：容器，docker，pod，deployment - harry的文章

2. k8s（Kubernetes )架构简介

下面这张图是k8s的架构图（来源：k8s官方网站）

可以看到一个Kubernetes集群整体上由两部分组成：Control Plane（控制平面）和Node （节点）

2.1 Control Plane（控制平面）

Control Plane在很多地方也被称为master 节点（主节点），而其他的node也被称为worker节点（工作节点）（这里面也有master -worker的构建思想）。

控制平面组件会为集群做出全局决策，比如资源的调度。 以及检测和响应集群事件，例如当不满足部署的 replicas 字段时， 要启动新的 pod）。

控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。

我觉得这也是为什么Control Plane会被叫做主节点的原因吧。
它主要包括以下几个部分：

• kube-apiserver API
  服务器是 Kubernetes 控制平面的组件， 该组件负责公开了 Kubernetes API，负责处理接受请求的工作，提供了资源操作的唯一入口，并提供认证、授权、访问控制、相关等机制。 API 服务器是Kubernetes 控制平面的前端。

• etcd
  一致且高度可用的键值存储，用作 Kubernetes 的所有集群数据的后台数据库，主要是保存了整个集群的状态。etcd 采用分布式、容错设计，被视为集群的最终事实来源。

• kube-scheduler kube-scheduler 是 负责监视新创建的、未指定运行节点（node）的 Pods， 并调度节点来让 Pod 在指定的机器上面运行。

• kube-controller-manager
  kube-controller-manager 是控制平面的组件， 负责运行控制器进程。负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。 从逻辑上讲， 每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。

• cloud-controller-manager
  这个组件和云平台有关系，不需要太多关心。 一个 Kubernetes 控制平面组件， 嵌入了特定于云平台的控制逻辑。 云控制器管理器（Cloud Controller Manager）允许你将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。 cloud-controller-manager 仅运行特定于云平台的控制器。 因此如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的集群不需要有云控制器管理器。

2.2 Node

这里的Node 就是worker node，负责处理真正的业务需求的节点。包括以下几个部分

• kubelet
  这是一个与控制平面通信的微型应用。kubelet 可确保容器在容器集内运行。当控制平面需要在节点中执行某个操作时，kubelet 就会执行该操作。

• kube-proxy
  kube-proxy 是集群中每个节点（node）所上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。
  kube-proxy 维护节点上的一些网络规则， 这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。
  如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 否则，kube-proxy 仅做流量转发。

• 容器运行时（Container Runtime）
  **容器运行环境是负责运行容器的软件。**默认的容器运行时为 Docker；其他还有containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现

当然还可以自己选择一些插件（add-on），这里不再赘述。

下面这两张图可能可以更加清晰地看到k8s各个组件之间的关系

3. k8s（Kubernetes )架构中体现的分层的思想

其实这里可能还不太能看出k8s中的分层思想，在worker node内部有pod ，deployment， service， container等更能看出其中的分层的思想。其中的分层实现可能要以一个更大的范畴来进行考量。
可以参考参考资料2，比如里**面的api 接口和ecosystem也就是生态系统之间就存在着分层关系，外部的应用（如监控）可以利用这些api接口。而管理层和应用层之间的关系就包括上述master node和worker node之间的关系。**这些就是很深入的知识了。

参考资料：

下面的资料质量都很高，如果想要深入了解的话，很推荐大家看看

1. k8s官方网站
2. https://www.kubernetes.org.cn/docs
3. https://www.redhat.com/zh/topics/containers/kubernetes-architecture