Kubernetes组件

结合自己的理解来学习记录k8s各个组件的功能。

简述

k8s一般都是以集群模式在生产环境中启动的，每个机器可以称为一个节点。这种模式就像公司，都会有一个主节点(高层领导)来管理其它节点(普通员工)，这个主节点称为master节点，主节点一般不干重活，只负责管理，所以主节点一般不会去负责应用的部署；应用部署的工作交由其它节点来做，这些节点被称为工作节点即worker节点。

当然，master节点如果只有一个是不可靠的，因为如果这个master节点机器宕机了，那整个k8s集群将不可用，所以master节点一般有多个(奇数)来保证集群的高可用。多个master节点组成类似公司董事会股东的角色，会通过选举机制(投票少数服从多数)选出一个CEO来负责管理工作节点，一旦这个CEO所在机器宕机了，这些master节点会重新选举出一个新的CEO来主持工作，这样集群就能保证高可用。

总结，Kubernetes Cluster = N master Node + N worker Node，N >= 1。

以下摘自官方文档：

---

当你部署完 Kubernetes, 即拥有了一个完整的集群。

一个 Kubernetes 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。

工作节点托管作为应用负载的组件的 Pod 。控制平面管理集群中的工作节点和 Pod 。 为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。

本文档概述了交付正常运行的 Kubernetes 集群所需的各种组件。

官方文档写的有些难理解，这里可以将k8s集群理解为生活中的一个集团(公司)。

控制平面组件（Control Plane Components）

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

控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。 请参阅使用 kubeadm 构建高可用性集群 中关于跨多机器控制平面设置的示例。

个人理解：控制平面相当于集团的总部，是最核心的地方，一般是在master节点上的，每个worker节点要干什么任务都是由这里发号施令的。

kube-apiserver

API 服务器是 Kubernetes 控制面的组件， 该组件公开了 Kubernetes API。 API 服务器是 Kubernetes 控制面的前端。

Kubernetes API 服务器的主要实现是 kube-apiserver。 kube-apiserver 设计上考虑了水平伸缩，也就是说，它可通过部署多个实例进行伸缩。 你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。

个人理解：里面有各种操作的api，角色上相当于集团中最普通的员工(打工人)，脏活累活都是这里干的，而且集群中其它组件想和别的组件交互都得通过这里，这里就相当于中介，注意只有这里能和worker节点交互，和worker节点交互时具体是和worker节点上的kubelet交互的。

etcd

etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。

您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。

要了解 etcd 更深层次的信息，请参考 etcd 文档。

个人理解：数据库，Kubernetes所有集群数据都保存在这里。

kube-scheduler

控制平面组件，负责监视新创建的、未指定运行节点（node）的 Pods，选择节点让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。

个人理解：集团中的调度者，负责做出让Pod在合适的节点上运行的调度策略，其中一些调度的数据存入etcd的操作和选择Pod在哪个机器上都是通过apiserver来完成的。

kube-controller-manager

运行控制器进程的控制平面组件。

从逻辑上讲，每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。

这些控制器包括:

• 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
• 任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
• 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
• 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌

个人理解：可以理解为集团内的总经理(决策者)，决定worker节点要干什么，但是这里不直接和worker节点联系，而是通过apiserver这个普通员工来和worker节点取得联系；其中的一些k8s集群数据也是通过apiserver来将数据存入etcd中的。

cloud-controller-manager

云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

cloud-controller-manager 仅运行特定于云平台的控制回路。 如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的环境中不需要云控制器管理器。

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

下面的控制器都包含对云平台驱动的依赖：

• 节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除
• 路由控制器（Route Controller）: 用于在底层云基础架构中设置路由
• 服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器

个人理解：其它云平台上的controller-manager(cm)。

Node 组件

节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。

kubelet

一个在集群中每个节点（node）上运行的代理。 它保证容器（containers）都 运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

个人理解：当前worker节点上的总代理，相当于集团子公司的一把手。可以监控所在的worker节点的运行情况，要想和控制平面组件交互都是通过与apiserver交互实现的。

kube-proxy

kube-proxy 是集群中每个节点上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。

kube-proxy 维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信。

如果操作系统提供了数据包过滤层并可用的话，kube-proxy 会通过它来实现网络规则。否则， kube-proxy 仅转发流量本身。

个人理解：负责网络代理、路由，维护网络规则，有点像网络中心的角色，功能上类似注册中心。工作节点的ip可以转变成服务名供其它访问，类似于微服务中的以服务名相互调用，当一个请求到达时这里可以负责路由找到其对应的是哪个Pod。每个worker节点上的kube-proxy都能相互联系。

容器运行时（Container Runtime）

容器运行环境是负责运行容器的软件。

Kubernetes 支持容器运行时，例如 Docker、 containerd、CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

插件（Addons）

插件使用 Kubernetes 资源（DaemonSet、 Deployment等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

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

DNS

尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该 有集群 DNS， 因为很多示例都需要 DNS 服务。

集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录。

Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列表中。

Web 界面（仪表盘）

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

个人理解：k8s系统的前端界面。

容器资源监控

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

个人理解：可以集成第三方组件，目前主流的是Prometheus + Grafana。

集群层面日志

集群层面日志 机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。

个人理解：可以集成第三方组件，比如ELK和EFK，Elasticsearch、Logstash、Fluentd、Kibana。

---