Kubernetes 关键组件解析

Kubernetes 用来管理容器集群的平台。既然是管理集群，那么就存在被管理节点，针对每个 Kubernetes 集群都由一个 Master 负责管理和控制集群节点。

通过 Master 对每个节点 Node 发送命令。简单来说，Master 就是管理者，Node 就是被管理者。Node 可以是一台机器或者一台虚拟机。在 Node 上面可以运行多个 Pod，Pod 是 Kubernetes 管理的最小单位，同时每个 Pod 可以包含多个容器(Docker)。

1、API Server

APIServer 的核心功能是对核心对象（例如：Pod，Service，RC）的增删改查操作，同时也是集群内模块之间数据交换的枢纽。它包括常用的 API、访问（权限）控制、注册、信息存储(etcd)等功能。在它的下面可以看到 Scheduler，它将待调度的 Pod 绑定到 Node 上，并将绑定信息写入 etcd 中。etcd 包含在 APIServer 中，用来存储资源信息。

API Server 的架构从上到下分为 4 层：

• API 层：主要以 REST 方式提供各种 API 接口，针对 Kubernetes 资源对象的 CRUD 和 Watch 等主要 API，还有健康检查、UI、日志、性能指标等运维监控相关的 API。

• 访问控制层：负责身份鉴权，核准用户对资源的访问权限，设置访问逻辑(Admission Control)。

• 注册表层：选择要访问的资源对象。注意，Kubernetes 把所有资源对象都保存在注册表(Registry)中，如 Pod、Service、Deployment 等。

• etcd 数据库：保存创建副本的信息。用来持久化 Kubernetes 资源对象的 Key-Value 数据库。

当 kubectl 用 Create 命令建立 Pod 时，是通过 APIServer 中的 API 层调用对应的 RESTAPI 方法。之后会进入权限控制层，通过 Authentication 获取调用者身份，通过 Authorization 获取权限信息。

AdmissionControl 中可配置权限认证插件，通过插件来检查请求约束。例如，启动容器之前需要下载镜像，或者检查具备某命名空间的资源。还记得 redis-leader-deployment.yaml 中配置需要生成的 Pod 的个数为 1。

到了 Registry 层，会从 CoreRegistry 资源中取出 1 个 Pod 作为要创建的 Kubernetes 资源对象。然后将 Node、Pod 和 Container 信息保存到 etcd 中去。这里的 etcd 可以是一个集群，由于里面保存集群中各个 Node/Pod/Container 的信息，所以必要时需要备份，或者保证其可靠性。

通过 kubectl 根据配置文件向 APIServer 发送命令，在 Node 上面建立 Pod 和 Container。在 API Server，经过 API 调用、权限控制、调用资源和存储资源的过程，实际上还没有真正开始部署应用。

2、Controller Manager

Kubernetes 是一个自动化运行的系统，需要有一套管理规则来控制这套系统。Controller Manager 就是这个管理者，或者说是控制者。它包括 8 个 Controller，分别对应着副本、节点、资源、命名空间、服务等。

由于微服务的部署都是分布式的，所以对应的 Pod 及容器的部署也是。为了能够方便地找到这些 Pod 或者容器，引入了 Service(kube-proxy)进程，由它来负责反向代理和负载均衡的实施。

Kubernetes 需要管理集群中的不同资源，所以针对不同的资源要建立不同的 Controller。每个 Controller 通过监听机制获取 API Server 中的事件（消息），它们通过 API Server 提供的(List-Watch)接口监控集群中的资源，并且调整资源的状态。

可以把它想象成一个尽职的管理者，随时管理和调整资源。比如 MySQL 所在的 Node 意外宕机了，Controller Manager 中的 Node Controller 会及时发现故障，并执行修复流程。在部署了成百上千微服务的系统中，这个功能极大地协助了运维人员。由此可以看出，Controller Manager 是 Kubernetes 资源的管理者，是运维自动化的核心。

3、Scheduler 与 kubelet

Scheduler 的作用是，将待调度的 Pod 按照算法和策略绑定到 Node 上，同时将信息保存在 etcd 中。

如果把 Scheduler 比作调度室，那么下面这 3 件事就是它需要关注的，待调度的 Pod、可用的 Node，以及调度算法和策略。

简单地说，就是通过调度算法/策略把 Pod 放到合适的 Node 中。此时 Node 上的 kubelet 通过 API Server 监听到 Scheduler 产生的 Pod 绑定事件，然后通过 Pod 的描述装载镜像文件，并且启动容器。

也就是说 Scheduler 负责思考 Pod 放在哪个 Node 中，然后将决策告诉 kubelet，kubelet 完成 Pod 在 Node 的加载工作。也可以这样认为，Scheduler 是“boss”，kubelet 是干活的“工人”，它们都通过 API Server 进行信息交换。部署在 Kubernetes 中，Pod 如何访问其他的 Pod 呢？答案是通过 Kubernetes 的 Service 机制。

在 Kubernetes 中的 Service 定义了一个服务的访问入口地址(IP+Port)。Pod 中的应用通过这个地址访问一个或者一组 Pod 副本。Service 与后端 Pod 副本集群之间是通过 Label Selector 来实现连接的。Service 所访问的这一组 Pod 都会有同样的 Label，通过这种方法知道这些 Pod 属于同一个组。

4、kube-proxy

只有理解了 kube-proxy 的原理和机制，才能真正理解 Service 背后的实现逻辑。在 Kubernetes 集群的每个 Node 上都会运行一个 kube-proxy 服务进程，可以把这个进程看作 Service 的负载均衡器，其核心功能是将发送到 Service 的请求转发到后端的多个 Pod 上。

此外，Service 的 Cluster-IP 与 NodePort 是 kube-proxy 服务通过 iptables 的 NAT 转换实现的。kube-proxy 在运行过程中动态创建与 Service 相关的 iptables 规则。

由于 iptables 机制针对的是本地的 kube-proxy 端口，所以在每个 Node 上都要运行 kube proxy 组件。

因此在 Kubernetes 集群内部，可以在任意 Node 上发起对 Service 的访问请求。Pod 在 Kubernetes 内互相访问，外网访问 Pod。

另外，作为资源监控，Kubernetes 在每个 Node 和容器上都运行了 cAdvisor。它是用来分析资源使用率和性能的工具，支持 Docker 容器。kubelet 通过 cAdvisor 获取其所在 Node 及容器(Docker)的数据。

cAdvisor 自动采集 CPU、内存、文件系统和网络使用的统计信息。kubelet 作为 Node 的管理者，把 cAdvisor 采集上来的数据通过 RESTAPI 的形式暴露给 Kubernetes 的其他资源，让他们知道 Node/Pod 中的资源使用情况。

下面部署一个 Nginx 服务来说明 Kubernetes 系统各个组件调用关系。

首先需要明确，一旦 Kubernetes 环境启动后，master 和 node 都会将自身的信息存储到 etcd 数据库中。

一个 Nginx 服务的安装请求首先会被发送到 master 节点上的 API Server 组件。

API Server 组件会调用 Scheduler 组件来决定到底应该把这个服务安装到哪个 node 节点上。此时，它会从 etcd 中读取各个 Node 节点的信息，然后按照一定的算法进行选择，并将结果告知 API Server。

API Server 调用 Controller-Manager 去调用 Node 节点安装 Nginx 服务。Kubelet 接收到指令后，会通知 Docker，然后由 Docker 来启动一个 Nginx 的 Pod。

Pod 是 Kubernetes 的最小操作单元，容器必须跑在 Pod 中。这样，一个 Nginx 服务就开始运行了，如果需要访问 Nginx，就需要通过 kube-proxy 来对 Pod 产生访问的代理，这样外界用户就可以访问集群中的 Nginx 服务了。