2026年6月15日发布 我最近在找工作。阅读招聘信息、进行面试、与十几家公司中的工程团队交流。我注意到与五年前我上一次找工作时相比：现在几乎每个人都在使用Kubernetes。我交谈的每一家公司都是如此。上次我找工作时根本不是这样。当时大致可分为三个阵营：少数Kubernetes采纳者、使用systemd的虚拟机/VPS/EC2人群和无服务器（如Lambda、Cloud Run等）的人。这让我感到惊讶，因为我所在的公司确实面临大科技规模的问题，所以K8s对我们来说非常合适。但是，一个有10个人和两个服务的初创公司呢？这些地方都没有进行微服务或任何接近高规模的尝试。所以我问了为什么。剧透：他们对K8s的技术方面并不太关心。为什么？技术面试实际上是问为什么的好地方，特别是当你直接与CTO交谈时。因此，我这样做了。答案在各处基本相同。首先是统一性。每个服务的部署方式相同。没有人秘密知道支付服务运行在某个裸虚拟机上，并且使用的是2019年的诅咒bash脚本，而API则在Docker Compose上，因为没有人碰过它。所有的部署方式都是一样的。其次是共享、可雇佣的知识。K8s现在基本上是通用语。在我目前工作的第一天，我调出了包含Helm图表和Kube配置的代码库，并在一个小时内对整个架构有了清晰的概念。知识在YAML中，而不是困在某个人的脑海里。如果有人离职，他们的替代者不会花三周时间查找文档来弄明白如何运行任何东西。在我当前的公司，值班的SRE即使从未接触过某个服务，也能保持该服务的正常运行。他们了解Kubernetes，而Kubernetes模式对所有团队来说都是相同的。试想一下，若有一堆虚拟机，每个服务的设置都不同，要做到这一点就难了。（警告：当然，如果没有人进行了特殊的设置，这一点是成立的。）第三是可追溯性（无论是否合规）。在我当前的公司，没人可以直接用kubectl apply -f将某个东西直接推到集群。你将Helm图表推到git，有了追踪，有了MR审批流程，然后FluxCD或ArgoCD处理实际的部署。没有任何事情在暗中发生。这与合规性非常匹配：这基本上是我们通过ISO认证的方式。由于GitOps与Kubernetes自然配对，你几乎可以免费获得这一切。我从中获得的启示 我所交谈的CTO并没有做出愚蠢的选择。他们在解决真正的问题。我只专注于技术方面，而Kube对我而言一直是技术问题的技术解决方案。但看起来很多CTO首要关注的是非技术利益。比我想象的要多。他们的技术问题根本不需要它。我敢打赌，你不会在他们的清单中找到任何topologySpreadConstraints，他们并不在意。没有HPA，没有Pod干扰预算，没有节点亲和性规则。节点的数量与他们使用虚拟机时相同。但是，他们愿意为组织利益接受拥有复杂软件的代价。老实说，我认为这大致是可以的。但我仍然认为大多数公司应该先从不使用它开始。当出现问题时，集群确实很难调试，而在那个阶段你希望把精力放在产品上，而不是基础设施上。当你仍在向下一个大客户推销时，启动一个VPS并进行一次脏的git pull是完全有效的应急修复。不理想，当然。但快速，而且你确切知道发生了什么。你真的不想在客户电话前花两个小时弄清楚为什么你的pod在CrashLoopBackOff中卡住了。为什么最近会发生这种变化 我仍然不太明白为什么这种变化在那时发生。五年前，三个阵营都运行良好。现在使用VM+systemd的人群几乎在招聘信息中消失，而无服务器仍然处于小众，K8s则赢得了胜利。我最好的猜测是：管理的K8s（EKS、GKE、AKS）已经成熟，人才库发生了转变：足够多的人学习了它，以至于招聘其他东西变得更加困难。而Helm使得“只需使用其他人的图表”成为一个现实选项。但我并不确定。如果你在这个转变中有更好的理论，我真心想知道。何时使用Kubernetes 我个人的门槛是CTO不再是唯一的工程师。只要第二个人出现，K8s解决的问题就变得真实。现在你有一个没有设置服务器，但需要部署的人。有一个需要适当访问控制的人，而不是所有东西的SSH密钥。还有一个最终会离职并带走他们所有知识的人。那时你希望系统来保存知识，而不是人。