4.Kubernetes 架构

Kubernetes 采用微服务架构设计，整个系统被划分为各个功能独立的组件，这些组件之间边界清晰，部署简单，可以运行在多种系统和环境中。

Kubernetes 采用主从分布式架构，节点在角色上分为 Master 和 Node，下图为 Kubernetes 的架构图：

下面这张图表示的也是 Kubernetes 的架构设计以及组件之间的通信协议：

如果大家依然觉得上面的图示看上去比较抽象复杂的话，下面还有一个最简化的架构版本可以供大家目前作为参考理解：

最后，Kubernetes 的设计理念和功能类似于 Linux 分层架构，示意图如下：

Kubernetes Master 是控制节点，用于调度管理整个系统。它的架构图示如下：

有如下组件：

• Kubernetes API Server: 这是 Kubernetes 系统资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制，其中封装了核心对象的增删改查操作，外部的客户端和内部的组件可以通过调用 REST API 接口的方式获取数据信息，这些数据信息都存储到了 Etcd 中。
• Kubernetes Scheduler: 负责集群中的资源调度，比如：为新建的 Pod 分配机器。后续也可以根据需要替换为其它的调度器。
• Kubernetes Controller Manager: 负责执行各种控制器，用于保证 Kubernetes 的正常运行和维护集群的状态。
• Etcd: 存储中间件，用于保存集群所有的网络配置和对象的状态信息。Etcd 是高可用的键值存储系统，通过 Raft 一致性算法处理日志复制来保证强一致性。Kubernetes 中的重要数据都持久化到 Etcd 中，所有架构中的各个组件都是无状态的。

Kubernetes 中的控制器列表如下所示：

控制器	作用
Replication Controller	保证 Replication Controller 定义的副本数量与实际运行 Pod 的数量一致
Replication Controller	保证 Replication Controller 定义的副本数量与实际运行 Pod 的数量一致
Node Controller	定期检查 Node 的健康状态，标识出失效的 Node
Namespace Controller	定期清理无效的 Namespace，以及 Namespace 下的 API 对象，比如：Pod、Service、Secrte 等
Endpoints Controller	创建 Endpoints 作为 Service 的后端，当 Pod 发生变化时，定期刷新 Endpoints
Service Account Controller	为每个 Namespace 创建默认的 Service Account，并为 Service Account 创建 Service Account Secret
Persistent Volume Controller	使用 Persistent Volume 绑定新的 Persistent Volume Claim，清理回收已经释放的 Volume Claim
Daemon Set Controller	创建 Daemon Pod，保证指定的 Node 上正常运行 Daemon Pod
Deployment Controller	保证运行指定数目的 Pod，当 Deployment 更新时，控制实现 Replication Controller 和 Pod 的更新
Job Controller	为 Job 创建一次性任务 Pod，确保完成 Job 指定完成的任务数目
Pod Autoscaler Controller	实现 Pod 的自动伸缩，定时获取监控数据，进行策略匹配，当满足条件时执行 Pod 的伸缩动作

Kubernetes Node 是运行节点，主要用于运行管理业务的容器。它的架构图示如下：

有如下组件：

• Kubelet：主要负责维护容器的生命周期，Kubelet 可以从 Master 节点中的 Kubernetes REST API Server 中接收创建 Pod 的请求，启动和停止容器，监控容器运行状态并汇报给 Kubernetes API Server，也负责 Volume（CSI） 和网络（CNI）的管理。
• Kubernetes Proxy：负责为 Pod 创建代理服务，Kubernetes Proxy 会从 Master 节点中的 Kubernetes REST API Server 中获取所有的 Service，根据 Service 信息创建代理服务，实现 Service 到 Pod 的请求路由转发，实现 Kubernetes 层级的虚拟转发网络，换句话说也就是集群内部的服务发现和负载均衡。
• Kubernetes Container Runtime：容器运行时，Node 是使用容器运行的节点，可以使用多种容器，其中最常使用的就是 Docker 服务（CRI）。

除了前面提到的核心组件外，还有一些推荐的插件：

• CoreDNS：为整个集群提供 DNS 服务。
• Ingress Controller：为服务提供外网入口。
• Dashboard：提供 GUI（图形用户界面）。
• Federation：提供跨可用区的集群。
• Fluentd：日志收集。

Kubernetes 作为云原生应用的基础调度平台，等同于云原生的操作系统，考虑到系统的可扩展性开放了以下的接口，我们可以按照自己业务的需求对接不同的后端进行定制化，下面的三种资源类型是一个分布式操作系统最基础的资源类型，Kubernetes 将它们整合在了一起：

• CRI(Container Runtime Interface)：容器运行时接口，提供计算资源。其中定义了容器和镜像的服务接口，容器运行时和镜像的生命周期是彼此隔离的。Kubernetes 默认使用 Docker 作为容器运行时，也可以通过 CRI 接口指定其它容器运行时作为 Pod 的后端。
• CNI(Container Network Interface)：容器网络接口，提供网络资源。它由一组配置 Linux 容器的网络接口的规范和库组成，同时还包含了一些插件。
• CSI(Container Storage Interface)：容器存储接口，提供存储资源。