展望Azure的Kubernetes容器模式的未来

多年来，Azure不断发展。 首先，它是使用一系列Azure服务的无状态应用程序的主机。 然后，它成为虚拟化基础架构的主机，并得到了用于大数据和存储的云托管工具的支持。 现在，它使用Kubernetes等容器和工具来管理您的代码 ，从而支持云原生的分布式应用程序开发。

在早期的迭代中，Azure不需要太多的新编程技能。 即使作为无状态平台，您也可以使用许多现有的.Net技能来构建和部署应用程序。 但是分布式系统（例如在Kubernetes上运行的系统）却大不相同。 尽管您可以使用始终拥有的相同工具和技术来构建应用，但其基础架构和设计模式却大不相同。

[您准备好入侵容器了吗？ 了解如何使用Kubernetes入门 。 •到底什么是Kubernetes ？ | 通过InfoWorld的云计算新闻通讯了解云计算的最新发展。 ]

Kubernetes项目的原始创始人之一Brendan Burns现在是Azure团队的杰出工程师。 作为该职位的一部分，他正在为基于Kubernetes的应用程序设计一套设计模式，可以帮助架构师和开发人员进入分布式应用程序开发领域，他在O'Reilly的2018 Oscon会议上谈到了这些想法。

容器的模式语言

正如Burns所指出的那样，编程的历史是不断增长的抽象以及引导开发人员的工具和模式之一。 作为一种职业，您已经从原始汇编语言编程到Fortran，再到Donald E. Knuth的开创性著作系列“计算机编程的艺术”，迈出了第一步，然后随着您的应用程序变得越来越大，您增加了面向对象和对设计模式的思考。

现在，您正在使用Azure之类的平台大规模构建分布式系统。 在拥有工具，Kubernetes和容器的同时，您仍然缺少现代的Knuth或Gang of Four 。 那就是Burns的作品（以及即将出版的书）开始发挥作用的地方。 他一直在考虑容器应用程序开发和部署中的重复模式，并且他开始为这些模式中的一些命名。

在Burns的分类法中，部署的基础单元是容器。 容器中运行多少代码无关紧要； 就架构模式而言，其服务端点是定义它的边界。 在Kubernetes模型的基础上，将各个容器分组到Pod中，每个Pod是跨集群和跨云的更高级别的部署点。

单节点模式

最简单的模式集是那些使用单个节点的模式，没有隐式的并行操作。 您的大多数应用程序都在单个容器中运行。 您可以将其视为传统的微服务部署。 容器边界无关紧要，直到您开始使用其他容器扩展应用程序为止

边车模式。 实际上，底层代码甚至不需要进行扩展，因为它只有本地存储和共享存储。 使用Burns所谓的“ sidecar”，您可以获取该代码并通过将另一个容器附加到这些文件上来添加新功能，如他所说的那样“增强和扩展”初始容器。 无需Sidecar即可了解正在扩展的应用程序的任何细节； 它只需要访问其文件，

一个示例是一个容器化的Web服务器，带有一个sidecar日志传送容器，该容器位于其现有日志本地存储和云存储服务之间。 容器中的原始代码不需要与S3存储桶或Azure Blob一起使用-这些API在适当的情况下由sidecar处理。 日志文件已正常写入，并且sidecar将其发送到适当的存储中。

大使模式。 大使模式与此类似，尽管在这里您需要更多有关底层应用程序容器的详细信息。 大使代表世界其他地区的原始应用程序，实现了代理来处理API转换或支持和管理跨分布式存储的分片数据。 与Sidecar不同，大使需要底层应用程序的详细信息才能有效地处理翻译和转换。

适配器模式。 最终的单节点模式是适配器。 像大使一样，这也是微服务与外界之间的联系。 但是，这里是翻译协议的工具。 如果您的代码一直在使用内部API，并且希望将其连接到外部服务，则适配器可以处理这些连接-无论是在服务内还是在服务外。

多节点模式

单节点分布式应用程序模式都相对简单。 他们采用现有的应用程序，并重新调整它们的用途以在更广阔的世界中使用，从而最大程度地减少了您对代码所做的更改。

但是多节点模式更加复杂，并且在您想到分布式系统设计时，您会想到更多。

复制服务模式 。 Burns的第一个多节点模式是一个熟悉的模式：复制服务。 使用负载平衡器，您可以部署同一基础服务的多个副本，并根据需要部署新副本或删除冗余副本。 就像您如何大规模构建和部署高密度Web服务器一样。 它也是通过新一代服务工具（例如Burns 自己的metaparticle.io或Microsoft校友在Pulumi开发的系统）来进行编程服务部署的模型。

通过将服务部署分解为代码，您可以在任意位置部署相同的代码，在不同的Azure区域或跨多个云的任何Kubernetes实例上实例化相同的容器。

分片系统模式 。 更复杂的多节点模式包括分片系统，其中负载平衡器后面的路由服务层将服务状态移交给分片数据存储。 这种方法为复制的系统增加了速度和弹性，并且自身可以被复制多次。

将来都是代码

通过将分布式系统分解为可重复的模式，可以更轻松地了解如何使用编程技术来设计和部署服务。 您可以使用相同的模式来定义用于构建应用程序的微服务，从而为您提供向现有分布式应用程序交付附加功能的快速方法。 然后，您可以使用它们来管理Kubernetes上的编排和管道，将其视为构建代码的层。

我们仍然对云原生应用程序开发采取常规方法，拥有像Burns这样的编纂设计模式集只能简化培训新开发人员以及大规模构建和管理代码的过程。

From: https://www.infoworld.com/article/3294791/a-peek-into-azures-kubernetes-container-pattern-future.html