导语

Kubernetes已成为山丘之王。开源技术Kubernetes以及随后的发行版正以超快的速度让人们爱上容器技术，并且开始夺回对容器化环境的控制权。不幸的是，编排容器只是战斗进行了一半。

正文

云服务提供商接连宣布他们的编排选择是Kubernetes私有发行版：Red Hat OpenShift（和CoreOS Tectonic），IBM Cloud，Microsoft Azure，VMware，Pivotal Container Service，Oracle Cloud，Google Kubernetes Engine，当然还有亚马逊网络服务。他们都创建了自己的Kubernetes发行版，并在其上标准化了编排流程。

最后，有一种标准方法可以控制半序混乱状态，即容器化应用程序基础架构。现在，我们有一种方法来了解何时需要容器资源，以及何时释放。

编排擅长将已知资源集带入系统，观察正在使用的资源，并据此做出基础架构/容器部署决策。使用K8s编排管理容器时，有两个问题：

一是它只能根据系统所知做出决策，二是它没有将应用程序性能纳入决策过程。

没有数据，您的分析工具将失去用处。实际上，互联网上充斥着借助数据以供分析的问题的文章。但我们要更进一步。Kubernetes（或任何编排）的最大问题是丢失了一些数据，有时丢失数据与数据错误一样有害。

这使我们从上面回到了第二个问题：应用程序性能。当然，在过去20年中，应用程序性能几乎是所有基础架构/平台管理系统中的一个大漏洞。这就是存在应用程序性能管理（APM）行业的原因：因为J2EE中间件平台对生产应用程序的可见性为零。

尝试在没有应用程序性能信息的情况下管理应用程序基础结构，就像在不了解飓风是出现在非洲还是欧洲的情况下评估风的平均风速。

随着时间的流逝，经过调整的平台和新的APM工具应运而生，以应对下一代应用程序技术以及每种应用程序提出的独特可见性挑战。

容器没有什么不同，因为即使是新的APM供应商，流行工具也无法从那些老旧的容器中执行其监控功能。

然后，我们进行了编排，在他们之上又放了一层！

因此，第一和第二问题并存。因为在没有应用程序性能信息的情况下，精心设计的应用程序环境可能会陷入困境，仅仅是因为它没有更好的了解。那时，丢失的数据让剩余的数据也成为垃圾。

结果是，在您的客户/最终用户受到服务影响的同时，所有指示灯都呈绿色点亮，这在IT操作中非常常见。

开发人员对他们的应用程序进行检测以使其可观察，使用自动插入监视以提供可见性的工具。

重要的是，您了解了应用程序性能，或更具体地说，是通过应用程序向用户提供的服务的性能，但需要确保您有一种方法来获取性能信息和业务流程信息并将它们结合起来（从数据管理的角度来看，它们是相互关联的），以便您可以根据服务水平制定业务流程决策，而且可以看到何时不提供应用程序，即使业务流程引擎认为一切正常。

随着应用程序平台和技术的不断发展，确定如何获得性能可见性的艰巨任务是艰巨的。像以前一样-首先使用J2EE，然后使用SOA，现在使用微服务工具和解决方案应运而生，以帮助查看内部应用程序并解决问题。

无论您是要弄清楚如何协调1，000个容器，还是要了解环境中的25种无服务器功能是如何执行的，或者只是了解整个应用程序如何为用户提供服务，都可以找到解决方案。