到目前為止，我們一直在以最基本的形式使用 Linkerd，而沒(méi)有關(guān)注生產(chǎn)級(jí)別的相關(guān)問(wèn)題。本節(jié)我們將了解生產(chǎn)環(huán)境中使用的一些主要注意事項(xiàng)，包括高可用 (HA) 模式、Helm Chart、跨集群通信和外部 Prometheus。

高可用

高可用描述了具有冗余架構(gòu)的系統(tǒng)，如果系統(tǒng)的某些部分出現(xiàn)故障，該系統(tǒng)將繼續(xù)運(yùn)行。Linkerd 的高可用模式旨在消除控制平面的單點(diǎn)故障。

啟用 HA 模式的一種方法是為 linkerd install 指定 --ha 標(biāo)志，此標(biāo)志啟用幾種不同的行為。它可以部署某些 Linkerd 控制平面組件的多個(gè)副本：

• Controller
• Destination
• Identity
• Proxy Injector
• Service Profile Validator

請(qǐng)注意，其他組件，例如 Grafana、Prometheus，不被看成核心的關(guān)鍵組件，因此不會(huì)配置多副本（如果沒(méi)有這些組件，數(shù)據(jù)平面仍然可以繼續(xù)正常運(yùn)行）。除了副本之外，HA 模式還為控制平面組件配置資源請(qǐng)求，并為這些組件啟用 Pod 反親和性，這樣可確保僅將特定組件的一個(gè)實(shí)例調(diào)度到同一節(jié)點(diǎn)。

不過(guò)需要注意的是 HA 模式有一些細(xì)微的區(qū)別，首先 HA 模式改變了 proxy injector 的方式，強(qiáng)制要求在有適當(dāng)注解的情況下注入代理。這是為了確保在生產(chǎn)環(huán)境中，使用 Linkerd 進(jìn)行 mTLS 的應(yīng)用程序可以依賴該代理，當(dāng)然如果 Linkerd 的 proxy injector 在某種程度上不可用了，則就無(wú)法創(chuàng)建 Pod 了。比如 kube-system 命名空間就會(huì)出現(xiàn)問(wèn)題，因此使用 HA 模式需要將標(biāo)簽 config.linkerd.io/admission-webhooks: disabled 添加到 kube-system 命名空間中，以允許創(chuàng)建 Kubernetes 組件，即使 Linkerd 出現(xiàn)某種問(wèn)題，但也不用太擔(dān)心，當(dāng)在 HA 模式下運(yùn)行時(shí)，當(dāng)標(biāo)簽不在 kube-system 命名空間上時(shí)，linkerd check 命令也會(huì)打印出一條告警信息。

Helm Chart

一般來(lái)說(shuō)在生產(chǎn)環(huán)境中不推薦使用 Linkerd CLI 工具來(lái)進(jìn)行安裝，而更推薦使用 Helm 之類的工具進(jìn)行安裝。Linkerd 為普通模式和 HA 模式提供了 Helm Chart，其中包含一個(gè)名為 values-ha.yaml 的模板，可以將其用作向集群部署高可用性的基礎(chǔ)，Helm 對(duì)于在新創(chuàng)建的集群上自動(dòng)配置 Linkerd 特別有用。

需要注意的一點(diǎn)是，Helm 的安裝過(guò)程不會(huì)像 linkerd install 命令那樣為你生成證書，所以需要在安裝過(guò)程中使用自己的證書，前面 mTLS 章節(jié)已經(jīng)介紹過(guò)。

無(wú)論你是否使用 Helm 安裝，是否在 HA 模式下安裝，對(duì)于生產(chǎn)系統(tǒng)來(lái)說(shuō)，你都應(yīng)該自己生成根證書和簽發(fā)者證書。創(chuàng)建你自己的信任錨，可以讓你避免手動(dòng)輪轉(zhuǎn)的麻煩（我們建議將過(guò)期時(shí)間設(shè)置為 10 年，而不是默認(rèn)的 1 年），也可以為未來(lái)的集群生成簽發(fā)者證書，請(qǐng)確保將私鑰存放在一個(gè)安全的地方!

Prometheus 指標(biāo)

Linkerd 控制平面包含一個(gè) Prometheus 的實(shí)例，該實(shí)例中的數(shù)據(jù)被用來(lái)為 Linkerd 儀表板以及 linkerd viz stat 等命令的輸出提供支持。

該實(shí)例默認(rèn)只保留最近 6 小時(shí)的指標(biāo)數(shù)據(jù)，生產(chǎn)環(huán)境往往需要在更長(zhǎng)的時(shí)間內(nèi)訪問(wèn)指標(biāo)，比如 1 周、1 個(gè)月甚至 1 年。當(dāng)然我們可以重新配置下該 Prometheus 實(shí)例，提高下數(shù)據(jù)保留時(shí)長(zhǎng)，但是顯然這是不被推薦的一種方法，最佳的做法是將指標(biāo)從 Linkerd 的控制平面提供的 Prometheus 輸出到一個(gè)專門的遠(yuǎn)程存儲(chǔ)中去，比如 Cortex、Thanos 或者 Victoriametrics，根據(jù)前面我們的對(duì) Prometheus 的學(xué)習(xí)更加推薦使用 Victoriametrics。

如果你現(xiàn)在已經(jīng)有一個(gè)可用的 Prometheus 集群了，那么同樣我們可以配置讓 Linkerd 來(lái)使用外部的 Prometheus 實(shí)例，同樣可以獲取 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: __tmp_pod_label_linkerd_io_(.+)
      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_(.+)

上面的抓取配置我們可以通過(guò)命令 kubectl get cm -n linkerd-viz prometheus-config -o yaml 獲取完整的配置，抓取配置更新完成后確保 Prometheus 可以抓取到相關(guān)指標(biāo)數(shù)據(jù)。

Linkerd 的 viz 擴(kuò)展組件依賴于 Prometheus 實(shí)例來(lái)為儀表板和 CLI 提供數(shù)據(jù)。安裝的時(shí)候有一個(gè) prometheusUrl 字段可以用來(lái)配置外部 Prometheus 的地址，所有這些組件都可以通過(guò)該參數(shù)配置到外部 Prometheus URL。不過(guò)需要注意的是在使用外部 Prometheus 并配置 prometheusUrl 字段時(shí)，Linkerd 的 Prometheus 仍然會(huì)包含在安裝中。如果您想禁用它，請(qǐng)務(wù)必同時(shí)包含以下配置：

prometheus:
  enabled: false

比如我們這里在 kube-mon 命名空間中有一個(gè)可用的 Prometheus 實(shí)例，則可用如下所示的命令來(lái)進(jìn)行替換：

$ 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 進(jìn)行安裝的則可以直接通過(guò) values 文件來(lái)進(jìn)行配置。更新后重新查看 Linkerd 的 Dashboard 依舊可以看到應(yīng)用的相關(guān)指標(biāo)數(shù)據(jù)。

包括 Grafana 的圖表也是正常顯示的。

這樣對(duì)于 Prometheus 指標(biāo)數(shù)據(jù)保存多長(zhǎng)時(shí)間或者如何保存就是依靠我們的外部 Prometheus 自身去實(shí)現(xiàn)了，這當(dāng)然降低了 Linkerd 自身的復(fù)雜性。

多集群通信

Linkerd 支持多集群通信，這一功能允許服務(wù)在 Kubernetes 集群間透明地進(jìn)行通信。啟用該功能后，如果服務(wù) A 與服務(wù) B 通信，它不需要知道 B 是在同一個(gè)集群還是不同的集群上運(yùn)行，是在同一個(gè)數(shù)據(jù)中心還是在互聯(lián)網(wǎng)上。同樣的 mTLS、指標(biāo)和可靠性功能在集群內(nèi)和跨集群的通信中都是統(tǒng)一應(yīng)用的。事實(shí)上，當(dāng)與流量分割相結(jié)合時(shí)，服務(wù) B 可以從本地集群遷移或故障轉(zhuǎn)移到遠(yuǎn)程集群，或跨越獨(dú)立的遠(yuǎn)程集群。

Linkerd 多集群組件使用 linkerd multi-cluster install 命令與控制平面組件分開安裝，此命令會(huì)創(chuàng)建一個(gè)名為 linkerd-multi-cluster 的命名空間，其中包含兩個(gè)組件：service-mirror 和 linkerd-gateway，這些組件用于確保兩個(gè)集群之間連接的健康，并為遠(yuǎn)程或目標(biāo)集群上存在的服務(wù)路由流量。

每個(gè)參與的集群都必須在安裝了這些組件的情況下運(yùn)行 Linkerd 控制平面。這就消除了任何一個(gè)集群的單點(diǎn)故障：如果一個(gè)集群被移除、崩潰或變得不可用，其余的集群和控制平面將繼續(xù)運(yùn)作。

多集群設(shè)置中最困難的部分是 mTLS 基礎(chǔ)設(shè)施：每個(gè)集群上的頒發(fā)者證書必須由同一個(gè)信任根簽署。這意味著簡(jiǎn)單地運(yùn)行 linkerd install 進(jìn)行安裝會(huì)有問(wèn)題，需要指定同一個(gè)根證書。

其他

上面是將 Linkerd 部署到生產(chǎn)環(huán)境之前需要考慮的一些重要事項(xiàng)，除此之外，還有一些事項(xiàng)也是值得我們關(guān)注的：

• 配置資源：當(dāng)你在 HA 模式下部署 Linkerd 時(shí)，Linkerd 為控制平面組件設(shè)置 CPU 和內(nèi)存資源請(qǐng)求和限制。這些限制是一個(gè)相對(duì)合理的值，但并不是所有的應(yīng)用都是一樣的，你可能需要調(diào)整這些資源配置以適應(yīng)你的需求。對(duì)于高流量的服務(wù)（每個(gè)實(shí)例每秒>1000個(gè)請(qǐng)求），我們可能還需要調(diào)整代理資源，也可以在部署應(yīng)用的時(shí)候指定config.linkerd.io/proxy-cpu-limit 注解來(lái)配置代理的并發(fā)。
• 檢查時(shí)鐘偏差：確保集群中的節(jié)點(diǎn)保持同步很重要，例如通過(guò)使用 NTP，節(jié)點(diǎn)之間的大時(shí)鐘偏差可能會(huì)破壞 Linkerd 代理驗(yàn)證它們用于 mTLS 的證書的能力（在解決集群中的問(wèn)題時(shí)，大的時(shí)鐘偏差可能會(huì)使跨節(jié)點(diǎn)讀取日志文件變得困難！）。
• 處理 NET_ADMIN：Linkerd 的proxy-init? 容器在注入 Pod 時(shí)運(yùn)行，并負(fù)責(zé)配置iptables? 規(guī)則，以便所有進(jìn)出應(yīng)用程序容器的 TCP 流量都自動(dòng)通過(guò)代理容器路由。這需要 Kubernetes 的NET_ADMIN? 這個(gè) Linux Capability，這意味著任何向集群添加支持 Linkerd 的工作負(fù)載的系統(tǒng)都必須被授予該能力。如果出于安全原因不希望這樣做，另一種方法是使用Linkerd CNI 插件在工作負(fù)載創(chuàng)建者權(quán)限范圍之外執(zhí)行此操作。
• linkerd viz tap 權(quán)限：前面我們已經(jīng)學(xué)習(xí)過(guò) tap 這個(gè)強(qiáng)大的命令，但是這個(gè)功能也會(huì)附帶很多風(fēng)險(xiǎn)，因?yàn)檫@個(gè)命令可能會(huì)將潛在的敏感信息暴露給用戶，不過(guò) Linkerd 允許我們使用 Kubernetes RBAC 限制來(lái)控制誰(shuí)可以訪問(wèn)該輸出。
• 使用 Ingress：與其他一些服務(wù)網(wǎng)格不同，Linkerd 不提供自己的 Ingress 控制器。相反，你可以將 Linkerd 與其他可用的 Kubernetes Ingress 控制器配合使用，當(dāng)這樣做的時(shí)候，我們建議將 Ingress 控制器與 Linkerd 代理注入，這將允許 Linkerd 的 mTLS 和可觀察性從請(qǐng)求進(jìn)入集群的那一刻起就已經(jīng)可用了。

到這里我們就基本上了解了如何在生產(chǎn)環(huán)境中使用 Linkerd 了。但也要注意上面我們介紹的這些事項(xiàng)并不是所有的，強(qiáng)烈建議在將 Linkerd 部署到生產(chǎn)環(huán)境之前完全理解這些概念并通讀 Linkerd 文檔。