Kubernetesapplications的application服务： 旧事新办

从 VMS VAX 故障排除到编写无服务器微服务还有很长的路要走（尽管随着AWS Lambda在 re:Invent 上宣布支持 COBOL，IT双纽线的第一圈可能已经完成）。

一路走来，很多事情都发生了变化。 我似乎记得能够用 Perl 编写脚本，并且对操作系统感到恼火，因为它会让你将目录更改为不存在的地方（奖励：一旦你到达那里，它会让你创建它）。 现在看来，你在决定解决问题的方法上所花的时间与实际解决问题所花的时间一样多。 这真是太棒了。 所有新玩具给我们带来的架构阵列、开发速度、数字机遇以及开发人员创造力的释放都是伟大的。 无论您站在舞台的哪一侧，开发人员和消费者都在享受更新、更好的应用程序，其速度和功能在不久前还只是科幻小说中的情节。

容器及其警惕的 Kubernetes 监护器就是一个很好的例子。 容器技术毫无疑问是application开发爆炸式增长的关键加速器。

本周，在阳光明媚的西雅图（截至撰写本文当天上午 10:46 [更新 - 下午 1:36 仍然晴朗]），超过 8,000 人聚集在一起讨论、聆听和了解 Kubernetes 和其他开源相关技术。 对话、实践学习和刺激的结合是创新的原汤。 当你阅读这篇文章时，12个伟大的新想法（和37个糟糕的想法）可能已经诞生。

其中一些应用程序将改变生活，一些将创新建筑结构，一些将改进用户界面，一些可能只是另一种方式来说明我与青年文化有多么脱节。

但一些需求会将这些不同的applications及其使用的框架统一起来。 解决方案可能看起来不同，但每个人都需要解决一些关键问题：

规模——如果您想要做大，您就需要能够一路做大（并且可能偶尔再次做大）。

稳定性——所有应用程序都需要适当的稳定性——从“完成舞台演示”到危及生命的正常运行时间要求。

安全性– 坏人是存在的，有时他们会攻击您的applications。 现代系统的复杂性似乎不断扩大您需要担心的攻击面。

可观察性——眼见为实，当出现问题时这一点就显得尤为重要。 快速将正确的信息从 OSI 层传递给正确的人员可以帮助您减少故障、加快恢复，并使“您构建它，您运行它”的世界更加舒适。

这些需求并不是十分独特，但它们仍然是每个精心设计的应用程序需要解决的基本问题，最好是在它们成为问题之前和编写代码之前解决。

我尊敬的雇主F5 Networks已经建立了一个价值数十亿美元的业务来满足这些需求，老实说，我们在这方面做得相当好（但我会这么说）。 我们将为满足这些需求而制作的东西称为application服务。 保护application流量、对其进行检查并引导的application服务。 将客户端路由到正确位置的application服务，提取、转发和显示关键应用遥测的application服务。 这些是让我们客户的applications保持正常运行的核心服务 - 而且无论应用程序在何处或如何创建，它们都是applications持续需要的服务。

将其带回供应商推介？

到目前为止，‘老顽固试图说服我，他的老式技术仍然有意义。’ 好的，这就是它在空中翻转、扭曲并倒置落地的样子。 让我们从最重要的开始： 服务部署的方式。

采用平台和工作实践背后的推动技术之一是以自动化、集成的方式将意图与行动联系起来的系统。 application服务必须是这个链的一部分，这代表着比简单的运行时变化更根本的转变。

有时，需要将服务注入到现有组件中——例如Aspen Mesh为Istio增加的卓越可见性和控制力。 或者， F5 容器连接器等连接工具可以将环境链接到服务，以便在添加或删除 Kubernetes pod 时，可以保护、扩展和观察它们。

理想情况下，创建application服务的代码需要与该application的代码存在于同一个存储库中，并以相同的方式部署。 application服务定义（例如 Webapplication防火墙服务）需要作为代码存在并被视为代码，从而源代码管理中的服务定义更改和提交会产生生产 Webapplication防火墙部署，而无需进一步的人工输入。 据最新消息，Airbnb 的Melaine Cebula在周三的Kubecon主题演讲中详细描述了这一模型，她描述了如何将一个服务的所有组件（包括基础设施定义）保存在一个项目中（以及他们为使应用程序开发人员的生活更轻松而做的其他大约五十件很酷的事情）。

服务实例化的这种变化（加上长长的 IT 票务队列的消失）是戏剧性的和明显的。

第二个变化可能稍微平凡一些，但仍然至关重要。 Kubernetes 和容器的一大亮点是环境之间的可移植性。 您的 Kubernetes 管理的微服务将在受支持的容器引擎所在的任何地方运行（提示：任何地方），并且相同的应用服务也应该在那里，而不是“有点相同”或“以不同的方式使用略有不同的界面执行相同的操作”。 相同。 这意味着我们需要部署的地方数量在不断增加。

与所有当前和潜在的 Kubernetes 部署以相同的方式和在相同的地点工作的需求已成为 F5 的指导原则。

这绝对至关重要，因为我们的客户不仅依靠我们来保持其现有应用程序的可扩展性和安全性，而且还需要知道我们将保护和观察那些被认为是流氓咖啡因分子与幸运的腺苷受体结合、需要午餐后提神作用的应用程序。