当前位置: 首页 > 文档资料 > Kubernetes 指南 >

Service Mesh - Linkerd

优质
小牛编辑
131浏览
2023-12-01

Linkerd是一个面向云原生应用的Service Mesh组件,也是CNCF项目之一。它为服务间通信提供了一个统一的管理和控制平面,并且解耦了应用程序代码和通信机制,从而无需更改应用程序就可以可视化控制服务间的通信。linkerd实例是无状态的,可以以每个应用一个实例(sidecar)或者每台Node一个实例的方式部署。

Linkerd - 图1

Linkerd的主要特性包括

  • 服务发现
  • 动态请求路由
  • HTTP代理集成,支持HTTP、TLS、gRPC、HTTP/2等
  • 感知时延的负载均衡,支持多种负载均衡算法,如Power of Two Choices (P2C) Least Loaded、Power of Two Choices (P2C) peak ewma、Aperture: least loaded、Heap: least loaded、Round robin等
  • 熔断机制,自动移除不健康的后端实例,包括fail fast(只要连接失败就移除实例)和failure accrual(超过5个请求处理失败时才将其标记为失效,并保留一定的恢复时间 )两种
  • 分布式跟踪和度量

Linkerd原理

Linkerd路由将请求处理分解为多个步骤

  • (1) IDENTIFICATION:为实际请求设置逻辑名字(即请求的目的服务),如默认将HTTP请求GET http://example/hello赋值名字/svc/example
  • (2) BINDING:dtabs负责将逻辑名与客户端名字绑定起来,客户端名字总是以/#/$开头,比如
  1. # 假设dtab为
  2. /env => /#/io.l5d.serversets/discovery
  3. /svc => /env/prod
  4. # 那么服务名/svc/users将会绑定为
  5. /svc/users
  6. /env/prod/users
  7. /#/io.l5d.serversets/discovery/prod/users
  • (3) RESOLUTION:namer负责解析客户端名,并得到真实的服务地址(IP+端口)
  • (4) LOAD BALANCING:根据负载均衡算法选择如何发送请求

Linkerd - 图2

Linkerd部署

Linkerd以DaemonSet的方式部署在每个Node节点上:

  1. # Deploy linkerd.
  2. # For CNI, deploy linkerd-cni.yml instead.
  3. # kubectl apply -f https://github.com/linkerd/linkerd-examples/raw/master/k8s-daemonset/k8s/linkerd-cni.yml
  4. kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/linkerd.yml
  5. # Deploy linked-viz.
  6. kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-viz/master/k8s/linkerd-viz.yml

默认情况下,Linkerd的Dashboard监听在每个容器实例的9990端口,可以通过服务的相应端口来访问。

  1. INGRESS_LB=$(kubectl get svc l5d -o jsonpath="{.status.loadBalancer.ingress[0].*}")
  2. echo "open http://$INGRESS_LB:9990 in browser"
  3. VIZ_INGRESS_LB=$(kubectl get svc linkerd-viz -o jsonpath="{.status.loadBalancer.ingress[0].*}")
  4. echo "open http://$VIZ_INGRESS_LB in browser"

对于不支持LoadBalancer的集群,可以通过NodePort来访问

  1. HOST_IP=$(kubectl get po -l app=l5d -o jsonpath="{.items[0].status.hostIP}")
  2. echo "open http://$HOST_IP:$(kubectl get svc l5d -o 'jsonpath={.spec.ports[2].nodePort}') in browser"

应用程序在使用Linkerd时需要为应用设置HTTP代理,其中

  • HTTP使用$(NODE_NAME):4140
  • HTTP/2使用$(NODE_NAME):4240
  • gRPC使用$(NODE_NAME):4340

在Kubernetes中,可以使用Downward API来获取NODE_NAME,比如

  1. env:
  2. - name: NODE_NAME
  3. valueFrom:
  4. fieldRef:
  5. fieldPath: spec.nodeName
  6. - name: http_proxy
  7. value: $(NODE_NAME):4140

开启TLS

  1. kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/certificates.yml
  2. kubectl delete ds/l5d configmap/l5d-config
  3. kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/linkerd-tls.yml

Zipkin

  1. # Deploy zipkin.
  2. kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/zipkin.yml
  3. # Deploy linkerd for zipkin.
  4. kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/linkerd-zipkin.yml
  5. # Get zipkin endpoint.
  6. ZIPKIN_LB=$(kubectl get svc zipkin -o jsonpath="{.status.loadBalancer.ingress[0].*}")
  7. echo "open http://$ZIPKIN_LB in browser"

Ingress Controller

Linkerd也可以作为Kubernetes Ingress Controller使用,注意下面的步骤将Linkerd部署到了l5d-system namespace。

  1. kubectl create ns l5d-system
  2. kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/linkerd-ingress-controller.yml -n l5d-system
  3. L5D_SVC_IP=$(kubectl get svc l5d -n l5d-system -o jsonpath="{.status.loadBalancer.ingress[0].*}")
  4. echo "open http://$L5D_SVC_IP:9990 in browser"

Linkerd使用示例

接下来部署两个测试服务。

首先验证Kubernetes集群是否支持nodeName,正常情况下node-name-test容器会输出一个nslookup解析后的IP地址:

  1. kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/node-name-test.yml
  2. kubectl logs node-name-test

然后部署hello world示例:

  1. kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/hello-world.yml
  2. kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/world-v2.yml

通过Linkerd代理访问服务

  1. $ http_proxy=$INGRESS_LB:4140 curl -s http://hello
  2. Hello (10.12.2.5) world (10.12.0.6)!!

如果开启了Linkerd ingress controller,那么可以继续创建Ingress:

  1. kubectl apply -f https://raw.githubusercontent.com/linkerd/linkerd-examples/master/k8s-daemonset/k8s/hello-world-ingress.yml
  2. curl ${L5D_SVC_IP}
  3. curl -H "Host: world.v2" $L5D_SVC_IP

Conduit

Conduit 是 Buoyant 公司推出的下一代轻量级 service mesh。与 linkerd 不同的是,它专用于 Kubernetes 集群中,并且比 linkerd 更轻量级(基于 Rust 和 Go,没有了 JVM 等大内存的开销),可以以 sidecar 的方式把代理服务跟实际服务的 Pod 运行在一起(这点跟 Istio 类似)。

  1. $ curl https://run.conduit.io/install | bash
  2. ..
  3. .
  4. Conduit was successfully installed ?
  5. $ conduit install | kubectl apply -f -
  6. ..
  7. .
  8. namespace "conduit" created...
  9. $ conduit dashboard
  10. Running `kubectl proxy --port=8001`... |
  11. # Install a demo app
  12. $ curl https://raw.githubusercontent.com/runconduit/conduit-examples/master/emojivoto/emojivoto.yml | conduit inject - --skip-inbound-ports=80 | kubectl apply -f -

参考文档

最后更新:

类似资料

  • 我们使用的是 K8s 集群,但我们没有集群级别的权限,因此我们只能在命名空间上创建 和 ,并且只需要在命名空间中安装服务网格解决方案(Istio 或 Linkerd)。 我们的运营团队将同意为我们在集群上应用CRDs,因此该部分得到了处理,但是我们不能请求集群管理权限来设置服务网格解决方案。 我们认为,如果我们在 Helm 图表上将所有 s 和 s 更改为 s 和 s,那么应该可以做到这一点。 所

  • 我已经部署了一个Linkerd服务网格,我的库伯内特斯集群配置了Nginx入口控制器作为DaemonSet,所有入口也可以在Linkerd上正常工作。最近,我添加了一个流量拆分功能来运行我的蓝色/绿色设置,我可以使用单独的入口资源访问这些服务。我创建了一个顶点Web服务,如下所述。如果我在内部联系到您此服务,它会完美运行。我创建了另一个入口资源,我无法在集群之外测试蓝色/绿色功能。我想提一下,我已

  • 本文是 Linkerd 使用指南,我们着重讲解在 kubernetes 中如何使用 linkerd 作为 kubernetes 的 Ingress controller。 前言 Linkerd 作为一款 service mesh 与kubernetes 结合后主要有以下几种用法: 作为服务网关,可以监控 kubernetes 中的服务和实例 使用 TLS 加密服务 通过流量转移到持续交付 开发测试

  • 注意:Linkerd最初版本是使用Scala开发的,现在已开始开发Linkerd2,使用Go语言开发,该公司的另一款轻量级Service Mesh conduit也寿终正寝,合并入Linkerd 2.0,详见Conduit 0.5发布—以及R.I.P. Conduit。 Linkerd是一个用于云原生应用的开源、可扩展的service mesh(一般翻译成服务网格,还有一种说法叫”服务啮合层“,见

  • Linkerd 是一个提供弹性云端原生应用服务网格的开源项目。其核心是一个透明代理,可以用它来实现一个专用的基础设施层以提供服务间的通信,进而为软件应用提供服务发现、路由、错误处理以及服务可见性等功能,而无需侵入应用内部本身的实现。

  • 原文: LINKERD: TWITTER-STYLE OPERABILITY FOR MICROSERVICES 作者: WILLIAM MORGAN, 时间: 2016-02-18 您如何大规模运维现代云原生应用程序?在实践中出现什幺问题,而他们是如何被处理? 在大容量和不可预测的工作负载下,运行基于云原生和微服务的应用程序实际需要什幺,而不会对功能版本或产品更改引入摩擦? 对于所有关于微服务的

开发工具

Linkerdlinkerd2