HashiCorp consur允许运营商跨多个云（本地、Google云、Amazon AWS等）以及多个运行时环境（wirtual machines、Kubernetes等）快速连接应用程序。请观看下面的视频以了解这一点的实际效果：»"制作网格"中的"为什么"企业内部的网络越来越复杂。在公共云的增长、Kubernetes的采用以及其他编排和交付平台的发展过程中，组织不得不改变他们处理应用程序和网络的方式。"服务网格"是云计算原生社区中经常谈论的一个短语，通常只关注Kubernetes。在HashiCorp，我们坚信服务网格解决的问题是应该关注的，而不是底层的平台技术。服务网格应该是全局的。它应该能够在您的云环境和运行时（Kubernetes、VM、Nomad等）之间扩展。这种服务网格的"全球"方法需要专注于支持工作流（而不是特定的技术），并使运营商能够解决多云环境中的连接性难题。随着工作负载在环境之间的可移植性越来越高，安全性要求变得越来越重要。零信任网络的基础应该是默认的，工作负载之间的连接都应该用mtl加密。随着网络本身变得更加动态，我们应用于这些环境的安全策略需要改变以适应这种模式。与consur一起，我们经常在从静态到动态的环境中讨论这一点，并使应用程序在网络上成为"一流公民"。在这一点上，仅仅在IP地址之间应用安全性的传统做法是不够的。随着企业将多云作为一种操作模式，他们发现他们使用的网络非常不一致（重叠的IP地址空间、VPN要求、NAT网络、限制性防火墙规则）。我们需要努力使用能够创建支持一致性的模型的平台，并支持支持在这些环境之间迁移工作负载连接的工作流，这是由一个共同的策略决定的。这些工作流还应包括以"服务网格设计模式"的方式扩展现有环境的能力；通过入口和出口功能。最后，所有这些都应该被编码，并且能够作为工件与应用程序代码一起存储。这确保了这些工作负载的未来部署将是一致的。与consur一起，我们经常谈论我们的核心焦点之一是如何使多云网络更容易为运营商服务。consur有很多诀窍可以在多个环境中创建一致的网络，并尽可能为我们的运营商提供"跨云"体验。最终目标是你的环境不应该是孤岛。服务网格应该是全局可见的，并且能够连接任何运行时或云。我们最近写了一篇博客，重点介绍了一个例子，她演示了使用两个Kubernetes集群（googlekubernetes引擎和azurekubernetes服务）并将这些环境连接到一个服务网格中。在执政官，我们称之为联合工作负荷。虽然今天的企业仍然在虚拟机中运行大量的工作负载，但我们也开始看到许多较小的Kubernetes集群的设计模式在这些环境中变得越来越丰富。团队采用Kubernetes，逐步地将工作负载转移到这些环境中。这就形成了一个应用程序经常在不同平台之间拆分的环境，从而为其他安全和应用程序生命周期挑战打开了大门。»了解多云执政官在上面的视频中，我们模拟了企业环境中常见的模型，从运行在虚拟机中的consur集群开始，将多个基于Kubernetes的consur数据中心联合到我们现有的数据中心中。利用我们在Consul 1.8中添加的广域网联盟功能，我们允许运营商通过mesh网关发送所有集群到集群的通信，而不是将所有consur节点暴露给一个或另一个。这种方法大大降低了跨云连接环境的门槛，也减少了这些环境之间专用VPN的需要。因为我们是在服务网格中运行的，所以我们可以保证在我们的工作负载之间端到端的相互TLS（mTLS）。我们还解锁了在这些工作负载之间应用基于意图的安全策略的能力——为零信任网络建立基础。最后，由于这是一个功能齐全的consur集群，我们可以通过启用服务发现、健康检查和网络基础设施自动化等概念来利用传统服务网格之外的功能。这些组合的能力建立了"以应用为中心的网络"的基础，在这里我们把连接应用程序的焦点转移到控制平面上，并将连接看作是应用概念，而不是静态IP到IP模式。»在库伯内特斯部署执政官和赫尔姆在本视频中，我们利用consur Helm图表将consur环境部署到Kubernetes集群上。Helm图表非常灵活，可以支持多种不同的部署模型。例如，利用领事舵图可以自动完成的一些配置如下。。。consur的独立"服务器"群集，默认情况下安全，并启用加密"作为现有客户机部署的群集"在consol中自动引导和配置访问控制列表（acl）自动配置联合多个Kubernetes环境的联邦机密（正如Nicole在我上面提到的她的博客文章中所演示的那样）入口/终端网关的配置网状网关配置在上面的视频中，当联合我们的环境时，我们遵循一个相当可重复的过程。我们在Kubernetes环境中创建联邦机密，其中包括证书颁发机构详细信息、gossip加密密钥和服务器配置详细信息（包括数据中心名称和mesh网关连接信息）我们使用预先配置的舵手清单来部署我们的舵图让我们看看我们用来部署consur环境并将其与基于vSphere的Kubernetes环境联合的清单：全球的：姓名：领事图片：执政官：1.8.0数据中心：humblelab kubetls:启用：真卡塞特：秘书名称：执政官联合会秘书：卡塞特卡基：秘书名称：执政官联合会密件：卡基联邦：启用：真加密：秘书名称：执政官联合会secretKey：gossipEncryptionKey连接件：启用：真网状网关：启用：真副本：1入口通道：启用：真默认值：副本：1服务：类型：负载平衡器服务器：存储：10GistorageClass:default-k8s额外卷数：-类型：秘密名称：领事联合会项目：-密钥：serverConfigJSON路径：配置.json载荷：真在这个配置文件中，我们挂载预先创建的Kubernetes secret作为一个卷供concur pods使用。这个秘密包含了必要的信息，以确保我们的执政官环境之间的安全通信。我们提供一个数据中心名称（在本例中为humblelab kube）、启用联合、我们的服务网格功能、mesh网关和入口网关来提供入站通信。有了这个配置文件（如前所述，创建了我们的秘密），我们可以发出以下命令来部署Helm图表。舵安装-f 1-vsphere-k8s.yaml consur hashicorp/consur在这个命令完成大约5分钟后，环境应该稳定下来，并作为一个联合工作负载集群加入到我们的主数据中心。这个过程可以在其他云环境中重复——如我们的演示视频所示。您可以在下面看到这个联合过程的最终结果»跨云部署工作负载我们还演示了如何部署跨这些云环境的应用程序。当您考虑在环境之间构建故障转移域时，以及考虑环境中应用程序的渐进式交付之类的事情时，这种设计模式就变得至关重要了。在我们的示例中，我们利用下面的清单将前端工作负载部署到基于VMware vSphere的Kubernetes集群中API版本：v1种类：服务帐户元数据：名称：前端---API版本：v1种类：吊舱元数据：名称：应用程序前端注释："consur.hashicorp.com/connect-注入"："true""consur.hashicorp.com/connect-服务端口："80""consur.hashicorp.com/connect-服务上游"："api:5000：埃克斯"标签：应用程序：训练营规格：容器：-名称：前端图片：codydearkland/app-前端：最新端口：-集装箱港口：80serviceAccountName:前端---API版本：v1种类：服务元数据：名称：前端规格：端口：-端口：80协议：TCP目标端口：80选择器：应用程序：训练营类型：负载平衡器在这个部署清单中，您会注意到，我们配置了一个"上游"服务，我们连接到这个服务，这个服务通过端口5000，托管在eks数据中心。虽然这是静态应用的，但我们可以利用流量整形策略在数据中心之间创建动态故障转移。不过，这是另一个故事了。我们可以发布kubectl get服务并连接到我们前端的地址。正如您所知，我们的API和数据库无法连接。这是因为他们还不存在。我们去创造它们吧。对于应用程序的API部分，我们切换到amazoneks集群，并利用以下清单配置第二层API版本：v1种类：服务帐户