新聞中心
Linkerd 2.10 中文手冊(cè)持續(xù)修正更新中:

- https://linkerd.hacker-linner.com
使用 Service Mesh Interface 的 Traffic Split API 很容易將故障注入應(yīng)用程序。TrafficSplit 允許您將一定比例的流量重定向到特定后端。這個(gè)后端是完全靈活的,可以返回任何你想要的響應(yīng)——500 秒、超時(shí)甚至瘋狂的有效載荷。
books demo 是展示這種行為的好方法。整體拓?fù)淙缦拢?/p>
在本指南中,您將把一些請(qǐng)求從 webapp 拆分到 books。大多數(shù)請(qǐng)求最終會(huì)到達(dá)正確的 books 目的地,但其中一些將被重定向到有問(wèn)題的后端。此后端將為每個(gè)請(qǐng)求返回 500 秒并將錯(cuò)誤注入 webapp 服務(wù)。不需要更改代碼,并且由于此方法是配置驅(qū)動(dòng)(configuration driven)的, 因此可以將其添加到集成測(cè)試和 CI 管道中。如果你真的過(guò)著混沌工程(chaos engineering)的 lifestyle,甚至可以在生產(chǎn)中使用故障注入。
先決條件
要使用本指南,您需要在集群上安裝 Linkerd 及其 Viz 擴(kuò)展。
設(shè)置服務(wù)
首先,將 books 示例應(yīng)用程序添加到您的集群:
- kubectl create ns booksapp && \
- linkerd inject https://run.linkerd.io/booksapp.yml | \
- kubectl -n booksapp apply -f -
由于此清單在其他地方用作 demo,因此已配置錯(cuò)誤率(error rate)。為了展示故障注入的工作原理,需要去除錯(cuò)誤率,以便有一個(gè)可靠的基線(reliable baseline)。要將 bookapp 的成功率提高到 100%,請(qǐng)運(yùn)行:
- kubectl -n booksapp patch deploy authors \
- --type='json' \
- -p='[{"op":"remove", "path":"/spec/template/spec/containers/0/env/2"}]'
過(guò)了一會(huì)兒,統(tǒng)計(jì)數(shù)據(jù)會(huì)顯示 100% 的成功率。您可以通過(guò)運(yùn)行以下命令來(lái)驗(yàn)證這一點(diǎn):
- linkerd viz -n booksapp stat deploy
輸出最終看起來(lái)有點(diǎn)像:
- NAME MESHED SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99 TCP_CONN
- authors 1/1 100.00% 7.1rps 4ms 26ms 33ms 6
- books 1/1 100.00% 8.6rps 6ms 73ms 95ms 6
- traffic 1/1 - - - - - -
- webapp 3/3 100.00% 7.9rps 20ms 76ms 95ms 9
創(chuàng)建有問(wèn)題的后端
將錯(cuò)誤注入到 booksapp 中需要一個(gè)配置為返回錯(cuò)誤的服務(wù)。為此,您可以啟動(dòng) NGINX 并通過(guò)運(yùn)行將其配置為返回 500s:
- cat <
- apiVersion: v1
- kind: ConfigMap
- metadata:
- name: error-injector
- namespace: booksapp
- data:
- nginx.conf: |-
- events {}
- http {
- server {
- listen 8080;
- location / {
- return 500;
- }
- }
- }
- ---
- apiVersion: apps/v1
- kind: Deployment
- metadata:
- name: error-injector
- namespace: booksapp
- labels:
- app: error-injector
- spec:
- selector:
- matchLabels:
- app: error-injector
- replicas: 1
- template:
- metadata:
- labels:
- app: error-injector
- spec:
- containers:
- - name: nginx
- image: nginx:alpine
- volumeMounts:
- - name: nginx-config
- mountPath: /etc/nginx/nginx.conf
- subPath: nginx.conf
- volumes:
- - name: nginx-config
- configMap:
- name: error-injector
- ---
- apiVersion: v1
- kind: Service
- metadata:
- name: error-injector
- namespace: booksapp
- spec:
- ports:
- - name: service
- port: 8080
- selector:
- app: error-injector
- EOF
注入故障
隨著 booksapp 和 NGINX 的運(yùn)行,現(xiàn)在是時(shí)候在現(xiàn)有的后端(backend)、books 和 新創(chuàng)建的 error-injector 之間部分地分割流量了。這是通過(guò)向集群添加 TrafficSplit 配置來(lái)實(shí)現(xiàn)的:
- cat <
- apiVersion: split.smi-spec.io/v1alpha1
- kind: TrafficSplit
- metadata:
- name: error-split
- namespace: booksapp
- spec:
- service: books
- backends:
- - service: books
- weight: 900m
- - service: error-injector
- weight: 100m
- EOF
當(dāng) Linkerd 看到流向 Books 服務(wù)的流量時(shí), 它會(huì)向原始服務(wù)發(fā)送 9?10 個(gè)請(qǐng)求,向錯(cuò)誤注入器(error injector)發(fā)送 1?10 個(gè)請(qǐng)求。您可以通過(guò)運(yùn)行 stat 并顯式過(guò)濾來(lái)自 webapp 的請(qǐng)求來(lái)查看它的樣子:
- linkerd viz -n booksapp routes deploy/webapp --to service/books
與之前的 stat 命令只查看服務(wù)器收到的請(qǐng)求不同, 這個(gè) routes 命令過(guò)濾到所有由 webapp 發(fā)出的 發(fā)往 books 服務(wù)本身的請(qǐng)求。輸出應(yīng)顯示 90% 的成功率:
- ROUTE SERVICE SUCCESS RPS LATENCY_P50 LATENCY_P95 LATENCY_P99
- [DEFAULT] books 90.08% 2.0rps 5ms 69ms 94ms
在這種情況下,您正在查看 service 而不是 deployment。如果你運(yùn)行這個(gè)命令并查看 deploy/books,成功率仍然是 100%。這樣做的原因是 error-injector 是一個(gè)完全獨(dú)立的 deployment, 并且流量正在服務(wù)級(jí)別(service level)轉(zhuǎn)移。請(qǐng)求永遠(yuǎn)不會(huì)到達(dá) books pod,而是重新路由到錯(cuò)誤注入器的 pod。
清理
要從集群中刪除本指南中的所有內(nèi)容,請(qǐng)運(yùn)行:
- kubectl delete ns booksapp
【編輯推薦】
- 中國(guó)程序員開發(fā)的遠(yuǎn)程桌面火了!Mac可用,僅9MB,支持自建中繼器
- 3分鐘帶你徹底搞懂 Kafka
- 抖音服務(wù)器帶寬有多大,才能供上億人同時(shí)刷?
- 火爆Github!這個(gè)號(hào)稱后現(xiàn)代編輯能超越Vim么?
- 2021年最危險(xiǎn)的七大攻擊技術(shù)
分享題目:Linkerd2.10(StepbyStep)—混沌工程之注入故障
標(biāo)題來(lái)源:http://www.dlmjj.cn/article/djoeggj.html


咨詢
建站咨詢
