[[405370]]

Linkerd 提供了許多功能，如：自動 mTLS、自動代理注入、分布式追蹤、故障注入、高可用性、HTTP/2 和 gRPC 代理、負(fù)載均衡、多集群通信、重試和超時、遙測和監(jiān)控、流量拆分(金絲雀、藍(lán)/綠部署)等。

Linkerd 2.10 中文手冊持續(xù)修正更新中：

• https://linkerd.hacker-linner.com/

Linkerd 2.10 系列

• 快速上手 Linkerd v2 Service Mesh(服務(wù)網(wǎng)格)
• 騰訊云 K8S 集群實戰(zhàn) Service Mesh—Linkerd2 & Traefik2 部署 emojivoto 應(yīng)用

功能概述

• 自動 mTLS：Linkerd 自動為網(wǎng)格應(yīng)用程序之間的所有通信啟用相互傳輸層安全性 (TLS)。
• 自動代理注入：Linkerd 會自動將數(shù)據(jù)平面代理注入到基于 annotations 的 pod 中。
• 容器網(wǎng)絡(luò)接口插件：Linkerd 能被配置去運行一個 CNI 插件，該插件自動重寫每個 pod 的 iptables 規(guī)則。
• 儀表板和 Grafana：Linkerd 提供了一個 Web 儀表板，以及預(yù)配置的 Grafana 儀表板。
• 分布式追蹤：您可以在 Linkerd 中啟用分布式跟蹤支持。
• 故障注入：Linkerd 提供了以編程方式將故障注入服務(wù)的機制。
• 高可用性：Linkerd 控制平面可以在高可用性 (HA) 模式下運行。
• HTTP、HTTP/2 和 gRPC 代理：Linkerd 將自動為 HTTP、HTTP/2 和 gRPC 連接啟用高級功能(包括指標(biāo)、負(fù)載平衡、重試等)。
• Ingress：Linkerd 可以與您選擇的 ingress controller 一起工作。
• 負(fù)載均衡：Linkerd 會自動對 HTTP、HTTP/2 和 gRPC 連接上所有目標(biāo)端點的請求進(jìn)行負(fù)載平衡。
• 多集群通信：Linkerd 可以透明且安全地連接運行在不同集群中的服務(wù)。
• 重試和超時：Linkerd 可以執(zhí)行特定于服務(wù)的重試和超時。
• 服務(wù)配置文件：Linkerd 的服務(wù)配置文件支持每條路由指標(biāo)以及重試和超時。
• TCP 代理和協(xié)議檢測：Linkerd 能夠代理所有 TCP 流量，包括 TLS 連接、WebSockets 和 HTTP 隧道。
• 遙測和監(jiān)控：Linkerd 會自動從所有通過它發(fā)送流量的服務(wù)收集指標(biāo)。
• 流量拆分(金絲雀、藍(lán)/綠部署)：Linkerd 可以動態(tài)地將一部分流量發(fā)送到不同的服務(wù)。

HTTP、HTTP/2 和 gRPC 代理

Linkerd 可以代理所有 TCP 連接，并將自動為 HTTP、HTTP/2 和 gRPC 連接 啟用高級功能(包括指標(biāo)、負(fù)載平衡、重試等)。

• 由于早期版本中的 bug，使用 grpc-go 的 gRPC 應(yīng)用程序必須使用 1.3 或更高版本。
• 由于早期版本中的 bug，使用 @grpc/grpc-js 的 gRPC 應(yīng)用程序必須使用 1.1.0 或更高版本。

TCP 代理和協(xié)議檢測

Linkerd 能夠代理所有 TCP 流量，包括 TLS 連接、WebSockets 和 HTTP 隧道。

大多數(shù)情況下，Linkerd 無需配置即可完成此操作。為此，Linkerd 執(zhí)行 protocol detection(協(xié)議檢測) 以確定 流量是 HTTP 還是 HTTP/2(包括 gRPC)。如果 Linkerd 檢測到連接 是 HTTP 或 HTTP/2，Linkerd 將自動提供 HTTP 級別的指標(biāo)(metrics)和路由(routing)。

如果 Linkerd 不能確定連接是使用 HTTP 還是 HTTP/2， Linkerd 會將連接代理為普通 TCP 連接， 應(yīng)用 mTLS 并像往常一樣提供字節(jié)級指標(biāo)(byte-level metrics)。

客戶端啟動的 HTTPS(Client-initiated HTTPS) 將被視為 TCP，而不是 HTTP， 因為 Linkerd 將無法觀察連接上的 HTTP 事務(wù)。

配置協(xié)議檢測

在某些情況下，Linkerd 的協(xié)議檢測無法運行， 因為它沒有提供足夠的客戶端數(shù)據(jù)。這可能會導(dǎo)致創(chuàng)建連接延遲 10 秒， 因為協(xié)議檢測代碼會等待更多數(shù)據(jù)。在使用“服務(wù)器優(yōu)先(server-speaks-first)”協(xié)議或服務(wù)器 在客戶端發(fā)送數(shù)據(jù)之前發(fā)送數(shù)據(jù)的協(xié)議時，經(jīng)常會遇到這種情況 ， 可以通過為 Linkerd 提供一些額外的配置來避免。

不管底層協(xié)議是什么，客戶端發(fā)起的 TLS 連接不需要任何額外的配置， 因為 TLS 本身是一個客戶端優(yōu)先協(xié)議(client-speaks-first)。

配置協(xié)議檢測有兩種基本機制：不透明端口(opaque ports)和跳過端口(skip ports)。將端口標(biāo)記為不透明(opaque)會指示 Linkerd 將連接代理為 TCP 流，而不是嘗試協(xié)議檢測。將端口標(biāo)記為跳過(skip)會完全繞過代理。不透明端口通常是首選(因為 Linkerd 可以提供 mTLS、TCP 級別的指標(biāo)等)， 但至關(guān)重要的是，不透明端口只能用于集群內(nèi)部的服務(wù)。

默認(rèn)情況下，Linkerd 會自動將一些端口標(biāo)記為不透明， 包括 SMTP、MySQL、PostgresQL 和 Memcache 的默認(rèn)端口。使用這些協(xié)議、使用默認(rèn)端口且位于集群內(nèi)部的服務(wù)不需要進(jìn)一步配置。

下表總結(jié)了一些常見的 server-speaks-first 協(xié)議以及處理它們所需的配置。“on-cluster config” 列指的是 destination 在同一個集群時的配置;當(dāng)目的地在集群外部時，“集群外配置(off-cluster config)”。

* 如果使用標(biāo)準(zhǔn)端口，則無需配置。如果使用非標(biāo)準(zhǔn)端口，則必須將該端口標(biāo)記為不透明(opaque)。

將端口標(biāo)記為不透明

您可以使用 config.linkerd.io/opaque-ports 注釋將端口標(biāo)記為不透明。這指示 Linkerd 跳過該端口的協(xié)議檢測。

可以在工作負(fù)載(workload)、服務(wù)(service)或 命名空間(namespace)上設(shè)置此注釋。在工作負(fù)載上設(shè)置它會告訴該工作負(fù)載的 被 mesh 的客戶端(meshed clients)跳過與工作負(fù)載建立的連接的協(xié)議檢測， 并告訴 Linkerd 在反向代理(reverse-proxying)傳入連接時跳過協(xié)議檢測。在服務(wù)上設(shè)置它會告訴被 mesh 的客戶端(meshed clients)在代理連接到服務(wù)時跳過協(xié)議檢測。在命名空間上設(shè)置它會將此行為應(yīng)用于該命名空間中的所有服務(wù)和工作負(fù)載。

由于此 annotation 通知被 mesh 的 clients 的行為， 因此它可以應(yīng)用于使用服務(wù)器優(yōu)先(server-speaks-first)協(xié)議的服務(wù)，即使服務(wù)本身沒有被網(wǎng)格。

可以在運行 linkerd inject 時使用 --opaque-ports 標(biāo)志來 設(shè)置 opaque-ports annotation。例如，對于運行在集群上的 MySQL 數(shù)據(jù)庫使用 非標(biāo)準(zhǔn)端口 4406，您可以使用以下命令：

linkerd inject mysql-deployment.yml --opaque-ports=4406 \ 
  | kubectl apply -f - 
 linkerd inject mysql-service.yml --opaque-ports=4406 \ 
  | kubectl apply -f - 

可以以逗號分隔的字符串形式提供多個端口。您提供的值將替換而不是增加不透明端口的默認(rèn)列表。

跳過代理

有時需要完全繞過代理。例如，當(dāng)連接到集群外的 server-speaks-first 目的地時， 沒有可以設(shè)置 config.linkerd.io/opaque-ports annotation 的服務(wù)資源。

在這種情況下，您可以在運行 linkerd inject 時 使用 --skip-outbound-ports 標(biāo)志來配置資源以在 發(fā)送到這些端口時完全繞過代理。(類似地，--skip-inbound-ports 標(biāo)志將 配置資源以繞過代理以連接到這些端口的傳入連接。)

跳過代理對于這些情況以及診斷問題很有用，但除此之外幾乎沒有必要。

與不透明端口一樣，可以以逗號分隔的字符串形式提供多個跳過端口。

重試和超時

自動重試是服務(wù)網(wǎng)格用于優(yōu)雅地處理部分或瞬時應(yīng)用程序故障的最強大和最有用的機制之一。如果實施不當(dāng)，重試可能會將小錯誤放大為系統(tǒng)范圍的中斷。出于這個原因，我們確保它們的實施方式可以提高系統(tǒng)的可靠性，同時限制風(fēng)險。

超時與重試密切相關(guān)。一旦請求被重試一定次數(shù)， 限制客戶端在完全放棄之前等待的總時間就變得很重要。想象多次重試迫使客戶端等待 10 秒。

服務(wù)配置文件可以將某些路由定義為可重試或指定路由超時。這將導(dǎo)致 Linkerd 代理在調(diào)用該服務(wù)時執(zhí)行適當(dāng)?shù)闹卦嚮虺瑫r。重試和超時總是在 outbound (client) 端執(zhí)行。

如果使用無頭服務(wù)(headless services)，則無法檢索服務(wù)配置文件(service profiles)。Linkerd 根據(jù)目標(biāo) IP 地址讀取服務(wù)發(fā)現(xiàn)信息， 如果這恰好是 pod IP 地址，則它無法判斷 pod 屬于哪個服務(wù)。

重試如何出錯

傳統(tǒng)上，在執(zhí)行重試時，您必須在放棄之前指定最大重試次數(shù)。不幸的是，以這種方式配置重試有兩個主要問題。

選擇最大重試次數(shù)是一個猜謎游戲

你需要選擇一個足夠高的數(shù)字來產(chǎn)生影響;允許多次重試通常是謹(jǐn)慎的，如果您的服務(wù)不太可靠，您可能希望允許多次重試。另一方面，允許過多的重試嘗試會在系統(tǒng)上產(chǎn)生大量額外的請求和額外的負(fù)載。執(zhí)行大量重試也會嚴(yán)重增加需要重試的請求的延遲。在實踐中，您通常會從一頂帽子中選擇一個最大的重試次數(shù)(3?)， 然后通過反復(fù)試驗來調(diào)整它，直到系統(tǒng)大致按照您希望的方式運行。

以這種方式配置的系統(tǒng)容易受到重試風(fēng)暴的攻擊

當(dāng)一項服務(wù)啟動(出于任何原因)遇到比正常故障率更高的故障率時， retry storm 就開始了。這會導(dǎo)致其客戶端重試那些失敗的請求。重試帶來的額外負(fù)載會導(dǎo)致服務(wù)進(jìn)一步減慢速度并導(dǎo)致更多請求失敗， 從而觸發(fā)更多重試。如果將每個客戶端配置為最多重試 3 次， 則發(fā)送的請求數(shù)量可能會增加四倍!更糟糕的是， 如果任何客戶端的客戶端配置了重試，重試次數(shù)就會成倍增加， 并且可以將少量錯誤變成自我造成的拒絕服務(wù)攻擊。

重試預(yù)算來救援

為了避免重試風(fēng)暴和任意重試次數(shù)的問題，使用重試預(yù)算配置重試。Linkerd 不是為每個請求指定固定的最大重試次數(shù)， 而是跟蹤常規(guī)請求和重試之間的比率，并將此數(shù)量保持在可配置的限制以下。例如，您可以指定您希望重試最多增加 20% 的請求。Linkerd 將在保持該比率的同時盡可能多地重試。

配置重試總是在提高成功率和不給系統(tǒng)增加太多額外負(fù)載之間進(jìn)行權(quán)衡。重試預(yù)算通過讓您指定系統(tǒng)愿意從重試中接受多少額外負(fù)載來明確權(quán)衡。

自動 mTLS

默認(rèn)情況下，Linkerd 通過在 Linkerd 代理之間建立和驗證安全的私有 TLS 連接， 為網(wǎng)狀 Pod 之間的大多數(shù) TCP 流量自動啟用相互傳輸層安全性 (mTLS)。這意味著 Linkerd 可以向您的應(yīng)用程序添加經(jīng)過身份驗證的加密通信， 而您只需做很少的工作。由于 Linkerd 控制平面也在數(shù)據(jù)平面上運行， 這意味著 Linkerd 控制平面組件之間的通信也通過 mTLS 自動保護(hù)。

它是如何工作的?

簡而言之，Linkerd 的控制平面向代理頒發(fā) TLS 證書， 這些證書的范圍限定為包含 Pod 的 Kubernetes ServiceAccount， 并每 24 小時自動輪換一次。代理使用這些證書來加密和驗證到其他代理的 TCP 流量。

為此，Linkerd 在集群中維護(hù)了一組憑據(jù)：信任錨(trust anchor)、 頒發(fā)者證書(issuer certificate)和私鑰(private key)。這些憑據(jù)在安裝時由 Linkerd 本身生成，或者由外部源 (例如 Vault 或 cert-manager。頒發(fā)者證書和私鑰放置在 Kubernetes Secret 中。默認(rèn)情況下，Secret 放置在 linkerd 命名空間中， 并且只能由 Linkerd 控制平面 的 identity 組件使用的服務(wù)帳戶讀取。

在數(shù)據(jù)平面方面，每個代理都在環(huán)境變量中傳遞信任錨(trust anchor)。在啟動時，代理會生成一個私鑰， 存儲在 tmpfs emptyDir 中，該私鑰留在內(nèi)存中并且永遠(yuǎn)不會離開 pod。代理連接到控制平面的身份(identity)組件，驗證與信任錨的身份(identity)連接， 并發(fā)出證書簽名請求 (CSR)。CSR 包含一個初始證書，其身份設(shè)置為 pod 的 Kubernetes ServiceAccount， 以及實際的服務(wù)帳戶令牌，以便該身份可以驗證 CSR 是否有效。驗證后，簽名的信任包將返回給代理，代理可以將其用作客戶端和服務(wù)器證書。這些證書的范圍為 24 小時，并使用相同的機制動態(tài)刷新。

當(dāng)注入 Pod 的代理從應(yīng)用程序容器接收到出站連接時， 它會通過使用 Linkerd 控制平面查找該 IP 地址來執(zhí)行服務(wù)發(fā)現(xiàn)。當(dāng)目的地在 Kubernetes 集群中時，控制平面為代理提供目的地的端點地址以及元數(shù)據(jù)。當(dāng)身份名稱包含在此元數(shù)據(jù)中時，這向代理表明它可以啟動雙向 TLS。當(dāng)代理連接到目標(biāo)時，它會發(fā)起 TLS 握手，驗證目標(biāo)代理的證書是否已針對預(yù)期的身份名稱進(jìn)行簽名。

維護(hù)

linkerd install 生成的信任錨在 365 天后過期， 必須手動輪換。或者，您可以自己提供信任錨并控制到期日期。

默認(rèn)情況下，頒發(fā)者證書和密鑰不會自動輪換。您可以使用 cert-manager 設(shè)置自動輪換。

注意事項和未來工作

Linkeder 自動加密和驗證集群中所有通信的能力存在一些已知的缺陷。這些缺口將在以后的版本中修復(fù)：

• Linkerd 目前不強制執(zhí)行 mTLS。網(wǎng)格內(nèi)的任何未加密請求都將隨機升級到 mTLS。

Linkerd 不會自動對來自網(wǎng)格內(nèi)部或外部的任何請求進(jìn)行 mTLS。這將在未來的 Linkerd 版本中解決，可能作為選擇加入行為， 因為它可能會破壞一些現(xiàn)有的應(yīng)用程序。

• 理想情況下，Linkerd 使用的 ServiceAccount 令牌不會

與該令牌的其他潛在用途共享。在未來的 Kubernetes 版本中，Kubernetes 將 支持 audience/time-bound 的 ServiceAccount 令牌， Linkerd 將使用這些令牌。

Ingress

為簡單起見，Linkerd 沒有提供自己的 ingress controller。相反，Linkerd 旨在與您選擇的 ingress controller 一起工作。

遙測和監(jiān)控

Linkerd 最強大的功能之一是其圍繞可觀察性(observability)的廣泛工具集— 在網(wǎng)格應(yīng)用程序中測量和報告觀察到的行為。雖然 Linkerd 沒有直接洞察服務(wù)代碼的內(nèi)部結(jié)構(gòu)， 但它對服務(wù)代碼的外部行為有著巨大的洞察力。

要訪問 Linkerd 的可觀察性功能，您只需要安裝 Viz 擴展：

linkerd viz install | kubectl apply -f - 

Linkerd 的遙測和監(jiān)控功能會自動運行，無需開發(fā)人員進(jìn)行任何工作。這些功能包括：

• 記錄 HTTP、HTTP/2 和 gRPC 流量的頂級(“黃金”)指標(biāo)(請求量、成功率和延遲分布)。
• 記錄其他 TCP 流量的 TCP 級別指標(biāo)(輸入/輸出字節(jié)等)。
• 報告每個服務(wù)、每個調(diào)用方(caller)/被調(diào)用方(callee)對或每個路由/路徑(使用服務(wù)配置文件)的指標(biāo)。
• 生成拓?fù)鋱D，顯示服務(wù)之間的運行時關(guān)系。
• 實時、按需請求采樣。

可以通過多種方式使用這些數(shù)據(jù)：

• 通過 Linkerd CLI，

例如：使用 linkerd viz stat 和 linkerd viz routes。

• 通過 Linkerd dashboard 和 pre-built Grafana dashboards。
• 直接來自 Linkerd 的內(nèi)置 Prometheus 實例

黃金指標(biāo)

成功率

這是一個時間窗口(默認(rèn)為 1 分鐘)內(nèi)成功請求的百分比。

在命令 linkerd viz routes -o wide 的輸出中， 此度量分為 EFFECTIVE_SUCCESS 和 ACTUAL_SUCCESS。對于配置了重試的路由，前者計算重試后的成功百分比(客戶端感知)， 后者計算重試前的成功率(可能暴露服務(wù)的潛在問題)。

流量(每秒請求數(shù))

這概述了對 service/route 的需求量。與成功率一樣，linkerd viz routes --o wide 將此指標(biāo) 拆分為 EFFECTIVE_RPS 和 ACTUAL_RPS，分別對應(yīng)于重試前后的比率。

延遲

每個 service/route 的服務(wù)請求所花費的時間分為第 50、95 和 99 個百分位數(shù)。較低的百分位數(shù)可讓您大致了解系統(tǒng)的平均性能，而尾部百分位數(shù)有助于捕捉異常行為。

Linkerd 指標(biāo)的生命周期

Linkerd 并非設(shè)計為長期歷史指標(biāo)存儲。雖然 Linkerd 的 Viz 擴展確實包含一個 Prometheus 實例， 但該實例會在很短的固定時間間隔(目前為 6 小時)內(nèi)使指標(biāo)過期。

相反，Linkerd 旨在補充(supplement)您現(xiàn)有的指標(biāo)存儲。如果 Linkerd 的指標(biāo)有價值，您應(yīng)該將它們導(dǎo)出到您現(xiàn)有的歷史指標(biāo)存儲中。

負(fù)載均衡

對于 HTTP、HTTP/2 和 gRPC 連接， Linkerd 會自動在所有目標(biāo)端點之間對請求進(jìn)行負(fù)載平衡，無需任何配置。(對于 TCP 連接，Linkerd 會平衡連接。)

Linkerd 使用一種稱為 EWMA 或 指數(shù)加權(quán)移動平均(exponentially weighted moving average)的算法來自動將請求發(fā)送到最快的端點。這種負(fù)載平衡可以改善端到端(end-to-end)延遲。

服務(wù)發(fā)現(xiàn)

對于不在 Kubernetes 中的目的地，Linkerd 將在 DNS 提供的端點之間進(jìn)行平衡。

對于 Kubernetes 中的目的地，Linkerd 將在 Kubernetes API 中查找 IP 地址。如果 IP 地址對應(yīng)于一個服務(wù)，Linkerd 將在該服務(wù)的端點之間進(jìn)行負(fù)載平衡， 并應(yīng)用該服務(wù)的服務(wù)配置文件中的任何策略。另一方面，如果 IP 地址對應(yīng)一個 Pod， Linkerd 將不會執(zhí)行任何負(fù)載均衡或應(yīng)用任何服務(wù)配置文件。

如果使用無頭服務(wù)(headless services)，則無法檢索服務(wù)的端點。因此，Linkerd 不會執(zhí)行負(fù)載均衡，而是只路由到目標(biāo) IP 地址。

負(fù)載均衡 gRPC

Linkerd 的負(fù)載均衡對于 Kubernetes 中的 gRPC(或 HTTP/2)服務(wù)特別有用， 對于這些服務(wù)，Kubernetes 的默認(rèn)負(fù)載均衡是無效的。

自動代理注入

當(dāng)命名空間或任何工作負(fù)載(例如部署或 Pod)上存在 linkerd.io/inject: enabled annotation 時， Linkerd 會自動將數(shù)據(jù)平面代理添加到 Pod。這稱為“代理注入(proxy injection)”。

代理注入也是代理配置發(fā)生的地方。雖然很少需要，但您可以通過在注入之前在資源級別 設(shè)置額外的 Kubernetes annotations 來配置代理設(shè)置。

細(xì)節(jié)

代理注入是作為 Kubernetes admission webhook 實現(xiàn)的。這意味著代理會添加到 Kubernetes 集群本身內(nèi)的 pod 中， 而不管 pod 是由 kubectl、CI/CD 系統(tǒng)還是任何其他系統(tǒng)創(chuàng)建的。

對于每個 pod，注入兩個容器：

1. linkerd-init，一個 Kubernetes Init Container，它配置 iptables 以通過代理自動轉(zhuǎn)發(fā)所有傳入和傳出的 TCP 流量。(請注意，如果 Linkerd CNI Plugin 已啟用，則此容器不存在。)
2. linkerd-proxy，Linkerd 數(shù)據(jù)平面代理本身。

請注意，簡單地將 annotation 添加到具有預(yù)先存在的 pod 的資源不會自動注入這些 pod。您將需要更新 pod(例如使用 kubectl rollout restart 等)以便注入它們。這是因為 Kubernetes 在需要更新底層資源之前不會調(diào)用 webhook。

覆蓋注入

通過添加 linkerd.io/inject: disabled annotation， 可以為 pod 或部署禁用自動注入，否則將為其啟用。

手動注入

linkerd inject CLI 命令是一個文本轉(zhuǎn)換， 默認(rèn)情況下，它只是將 inject annotation 添加到給定的 Kubernetes 清單。

或者，這個命令也可以使用 --manual 標(biāo)志在客戶端執(zhí)行完全注入。這是 Linked2.4 之前的默認(rèn)行為;但是，向集群側(cè)注入數(shù)據(jù)可以更容易地確保 數(shù)據(jù)平面始終存在并正確配置，而不管 pod 是如何部署的。

容器網(wǎng)絡(luò)接口插件

Linkerd installs 可以配置去運行一個 CNI plugin， 該插件自動重寫每個 pod 的 iptables 規(guī)則。通過 pod 的 linkerd-proxy 容器路由網(wǎng)絡(luò)流量需要重寫 iptables。啟用 CNI 插件后，單個 Pod 不再需要包含需要 NET_ADMIN 功能來執(zhí)行重寫的 init 容器。這在集群管理員限制該功能的集群中很有用。

安裝

使用 Linkerd CNI 插件需要先在集群上成功安裝 linkerd-cni DaemonSet， 然后再安裝 Linkerd 控制平面。

使用 CLI

要安裝 linkerd-cni DaemonSet，請運行：

linkerd install-cni | kubectl apply -f - 

一旦 DaemonSet 啟動并運行，所有包含 linkerd-proxy 容器(包括 Linkerd 控制平面) 的后續(xù)安裝都不再需要包含 linkerd-init 容器。init 容器的省略由控制平面安裝時的 --linkerd-cni-enabled 標(biāo)志控制。

安裝 Linkerd 控制平面，使用：

linkerd install --linkerd-cni-enabled | kubectl apply -f - 

這將在 linkerd-config ConfigMap 中設(shè)置 cniEnabled 標(biāo)志。所有后續(xù)代理注入都將讀取此字段并省略 init 容器。

使用 Helm

首先確保您的 Helm 本地緩存已更新：

helm repo update 
 
helm search linkerd2-cni 
NAME                      CHART VERSION  APP VERSION    DESCRIPTION 
linkerd-edge/linkerd2-cni   20.1.1       edge-20.1.1    A helm chart containing the resources needed by the Linke... 
linkerd-stable/linkerd2-cni  2.7.0       stable-2.7.0   A helm chart containing the resources needed by the Linke... 

運行以下命令安裝 CNI DaemonSet：

# install the CNI plugin first 
helm install linkerd2-cni linkerd2/linkerd2-cni 
 
# ensure the plugin is installed and ready 
linkerd check --pre --linkerd-cni-enabled 

對于低于 v3 的 Helm 版本，必須專門傳遞 --name 標(biāo)志。在 Helm v3 中，它已被棄用，并且是上面指定的第一個參數(shù)。

此時，您已準(zhǔn)備好在啟用 CNI 的情況下安裝 Linkerd。您可以按照使用 Helm 安裝 Linkerd 來執(zhí)行此操作。

附加配置

linkerd install-cni 命令包括可用于自定義安裝的附加標(biāo)志。有關(guān)更多信息，請參閱 linkerd install-cni --help。請注意，許多標(biāo)志類似于運行 linkerd 注入時可用于配置代理的標(biāo)志。如果在運行 linkerd install-cni 時更改了默認(rèn)值， 則需要確保在運行 linkerd inject 時進(jìn)行相應(yīng)的更改。

最重要的標(biāo)志是：

1. --dest-cni-net-dir: 這是 CNI 配置所在節(jié)點上的目錄。默認(rèn)為: /etc/cni/net.d。
2. --dest-cni-bin-dir: 這是 CNI 插件二進(jìn)制文件所在的節(jié)點上的目錄。默認(rèn)為:/opt/cni/bin。
3. --cni-log-level: 將此設(shè)置為 debug 將允許更詳細(xì)的日志記錄。要查看 CNI 插件日志，您必須能夠查看 kubelet 日志。一種方法是登錄節(jié)點并使用 journalctl -t kubelet。字符串 linkerd-cni: 可用作查找插件日志輸出的搜索。

升級 CNI 插件

由于 CNI 插件基本上是無狀態(tài)的，因此不需要單獨的 upgrade 命令。如果您使用 CLI 升級 CNI 插件，您可以執(zhí)行以下操作：

linkerd install-cni   | kubectl apply --prune -l  linkerd.io/cni-resource=true -f - 

請記住，如果您是從實驗版本(experimental version)升級插件，則需要卸載并重新安裝。

儀表板和 Grafana

除了命令行界面， Linkerd 還提供了一個 Web 儀表板和預(yù)配置的 Grafana 儀表板。

要訪問此功能，您需要安裝 Viz 擴展：

linkerd viz install | kubectl apply -f - 

Linkerd 儀表板

Linkerd 儀表板提供實時服務(wù)發(fā)生情況的高級視圖。它可用于查看“黃金”指標(biāo)(成功率、請求/秒和延遲)、 可視化服務(wù)依賴關(guān)系并了解特定服務(wù)路由的健康狀況。拉起它的一種方法是從命令行運行 linkerd viz dashboard。

Grafana

作為控制平面的一個組件，Grafana 為您的服務(wù)提供開箱即用的可操作儀表板。可以查看高級指標(biāo)并深入了解細(xì)節(jié)，甚至是 pod。

開箱即用的儀表板包括：

Top Line Metrics

Deployment Detail

Pod Detail

Linkerd Health

分布式追蹤

跟蹤可以成為調(diào)試分布式系統(tǒng)性能的寶貴工具， 尤其是用于識別瓶頸和了解系統(tǒng)中每個組件的延遲成本。Linkerd 可以配置為從代理發(fā)出跟蹤跨度， 允許您準(zhǔn)確查看請求和響應(yīng)在內(nèi)部花費的時間。

與 Linkerd 的大多數(shù)功能不同，分布式跟蹤需要更改代碼和配置。

此外，Linkerd 提供了許多通常與分布式跟蹤相關(guān)的功能，無需配置或應(yīng)用程序更改，包括：

• 實時服務(wù)拓?fù)浜鸵蕾囮P(guān)系圖
• 聚合服務(wù)運行狀況、延遲和請求量
• 聚合 path / route 運行狀況、延遲和請求量

例如，Linkerd 可以顯示服務(wù)的所有傳入和傳出依賴項的實時拓?fù)洌?而無需分布式跟蹤或任何其他此類應(yīng)用程序修改：

Linkerd 儀表板顯示自動生成的拓?fù)鋱D

同樣，Linkerd 可以為每個服務(wù)和每個 route 提供黃金指標(biāo)， 同樣不需要分布式跟蹤或任何其他此類應(yīng)用程序修改：

Linkerd 儀表板顯示自動生成的路由指標(biāo)

使用分布式跟蹤

也就是說，分布式跟蹤肯定有其用途，Linkerd 使這盡可能簡單。Linkerd 在分布式跟蹤中的作用實際上非常簡單：當(dāng) Linkerd 數(shù)據(jù)平面代理(data plane proxy)在代理的 HTTP 請求中 看到跟蹤頭(tracing header)時， Linkerd 將為該請求發(fā)出跟蹤范圍(trace span)。此跨度將包括有關(guān)在 Linkerd 代理中花費的確切時間量的信息。當(dāng)與軟件配合使用來收集、存儲和分析這些信息時， 這可以提供對 mesh 行為的重要洞察。

要使用此功能，您還需要引入幾個額外的系統(tǒng)中的組件， 包括啟動特定請求跟蹤的入口層(ingress layer)、 應(yīng)用程序的客戶端庫(或傳播跟蹤頭的機制)、 收集跨度數(shù)據(jù)并將其轉(zhuǎn)換為跟蹤的跟蹤收集器， 以及跟蹤后端存儲跟蹤數(shù)據(jù)并允許用戶查看/查詢它。

故障注入

故障注入是混沌工程的一種形式，通過人為地增加服務(wù)的錯誤率來觀察對整個系統(tǒng)的影響。傳統(tǒng)上，這需要修改服務(wù)的代碼，以添加一個執(zhí)行實際工作的錯誤注入庫。Linkeder 可以做到這一點，而不需要任何服務(wù)代碼更改，只需要一點配置。

高可用性

對于生產(chǎn)工作負(fù)載，Linkerd 的控制平面可以在高可用性 (HA) 模式下運行。這種模式：

• 運行關(guān)鍵控制平面組件的三個副本。
• 在控制平面組件上設(shè)置生產(chǎn)就緒(production-ready) CPU 和內(nèi)存資源請求。
• 在數(shù)據(jù)平面代理上設(shè)置生產(chǎn)就緒的 CPU 和內(nèi)存資源請求
• 要求 proxy auto-injector 可用于任何要調(diào)度的 pod。
• 在關(guān)鍵控制平面組件上設(shè)置反關(guān)聯(lián)性策略(anti-affinity policies)，

以確保在可能的情況下，默認(rèn)情況下將它們安排在單獨的節(jié)點和單獨的區(qū)域中。

啟用 HA

您可以在控制平面安裝時使用 --ha 標(biāo)志啟用 HA 模式：

linkerd install --ha | kubectl apply -f - 

另請注意，可視化擴展還支持具有類似特征的 --ha 標(biāo)志：

linkerd viz install --ha | kubectl apply -f - 

您可以在安裝時通過將其他標(biāo)志傳遞給 install 命令來覆蓋 HA 行為的某些方面。例如，您可以使用 --controller-replicas 標(biāo)志覆蓋關(guān)鍵組件的副本數(shù)：

linkerd install --ha --controller-replicas=2 | kubectl apply -f - 

請參閱完整的 install CLI 文檔以供參考。

linkerd upgrade 命令可用于在現(xiàn)有控制平面上啟用 HA 模式：

linkerd upgrade --ha | kubectl apply -f - 

代理注入器故障策略

HA 代理注入器(proxy injector)部署了更嚴(yán)格的故障策略(failure policy)， 以強制執(zhí)行 automatic proxy injection。此設(shè)置可確保在沒有 Linkerd 代理的情況下， 不會意外安排帶注解的工作負(fù)載在您的集群上運行。(當(dāng)代理注入器關(guān)閉時可能會發(fā)生這種情況。)

如果在準(zhǔn)入階段由于無法識別或超時錯誤導(dǎo)致代理注入過程失敗， 則工作負(fù)載準(zhǔn)入將被 Kubernetes API 服務(wù)器拒絕，部署將失敗。

因此，始終至少有一個運行在集群上的代理注入器的健康副本非常重要。

如果您不能保證集群上健康的代理注入器的數(shù)量， 您可以通過將其值設(shè)置為 Ignore 來放松 webhook 故障策略，如 Linkerd Helm chart所示。

有關(guān)準(zhǔn)入 webhook 失敗策略的更多信息，請參閱 Kubernetes documentation。

排除 kube-system 命名空間

根據(jù) Kubernetes documentation 的建議，應(yīng)該為 kube-system 命名空間禁用代理注入器。

這可以通過使用以下標(biāo)簽標(biāo)記 kube-system 命名空間來完成：

kubectl label namespace kube-system config.linkerd.io/admission-webhooks=disabled 

在具有此標(biāo)簽的命名空間中工作負(fù)載的準(zhǔn)入階段，Kubernetes API 服務(wù)器不會調(diào)用代理注入器。

Pod 反關(guān)聯(lián)規(guī)則

所有關(guān)鍵控制平面組件都部署了 pod 反關(guān)聯(lián)性(anti-affinity)規(guī)則以確保冗余。

Linkerd 使用 requiredDuringSchedulingIgnoredDuringExecution pod anti-affinity 規(guī)則 來確保 Kubernetes 調(diào)度程序不會將關(guān)鍵組件的副本并置在同一節(jié)點上。還添加了一個 preferredDuringSchedulingIgnoredDuringExecution pod anti-affinity 規(guī)則， 以嘗試在可能的情況下在不同區(qū)域中安排副本。

為了滿足這些反關(guān)聯(lián)(anti-affinity)規(guī)則，HA 模式假設(shè) Kubernetes 集群中始終至少有三個節(jié)點。如果違反此假設(shè)(例如，集群縮小到兩個或更少的節(jié)點)，則系統(tǒng)可能會處于非功能(non-functional)狀態(tài)。

請注意，這些反關(guān)聯(lián)性規(guī)則不適用于 Prometheus 和 Grafana 等附加組件。

縮放 Prometheus

Linkerd Viz 擴展提供了一個預(yù)配置的 Prometheus pod，但對于生產(chǎn)工作負(fù)載， 我們建議設(shè)置您自己的 Prometheus 實例。

在規(guī)劃存儲 Linkerd 時間序列數(shù)據(jù)的內(nèi)存容量時，通常的指導(dǎo)是每個網(wǎng)格 pod 5MB。

如果您的 Prometheus 由于來自數(shù)據(jù)平面的數(shù)據(jù)量而遇到定期 OOMKilled 事件， 則可以調(diào)整的兩個關(guān)鍵參數(shù)是：

• storage.tsdb.retention.time 定義將采樣保留多長時間。更高的值意味著需要更多的內(nèi)存來將數(shù)據(jù)保存更長時間。降低此值將減少 OOMKilled 事件的數(shù)量，因為數(shù)據(jù)保留的時間較短
• storage.tsdb.retention.size 定義可以為塊存儲的最大字節(jié)數(shù)。較低的值也將有助于減少 OOMKilled 事件的數(shù)量

使用 Cluster AutoScaler

Linkerd 代理將其 mTLS 私鑰存儲在 tmpfs emptyDir 卷中， 以確保此信息永遠(yuǎn)不會離開 pod。這會導(dǎo)致 Cluster AutoScaler 的默認(rèn)設(shè)置無法縮小具有注入工作負(fù)載副本的節(jié)點。

解決方法是使用 cluster-autoscaler.kubernetes.io/safe-to-evict: "true" annotation 來注入工作負(fù)載。如果您可以完全控制 Cluster AutoScaler 配置， 則可以使用 --skip-nodes-with-local-storage=false 選項啟動 Cluster AutoScaler。

多集群通信

Linkerd 可以以安全、對應(yīng)用程序完全透明且獨立于網(wǎng)絡(luò)拓?fù)涞姆绞?跨集群邊界連接 Kubernetes 服務(wù)。這種多集群功能旨在提供：

1. 統(tǒng)一的信任域。 在集群邊界內(nèi)和跨集群邊界的每一步都驗證源和目標(biāo)工作負(fù)載的身份。
2. 單獨的故障域。 一個集群的故障允許剩余的集群運行。
3. 支持異構(gòu)網(wǎng)絡(luò)。 由于集群可以跨越云、VPC、本地數(shù)據(jù)中心及其組合， Linkerd 不會引入除網(wǎng)關(guān)連接(gateway connectivity)之外的任何 L3/L4 要求。
4. 集群通信中的統(tǒng)一模型。 Linkerd 為集群內(nèi)通信提供的可觀測性(observability)、可靠性(reliability) 和安全特性(security)也擴展到了跨集群通信。

就像集群內(nèi)連接一樣，Linkerd 的跨集群連接對應(yīng)用程序代碼是透明的。無論通信發(fā)生在集群內(nèi)、數(shù)據(jù)中心或 VPC 內(nèi)的集群之間， 還是通過公共互聯(lián)網(wǎng)，Linkerd 都會在集群之間建立連接， 該連接在雙方都使用 mTLS 進(jìn)行加密和身份驗證。

工作原理

Linkerd 的多集群支持通過在集群之間“鏡像(mirroring)”服務(wù)信息來工作。由于遠(yuǎn)程服務(wù)被表示為 Kubernetes 服務(wù)， Linkerd 的完整可觀察性、安全性和路由功能統(tǒng)一 適用于集群內(nèi)和集群調(diào)用，應(yīng)用程序不需要區(qū)分這些情況。

Linkerd 的多集群功能由兩個組件實現(xiàn)：服務(wù)鏡像(service mirror)和網(wǎng)關(guān)(gateway)。服務(wù)鏡像(service mirror)組件監(jiān)視目標(biāo)集群中的服務(wù)更新，并在源集群上本地鏡像這些服務(wù)更新。這提供了對目標(biāo)集群的服務(wù)名稱的可見性，以便應(yīng)用程序可以直接尋址它們。多集群網(wǎng)關(guān)組件為目標(biāo)集群提供了一種從源集群接收請求的方式。(這允許 Linkerd 支持分層網(wǎng)絡(luò))

安裝這些組件后，可以將與標(biāo)簽選擇器(label selector)匹配的 Kubernetes Service 資源導(dǎo)出到其他集群。

服務(wù)配置文件

服務(wù)配置文件是一種自定義 Kubernetes 資源 (CRD)， 可以提供有關(guān)服務(wù)的 Linkerd 附加信息。特別是，它允許您定義服務(wù)的路由列表。每個路由都使用一個正則表達(dá)式來定義哪些路徑應(yīng)該與該路由匹配。定義服務(wù)配置文件使 Linkerd 能夠報告每個路由的指標(biāo)， 還允許您啟用每個路由的功能，例如重試和超時。

如果使用無頭服務(wù)，則無法檢索服務(wù)配置文件。Linkerd 根據(jù)目標(biāo) IP 地址讀取服務(wù)發(fā)現(xiàn)信息， 如果這恰好是 pod IP 地址，則它無法判斷 pod 屬于哪個服務(wù)。

流量拆分(金絲雀、藍(lán)/綠部署)

Linkerd 的流量拆分功能允許您將目的地為 Kubernetes 服務(wù)的流量的任意部分動態(tài)轉(zhuǎn)移到不同的目的地服務(wù)。此功能可用于實施復(fù)雜的部署策略，例如 金絲雀部署和 藍(lán)/綠部署， 例如，通過緩慢地將流量從舊版本的服務(wù)轉(zhuǎn)移到新版本。

如果使用無頭服務(wù)，則無法檢索流量拆分。Linkerd 根據(jù)目標(biāo) IP 地址讀取服務(wù)發(fā)現(xiàn)信息， 如果這恰好是 pod IP 地址，則它無法判斷 pod 屬于哪個服務(wù)。

Linkerd 通過 Service Mesh Interface (SMI) TrafficSplit API 公開此功能。要使用此功能，您需要按照 TrafficSplit 規(guī)范中的描述創(chuàng)建一個 Kubernetes 資源，Linkerd 負(fù)責(zé)其余的工作。

通過將流量拆分與 Linkerd 的指標(biāo)相結(jié)合，可以實現(xiàn)更強大的部署技術(shù)， 自動考慮新舊版本的成功率和延遲。有關(guān)此示例的一個示例，請參閱 Flagger 項目。