Kubernetes架构与组件

K8s 架构

当你部署完 Kubernetes，便拥有了一个完整的集群。一组工作机器，称为节点，会运行容器化应用程序。每个集群至少有一个工作节点（WorkerNode）。工作节点会托管Pod，而 Pod 就是作为应用负载的组件。

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

K8s 系统设计是遵循 c-s 架构的，也就是我们图中 apiserver 与其余组件的交互。Master 通常上包括 kube-apiserver、etcd 存储、kube-controller-manager、cloud-controller-manager、kube-scheduler 和用于 K8s 服务的 DNS 服务器（插件）。这些对集群做出全局决策（比如调度），以及检测和响应集群事件的组件集合也称为控制平面组件。

控制平面组件

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

kube-apiserver

提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制。这是 Kubernetes 控制平台的前端，可以水平扩展（通过部署更多的实例以达到性能要求）。kubectl/Kubernetes dashboard/kuboard 等 Kubernetes 管理工具就是通过 Kubernetes API 实现对 Kubernetes 集群的管理。

etcd

etcd 保存了整个集群的状态，支持一致性和高可用的键值存储组件，Kubernetes集群的所有配置信息都存储在 etcd 中。

kube-scheduler

负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上。监控所有新创建尚未分配到节点上的 Pod，并且自动选择为 Pod 选择一个合适的节点去运行。

影响调度的因素有：

• 单个或多个 Pod 的资源需求
• 硬件、软件、策略的限制
• 亲和与反亲和（affinity and anti-affinity）的约定
• 数据本地化要求
• 工作负载间的相互作用

kube-controller-manager

负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。此组件运行了所有的控制器。逻辑上来说，每一个控制器是一个独立的进程，但是为了降低复杂度，这些控制器都被合并运行在一个进程里。

kube-controller-manager 中包含的控制器有：

• 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
• 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
• 端点分片控制器（EndpointSlice controller）：填充端点分片（EndpointSlice）对象（以提供 Service 和 Pod 之间的链接）
• 服务账号控制器（ServiceAccount controller）：为新的命名空间创建默认的服务账号（ServiceAccount）

cloud-controller-manager

云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上，同时可以将云平台交互组件与本地集群中组件分离。

cloud-controller-manager 仅运行特定于云平台的控制回路。如果我们在自己的环境中运行 Kubernetes，大多数时候非混合云环境是用不到这个组件的。

与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。你可以对其执行水平扩容（运行不止一个副本）以提升性能或者增强容错能力。

以下控制器中包含与云供应商相关的依赖：

• 节点控制器：当某一个节点停止响应时，调用云供应商的接口，以检查该节点的虚拟机是否已经被云供应商删除
• 路由控制器：在云供应商的基础设施中设定网络路由
• 服务（Service）控制器：创建、更新、删除云供应商提供的负载均衡器
• 数据卷（Volume）控制器：创建、绑定、挂载数据卷，并协调云供应商编排数据卷

Node 组件

Node 组件运行在每一个节点上（包括 master 节点和 worker 节点），负责维护运行中的 Pod 并提供 Kubernetes 运行时环境。

kubelet

负责维护容器的生命周期，同时也负责 Volume（CVI）和网络（CNI）的管理。运行在每一个集群节点上的代理程序。它确保 Pod 中的容器处于运行状态。Kubelet 通过多种途径获得 PodSpec 定义，并确保 PodSpec 定义中所描述的容器处于运行和健康的状态。Kubelet 不管理不是通过 Kubernetes 创建的容器。

kube-proxy

kube-proxy 是一个网络代理程序，运行在集群中的每一个节点上，是实现 Kubernetes Service 概念的重要部分，负责为 Service 提供 cluster 内部的服务发现和负载均衡。

kube-proxy 在节点上维护网络规则。这些网络规则使得您可以在集群内、外正确地与 Pod 进行网络通信。如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。否则，kube-proxy 仅做流量转发。

容器引擎

容器引擎负责运行容器，负责镜像管理以及 Pod 和容器的真正运行（CRI）。Kubernetes 支持多种容器引擎：Docker、containerd、cri-o、rktlet 以及任何实现了 Kubernetes 容器引擎接口的容器引擎。

插件（Addons）

Addons 使用 Kubernetes 资源（DaemonSet、Deployment等）实现集群的功能特性。由于他们提供集群级别的功能特性，addons 使用到的 Kubernetes 资源都放置在 kube-system 名称空间下。

下面描述众多插件中的几种。有关可用插件的完整列表，请参见插件（Addons）。

DNS

Cluster DNS 是一个 DNS 服务器，是对您已有环境中其他 DNS 服务器的一个补充，存放了 Kubernetes Service 的 DNS 记录。Kubernetes 启动容器时，自动将该 DNS 服务器加入到容器的 DNS 搜索列表中。

除了 DNS Addon 以外，其他的 addon 都不是必须的，所有 Kubernetes 集群都应该有 Cluster DNS。

Web UI（控制台）

Dashboard 是 Kubernetes 集群的通用的、基于 Web 的用户界面。用户可以管理集群中运行的应用程序以及集群本身，并进行故障排除。

Kuboard

Kuboard 是一款基于 Kubernetes 的微服务管理界面，相较于 Dashboard，Kuboard 强调：

• 无需手工编写 YAML 文件
• 微服务参考架构
• 上下文相关的监控
• 场景化的设计
  • 导出配置
  • 导入配置

容器资源监控

容器资源监控（ContainerResource Monitoring）将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供浏览这些数据的界面。

集群层面日志

集群层面日志（Cluster-level Logging）机制负责将容器的日志数据保存到一个集中的日志存储中，这种集中日志存储提供搜索和浏览接口。