Linkerd 2.10 系列
- 快速上手 Linkerd v2.10 Service Mesh
- 騰訊雲 K8S 叢集實戰 Service Mesh—Linkerd2 & Traefik2 部署 emojivoto 應用
- 詳細瞭解 Linkerd 2.10 基礎功能,一起步入 Service Mesh 微服務架構時代
- 將您的服務新增到 Linkerd
- 自動化的金絲雀釋出
- 自動輪換控制平面 TLS 與 Webhook TLS 憑證
- 如何配置外部 Prometheus 例項
- 配置代理併發
- 配置重試
- 配置超時
- 控制平面除錯端點
- 使用 Kustomize 自定義 Linkerd 的配置
- 使用 Linkerd 進行分散式跟蹤
- 除錯 502s
- 使用每個路由指標除錯 HTTP 應用程式
- 使用請求跟蹤除錯 gRPC 應用程式
- 匯出指標
- 暴露 Dashboard
- 生成您自己的 mTLS 根證照
- 獲取每條路由指標
- 混沌工程之注入故障
- 優雅的 Pod 關閉
- Ingress 流量
- 安裝多叢集元件
- 安裝 Linkerd
- 使用 Helm 安裝 Linkerd
- Linkerd 和 Pod 安全策略 (PSP)
- 手動輪換控制平面 TLS 憑證
- 修改代理日誌級別
- 多叢集通訊
- 將 GitOps 與 Linkerd 和 Argo CD 結合使用
- 使用 Debug Sidecar,注入除錯容器來捕獲網路資料包
Linkerd 2.10 中文手冊持續修正更新中:
Service profiles
為 Linkerd
提供
了關於服務以及如何處理服務請求的附加資訊。
當 Linkerd proxy
接收到 HTTP
(非 HTTPS
)請求時,
會識別該請求的目標服務(destination service
)。
如果存在該目標服務的服務配置檔案,則該 service profile
用於
提供每個路由指標
、重試
和 超時
。
請求的 destination service
是通過選擇存在的第一個 header 的值、
l5d-dst-override
、:authority
和 Host
來計算的。
埠元件(如果包含幷包含冒號)將被剝離。該值對映到完全限定的 DNS
名稱。
當 destination service
與傳送方或接收方名稱空間中的服務配置檔名稱匹配時,
Linkerd 將使用它來提供 per-route metrics
、retries
和 timeouts
。
有時您可能需要為駐留在您無法控制的名稱空間中的服務定義服務配置檔案。
為此,只需像以前一樣建立一個服務配置檔案,但將服務配置檔案的名稱空間編輯為呼叫該服務的
pod
的名稱空間。當 Linkerd
代理對服務的請求時,源名稱空間中的服務配置檔案將優先於目標名稱空間中的服務配置檔案。
您的 destination service
可能是ExternalName
service。
在這種情況下,請使用 spec.metadata.name
和 spec.metadata.namespace
值來命名您的 ServiceProfile
。例如,
apiVersion: v1
kind: Service
metadata:
name: my-service
namespace: prod
spec:
type: ExternalName
externalName: my.database.example.com
使用名稱 my-service.prod.svc.cluster.local
作為 ServiceProfile
。
請注意,目前您無法在 Web 儀表板中檢視針對此 ServiceProfile 中的路由收集的統計資訊。
您可以使用 CLI 獲取統計資訊。
如需完整的演示演練,請檢視 books
demo。
有幾種不同的方法可以使用 linkerd profile
來建立服務配置檔案。`
與路由關聯的請求將有一個 rt_route
annotation。
要手動驗證請求是否正確關聯,請在您自己的部署上執行 tap
:
linkerd viz tap -o wide <target> | grep req
輸出將實時流式傳輸 deploy/webapp
正在接收的請求。 一個樣本是:
req id=0:1 proxy=in src=10.1.3.76:57152 dst=10.1.3.74:7000 tls=disabled :method=POST :authority=webapp.default:7000 :path=/books/2878/edit src_res=deploy/traffic src_ns=foobar dst_res=deploy/webapp dst_ns=default rt_route=POST /books/{id}/edit
相反,如果 rt_route
不存在,則請求 未 與任何路由相關聯。嘗試執行:
linkerd viz tap -o wide <target> | grep req | grep -v rt_route
Swagger
如果您的服務有 OpenAPI (Swagger)
規範,則可以使用 --open-api
標誌從 OpenAPI 規範檔案生成服務配置檔案。
linkerd profile --open-api webapp.swagger webapp
這會從 webapp.swagger
OpenAPI 規範檔案為 webapp
服務生成一個服務配置檔案。
生成的服務配置檔案可以直接通過管道傳輸到 kubectl apply
,並將安裝到服務的名稱空間中。
linkerd profile --open-api webapp.swagger webapp | kubectl apply -f -
Protobuf
如果您的服務具有 protobuf 格式,
則可以使用 --proto
標誌生成服務配置檔案。
linkerd profile --proto web.proto web-svc
這將從用於 web-svc
服務的 web.proto
格式檔案生成服務配置檔案。
生成的服務配置檔案可以直接通過管道傳輸到 kubectl apply
,並將安裝到服務的名稱空間中。
自動建立
沒有 OpenAPI 規範或 protobuf 格式是很常見的。
您還可以通過觀看實時流量生成服務配置檔案。
這是基於點選資料,是瞭解服務配置檔案可以為您做什麼的好方法。
要開始此生成過程,您可以使用 --tap
標誌:
linkerd viz profile -n emojivoto web-svc --tap deploy/web --tap-duration 10s
這將在該命令執行的10秒內從觀察到的 deploy/web
流量中生成一個服務配置檔案。
產生的服務配置檔案可以直接通過管道傳輸到 kubectl apply
,並將被安裝到服務的名稱空間中。
模板
除了自動建立服務配置檔案的所有方法外,您還可以獲得一個模板,允許您手動新增路由。要生成模板,請執行:
linkerd profile -n emojivoto web-svc --template
這會生成一個服務配置檔案模板,其中包含可以手動更新的示例。
更新服務配置檔案後,使用 kubectl apply
將其安裝到叢集上服務的名稱空間中。