還有其他開源和托管服務網(wǎng)格可供選擇，比如Istio、Linkerd和KongMesh。
為什么使用服務網(wǎng)格?
我們使用服務網(wǎng)格的主要目的之一是，在內(nèi)部pod服務之間獲得相互傳輸層安全(mTLS)以確保安全。另外，使用服務網(wǎng)格具有諸多好處，因為它允許工作負載在多個Kubernetes集群之間聯(lián)系，或者運行連接到Kubernetes的標準裸機應用程序。它提供跟蹤、記錄pod之間的連接，可以將連接端點健康指標輸出到Prometheus。
該圖顯示了在實施服務網(wǎng)格之前工作負載的樣子。在左邊的示例中，團隊花費時間構(gòu)建管道而不是構(gòu)建產(chǎn)品或服務，通用功能在服務之間加以復制，存在不一致的安全性和可觀察性實踐，還存在毫無可見性的黑盒實現(xiàn)。
在右邊，在實現(xiàn)服務網(wǎng)格之后，同一個團隊可以致力于構(gòu)建產(chǎn)品和服務。他們能夠構(gòu)建可擴展的高效分布式架構(gòu)，可觀察性在多個平臺上保持一致，更容易實施安全和合規(guī)最佳實踐。
Kuma服務網(wǎng)格架構(gòu)的工作原理
將應用程序pod的套接字通信從明文轉(zhuǎn)移到mTLS的神奇之處在于Kuma控制平面、邊車(sidecar)和Kuma容器網(wǎng)絡接口(CNI)。當開發(fā)人員合并一些更改、為應用程序添加新服務時，Kuma透明地檢測和注入所需的位，跨自己的網(wǎng)絡數(shù)據(jù)平面自動代理流量。
Kuma服務網(wǎng)格包括三大組件：
KumaCNI：這個CNI插件可以根據(jù)注釋來識別帶有邊車的用戶應用程序pod，以設置流量重定向。它在pod生命周期的網(wǎng)絡設置階段完成這項設置，此時每個pod通過名為mutatingwebhook的進程在Kubernetes中進行調(diào)度。
Kuma-sidecar：它在每個暴露服務的實例上運行。這些服務將所有連接性和可觀察性問題委托給進程外的運行時環(huán)境，該運行時環(huán)境將位于每個請求的執(zhí)行路徑上。它代理所有出站連接，并接受所有入站連接。當然，它還會在運行時執(zhí)行流量策略，比如路由或日志。如果使用這種方法，開發(fā)人員不必操心加密連接，可以完全專注于服務和應用程序上。它被稱為邊車代理，因為它是在同一個pod上的服務進程旁邊運行的另一個容器。每個運行的服務實例都會有一個邊車代理實例;又由于所有出入請求及其數(shù)據(jù)始終通過邊車代理來傳輸，這又叫Kuma數(shù)據(jù)平面(DP)，因為它位于網(wǎng)絡數(shù)據(jù)路徑上。
Kuma控制平面(kuma-cp)：這是一個用GoLang編寫的分布式可執(zhí)行文件，可以在Kubernetes上運行，頒發(fā)數(shù)據(jù)平面證書，并在KubernetesAPI內(nèi)協(xié)調(diào)數(shù)據(jù)平面(DP)狀態(tài)。您可以使用Kuma自定義資源定義(CRD)來配置Kuma設置和策略，邊車自動從控制平面獲取更改。
結(jié)語
現(xiàn)在的服務網(wǎng)格拓撲結(jié)構(gòu)酷似1990年代和2000年代的企業(yè)服務總線(ESB)架構(gòu)。無需像ESB架構(gòu)那樣根據(jù)業(yè)務策略沿路由引導代理流量，有了網(wǎng)格，您可以自由地連接應用程序，網(wǎng)格自上而下管理路由和策略。
在我看來，ESB架構(gòu)在業(yè)界沒有更流行的最大原因是它必須滿足整體式代碼庫需求以及經(jīng)常遇到的最終的依賴項管理問題。您會有數(shù)十個項目共享依賴項以管理ESB上的對象，這成了軟件管理的一大難題。
服務網(wǎng)格技術(shù)通過與代碼保持分離來減輕復雜度。它讓開發(fā)人員可以將安全性、可靠性和可觀察性的復雜性從應用程序堆棧轉(zhuǎn)移出來，將其作為基礎設施環(huán)境的一部分。
原文標題：??ImplementingaSecureServiceMesh??，作者：JonathanKelley
