Kubernetes并非一蹴而就。
它凝聚了谷歌在运行数十亿个容器过程中，历经15年汗水与实践积累的宝贵经验。
🎯 本文涵盖内容
- 谷歌内部集群管理系统 Borg的诞生背景与核心理念
- 为克服Borg局限而设计的 Omega的实验性尝试
- 开源走向世界的 Kubernetes如何成为云标准
- 三大系统的核心差异比较
📌 引入 / 背景 — 谷歌为何要创建这些系统？
我们现在使用的Gmail、YouTube、Google搜索。您是否曾想过这些服务同时处理着数亿用户的请求？
2000年代初期，谷歌面临着一个巨大的问题。随着服务呈爆炸式增长，手动逐一管理数千台服务器变得物理上不可能。一旦有人不小心配置错误，就会引发故障，资源被浪费，工程师们则通宵达旦地应对故障。
正是在这种痛苦中，谷歌的集群管理系统三部曲——Borg → Omega → Kubernetes应运而生。
💡 什么是集群(Cluster)？ 将多台服务器（节点）捆绑成一个计算资源池。其理念是将整个集群视为一台巨大的计算机来管理，而非管理单个服务器。
🔍 第一代: Borg — “谷歌的秘密武器” (2003年~)
Borg是什么？
Borg是谷歌自2003年起内部开发并运营的大规模集群管理系统。它能够自动将数十万个作业(Job) 分发并管理到数千台机器上。
其名称来源于《星际迷航》中的外星种族“Borg”。就像Borg将个体吸收到集体中一样，其理念是将数千台独立的服务器作为一个巨大的集体来运营。
Borg的核心概念
Borg将作业分为两种类型：
- Prod (Production): 对延迟敏感的服务。如Gmail、搜索等实时服务。始终具有最高优先级。
- Non-Prod (Batch): 大数据处理等批处理作业。优先级较低。
这种分类是核心。Borg通过将Prod和Non-Prod作业混合部署(Bin Packing) 在同一物理服务器上，最大限度地减少了资源浪费。当Prod作业不使用CPU时，Batch作业会偷偷使用，一旦Prod需要，Batch作业会立即让出资源。
Borg解决了什么？
| 问题 | Borg的解决方案 |
| 手动管理数千台服务器 | 中央调度器自动部署 |
| 服务故障时手动恢复 | 自动重启、重新调度 |
| 资源浪费 | Prod/Batch混合部署，最大化利用率 |
| 缺乏部署自动化 | 通过Job定义文件进行声明式部署 |
### Borg的架构
Borg由BorgMaster（中央控制平面）和Borglet（各节点的代理）组成。
[BorgMaster] ─── 스케줄링 결정
│
├── [Borglet] ─ 서버 노드 1
├── [Borglet] ─ 서버 노드 2
└── [Borglet] ─ 서버 노드 N当BorgMaster指示“将此作业运行在那台服务器上”时，Borglet会实际执行并报告状态。
Borg的局限性
然而，Borg存在结构性问题：
- 单体式BorgMaster: 所有决策都由一个BorgMaster做出。随着系统规模扩大，瓶颈日益严重。
- 以Job为中心的设计: Borg的基本单位是“Job”，其中包含“Task”。表达作业之间的关系显得笨拙。
- IP地址共享: 同一服务器上的Task共享IP地址，导致频繁的端口冲突。
- 历史遗留问题累积: 由于长期仅在内部使用，为了保持向下兼容性，结构改进变得困难。
🔍 第二代: Omega — “从零开始重新设计” (2008年~)
Omega的诞生目的
感受到Borg局限性的谷歌工程师们，在2008年左右启动了一个名为Omega的实验性项目。它始于一个问题：“如果我们不修复Borg，而是从头开始正确设计，会怎么样？”
Omega确实在谷歌内部运行过，但未能完全取代Borg。因为Borg已经深深植根于谷歌的基础设施中。
Omega的创新: 共享状态(Shared State)架构
Borg最大的问题是集中式调度器。一个BorgMaster做出所有决策，导致扩展性受限。
Omega通过共享状态(Shared State)方式解决了这个问题：
기존 Borg:
[BorgMaster] → 모든 결정 → [Borglet들]
(병목 발생)
Omega:
[Scheduler A] ──┐
[Scheduler B] ──┼─→ [공유 상태 저장소] → [노드들]
[Scheduler C] ──┘
(낙관적 동시성 제어)多个调度器同时观察集群状态并独立做出调度决策。如果发生冲突，则通过乐观并发控制(Optimistic Concurrency Control)来解决。
💡 乐观并发控制: “假设冲突很少发生，先执行操作，如果之后发现冲突则重试”的方式。相比悲观方式（先加锁再开始），其吞吐量更高。
###
Omega留下的遗产
Omega本身未能取代Borg，但其核心思想对后来的Kubernetes产生了巨大影响：
- 将资源视为一等公民: 具体明确并跟踪CPU、内存
- 调度器分离: 摆脱对单一调度器的依赖
- 强化声明式API: 声明所需状态，系统自动调整以匹配的方式
🔍 第三代: Kubernetes — “改变世界的开源项目” (2014年~)
谷歌为何要开源？
2013年Docker的出现，使得容器技术开始普及。谷歌意识到：“如果我们把十多年积累的经验开源出来，我们就能制定云生态系统的标准。”
2014年6月，谷歌将Kubernetes（库伯内特斯）开源。它在希腊语中意为“舵手”（掌舵的人）。其标志是船舵（Helm）也因此而来。
将Borg的教训融入Kubernetes
谷歌工程师们在2016年发表的论文《Borg, Omega, Kubernetes》中详细阐述了Borg的运营经验如何影响了Kubernetes的设计：
🔴 Borg的错误 → Kubernetes的解决方案
| Borg的问题 | Kubernetes的解决方案 |
| 以Job/Task为中心结构，难以表达关系 | 引入Pod概念。将容器组重新定义为单位 |
| Task共享IP，端口冲突 | 为每个Pod分配唯一IP |
| 单体式BorgMaster | 分离的组件 (API Server, Scheduler, Controller Manager) |
| 内部专用设计 | 以开放API为中心，可扩展的插件结构 |
###
Kubernetes的核心架构
[Control Plane]
├── API Server ← 모든 요청의 관문
├── Scheduler ← Pod를 어느 노드에 배치할지 결정
├── Controller Mgr ← 현재 상태를 원하는 상태로 유지
└── etcd ← 클러스터 전체 상태 저장 (분산 KV 저장소)
[Worker Nodes]
├── kubelet ← Borglet과 동일한 역할, 컨테이너 실행·관리
├── kube-proxy ← 네트워크 규칙 관리
└── Container Runtime (Docker, containerd 등)###
声明式API — Kubernetes的哲学Kubernetes最强大的哲学是声明式(Declarative)管理。
# 声明所需状态
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-webserver
spec:
replicas: 3 # 始终运行3个
selector:
matchLabels:
app: webserver
template:
metadata:
labels:
app: webserver
spec:
containers:
- name: nginx
image: nginx:1.25
resources:
requests:
cpu: "250m" # 0.25 CPU请求
memory: "128Mi" # 128MB内存请求
limits:
cpu: "500m" # 最大0.5 CPU
memory: "256Mi" # 最大256MB应用此YAML后，Kubernetes会自动运行3个nginx Pod，如果其中一个宕机，也会自动恢复。工程师只需声明“想要什么”，而非“如何实现”。
Kubernetes创建的生态系统
Kubernetes真正伟大的原因不仅仅是技术本身。它创造了一个生态系统。
- 2015年: 成立CNCF(Cloud Native Computing Foundation)。谷歌捐赠Kubernetes。
- 2016年: Helm（包管理器）、各云厂商的托管服务（GKE、AKS、EKS）出现。
- 2017年: Docker Swarm、Mesos等竞争对手事实上承认Kubernetes为标准。
- 2018年以后: Service Mesh (Istio)、GitOps (ArgoCD)、Serverless (Knative)等数百种工具在Kubernetes之上运行。
⚠️ 注意事项 / 常见错误
1. Kubernetes并非Borg的开源版本 🚫 Kubernetes是基于Borg的经验教训，从头开始重新设计的系统。它并非将Borg的代码直接开源。
2. Omega也未能取代Borg 🚫 在谷歌内部，Borg、Omega和Kubernetes是同时运行的。Borg至今仍支撑着谷歌的核心基础设施。
3. Kubernetes = 不仅仅是容器编排 ✅ 许多人只将其理解为“管理多个Docker的工具”，但Kubernetes是一个声明式管理整个云原生基础设施的平台。它涵盖了网络、存储、安全策略、服务发现等。
✅ 总结 / 结束语
| 系统 | 时期 | 公开情况 | 核心创新 | 局限性 |
| Borg | 2003~ | 内部专用 | 大规模自动化，Prod/Batch混合 | 单体式，扩展性受限 |
| Omega | 2008~ | 内部专用 | 共享状态，多调度器 | 未能取代Borg |
| Kubernetes | 2014~ | 开源 | 声明式API，插件生态系统 | 学习曲线陡峭 |
谷歌的15年征程不仅仅是简单的技术演进。它是从运营数十亿个容器中汲取的痛苦教训，以Kubernetes的形式向世界公开。
当您执行一行`kubectl apply -f deployment.yaml`时，其背后是谷歌工程师们20年来积累的智慧在运作。🚀
下一步，学习Kubernetes的调度机制、etcd的Raft共识算法以及Service Mesh (Istio)将帮助您更好地理解这个生态系统的深度。
发表回复