Linkerd 2.10(Step by Step)—設定服務配置檔案

為少發表於2021-06-29

Linkerd 2.10 系列

Linkerd 2.10 中文手冊持續修正更新中:

Service profilesLinkerd 提供
了關於服務以及如何處理服務請求的附加資訊。

Linkerd proxy 接收到 HTTP(非 HTTPS)請求時,
會識別該請求的目標服務(destination service)。
如果存在該目標服務的服務配置檔案,則該 service profile 用於
提供每個路由指標重試超時

請求的 destination service 是通過選擇存在的第一個 header 的值、
l5d-dst-override:authorityHost 來計算的。
埠元件(如果包含幷包含冒號)將被剝離。該值對映到完全限定的 DNS 名稱。
destination service 與傳送方或接收方名稱空間中的服務配置檔名稱匹配時,
Linkerd 將使用它來提供 per-route metricsretriestimeouts

有時您可能需要為駐留在您無法控制的名稱空間中的服務定義服務配置檔案。
為此,只需像以前一樣建立一個服務配置檔案,但將服務配置檔案的名稱空間編輯為呼叫該服務的
pod 的名稱空間。當 Linkerd
代理對服務的請求時,源名稱空間中的服務配置檔案將優先於目標名稱空間中的服務配置檔案。

您的 destination service 可能是ExternalName
service

在這種情況下,請使用 spec.metadata.namespec.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 將其安裝到叢集上服務的名稱空間中。

相關文章