一. 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/

转自:https://blog.wyatt.plus/archives/139