Linkerd stable-2.11.0 穩定版發布：授權策略、gRPC 重試、性能改進等！

公眾號：黑客下午茶

授權策略

Linkerd 的新服務器授權策略(server authorization policy)功能使您可以細粒度控制允許哪些服務相互通信。這些策略直接建立在 Linkerd 的自動 mTLS 功能提供的安全服務身份上。與 Linkerd 的設計原則保持一致，授權策略以可組合的 Kubernetes 原生方式表達，這種方式只需最少的配置，就可表達廣泛的行為。

• https://linkerd.io/2.11/features/automatic-mtls

為此，Linkerd 2.11 引入了一組默認授權策略，只需設置 Kubernetes annotation 即可應用於 cluster、namespace 或 pod 級別，包括：

• all-authenticated（只允許來自 mTLS-validated 服務的請求）；
• all-unauthenticated（允許所有請求）
• deny（拒絕所有請求）
• … 和更多。

Linkerd 2.11 還引入了兩個新的 CRD Server 和 ServerAuthorization，它們一起允許在任意一組 pod 中應用細粒度的策略。例如，Server 可以選擇 namespace 中所有 pod 上的所有管理端口(admin ports)，ServerAuthorization 可以允許來自 kubelet 的健康檢查連接，或用於指標收集(metrics collection)的 mTLS 連接。

這些 annotation 和 CRD 一起使您可以輕松地為集群指定各種策略，從 “允許所有流量” 到 “服務 Foo 上的端口 8080 只能從使用 Bar 服務帳戶的服務接收 mTLS 流量”，更多。（請參閱完整的策略文檔 »）

• https://linkerd.io/2.11/features/server-policy/

重試帶有正文的 HTTP 請求

重試失敗的請求是 Linkerd 提高 Kubernetes 應用程序可靠性能力的關鍵部分。到目前為止，出於性能原因，Linkerd 只允許重試無正文請求，例如 HTTP GET。在 2.11 中，Linkerd 還可以重試帶有 body 的失敗請求，包括 gRPC 請求，最大 body 大小為 64KB。

容器啟動排序解決方法

Linkerd 2.11 現在默認確保 linkerd2-proxy 容器在 pod 中的任何其他容器初始化之前准備就緒。這是 Kubernetes 對容器啟動順序缺乏控制的一種解決方法，並解決了一大類棘手的競爭條件，即應用程序容器在代理准備就緒之前嘗試連接。

更小、更快、更輕

像往常一樣，Linkerd 2.11 繼續讓 Linkerd 成為 Kubernetes 最輕、最快的服務網格。2.11 中的相關變化包括：

• 控制平面(control plane)減少到只有 3 個部署。
• 由於高度活躍的 Rust 網絡生態系統，Linkerd 的數據平面(data plane) “微代理(micro-proxy)” 更小、更快。
• SMI 功能大部分已從核心控制平面中刪除，並移至擴展中。
• Linkerd 鏡像現在使用最小的 “distroless” 基礎鏡像。

還有更多！

Linkerd 2.11 還包含大量其他改進、性能增強和錯誤修復，包括：

• Kubernetes 資源的新 CLI tab completion(命令自動完成)。
• 現在可以在 Namespace 資源上設置所有 config.linkerd.io annotations，它們將作為在該命名空間中創建的 pod 的默認值。
• 一個 linkerd check -o short 帶有簡短輸出的新命令。
• Dashboard 中的新 擴展(Extensions) 頁面
• 代理的模糊測試(Fuzz testing)！
  • https://linkerd.io/2021/05/07/fuzz-testing-for-linkerd/
• 代理現在設置信息性的 l5d-client-id 和 l5d-proxy-error header。
• 對 Helm 可配置性和 linkerd check 進行了大量改進。
• 使用 linkerd-multicluster 對 StatefulSets 的實驗支持
• 還有更多！

有關詳細信息，請參閱完整的發行版說明

• https://github.com/linkerd/linkerd2/releases/tag/stable-2.11.0。

公眾號：黑客下午茶