26、Linkerd：轻量级服务网格的崛起与实践

Linkerd：轻量级服务网格的崛起与实践

1. Linkerd简介

Linkerd是一个由CNCF孵化毕业的项目，采用Apache v2许可协议。Buoyant（https://buoyant.io/）是Linkerd的主要贡献者。它可能是最早的服务网格技术之一。最初在2017年由Buoyant公开发布，虽初期取得了一定成功，但因资源消耗大而受到批评。早期的Linkerd代理使用Scala和Java网络生态编写，运行时依赖Java虚拟机（JVM），导致显著的资源消耗。

2018年，Buoyant发布了名为Conduit的新版本Linkerd，后更名为Linkerd v2。Linkerd v2的数据平面由Linkerd2 - proxy组成，它用Rust编写，资源消耗小，专为Kubernetes Pod中的边车代理而设计。而Linkerd控制平面则用Golang开发。

2. 在minikube上安装Linkerd

以下是在minikube上安装Linkerd的详细步骤：
1. 安装Linkerd CLI ：

% curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh

安装完成后，将Linkerd CLI添加到路径中：

export PATH=$PATH:/Users/arai/.linkerd2/bin

2. 检查Kubernetes集群是否满足安装前提条件 ：

% linkerd check --pre

如果输出包含 Status check results are √ ，则可以继续安装；否则，需根据https://linkerd.io/2.12/tasks/troubleshooting/#pre - k8s - cluster - k8s%20for%20hints 中的建议解决问题。
3. 安装Linkerd ：
- 安装CRDs ：

% linkerd install --crds | kubectl apply -f -

- **安装Linkerd控制平面**：

% linkerd install --set proxyInit.runAsRoot=true | kubectl apply -f -

4. 检查Linkerd是否安装成功 ：

% linkerd check

如果安装成功，将看到 Status check results are √ 。

安装完成后，可通过以下命令查看安装的Pod和服务：

% kubectl get pods,services -n linkerd

Linkerd控制平面由多个Pod和服务组成，各组件功能如下：
| 组件名称 | 功能描述 |
| ---- | ---- |
| linkerd - identity | 为Linkerd代理生成签名证书的CA |
| linkerd - proxy - injector | Kubernetes准入控制器，负责修改Kubernetes Pod规范以添加linkerd - proxy和proxy - init容器 |
| destination服务 | Linkerd控制平面的核心，维护服务发现、服务身份信息以及用于保护和管理网格中流量的策略 |

3. 在Linkerd中部署envoydemo和curl应用

部署envoydummy和curl应用并检查Linkerd的服务网格功能，步骤如下：
1. 添加注解 ：
在部署描述符中添加以下注解：

annotations:
    linkerd.io/inject: enabled

envoydummy和curl应用的配置文件及注解可在AppendixA/Linkerd/envoy - proxy - 01.yaml中找到。
2. 应用配置 ：

% kubectl create ns appendix - linkerd
% kubectl apply -f AppendixA/Linkerd/envoy - proxy - 01.yaml

3. 检查注入的容器 ：

% kubectl get po/curl -n appendix - linkerd -o json | jq '.spec.initContainers[].image, .spec.initContainers[].name'
% kubectl get po/curl -n appendix - linkerd -o json | jq '.spec.containers[].image, .spec.containers[].name'

从输出可以看出，Pod初始化由 cr.l5d.io/linkerd/proxy - init:v2.0.0 类型的 linkerd - init 容器执行，Pod中有两个运行的容器： curl 和 linkerd - proxy ， linkerd - proxy 采用 cr.l5d.io/linkerd/proxy:stable - 2.12.3 类型。 linkerd - init 容器在Pod初始化阶段运行，修改iptables规则，将所有网络流量从 curl 路由到 linkerd - proxy 。

4. 验证通信 ：

% kubectl exec -it pod/curl -c curl -n appendix - linkerd -- curl http://envoydummy:80

下面是部署envoydemo和curl应用的流程图：

graph LR
    A[添加注解] --> B[应用配置]
    B --> C[检查注入的容器]
    C --> D[验证通信]

4. Linkerd的零信任网络

Linkerd提供了全面的策略来限制网格中的流量，通过一组CRDs定义策略来控制流量。以下是控制到envoydummy Pod流量的策略实现步骤：
1. 锁定集群中的所有流量 ：

% linkerd upgrade --default - inbound - policy deny --set proxyInit.runAsRoot=true | kubectl apply -f -

应用此策略后，所有对envoydummy服务的访问将被拒绝：

% kubectl exec -it pod/curl -c curl -n appendix - linkerd -- curl --head http://envoydummy:80

2. 创建服务器资源 ：
   定义一个服务器资源来描述envoydummy端口，配置文件如下：

apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata:
    namespace: appendix - linkerd
    name: envoydummy
    labels:
        name: envoydummy
spec:
    podSelector:
        matchLabels:
            name: envoydummy
    port: envoydummy - http
    proxyProtocol: HTTP/1

配置文件可在AppendixA/Linkerd/envoydummy - server.yaml中找到，应用该配置：

% kubectl apply -f AppendixA/Linkerd/envoydummy - server.yaml

3. 创建授权策略 ：
   创建一个授权策略，允许 curl 访问 envoydummy ，配置文件如下：

apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
    name: authorise - curl
    namespace: appendix - linkerd
spec:
    targetRef:
        group: policy.linkerd.io
        kind: Server
        name: envoydummy
    requiredAuthenticationRefs:
        - name: curl
          kind: ServiceAccount

配置文件可在AppendixA/Linkerd/authorize - curl - access - to - envoydummy.yaml中找到，应用该配置：

% kubectl apply -f AppendixA/Linkerd/authorize - curl - access - to - envoydummy.yaml

4. 验证访问 ：

% kubectl exec -it pod/curl -c curl -n appendix - linkerd -- curl http://envoydummy:80

5. 基于HTTPRoute的细粒度访问控制

为了实现更细粒度的访问控制，例如只允许URI以 /dummy 开头的请求从 curl 访问，可按以下步骤操作：
1. 定义HTTPRoute策略 ：

apiVersion: policy.linkerd.io/v1beta1
kind: HTTPRoute
metadata:
    name: envoydummy - dummy - route
    namespace: appendix - linkerd
spec:
    parentRefs:
        - name: envoydummy
          kind: Server
          group: policy.linkerd.io
          namespace: appendix - linkerd
    rules:
        - matches:
            - path:
                value: "/dummy/"
                type: "PathPrefix"
              method: GET

配置文件可在AppendixA/Linkerd/HTTPRoute.yaml中找到。
2. 修改授权策略 ：
将授权策略关联到HTTPRoute，配置文件如下：

apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata:
    name: authorise - curl
    namespace: appendix - linkerd
spec:
    targetRef:
        group: policy.linkerd.io
        kind: HTTPRoute
        name: envoydummy - dummy - route
    requiredAuthenticationRefs:
        - name: curl
          kind: ServiceAccount

配置文件可在AppendixA/Linkerd/HttpRouteAuthorization.yaml中找到。

应用这两个配置后，只有URI以 /dummy 开头的请求才能从 curl 访问。

Linkerd还支持其他认证类型，如MeshTLSAuthentication和NetworkAuthentication：
- MeshTLSAuthentication ：基于客户端的网格身份进行识别，例如 curl Pod表示为 curl.appendix - linkerd.serviceaccount.identity.linkerd.local 。
- NetworkAuthentication ：基于客户端的网络位置，使用无类域间路由（CIDR）块进行识别。

此外，Linkerd提供重试和超时机制以增强应用的弹性，支持使用指数加权移动平均（EWMA）算法进行自动负载均衡，还支持基于权重的流量拆分，使用Service Mesh Interface（SMI）Traffic Split API，方便进行金丝雀和蓝绿部署。

Linkerd的超轻量级服务代理使用Rust构建，性能卓越，精心设计用于解决应用网络问题。但它在某些功能上存在不足，如断路器和速率限制，希望其开发者能缩小与Envoy的差距。

Linkerd：轻量级服务网格的崛起与实践

6. Linkerd 的重试和超时机制

Linkerd 提供重试和超时机制，以增强应用在系统压力或部分故障时的弹性。除了支持常见的重试策略外，还允许指定重试预算，避免重试加剧弹性问题。

6.1 重试机制

重试机制可确保在请求失败时进行重试，提高请求的成功率。例如，当服务暂时不可用时，Linkerd 可以自动重试请求。以下是一个简单的重试配置示例：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-dr
spec:
  host: my-service
  trafficPolicy:
    retry:
      attempts: 3
      perTryTimeout: 2s

在上述示例中，当请求 my-service 失败时，Linkerd 会尝试重试 3 次，每次重试的超时时间为 2 秒。

6.2 超时机制

超时机制可避免请求长时间挂起，提高系统的响应性能。例如，当服务响应时间过长时，Linkerd 可以在达到超时时间后终止请求。以下是一个简单的超时配置示例：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-service-vs
spec:
  hosts:
    - my-service
  http:
    - route:
        - destination:
            host: my-service
      timeout: 5s

在上述示例中，当请求 my-service 的时间超过 5 秒时，Linkerd 会终止请求。

7. Linkerd 的负载均衡

Linkerd 支持使用指数加权移动平均（EWMA）算法进行自动负载均衡，将请求均匀地分配到所有目标端点。此外，它还支持基于权重的流量拆分，使用 Service Mesh Interface（SMI）Traffic Split API，方便进行金丝雀和蓝绿部署。

7.1 EWMA 负载均衡

EWMA 算法根据端点的历史性能动态调整负载分配，确保请求被分配到性能较好的端点。以下是一个简单的 EWMA 负载均衡配置示例：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-service-dr
spec:
  host: my-service
  trafficPolicy:
    loadBalancer:
      simple: EWMA

在上述示例中，Linkerd 会使用 EWMA 算法对 my-service 的请求进行负载均衡。

7.2 基于权重的流量拆分

基于权重的流量拆分允许将流量按比例分配到不同的服务版本，方便进行金丝雀和蓝绿部署。以下是一个简单的流量拆分配置示例：

apiVersion: split.smi-spec.io/v1alpha4
kind: TrafficSplit
metadata:
  name: my-service-split
spec:
  service: my-service
  backends:
    - service: my-service-v1
      weight: 80
    - service: my-service-v2
      weight: 20

在上述示例中，80% 的流量将被分配到 my-service-v1 ，20% 的流量将被分配到 my-service-v2 。

8. Linkerd 与其他服务网格的比较

Linkerd 与其他服务网格（如 Istio、Consul、Kuma 等）有很多相似之处，但也有其独特的特点。以下是 Linkerd 与其他服务网格的比较：
| 服务网格 | 特点 |
| ---- | ---- |
| Linkerd | 超轻量级，性能卓越，使用 Rust 构建代理；功能相对较少，如缺乏断路器和速率限制 |
| Istio | 功能丰富，社区庞大，支持多种插件和扩展；资源消耗较大 |
| Consul | 与 HashiCorp 生态集成良好，提供服务发现和配置管理；对 Kubernetes 的集成相对较弱 |
| Kuma | 易于使用，提供多集群支持；功能相对较少 |

9. 总结与展望

Linkerd 作为一个超轻量级的服务网格，具有出色的性能和精心设计的架构，能够有效解决应用网络问题。它提供了丰富的功能，如零信任网络、重试和超时机制、负载均衡和流量拆分等，方便进行应用的部署和管理。

然而，Linkerd 在某些功能上还存在不足，如断路器和速率限制。希望其开发者能够不断完善这些功能，缩小与 Envoy 等其他服务网格的差距。

未来，随着微服务架构的不断发展，服务网格的需求将越来越大。Linkerd 有望在这个领域发挥更大的作用，为开发者提供更加高效、可靠的服务网格解决方案。

以下是 Linkerd 功能的总结表格：
| 功能 | 描述 |
| ---- | ---- |
| 零信任网络 | 通过 CRDs 定义策略，限制网格中的流量 |
| 重试和超时机制 | 增强应用在系统压力或部分故障时的弹性 |
| 负载均衡 | 使用 EWMA 算法进行自动负载均衡，支持基于权重的流量拆分 |
| 细粒度访问控制 | 通过 HTTPRoute 策略实现更细粒度的访问控制 |

下面是 Linkerd 主要功能的流程图：

graph LR
    A[零信任网络] --> B[重试和超时机制]
    B --> C[负载均衡]
    C --> D[细粒度访问控制]

总之，Linkerd 是一个值得关注的服务网格技术，它为开发者提供了一种轻量级、高性能的解决方案，能够帮助开发者更好地管理和保护微服务应用。