1. 概述

官网文档
GitHub 地址

Kubernetes（简称K8s）是一款具备可移植性、高可扩展性的开源容器编排平台，面向容器化工作负载与业务服务提供全生命周期管理，原生支持声明式配置与自动化运维能力。

项目拥有庞大且持续高速扩张的开源生态，配套运维工具、商业技术支持、中间件插件体系非常完善，目前已是云原生领域事实标准。

Kubernetes源自希腊语，本义为舵手、领航员，寓意平台统一调度集群内所有容器实例，掌控分布式业务运行状态。K和s中间有8个字符，简写为K8s，是行业通用简称。

2. 核心能力

容器可以把应用连同运行环境打包，运行起来十分方便。但上线生产后，只靠容器远远不够：一旦容器崩溃，业务就会中断，需要手动拉起新容器来顶替。

如果能让系统自动监控、自动顶替故障容器，运维就轻松多了，而Kubernetes就是干这件事的平台。用来管控分布式应用的整套框架，自动处理扩容、故障容灾、版本发布等问题，像金丝雀发布这类灰度部署都能轻松实现。

容器负责打包应用，K8s负责大批量容器的自动化运维：调度资源、自动扩容、自动救急、灰度发布、保管密钥，实现业务7×24小时稳定运行。

2.1 服务发现与负载均衡

给容器分配固定访问地址，支持域名访问。当访问流量暴涨时，自动把流量分摊到多个实例上，避免单台压力过大，保障业务稳定。

2.2 存储编排

不用手动给每一台机器挂载硬盘。可以自动挂载本地磁盘、云硬盘等各类存储，让数据和容器解耦，容器迁移数据不会丢失。

2.3 自动部署与版本回滚

只需要定义好目标状态，K8s会分批平稳升级应用。新版本出问题时，一键回退到老版本；也能自动销毁旧容器、创建新容器，全程可控。

2.4 资源调度（自动装箱）

服务器组成集群，你只需要填写每个应用需要多少CPU、内存。K8s会智能把容器调度到合适的服务器上，充分利用硬件资源，避免资源浪费。

2.5 自我修复

• 自动重启崩溃的容器
• 节点宕机时，把容器迁移到其他机器重建
• 健康检查失败就直接杀掉异常实例
• 实例没就绪前，不会把流量切过来，防止用户访问报错

2.6 配置与密钥管理

密码、令牌、密钥这类敏感信息统一保管。修改配置或者密钥时，不需要重新打包镜像，也不用把明文密码写到配置文件里，更加安全。

3. 应用部署三大演进阶段

Kubernetes的诞生并非偶然，而是传统业务部署模式在规模化、云原生场景下的技术演进必然结果。通过梳理物理机部署、虚拟机部署、容器部署三个时代的架构痛点与优势，可清晰论证Kubernetes成为新一代容器编排标准的核心原因。

3.1 传统物理机部署时代

早期企业业务直接部署、运行在物理服务器硬件之上，无任何虚拟化、资源隔离层。

核心痛点：

• 资源无隔离：单台物理机多应用共享硬件资源，无CPU、内存配额限制，极易出现单应用抢占全部资源，导致其他业务卡顿、宕机。
• 资源利用率极低：为规避资源争抢问题，普遍采用“一应用一物理机”部署模式，大量硬件资源长期闲置浪费。
• 运维成本高昂：业务扩张需要采购、维护大量物理服务器，机房运维、硬件折旧、电力成本极高。
• 无法横向扩容：部署固化、环境固化，业务弹性伸缩能力极差，无法适配互联网业务快速迭代、突发流量场景。

3.2 虚拟化部署时代（VM）

基于虚拟化技术，单台物理服务器可虚拟出多台独立虚拟机（VM），每台虚拟机拥有完整独立操作系统、硬件资源、文件系统，实现物理硬件的切片复用。

核心优势：

• 资源隔离安全：虚拟机之间完全隔离，独立系统、独立资源，业务数据互不互通，解决物理机资源争抢问题。
• 硬件利用率提升：单物理机运行多业务虚拟机，大幅盘活闲置硬件资源，降低硬件采购成本。
• 运维灵活度提升：虚拟机可快速创建、销毁、迁移，业务新增、迭代、上线效率优于物理机。
• 集群化能力成型：可将多台物理机资源整合为虚拟机资源池，实现资源统一调度。

固有缺陷：虚拟机属于重量级虚拟化方案，每台VM均搭载完整操作系统，占用大量内存、磁盘、CPU资源，启动慢、部署密度低，无法适配微服务、大规模批量任务的轻量化、高频部署场景。

3.3 容器部署时代

容器在虚拟机隔离能力的基础上进一步轻量化，多个容器共享宿主机操作系统内核，仅封装应用程序与依赖环境；同时保留独立CPU、内存、进程、文件系统隔离能力，实现轻量隔离、高效复用。

容器与底层硬件、操作系统解耦，镜像一次构建，可在本地机房、各大公有云、不同Linux发行版环境无缝迁移，可移植性极强。

容器核心优势：

• 敏捷构建与发布：容器镜像结构精简、制作简单，相较于虚拟机镜像，构建速度更快、交付效率更高。
• 稳定持续集成与交付：基于不可变镜像特性，可实现高频、稳定的版本发布，支持秒级快速回滚，规避发布事故风险。
• 开发运维解耦：在项目构建/打包阶段完成容器镜像制作，部署阶段无需重复配置环境，彻底实现业务代码与底层基础设施解耦。
• 全方位可观测性：不仅支持系统层级指标采集，还可精准抓取应用健康状态、业务埋点、运行日志，运维可观测性更强。
• 全环境一致性：开发、测试、预发、生产环境镜像完全一致，彻底解决“本地能跑、线上报错”的环境差异问题。
• 跨平台可移植：兼容Ubuntu、RHEL、CoreOS等主流系统，适配本地机房、私有云、各大公有云，无平台绑定。
• 面向应用的精细化管理：管控重心从“维护操作系统”升级为“管理业务应用”，贴合业务运维核心诉求。
• 适配微服务架构：支持单体应用拆分为多组独立微服务，动态部署、弹性调度，摆脱传统单主机笨重部署模式。
• 稳定资源隔离：通过内核层级资源限制，保障各应用资源配额稳定，业务性能可预测。
• 超高资源利用率：容器轻量化、低开销、高密度部署，最大化利用服务器硬件资源，大幅降低企业IT成本。

4. Google 三代容器集群管理平台

4.1 第一代：Borg（2003–2013，内部闭源系统）

Google第一代大规模容器集群管理平台，支撑谷歌搜索、Gmail、YouTube全量业务稳定运行，是Kubernetes技术根基。

采用中心化Master+Agent架构，统一管理数万台服务器上数十万任务，负责任务与节点的分配调度。

整体架构为单体中心化设计，多团队协作开发导致工具生态碎片化，扩展灵活性不足，难以支撑多租户大规模并发调度。

4.2 第二代：Omega（2011–2014，内部试验项目）

Borg的下一代迭代版本，属于架构预研项目，仅在Google内部试验，未正式上线全量业务，为K8s奠定架构理论基础。Omega模块化、状态驱动、声明式设计，直接决定了Kubernetes控制平面整体架构。

摒弃Borg单体调度器，采用共享全局状态存储 + 乐观并发控制，支持多个调度器并行工作，实现多租户资源隔离与并发调度，集群扩展性大幅提升。

不再依赖逐条执行命令式操作，用户只定义业务最终期望状态，系统自动持续收敛目标状态，形成K8s声明式API的前身。

集群所有资源状态统一存入强一致性存储，所有控制组件监听状态变更，解耦控制平面各个模块。

4.3 第三代：Kubernetes（2014 年 6 月 至今）

2014年6月，Google在DockerCon正式对外开源Kubernetes项目。

2015年7月发布v1.0正式版，随后项目移交Linux基金会旗下CNCF（云原生计算基金会）托管，彻底脱离Google厂商绑定，走向中立开源治理。

核心发展阶段：

5. 集群可扩展性阈值

K8s官方没办法保证无限规模集群都稳定。想要集群不卡、不崩、API响应正常，就必须遵守官方给出的最大负载标准。

这份文档是K8s性能小组（SIG Scalability）实测出来的安全上限，超过不会直接炸，但会：

• 集群越来越卡
• 页面刷新慢
• 发布延迟、调度卡顿
• etcd、apiserver压力暴增

5.1 重要前置说明

下文给出的阈值存在若干前提约束：

1. 绝大多数阈值并非硬性强制限制；超出阈值只会造成性能下降，不会直接导致集群整体宕机。
2. 绝大多数集群级阈值，都是针对最大规模集群给出的；集群规模缩小时，对应上限会按比例降低。
3. 不同Kubernetes版本阈值会发生变动（整体只升不降），下文阈值基于开发主干版本（head）。
4. 配置直接影响阈值大小，本文默认采用开源社区版本：分片etcd架构。自2025年12月起，版本准入级别的大规模压测均基于kops部署。

5.2 内置资源：API Server & etcd 存储阈值

5.3 各类资源对象数量阈值

5.4 依赖云厂商与环境的阈值（非完整清单）

6. K8s 不属于全能型 PaaS 平台

Kubernetes 并不是大而全的传统 PaaS 平台。

它工作在容器层，而非底层硬件层。虽然自带部署、扩缩容、负载均衡这类PaaS通用能力，同时支持对接日志、监控、告警等第三方组件。

K8s并非大一统的封闭系统，内置方案全部支持替换、插件化。它只用来搭建上层开发平台底座，把技术选择权留给使用者，保证高度灵活。

Kubernetes不具备的能力：

1. 不约束应用类型：支持几乎所有业务负载：无状态服务、有状态数据库、大数据计算任务。只要程序能装进容器，就能在K8s正常运行。
2. 不负责编译代码、打包构建应用：CI/CD流水线完全交给企业自主选型，K8s只负责运行最终的容器镜像，不介入源码构建环节。
3. 不内置应用中间件服务：消息队列、Spark计算框架、MySQL数据库、Redis缓存、分布式存储这类组件，K8s不会预装。
   你可以自行把中间件部署到集群里，业务应用再通过标准接口调用。
4. 不是完整的日志、监控、告警产品：仅预留指标采集与输出接口，只提供基础验证能力，完整运维体系需要接入Prometheus、ELK等第三方组件。
5. 不强制特定配置语法：只对外提供声明式API，YAML、JSON或者其他配置工具都可以对接，不限定jsonnet 这类专用语言。
6. 不管理宿主机操作系统：不做服务器初始化、系统运维、机器自愈，只管控容器层面。