Consul 1.13 正式发布，包括这些重大更新

前两天，HashiCorp Consul 1.13 正式发布。此版本帮助组织降低运营复杂性、大规模高效运行 Consul 并将服务网格安全地集成到其应用程序工作流中又迈出的一大步。

Consul 1.13 中的新功能包括 Consul on Kubernetes CNI 插件、用于 Envoy 故障排除的 CLI 增强、Terminating Gateways 的增强和集群对等（测试版）。

Consul on Kubernetes CNI 插件

默认情况下，Kubernetes 上的 Consul 会注入一个 init 容器，consul-connect-inject-init它通过配置 sidecar 代理来设置透明代理流量重定向，以便应用程序可以轻松地在网格内进行通信而无需任何修改。在 pod 中部署 init 容器以设置透明代理需要 pod 具有足够的 Kubernetes RBAC 权限来部署具有CAP_NET_ADMINLinux 功能的容器。但是，对于具有非常严格的安全标准的组织来说，将 pod 配置为以这种升级的权限进行部署是有问题的，因此是网格采用的障碍。

作为 Consul 1.13 版本的一部分，Kubernetes 上的 Consul 现在将分发一个链式 CNI（容器网络接口）插件，用于处理 pod 生命周期网络设置阶段的流量重定向配置。CAP_NET_ADMIN这取代了使用 init 容器应用流量重定向规则的要求，并删除了在将工作负载部署到服务网格时允许特权的任何要求。CNI 插件计划在 consul-k8s ^[1] 0.48.0 中发布，将在 Consul 1.13 中得到支持。

Consul on Kubernetes CLI 增强 Envoy 故障排除

在诊断服务网格中的流量管理问题时，用户通常依靠 Envoy 代理配置来快速识别和解决在将应用程序部署到网格上时出现的配置问题。Kubernetes 上的 Consul 现在提供了额外的 CLI 命令，以通过consul-k8s proxy list和consul-k8s proxy read <pod name>命令快速解决 Envoy 配置问题。

该consul-k8s proxy list命令提供了具有由 Consul 管理的 Envoy 代理的所有 pod 的列表。Pod 和其Type一起列出，这决定了 proxy 是 sidecar 还是作为 Consul 部署的网关的一部分。

Namespace: All Namespaces
 
Namespace Name                                    Type
consul    consul-ingress-gateway-6fb5544485-br6fl Ingress Gateway
consul    consul-ingress-gateway-6fb5544485-m54sp Ingress Gateway
default   backend-658b679b45-d5xlb                Sidecar
default   client-767ccfc8f9-6f6gx                 Sidecar
default   client-767ccfc8f9-f8nsn                 Sidecar
default   client-767ccfc8f9-ggrtx                 Sidecar
default   frontend-676564547c-v2mfq               Sidecar

该consul-k8s proxy read <pod name>命令允许您检查为给定 pod 运行的任何 Envoy 的配置。默认情况下，该命令会列出 Envoy 代理已配置的可用 Envoy 集群、侦听器、端点、路由和 secrets，如下所示：

Envoy configuration for backend-658b679b45-d5xlb in namespace default:
 
==> Clusters (5)
Name                 FQDN                                                                      Endpoints                                                        Type         Last Updated
local_agent          local_agent                                                               192.168.79.187:8502                                              STATIC       2022-05-13T04:22:39.553Z
client               client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul   192.168.18.110:20000, 192.168.52.101:20000, 192.168.65.131:20000 EDS          2022-08-10T12:30:32.326Z
frontend             frontend.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul 192.168.63.120:20000                                             EDS          2022-08-10T12:30:32.233Z
local_app            local_app                                                                 127.0.0.1:8080                                                   STATIC       2022-05-13T04:22:39.655Z
original-destination original-destination                                                                                                                       ORIGINAL_DST 2022-05-13T04:22:39.743Z
 
 
==> Endpoints (6)
Address:Port         Cluster                                                                   Weight Status
192.168.79.187:8502  local_agent                                                               1.00   [32mHEALTHY[0m
192.168.18.110:20000 client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul   1.00   [32mHEALTHY[0m
192.168.52.101:20000 client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul   1.00   [32mHEALTHY[0m
192.168.65.131:20000 client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul   1.00   [32mHEALTHY[0m
192.168.63.120:20000 frontend.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul 1.00   [32mHEALTHY[0m
127.0.0.1:8080       local_app                                                                 1.00   [32mHEALTHY[0m
 
==> Listeners (2)
Name              Address:Port         Direction Filter Chain Match              Filters                                                                      Last Updated
public_listener   192.168.69.179:20000 INBOUND   Any                             * to local_app/                                                              2022-08-10T12:30:47.142Z
outbound_listener 127.0.0.1:15001      OUTBOUND  10.100.134.173/32, 240.0.0.3/32 to client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul   2022-07-18T15:31:03.246Z
                                                 10.100.31.2/32, 240.0.0.5/32    to frontend.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul
                                                 Any                             to original-destination
 
==> Routes (1)
Name            Destination Cluster Last Updated
public_listener local_app/          2022-08-10T12:30:47.141Z
 
==> Secrets (0)
Name Type Last Updated

Terminating Gateways 增强功能

用户希望能够通过 Terminating Gateways 将路由连接到所有外部目的地（即注册到 Consul 的服务和未注册到 Consul 的服务）。目标是为离开其网格的流量建立众所周知的出口点，根据定义的访问策略授权连接，并确保流量在允许其出口服务网格之前满足安全要求。在 1.13 版本中，Consul 的终端网关得到了增强，可以使用透明代理与外部服务通信。

在 Consul 1.13 之前，下游服务可以通过 Terminating Gateways 访问外部服务，方法是通过静态配置的 upstream^[2]公开服务，或者使用透明代理并使用其 Consul 分配的虚拟服务主机名^[3]连接到服务。在某些情况下，可能需要或希望使用其真实主机名（例如www.example.com^[4]）而不是服务网格内部的地址与外部服务进行通信。

Consul 1.13 通过允许管理员创建一个允许的外部主机名或 IP 地址列表来实现与外部服务的无缝通信，这些外部主机名或 IP 地址可以被下游服务访问，并将这些连接汇集到 Terminating Gateways，该网关充当退出流量的中心出口点服务网格。

集群对等（测试版）

在大型企业中，平台团队^[5]的任务通常是为整个组织提供标准的网络解决方案。通常这些团队已经对云提供商和运行时平台做出了自己的选择，但平台团队仍然需要启用安全的跨团队连接。为了使其发挥作用，该组织需要像 Consul 这样的共享网络技术，它可以在任何地方使用。Consul 在 1.13 中通过名为 cluster peering 的新功能增强了其跨团队功能。

集群对等之前

Consul 当前的联合模型基于这样一种理念，即所有Consul 数据中心^[6]（也称为集群）都由一个共同的管理控制来管理。假设安全密钥、策略和升级活动在整个联盟中进行协调。网格配置和服务身份也是全局的，这意味着特定于服务的配置、路由和意图^[7]被假定由同一个团队管理，在所有数据中心都有单一的事实来源。

该模型还需要数据中心之间的全网状网络连接，以及与远程数据中心的相对稳定的连接。如果这与您管理基础设施的方式相匹配，WAN 联合提供了一个相对简单的解决方案：只需少量配置，每个服务都可以跨所有数据中心连接到所有其他服务。

WAN 联合的优点包括：

• 共享密钥
• 协调升级
• 静态主数据中心

然而，许多组织正在将 Consul 部署到由跨不同网络边界的独立团队管理的环境中。这些团队通常需要能够与一些（但不是全部）集群建立服务连接，同时保留操作自主权来定义特定于他们需求的服务网格配置，而不会与联盟中其他集群中定义的配置发生冲突。这突出了 WAN 联合模型中的一些限制：

• 依赖与主数据中心的连接。
• 假设整个联邦的资源相同。
• 难以支持复杂的中心辐射型拓扑。

使用集群对等

通过集群对等，每个集群都是自治的，拥有自己的密钥、目录和访问控制列表 (ACL) 信息。没有主数据中心的概念。

集群管理员明确地与他们需要连接的集群建立关系（或“对等”）。对等集群会自动交换明确向其他对等方公开的服务的相关目录信息。

在 Consul 1.13 的开源版本中，集群对等将使运营商能够在 Consul 数据中心之间建立安全的服务连接，无论网络拓扑或团队所有权是什么样的。

集群对等提供了跨团队、集群和网络边界的任意组合连接服务的灵活性。好处包括：

• 细粒度连接
• 最小耦合
• 运营自主权
• 支持中心辐射型对等关系

集群对等使用户能够跨内部和外部组织边界安全地连接应用程序，同时保持相互 TLS 提供的安全性以及独立服务网格之间的自治。

Consul Enterprise 中的集群对等互连

Admin Partitions 是 Consul 1.11^[8]中引入的一项企业功能，它为不同的团队提供改进的多租户，以便使用单个共享的 Consul 控制平面开发、测试和运行他们的生产服务。Admin Partitions^[9]让您的平台团队可以操作共享服务器以支持多个应用程序团队和集群。但是，Consul 1.11 中的 Admin Partitions 仅支持连接单个区域中相同服务器上的分区。

现在，通过集群对等，分区所有者可以与位于同一 Consul 数据中心或不同区域的集群或分区建立对等。对等关系独立于任何其他团队的分区，即使它们共享相同的 Consul 服务器。

集群对等是 Consul 的一个令人兴奋的新增功能，它使运营商在跨组织边界连接服务方面具有更大的灵活性。

请注意，集群对等并不打算立即取代 WAN 联合。从长远来看，在集群对等互连具有与 WAN 联合的所有特性相同的特性之前，需要额外的功能。如果您已经在使用 WAN 联合，则无需立即将现有集群迁移到集群对等互连。

下一步

HashiCorp Consul 的目标是提供一个企业就绪、一致的控制平面来发现和安全连接任何应用程序。如需更多信息，请访问Consul 文档^[10]。要开始使用 Consul 1.13，请从我们的发布页面下载相应的操作系统二进制文件，或安装支持 Consul 1.13 for Kubernetes 的最新Helm Chart 包^[11]。

原文：

https://www.hashicorp.com/blog/consul-1-13-introduces-cluster-peering

参考资料