Linkerd 2.10 系列

• 快速上手 Linkerd v2 Service Mesh（服務網格）
• 騰訊雲 K8S 叢集實戰 Service Mesh—Linkerd2 & Traefik2 部署 emojivoto 應用
• 詳細瞭解 Linkerd 2.10 基礎功能，一起步入 Service Mesh 微服務架構時代
• Linkerd 2.10(Step by Step)—1. 將您的服務新增到 Linkerd
• Linkerd 2.10(Step by Step)—2. 自動化的金絲雀釋出
• Linkerd 2.10(Step by Step)—3. 自動輪換控制平面 TLS 與 Webhook TLS 憑證

Linkerd 2.10 中文手冊持續修正更新中：

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

Linkerd 資料平面的代理是多執行緒(multithreaded)的，
並且能夠執行可變數量的工作執行緒，
以便它們的資源使用(resource usage)與應用程式工作負載(application workload)相匹配。

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

真實世界的部署不是一個負載測試(load test)，
在這個測試中，客戶端和伺服器除了用請求使代理飽和之外，沒有其他工作要做。
相反，服務網格模型將代理例項部署為應用程式容器的 sidecar

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

使用 proxy-cpu-limit Annotation

配置代理執行緒池的最簡單方法是使用 config.linkerd.io/proxy-cpu-limit

使用 linkerd install CLI 命令安裝 Linkerd 時，
--proxy-cpu-limit 引數會為 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 核心的整數來表示。小數值將四捨五入到最接近的整數。

使用 Kubernetes CPU Limits 與 Requests

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

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

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

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

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

• kubelet 必須配置 static CPU 管理器策略
• Pod 必須屬於有
  Guaranteed QoS class。
  這意味著 pod 中的所有容器都必須同時具有記憶體和 CPU 的 limit 和 request，並且每個的 limit 必須與 request 具有相同的值。
• CPU limit 和 CPU request 必須是大於或等於 1 的整數。

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

使用 Helm

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

我是為少
微信：uuhells123
公眾號：黑客下午茶
加我微信（互相學習交流），關注公眾號（獲取更多學習資料~）