为什么从第一天起就应该在Kubernetes上构建应用( 二 )

对云服务的依赖也是如此。你可以在基础设施即服务（IaaS）产品（如Amazon的EC2）之上构建你的新应用程序。或者，你可能开始依赖平台即服务（PaaS）产品，例如Microsoft的AzureSQL 。但是，你是否愿意在现阶段对其背后的云提供商做出长期承诺？如果你还不知道你的旅程会带你去哪里，也许你更愿意保持云无关状态一段时间。
让我们回到基础设施即代码：将诸如Terraform[2]之类的工具投入其中将帮助你在某种程度上保持与云无关。它提供了统一的工具包和配置语言（HCL[3]）来跨不同的云和基础架构提供商管理你的资源。你的应用程序不太可能真正与云无关，但是在这种情况下，你可以像切换家中的互联网或电力供应商一样轻松地切换云提供商。
HashiCorp论坛中有一个关于这个主题的很好的讨论：Terraform真的与云无关吗[4]？正如其中一位评论者指出的那样：
Kubernetes集群是对计算资源进行抽象的一个很好的例子：它在不同平台上有许多托管和自我管理的实现，所有这些实现都提供了一个通用的API和一组通用的功能。
这总结得很好！它仍然不是一个完美的抽象。例如，每个云提供商可能都有自己的自定义方式来实现公共负载均衡器和Kubernetes中的持久卷等内容。公平地说，如果你在Kubernetes上构建应用，你将在一定程度上保持云无关。
你可以轻松地启动新环境-随心所欲！
Kubernetes通常被视为管理生产基础设施的一种方式。但是在StackOverflow ，我们一直在使用它来动态管理我们的测试环境。我们使用Kubernetes来托管我们所谓的PR环境。只需按一下按钮，每个拉取请求都可以在隔离的测试环境中运行：

当我们说“隔离环境”时，我们指的是一切：应用程序本身（包含PR分支中更改的代码）及其自己的SQLServer、Redis、Elasticsearch和额外的服务实例。所有这些都会在几分钟内从头开始启动，并在专用命名空间中的少数容器中运行，同时只为你和任何对你的PR感兴趣的人服务。
这不是我们发明的；其他组织一直在使用这个概念。这个想法是每个代码更改都会通过拉取请求进入像Git这样的版本控制系统。其他开发人员会审查代码，但代码不能说明一切。你希望看到代码的运行情况。通常，你必须在本地下载所有代码，编译并运行它。这可能很简单，但是如果你正在运行一个需要从多个仓库中提取代码的大型应用程序，或者微服务架构，那么你可能会需要几个小时的调试。
让我们更理想一点说，假设你已将一项新功能的所有提交（commits）压缩为一个，并将其作为单个PR提交。将这个PR环境作为一个链接发送到销售或营销部门那里，以便他们可以预览实际运行的功能。如果你的销售团队想要演示具有特定功能或自定义构建的应用程序，那么直接给他们发送PR环境链接。你不必花时间指导技术水平较低的同事完成构建过程。
达到这一点需要大量的基础工作。首先，在WindowsContainers中运行经典的.NETFramework并不是我们真正想要追求的途径。理论上这是可能的——从v1.19开始， Kubernetes就已经提供了Windows支持——但Docker/Kubernetes生态系统实际上更以Linux为中心。幸运的是，我们向.NETCore的迁移已经在进行中，所以我们决定押注Linux容器。
当然，这也带来了一系列挑战。当处理一个已有10多年历史的代码库时，你可能会发现关于它运行的基础架构的假设：硬编码文件路径（包括我们最喜欢的：正斜杠与反斜杠）、服务URL、配置等。但我们最终完成了这个工作，现在我们可以在自动扩展的Kubernetes集群上启动任意数量的StackOverflow、StackExchange网络和Teams产品的测试实例。