一. Kubernetes 整体架构
Kubernetes集群包含有Master组件(APIs，scheduler，controller等)和Node，一切都基于分布式的存储系统。
以下 K8s 架构图显示了 Kubernetes 集群的各组件之间的联系：
如果需要更加细节，则可以查看如下图：
二. Master架构设计
Control Plane 是K8S 集群的神经中枢。我们可以找到用于控制集群的 Kubernetes 组件以及一些有关集群状态和配置的数据。这些核心 Kubernetes 组件负责处理重要的工作，以确保容器以足够的数量和所需的资源运行。
Control Plane会一直与各个计算机保持联系。集群已被配置为以特定的方式运行，而控制平面要做的就是确保万无一失。
整体Master架构图如下：
2.1 集群API: kube-apiserver
kube-apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制。
当需要与 Kubernetes 集群进行交互时，就要通过 API。 Kubernetes API是 Kubernetes Control Plane的前端，用于处理内部和外部请求。API 服务器会确定请求是否有效，如果有效，则对其进行处理。用户通过 REST 调用、kubectl 命令行界面或其他命令行工具（例如 kubeadm）来访问 API。
2.2 集群调度：kube-scheduler
kube-scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上。
调度程序会考虑容器集的资源需求（例如 CPU 或内存）以及集群的运行状况。随后，它会将容器集安排到适当的计算节点。
2.3 集群控制器：kube-controller-manager
kube-controller-manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。
控制器负责实际运行集群，而 Kubernetes 控制器管理器则是将多个控制器功能合而为一。控制器用于查询调度程序，并确保有正确数量的容器集在运行。如果有容器集停止运行，另一个控制器会发现并做出响应。控制器会将服务连接至容器集，以便让请求前往正确的端点。还有一些控制器用于创建帐户和 API 访问令牌。
2.4 键值存储数据库：etcd
etcd保存了整个集群的状态。
应用的配置数据以及有关集群状态的信息位于etcd（k-v数据库）中。etcd 采用分布式、容错设计，被视为集群的最终事实来源。
三. Node架构设计
Kubernetes 集群中至少需要一个计算节点，但通常会有多个计算节点。Pods经过调度和编排后，就会在Node上运行。如果需要扩展集群的容量，那就要添加更多的Node。
Node端的架构设计图如下：
3.1 Pod
Pod是 Kubernetes 对象模型中最小、最简单的单元。
它代表了应用的单个实例。每个Pod都由一个容器（或一系列紧密耦合的容器）以及若干控制容器运行方式的选件组成。Pod可以连接至持久存储，以运行有状态应用。
3.2 Container Runtime Engine
Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）。
为了运行容器，每个Node都有一个容器运行时引擎。比如Docker，但 Kubernetes 也支持其他符合开源容器运动（OCI）标准的容器，例如 rkt 和 CRI-O。Kubernetes支持实现了CRI接口的其他大多数的容器。
3.3 kubelet
kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理。
每个计算节点中都包含一个 kubelet，这是一个与Control Plane通信的微型应用。kublet 可确保容器在Pod内运行。当Control Plane需要在节点中执行某个操作时，kubelet 就会执行该操作。
3.4 kube-proxy
kube-proxy负责为Service提供cluster内部的服务发现和负载均衡。
每个计算节点中还包含 kube-proxy，这是一个用于优化 Kubernetes 网络服务的网络代理。kube-proxy 负责处理集群内部或外部的网络通信（靠操作系统的数据包过滤层，或者自行转发流量）。
四. K8S Add-ons
4.1 Persistent Storage
除了管理运行应用的容器外，Kubernetes 还可以管理附加在集群上的应用数据。Kubernetes 允许用户请求存储资源，而无需了解底层存储基础架构的详细信息。持久卷（Persistent volumes）是集群（而非容器集）所特有的，因此其寿命可以超过容器集，例如PV和PVC等相关设计。
4.2 Container Registry
Kubernetes 所依赖的容器镜像存储于容器镜像仓库中。这个镜像仓库可以由您自己配置的，也可以由第三方提供，例如Harbor。
4.3 底层基础架构
我们可以决定具体在哪里运行 Kubernetes，例如裸机服务器、虚拟机、公共云提供商、私有云和混合云环境。Kubernetes 的一大优势就是它可以在许多不同类型的基础架构上运行。
五. 整体分层架构
K8S整体分层架构可以如下：
详细分层内容如下：
- 核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
- 应用层：部署（无状态应用Deployment、有状态应用Stateful、批处理任务Job、集群应用等）和路由（服务发现、DNS解析等）
- 管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
- 接口层：kubectl命令行工具、客户端SDK以及集群
- 生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
- Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
- Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
六. 总结
Kubernetes 提供了编排复杂的大型容器化应用所需的工具，但也对使用者的技能水平提出了很高的要求。当我们选择操作系统、容器运行时、持续集成/持续交付（CI/CD）工具、应用服务、存储以及其他大多数组件，都需要根据公司的实际情况来进行设计，K8S并不是银弹。
但是 Kubernetes的 灵活性，虽然实施起来可能比较复杂，但 Kubernetes 赋予了强大的功能，可以按照自己的条件运行容器化应用，让我们能够更加“敏捷”地适应“敏捷开发”。
这篇文章的架构只是属于非常简单的个人理解，关于K8S的知识框架还是在不断完善，欢迎指正和交流沟通。
Reference
https://www.redhat.com/en/topics/containers/kubernetes-architecture
https://www.kubernetes.org.cn/kubernetes%e8%ae%be%e8%ae%a1%e6%9e%b6%e6%9e%84
https://kubernetes.io/docs/concepts/architecture/