出于撰寫本文的需要，我將介紹Kuma。Kuma是一種建立在Envoy之上的開源解決方案，為微服務和服務網格充當控制平面。它與Kubernetes和虛擬機兼容，可以支持一個集群中的多個網格。

還有其他開源和托管服務網格可供選擇，比如Istio、Linkerd和Kong Mesh。

為什么使用服務網格?

我們使用服務網格的主要目的之一是，在內部pod服務之間獲得相互傳輸層安全(mTLS) 以確保安全。另外，使用服務網格具有諸多好處，因為它允許工作負載在多個Kubernetes集群之間聯系，或者運行連接到Kubernetes的標準裸機應用程序。它提供跟蹤、記錄pod之間的連接，可以將連接端點健康指標輸出到Prometheus。

該圖顯示了在實施服務網格之前工作負載的樣子。在左邊的示例中，團隊花費時間構建管道而不是構建產品或服務，通用功能在服務之間加以復制，存在不一致的安全性和可觀察性實踐，還存在毫無可見性的黑盒實現。

在右邊，在實現服務網格之后，同一個團隊可以致力于構建產品和服務。他們能夠構建可擴展的高效分布式架構，可觀察性在多個平臺上保持一致，更容易實施安全和合規最佳實踐。

Kuma服務網格架構的工作原理

將應用程序pod的套接字通信從明文轉移到mTLS的神奇之處在于Kuma控制平面、邊車(sidecar)和Kuma 容器網絡接口(CNI)。當開發人員合并一些更改、為應用程序添加新服務時，Kuma透明地檢測和注入所需的位，跨自己的網絡數據平面自動代理流量。

Kuma服務網格包括三大組件：

• Kuma CNI：這個CNI插件可以根據注釋來識別帶有邊車的用戶應用程序pod，以設置流量重定向。它在pod生命周期的網絡設置階段完成這項設置，此時每個pod通過名為mutating webhook的進程在Kubernetes中進行調度。
• Kuma-sidecar：它在每個暴露服務的實例上運行。這些服務將所有連接性和可觀察性問題委托給進程外的運行時環境，該運行時環境將位于每個請求的執行路徑上。它代理所有出站連接，并接受所有入站連接。當然，它還會在運行時執行流量策略，比如路由或日志。如果使用這種方法，開發人員不必操心加密連接，可以完全專注于服務和應用程序上。它被稱為邊車代理，因為它是在同一個pod上的服務進程旁邊運行的另一個容器。每個運行的服務實例都會有一個邊車代理實例;又由于所有出入請求及其數據始終通過邊車代理來傳輸，這又叫Kuma數據平面(DP)，因為它位于網絡數據路徑上。
• Kuma控制平面(kuma-cp)：這是一個用GoLang編寫的分布式可執行文件，可以在Kubernetes上運行，頒發數據平面證書，并在Kubernetes API內協調數據平面(DP)狀態。您可以使用Kuma自定義資源定義(CRD)來配置Kuma設置和策略，邊車自動從控制平面獲取更改。

結語

現在的服務網格拓撲結構酷似1990年代和2000年代的企業服務總線(ESB)架構。無需像ESB架構那樣根據業務策略沿路由引導代理流量，有了網格，您可以自由地連接應用程序，網格自上而下管理路由和策略。

在我看來，ESB架構在業界沒有更流行的最大原因是它必須滿足整體式代碼庫需求以及經常遇到的最終的依賴項管理問題。您會有數十個項目共享依賴項以管理ESB上的對象，這成了軟件管理的一大難題。

服務網格技術通過與代碼保持分離來減輕復雜度。它讓開發人員可以將安全性、可靠性和可觀察性的復雜性從應用程序堆棧轉移出來，將其作為基礎設施環境的一部分。

原文標題：??Implementing a Secure Service Mesh??，作者：Jonathan Kelley