图解K8s源码 - 序章 - K8s组件架构

才浅Coding攻略

发布于 2022-12-12 18:16:49

5860

发布于 2022-12-12 18:16:49

在之前的文章中我们介绍了从传统部署方式到虚拟化再到容器部署方式的演变，随着容器数量规模的不断增大，我们急需一个大规模容器编排系统。Kubernetes是一个全新的基于容器技术的分布式架构解决方案，并且是一个一站式的完备的可弹性运行的分布式系统开发和支撑平台。

Docker容器：“我竟可以是个饭盒？！”

Kubernetes微服务常见概念及应用

Kubernetes具有以下特性：

服务发现和负载均衡 Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
存储编排 Kubernetes 允许自动挂载你选择的存储系统，例如本地存储、公共云提供商等。
自动部署和回滚 你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。
自动完成装箱计算 Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。
自我修复 Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。
密钥与配置管理 Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

Kubernetes属于主从设备模型（Master-Slave架构），由Master和Node节点组成。它的工作方式为 Kubernetes Cluster = N Master Node + N Worker Node：N主节点+N工作节点；N>=1。

Kubernetes架构借鉴了 Borg 的设计理念。Kubernetes 的整体架构跟 Borg 非常像，如下图所示，我们把服务分为运行在工作节点上的服务和组成集群级别控制板的服务：

Kubernetes组件架构如下图，其中包含Master节点的控制平面组件（Control Plane Components）和worker节点的Node 组件：

Kubernetes节点有运行应用容器必备的服务，而这些都是受Master的控制。控制平面的组件对集群做出全局决策(比如调度)，以及检测和响应集群事件（例如，当不满足部署的 replicas 字段时，启动新的 pod）。

kube-Apiserver: 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制。
kube-Controller-Manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。从逻辑上讲，每个控制器都是一个单独的进程，但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。这些控制器包括：
- 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
- 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
- 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）
- 服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）。（1.25版本前为服务账户和令牌控制器（Service Account & Token Controllers）：为新的命名空间创建默认账户和 API 访问令牌）
Etcd：键值数据库，负责存储整个集群的配置信息和各种资源的状态信息，因为有watch(观察者)的支持，各部件协调中的改变可以很快被察觉。详细内容见往期文章读猿码系列——2. 搞懂Etcd核心API
kube-Scheduler：负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上。
cloud-controller-manager：云控制器管理器是指嵌入特定云的控制逻辑的控制平面组件。

Node 节点下包含组件：

kubelet：负责维护容器的生命周期，同时也负责与Master节点中的api-server组件沟通，并按照api-server的指示，直接管理 Worker 节点。
kube-proxy ：负责为Service提供cluster内部的服务发现和负载均衡。
Container Runtime：负责镜像管理以及Pod和容器的真正运行。

除了核心组件，还有一些常用的Add-ons：

kube-dns负责为整个集群提供DNS服务
Ingress Controller为服务提供外网入口
Heapster提供资源监控
Dashboard提供GUI
Federation提供跨可用区的集群
Fluentd-elasticsearch提供集群日志采集、存储与查询

Pod 是 kubernetes 中可以创建和部署的最小也是最简的单位。代表着集群中运行的进程。在Kubenetes中，所有的容器均在Pod中运行,一个Pod可以承载一个或者多个相关的容器。同一个 Pod 中的容器会自动地分配到同一个 node 上。同一个 Pod 中的容器共享资源、网络环境和依赖，它们总是被同时调度。逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。Service 所针对的 Pod 集合通常是通过选择算符来确定的。

在Kubernetes中，Service是分布式集群架构的核心。一个Service对象拥有如下关键特征：

拥有唯一指定的名称（比如mysql-server）。
拥有一个虚拟IP地址（ClusterIP地址）和端口号。
能够提供某种远程服务能力。
能够将客户端对服务的访问请求转发到一组容器应用上。

概念上来讲，K8S 集群的服务，其实就是负载均衡或反向代理。

对于上面的组件架构图，我在B站刷到了一个非常有意思且易于理解的比喻，我先上图：

Master节点理解为一个集团总公司，其中Controller manager是公司的高层决策者，他将决策下发到API server秘书部，API server秘书部将决策备份到etcd资料库中保存起来，并通知给Scheduler调度者由他调度项目由哪个或者哪几个分厂去做，Scheduler调度者将结果反馈到API server秘书部，秘书部将调度结果存放到etcd资料库，并按调度结果来通知到各个分厂，然后通知Cloud controller manager外联部也就是外部云厂商。每个分厂中的kubelet厂长负责控制当前节点该搞哪些项目和不搞哪些项目，由API server秘书部通知kubelet厂长调度结果。kube-proxy是每个分厂的门卫大爷，他们知道每个分厂都在搞哪个项目，当有领导视察某个项目在哪个分厂时，由kube-proxy门卫大爷告知地址，并且大爷们之间信息是同步的。

API server秘书部是去总部访问的唯一入口；

kube-proxy门卫大爷是集群中控制网络的唯一入口；

我们的kubectl也是通过api-server才能传达给controller-manager。