Kubernetes 的系统架构是怎样的？

前言

本文隶属于专栏《1000个问题搞定大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！

本专栏目录结构和参考文献请见1000个问题搞定大数据技术体系

正文

一个典型的 Kubernetes 集群由多个工作节点( worker node )和一个集群控制平面( control plane ，即 Master )，以及一个集群状态存储系统( etcd )组成。

其中 Master 节点负责整个集群的管理工作，为集群提供管理接口，并监控和编排集群中的各个工作节点。

各节点负责以 Pod 的形式运行容器，因此，各节点需要事先配置好容器运行依赖到的所有服务和资源，如容器运行时环境等。

Kubernetes 的系统架构如图所示。

Master 节点主要由 apiserver 、 controller - manager 和 scheduler 三个组件，以及一个用于集群状态存储的 etcd 存储服务组成，而每个 Node 节点则主要包含 kubelet 、 kube - proxy 及容器引擎( Docker 是最为常用的实现)等组件。

此外，完整的集群服务还依赖于一些附加组件，如 KubeDNS 等。

Master 组件

Kubernetes 的集群控制平面由多个组件组成，这些组件可统一运行于单一 Master 节点也可以以多副本的方式同时运行于多个节点，以为 Master 提供高可用功能，甚至还可以运行于 Kubernetes 集群自身之上。

Master 主要包含以下几个组件。

1.API Server

API Server 负责输出 RESTFUL 风格的 KubernetesAPI ，它是发往集群的所有 REST 操作命令的接入点，并负责接收、校验并响应所有的 REST 请求，结果状态被持久存储于 etcd 中。

因此， APIServer 是整个集群的网关。

2.集群状态存储( Cluster State Store )

Kubernetes 集群的所有状态信息都需要持久存储于存储系统 etcd 中，不过， etcd 是由 Cores 基于 Raft 协议开发的分布式键值存储，可用于服务发现、共享配置以及一致性保障(如数据库主节点选择、分布式锁等)。

因此， etcd 是独立的服务组件，并不隶属于 Kubernetes 集群自身。 生产环境中应该以 etcd 集群的方式运行以确保其服务可用性。

etcd 不仅能够提供键值数据存储，而且还为其提供了监听( Watch )机制，用于监听和准送变更。

Kubernetes 集群系统中， etcd 中的键值发生变化时会通知到 APIServer ，并由其通过 watchAPI 向客户端输出。

基于 Watch 机制， Kubernetes 集群的各组件实现了高效协同。

3. 控制器管理器( Controller Manager )

Kubernetes 中，集群级别的大多数功能都是由几个被称为控制器的进程执行实现的，这几个进程被集成于 kube - controller - manager 守护进程中。

由控制器完成的功能主要包括生命周期功能和 API 业务逻辑，具体如下。

• 生命周期功能:包括 Namespace 创建和生命周期、 Event 垃圾回收、 Pod 终止相关的垃圾回收、级联垃圾回收及 Node 垃圾回收等。
• API 业务逻辑:例如，由 ReplicaSet 执行的 Pod 扩展等。

4.调度器( Scheduler )

Kubernetes 是用于部署和管理大规模容器应用的平台，根据集群规模的不同，其托管运行的容器很可能会数以千计甚至更多。

API Server 确认 Pod 对象的创建请求之后，便需要由 Scheduler 根据集群内各节点的可用资源状态，以及要运行的容器的资源需求做出调度决策。

另外， Kubernetes 还支持用户自定义调度器。

Node 组件

Node 负责提供运行容器的各种依赖环境，并接受 Master 的管理。

每个 Node 主要由以下几个组件构成。

1.Node 的核心代理程序 kubelet

kubelet 是运行于工作节点之上的守护进程，它从 APIServer 接收关于 Pod 对象的配置信息并确保它们处于期望的状态( desired state )。

kubelet 会在 APIServer 上注册当前工作节点，定期向 Master 汇报节点资源使用情况，并通过 advisor 监控容器和节点的资源占用状况。

2. 容器运行时环境

每个 Node 都要提供一个容器运行时( Container Runtime )环境，它负责下载镜像并运行容器。

kubelet 并未固定链接至某容器运行时环境，而是以插件的方式载入配置的容器环境。

这种方式清晰地定义了各组件的边界。 目前， Kubernetes 支持的容器运行环境至少包括 Docker 、 RKT 、 cri - o 和 Fraki 等。

3.kube - proxy

每个工作节点都需要运行一个 kube - proxy 守护进程，它能够按需为 Service 资源对象生成 iptables 或 ipvs 规则，从而捕获访问当前 Service 的 Cluster 的流量并将其转发至正确的后端Pod对象。

核心附件

Kubernetes 集群还依赖于一组称为“附件”( ad - ons )的组件以提供完整的功能，它们通常是由第三方提供的特定应用程序，且托管运行于 Kubernetes 集群之上。

下面列出的几个附件各自为集群从不同角度引用了所需的核心功能。

• KubeDNS :在 Kubernetes 集群中调度运行提供 DNS 服务的 Pod ，同一集群中的其他 Pod 可使用此 DNS 服务解决主机名。 Kubernetes 自 1 . 11 版本开始默认使用 KubeDNS 项日为集群提供服务注册和服务发现的动态名称解析服务，之前的版本中用到的是 kube - dns 项目，而 SkyDNS 则是更早一代的项目。
• Kubernetes Dashboard : Kubernetes 集群的全部功能都要基于 Web 的 UI ，来管理集群中的应用甚至是集群自身。
• Heapster :容器和节点的性能监控与分析系统，它收集并解析多种指标数据，如资源利用率、生命周期事件等。 新版本的 Kubernetes 中，其功能会逐渐由 Prometheus 结合其他组件所取代。
• IngressController : Service 是一种工作于传统层的负载均衡器，而 Ingress 是在应用层实现的 HTTP ( s )负载均衡机制。 不过， Ingress 资源自身并不能进行“流量穿透”，它仅是一组路由规则的集合，这些规则需要通过 Ingress 控制器 ( IngressController ) 发挥作用。 目前，此类的可用项目有 Nginx 、 Traefik 、 Envoy 及 HAProxy 等。