从求职面试看 Kubernetes 的普及：技术选型背后的组织逻辑

背景

作者近期重返求职市场，在浏览职位描述、参与面试以及与十余家公司的工程团队交流后，观察到一个显著现象：与五年前相比，如今几乎所有公司都在使用 Kubernetes（K8s）。

回顾五年前，当时的技术生态主要分为三派：极少数采用 K8s 的先驱、基于 systemd 运行在虚拟机/VPS/EC2 上的主流群体，以及拥抱 Serverless（如 AWS Lambda、Google Cloud Run 等）的群体。

这一现状令作者感到惊讶，因为在他目前工作的“大型科技公司”级别的环境中，K8s 解决的是真实的大规模技术难题，其采用合乎逻辑。然而，许多只有 10 人左右、仅运行两个服务的初创公司，既没有微服务架构，也不具备高并发规模，却依然选择 K8s。这促使作者深入探究其背后的真实动因。

核心内容

作者在与多位 CTO 进行技术面试交流后发现，这些公司采用 K8s 的主要原因并非为了解决复杂的技术瓶颈，而是为了解决组织和管理层面的问题。CTO 们并非做出了错误的技术选择，而是在用 K8s 解决真实的非技术痛点。

1. 部署的统一性 (Uniformity)

K8s 实现了所有服务部署方式的一致性。在没有 K8s 的环境中，往往存在“信息孤岛”：例如，支付服务可能运行在一台裸金属 VM 上，依赖一个来自 2019 年、充满诅咒的 Bash 脚本；而 API 服务则运行在 Docker Compose 上，因为没人敢去动它。K8s 强制推行“一种方式部署所有服务”，消除了这种隐蔽的技术债务和配置差异。

2. 标准化的可雇佣知识 (Standardized Knowledge)

K8s 已成为工程界的通用语言（Lingua Franca）。

• 知识显性化：在作者的新公司，入职第一天通过查看 Helm Charts 和 Kube 配置文件，就能在小时内掌握整体架构。知识存储在 YAML 文件中，而非某人的脑海中。
• 降低人员流动风险：如果核心员工离职，继任者无需花费数周时间查阅文档来理解系统如何运行。
• 运维标准化：On-call SRE（站点可靠性工程师）即使从未接触过某个服务，也能凭借对 K8s 通用模式的理解将其恢复上线。相比之下，在每台服务器配置各异的 VM 环境中，很难实现这种跨服务的无缝切换。
  • 注：这一优势的前提是团队没有采用过于 exotic（奇异/非标准）的配置。

3. 可追溯性与合规性 (Traceability)

K8s 天然契合 GitOps 工作流，极大地提升了操作的透明度和合规性。

• 无影子操作：在作者的公司，没人能直接向集群执行 kubectl apply -f。所有变更必须通过 Git 推送 Helm Chart，经过 MR（Merge Request）审批流程，再由 FluxCD 或 ArgoCD 执行实际部署。
• 合规优势：这种全流程的审计追踪使得通过 ISO 等合规认证变得轻而易举。由于 GitOps 与 K8s 的自然结合，这些管理收益几乎是“免费”获得的。

技术取舍与现实

作者指出，许多初创公司虽然使用了 K8s，但其技术需求其实很简单。他们可能根本不会在 Manifests 中使用 topologySpreadConstraints，也不关心 HPA（水平自动伸缩）、Pod 中断预算或节点亲和性规则。他们使用的节点数量与使用 VM 时并无二致。

然而，这些公司愿意支付维护复杂软件栈的成本，以换取组织层面的收益。作者认为这并非不明智的选择，而是 CTOs 对非技术利益的优先考量。

何时不应使用 K8s？

尽管作者认为大多数公司的选择是合理的，但他仍建议大多数公司从不使用 K8s 开始。

• 调试难度：集群在故障时的调试极其困难。在早期阶段，团队应将精力集中在产品上，而非基础设施。
• 应急效率：在向关键客户演示或交付前，如果出现问题，在 VPS 上执行 git pull 是一个完全有效的紧急修复手段。虽然不够优化，但速度快且状态明确。
• 避免过度复杂：在客户电话会议前，花费两小时排查 Pod 为何处于 CrashLoopBackOff 状态是极其糟糕的体验。

近期转变的原因推测

作者对 K8s 为何在最近五年突然取代 VM+systemd 成为主流感到好奇。他推测原因可能包括：

1. 托管服务成熟：EKS、GKE、AKS 等托管 K8s 服务的成熟降低了运维门槛。
2. 人才池翻转：足够多的人学会了 K8s，导致招聘其他技术栈的人才反而变得更难。
3. Helm 的普及：Helm 使得“直接使用现成的 Chart”成为可行选项，降低了起步难度。

作者的建议阈值

作者个人的建议是：当 CTO 不再是公司唯一的工程师时，就是引入 K8s 的时刻。 一旦有第二名工程师加入，K8s 解决的问题就变得真实且紧迫：

• 需要有人部署，但他没有配置服务器。
• 需要完善的访问控制，而不是共享所有服务的 SSH 密钥。
• 员工终将离职，带走所有隐性知识。

此时，系统应当承载知识，而不是依赖个人。

关键要点

• K8s 的普及驱动力已转变：对于大多数非超大规模公司，采用 K8s 主要出于组织管理、标准化和合规性需求，而非单纯的技术扩展性需求。
• 统一性与标准化：K8s 提供了统一的部署标准和通用的技术语言，降低了人员流动带来的知识流失风险，提升了运维团队的通用能力。
• GitOps 与合规：K8s 与 GitOps 工具链（如 ArgoCD, FluxCD）的结合，实现了变更的可追溯性，极大地简化了合规审计流程。
• 早期阶段的陷阱：初创公司或小型团队在早期应避免过早引入 K8s。其调试复杂度高，可能分散团队对核心产品的精力；简单的 VPS 或 Serverless 方案在应急和快速迭代上更具优势。
• 引入时机：当团队规模扩大，出现多人协作、权限管理和知识沉淀需求时，才是引入 K8s 的最佳时机。
• 生态成熟度：托管服务（EKS/GKE/AKS）的成熟、Helm 生态的完善以及开发者技能树的迁移，共同推动了 K8s 成为行业默认标准。

意义与影响

这篇文章揭示了一个重要的行业趋势：基础设施选型正在从“纯技术驱动”向“工程治理驱动”转变。

1. 基础设施即管理工具：Kubernetes 不再仅仅被视为一个容器编排引擎，而是演变为一种工程治理框架。它通过强制标准化、版本控制和自动化部署，解决了软件工程中常见的“配置漂移”、“知识孤岛”和“合规黑洞”问题。
2. 对初创公司的警示：对于初创团队而言，盲目追随技术潮流可能导致“过度工程化”。在团队规模较小、需求不稳定时，简单性（Simplicity）优于复杂性。过早引入 K8s 可能带来不必要的运维负担，阻碍产品迭代速度。
3. 对技术招聘的影响：K8s 已成为事实上的行业标准技能。这不仅改变了招聘要求，也影响了工程师的职业发展路径。掌握 K8s 及其周边生态（Helm, GitOps, Service Mesh）已成为现代后端和 SRE 工程师的核心竞争力。
4. DevOps 文化的深化：文章强调的 GitOps 和标准化部署，反映了 DevOps 文化从“自动化脚本”向“平台工程（Platform Engineering）”的演进。企业开始构建内部开发者平台（IDP），通过标准化的 K8s 抽象层，让开发人员专注于业务逻辑，而非底层基础设施细节。

总之，Kubernetes 的胜利不仅是技术的胜利，更是工程组织方式标准化的胜利。理解这一点，有助于企业在不同发展阶段做出更理性的技术架构决策。