使用Kubernetes来构建：克服新的建筑成本

客座文章之前由Brad Ascar，高级解决方案架构师，在Carbon Relay博客上发表

https://www.carbonrelay.com/blog/building-with-kubernetes-overcoming-the-cost-of-new-construction/

市场数据显示，容器化的采用是多么迅速，特别是Kubernetes在企业中的增长。例如，CNCF最近的一项调查显示，84%的企业IT受访者表示，他们在生产中运行容器，其中大部分（78%）引用Kubernetes作为编排系统。

换句话说，容器和Kubernetes已经成为主流。

这意味着许多企业IT和DevOps团队都在使用这项相当新的技术（它只有6年的历史），作为他们为云原生世界重建遗留IT环境的关键部分。

有很多新的IT“建筑”是由相对缺乏经验的工作人员使用新材料和新技术建造的。

然而，正如每一个建筑监理和贸易人员都知道的那样，处理新“东西”自然会带来一些问题和挑战。

这些Kubernetes构建人员遇到的一些常见问题是什么？以下是我们在该领域看到的或在行业内听到的一些重点。

新技术，缺乏经验

Kubernetes的新面孔，加上它的迅速普及，导致了技术上的差距。在这项技术上有丰富经验的人很难找到和招聘，雇佣成本也很高。根据Enterprise Project，Kubernetes的工作在全国的平均工资接近14.5万美元。

因此，一些企业急于向前发展，把那些本来很有成就的人放在上面，以为他们会解决。这就像让一个木匠学徒来搭建整个房子。这是一种糟糕的开始方式，即使最终获得了可接受的结果，在此过程中也肯定会出现问题。

陌生景观

Kubernetes承诺在更少的基础设施和更低的成本下实现更大的业务敏捷性和响应能力。通常从一个应用程序开始，企业团队面临将其转换为完全不同东西的艰巨任务。在许多情况下，它们采用一个具有单体设计的应用程序（在预先配置的数据中心的专用硬件上的虚拟机中运行的统一堆栈），并将其分解为微服务集合，通过云从一系列不同的来源进行配置。

虽然新的微服务和容器化方法很复杂，但大多数企业团队都有能力建立一个Kubernetes集群，并在其上运行一个应用程序。让这个应用程序可靠地运行，然后优化，这才是真正的挑战。

过度配置

现在很多公司都在发生这样的事情。他们的团队已经使用Kubernetes，建立集群，他们已经将大型应用分解成许多小块，这些小块是他们从云中的不同来源收集来的。他们的第一个K8s应用程序已经启动并运行。然后，他们试图通过更改设置来对其进行一些调整，然后，砰的一声！应用崩溃。或者，它们没有更改任何默认值，而较大的负载或系统上的其他压力导致系统出现故障。

虽然他们不知道为什么这个应用程序在1g的情况下会崩溃，但他们意识到在1.5g的情况下崩溃的几率会小一些。所以，他们尝试了2g，它在大部分时间似乎运行正常。但是“ok”并不能解决问题。为了降低应用程序的风险，避免停机和凌晨3点的紧急呼叫，他们将配置提升到4g。

结果呢？一个应用程序，如果正确配置，可能在最高250mb的情况下可靠地运行，则有375%的过载。当第二个、第三个、第四个或第100个应用程序被容器化时，同样的过度配置发生时，问题随之而来。在某个时候，系统会崩溃，应用程序会崩溃，风险会变成实际的操作和声誉损害。当云资源消耗的指数级增长反映在云服务提供商的每月账单上时，这种伤害就更大了。

虽然这些团队可能减少了必须购买和管理的基础设施的数量，并提高了业务敏捷性，但其成本往往是其老式本地硬件和vm成本的好几倍。

玩“打地鼠”式的设置

在Kubernetes清单中，IT团队可以操作两个主要的设置，并且只针对两种资源类型。有一些针对资源请求和资源限制的设置，它们应用于CPU和内存资源。再加上replicaset和自动缩放选项等概念，就会有许多可移动的部分。应用程序是scale-up，还是scale-out？哪种方式更经济实惠？

初始设置可能在一段时间内工作良好，即使它们在错误的地方开始，并且现在正在测量错误的事情，或错误的方式运行正确的事情。但是，随着水平扩展部署和新的集群上线，以及具有非常不同行为的新应用程序被加入其中，事情可能会出错。由于初始设置不再有效，IT团队希望调整它们。

这就是“打地鼠”游戏的开始。缺乏对设置更改的影响的可见性，将这个过程变成了危险的猜测。也许更重要的是，它消耗了开发人员昂贵的时间。

应用程序参数使事情进一步复杂化

尽管针对Kubernetes的部署设计明显不同，应用程序仍然有可调参数，团队可以对其进行修改和更改。例如，对于一个简单的数据库，团队可以设置内存和页面缓存资源的级别、数据在写入磁盘之前在内存中存在多长时间的时间段，以及允许运行多少个副本。

另一个例子是Java应用程序，其中有许多JVM设置需要设置和调优，比如堆大小和垃圾收集参数，这些设置对性能有很大影响。

应用程序可能成为“噪音邻居”，并开始影响其他应用程序的性能。在多层环境中部署时，在第一层调优参数通常相对容易，风险也低，但在第二层和第三层，难度和风险显著增加。

简而言之，Kubernetes中允许的最小设置，加上应用程序“堆栈”的不同层上不同的可调参数，使得实现Kubernetes应用程序的性能和成本非常困难。

总结

这并不是说IT团队最终不能得到他们需要的答案。而是说这是一项困难、乏味、有风险的工作，而且他们需要快速解决变化。因此，就像由木匠、水管工和电工组成的建筑工人一样，这些企业团队所从事的工作需要艰苦、乏味、有时还有风险。他们正在做的IT工作相当于建造一个新的结构--移动和准备材料，初步确定新结构，并完成最后的工作。

然而，有一些新的、聪明的方法可以确保你的IT构建人员团队避免上述列出的缺陷。使用这些新方法，当他们看到自己已经成功建立的东西时，一定会微笑。我们将在下一篇文章中探讨这些新方法。请继续关注。