这篇文章最初是由newstack发布的。部署容器的学习曲线是陡峭的。大多数组织在投入生产前才开始试验。容器为组织的基础设施（内部或云端）带来的性能、成本和可扩展性优势是不可否认的，这可能就是为什么Gartner的聪明人预测，到2020年，超过50%的全球组织将在生产中运行集装箱化应用程序，而不是更少比今天的百分之二十。并且做好准备，因为一旦一个组织找到了在哪里以及如何最好地部署容器，采用率将以比从物理到虚拟的转变快得多的速度增长。集装箱很容易像野火一样蔓延，因为它们可以在几分钟内弹出，几乎可以立即为客户提供服务。这对于敏捷性和弹性来说非常棒，但是即时的满足感会带来挑战，尤其是在云计算中成本超支的时候。这一切的主角是库伯内特斯。"Kubernetes，这是我的应用程序-现在为我运行它。使用Kubernetes，您可以拥有遗留的应用程序、微服务或功能，跨越一个或多个公共云和prem。听起来很简单，对吗？别这么快！对于前几个应用程序来说，它可能足够简单。然而，随着采用率的增加，管理许多服务的复杂性也随之增加，每个服务的需求都在不断变化。对复杂性有先见之明并了解部署容器的所有层是至关重要的，阿里大数据，快速自助建站，这样您就可以在火花击中您的组织时做好控制野火的准备。为了确保您的服务运行良好，并且平台能够处理快速增长的部署，管理服务级别目标（slo）中的多个维度是必不可少的。这引发了多个问题。工作负载可以扩展，但是如何在CPU或Mem或事务（响应时间、吞吐量）的所有关键维度上优化扩展呢？什么时候，应该水平还是垂直缩放？如果你扩展到一个维度，你会在另一个维度上冒拥塞的风险吗？服务可以依赖于其他服务、数据或接近客户端，那么它们应该在哪里运行-更靠近客户端还是更靠近数据？虽然该平台提供了弹性，但是您是应该扩展您的on-prem集群还是应该突发到云端呢？您如何确定何时可以省钱？这些都是重要的问题。所以，让我们来探讨一下选择。选项1：自动调整工作负载容器编排平台提供自动缩放策略。但是，一个挑战是，您需要确定度量（CPU和内存是默认值）并分别为每个度量值设置一个静态阈值。这种类型的分析需要用户确定阈值，然后手动维护它并分析趋势，以评估阈值是否仍然足够好。这些策略不能水平扩展并假设容器处于资源的最佳配置中。考虑到即使是单个容器也可能被限制在一个维度（如内存），但在另一个维度（如CPU）上过度分配。水平扩展，而不首先调整大小，意味着您传播的配置不能保证性能。首先，最好的操作可能是调整容器的大小，而不是仅仅依赖于水平缩放。任何扩展操作都需要评估节点资源的可用性，如果没有可用的资源，那么系统应该提供更多资源。仅仅管理资源是不够的。您可以围绕事务和响应时间添加自定义度量，但是首先，您需要添加一个解决方案来生成遥测数据（例如服务网格），然后配置Prometheus来收集它。但同样，你正在设法达到一个近视的临界值，而这个临界值并不是动态维持的。一个自我管理的系统应该持续关注工作负载需求，并且在不需要人工干预的情况下，确定是否需要垂直或水平扩展，开始云，返利啦，同时确保您能够适应峰值需求。这需要多维度的分析。即使在工作负载扩展之前，系统也应该确定如何更好地管理不断变化的工作负载需求，以避免由于噪音太大的邻居或节点性能问题而造成的资源拥塞，无论是来自容器的峰值还是来自底层集群中计算或存储的拥塞。为了确保工作负载能够正确访问可用的资源，通过重新调度pods来重新分配工作负载意味着pods可以利用其他兼容节点上的可用资源。您希望高效地使用资源，并且更好地重新分配工作负载应该以释放更大的"块"资源为目标，从而减少处于挂起状态的pod—而不会对性能带来风险。那么，如何知道要移动哪个机架和节点，同时确保不会给您带来风险另一个吊舱？这是多维分析优化重新调度和缩放决策的地方，并使它们具有可操作性，这要归功于第三方调度器与本机调度器交互以执行移动。选项2：自动扩展基础设施在开始采用容器时，通常会过度供应。但是，如果您继续以40%到60%的利用率运行，这将导致浪费资金，因为您没有更好的方法来评估工作负载扩展的影响。另一方面，您希望自动扩展集群，这应该基于您的需求、在环境中看到的增长以及对处于待定状态的pods的了解。智能扩展需要根据底层基础设施的可用性评估需求，如果在公共云中，则根据成本进行评估。一旦您有办法知道其他节点何时应该向外扩展或向内扩展，那么您就需要考虑如何执行该操作。公共云提供了缩放集/缩放组，但阈值只查看节点。使用一致的方法来缩放Kubernetes节点将允许多维分析和一致的执行。我在Turbonomic的团队正在密切关注SIGs集群API（使用MachineSets显示前景）、集群注册表和Multicluster，以期实现这一目标。选项3：多云虽然您可能还没有做到这一点，但集装箱化的Kubernetes工作负载提供了真正的可移植性，并且可以在任何地方运行，允许组织利用不同的基础设施提供商来优化成本和访问其他服务或功能。这需要应用程序服务、体系结构和正确的模式来为多云做好准备。Multicloud给DevOps带来了挑战，即服务的位置和彼此之间的距离是分析中的附加维度。这回避了"下一步是什么"的问题它看起来像是组合服务，它将利用集装箱化的服务和功能，这将进一步推动基于服务级别目标的性能和效率管理的需求。但是，那是另一天的话题。 了解更多关于容器的信息！

，大数据是啥