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

用户头像
Rammus
关注
发布于: 2020 年 08 月 10 日
Linkerd 2.8 - 實現超級簡單又安全的多叢集(multicluster) Kubernetes 架構

嘗試過目前市面上現有的三套開源軟體(LinkerdConsulIstio),決定推坑大家 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 -



Showtime

Dashboard: 可以看到目前所有的 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





Benchmark

wrk 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 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。



Reference



本篇文章使用 CC BY-NC-ND 4.0 並同步發表於https://rammusxu.github.io/2020/07/28/Linkerd-Multi-Kubernetes-Cluster-Feature-Overview



发布于: 2020 年 08 月 10 日 阅读数: 77
用户头像

Rammus

关注

DevOps Engineer 2019.10.22 加入

喜愛鑽研 CI/CD 及維運工具

评论

发布
暂无评论
Linkerd 2.8 - 實現超級簡單又安全的多叢集(multicluster) Kubernetes 架構