什么是 Kubernetes？

在《Docker 容器技术》章节就有简单介绍 Kuberntes，它是谷歌开源的容器容器集群管理系统，是谷歌内部容器管理系统 Borg 的开源版本。

Borg 系统是谷歌内部使用很多的容器管理系统，在早期是采用 Chroot Jail 实现安全隔离，后期采用 Namespace，资源隔离是采用 CGroup 实现。

为什么谷歌要推出 Kubernetes 开源版本呢？我个人的理解是：

• 使用开源社区的力量来解决谷歌未解决的问题
• 在云原生领域分一杯羹
• 推动云原生的发展，毕竟谷歌在容器领域已经玩了许多年了

Kubernetes 具有以下特点：

• 便携性: 无论公有云、私有云、混合云还是多云架构都全面支持
• 可扩展: 它是模块化、可插拔、可挂载、可组合的，支持各种形式的扩展
• 自修复: 它可以自保持应用状态、可自重启、自复制、自缩放的，通过声明式语法提供了强大的自修复能力

使用 Kubernetes, 您可以快速高效地响应客户需求:

• 快速、可预测地部署您的应用程序
• 拥有即时扩展应用程序的能力
• 不影响现有业务的情况下，无缝地发布新功能
• 优化硬件资源，降低成本

Kubernetes 是一个声明式系统，声明式系统和命令式系统是有本质的区别。所谓声明式系统关注点是做什么，即告诉你将要达成什么样的期望，至于怎么达到是你系统的事情。而命令式系统则是必须按照相应的规定或者步骤达到某个目标或者完成某个任务，其关注点是在怎么做。

命令式强调的是 How，它需要你通过 step-by-step 的方式告诉计算机如何完成一个任务，在这种场景下，计算机是不具备“智能”，只能很机械的完成任务，至于完成的结果如何，需要看编程者的水平了。

而声明式强调的是 What，你只需要告诉计算机你想要什么，然后由计算机自己去执行，这时候的计算机是具备一定的“智能”。当然，声明式不一定会满足你所有的需要。

在日常工作中，命令式编程比较普遍，这种编程实现比较方便，只需要按照一定的步骤开发即可，但是在一些特定的场合，声明式要比命令式方便，其实大多数声明式语言都是针对特定任务的领域专用语言，即 DSL。

最常见的声明式语言就是 SQL，只需要告诉计算机你想要的结果集，数据库就会帮你设计获取这个结果集的执行路径，并返回结果。

Kubernetes 就是一个声明式系统，在使用 Kubernetes 的时候，用户不需要去定义 A->B->C 这种 Workflow，而是直接去描述一个期望状态，然后 Kubernetes 就会帮助用户达到这个状态，至于如何达到这个状态，用户不需要关心。这种设计使得 Kubernetes 更加易用和健壮，也更具弹性和扩展性。

Kubernetes 的架构

Kubernetes 整体是 Master-Slave 架构，如下：

其中：

• etcd 保存了整个集群的状态，就是一个数据库，只有 API Server 能与其通信；
• apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制；
• controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；
• kubelet 负责维护容器的生命周期，同时也负责 Volume（CSI）和网络（CNI）的管理；
• container runtime 负责镜像管理以及 Pod 和容器的真正运行（CRI）；
• kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡；
• registry 是镜像仓库，负责存储容器镜像
• kubectl 和 dashboard 都是客户端工具

上面的架构是逻辑架构，在实际的生产运用中，为了达到高可用，会对架构做对应的调整，调整对象就是主节点，如下：

主要做了以下改变：

（1）将 Master 节点从单节点变成了多节点，在 kube-apiserver 前增加了 load balancer 用来负载，其他组件通信都是通过 LB 进行

（2）将 etcd 和 master 节点独立开，避免由于某个 master 节点故障导致 ectd 受影响

Kubernetes 架构的设计原则是：

• 只有 APIServer 可以直接访问 Etcd 存储，其他服务必须通过 Kubernetes API 来访问集群的状态
• 单节点故障原则上不应该影响集群的状态
• 在没有新请求的情况下，所有组件应该在故障恢复后继续执行上次最后收到的请求
• 所有组件应该在内存中保持所需要的状态，APIServer 将状态写入 Etcd 存储，而其他组件则通过 APIServer 更新并监听所有的变化，最终由 Controller Manager 去协调
• 优先使用事件监听而不是轮询

Kubernetes 的重要组件

上面介绍了 Kubernetes 的整体架构以及简单介绍了各个组件的作用，但是它们之间的关系具体如何并没有做过多的介绍，我们现在来看看各个组件以及它们之间是怎么协作的。

（1）kubectl 客户端首先将 CLI 命令转化为 RESTful 的 API 调用，然后发送到 kube-apiserver。

（2）kube-apiserver 在认证、授权、准入验证过后，将任务元信息并存储到 etcd，然后 kube-scheduler 会对任务进行调度，并将调度结果返回给 kube-apiserver。

（3）一旦 kube-scheduler 返回一个适合调度的目标节点后，kube-apiserver 就把任务的节点信息存入 etcd，并创建任务。

（4）此时目标节点中的 kubelet 正监听 apiserver，当监听到有新任务需要调度到本节点后，kubelet 通过本地 runtime 创建任务容器，执行作业。

（5）接着 kubelet 将任务状态等信息返回给 apiserver 存储到 etcd。

（6）kube-proxy 也会监听 apiserver，如果有网络策略相关的操作，就会在本机上创建对应的 iptables 或者 ipvs 规则。

（7）这样我们的任务已经在运行了，此时 control-manager 发挥作用保证任务一直是我们期望的状态。

其主要组件如下：

• Etcd
• API Server
• Controller Manager
• Scheduler
• Kubelet
• Kube-proxy

Etcd

Etcd 是兼具一致性和高可用性的键值存储，可用于服务发现、共享配置以及一致性保障，在 Kubernetes 中，Etcd 是作为唯一的存储，保存 Kubernetes 的所有 API 对象。

在生产级 Kubernetes 中 etcd 通常会以集群的方式存在，安全原因，它只能从 API 服务器访问。

API Server

API Server 是 Kubernetes 最重要的核心组件之一，主要提供以下功能：

• 提供集群管理的 REST API 接口，包括：
  • 认证
  • 授权
  • 准入
• 为其他模块提供数据交互和通信的枢纽
• API Server 提供 Etcd 的数据缓存，减少集群对 Etcd 的访问

Controller Manager

Kubernetes 在后台运行许多不同的控制器进程，当服务配置发生更改时（例如，替换运行 pod 的镜像，或更改配置 yaml 文件中的参数），控制器会发现更改并开始朝着新的期望状态工作。

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

控制器包括:

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

下面就是 Deployment Controller 和 ReplicaSet Controller 两个控制器的工作流程。

Scheduler

kube-scheduler 负责监视新创建、未指定运行 Node 的 Pods，决策出一个让 pod 运行的节点。

例如，如果应用程序需要 1GB 内存和 2 个 CPU 内核，那么该应用程序的 pod 将被安排在至少具有这些资源的节点上。每次需要调度 pod 时，调度程序都会运行。调度程序必须知道可用的总资源以及分配给每个节点上现有工作负载的资源。

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

调度总共分为三个阶段：

• Predict：预选阶段，过滤不能满足业务需求的节点
• Priority：优选阶段，选择最优的节点
• Bind：绑定阶段，将最优节点和 Pod 进行绑定，完成调度

Kubelet

Kubelet 是每个节点上的核心组件之一，负责管理节点的资源对象。

• 从不同源获取 Pod 清单，并按需启停 Pod
  • Pod 清单可以来自本地文件目录、给定的 Http Server、API Server 等
  • Kubelet 将 Container Runtime、Network、Stroage 抽象成 CRI、CNI、CSI
• 负责汇报节点的健康状态以及资源信息
• 负责 Pod 的健康检查和状态汇报

Kube-proxy

kube-proxy (opens new window) 是集群中每个节点上运行的网络代理， 实现 Kubernetes 服务（Service） 概念的一部分。用于处理单个主机子网划分并向外部世界公开服务。它跨集群中的各种隔离网络将请求转发到正确的 pod/容器。

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

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

其他组件

上面介绍的这些组件是集群的架子，光有架子还不够，还需要第三方的组件让其更强大：

• kube-dns：负责为整个集群提供 DNS 服务，常用的是 CoreDNS
• Ingress Controller：为集群提供外网访问入口
• Metrics-Server：为集群提供监控资源
• DashBoard：提供 GUI，方便运维
• Prometheus：收集并监控集群资源
• Grafana：图形化展示监控数据
• ELK：收集、存储、查询集群日志