K8s 是什么？ 基本元件、核心功能、4 大优点一次看！

K8s 解决了什么问题？

介绍 K8s 前，我们应先了解它被用来解决什么问题。

K8s 旨在帮助开发者构建大型服务时，有效管理成百上千台主机上容器间的通讯。

K8s 尚未问世前，想通过 Docker 快速启动由容器组成的微服务，可以在单一服务器上使用 Docker Compose 。 开发者只需写出一份yaml文件，将参数设置好后直接执行设置文件，就能启动或终止一组相依的服务。

这虽然有效降低了测试和部署的难度，但 Docker Compose 的运行范围受限于单一主机。 在面对需要跨越多台主机协同工作的大规模服务时，就显得力不从心。 K8s 的容器自动化部署、扩展功能也就此展露头角，成为大规模管理容器通讯的最佳解决方案。

K8s 是什么？

K8s 是一种容器资源调度平台，能够将部署流程自动化、扩展并管理不同容器间的工作负载。 它的构想理念是「Automated container deployment， scaling， and management」，意即通过自动化功能提升应用程序的可靠性和减轻维运负担，让开发人员专注于软件开发任务。

K8s 的微服务管理群集，能够达成 Docker Compose 的所有功能，例如：启动容器，管理网络以及容器间的通讯。 除此之外，它还能将多个 Container 分派到多台主机上，并监控每个 Container 的运行状态。

如果 K8s 检测到某个 Container 或 Pod 故障，它会启动 Replica Set 来确保服务持续运行。 除了能够监控节点状态，K8s 的自动扩展功能（Auto Scaling）可以帮助开发团队自动调整 K8s 的节点数量来配合开发和运营时所需的资源用量。

在部署方面，K8s 的容器自动部署 （Automated deployment） 功能让用户能通过一个描述状态的文件（通常是 yaml 格式）指定服务所需的容器和设置，让 K8s 根据这份文件建立所需的资源或配置。

K8s 的架构和工作流程

下图为一个 K8s 平台的 Cluster（集群），K8s Cluster [1] 中的成员统称为 Node，这些 Node 会依照其工作角色，被区分成 Worker 或 Master。

我们能将 Worker Node 想象成人体的躯干，并将 Master Node 想象成人体的大脑，负责发号命令。

1. 图中右边为 Worker Node，通常会被配置较多的运算资源，因为它们要负责成百上千的应用程序。
2. 图中左边的为 Master Node。 Master 上面执行的管理程序叫做 Control Plane，它们负责整个 Cluster 的日程安排和状态维护。
3. Worker Node 里运行着数个 Pod[2]，Pod 是 K8s 里运行和部署的基本单位，而一个 Pod 内允许多个 Container 并存。 Kubernetes 通过 Pod 来包装管理 Container，增加调度部署的弹性。

K8s 两大基本元件

元件一、Master Node（Control Plane）

Control plane 又叫控制平台，是 K8s 的运作的指挥中心，负责下达指挥命令。 例如： 容器日程日程（Scheduling Containers）、服务管理（Managing Services）和响应API请求（Serving API Requests）。

Control Plane 会通过专用 API 与各个 Node 进行通讯，也会监控所有 Node 的工作负载，并下发指令来应对突发状况。 例如：如果 Control Plane 检测到应用的使用量暴增，它会调度相应的运算资源来应对，并在使用量下降时，自动缩减运算资源。

Control plane 由 4 个重要组件组成：

• Kube-API Server： 是所有请求的唯一入口，也是 Cluster 中各个 Node 的沟通桥梁，

负责身份验证（Authentication）、授权（Authorization）、访问控制（Access Control）和 API 注册（Registration）。

• etcd：是用来存放 K8s Cluster 备份信息的数据库，纪录整个 K8s 的状态。 当 Controller Plane 发生故障， etcd 可以帮我们还原 K8s 的状态。
• Kube-scheduler：是 K8s 的工作调度器，它负责监控所有用户开启 Pod 的指令，并根据 Worker Node 的资源规定和硬件限制找出最合适的 Worker Node。
• kube-controller-manager：是 K8s Cluster 的自动化控制中心，负责管理并运行 K8s Controller 的组件。

组件二、Worker Node

Worker Node 是 K8s 中的工作主机，负责管理和运行 Pod。 它可以是物理机，也可以是虚拟机（例如：AWS 上的 EC2）。 每个Node都包含运行Pod所需的服务，并由Master Node管理。

Worker Node 上的服务包括：

• Pod

Pod 是 K8s 中最小的资源部署单位，它的设计目的是简化容器化应用程序的部署和管理。

一个Pod封装了一个或多个Container，这些容器共同执行相同的工作任务，也共享相同的网络资源（例如：IP 地址、内存和主机名）。 这种架构允许容器间能高效地共享和交换数据，同时也保证了容器间通信的简便性和安全性。

虽然用户能将应用程序上的所有容器封装至同一个Pod，但最佳做法是让每个Pod对应一个Container，接着再把这些Pod装入Namespace，这样就能组成一个完整的应用程序。

• Kubelet：

Kubelet 是 Worker Node 与 Kube-API Server 进行沟通的组件，主要负责接收 API server 发送的新或修改后的 Pod 规格，确保 Pod 及 Pod 内的容器在 API Server 的期望下运行。

Kubelet 也会定时从 Worker Node 上收集 Pod/Container 上的状态（例如：运行什么 Container、副本运行数量、资源配置），并将这些信息汇报给 Control Plane。 如果 Controller 没有收到节点的运行信息，该 Node 就会被断定为 Unhealthy。

• Kube-proxy：

Kube-Proxy 是每个 Node 上运行的网络代理服务，它负责管理 Pod 间的网络通信规则、 Cluster 内部的通讯与响应 Cluster 外部的 request 。 如果操作系统中存在封包过滤器（packet filtering layer ），Kube-proxy 会将处理 request 的请求转由 Worker Node 的操作系统处理。

• Container Runtime：

Container Runtime 属于较为底层的组件，负责实际运行容器，并听从 Kubelet 的命令管理容器。 K8s 支持多种不同的 Container Runtime，例如 containerd 、 runC 、 CRI-O 等。

四个 K8s 核心功能

功能一、动态扩展（Dynamic Scaling）

在实际应用中，DevOps 人员经常面临资源不足的问题，这得归因于每个应用在每个时间点的流量都不是固定的，但每个应用分配到的资源却是固定的。 K8s 通过 Dynamic Scaling 可以动态地增加或减少运算资源，其中常见的方式有 Horizontal Scaling 和 Vertical Scaling。

水平扩展（Horizontal Scaling）

水平扩展（Horizontal Scaling）[3]的核心概念是根据「工作负载的变化来更新 Pod 的数量」。 这意味着当负载增加时，我们可以自动部署更多的Pod，以确保服务的性能。 而负载减少时，也能减少Pod的数量，以确保资源不被浪费。

具体来说， K8s 会通过 Horizontal Pod Autoscaler（简称 HPA，一种用于自动调整应用程序中 Pod 副本数的控制器） 自动更新工作负载资源（例如：Deployment 或 StatefulSet），并由这两种资源负责更新 Pod 数量，使 Pod 在资源节约和服务性能之间达到平衡。

水平扩展运作流程

如上图所示，使用HPA架构的K8s首先会透过Metric Server检测各项指标，如果监测到CPU/Mermory的利用率高于目标，HPA会增加Pod的数量，直到平均使用率降低到目标范围内。

垂直扩展（Vertical Scaling） 

和水平扩展不同，垂直扩展（Vertical Scaling）的核心概念是根据工作负载的变化来「更新 Pod 的资源请求而非 Pod 数量」。 也就是说当负载增加时，我们可以给Pod更多资源，以确保服务不会因为超出资源限制而降低性能。 负载减少时，也能减少 Pod 的资源请求，以确保资源不被浪费。

Vertical Pod Autoscaler（简称 VPA ，是一种垂直 Pod 资源扩缩器）会根据容器的资源使用率自动缩放 Pod 能访问的 CPU 和 Memory 资源，让 Pod 中的应用程序能够取得足够的运算资源，维持应用的服务质量。

垂直扩展运作流程

如上图所示，首先使用VPA架构的K8s会每隔10秒检查各资源的使用指标，如果请求资源增加，VPA Operator会根据资源使用量更动Pod的资源配置，并将Pod重启，重启后的Pod就会是新的资源配置。

简而言之，水平扩展是关于「增减 Pod 的数量」，而垂直扩展则是关于「调整单个 Pod 的资源」。 这两种机制使我们能够在 K8s 中实现有效的负载管理，确保应用程序在不同工作负载下都能保持高性能。

功能二、自我修复（Self Healing）

K8s 能够实时地修复 Cluster 中有问题的 Pod。 当一个节点或Pod出现故障时， K8s 会自动将它们从 Cluster 中删除并重新创建，以确保应用程序的可用性。

除此之外，K8s还会确认系统状态是否与开发者的需求配置相符，举例来说，如果开发者向K8s提出建立3个副本的需求，K8s除了建立副本之外，也会持续确认这3个副本的运行状态，如果发现有第4个副本被建立了，K8s会将第4个副本删除，以维持3个副本的设定。 另外，如果其中一个副本停止运行，为了维持运行3个副本，K8s 就会重新建立一个副本。

功能三、滚动更新（Rolling Updates）

开发团队能通过 K8s Cluster 中的 ReplicaSet 执行 Rolling Update [4] ，从而避免应用程序更新时造成停机。 ReplicaSet 主要负责管理Pod 的数量，确保某个Pod 在停止运行时，能将其快速重建以确保服务的可用性。

Rolling Update 会通过同时建立新版 Pod 的 ReplicaSet 以及逐步关闭旧版 Pod 来进行更新。 这意味着开发者无须担心在更新过程中将所有 Pod 同时关闭，进而导致服务中断。

功能四、回复旧版（Rolling Back）

如果将版本更新后发现服务有问题怎么办？ Rolling Back可以解决这个问题。

前段提到的Rolling Update会通过建立新版Pod的RoeplicaSet来更新，而Rolling Back则是透过旧版的RoeplicaSet来恢复旧版Pod。

通常如果没有设置参数，一个 Deployment 中保留最多十版的 ReplicaSet 。 开发者如果在服务运行时发现错误，就可通过 Rolling Back 功能找到想要恢复的旧版本 ReplicaSet 进行无痛 Rollback。

K8s 的四个优势

一、轻量级

K8s 的轻量化特性让应用程序能被轻易地部署至不同环境，例如：地端数据中心、公有云或其他云端混合环境。 K8s 容器化的本质让封装在内的应用程序与其相依的资源能够紧密结合，从而解决不同平台的兼容问题，并降低在不同基础架构上部署的难度。

同时，借助 HashiCorp Vault，您可以轻松地在这些环境中安全地管理应用程序的 secrets 和凭证，无需担心安全风险。 Vault 可以与 K8s 无缝整合，提供集中式的 secrets 管理，简化 secrets 的访问控制，并确保应用程序在不同环境中的安全性。

二、宣告式组态

K8s 让用户通过声明式配置文档（Kubernetes Manifest）来宣告期望的系统状态，管理应用程序和资源。 由于宣告式配置直接描述期望的服务状态（declarative），不需要透过逐项命令式宣告（imperative）来堆栈，因此不易出错。

K8s 宣告式配置以 YAML 或 JSON 文件格式撰写，描述要执行运作的资源配置，再发送到 K8s API Server。 API Server 会确保目标的运行状态与用户的期望相符。

例如，在部署 EDB PostgreSQL 数据库时，您可以使用 K8s 宣告式配置来定义 PostgreSQL 群集的期望状态，包括副本数量、储存配置、资源限制等。 K8s 会自动确保 PostgreSQL 群集按照您的配置运行，并在发生故障时自动进行修复，确保数据库的高可用性和稳定性。

K8s 声明式配置支持版本控制、自动部署、回滚、扩展和自我修复，可以提高用户管理大规模分布式系统的能力。 同时，它提供了高层次的抽象化，使开发人员和运营人员能够专注于应用程序的行为和需求。

三、促进开发团队和维运团队的协作

K8s 通过提供统一的应用程序部署和管理平台，促进开发和维运团队间的协作。 开发人员能通过 Kubernetes Manifests File 将应用的配置定义为代码，从而实现版本控管和持续部署。 维运人员则能通过 K8s 自动化部属流程，监控应用程序运行状况并导入 CI/CD 工作流程。

此外，开发和维运团队可以共同使用 ELK Stack 来监控应用程序的效能和健康状况。 ELK Stack 可以收集和分析 K8s 丛集中的各种日志和指标数据，例如应用日志、系统日志、Pod 事件等，并提供实时的可视化 dashboards 和报警功能。 开发人员可以通过 Kibana 的可视化界面，快速识别和诊断应用程序问题; 维运人员可以利用 Elasticsearch 的强大搜寻和分析功能，深入分析日志数据，并主动地解决潜在问题，进一步提升团队协作效率。

四、储存调度

K8s 的存储调度（Storage Orchestration）功能对运行 Stateful 应用程序至关重要，因为它能将需要储存资源的容器连接到能够提供资源的基础设施。

例如，EDB PostgreSQL 数据库等 Stateful 应用程序需要持久化的保存来保存数据。 K8s 的存储调度功能可以将 PostgreSQL 容器连接到合适的存储卷，并确保数据的持久性和一致性，即使 Pod 重新启动或迁移到不同的节点，数据也不会丢失。

K8s 执行储存协调的方式会因多种因素而异，例如储存基础架构（Storage Infrastructure）种类以及容器使用 Storage 的方式。 以下图为例，需要将日志文件写入本地 Volume 时可以使用 Local 储存方式，使用 Azure 时可以使用 AzureFile 存储方式等。 K8s 的储存协调功能让用户能按照不同需求进行储存。

开源容器编排工具的对比：K8s v.s Docker Swarm

K8s 和 Docker Swarm 是市面上两种主流容器编排工具，这段我们将比较这两种工具的功能、优势与适用场景。

高可用性（High availability）

两种工具都具备高可用性

• K8s：自动检测不健康的 Pod，并将工作负载调度到健康的 Pod 上，从而确保服务的可用性。
• Docker Swarm：Swarm Managers 的高可用性控制机制（Availability Control）能确保节点出现故障时，丛集仍能够运行。 此外，Swarm Manager 会自动在丛集中的节点上分配和调度服务实例，从而达到负载平衡和高可用的目的。

负载平衡（Load balancing）

Docker Swarm 相较 K8s 具备自动化负载平衡功能。 然而，用户可以通过第三方工具将负载平衡功能集成至 K8s Cluster 上。

• Kubernetes： 通过单一的 DNS 名称启用服务的 Discovery。 K8s 能通过 IP 或 HTTP Route 访问容器应用程序。
• Docker Swarm：具备内建的负载平衡器

扩展性（Scalability）

K8s 以 Pod 为单位扩展，适合规模较大的扩展。 与之相比，Docker Swarm以容器为单位扩展，扩展速度较快。

• K8s：内建 HPA 水平扩展
• Docker Swarm：需要额外安装水平扩展

我该选择 K8s 还是 Docker Swarm ？

K8s 作为热门的容器调度平台，拥有庞大的社群资源。 除此之外，各大云商和 Docker EE 也都支持 K8s 。 虽然 K8s 的功能相较 Docker EE 更强大、更灵活且更定制化，但学习曲线也更陡峭。 因此 K8s 需要由一支经验丰富的团队维运; 为了节省成本，一些公司也会选择将 K8s 交由托管商维运。

而 Docker Swarm 拥有 Docker 原生与配置较为简单的优势，能够无缝与 Docker 引擎整合，并且在环境中快速启动和部署。 相较于 K8s，Docker Swarm 提供用户更直观的入门选择，并适合处理较小的工作负载。

选择 Docker Swarm 还是 K8s 这个问题取决于自身的需求、团队的技术能力以及想要实现的目标。 如果你的应用规模较小，并且正在寻找一个部署步骤简单、容易上手的解决方案，Docker Swarm 会是不错的选择。 反之，如果你有足够的预算并且需要一个功能丰富、能大规模扩展并且有庞大社群和云商支持的解决方案，K8s 将更合适。