Kubernetes是容器化微服务的圣杯么？

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种无服务器功能是如何执行的，或者只是了解整个应用程序如何为用户提供服务，均可以找到解决方案。