认识 Kubernetes：前世今生

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

Souloss

公告

欢迎来到我的博客！这是一条示例公告

Learn More

标签

10003 字

28 分钟

认识 Kubernetes：前世今生

2023-05-10

云原生

Kubernetes

/

云原生

/

容器

/

Docker

一、云计算商业模式的发展#

要回答「Kubernetes 是什么」这个问题，需要从云计算的起源说起。早年的企业服务器都依靠大型计算机提供支撑，但大多数初创企业无力承担购买和维护大型计算机的高昂成本。好在那个年代微机发展迅速，每个对计算机感兴趣的人都能购买自己的专用设备。某家初创企业的年轻人决定用软件来克服硬件成本问题——他们购买了大量廉价的微机，通过网络将其连接起来，使用软件实现服务的负载均衡和容灾，这便是云计算最早期的模式。

云计算的发展实际上是「云计算相关技术」与「云计算服务产品化、商业化」两条主线的演进：前者为云计算提供虚拟化、分布式等技术支撑，后者为云计算提供产品形态和计费模式。两者相辅相成，共同成就了云计算的今天。下面我将梳理这两条路线的发展历程。

云计算服务产品化、商业化发展历程：

2006 年：亚马逊推出云主机、S3 对象存储、弹性 IP、RDS 等云产品，为云计算行业树立了标杆，亚马逊也因此成为云计算市场的领导者和统治者。
2009 年：Heroku 公有云 PaaS 提出云原生 12 要素以及「以应用为中心」的理念，开发者只需推送代码便可完成新版本发布，基于云的开发和发布逐渐成熟。这引导了大量开发者将应用开发、运行与维护迁移到云上。
2010~2011 年：由 NASA（美国国家航空航天局）和 Rackspace 合作研发并发起 OpenStack 项目，它由一系列开源项目组成。同时，VMware 也推出了业界第一个开源 PaaS 云平台 Cloud Foundry，支持多种框架、语言、运行时环境和应用服务。这标志着云计算正式走向开放，国内一些企业也开始基于开源技术搭建自己的公有/私有云平台。开源是云计算百花齐放的起点，也是建设开发者生态的开端。
2013~2020 年：Docker 和 K8s 的开源使「容器云」正式走入大众视野。相比传统云计算，它更加轻量和易用，并且使所有「容器云」互相兼容，由此产生了「多云」这一概念。

云计算相关技术发展历程：

1974 年：Popek 和 Goldberg 发表论文《Formal Requirements for Virtualizable Third Generation Architectures》，提出了虚拟化的充分条件，指出满足条件的控制程序可被称为虚拟机监视器（Virtual Machine Monitor，VMM）：（1）一致性：运行于虚拟机上的程序，其行为应与直接运行于物理机上的行为基本一致，仅允许细微差异（如系统时间方面）；（2）可控性：VMM 对系统资源拥有完全的控制能力和管理权限；（3）高效性：绝大部分虚拟机指令应由硬件直接执行，无需 VMM 参与。
1978 年：IBM 获得独立磁盘冗余阵列（Redundant Arrays of Independent Disks，RAID）概念的专利。该专利将物理设备组合为资源池，然后从中切分出逻辑单元号（Logical Unit Number，LUN）供主机使用。虽然该技术直到 1988 年 IBM 才与加利福尼亚州立大学伯克利分校联合开发出第一个实用版本，但该专利首次将虚拟化技术引入存储领域。
1991 年：伯纳斯-李发明了万维网，开启了网上冲浪的浪潮。
2003 年：谷歌发表三篇论文，史称「三驾马车」——GFS、MapReduce、BigTable，开创性地提出了通过大量廉价服务器进行分布式存储和计算的方法。随后 Yahoo 参照这三篇论文实现了 Hadoop 1.0，成为大数据领域的不老神话。
2006 年 10 月：以色列创业公司 Qumranet 在完成虚拟化 Hypervisor 基本功能、动态迁移以及主要性能优化后，正式对外宣布 KVM 的诞生。同年 10 月，KVM 模块的源代码被正式接纳进入 Linux Kernel，成为内核源代码的一部分，Linux 下的虚拟机技术由此诞生。
2008 年：LXC（Linux Container）容器发布，这是一种内核虚拟化技术，可提供轻量级的虚拟化，用于隔离进程和资源。LXC 是 Docker 最初使用的具体内核功能实现，为 Linux 在云计算时代增添了一件利器。事实上，容器使用的技术最早由 Google 工程师贡献给 Linux 内核。
2013 年：Docker 开源并引起社区关注。它用镜像保证软件发布的不可变性，利用 Linux UTS/IPC/PID/Network/Mount/User 命名空间、cgroup 以及 rootfs 保证隔离性和资源限制，使用联合文件系统和写时复制最大化复用存储空间。这形成了最初的容器标准，获得了大量开发者的高度认可，一夜之间火遍大江南北。
2014~2015 年：谷歌以数十年大规模集群管理系统 Borg 为基础、以 Docker 容器为负载单元，发布了 Kubernetes。它迅速击败同领域的其他对手，成为容器管理领域的事实标准。次年，谷歌与 Linux 基金会共同成立 CNCF（云原生计算基金会），开始打造开放生态，Kubernetes 和 Prometheus 等成为第一批毕业项目。
2016~2020 年：CNCF 飞速发展。在 CNCF Native Interactive Landscape 中，从容器化到 CI/CD，从应用编排、监控分析到服务代理与发现等相关生态都有了长足进步，K8s 及其相关组件体系已趋于成熟。

云计算本质上是一种提供计算和存储资源的租赁式服务——服务提供商通过虚拟化和分布式等关键技术隐藏资源管理细节，客户通过购买服务免除自行管理资源的成本。目前根据资源托管的层次，可将服务等级分为基础设施服务（IaaS）、平台服务（PaaS）和软件服务（SaaS）等。这种租赁式服务大大提升了计算机资源的灵活性和可维护性。早在 1961 年，约翰·麦卡锡在麻省理工学院一百周年纪念庆典上就首次提出了 Utility Computing（公共计算服务）的概念，并指出这将是一种全新的重要工业基础。直到「容器云/多云」的出现，各大云服务提供商都支持以同样的方式销售计算资源，这一趋势才逐渐显现。

timeline title 云计算与容器技术发展历程 section 虚拟化奠基 1974 : Popek & Goldberg 虚拟化理论 1978 : IBM RAID 专利 2003 : Google 三驾马车论文 2006 : KVM 进入 Linux 内核 section 容器化兴起 2008 : LXC 发布 2013 : Docker 开源 section 编排与生态 2014 : Kubernetes 开源 2015 : CNCF 成立 2016-2020 : 生态爆发 section 云原生成熟 2021+ : 多云 / 边缘计算 / eBPF

二、从 Borg 到 Kubernetes：谷歌集群管理的传承#

Kubernetes 并非凭空诞生，它深深植根于谷歌十多年的大规模集群管理经验。要理解 Kubernetes 的设计哲学，需要回到谷歌内部系统演进的完整脉络。

2.1 Borg：大规模集群管理的起点#

Borg 是谷歌内部最早的大规模集群管理系统，早在 2003~2004 年间就开始投入使用，管理着谷歌全球数据中心的数十万台机器。Borg 的核心设计理念包括：

统一的资源池：将所有工作负载（在线服务、离线批处理）混合部署在同一集群中，通过优先级和抢占机制实现资源复用。在线服务白天资源需求高，批处理任务夜晚资源需求高，混合部署使整体利用率大幅提升。Borg 论文数据显示，谷歌集群的平均 CPU 利用率达到 60%~70%，远超同期传统数据中心的 10%~20%。
声明式期望状态：用户提交 Job 时声明期望的副本数和资源需求，Borg 负责持续驱动实际状态向期望状态收敛。如果一个 Task 失败，Borg 会自动在集群中寻找合适的机器重新启动它。
Borglet 与 Borgmaster：每个节点上运行 Borglet 代理，负责本地的 Task 启停和状态上报；Borgmaster 作为中央控制器，由主进程和 Scheduler 组成。主进程处理所有 RPC 请求并持久化状态到 Paxos 存储，Scheduler 负责将 Task 分配到满足约束的机器上。

Borg 面向的用户主要是谷歌内部的工程师，API 设计偏向底层，直接暴露了 Task、Job、Allocation 等概念。这种设计虽然灵活，但也带来了使用上的复杂性。

2.2 Omega：下一代架构的探索#

Omega 是 Borg 的后继系统，大约在 2013 年前后投入使用。Omega 的核心改进在于去中心化的调度架构：

Borg 采用集中式调度器，所有调度决策由 Borgmaster 的 Scheduler 统一做出，调度效率受限于单点吞吐。
Omega 引入了基于事务的共享状态存储（Transaction-based Shared State），多个调度器可以并发地读取集群状态并提交调度决策，通过乐观并发控制（OCC）解决冲突。这使 Omega 能够支持异构的调度策略——不同类型的工作负载可以使用最适合自己的调度算法。

Omega 的这一设计思想直接影响了 Kubernetes 中 Scheduler 的可扩展架构（Scheduler Framework / Multiple Schedulers），以及基于 etcd 的事务性资源操作模型。

2.3 Kubernetes：开源的 Borg 传承#

2014 年 6 月，谷歌在 DockerCon 上正式开源 Kubernetes v0.1。Kubernetes 从 Borg/Omega 中继承了核心设计理念，同时做了重要的简化和改进：

设计理念	Borg	Omega	Kubernetes
调度架构	集中式 Scheduler	共享状态 + 多调度器	单调度器 + Framework 扩展
配置接口	BCL（Borg Configuration Language）	类 BCL	YAML/JSON 声明式 API
容器隔离	自研容器方案	自研容器方案	Docker / containerd / CRI-O
服务发现	Borg Name Service（BNS）	BNS	Service + DNS + CoreDNS
存储抽象	挂载到 Task 的 Volume	类似 Borg	PV/PVC + CSI 插件
期望状态	声明式	声明式	声明式（核心设计）
标签选择	不支持	不支持	Label + Selector（创新）

Kubernetes 最重要的创新之一是 Label + Selector 机制。Borg 中 Job 和 Task 是强绑定的层级关系，而 Kubernetes 通过 Label 实现了松耦合的资源关联。任何对象都可以打上任意的 Label，通过 Selector 按条件筛选，这使得 Service、Deployment、NetworkPolicy 等高层概念可以灵活地组合和查询底层 Pod。

graph TB subgraph "谷歌集群管理系统演进" B["Borg 2003~2013 集中式调度 BCL 配置"] O["Omega 2013~2016 共享状态调度 事务性操作"] K["Kubernetes 2014~至今 开源 声明式 API"] end B -->|"架构经验"| O B -->|"设计理念"| K O -->|"调度思想"| K subgraph "Kubernetes 从 Borg 继承的核心设计" D1["声明式期望状态"] D2["控制器循环 Reconcile"] D3["Label/Selector 松耦合"] D4["Pod 最小调度单元"] end K --> D1 K --> D2 K --> D3 K --> D4 style B fill:#fff3e0 style O fill:#e8f5e9 style K fill:#e1f5fe

Kubernetes 还简化了 Borg 中过于底层的设计。例如，Borg 的 Allocation 概念（预留资源槽位）在 K8s 中被合并到 Pod 的资源请求（requests/limits）中；Borg 的 Task 级别重启策略在 K8s 中被抽象为 Pod 的 restartPolicy；Borg 的优先级和抢占机制在 K8s v1.14（2019 年 3 月）才通过 PodPriority 和 Preemption 正式引入。

三、Kubernetes 版本演进与关键里程碑#

从 2014 年开源至今，Kubernetes 已经发布了 30 多个大版本。以下是关键版本的演进脉络：

3.1 早期探索期（v1.0 ~ v1.5）#

v1.0（2015 年 7 月）：第一个正式发布版本，标志着 Kubernetes 进入生产可用阶段。核心 API 对象包括 Pod、Service、ReplicationController、Node 等，Namespace 提供基础的多租户隔离。
v1.1（2015 年 11 月）：引入 Horizontal Pod Autoscaler（HPA），支持基于 CPU 利用率的自动水平扩缩容。Job 资源支持批处理任务。
v1.2（2016 年 3 月）：Deployment 进入 Beta，取代了 ReplicationController 成为管理无状态应用的首选方式。Deployment 提供了声明式的滚动更新和回滚能力。
v1.3（2016 年 7 月）：引入 PetSet（后更名为 StatefulSet），为有状态应用提供稳定的网络标识和持久化存储。同时引入 Cluster Autoscaler，支持根据资源需求自动增减节点。
v1.4（2016 年 9 月）：引入 DaemonSet，确保每个（或特定）节点运行一个 Pod 副本，适合日志采集、监控 Agent 等系统级守护进程。同时，CRI（Container Runtime Interface）开始孵化。
v1.5（2016 年 12 月）：PetSet 正式更名为 StatefulSet。引入 PodDisruptionBudget（PDB），允许在自愿中断（如节点维护）期间限制不可用 Pod 的数量，保障服务连续性。Windows Server 容器支持进入 Alpha。

3.2 功能成熟期（v1.6 ~ v1.11）#

v1.6（2017 年 3 月）：RBAC（Role-Based Access Control）进入 Beta，取代 ABAC 成为推荐的授权模式。etcd 从 v2 迁移到 v3，支持更高效的数据存储和 watch 机制。集群规模支持达到 5000 节点。
v1.7（2017 年 6 月）：CustomResourceDefinition（CRD，原名 ThirdPartyResources）进入 Beta，Kubernetes 的扩展能力从此进入新纪元。CRD 允许用户定义自己的 API 资源类型，配合自定义 Controller 构建 Operator。
v1.8（2017 年 9 月）：CRI 进入 Beta，containerd 和 CRI-O 作为替代 Docker 的运行时开始受到关注。Workload API 升级，Deployment、DaemonSet、StatefulSet 均进入 GA（General Availability）。Cloud Provider 接口开始解耦。
v1.9（2017 年 12 月）：CRD 正式 GA，成为 Kubernetes 扩展机制的基石。Admission Webhook 进入 Beta，允许对 API 请求进行动态校验和变更。这种可插拔的准入控制机制催生了 Kyverno、OPA/Gatekeeper 等策略引擎。
v1.10（2018 年 3 月）：StorageClass、Dynamic Provisioning 等存储功能 GA。Kube-proxy 的 IPVS 模式进入 Beta，在大规模 Service 场景下性能显著优于 iptables 模式。
v1.11（2018 年 6 月）：IPVS 模式 GA。引入 PodPriority 和 Preemption 的 Alpha 版本（v1.14 GA），高优先级 Pod 可以抢占低优先级 Pod 的资源。

3.3 生态扩展期（v1.12 ~ v1.18）#

v1.12（2018 年 9 月）：CSI（Container Storage Interface）进入 Beta，第三方存储厂商可以通过标准化插件接入 Kubernetes，不再需要将驱动代码编译进 Kubernetes 核心代码。Taint/Toleration 增强，支持条件性容忍。
v1.13（2018 年 12 月）：CSI GA。kube-scheduler 的调度框架（Scheduling Framework）进入 Alpha，允许通过插件扩展调度逻辑。这是自 Borg/Omega 以来调度架构最大的一次变革。
v1.14（2019 年 3 月）：PodPriority 和 Preemption GA，Kubernetes 终于具备了 Borg 时代的优先级抢占能力。Windows 节点支持进入 GA。
v1.15（2019 年 6 月）：CRD 的 Schema Validation 进入 Beta，允许在 CRD 定义中声明 OpenAPI v3 Schema，提升类型安全性。
v1.16（2019 年 9 月）：正式移除部分已废弃的 API 版本（如 apps/v1beta1、extensions/v1beta1 中的 Deployment 等），推动用户迁移到稳定的 apps/v1 API。
v1.17（2019 年 12 月）：CSI 卷快照（Volume Snapshot）进入 Beta。Topology Manager 进入 Alpha，支持 CPU、设备、内存等资源的 NUMA 感知调度。
v1.18（2020 年 3 月）：IngressClass 正式 GA，Ingress 资源可以指定由哪个 Ingress Controller 处理。Scheduling Framework 进入 Beta。

3.4 稳定迭代期（v1.19 ~ v1.25）#

v1.19（2020 年 8 月）：发布周期从 4 次调整为 3 次每年。Seccomp Profile 进入 Beta，增强容器安全隔离。
v1.20（2020 年 12 月）：Dockershim 弃用声明，Kubernetes 将在 v1.22 中移除对 Docker Engine 的直接支持（仅影响作为容器运行时，不影响 Docker 构建的镜像），社区引发了广泛讨论。CSI Service Account Token 投射进入 Beta。
v1.22（2021 年 8 月）：Dockershim 正式移除，默认容器运行时切换为 containerd。Server-side Apply 进入 GA，支持声明式字段所有权管理。此版本删除了大量已废弃的 API，是迁移影响最大的版本之一。
v1.24（2022 年 5 月）：彻底移除 Dockershim 代码。默认关闭对 kubernetes.io 后缀 Service Account 的自动创建。引入 PodReadyToStartContainers 条件，改善容器启动顺序控制。
v1.25（2022 年 8 月）：PodSecurityPolicies（PSP）正式移除，替换为 Pod Security Standards（PSS）和 Pod Security Admission（PSA），安全策略模型从白名单转变为预定义的分级策略（Privileged/Baseline/Restricted）。

3.5 现代化演进（v1.26 ~ v1.30+）#

v1.26（2022 年 12 月）：启用跨命名空间的 Storage Provisioner，动态存储供应能力增强。Kube-proxy 的 nftables 后端进入 Alpha，替代 iptables 成为下一代规则管理方案。
v1.27（2023 年 4 月）：SeccompProfile 默认使用 RuntimeDefault，增强安全基线。节点排空（Node Drain）性能优化，大规模集群升级速度提升。
v1.28（2023 年 8 月）：Sidecar Container 正式进入 Alpha（initContainers 中设置 restartPolicy: Always），解决了长期困扰社区的边车容器管理问题。之前的边车容器（如 Istio 的 Envoy 代理）需要通过 Hack 实现，启动顺序和生命周期管理都不理想。
v1.29（2023 年 12 月）：ReadWriteOncePod PVC 访问模式 GA，确保只有一个 Pod 可以读写挂载的卷。Kubernetes 发布周期正式调整为每年 3 个版本。
v1.30（2024 年 4 月）：CEL（Common Expression Language）验证规则进入 Beta，允许在 CRD 中声明复杂的验证逻辑，替代传统的 Webhook 校验。此版本也标志着 Kubernetes 集群规模稳定支持 5000 节点，最大 15 万 Pod。

graph LR subgraph "v1.0-v1.5 早期探索" A1["v1.0 核心 API"] A2["v1.2 Deployment"] A3["v1.3 StatefulSet"] A4["v1.4 DaemonSet"] end subgraph "v1.6-v1.11 功能成熟" B1["v1.7 CRD Beta"] B2["v1.9 CRD GA"] B3["v1.10 IPVS"] B4["v1.11 PodPriority"] end subgraph "v1.12-v1.18 生态扩展" C1["v1.13 CSI GA"] C2["v1.14 Preemption GA"] C3["v1.16 API 清理"] C4["v1.18 Scheduling FW"] end subgraph "v1.19-v1.25 稳定迭代" D1["v1.22 Dockershim 移除"] D2["v1.25 PSP → PSS"] end subgraph "v1.26+ 现代化" E1["v1.28 Sidecar"] E2["v1.30 CEL Validation"] end A1 --> A2 --> A3 --> A4 B1 --> B2 --> B3 --> B4 C1 --> C2 --> C3 --> C4 D1 --> D2 E1 --> E2 style A1 fill:#e8f5e9 style B2 fill:#e1f5fe style C1 fill:#fff3e0 style D1 fill:#fce4ec style E1 fill:#f3e5f5

3.6 CNCF 生态里程碑#

CNCF（云原生计算基金会）自 2015 年成立以来，一直是 Kubernetes 生态繁荣的关键推手。以下是 CNCF 生态的关键节点：

2015 年 7 月：CNCF 成立，Kubernetes 成为第一个托管项目。初始成员包括 Google、CoreOS、Mesosphere、Red Hat 等。
2016 年 11 月：Kubernetes 成为 CNCF 第一个毕业项目，标志着其社区治理和成熟度达到生产级标准。
2017 年：Prometheus 毕业，可观测性生态成型。Envoy、containerd 进入孵化。
2018 年：CoreDNS 替代 kube-dns 成为默认 DNS 方案（v1.11+）。Helm 从 CNCF 毕业，成为 Kubernetes 事实上的包管理标准。
2019 年：Vitess 毕业。TiKV、NATS 进入孵化。CNCF 项目数突破 80。
2020 年：etcd 进入孵化。Falco 毕业，运行时安全成为关注焦点。
2021 年：Cilium 进入孵化，eBPF 开始在 Kubernetes 网络和可观测性领域展露头角。Contour、Open Policy Agent 毕业。
2022 年：Cilium 毕业，成为 CNCF 历史上毕业速度最快的项目之一。Dapr、Backstage 进入孵化。CNCF Landscape 项目数突破 900。
2023 年：Istio 进入 CNCF 孵化，服务网格领域进一步整合。KubeVirt 毕业，虚拟机与容器的混合管理成为趋势。

截至 2024 年，CNCF Landscape 已覆盖应用定义与开发、编排与管理、运行时、配置、可观测性与分析、服务网格、服务代理、存储等 10 余个类别，超过 1100 个项目。

四、为什么需要 Kubernetes#

4.1 K8s 的部署优势#

Kubernetes 以 Borg 十多年大规模集群管理和任务调度经验为基础，以容器化为底座，为存储和网络提供了统一接口，并且内置多种控制器用于应对各种部署和维护场景，为大规模集群管理交出了一份新的答卷。在正式介绍 K8s 之前，需要先回顾历史，才能理解它为何被历史所选择。

传统部署时代：

早期，各组织机构在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，可能会出现某个应用程序占用大部分资源的情况，结果可能导致其他应用程序性能下降。一种解决方案是在不同的物理服务器上运行每个应用程序，但这会因资源利用不足而无法扩展，且维护大量物理服务器的成本很高。

虚拟化部署时代：

作为解决方案，虚拟化技术应运而生。它允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。虚拟化使应用程序在 VM 之间隔离，并提供一定程度的安全保障，因为一个应用程序的信息不能被另一个应用程序随意访问。

虚拟化技术能够更好地利用物理服务器上的资源，并且因可轻松添加或更新应用程序而实现了更好的可伸缩性，降低了硬件成本等。

每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。

容器部署时代：

容器类似于 VM，但具有更宽松的隔离属性，可以在应用程序之间共享操作系统（OS）。因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。

容器因具有许多优势而流行起来。以下是容器的一些好处：

敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。
持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的容器镜像构建和部署。
关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像，从而将应用程序与基础架构分离。
可观察性：不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。
跨开发、测试和生产的环境一致性：在便携式计算机上与在云中运行方式相同。
跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、Google Kubernetes Engine 以及其他任何地方运行。
以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。
松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分，可以动态部署和管理——而不是在一台大型单机上整体运行。
资源隔离：可预测的应用程序性能。
资源利用：高效率和高密度。

容器是一种更好的打包和运行应用程序的方式。在生产环境中，你需要管理运行应用程序的容器，并确保不会停机。例如，如果一个容器发生故障，则需要启动另一个容器。如果由系统自动处理这一行为，会不会更轻松？

这正是 Kubernetes 要解决的问题！Kubernetes 为你提供了一个面向终态的、可弹性运行分布式系统的框架。它会满足你的扩展要求、故障转移、部署模式等需求。

Kubernetes 为你提供：

服务发现和负载均衡：Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器。如果进入容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。
存储编排：Kubernetes 允许你自动挂载你选择的存储系统，例如本地存储、公共云提供商等。
自动部署和回滚：你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。
自动完成装箱计算：Kubernetes 允许你指定每个容器所需 CPU 和内存（RAM）。当容器指定了资源请求时，Kubernetes 可以做出更好的决策来管理容器的资源。
自我修复：Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。
密钥与配置管理：Kubernetes 允许你存储和管理敏感信息，例如密码、OAuth 令牌和 SSH 密钥。你可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。

4.2 Kubernetes 与其他编排系统的对比#

Kubernetes 并非唯一的容器编排系统，但它最终赢得了「容器编排之战」。理解它胜出的原因，需要对比同期的主要竞争者：

维度	Kubernetes	Docker Swarm	Apache Mesos/Marathon	Nomad
架构	声明式、面向终态	声明式	声明式（Marathon）/ 命令式（Mesos）	声明式
扩展性	CRD + Operator + Webhook	有限	Framework 机制	Task Driver
容器运行时	CRI（Docker/containerd/CRI-O）	Docker 仅限	Docker/containerd	多种（Docker/QEMU/Java）
服务发现	Service + CoreDNS	内置 DNS	Mesos-DNS/Consul	Consul 集成
网络模型	CNI 插件	Overlay 网络	CNI/DCOS Overlay	CNI
存储模型	PV/PVC/CSI	Volume 插件	外部存储	CSI
多负载支持	Pod/Deployment/StatefulSet/Job/DaemonSet	Service/Stack	Docker 容器/自定义执行器	多种 Task Driver
社区规模	最大（CNCF）	较小	中等（Mesosphere）	较小（HashiCorp）

Kubernetes 胜出的核心原因：

声明式 API + 控制器模式：这一源自 Borg 的设计理念使 K8s 天然支持自愈和期望状态收敛，运维复杂度远低于命令式系统。
可扩展性：CRD + Operator 模式使 K8s 不仅仅是一个编排器，更是一个通用的工作负载平台。任何有状态应用都可以通过 Operator 接入 K8s 管理。
开放生态：CNCF 中立的治理结构吸引了大量厂商和开发者，形成了强大的网络效应。Google、Red Hat、微软、华为等大厂的共同投入使 K8s 的迭代速度远超竞争对手。
时机：2015 年 Docker 刚刚开始普及容器化，市场需要一个开源的、中立的编排方案。Swarm 太封闭，Mesos 太复杂，Nomad 太小众，K8s 刚好占据了最佳位置。

五、可变基础设施和不可变基础设施#

基础设施，可以理解为服务器、虚拟机或容器。

与不可变基础设施相对的，我们称之为可变基础设施。在以往传统的开发运维体系中，软件开发完成后，需要工程师或管理员通过 SSH 连接到服务器上，然后进行脚本安装、deb/rpm 包安装等工作，并逐个机器地调整对应的配置参数及文件。后续还会根据需要对该环境进行不断更改，比如内核升级、配置更新、打补丁等。

随着这类变更操作越来越多，没有人能弄清楚这个环境具体经历了哪些操作，后续的变更也经常会遇到各种意想不到的问题，比如软件包的循环依赖、参数配置不一致、版本漂移等。

基础设施会变得越来越脆弱、敏感，一些小的改动都有可能引发大的不可预知的结果。这令广大开发者和环境管理员异常抓狂——他们需要凭借丰富的技术积累，耗费大量时间去排查解决问题。云计算的出现降低了环境标准化的成本，但业务的交付管理成本依然很高。

通常来说，可变基础设施会导致以下问题：

持续的变更修改给服务运行态引入过多的中间态，增加了不可预知的风险。
故障发生时，难以及时快速构建出新的服务副本。
不易标准化，交付运维过程异常痛苦。虽然可以通过 Ansible、Puppet 等部署工具进行交付，但很难保证对底层各种异构环境支持良好，还存在随时可能出现的版本漂移问题。比如你可能经常遇到这样的情况：某个软件包几个月前安装还能正常运行，现在到一个新环境安装后竟然无法正常工作了。

不可变基础设施则是另一种思路：部署完成以后，便成为一种只读状态，不可对其进行任何更改。如果需要更新或修改，就使用新的环境或服务器去替代旧的。不可变基础设施带来了更一致、更可靠、更可预测的设计理念，可以缓解或完全避免可变基础设施中遇到的各种常见问题。

同时，借助容器技术可以自动化地构建出不可变的、可版本化管理的、可一致性交付的应用服务体系，其中包括标准化实例、运行环境等。还可以依赖持续部署系统进行应用服务的自动化部署更新，加快迭代和部署效率。Kubernetes 中的不可变基础设施就是 Pod。

graph LR subgraph "可变基础设施" M1["SSH 登录服务器"] M2["手动安装依赖"] M3["修改配置文件"] M4["打补丁/升级"] M5["环境漂移"] M1 --> M2 --> M3 --> M4 --> M5 end subgraph "不可变基础设施" I1["编写 Dockerfile"] I2["构建镜像"] I3["推送镜像仓库"] I4["创建新 Pod 替换旧 Pod"] I5["环境一致"] I1 --> I2 --> I3 --> I4 --> I5 end style M5 fill:#ffcdd2 style I5 fill:#c8e6c9

5.1 不可变基础设施的实践原则#

不可变基础设施不仅是一个概念，更是一套实践原则：

镜像即交付物：应用及其全部依赖打包为容器镜像，镜像一旦构建不可修改。任何变更都需要重新构建镜像并推送新版本。
配置与代码分离：通过 ConfigMap 和 Secret 将配置从镜像中剥离出来，运行时注入。这样同一镜像可以在不同环境（dev/staging/prod）中复用，只需变更配置。
版本化一切：镜像有 Tag，配置有 Git Commit，部署有 Release。任何变更都可以追溯到具体的版本号，回滚也有明确的基准点。
替换而非修改：当 Pod 需要更新时，K8s 不会在原容器上做原地修改，而是创建新 Pod、销毁旧 Pod。这就是 Deployment 滚动更新的核心机制。

六、Kubernetes 是怎样工作的#

Kubernetes 采用经典的 C/S 架构，由控制平面（Control Plane）和工作节点（Worker Node）组成。所有组件通过 API Server 进行通信，etcd 作为唯一的持久化存储，这是一种高度解耦的设计。

主节点部分：

etcd：持久化存储整个集群的状态。etcd 是一个分布式键值存储，基于 Raft 协议保证一致性。Kubernetes 的所有资源定义（Pod、Service、ConfigMap 等）都存储在 etcd 中。etcd 的性能和可靠性直接决定了集群的可用性，生产环境建议部署 3 或 5 个节点的 etcd 集群。
API Server：提供资源操作的唯一入口，并提供认证、授权、访问控制、API 注册和发现等机制。所有组件（kubectl、Scheduler、Controller Manager、Kubelet）都通过 API Server 进行交互，绝不直接访问 etcd。API Server 支持多种认证方式（TLS 证书、Token、OIDC 等）和授权模式（RBAC、ABAC、Node 等），还支持 Admission Webhook 进行自定义校验和变更。
Controller Manager：负责维护集群的状态，比如故障检测、自动扩展、滚动更新等。Controller Manager 内部运行着多个控制器：Deployment Controller、ReplicaSet Controller、StatefulSet Controller、DaemonSet Controller、Job Controller、Endpoint Controller、Service Account Controller 等。每个控制器通过「期望状态 → 实际状态」的 Reconcile 循环不断驱动集群向期望状态收敛。
Scheduler：负责资源调度，按照预定的调度策略将 Pod 调度到相应的机器上。v1.19+ 默认调度器基于 Scheduling Framework 实现，调度过程分为 Filter（过滤不满足条件的节点）、Score（对满足条件的节点打分）、Bind（绑定 Pod 到得分最高的节点）三个阶段。每个阶段都可以通过插件扩展。

工作节点部分：

Kubelet：从 API Server 获取 Pod 的配置，负责维护容器的生命周期以及 Volume（CVI）和网络（CNI）的管理。Kubelet 定期向 API Server 上报节点状态（NodeStatus），并通过 CAdvisor 采集容器的资源使用指标。Kubelet 还实现了 Pod 的生命周期管理（Pod Lifecycle Event Generator，PLEG），通过容器运行时接口（CRI）与 containerd 交互。
Container Runtime（1.20 之前默认为 Docker，之后默认为 containerd）：负责镜像管理以及 Pod 和容器的真正运行（CRI）。CRI（Container Runtime Interface）将 Kubelet 与具体的运行时实现解耦，目前支持的运行时包括 containerd、CRI-O 和 Mirantis Container Runtime。
Kube-proxy：负责为 Service 提供集群内部的服务发现和负载均衡。Kube-proxy 支持三种模式：userspace（已废弃）、iptables（默认，v1.2+）和 IPVS（v1.8+，大规模场景推荐）。v1.26+ 开始引入 nftables 模式作为 iptables 的继任者。

客户端部分：

kubectl：与 API Server 通信，将命令发送到主节点的命令行工具。kubectl 支持命令式命令（kubectl run）、命令式对象配置（kubectl apply -f）和声明式对象配置（kubectl apply -k）三种操作模式。

组件之间的关系为：

Kubernetes 中调度工作负载的最小单位为 Pod。Pod 实际上就是一组协同工作的容器组合，它们运行在同一个工作节点（Node）上，共享网络/PID/IPC/UTS 命名空间，并通过卷共享存储资源。在 Pod 之上是各种控制器，它们以不同的方式控制 Pod 的运行行为：

通过 Deployment 可以维护无状态的多副本集程序。
通过 Job/CronJob 可以维护定时批处理任务。
通过 DaemonSet 针对不同类型的工作节点运行 Pod，提供系统级的后台任务。
通过 StatefulSet 可以运行名称固定且拥有独立生命周期的存储，是一种更可靠和稳定的模拟虚拟机的机制。

6.1 一个 Pod 从创建到运行的工作流#

理解 Kubernetes 的工作方式，最好的方式是跟踪一个 Pod 从提交到运行的完整流程：

sequenceDiagram participant U as 用户/kubectl participant A as API Server participant E as etcd participant S as Scheduler participant CM as Controller Manager participant K as Kubelet participant C as Container Runtime U->>A: kubectl apply -f pod.yaml A->>A: 认证 / 授权 / 准入控制 A->>E: 持久化 Pod 定义 A-->>U: 返回提交成功 Note over S: Scheduler Watch 到未调度 Pod S->>A: 绑定 Pod 到 Node（更新 Pod.spec.nodeName） A->>E: 持久化绑定结果 Note over K: Kubelet Watch 到本节点新 Pod K->>A: 更新 Pod 状态为 Pending K->>C: CRI: Pull Image C-->>K: 镜像拉取完成 K->>C: CRI: Create & Start Container K->>A: 更新 Pod 状态为 Running Note over K: 探针检测容器就绪 K->>A: 更新 Pod Condition: Ready=True A-->>U: Pod 可用

用户通过 kubectl apply 提交 Pod YAML 到 API Server。
API Server 经过认证（谁在操作）、授权（有没有权限）、准入控制（操作是否合规）三层校验后，将资源写入 etcd。此时 Pod 的 spec.nodeName 为空，状态为 Pending。
Scheduler 通过 Watch 机制感知到未调度的 Pod，执行调度算法：先过滤（Filter）出满足约束的节点，再打分（Score）选出最优节点，最后将绑定结果写回 API Server。
目标节点上的 Kubelet 通过 Watch 感知到新分配的 Pod，调用 CRI 接口拉取镜像、创建并启动容器。
Kubelet 持续上报 Pod 状态到 API Server，容器通过就绪探针（Readiness Probe）检查后，Pod 进入 Ready 状态，可以接收 Service 流量。

这个流程体现了 Kubernetes 最核心的设计模式：声明式 API + 控制器循环。用户只需声明「我想要什么」，Kubernetes 的各个组件自动协同驱动实际状态向期望状态收敛。