今天，考虑在除Kubernetes之外的任何东西上运行微服务几乎是亵渎神明的。但在2016年，当我们第一次开始微服务之旅时，Kubernetes并没有现在这样的成熟度。那时，我们只想从将我们的单一应用程序分解成松散耦合的服务中获益。像大多数组织一样，巨石集团尽其所能为我们服务。但当Docker使集装箱变得容易时，一个全新的世界打开了。当时，docker compose是启动一组容器化应用程序服务的最简单方法，但接下来要考虑的是编排这些容器。我们很快发现docker compose不允许跨集群节点轻松地分发和编排组件。多节点联网和跨节点共享存储也存在挑战。然后库伯内特斯出现了。问题：我们如何在Kubernetes上运行一个在Kubernetes出现之前就开始构建的应用程序？技术领域变化迅速。随着多年的应用程序现代化进程，您必须适应这一点，这正是您必须做的，以充分利用现有的应用程序。Kubernetes为集群中的共享网络和共享存储提供了多节点容器编排和抽象。首先，我们使用kompose将docker compose yams文件转换为kubernetes部署，但是它创建的静态yams文件并不便于部署和配置应用程序，我们希望能够使用不同的容器限制、不同的容器标签和静态yaml文件，每次更改都必须单独编辑它们。解决方案：使用Helm图表模板化您的应用程序部署。Helm图表提供了一种简单的方法来模板化应用程序部署。它使告诉Kubernetes如何建立网络和存储、如何创建容器、什么类型的容器等变得更加容易。而且，一旦部署，就让库伯内特斯去做它该做的事情。因此，我们将应用程序配置转换为主图表，从而驱动全局配置。为了管理必需和可选的依赖关系，我们将每个组件转换为一个依赖子图使用Helm，可以使用主Helm图表（Helm install xl）轻松部署整个应用程序，并使用值为特定环境启用或禁用依赖关系。helm图表中的全局值可以驱动应用程序的版本控制、部署源和其他全局配置，例如在子组件中启用/禁用java调试选项。这些子图可以分别为它们的资源分配配置（请参阅我之前关于使用cgroup memory limit for max java heap size）和水平伸缩的文章。作为参考，请查看在GitHub上安装t8c。XL主图表具有强制和可选的子图表依赖项：基本组件，提供监视、日志记录、持久性探测，提供调解平台组件，为创建和维护公共抽象和公共分析提供公共服务。结果：我们的模板化应用程序部署可以快速启动Kubernetes上的微服务。你好，可伸缩性。将应用程序重新设计为微服务是一回事。完全是另一回事。仅仅考虑特性和功能是不够的。我们必须构建可伸缩性，利用Helm图表来配置和模板，以实现更无缝的部署，这是一件好事。当然，还有安全性，正如我在前一篇博客文章中所讨论的，我们使用Red Hat Universal Base Image来保护我们的容器在不断变化的云原生环境中导航是一个挑战，但也是一个有趣的挑战。现在，如果我们有办法确保我们的微服务应用程序在任何云或基础设施上一直运行在Kubernetes上的性能就好了。;-)