# Linkerd簡介 > **注意**：Linkerd最初版本是使用Scala開發的，現在已開始開發Linkerd2，使用Go語言開發，該公司的另一款輕量級Service Mesh conduit也壽終正寢，合并入Linkerd 2.0，詳見[Conduit 0.5發布—以及R.I.P. Conduit](http://www.servicemesher.com/blog/rip-conduit/)。 Linkerd是一個用于云原生應用的開源、可擴展的service mesh（一般翻譯成服務網格，還有一種說法叫”服務嚙合層“，見[Istio：用于微服務的服務嚙合層](http://www.infoq.com/cn/news/2017/05/istio)）。 ## Linkerd是什么 Linkerd的出現是為了解決像twitter、google這類超大規模生產系統的復雜性問題。Linkerd不是通過控制服務之間的通信機制來解決這個問題，而是通過在服務實例之上添加一個抽象層來解決的。  Linkerd負責跨服務通信中最困難、易出錯的部分，包括延遲感知、負載平衡、連接池、TLS、儀表盤、請求路由等——這些都會影響應用程序伸縮性、性能和彈性。 ## 如何運行 Linkerd作為獨立代理運行，無需特定的語言和庫支持。應用程序通常會在已知位置運行linkerd實例，然后通過這些實例代理服務調用——即不是直接連接到目標服務，服務連接到它們對應的linkerd實例，并將它們視為目標服務。 在該層上，linkerd應用路由規則，與現有服務發現機制通信，對目標實例做負載均衡——與此同時調整通信并報告指標。 通過延遲調用linkerd的機制，應用程序代碼與以下內容解耦： - 生產拓撲 - 服務發現機制 - 負載均衡和連接管理邏輯 應用程序也將從一致的全局流量控制系統中受益。這對于多語言應用程序尤其重要，因為通過庫來實現這種一致性是非常困難的。 Linkerd實例可以作為sidecar（既為每個應用實體或每個主機部署一個實例）來運行。 由于linkerd實例是無狀態和獨立的，因此它們可以輕松適應現有的部署拓撲。它們可以與各種配置的應用程序代碼一起部署，并且基本不需要去協調它們。 ## 詳解 Linkerd 的基于 Kubernetes 的 Service Mesh 部署方式是使用 Kubernetes 中的 **DaemonSet** 資源對象，如下圖所示。  這樣 Kubernetes 集群中的每個節點都會運行一個 Linkerd 的 Pod。 但是這樣做就會有幾個問題： - 節點上的應用如何發現其所在節點上的 Linkerd 呢？ - 節點間的 Linkerd 如何路由的呢？ - Linkerd 如何將接收到的流量路由到正確的目的應用呢？ - 如何對應用的路有做細粒度的控制？ 這幾個問題在 Buoyant 公司的這篇博客中都有解答：[A Service Mesh for Kubernetes, Part II: Pods are great until they’re not](https://buoyant.io/2016/10/14/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/)，我們下面將簡要的回答上述問題。 ### 節點上的應用如何發現其所在節點上的 Linkerd 呢？ 簡而言之，是使用環境變量的方式，如在應用程序中注入環境變量 `http_proxy`： ```yaml env: - name: NODE_NAME valueFrom: fieldRef: fieldPath: spec.nodeName - name: http_proxy value: $(NODE_NAME):4140 args: - "-addr=:7777" - "-text=Hello" - "-target=world" ``` 這要求應用程序必須支持該環境變量，為應用程序所在的 Pod 設置了一個代理，實際上對于每種不同的協議 Linkerd 都監聽不同的端口。 - 4140 for HTTP - 4240 for HTTP/2 - 4340 for gRPC 關于 Linkerd 作為 Service Mesh 的詳細配置請參考 [serivcemesh.yml](https://github.com/rootsongjc/kubernetes-handbook/blob/master/manifests/linkerd/servicemesh.yml)。 ### 節點間的 Linkerd 如何路由的以及 Linkerd 如何將接收到的流量路由到正確的目的應用呢？ 通過 **transformer** 來確定節點間的 Linkerd 路由，參考下面的配置： ```yaml routers: - protocol: http label: outgoing interpreter: kind: default transformers: - kind: io.l5d.k8s.daemonset namespace: default port: incoming service: l5d ``` Router 定義 Linkerd 如何實際地處理流量。Router 監聽請求并在這些請求上應用路有規則，代理這些請求到正確的目的地。Router 是與協議相關的。對于每個 Router 都需要定義一個 incoming router 和一個 outcoming router。預計該應用程序將流量發送到 outcoming router，該 outcoming router 將其代理到目標服務節點上運行的 Linkerd 的 incoming router。Incoming router 后將請求代理給目標應用程序本身。我們還定義了 HTTP 和 HTTP/2 incoming router，它們充當 Ingress controller 并基于 Ingress 資源進行路由。 ### 如何對路由規則做細粒度的控制呢？ 路由規則配置是在 namerd 中進行的，例如： ```ini $ namerctl dtab get internal # version MjgzNjk5NzI= /srv => /#/io.l5d.k8s/default/http ; /host => /srv ; /tmp => /srv ; /svc => /host ; /host/world => /srv/world-v1 ; ``` Namerd 中存儲了很多 dtab 配置，通過這些配置來管理路有規則，實現微服務的流量管理。  如果將 Linkerd 作為*邊緣節點*還可以充當 Ingress controller，如下圖所示。  Linkerd 自己最令人稱道的是它在每臺主機上只安裝一個 Pod，如果使用 Sidecar 模式會為每個應用程序示例旁都運行一個容器，這樣會導致過多的資源消耗。[Squeezing blood from a stone: small-memory JVM techniques for microservice sidecars](https://buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/) 這篇文章中詳細說明了 Linkerd 的資源消耗與性能。 ## 參考 - [A Service Mesh for Kubernetes, Part II: Pods are great until they’re not](https://buoyant.io/2016/10/14/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/) - [Squeezing blood from a stone: small-memory JVM techniques for microservice sidecars](https://buoyant.io/2016/06/17/small-memory-jvm-techniques-for-microservice-sidecars/) - [Buoyant發布服務網格Linkerd的1.0版本](http://www.infoq.com/cn/news/2017/05/buoyant-release-ver-1-of-linkerd) - [Linkerd documentation](https://linkerd.io/documentation/) - [Istio：用于微服務的服務嚙合層](http://www.infoq.com/cn/news/2017/05/istio)