文章目录1. 概述2. 核心能力2.1 服务发现与负载均衡2.2 存储编排2.3 自动部署与版本回滚2.4 资源调度自动装箱2.5 自我修复2.6 配置与密钥管理3. 应用部署三大演进阶段3.1 传统物理机部署时代3.2 虚拟化部署时代VM3.3 容器部署时代4. Google 三代容器集群管理平台4.1 第一代Borg2003–2013内部闭源系统4.2 第二代Omega2011–2014内部试验项目4.3 第三代Kubernetes2014 年 6 月 至今5. 集群可扩展性阈值5.1 重要前置说明5.2 内置资源API Server etcd 存储阈值5.3 各类资源对象数量阈值5.4 依赖云厂商与环境的阈值非完整清单6. K8s 不属于全能型 PaaS 平台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 第一代Borg2003–2013内部闭源系统Google第一代大规模容器集群管理平台支撑谷歌搜索、Gmail、YouTube全量业务稳定运行是Kubernetes技术根基。采用中心化MasterAgent架构统一管理数万台服务器上数十万任务负责任务与节点的分配调度。整体架构为单体中心化设计多团队协作开发导致工具生态碎片化扩展灵活性不足难以支撑多租户大规模并发调度。4.2 第二代Omega2011–2014内部试验项目Borg的下一代迭代版本属于架构预研项目仅在Google内部试验未正式上线全量业务为K8s奠定架构理论基础。Omega模块化、状态驱动、声明式设计直接决定了Kubernetes控制平面整体架构。摒弃Borg单体调度器采用共享全局状态存储 乐观并发控制支持多个调度器并行工作实现多租户资源隔离与并发调度集群扩展性大幅提升。不再依赖逐条执行命令式操作用户只定义业务最终期望状态系统自动持续收敛目标状态形成K8s声明式API的前身。集群所有资源状态统一存入强一致性存储所有控制组件监听状态变更解耦控制平面各个模块。4.3 第三代Kubernetes2014 年 6 月 至今2014年6月Google在DockerCon正式对外开源Kubernetes项目。2015年7月发布v1.0正式版随后项目移交Linux基金会旗下CNCF云原生计算基金会托管彻底脱离Google厂商绑定走向中立开源治理。核心发展阶段阶段时间区间核心特征初创完善期2014–2016补齐调度、自愈、滚动发布基础能力社区初步成型生态爆发期2017–2020CRD 自定义资源、Operator 模式成熟监控、存储、网络插件百花齐放击败 Docker Swarm、Mesos 成为行业标准稳定标准化期2021 至今控制面高可用、安全机制、双栈网络、批量任务调度持续完善成为私有云、混合云、公有云统一容器底座5. 集群可扩展性阈值K8s官方没办法保证无限规模集群都稳定。想要集群不卡、不崩、API响应正常就必须遵守官方给出的最大负载标准。这份文档是K8s性能小组SIG Scalability实测出来的安全上限超过不会直接炸但会集群越来越卡页面刷新慢发布延迟、调度卡顿etcd、apiserver压力暴增5.1 重要前置说明下文给出的阈值存在若干前提约束绝大多数阈值并非硬性强制限制超出阈值只会造成性能下降不会直接导致集群整体宕机。绝大多数集群级阈值都是针对最大规模集群给出的集群规模缩小时对应上限会按比例降低。不同Kubernetes版本阈值会发生变动整体只升不降下文阈值基于开发主干版本head。配置直接影响阈值大小本文默认采用开源社区版本分片etcd架构。自2025年12月起版本准入级别的大规模压测均基于kops部署。5.2 内置资源API Server etcd 存储阈值指标项单资源类型上限整集群上限非Event类对象总数150000待定(TBD)Event事件对象总数1000000无限制单个对象大小1.5MB1.5MB对象总存储容量1.5GB待定(TBD)5.3 各类资源对象数量阈值指标项单命名空间上限整集群上限节点 Node 数量—5000命名空间 Namespace 数量—10000Pod 总数量3000150000单节点Pod数量min(110, 10×CPU核心数)min(110, 10×CPU核心数)Service 服务数量500010000全部Service后端Endpoint总数待定待定单个Service下Endpoint数量250—Secret密钥数量待定待定ConfigMap配置数量待定待定Deployment副本控制器2000待定DaemonSet待定待定Job定时任务待定待定StatefulSet有状态应用待定待定AccessToken令牌数量20002000AccessToken校验QPS5000 QPS5000 QPS5.4 依赖云厂商与环境的阈值非完整清单指标项单命名空间上限整集群上限Ingress网关规则待定待定PersistentVolume持久卷PV—待定PersistentVolumeClaim存储PVC待定待定单节点PVC挂载数量待定待定6. K8s 不属于全能型 PaaS 平台Kubernetes 并不是大而全的传统 PaaS 平台。它工作在容器层而非底层硬件层。虽然自带部署、扩缩容、负载均衡这类PaaS通用能力同时支持对接日志、监控、告警等第三方组件。K8s并非大一统的封闭系统内置方案全部支持替换、插件化。它只用来搭建上层开发平台底座把技术选择权留给使用者保证高度灵活。Kubernetes不具备的能力不约束应用类型支持几乎所有业务负载无状态服务、有状态数据库、大数据计算任务。只要程序能装进容器就能在K8s正常运行。不负责编译代码、打包构建应用CI/CD流水线完全交给企业自主选型K8s只负责运行最终的容器镜像不介入源码构建环节。不内置应用中间件服务消息队列、Spark计算框架、MySQL数据库、Redis缓存、分布式存储这类组件K8s不会预装。你可以自行把中间件部署到集群里业务应用再通过标准接口调用。不是完整的日志、监控、告警产品仅预留指标采集与输出接口只提供基础验证能力完整运维体系需要接入Prometheus、ELK等第三方组件。不强制特定配置语法只对外提供声明式APIYAML、JSON或者其他配置工具都可以对接不限定jsonnet 这类专用语言。不管理宿主机操作系统不做服务器初始化、系统运维、机器自愈只管控容器层面。