Linkerd 2.8 - 實現超級簡單又安全的多叢集 (multicluster) Kubernetes 架構

 关注
发布于: 2020 年 08 月 10 日
Linkerd 2.8 - 實現超級簡單又安全的多叢集(multicluster) Kubernetes 架構
嘗試過目前市面上現有的三套開源軟體(Linkerd, Consul, Istio)，決定推坑大家 Linkerd 在今年六月釋出的 Linkerd 2.8，實現了 multi-cluster Kubernetes 架構，我們來看看主打超輕量化 service mesh 的 Linkerd 會怎麼表現在 multi-cluster。
﻿
目前筆者在同一個 GCP 呼叫不同 cluster 的 service 都需要使用 internal load balancer，除了會增加許多額外的花費，internal load balancer 預設是能夠讓同一個 VPC 存取，代表任何 VM 都能使用這個 service，這當然不是我們所預期的行為。最重要的是很難維護，所以開始尋找有沒有 solution 可以解決這個問題。
可以從 Cluster-A 存取 Cluster-B 的 service
Cluster-B 可以決定要 expose 哪些 service 給特定的 cluster
connections 低延遲、穩定
configuration 越少越好
discover service fast
private connection with security
Install Linkerd這邊不會提到 cli 和 cluster setup，只會帶到 linkerd，更詳細的 script 會放在 https://github.com/RammusXu/toolkit/tree/master/k8s/linkerd-multi-cluster
﻿
其實只要三個指令就能讓兩個 cluster 相互溝通，可以看到 linkerd 在 cli 的設計，非常簡化、直覺。
﻿
linkerd install
linkerd multicluster install
linkerd --context=east multicluster link --cluster-name east | kubectl --context=west apply -f -
## Create CA certificate
step certificate create identity.linkerd.cluster.local root.crt root.key \
 --profile root-ca --no-password --insecure
step certificate create identity.linkerd.cluster.local issuer.crt issuer.key \
 --profile intermediate-ca --not-after 87600h --no-password --insecure \
 --ca root.crt --ca-key root.key
## Install Linkerd in every cluster
for ctx in $(kubectx); do
 kubectx ${ctx}
echo "Checking cluster: ${ctx} .........\n"
 linkerd install \
 --identity-trust-anchors-file root.crt \
 --identity-issuer-certificate-file issuer.crt \
 --identity-issuer-key-file issuer.key \
 | kubectl apply -f -
 linkerd check || break
echo "-------------\n"
done
## Install Linkerd multicluster component
for ctx in $(kubectx); do
echo "Installing on cluster: ${ctx} ........."
 linkerd --context=${ctx} multicluster install | \
 kubectl --context=${ctx} apply -f - || break
echo "-------------\n"
done
## Check multicluster gateways
for ctx in $(kubectx); do
echo "Checking gateway on cluster: ${ctx} ........."
 kubectl --context=${ctx} -n linkerd-multicluster \
 rollout status deploy/linkerd-gateway || break
 linkerd --context=${ctx} check --multicluster || break
 linkerd --context=${ctx} multicluster gateways
echo "-------------\n"
done
## Link cluster:east to cluster:west
linkerd --context=east multicluster link --cluster-name east |
 kubectl --context=west apply -f -
﻿
ShowtimeDashboard: 可以看到目前所有的 namespace 有多少 meshed(injected), SR, RPS, Latency，還能直接開啟 grafana 看更詳細的資訊。
﻿
點進 Namespace 可以看到 deployment 之間的關聯。
﻿
Deployment 後能看到所有進出的流量。
﻿
點擊右邊的 Tap，可以看到目前所有的 request，非常強大的 debug 工具。
﻿
分流的 yaml 也相當直覺
﻿
apiVersion: split.smi-spec.io/v1alpha1
kind: TrafficSplit
metadata:
  name: podinfo
  namespace: test
spec:
  service: podinfo
  backends:
  - service: podinfo
    weight: 50
  - service: podinfo-east
    weight: 50
﻿
grafana 即時顯示 SR, RPS, Latency
﻿
﻿
Benchmarkwrk Benchmark
﻿
這邊在 Cluster control 對 Cluster remote 的 podinfo 壓力測試
這邊比較的基準是直接用 type: LoadBalancer 產生一個 GKE L4 Load Balancer
linkerd 會在 Cluster control 產生一個 mirrored service podinfo-remote，透過兩邊的 linkerd-gateway 溝通
﻿
環境:
Cluster control: n2-highcpu-32 regional GKE in Taiwan
Cluster remote: n2-highcpu-32 regional GKE in Oregon
wrk -t10 -c500 -d30 --latency http://podinfo-remote:9898
wrk -t10 -c500 -d30 --latency http://34.83.93.113:9898
﻿
benchmark result
可以看到在 100 connections 也只增加了 7% 的延遲，已經能處理大部分的 micro service 使用場景。在 500 connections 增加了 50%，不過對於 cross region HA 的話，還算可以接受的範圍。
﻿
更多 linkerd vs istio 在 single cluster 的比較: https://linkerd.io/2019/05/18/linkerd-benchmarks
Other multi cluster solutionsConsulPod injection 大概會長這樣，比起 linkerd 多了 serviceAccount 的部分，任何需要到 remote 的 service 都要加入。
apiVersion: v1
kind: ServiceAccount
metadata:
  name: static-client
---
apiVersion: v1
kind: Pod
metadata:
  name: static-client
  annotations:
    'consul.hashicorp.com/connect-inject': 'true'
    'consul.hashicorp.com/connect-service-upstreams': 'static-server:1234:dc2'
spec:
  containers:
    - name: static-client
      image: tutum/curl:latest
      command: ['/bin/sh', '-c', '--']
      args: ['while true; do sleep 30; done;']
  serviceAccountName: static-client
﻿
不知道為什麼在 service discovery 的部分有時候會需要 2-3 分鐘。
Latency 多了 50% (Consul Gateway 比 L4 Load Balancer)。
Istio跟著 tutorial 做完，也無法連到另外一個 cluster 的服務
用 GKE addon 或是最新版的 istioctl 都無法部署成功
目前的問題只能接受 HTTP trafic
感想不知道是不是先有了部署 Istio 和 Consul 的經驗，部署 linkerd 大概只花了 20-30 分鐘，也可能因為是剛出的文章，所以跑完 tutorial 後能夠正確地顯示結果。相比 Consul 的 tutorial 漏了一堆 configuration，還需要查其他文件才能正確部署成功（大概花了 3-4 小時吧）。Istio 則是完全沒有任何線索繼續。
﻿
相較另外兩套 service mesh，Linkerd 相對的平易近人許多，尤其是 pod injection 和 service discovery 的部分，讓我覺得可控性很高，但又不需要太多 config。
﻿
Referencehttps://github.com/linkerd/linkerd2/releases/tag/stable-2.8.0
https://learn.hashicorp.com/consul/kubernetes/mesh-gateways
https://istio.io/latest/docs/setup/install/multicluster/shared
https://linkerd.io/2/tasks/installing-multicluster/
https://linkerd.io/2/tasks/multicluster/
﻿
本篇文章使用 CC BY-NC-ND 4.0 並同步發表於https://rammusxu.github.io/2020/07/28/Linkerd-Multi-Kubernetes-Cluster-Feature-Overview 
﻿