到目前為止，我們一直在以最基本的形式使用 Linkerd，而沒有關注生產級別的相關問題。本節我們將了解生產環境中使用的一些主要注意事項，包括高可用 (HA) 模式、Helm Chart、跨集群通信和外部 Prometheus。

高可用

高可用描述了具有冗余架構的系統，如果系統的某些部分出現故障，該系統將繼續運行。Linkerd 的高可用模式旨在消除控制平面的單點故障。

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

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

請注意，其他組件，例如 Grafana、Prometheus，不被看成核心的關鍵組件，因此不會配置多副本（如果沒有這些組件，數據平面仍然可以繼續正常運行）。除了副本之外，HA 模式還為控制平面組件配置資源請求，并為這些組件啟用 Pod 反親和性，這樣可確保僅將特定組件的一個實例調度到同一節點。

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

Helm Chart

一般來說在生產環境中不推薦使用 Linkerd CLI 工具來進行安裝，而更推薦使用 Helm 之類的工具進行安裝。Linkerd 為普通模式和 HA 模式提供了 Helm Chart，其中包含一個名為 values-ha.yaml 的模板，可以將其用作向集群部署高可用性的基礎，Helm 對于在新創建的集群上自動配置 Linkerd 特別有用。

需要注意的一點是，Helm 的安裝過程不會像 linkerd install 命令那樣為你生成證書，所以需要在安裝過程中使用自己的證書，前面 mTLS 章節已經介紹過。

無論你是否使用 Helm 安裝，是否在 HA 模式下安裝，對于生產系統來說，你都應該自己生成根證書和簽發者證書。創建你自己的信任錨，可以讓你避免手動輪轉的麻煩（我們建議將過期時間設置為 10 年，而不是默認的 1 年），也可以為未來的集群生成簽發者證書，請確保將私鑰存放在一個安全的地方!

Prometheus 指標

Linkerd 控制平面包含一個 Prometheus 的實例，該實例中的數據被用來為 Linkerd 儀表板以及 linkerd viz stat 等命令的輸出提供支持。

該實例默認只保留最近 6 小時的指標數據，生產環境往往需要在更長的時間內訪問指標，比如 1 周、1 個月甚至 1 年。當然我們可以重新配置下該 Prometheus 實例，提高下數據保留時長，但是顯然這是不被推薦的一種方法，最佳的做法是將指標從 Linkerd 的控制平面提供的 Prometheus 輸出到一個專門的遠程存儲中去，比如 Cortex、Thanos 或者 Victoriametrics，根據前面我們的對 Prometheus 的學習更加推薦使用 Victoriametrics。

如果你現在已經有一個可用的 Prometheus 集群了，那么同樣我們可以配置讓 Linkerd 來使用外部的 Prometheus 實例，同樣可以獲取 Linkerd 控制平面組件和代理的相關指標。

配置外部 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_(.+)

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

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

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 依舊可以看到應用的相關指標數據。

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

這樣對于 Prometheus 指標數據保存多長時間或者如何保存就是依靠我們的外部 Prometheus 自身去實現了，這當然降低了 Linkerd 自身的復雜性。

多集群通信

Linkerd 支持多集群通信，這一功能允許服務在 Kubernetes 集群間透明地進行通信。啟用該功能后，如果服務 A 與服務 B 通信，它不需要知道 B 是在同一個集群還是不同的集群上運行，是在同一個數據中心還是在互聯網上。同樣的 mTLS、指標和可靠性功能在集群內和跨集群的通信中都是統一應用的。事實上，當與流量分割相結合時，服務 B 可以從本地集群遷移或故障轉移到遠程集群，或跨越獨立的遠程集群。

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

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

多集群設置中最困難的部分是 mTLS 基礎設施：每個集群上的頒發者證書必須由同一個信任根簽署。這意味著簡單地運行 linkerd install 進行安裝會有問題，需要指定同一個根證書。

其他

上面是將 Linkerd 部署到生產環境之前需要考慮的一些重要事項，除此之外，還有一些事項也是值得我們關注的：

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

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