為了讓您的服務利用 Linkerd
,它們還需要通過將 Linkerd
的資料平面代理(data plane proxy
)注入到它們服務的 pod
中,從而進行網格化。
Linkerd 2.10 中文手冊持續修正更新中:
Linkerd 2.10 系列
- 快速上手 Linkerd v2 Service Mesh(服務網格)
- 騰訊雲 K8S 叢集實戰 Service Mesh—Linkerd2 & Traefik2 部署 emojivoto 應用
- 詳細瞭解 Linkerd 2.10 基礎功能,一起步入 Service Mesh 微服務架構時代
將 Linkerd
的控制平面新增到您的叢集不會改變您的應用程式的任何內容。為了讓您的服務利用 Linkerd
,它們需要通過將 Linkerd
的資料平面代理注入到它們的 pod
中來進行網格化(meshed)。
對於大多數應用程式,網格化服務就像新增 Kubernetes annotation
一樣簡單。但是,在啟動時立即進行網路呼叫的服務可能需要處理啟動競爭條件,而使用 MySQL
、SMTP
、Memcache
和類似協議的服務可能需要處理 server-speaks-first
協議。
繼續閱讀以瞭解更多資訊!
使用註解(annotations)對服務進行網格化
對 Kubernetes resource
進行網格劃分通常是通過使用 linkerd.io/inject: enabled
的 Kubernetes annotation
來註解資源或其名稱空間來完成的。當資源被建立或更新時,這個註解會觸發自動代理注入。
為方便起見,Linkerd
提供了一個 linkerd inject
文字轉換命令,可以將此 annotation
新增到給定的 Kubernetes
清單中。
當然,這些註解可以通過任何其他機制進行設定。
簡單地新增註釋不會自動對現有 pod
進行網格劃分。設定註解後,您需要重新建立或更新任何資源(例如使用 kubectl rollout restart
)以觸發代理注入。
(通常,可以執行rolling
update 以將代理注入實時服務而不會中斷。)
示例
要將 Linkerd 的資料平面代理新增到 Kubernetes 清單中定義的服務,
您可以在將清單應用到 Kubernetes 之前
使用 linkerd inject
新增註解(annotations):
cat deployment.yml | linkerd inject - | kubectl apply -f -
此示例轉換 deployment.yml
檔案以在正確的位置
新增註入註解(injection annotations),然後將其應用於叢集。
驗證資料平面 Pod 是否已注入
要驗證您的服務是否已新增到網格中,
您可以查詢 Kubernetes 以獲取 pod 中的容器列表,並確保列出了代理:
kubectl -n MYNAMESPACE get po -o jsonpath='{.items[0].spec.containers[*].name}'
這裡我們看一下 emojivoto
這個應用相關的資訊:
kubectl -n emojivoto get po -o jsonpath='{.items[0].spec.containers[*].name}'
# 如果一切順利,您將在輸出中看到 `linkerd-proxy`,例如:
linkerd-proxy emoji-svc
關於啟動競爭條件(startup race conditions)的說明
雖然代理啟動非常快,但 Kubernetes 不提供任何關於容器啟動順序的保證,
因此應用程式容器可能會在代理準備好之前啟動。
這意味著在應用程式啟動時立即建立的任何連線都可能會失敗,直到代理處於活動狀態。
在很多情況下,這可以被忽略:理想情況下,應用程式將重試連線,
或者 Kubernetes 將在失敗後重新啟動容器,最終代理將準備就緒。
或者,您可以使用 linkerd-await
延遲應用程式容器直到代理準備好,
或者設定一個 skip-outbound-ports
來繞過這些連線的代理。
關於 server-speaks-first 協議的說明
Linkerd
的協議檢測通過檢視客戶端資料的
前幾個位元組來確定連線的協議。
某些協議(例如 MySQL
、SMTP
和其他伺服器優先協議)不傳送這些位元組。
在某些情況下,這可能需要額外的配置以避免在
建立第一個連線時出現 10 秒的延遲。