本篇文章以 Linkerd 2.11.2 為主 (2022/05/29)。
最近在工作上需要在 K8S 集群導入 Service Mesh，於是在這方面做了一點功課，相信你對於 Service Mesh 有初步了解的話，應該都聽過 Istio 這套最知名的 Service Mesh 工具。但本章將著重於介紹 Linkerd ，原因是在功能面向以及需求的考慮之後，認為 Linkerd 會比較符合我們的場景（相對 Istio 來說較輕量、快速，有興趣比較可以參考這篇文章），當然不可否認 Istio 這套 Service Mesh 真的是很強大。
首先，先簡單介紹下 Linkerd，Linkerd 是為了 kubernetese 所建置的 Service Mesh ，官網描述如下：
Linkerd is a service mesh for Kubernetes. It makes running services easier and safer by giving you runtime debugging, observability, reliability, and security — all without requiring any changes to your code.
其主要提供下列功能：
- Observability (可觀察性): Service-level golden metrics: success rates, latencies, throughput. Service topologies. 提供一些 service 之間的指標，像是請求成功的比例、各種不同等級的延遲、service 間的拓墣。
- Reliability (可靠性): Retries, timeouts, load balancing, circuit breaking，這些都是 Service Mesh 滿基本的功能應該不用我多提了，比較可惜的是在目前還不支持像是 Istio 提供的 traffic routing (根據header或是path 決定路由)，但是其支持 traffic splitting (canary deployment/blue-green deployment)
- Security(安全性): Transparent mTLS, policy，所有 meshed 的 pod 之間的TCP 連線預設都啟用 mTLS。
以上功能已經滿足了我們團隊對於 Service Mesh 的期許，其輕量化、易結合、管理、使用的特色，也是我們最後決定採用 Linkerd 的原因。
在引入過程中，有幾個面向需要考量到，過程中也遇到了些問題，在下方做個紀錄。
Monitoring(Prometheus/Grafana)
除了安裝 linkerd 本身外，也需要安裝 linkerd-viz 這個套件於集群中，幫助我們更好的視覺化 proxy 收集到的數據。
這個套件裡面包含了幾個部分，除了 linkerd 核心的 dashboard，也自帶了常見的 Prometheus、Grafana 兩個 Monitoring 的工具：
This metrics stack may require significant cluster resources. Prometheus, in particular, will consume resources as a function of traffic volume within the cluster.
Additionally, by default, metrics data is stored in a transient manner that is not resilient to pod restarts or to node outages. See Bringing your own Prometheus for one way to address this.
文件上也描述說你可以使用原先集群已經有的 Prometheus 以及 Grafana，可以參考下列文件來進行配置 :
- Bringing your own Prometheus : https://linkerd.io/2.11/tasks/external-prometheus/
- Grafana : https://linkerd.io/2.11/tasks/grafana/#hook-grafana-with-linkerd-viz-dashboard
由於筆者集群已經預先通過 kube-prometheus 安裝好 Prometheus 了，所以就跟著上面的文件操作了一遍，如果你也參考文件的話，步驟大致如下：
- 確保你的 Prometheus 有配置好 scrape linkerd metrics 的配置
2. 你透過 Helm 或是 cli 方式安裝的 Prometheus url 要配置正確的 URL 以及 Port
以上兩點是官網提及的地方，但筆者本身還遇到了配置好後 Prometheus 沒有出現相應指標的問題，看了一下 Prometheus 的 pod 日誌，發現是 Prometheus 的 cluster role 沒有權限去抓取對應 namespace 的 metrics，在增加相關權限後，成功出現了對應的指標。
Ingress
在 Ingress 部分，我知道 Istio 有提供 Ingress Gateway，但是 Linkerd 在設計時考量到與其他 Ingress Controller結合，而不自己開發 Ingress 功能（讚讚讚），
(From 官網 ，https://linkerd.io/2.11/features/ingress/)
For reasons of simplicity, Linkerd does not provide its own ingress controller. Instead, Linkerd is designed to work alongside your ingress controller of choice.
See the Using Ingress with Linkerd Guide for examples of how to get it all working together.
因此我們可以原先集群預設使用的 Ingress Controller，但筆者的集群中用的是 Kong API Gateway，而不是常見的 Nginx ingress controller 或是 AWS load balancer controller，因此在這方面我們也做了相關的測試，目前除了 Distributed tracing 還沒測試之外，其他功能在 meshed kong pods 之後運作都正常，也有相關的 metrics 請求數據。
Network Policy
在 Network Policy 方面，如果你有結合像是 cilium 之類 Network Policy 的功能，請注意要於你 meshed 的 pod 的 CiliumNetworkPolicy 內加下列的 ingress 規則：
- fromEndpoints:
- matchLabels:
io.kubernetes.pod.namespace: linkerd-viz### （如果你沒有自帶 Prometheus 的話，使用 linkerd-viz 預設的 Prometheus，則下面可以省略，只添加上面三行，如果你使用自己的 Prometheus，下面的 monitorin g 要改成 Prometheus 所在的 namespace）
- fromEndpoints:
- matchLabels:
io.kubernetes.pod.namespace: monitoring
如果沒有允許上面的 ingress 規則，雖然不影響 linkerd-proxy 正常運作，但有些 linkerd dashboard 上面的數據會無法正常顯示。
linkerd 2 vs 1 的差異 (待補充)
在下面幾篇文章，我會花些時間研究、介紹下 linkerd、linkerd-viz 是怎麼運作的，裡面包含了哪些組件，更深入的去研究這神奇的 Service Mesh 工具。
這邊先留個問題問大家，service mesh 是怎麼做到攔截流量、流量轉發、提供 latency 、success rate 數據之類的功能的？主要是靠哪個技術去實踐？
這題應該會有不同的答案，就列出你心目中的那一個吧😛
(2022.08.10 updated)
最近在遷移集群部署linkerd時又遇到了一個坑，嚴格來說不是 linkerd 的錯，如果有在使用 kustomize 的話，如果裡面填寫 namespace 的話，在部署 linkerd-viz 時很有可能會覆蓋掉下面 RoleBinding 的 namespace，如果你在部署完發現 tap 這個 pod 一直處於 Crashloop 的情況下，可以檢查 tap 的日誌，看是否遇到這個問題。
apiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata: name: linkerd-linkerd-viz-tap-auth-reader namespace: kube-systemlabels: linkerd.io/extension: viz component: tap namespace: linkerd-vizroleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: extension-apiserver-authentication-readersubjects:- kind: ServiceAccount name: tap namespace: linkerd-viz
