在生產(chǎn)環(huán)境中使用 Linkerd
到目前為止，我們一直在以最基本的形式使用 Linkerd，而沒有關(guān)注生產(chǎn)級別的相關(guān)問題。本節(jié)我們將了解生產(chǎn)環(huán)境中使用的一些主要注意事項，包括高可用 (HA) 模式、Helm Chart、跨集群通信和外部 Prometheus。
高可用
高可用描述了具有冗余架構(gòu)的系統(tǒng)，如果系統(tǒng)的某些部分出現(xiàn)故障，該系統(tǒng)將繼續(xù)運行。Linkerd 的高可用模式旨在消除控制平面的單點故障。
啟用 HA 模式的一種方法是為 linkerd install 指定 --ha 標(biāo)志，此標(biāo)志啟用幾種不同的行為。它可以部署某些 Linkerd 控制平面組件的多個副本：
- Controller
- Destination
- Identity
- Proxy Injector
- Service Profile Validator
請注意，其他組件，例如 Grafana、Prometheus，不被看成核心的關(guān)鍵組件，因此不會配置多副本（如果沒有這些組件，數(shù)據(jù)平面仍然可以繼續(xù)正常運行）。除了副本之外，HA 模式還為控制平面組件配置資源請求，并為這些組件啟用 Pod 反親和性，這樣可確保僅將特定組件的一個實例調(diào)度到同一節(jié)點。
不過需要注意的是 HA 模式有一些細(xì)微的區(qū)別，首先 HA 模式改變了 proxy injector 的方式，強制要求在有適當(dāng)注解的情況下注入代理。這是為了確保在生產(chǎn)環(huán)境中，使用 Linkerd 進行 mTLS 的應(yīng)用程序可以依賴該代理，當(dāng)然如果 Linkerd 的 proxy injector 在某種程度上不可用了，則就無法創(chuàng)建 Pod 了。比如 kube-system 命名空間就會出現(xiàn)問題，因此使用 HA 模式需要將標(biāo)簽 config.linkerd.io/admission-webhooks: disabled 添加到 kube-system 命名空間中，以允許創(chuàng)建 Kubernetes 組件，即使 Linkerd 出現(xiàn)某種問題，但也不用太擔(dān)心，當(dāng)在 HA 模式下運行時，當(dāng)標(biāo)簽不在 kube-system 命名空間上時，linkerd check 命令也會打印出一條告警信息。
Helm Chart
一般來說在生產(chǎn)環(huán)境中不推薦使用 Linkerd CLI 工具來進行安裝，而更推薦使用 Helm 之類的工具進行安裝。Linkerd 為普通模式和 HA 模式提供了 Helm Chart，其中包含一個名為 values-ha.yaml 的模板，可以將其用作向集群部署高可用性的基礎(chǔ)，Helm 對于在新創(chuàng)建的集群上自動配置 Linkerd 特別有用。
需要注意的一點是，Helm 的安裝過程不會像 linkerd install 命令那樣為你生成證書，所以需要在安裝過程中使用自己的證書，前面 mTLS 章節(jié)已經(jīng)介紹過。
無論你是否使用 Helm 安裝，是否在 HA 模式下安裝，對于生產(chǎn)系統(tǒng)來說，你都應(yīng)該自己生成根證書和簽發(fā)者證書。創(chuàng)建你自己的信任錨，可以讓你避免手動輪轉(zhuǎn)的麻煩（我們建議將過期時間設(shè)置為 10 年，而不是默認(rèn)的 1 年），也可以為未來的集群生成簽發(fā)者證書，請確保將私鑰存放在一個安全的地方!
Prometheus 指標(biāo)
Linkerd 控制平面包含一個 Prometheus 的實例，該實例中的數(shù)據(jù)被用來為 Linkerd 儀表板以及 linkerd viz stat 等命令的輸出提供支持。
該實例默認(rèn)只保留最近 6 小時的指標(biāo)數(shù)據(jù)，生產(chǎn)環(huán)境往往需要在更長的時間內(nèi)訪問指標(biāo)，比如 1 周、1 個月甚至 1 年。當(dāng)然我們可以重新配置下該 Prometheus 實例，提高下數(shù)據(jù)保留時長，但是顯然這是不被推薦的一種方法，最佳的做法是將指標(biāo)從 Linkerd 的控制平面提供的 Prometheus 輸出到一個專門的遠(yuǎn)程存儲中去，比如 Cortex、Thanos 或者 Victoriametrics，根據(jù)前面我們的對 Prometheus 的學(xué)習(xí)更加推薦使用 Victoriametrics。
如果你現(xiàn)在已經(jīng)有一個可用的 Prometheus 集群了，那么同樣我們可以配置讓 Linkerd 來使用外部的 Prometheus 實例，同樣可以獲取 Linkerd 控制平面組件和代理的相關(guān)指標(biāo)。
配置外部 Prometheus
如果要使用外部的 Prometheus 則需要在外部 Prometheus 中添加如下抓取配置：
- job_name: "grafana"
kubernetes_sd_configs:
- role: pod
namespaces:
names: ["linkerd-viz"]
relabel_configs:
- source_labels:
- __meta_kubernetes_pod_container_name
action: keep
regex: ^grafana$
- job_name: "linkerd-controller"
relabel_configs:
- source_labels:
- __meta_kubernetes_pod_container_port_name
action: keep
regex: admin-http
- source_labels: [__meta_kubernetes_pod_container_name]
action: replace
target_label: component
kubernetes_sd_configs:
- role: pod
namespaces:
names:
- "linkerd"
- "linkerd-viz"
- job_name: "linkerd-service-mirror"
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels:
- __meta_kubernetes_pod_label_linkerd_io_control_plane_component
- __meta_kubernetes_pod_container_port_name
action: keep
regex: linkerd-service-mirror;admin-http$
- source_labels: [__meta_kubernetes_pod_container_name]
action: replace
target_label: component
- job_name: "linkerd-proxy"
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels:
- __meta_kubernetes_pod_container_name
- __meta_kubernetes_pod_container_port_name
- __meta_kubernetes_pod_label_linkerd_io_control_plane_ns
action: keep
regex: ^linkerd-proxy;linkerd-admin;linkerd$
- source_labels: [__meta_kubernetes_namespace]
action: replace
target_label: namespace
- source_labels: [__meta_kubernetes_pod_name]
action: replace
target_label:
pod
# special case k8s' "job" label, to not interfere with prometheus' "job"
# label
# __meta_kubernetes_pod_label_linkerd_io_proxy_job=foo =>
# k8s_job=foo
- source_labels: [__meta_kubernetes_pod_label_linkerd_io_proxy_job]
action: replace
target_label:
k8s_job
# drop __meta_kubernetes_pod_label_linkerd_io_proxy_job
- action: labeldrop
regex:
__meta_kubernetes_pod_label_linkerd_io_proxy_job
# __meta_kubernetes_pod_label_linkerd_io_proxy_deployment=foo =>
# deployment=foo
- action: labelmap
regex:
__meta_kubernetes_pod_label_linkerd_io_proxy_(.+)
# drop all labels that we just made copies of in the previous labelmap
- action: labeldrop
regex:
__meta_kubernetes_pod_label_linkerd_io_proxy_(.+)
# __meta_kubernetes_pod_label_linkerd_io_foo=bar =>
# foo=bar
- action: labelmap
regex:
__meta_kubernetes_pod_label_linkerd_io_(.+)
# Copy all pod labels to tmp labels
- action: labelmap
regex: __meta_kubernetes_pod_label_(.+)
replacement:
__tmp_pod_label_$1
# Take `linkerd_io_` prefixed labels and copy them without the prefix
- action: labelmap
regex: (.+)
replacement:
__tmp_pod_label_$1
# Drop the `linkerd_io_` originals
- action: labeldrop
regex:
__tmp_pod_label_linkerd_io_(.+)
# Copy tmp labels into real labels
- action: labelmap
regex: __tmp_pod_label_(.+)
上面的抓取配置我們可以通過命令 kubectl get cm -n linkerd-viz prometheus-config -o yaml 獲取完整的配置，抓取配置更新完成后確保 Prometheus 可以抓取到相關(guān)指標(biāo)數(shù)據(jù)。
Linkerd 的 viz 擴展組件依賴于 Prometheus 實例來為儀表板和 CLI 提供數(shù)據(jù)。安裝的時候有一個 prometheusUrl 字段可以用來配置外部 Prometheus 的地址，所有這些組件都可以通過該參數(shù)配置到外部 Prometheus URL。不過需要注意的是在使用外部 Prometheus 并配置 prometheusUrl 字段時，Linkerd 的 Prometheus 仍然會包含在安裝中。如果您想禁用它，請務(wù)必同時包含以下配置：
prometheus:
enabled: false
比如我們這里在 kube-mon 命名空間中有一個可用的 Prometheus 實例，則可用如下所示的命令來進行替換：
$ kubectl get svc prometheus -n kube-mon
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
prometheus NodePort 10.100.236.253 <none> 9090:31561/TCP 60d
$ linkerd viz install --set prometheusUrl=http://prometheus.kube-mon.svc.cluster.local:9090,prometheus.enabled=false | kubectl apply -f -
如果使用的是 Helm 進行安裝的則可以直接通過 values 文件來進行配置。更新后重新查看 Linkerd 的 Dashboard 依舊可以看到應(yīng)用的相關(guān)指標(biāo)數(shù)據(jù)。
包括 Grafana 的圖表也是正常顯示的。
這樣對于 Prometheus 指標(biāo)數(shù)據(jù)保存多長時間或者如何保存就是依靠我們的外部 Prometheus 自身去實現(xiàn)了，這當(dāng)然降低了 Linkerd 自身的復(fù)雜性。
多集群通信
Linkerd 支持多集群通信，這一功能允許服務(wù)在 Kubernetes 集群間透明地進行通信。啟用該功能后，如果服務(wù) A 與服務(wù) B 通信，它不需要知道 B 是在同一個集群還是不同的集群上運行，是在同一個數(shù)據(jù)中心還是在互聯(lián)網(wǎng)上。同樣的 mTLS、指標(biāo)和可靠性功能在集群內(nèi)和跨集群的通信中都是統(tǒng)一應(yīng)用的。事實上，當(dāng)與流量分割相結(jié)合時，服務(wù) B 可以從本地集群遷移或故障轉(zhuǎn)移到遠(yuǎn)程集群，或跨越獨立的遠(yuǎn)程集群。
Linkerd 多集群組件使用 linkerd multi-cluster install 命令與控制平面組件分開安裝，此命令會創(chuàng)建一個名為 linkerd-multi-cluster 的命名空間，其中包含兩個組件：service-mirror 和 linkerd-gateway，這些組件用于確保兩個集群之間連接的健康，并為遠(yuǎn)程或目標(biāo)集群上存在的服務(wù)路由流量。
每個參與的集群都必須在安裝了這些組件的情況下運行 Linkerd 控制平面。這就消除了任何一個集群的單點故障：如果一個集群被移除、崩潰或變得不可用，其余的集群和控制平面將繼續(xù)運作。
多集群設(shè)置中最困難的部分是 mTLS 基礎(chǔ)設(shè)施：每個集群上的頒發(fā)者證書必須由同一個信任根簽署。這意味著簡單地運行 linkerd install 進行安裝會有問題，需要指定同一個根證書。
其他
上面是將 Linkerd 部署到生產(chǎn)環(huán)境之前需要考慮的一些重要事項，除此之外，還有一些事項也是值得我們關(guān)注的：
- 配置資源：當(dāng)你在 HA 模式下部署 Linkerd 時，Linkerd 為控制平面組件設(shè)置 CPU 和內(nèi)存資源請求和限制。這些限制是一個相對合理的值，但并不是所有的應(yīng)用都是一樣的，你可能需要調(diào)整這些資源配置以適應(yīng)你的需求。對于高流量的服務(wù)（每個實例每秒>1000個請求），我們可能還需要調(diào)整代理資源，也可以在部署應(yīng)用的時候指定config.linkerd.io/proxy-cpu-limit 注解來配置代理的并發(fā)。
- 檢查時鐘偏差：確保集群中的節(jié)點保持同步很重要，例如通過使用 NTP，節(jié)點之間的大時鐘偏差可能會破壞 Linkerd 代理驗證它們用于 mTLS 的證書的能力（在解決集群中的問題時，大的時鐘偏差可能會使跨節(jié)點讀取日志文件變得困難！）。
- 處理 NET_ADMIN：Linkerd 的proxy-init? 容器在注入 Pod 時運行，并負(fù)責(zé)配置iptables? 規(guī)則，以便所有進出應(yīng)用程序容器的 TCP 流量都自動通過代理容器路由。這需要 Kubernetes 的NET_ADMIN? 這個 Linux Capability，這意味著任何向集群添加支持 Linkerd 的工作負(fù)載的系統(tǒng)都必須被授予該能力。如果出于安全原因不希望這樣做，另一種方法是使用Linkerd CNI 插件在工作負(fù)載創(chuàng)建者權(quán)限范圍之外執(zhí)行此操作。
- linkerd viz tap 權(quán)限：前面我們已經(jīng)學(xué)習(xí)過 tap 這個強大的命令，但是這個功能也會附帶很多風(fēng)險，因為這個命令可能會將潛在的敏感信息暴露給用戶，不過 Linkerd 允許我們使用 Kubernetes RBAC 限制來控制誰可以訪問該輸出。
- 使用 Ingress：與其他一些服務(wù)網(wǎng)格不同，Linkerd 不提供自己的 Ingress 控制器。相反，你可以將 Linkerd 與其他可用的 Kubernetes Ingress 控制器配合使用，當(dāng)這樣做的時候，我們建議將 Ingress 控制器與 Linkerd 代理注入，這將允許 Linkerd 的 mTLS 和可觀察性從請求進入集群的那一刻起就已經(jīng)可用了。
到這里我們就基本上了解了如何在生產(chǎn)環(huán)境中使用 Linkerd 了。但也要注意上面我們介紹的這些事項并不是所有的，強烈建議在將 Linkerd 部署到生產(chǎn)環(huán)境之前完全理解這些概念并通讀 Linkerd 文檔。
