客座文章之前由 Brad Ascar，高级解决方案架构师，在 Carbon Relay 博客上发表
市场数据显示，容器化的采纳是如许迅速，特地是 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 构建人员团队防止上述列出的缺点。应用这些新办法，当他们看到本人曾经胜利建设的货色时，肯定会微笑。咱们将在下一篇文章中探讨这些新办法。请持续关注。
点击浏览网站原文。
CNCF (Cloud Native Computing Foundation)成立于 2015 年 12 月，隶属于 Linux Foundation，是非营利性组织。
CNCF（云原生计算基金会）致力于培养和保护一个厂商中立的开源生态系统，来推广云原生技术。咱们通过将最前沿的模式民主化，让这些翻新为公众所用。扫描二维码关注 CNCF 微信公众号。