[[405370]]

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

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

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

Linkerd 2.10 系列

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

功能概述

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

HTTP、HTTP/2 和 gRPC 代理

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

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

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

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

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

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

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

配置協(xié)議檢測(cè)

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

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

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

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

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

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

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

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

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

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

可以在運(yùn)行 linkerd inject 時(shí)使用 --opaque-ports 標(biāo)志來(lái) 設(shè)置 opaque-ports annotation。例如，對(duì)于運(yùn)行在集群上的 MySQL 數(shù)據(jù)庫(kù)使用 非標(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 - 

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

跳過(guò)代理

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

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

跳過(guò)代理對(duì)于這些情況以及診斷問(wèn)題很有用，但除此之外幾乎沒(méi)有必要。

與不透明端口一樣，可以以逗號(hào)分隔的字符串形式提供多個(gè)跳過(guò)端口。

重試和超時(shí)

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

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

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

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

重試如何出錯(cuò)

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

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

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

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

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

重試預(yù)算來(lái)救援

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

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

自動(dòng) mTLS

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

它是如何工作的?

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

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

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

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

維護(hù)

linkerd install 生成的信任錨在 365 天后過(guò)期， 必須手動(dòng)輪換?；蛘?，您可以自己提供信任錨并控制到期日期。

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

注意事項(xiàng)和未來(lái)工作

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

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

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

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

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

Ingress

為簡(jiǎn)單起見(jiàn)，Linkerd 沒(méi)有提供自己的 ingress controller。相反，Linkerd 旨在與您選擇的 ingress controller 一起工作。

遙測(cè)和監(jiān)控

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

要訪問(wèn) Linkerd 的可觀察性功能，您只需要安裝 Viz 擴(kuò)展：

linkerd viz install | kubectl apply -f - 

Linkerd 的遙測(cè)和監(jiān)控功能會(huì)自動(dòng)運(yùn)行，無(wú)需開(kāi)發(fā)人員進(jìn)行任何工作。這些功能包括：

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

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

• 通過(guò) Linkerd CLI，

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

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

黃金指標(biāo)

成功率

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

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

流量(每秒請(qǐng)求數(shù))

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

延遲

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

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

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

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

負(fù)載均衡

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

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

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

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

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

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

負(fù)載均衡 gRPC

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

自動(dòng)代理注入

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

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

細(xì)節(jié)

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

對(duì)于每個(gè) pod，注入兩個(gè)容器：

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

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

覆蓋注入

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

手動(dòng)注入

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

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

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

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

安裝

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

使用 CLI

要安裝 linkerd-cni DaemonSet，請(qǐng)運(yùn)行：

linkerd install-cni | kubectl apply -f - 

一旦 DaemonSet 啟動(dòng)并運(yùn)行，所有包含 linkerd-proxy 容器(包括 Linkerd 控制平面) 的后續(xù)安裝都不再需要包含 linkerd-init 容器。init 容器的省略由控制平面安裝時(shí)的 --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... 

運(yùn)行以下命令安裝 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 

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

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

附加配置

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

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

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

升級(jí) CNI 插件

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

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

請(qǐng)記住，如果您是從實(shí)驗(yàn)版本(experimental version)升級(jí)插件，則需要卸載并重新安裝。

儀表板和 Grafana

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

要訪問(wèn)此功能，您需要安裝 Viz 擴(kuò)展：

linkerd viz install | kubectl apply -f - 

Linkerd 儀表板

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

Grafana

作為控制平面的一個(gè)組件，Grafana 為您的服務(wù)提供開(kāi)箱即用的可操作儀表板?？梢圆榭锤呒?jí)指標(biāo)并深入了解細(xì)節(jié)，甚至是 pod。

開(kāi)箱即用的儀表板包括：

Top Line Metrics

Deployment Detail

Pod Detail

Linkerd Health

分布式追蹤

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

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

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

• 實(shí)時(shí)服務(wù)拓?fù)浜鸵蕾?lài)關(guān)系圖
• 聚合服務(wù)運(yùn)行狀況、延遲和請(qǐng)求量
• 聚合 path / route 運(yùn)行狀況、延遲和請(qǐng)求量

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

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

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

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

使用分布式跟蹤

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

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

故障注入

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

高可用性

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

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

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

啟用 HA

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

linkerd install --ha | kubectl apply -f - 

另請(qǐng)注意，可視化擴(kuò)展還支持具有類(lèi)似特征的 --ha 標(biāo)志：

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

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

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

請(qǐng)參閱完整的 install CLI 文檔以供參考。

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

linkerd upgrade --ha | kubectl apply -f - 

代理注入器故障策略

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

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

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

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

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

排除 kube-system 命名空間

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

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

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

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

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

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

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

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

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

縮放 Prometheus

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

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

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

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

使用 Cluster AutoScaler

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

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

多集群通信

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

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

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

工作原理

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

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

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

服務(wù)配置文件

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

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

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

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

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

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

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