此版本增強了 Consul 中的許多功能，同時添加了 Consul on Kubernetes CNI 插件和集群對等測試版等新功能。

前兩天，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 命令快速解決 Envoy 配置問題。

該consul-k8s proxy list命令提供了具有由 Consul 管理的 Envoy 代理的所有 pod 的列表。Pod 和其Type一起列出，這決定了 proxy 是 sidecar 還是作為 Consul 部署的網關的一部分。

Namespace:AllNamespaces

NamespaceNameType
consulconsul-ingress-gateway-6fb5544485-br6flIngressGateway
consulconsul-ingress-gateway-6fb5544485-m54spIngressGateway
defaultbackend-658b679b45-d5xlbSidecar
defaultclient-767ccfc8f9-6f6gxSidecar
defaultclient-767ccfc8f9-f8nsnSidecar
defaultclient-767ccfc8f9-ggrtxSidecar
defaultfrontend-676564547c-v2mfqSidecar

該consul-k8s proxy read 命令允許您檢查為給定 pod 運行的任何 Envoy 的配置。默認情況下，該命令會列出 Envoy 代理已配置的可用 Envoy 集群、偵聽器、端點、路由和 secrets，如下所示：

Envoyconfigurationforbackend-658b679b45-d5xlbinnamespacedefault:

==>Clusters(5)
NameFQDNEndpointsTypeLastUpdated
local_agentlocal_agent192.168.79.187:8502STATIC2022-05-13T0439.553Z
clientclient.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul192.168.18.110:20000,192.168.52.101:20000,192.168.65.131:20000EDS2022-08-10T1232.326Z
frontendfrontend.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul192.168.63.120:20000EDS2022-08-10T1232.233Z
local_applocal_app127.0.0.1:8080STATIC2022-05-13T0439.655Z
original-destinationoriginal-destinationORIGINAL_DST2022-05-13T0439.743Z


==>Endpoints(6)
Address:PortClusterWeightStatus
192.168.79.187:8502local_agent1.00[32mHEALTHY[0m
192.168.18.110:20000client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul1.00[32mHEALTHY[0m
192.168.52.101:20000client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul1.00[32mHEALTHY[0m
192.168.65.131:20000client.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul1.00[32mHEALTHY[0m
192.168.63.120:20000frontend.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul1.00[32mHEALTHY[0m
127.0.0.1:8080local_app1.00[32mHEALTHY[0m

==>Listeners(2)
NameAddress:PortDirectionFilterChainMatchFiltersLastUpdated
public_listener192.168.69.179:20000INBOUNDAny*tolocal_app/2022-08-10T1247.142Z
outbound_listener127.0.0.1:15001OUTBOUND10.100.134.173/32,240.0.0.3/32toclient.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul2022-07-18T1503.246Z
10.100.31.2/32,240.0.0.5/32tofrontend.default.dc1.internal.bc3815c2-1a0f-f3ff-a2e9-20d791f08d00.consul
Anytooriginal-destination

==>Routes(1)
NameDestinationClusterLastUpdated
public_listenerlocal_app/2022-08-10T1247.141Z

==>Secrets(0)
NameTypeLastUpdated

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 Enterprise 中的集群對等

集群對等是 Consul 的一個令人興奮的新增功能，它使運營商在跨組織邊界連接服務方面具有更大的靈活性。

請注意，集群對等并不打算立即取代 WAN 聯合。從長遠來看，在集群對等互連具有與 WAN 聯合的所有特性相同的特性之前，需要額外的功能。如果您已經在使用 WAN 聯合，則無需立即將現有集群遷移到集群對等互連。

下一步

HashiCorp Consul 的目標是提供一個企業就緒、一致的控制平面來發現和安全連接任何應用程序。如需更多信息，請訪問Consul 文檔[10]。要開始使用 Consul 1.13，請從我們的發布頁面下載相應的操作系統二進制文件，或安裝支持 Consul 1.13 for Kubernetes 的最新Helm Chart 包。