[[405974]]

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

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

Linkerd 數(shù)據(jù)平面的代理是多線程(multithreaded)的， 并且能夠運行可變數(shù)量的工作線程， 以便它們的資源使用(resource usage)與應用程序工作負載(application workload)相匹配。

當然，在真空(vacuum)中，當允許使用盡可能多的 CPU 內核時， 代理將表現(xiàn)出最佳的吞吐量(throughput)和最低的延遲(latency)。但是，在實踐中，還需要考慮其他因素。

真實世界的部署不是一個負載測試(load test)， 在這個測試中，客戶端和服務器除了用請求使代理飽和之外，沒有其他工作要做。相反，服務網(wǎng)格模型將代理實例部署為應用程序容器的 sidecar。每個代理只處理進出它注入的 pod 的流量。這意味著吞吐量和延遲受應用程序工作負載的限制。如果應用程序容器實例每秒只能處理這么多請求，那么代理可以處理更多的請求可能并不重要。事實上，給代理提供比它需要的更多 CPU 內核來跟上應用程序可能會損害整體性能， 因為應用程序可能不得不與代理競爭有限的系統(tǒng)資源。

因此，單個代理有效處理其流量比配置所有代理以處理最大可能負載更為重要。調整代理資源使用的主要方法是限制代理用于轉發(fā)流量的工作線程數(shù)。有多種方法可以做到這一點。

使用 proxy-cpu-limit Annotation

配置代理線程池的最簡單方法是使用 config.linkerd.io/proxy-cpu-limit annotation。此 annotation 配置代理注入器以設置一個環(huán)境變量，該變量控制代理將使用的 CPU 核數(shù)。

使用 linkerd install CLI 命令安裝 Linkerd 時， --proxy-cpu-limit 參數(shù)會為 Linkerd 安裝注入的所有代理全局設置此 annotation。例如，

linkerd install --proxy-cpu-limit 2 | kubectl apply -f -

對于更細粒度(fine-grained)的配置，可以將 annotation 添加到 任何可注入的 Kubernetes 資源，例如 namespace、pod 或 deployment。

例如，以下將配置 my-deployment 部署中的代理使用1個 CPU 內核：

kind: Deployment 
apiVersion: apps/v1 
metadata: 
  name: my-deployment 
  # ... 
spec: 
  template: 
    metadata: 
      annotations: 
        config.linkerd.io/proxy-cpu-limit: '1' 
  # ... 

與 Kubernetes CPU 限制和請求可以用 milliCPUs 表示不同， proxy-cpu-limit 注解應該用 CPU 內核的整數(shù)來表示。小數(shù)值將四舍五入到最接近的整數(shù)。

使用 Kubernetes CPU Limits 與 Requests

Kubernetes 提供 CPU limits and CPU requests 來配置分配給任何 pod 或容器的資源。這些也可用于配置 Linkerd 代理的 CPU 使用率。但是，根據(jù) kubelet 的配置方式， 使用 Kubernetes 資源限制 而不是 proxy-cpu-limit annotation 可能并不理想。

kubelet 使用兩種機制之一來強制執(zhí)行 pod CPU 限制。這由 --cpu-manager-policy kubelet 選項 決定。使用默認的 CPU 管理器策略 none， kubelet 使用 CFS 配額 來強制執(zhí)行 CPU limits。這意味著 Linux 內核被配置為限制屬于給定進程的線程被調度的時間量。或者，CPU 管理器策略可以設置為 static。在這種情況下，kubelet 將使用 Linux cgroups 對滿足特定條件的容器實施 CPU limits。

當 proxy-cpu-limit annotation 配置的環(huán)境變量未設置時， 代理將運行與可用 CPU 內核數(shù)相等的工作線程數(shù)。這意味著使用默認的 noneCPU 管理器策略，代理可能會產(chǎn)生大量工作線程， 但 Linux 內核會限制它們的調度頻率。這比簡單地減少工作線程的數(shù)量效率更低，就像 proxy-cpu-limit 所做的那樣：更多的時間花在上下文切換上，每個工作線程的運行頻率將降低，這可能會影響延遲。

另一方面，使用 cgroup cpusets 將限制進程可用的 CPU 核數(shù)。從本質上講，代理會認為系統(tǒng)的 CPU 內核數(shù)比實際少。這將導致與 proxy-cpu-limit annotation 類似的行為。

但是，值得注意的是，要使用此機制，必須滿足某些條件：

• kubelet 必須配置 static CPU 管理器策略
• Pod 必須屬于有 Guaranteed QoS class。這意味著 pod 中的所有容器都必須同時具有內存和 CPU 的 limit 和 request，并且每個的 limit 必須與 request 具有相同的值。
• CPU limit 和 CPU request 必須是大于或等于 1 的整數(shù)。

如果您不確定是否會全部滿足這些條件，除了任何 Kubernetes CPU limits 和 requests 之外， 最好使用 proxy-cpu-limit annotation。

使用 Helm

使用 Helm 時，如果不滿足上述基于 cgroup 的 CPU 限制條件， 用戶必須注意設置 proxy.cores Helm 變量和 proxy.cpu.limit 之外的變量。