Linkerd2.10中文手册正在修订更新中：https://linkerd.hacker-linner.comLinkerd数据平面代理是多线程的，可以运行可变数量的工作线程所以他们的资源使用与应用程序工作负载相匹配。当然，在真空中，当允许使用尽可能多的CPU内核时，代理将表现出最佳吞吐量和最低延迟。然而，在实践中，还需要考虑其他因素。真实世界的部署不是负载测试，客户端和服务器除了用请求使代理饱和外没有其他工作可做。相比之下，服务网格模型将代理实例部署为应用程序容器的边车。每个代理只处理进出它注入的pod的流量。这意味着吞吐量和延迟受应用程序工作负载的限制。如果应用程序容器实例每秒只能处理这么多请求，那么代理可以处理更多请求可能并不重要。事实上，为代理提供比跟上应用程序所需的更多CPU内核会损害整体性能，因为应用程序可能不得不与代理竞争有限的系统资源。因此，对于单个代理而言，有效处理其流量比配置所有代理以处理最大可能负载更为重要。调整代理资源使用的主要方法是限制代理用于转发流量的工作线程数。有多种方法可以做到这一点。使用proxy-cpu-limit注解配置代理线程池的最简单方法是使用config.linkerd.io/proxy-cpu-limit注解。这个注释配置代理注入器来设置一个环境变量来控制代理将使用的CPU核心数。使用linkerdinstallCLI命令安装Linkerd时，--proxy-cpu-limit参数会为Linkerd安装注入的所有代理全局设置此注释。例如，linkerdinstall--proxy-cpu-limit2|kubectlapply-f-对于更细粒度的配置，可以将注释添加到任何可注入的Kubernetes资源，例如命名空间、pod或部署。例如，以下将配置my-deployment部署中的代理使用1个CPU核心：kind:DeploymentapiVersion:apps/v1metadata:name:my-deployment#...spec:template:metadata:annotations:config.linkerd。io/proxy-cpu-limit:'1'#...与KubernetesCPU限制和请求可以用milliCPU表示不同，proxy-cpu-limit注解应该用CPU核的整数表示。小数值将四舍五入到最接近的整数。使用KubernetesCPU限制和请求Kubernetes提供CPU限制和CPU请求来配置分配给任何pod或容器的资源。这些也可用于配置Linkerd代理的CPU使用率。但是，根据kubelet的配置方式，使用Kubernetes资源限制而不是proxy-cpu-limit注释可能并不理想。kubelet使用两种机制中的一种来强制执行podCPU限制。这由--cpu-manager-policykubelet选项决定。使用默认的CPU管理器策略none，kubelet使用CFS配额来强制执行CPU限制。这意味着Linux内核被配置为限制属于给定进程的线程被调度的时间量。或者，可以将CPU管理器策略设置为静态。在这种情况下，kubelet将使用Linuxcgroups对满足特定条件的容器实施CPU限制。当未设置proxy-cpu-limit注释配置环境变量时，代理将运行与可用CPU内核数相等的工作线程数。这意味着使用默认的noneCPU管理器策略，代理可能会生成大量工作线程，但Linux内核会限制它们的调度频率。这不如像proxy-cpu-limit那样简单地减少工作线程的数量：更多的时间花在上下文切换上，每个工作线程运行的频率会降低，这会影响延迟。另一方面，使用cgroupcpusets会限制进程可用的CPU核心数。本质上，代理认为系统的CPU内核比实际少。这将导致与proxy-cpu-limit注释类似的行为。但是，值得注意的是，要使用此机制，必须满足某些条件：kubelet必须配置静态CPU管理器策略，并且pod必须属于GuaranteedQoS类。这意味着pod中的所有容器必须同时具有内存和CPU限制和请求，并且每个限制必须与请求具有相同的值。CPUlimit和CPUrequest必须是大于或等于1的整数。如果您不确定是否会全部满足这些条件，最好在任何KubernetesCPU限制和请求之外使用proxy-cpu-limit注释。使用Helm时，如果不满足上述基于cgroup的CPU限制条件，用户必须注意设置proxy.coresHelm变量和proxy.cpu.limit以外的变量。
