作者通过求职面试发现，如今几乎所有公司都在使用Kubernetes，而五年前情况并非如此。即使是不需要微服务或大规模的小公司也在采用K8s，主要原因是追求部署方式的统一性，避免不同服务采用不同部署方式的混乱局面。

面试教会我的Kubernetes真谛

最近求职面试时，我发现与五年前相比有个显著变化：现在所有公司都在用Kubernetes。上次求职时情况完全不同，当时企业主要分三类：少数Kubernetes先行者、使用systemd管理虚拟机的主流群体，以及无服务器架构的探索者。

令我惊讶的是，现在连只有10人规模、两个服务的初创公司都在用K8s。通过与CTO们的直接对话，我发现了三个核心原因：

统一部署规范

所有服务采用相同部署方式，避免了"支付服务跑在201年的诡异bash脚本上，而API服务却用Docker Compose"这类混乱局面。

标准化知识体系

K8s已成为行业通用语言。新员工通过查看Helm图表和Kube配置，一小时内就能掌握整个架构。值班SRE即使面对陌生服务也能快速应对，因为所有团队都遵循相同的Kubernetes模式。

完善的追踪机制

通过GitOps工作流（如FluxCD/ArgoCD），所有变更都有迹可循。这种天然与K8s集成的特性，让企业轻松满足ISO认证等合规要求。

深层启示

CTO们看重的其实是非技术优势。他们可能根本用不到拓扑分布约束这类高级功能，但愿意为管理效益承受系统复杂性。不过我认为初创公司应该暂缓采用K8s——当产品还在争取客户时，用VPS快速git pull解决问题可能比排查两小时的CrashLoopBackOff更实际。

转型时机建议

我认为引入K8s的最佳时机是团队扩展到第二名工程师时。这时你需要考虑：部署权限管控、知识传承等问题，正是K8s最能发挥价值的阶段。

（注：原文中关于技术细节的英文术语如topologySpreadConstraints等保留原表述，符合技术类文章惯例）

以下是评论内容的总结，平衡呈现不同观点并保留关键引用：

支持Kubernetes的观点

1. 成熟与普及：Kubernetes已成为行业标准，管理工具（如Helm、托管服务）的成熟使其更易用。

   • "managed kubernetes is a lot better... it became good + convenient" (JohnMakin)
   • "Kubernetes is becoming more the 'Boring Technology'" (mikgp)

2. 开发效率与隔离性：LLM工具简化了YAML编写，本地K8s提供更好的隔离性。

   • "Ask your favorite GPT to generate manifests... it's pretty much free lunch" (xlii)
   • "on local k8s I can spin cluster per workspace" (xlii)

3. 标准化与人才储备：统一的部署方式和广泛的技术社区支持。

   • "Every service deploys the same way... K8s is basically a lingua franca" (nitwit005引用原文)
   • "People were demanding experience with Kubernetes" (nitwit005)

反对或质疑的观点

1. 过度复杂：对小型团队或不复杂需求而言，K8s引入不必要的复杂性。

   • "k8s is such a pain in the ass... a huge amount of complexity" (mikeocool)
   • "mostly engineered to solve problems I don't have" (avhception)

2. 跟风采用：部分公司因技术潮流或招聘需求盲目使用，而非实际需要。

   • "companies follow hype... complexities are added for no reason" (h4kunamata)
   • "resume++... not justification to using it" (mianos)

3. 替代方案：简单场景下，其他工具（如Docker Compose、bash脚本）更合适。

   • "many are happy with monoliths deployed using bash scripts" (FpUser)
   • "a real hole in the market for a simple solution" (mikeocool)

中立/补充观点

1. 技术演进：LLM和托管服务降低了使用门槛，但升级维护负担仍存。

   • "agents are really good at spinning up k8s clusters" (reillyse)
   • "upgrade schedule is exhausting... every 6 months" (JohnMakin)

2. 核心价值：仅需20%核心功能（如Deployment管理），过度扩展会带来问题。

   • "core 20%... is very nice... massive holes of despair" (liampulles)

3. YAML争议：YAML作为配置格式的局限性。

   • "yaml is a terrible format for the knowledge" (aaronbrethorst)

关键分歧点在于：是否值得为标准化和未来扩展性接受K8s的复杂性。支持者强调其成熟生态和工具链，反对者则认为多数场景下是过度设计。