Linkerd 2.8 - 實現超級簡單又安全的多叢集(multicluster) Kubernetes 架構
嘗試過目前市面上現有的三套開源軟體(, , )，決定推坑大家 Linkerd 在今年六月釋出的 ，實現了 multi-cluster Kubernetes 架構，我們來看看主打超輕量化 service mesh 的 Linkerd 會怎麼表現在 multi-cluster。
目前筆者在同一個 GCP 呼叫不同 cluster 的 service 都需要使用 ，除了會增加許多額外的花費，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 會放在
其實只要三個指令就能讓兩個 cluster 相互溝通，可以看到 linkerd 在 cli 的設計，非常簡化、直覺。
## 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 -Showtime
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
Benchmark
這邊在 Cluster 對 Cluster 的 podinfo 壓力測試
這邊比較的基準是直接用 產生一個 GKE L4 Load Balancer
linkerd 會在 Cluster 產生一個 mirrored service podinfo-remote，透過兩邊的 linkerd-gateway 溝通
環境:
Cluster : n2-highcpu-32 regional GKE in Taiwan
Cluster : 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
可以看到在 100 connections 也只增加了 7% 的延遲，已經能處理大部分的 micro service 使用場景。在 500 connections 增加了 50%，不過對於 cross region HA 的話，還算可以接受的範圍。
Other multi cluster solutions
Consul
Pod 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。