Kubernetes 改变了什么：从 Google 的内部工具说起

朴素科技第二篇文章，从 Kubernetes 的诞生、它和 Google 的渊源，到今天围绕它的企业会员与云原生生态，以及这一切如何悄悄改变了软件的生产方式。

2026年8月29日

📖 约 5 分钟阅读

Kubernetes 改变了什么：从 Google 的内部工具说起

这是「朴素科技」的第二篇文章。上次我们讲了 Docker——它把应用装进了一个标准化的「集装箱」。这次我们来讲讲：当全球有几十亿个集装箱需要调度时，谁来当「港口调度员」？

一、上次的留白：从一个集装箱到一支船队

在上一篇文章里，我们聊过 Docker 如何用一个轻量的容器，把软件和它运行所需的一切打包起来，让「在我电脑上明明是好的」这类笑话越来越少。

但很快，问题就变了。

假设你是一个互联网公司的工程师，今天公司有 10 个服务、100 个容器，你用 docker run 一条条命令也能管得过来。明天公司做大了，有 300 个微服务、3 万个容器，每个容器还需要版本管理、灰度发布、自动扩容、跨机器调度、节点宕机后的自动迁移……

这时候，“集装箱”已经做好了，但港口根本来不及调度。

Kubernetes 解决的就是这件事——把成百上千个容器，自动、安全、可预期地编排起来。

它的名字来自希腊语 κυβερνήτης (kubernetes)，意为「舵手」或「领航员」。工程师们通常简称它 k8s——中间的 8 个字母被 8 代替，就像业内常见的小习惯一样。

二、Kubernetes 到底是什么

如果你第一次接触 k8s，最容易绕进去的是它那一堆名词：Pod、Service、Deployment、Ingress、ConfigMap、Secret、Namespace…… 把它们剥到最朴素的层面，k8s 做的事情可以用一句话概括：

你告诉它「我想要 3 个 Web 服务实例、5 个数据库副本、其中 Web 用 5% 的 CPU 就自动扩容」，它负责让你的这堆容器一直满足这个期望。

这背后是一种叫 “期望状态” (desired state) 的思维方式：

# 一个最朴素的 Kubernetes 部署描述
apiVersion: apps/v1
kind: Deployment
metadata:
  name: blog
spec:
  replicas: 3        # 我希望跑 3 个实例
  selector:
    matchLabels:
      app: blog
  template:
    metadata:
      labels:
        app: blog
    spec:
      containers:
        - name: blog
          image: nginx:1.27
          ports:
            - containerPort: 80

只要把这个文件交给 k8s，它就会：

找 3 台合适的服务器，把 nginx:1.27 跑起来；
如果其中一台机器宕机，k8s 会把容器挪到其他机器，仍然保持 3 个；
如果你把 replicas 改成 5，它会自动启动额外的 2 个；
如果你把镜像改成 nginx:1.28，它会按你的节奏滚动升级，不会一次性把服务打挂。

这种“声明式 + 自动修复”的思路，是 k8s 真正革命性的地方。 它让运维从「人盯着屏幕敲命令」，变成了「写一份期望，剩下的让机器去做」。

三、Google 与 Kubernetes 的故事

聊 k8s，不能不聊 Google。

1. 一切要从 Borg 说起

在 Kubernetes 出现之前，Google 内部已经运行着一套叫 Borg 的系统十多年了。

Borg 之于 Google，就像 Windows 之于早期的微软——它是藏在一切产品背后的“操作系统”。 YouTube、Gmail、Google Search……这些服务都跑在 Borg 之上。它让 Google 成为第一家真正在大规模上做到「自动调度容器」的公司。

但 Borg 是 Google 高度内部化的东西，外界几乎看不到。

2013 年，Google 发表了那篇著名的论文 Large-scale cluster management at Google with Borg，把 Borg 的部分设计公开，第一次让业界窥见：原来“调度几十万台机器”这件事，有这种玩法。

2. 从 Borg 到 Kubernetes

2014 年 6 月，Google 在 DockerCon 上宣布开源一个叫 Kubernetes 的项目。

它由 Joe Beda、Brendan Burns、Craig McLuckie 三人主导发起——这三个人后来被称为「k8s 的三个父亲」。设计上有意借鉴了 Borg 的核心思想，但目标是给外部世界一个轻量、可学习、模块化的版本。

有意思的是，Google 在发布 k8s 的同时，做了一件更具战略眼光的事：

2015 年 7 月，Google 联合 Linux 基金会，把 Kubernetes 捐给了新成立的 CNCF（Cloud Native Computing Foundation）。

这一举动让 k8s 不再属于 Google，而成为整个云原生社区的公共基础设施。这让几乎所有云厂商、几乎所有企业，都可以放心地基于它做产品——而不用担心被某一家公司“绑架”。

3. 为什么 Google 要这么做？

这个问题值得多想一秒。

Google 拥有当时最强的容器编排技术，但它选择把它开源出来并且中立化。这件事从商业角度看，其实是 Google 一以贯之的“Android 模式”：

占领标准：让所有人都按我的接口写软件，那么云时代的“操作系统”就由我定义。
绑定生态：围绕 k8s 出现了一整个工具链（Helm、Prometheus、Istio、Argo……），这些工具大部分托管在 CNCF。
倒逼对手：AWS 当年有自己的 ECS，Azure 有自己的 Service Fabric——Google 用一个真正“中立”的开源项目，把对手的产品逼成了二线选择。

对 Google 来说，Kubernetes 不是一个产品，而是一张入场券：保证它在下一个十年依然站在云时代的最中心。

四、今天 K8s 的“企业会员”们

聊完了历史，再来看看今天的局面。

CNCF 把生态分成几个层级：白金会员、金牌会员、银牌会员，以及更广泛的开源贡献者。 2026 年的今天，白金会员主要有这几家：

Google（创始成员，至今仍是最大贡献者之一）
Microsoft（Azure Kubernetes Service 的母公司）
AWS（EKS，背后是 AWS 对整个云生态的回应）
Red Hat（OpenShift 是企业级 k8s 的代表）
VMware（Tanzu，被 Broadcom 收购后依然保持投入）
Intel、Huawei、阿里云、Oracle、SUSE、Cisco、F5 等

中国厂商里，华为和阿里云是白金会员，其他一些大厂如腾讯、字节也通过各种方式深度参与。

1. 为什么要花数百万美元成为会员？

CNCF 的白金会员每年要交数十万美元的会费，外加承诺投入工程师资源。这笔钱对企业来说不是小数目。

它们的目的至少有以下几层：

第一，话语权与生态位置 白金会员在 CNCF 的技术监督委员会（TOC）有席位，可以在生态走向中投票。这等于花钱买了一张“决定下一代云原生标准长什么样”的椅子。

第二，云市场的卡位 公有云是一个赢者通吃的市场。如果你的云上跑的 k8s 版本比别人更稳定、更便宜，企业自然会选择你的云——而 k8s 是所有云的“地基”。

第三，人才与品牌 一个企业如果在 CNCF 主导了某个项目，它就很容易吸引到全球最优秀的工程师，也会被外界视为“懂云原生的公司”。这是招聘和 PR 上的双重收益。

第四，绑定客户 围绕 k8s 的工具链（监控、安全、网络、存储……）通常由这些企业自己提供，客户一旦用上，就被软性地锁进了它们的生态。

2. 有趣的现象：曾经的对手，今天的盟友

最值得玩味的是 AWS。

AWS 一直是云计算市场的霸主，长期以来对开源态度“又爱又恨”。但当 k8s 事实上成为容器编排标准后，AWS 也只能入场：推出 EKS、把 ECR 容器仓库做强、甚至自己也主导了一些 CNCF 项目。

这就是标准的威力——一旦它赢了，所有人都得按它的规则玩。

五、Kubernetes 对我们意味着什么

和上次讲 Docker 时一样，我不想把这一节写成宣传文案，而是写下我真实感受到的“它如何改变了一些事”。

1. 对开发者：不必再懂“机器”

在 k8s 出现之前，要上线一个服务，你需要懂：操作系统、网络、负载均衡、CDN、监控告警、自动化脚本……

在 k8s 之后，一个写应用的工程师可以只关心应用本身—— 把容器镜像做好，把 yaml 文件写好，剩下的事 k8s 帮你处理。

这是一种温柔的解放：把专业的事交给专业的工具，把工程师宝贵的注意力还给创造本身。

2. 对公司：上云不再是一次“押宝”

以前，把核心业务放到某一家云上，就像把家搬到别人盖的房子里—— 一旦对方政策变了，你就很被动。

k8s 的好处在于，它是一套接口标准。你在 AWS 上跑的应用，几乎可以无缝迁到阿里云、华为云、私有数据中心，甚至是开发者自己的香橙派上。

它让“基础设施”第一次具有了真正的可移植性。

3. 对普通人：看不见的秩序

很多人不知道，今天你打网约车、订外卖、刷短视频、查健康码、订火车票—— 几乎每一个动作背后，都可能有一组 k8s 集群在某个云数据中心安静地工作着。

它们不会出现在新闻里，也不会出现在 App 的介绍页。它们只是默默地维持着这些服务的稳定、流畅、便宜。

这又是一种朴素的科技——不喧哗，自有力量。

六、一点朴素的感想

23 年毕业、初入公司的那段时间，是我真正接触 k8s 的开始。

在那之前，我对它的印象还停留在“听说过名字、知道它能调度容器”的层面；日常用的，一直是 Docker。直到被分到一个内部运维的活，我才第一次坐到一个真实的 k8s 集群前，看着 kubectl get nodes、 kubectl get pods 一行行地敲出来。

那是一台不太新的服务器，承担着公司好几套内部系统——OA、知识库、监控、CI runner…… 每个系统都被细心地打了多个副本，分散在不同节点上，任意一台机器宕机，另一个副本就会自动接管。对一个新人来说，这种“几乎不会停”的感觉，比任何抽象的概念都来得直接。

那也是我第一次真切地理解“舵手”这个名字——它不直接驮运货物（那是 Docker 的事），而是在几十个节点、几百个 Pod 之间，把每一个都放在最合适的位置。

后来又过了几年，我才慢慢分清两种 k8s 的差别：

公有云上的 k8s，几乎把所有麻烦事都替你想好了。块存储、文件存储、对象存储 S3，对应的 StorageClass 配好驱动就能用，想要多大就给多大，扩容是秒级的。
公司内自建的 k8s，更多时候只有一台老旧的 NAS 在背后默默撑着。文件存储能用，但块存储要做，对象存储要自己搭，每一个新需求都要从底层一路补到上面。

升级也是同样的对比。云上的 k8s 一个版本号点过去就完成了；自建的集群，从 kubeadm upgrade 到节点逐个 drain、再补回集群，常常要忙上一整个下午——但忙完之后，那种“一切稳稳地在最新版本上跑着”的感觉，也让人踏实。

回头看，k8s 的本质其实和 Docker 一样，是一种“驯服复杂性”的力量。它把“我要在 1000 台机器上跑 1000 个服务”这种让人头皮发麻的问题，拆成了“写一份 yaml，剩下的交给系统”。

科技并不需要炫技。能把复杂的事变简单，让小团队也能做大事，让普通人也能享受稳定的服务—— 这就是我想写下来的「朴素」。

如果你愿意，我想和你一起，慢一点地把科技的脉络梳清楚。下一次，我们也许可以聊聊支撑这一切的另一块朴素拼图—— S3，那个看起来不起眼、却悄悄让无数应用具备了“无限硬盘”能力的小东西。

参考资料

Brendan Burns et al., Kubernetes: Up and Running (O’Reilly)
Google, Large-scale cluster management at Google with Borg (EuroSys 2015)
CNCF 官网会员页面：cncf.io/about/members
CNCF Annual Survey 历年报告

— RCLiLong，写于 2026 年夏