KUBERNETES是如何工作的？

文章译自 HOW DOES KUBERNETES WORK?^[1]，作者 Janakiram MSV。

以下内容节选自 The New Stack 新书《The State of the Kubernetes Ecosystem^[2]》。

需要该书的朋友可以访问原网站下载，或加译者微信 youmoolee 索取。

当代的应用程序，通常会被打包进一组容器，并以微服务方式来部署。它需要一个足够强大的基础设施来处理集群的需求和动态协调的压力。这样的基础架构应该为跨主机的容器调度、监控、升级和迁移提供基本原语(primitives)。它必须能将底层算力(compute)、存储(storage)和网络(network)原语处理为资源池。每个容器化了的工作负载(workload)都应能利用暴露给它的资源，包括CPU核心(CPU cores)、存储单元(storage units)和网络(networks)。

Kubernetes 是一个开源的分布式系统^[3]，它抽象了底层的物理基础设施，使其更容易大规模地运行容器化应用。一个由 Kubernetes 管理整个生命周期的应用，是由一组容器聚集在一起，并协调成一个单元。一个高效的集群管理器层(cluster manager layer)可以让 Kubernetes 将应用与支撑它的基础设施有效地解耦，如下面图一所示。一旦 Kubernetes 基础设施完全配置完毕，DevOps团队就可以专注于管理部署的工作负载，而不是处理底层的资源池--CPU和内存--它们将由 Kubernetes 处理。

Kubernetes Works Like an Operating System

Kubernetes 工作起来像一个操作系统。

Kubernetes 是一个架构良好的分布式系统的例子。它将集群中的所有机器视为一个单一的资源池。它承担了分布式操作系统的角色，有效地管理调度、分配资源、监控基础设施的健康状况，甚至维护基础设施和工作负载的期望状态(desired state)。Kubernetes 是一个能够在云服务和私有数据中心环境上跨多个集群和基础设施运行现代应用程序的操作系统。

和其他成熟的分布式系统一样，Kubernetes 分为两层，包括头节点(head nodes)和工作节点(worker nodes)。头节点通常运行控制平面(control plane)，负责调度和管理工作负载的生命周期。工作节点作为运行应用(applications)的工作主力。头节点和工作节点的集合构成一个集群。

管理集群的DevOps团队通过命令行(CLI)或第三方工具与控制平面(control plane)的API进行对话。用户访问运行在工作节点上的应用程序。应用程序由一个或多个容器镜像组成，这些镜像存储在一个可访问的镜像注册中心(image registry)中。

The Kubernetes Control Plane (控制平面)

控制平面运行着提供核心功能的 Kubernetes 组件：暴露 Kubernetes API、调度部署工作负载、管理集群以及指导整个系统的通信。如第二张图所描述的那样，头节点监控着每个节点中运行的容器以及所有注册节点的健康状况。容器镜像作为可部署的部件(deployable artifacts)，必须对 Kubernetes 集群可用，不管是通过私有还是公共的镜像注册中心。负责调度和运行应用程序的节点通过容器运行时(container runtime)从注册中心访问镜像。

Kubernetes头节点运行以下组件，它们一起构成了控制平面：

etcd

etcd 由 CoreOS 开发，后者后来被红帽收购，它是一个持久化、轻量、分布式的键值数据存储仓库，被用来维护集群配置数据。它代表了集群在任何给定时间点的整体状态，充当了唯一的真相来源(single source of truth)。其他各种组件和服务监听 etcd 存储的变化，以维持应用程序的期望状态。该状态由声明性策略(declarative policy)定义；实际上，它是一个为应用声明最佳环境的文档，编排器(orchestrator)根据它来努力实现环境要求。该策略定义了编排器如何处理应用程序的各种属性，如实例数量、存储要求和资源分配。

etcd 数据库只能通过 API server 访问。集群中任何需要读写 etcd 的组件都是通过 API server 进行的。

API Server

API server 通过基于HTTP协议的JSON接口来暴露 Kubernetes API，为编排器的内部和外部端点(endpoints)提供REST接口。CLI、Web界面(UI)或其他工具可以向 API server 发送请求。API server 处理并验证该请求，然后更新 etcd 中 API对象的状态。这使得客户端能够跨工作节点配置工作负载和容器。

Scheduler (调度器)

调度器根据其对资源可用性的评估选择每个工作负载应该运行的节点，然后跟踪资源利用率，以确保 pod 的资源消耗不超过其配额。它维护和跟踪资源需求、资源可用性以及各种其他用户提供的约束和策略指令；例如，服务质量(quality of service QoS)、亲和/反亲和要求以及数据本地性(data locality)。运维团队可以声明式地定义资源模型。调度器会将这些声明解释为为每个工作负载提供和分配正确资源集的指令。

Controller-Manager (控制器-管理器)

Kubernetes 架构中赋予其多功能性的部分是控制器-管理器，它是头节点的一部分。控制器-管理器的职责是通过定义好的控制器，确保集群一直保持期望的应用状态。控制器是一个控制循环(control loop)，它通过 API server 监视集群的共享状态，并在需要时做出改变，尝试将当前状态向期望状态移动。

控制器通过不断监控集群的健康状况和部署在该集群上的工作负载，来维持节点和 pods 的稳定状态。例如，当一个节点变得不健康时，运行在该节点上的 pod 可能会变得不可访问。在这种情况下，控制器的工作就是在另外的节点上调度相同数量的新 pod。这项活动确保集群在任何给定的时间点都能保持预期的状态。

Kubernetes 有一套内置的控制器，运行在 controller-manager 内部。这些控制器提供了与某一类工作负载相一致的原语，如stateless、stateful、scheduled cron jobs 和 run-to-completion jobs。在 Kubernetes 中打包和部署应用程序时，开发人员和操作人员可以利用这些原语。

本系列接下来的文章将更详细地探讨 Kubernetes 架构，包括工作节点和工作负载的关键组件；服务和服务发现；以及网络和存储。

歇一歇，下一篇文章将很快译出。欢迎转发点赞。