在从零开始开发新项目、如一个应用、服务或网站时，核心关注点通常不是如何在高可用网络中实现大规模运行。更多情况下，你会专注于为目标用户打造合适的产品，或寻找市场契合点。如果你在为初创公司开发 MVP，在实现大规模扩展前，必须先完成最小可用产品，否则你在为谁扩展？对于企业级开发者而言，当前要做的事是确保现有业务符合需求。规模化运营往往是明天要面对的挑战。
因此，在选择技术栈时，Kubernetes（通常与大型分布式系统相关）现在可能不是你优先考虑的对象。毕竟，它涉及大量工作量：集群的搭建与运维、应用容器化、服务定义、部署、负载均衡等。早期看来可能有些得不偿失，你的时间更应投入到实际应用的前几次迭代。
回望我们在早期开发 Stack Overflow 的经历，既没有 Docker，也没有 Kubernetes。云计算还处在起步阶段，Argue 与托管服务尚未普及。我们的系统是为特定硬件设计的，许多假设需要在云端迁移和现代化改造。这个过程让我们对容器化与云原生有了新的认知。
如今，若你今天开始构建新应用，认真研究如何从一开始就采用云原生架构并使用 Kubernetes，可能会带来显著的长期收益。设置 Kubernetes 的工作量往往比你想象中要低，而且在后续迁移和扩展时也更省力。
下面给出三个理由，说明从一开始就让应用运行在 Kubernetes 上并非不可取，甚至可能成为加速器。
托管型 Kubernetes 提供了沉重工作的简化
几年前，我们在内部搭建第一套 Kubernetes 集群时，花了将近一周的时间来启动、配置、安装和调试。集群上线后，运维工作仍然不断。托管服务让我们看到了不同的选择：例如，Amazon 的 Elastic Kubernetes Service（EKS）、Microsoft 的 Azure Kubernetes Service（AKS）或 Google 的 Google Kubernetes Engine（GKE）等。它们让你在几分钟内创建集群：在 AKS 上，只需点击几下、填写表单即可。
如果你愿意，仍可一个人完成向向导的持续运行，但不要立即点击“创建”按钮。将配置导出为 ARM/模板并将其纳入源代码控制，便于实现基础设施即代码（IaC）。一旦设置完成，扩容只需增加资源分配，容错、负载均衡、流量分配等问题都已就绪，未来的扩展也更从容。
在云环境中，你可以保持云无关性：通过 Terraform 等工具，用统一的语言和工具在不同云之间管理资源。应用本身并非完全云无关，但你可以让云提供商切换变得更容易，减少对特定平台的长期绑定。
在社区讨论中，关于“是否真的云无关”有不少观点，但结论是 Kubernetes 本身对计算资源的抽象提供了跨平台的一致性。不同云提供商在实现负载均衡、持久卷等方面可能存在差异，但从高层来看，仍然支持跨云的部署能力，这使得在 Kubernetes 上构建应用更具弹性。
你可以更灵活地启动新环境
Kubernetes 常被视为管理生产基础设施的工具，但在实践中，我们也用它来动态管理测试环境。通过 Kubernetes，我们可以在按下按钮后为每个拉取请求创建隔离的测试环境：包含应用程序、数据库、缓存、搜索等服务，独立运行在专用命名空间中，几分钟内从零开始部署，并对特定人员可见。
这种方式的核心理念是：每次代码变更都通过版本控制进入代码库，对同事进行透明的演示与验证。若你需要向销售或市场团队展示功能，直接分享可预览的部署链接即可，避免现场搭建和繁琐的本地依赖。
实现这一点需要一定的工作：例如，确保对旧有架构的假设尽可能地解耦，以及在 Linux 容器中运行核心组件。随着经验积累，我们可以在可扩展的 Kubernetes 集群上启动任意数量的测试实例，覆盖涉及的 Stack Overflow、Stack Exchange 及相关团队产品。
从一开始就使用 Kubernetes 的取舍
在应用早期阶段，快速构建、评估并学习往往比一开始就追求最优架构更重要。容器化与 Kubernetes 能帮助你以更高的速度迭代，并且在需要扩展时提供向前的支持。
那么，你应否从一开始就使用 Kubernetes？答案可能是肯定的，但也取决于你的具体项目、需求和优先级。
如果你一直在说“我们还没有产品市场契合，不需要 Kubernetes”，不妨换个角度思考：也许你需要的是 Kubernetes 来帮助你在还没有成熟产品时就快速试错、获得反馈并缩短路上时间。
