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。

公众号：黑客下午茶