[[405758]]

Linkerd 2.10 系列

• 快速上手 Linkerd v2 Service Mesh(服務網格)
• 騰訊云 K8S 集群實戰(zhàn) Service Mesh—Linkerd2 & Traefik2 部署 emojivoto 應用
• 詳細了解 Linkerd 2.10 基礎功能，一起步入 Service Mesh 微服務架構時代
• Linkerd 2.10(Step by Step)—1. 將您的服務添加到 Linkerd
• Linkerd 2.10(Step by Step)—2. 自動化的金絲雀發(fā)布
• Linkerd 2.10 中文手冊持續(xù)修正更新中：

https://linkerd.hacker-linner.com

自動輪換控制平面 TLS 憑證

Linkerd 的自動 mTLS 功能使用一組 TLS 憑據(jù)(TLS credentials)為代理生成 TLS 證書(TLS certificates)：信任錨(trust anchor)、頒發(fā)者證書(issuer certificate)和私鑰(private key)。雖然 Linkerd 每 24 小時自動輪換數(shù)據(jù)平面代理的 TLS 證書， 但它不會輪換用于頒發(fā)這些證書的 TLS 憑據(jù)。在本文檔中，我們將描述如何使用外部解決方案 自動輪換頒發(fā)者證書和私鑰。

(請注意，Linkerd 的信任錨仍然必須在 long-lived 集群上手動輪換)

Cert manager

Cert-manager 是一個流行的項目，用于使來自外部來源的 TLS 憑證(TLS credentials)可用于 Kubernetes 集群。

第一步，在您的集群上安裝 cert-manager。

如果您要安裝 cert-manager >= 1.0， 則需要 kubernetes >= 1.16。cert-manager 中用于 kubernetes <= 1.15 的傳統(tǒng)自定義資源定義沒有 keyAlgorithm 選項， 因此證書將使用 RSA 生成并且與 linkerd 不兼容。

有關版本要求的更多詳細信息，請參閱 v0.16 到 v1.0 升 級說明。

Cert manager 作為集群上的證書頒發(fā)機構(CA)

在這種情況下，我們不會從外部來源(external source)獲取憑據(jù)， 而是將其配置為集群上的 CA， 并讓它定期重新頒發(fā) Linkerd 的頒發(fā)者證書(issuer certificate)和私鑰(private key)。

首先，創(chuàng)建 cert-manager 將用來存儲其 Linkerd 相關資源的命名空間。為簡單起見，我們建議使用默認的 Linkerd 控制平面命名空間：

kubectl create namespace linkerd 

將簽名密鑰對(signing key pair)保存為 Secret

接下來，使用 step 工具， 創(chuàng)建一個簽名密鑰對(signing key pair)并將其存儲在上面創(chuàng)建的 命名空間中的 Kubernetes Secret 中：

step certificate create root.linkerd.cluster.local ca.crt ca.key \ 
  --profile root-ca --no-password --insecure && 
  kubectl create secret tls \ 
    linkerd-trust-anchor \ 
    --cert=ca.crt \ 
    --key=ca.key \ 
    --namespace=linkerd 

對于壽命更長(longer-lived)的信任錨證書，將 --not-after 參數(shù)傳遞 給具有所需值(desired value)的 step 命令(例如 --not-after=87600h)。

創(chuàng)建引用密鑰(referencing the secret)的頒發(fā)者(Issuer)

有了 Secret，我們可以創(chuàng)建一個引用它的 cert-manager "Issuer" 資源：

cat <<EOF | kubectl apply -f - 
apiVersion: cert-manager.io/v1 
kind: Issuer 
metadata: 
  name: linkerd-trust-anchor 
  namespace: linkerd 
spec: 
  ca: 
    secretName: linkerd-trust-anchor 
EOF 

頒發(fā)證書(Issuing certificates)并將它們寫入一個 secret

最后，我們可以創(chuàng)建一個 cert-manager "Certificate" 資源， 它使用這個 Issuer 來生成所需的證書：

cat <<EOF | kubectl apply -f - 
apiVersion: cert-manager.io/v1 
kind: Certificate 
metadata: 
  name: linkerd-identity-issuer 
  namespace: linkerd 
spec: 
  secretName: linkerd-identity-issuer 
  duration: 48h 
  renewBefore: 25h 
  issuerRef: 
    name: linkerd-trust-anchor 
    kind: Issuer 
  commonName: identity.linkerd.cluster.local 
  dnsNames: 
  - identity.linkerd.cluster.local 
  isCA: true 
  privateKey: 
    algorithm: ECDSA 
  usages: 
  - cert sign 
  - crl sign 
  - server auth 
  - client auth 
EOF 

(在上面的 YAML 清單中，duration key 指示 cert-manager 將 證書視為有效 48 小時，而 renewBefore key 指示 cert-manager 將嘗試在當前證書到期前 25 小時頒發(fā)新證書。這些值可以根據(jù)您的喜好定制。)

此時，cert-manager 現(xiàn)在可以使用此證書資源(Certificate resource) 獲取 TLS 憑據(jù)(TLS credentials)， 該憑據(jù)將存儲在名為 linkerd-identity-issuer 的 secret 中。要驗證您新頒發(fā)的證書，您可以運行：

kubectl get secret linkerd-identity-issuer -o yaml -n linkerd 

現(xiàn)在我們只需要通知 Linkerd 使用這些憑據(jù)。

由于 cert-manager 中的 bug， 如果您將 cert-manager 版本 0.15 與實驗控制器(experimental controllers)一起使用， 則它頒發(fā)的證書與 Linkerd 版本 <= stable-2.8.1 不兼容。

您的 linkerd-identity pod 可能會因以下日志輸出而崩潰：

"Failed to initialize identity service: failed to read CA from disk: 
unsupported block type: 'PRIVATE KEY'" 

解決此問題的一些可能方法是：

• 將 Linkerd 升級到包含修復程序的邊緣版本 >= edge-20.6.4。
• 將 cert-manager 升級到版本 >= 0.16。(如何升級)
• 關閉 cert-manager 實驗控制器(experimental controllers)。(docs)

替代 CA 提供商

您可以將 Cert Manager 配置為依賴于許多其他解決方案， 例如 Vault， 而不是使用 Cert Manager 作為 CA。可以在此處找到 有關如何設置現(xiàn)有證書管理器 以使用不同類型的頒發(fā)者的更多詳細信息。

第三方證書管理解決方案

需要注意的是，Linkerd 提供的機制也可以在 cert-manager 之外使用。Linkerd 將讀取 linkerd-identity-issuer Secret， 如果它是 kubernetes.io/tls 類型，將使用內容作為其 TLS 憑證(TLS credentials)。這意味著任何能夠通過將 TLS 證書(certificates)寫入此密鑰 來輪換它們的解決方案都可用于提供動態(tài) TLS 證書管理。

在 CLI 安裝中使用這些憑據(jù)

對于 CLI 安裝，Linkerd 控制平面應該 與 --identity-external-issuer 標志一起安裝， 該標志指示 Linkerd 從 linkerd-identity-issuer secret 讀取證書。每當更新存儲在 secret 中的 certificate 和 key 時， identity 服務將自動檢測此更改并重新加載新憑據(jù)。

瞧!我們已經設置了 Linkerd 控制平面 TLS 憑據(jù)的自動輪換。如果你想監(jiān)控更新過程，你可以檢查服務發(fā)出的 IssuerUpdated 事件：

kubectl get events --field-selector reason=IssuerUpdated -n linkerd 

使用 Helm 安裝

對于 Helm 安裝，而不是運行 linkerd install， 將 identityTrustAnchorsPEM 設置為 linkerd-identity-issuer Secret 中 ca.crt 的值：

helm install linkerd2 \ 
  --set-file identityTrustAnchorsPEM=ca.crt \ 
  --set identity.issuer.scheme=kubernetes.io/tls \ 
  --set installNamespace=false \ 
  linkerd/linkerd2 \ 
  -n linkerd 

對于低于 v3 的 Helm 版本，必須專門傳遞 --name 標志。在 Helm v3 中，它已被棄用，并且是上面指定的第一個參數(shù)。

自動輪換 Webhook TLS 憑證

Linkerd 控制平面包含幾個組件，稱為 webhooks， 由 Kubernetes 本身直接調用。從 Kubernetes 到 Linkerd webhooks 的流量使用 TLS 進行保護， 因此每個 webhooks 都需要一個包含 TLS 憑據(jù)的 secret。這些證書與 Linkerd 代理用于保護 pod 到 pod 通信并 使用完全獨立的信任鏈的證書不同。

默認情況下，當 Linkerd 與 Linkerd CLI 或 Linkerd Helm chart 一起安裝時， 會自動為所有 webhook 生成 TLS 憑據(jù)。如果這些證書過期或因任何原因需要重新生成， 執(zhí)行 Linkerd upgrade(使用 Linkerd CLI 或使用 Helm)將重新生成它們。

此工作流程適用于大多數(shù)用戶。但是，如果您需要定期自動輪換這些 webhook 證書， 則可以使用 cert-manager 來自動管理它們。

安裝 Cert manager

第一步，在 您的集群上安裝 cert-manager 并創(chuàng)建 cert-manager 將用于存儲其 webhook 相關資源的命名空間。為簡單起見，我們建議使用默認命名空間 linkerd 使用：

# control plane core 
kubectl create namespace linkerd 
 
# viz (ignore if not using the viz extension) 
kubectl create namespace linkerd-viz 
 
# viz (ignore if not using the jaeger extension) 
kubectl create namespace linkerd-jaeger 

將簽名密鑰對(signing key pair)保存為 Secret

接下來，我們將使用 step 工具創(chuàng)建一個簽名密鑰對(signing key pair)，用于對每個 webhook 證書進行簽名：

step certificate create webhook.linkerd.cluster.local ca.crt ca.key \ 
  --profile root-ca --no-password --insecure --san webhook.linkerd.cluster.local 
 
kubectl create secret tls webhook-issuer-tls --cert=ca.crt --key=ca.key --namespace=linkerd 
 
# ignore if not using the viz extension 
kubectl create secret tls webhook-issuer-tls --cert=ca.crt --key=ca.key --namespace=linkerd-viz 
 
# ignore if not using the jaeger extension 
kubectl create secret tls webhook-issuer-tls --cert=ca.crt --key=ca.key --namespace=linkerd-jaeger 

創(chuàng)建引用 secrets 的發(fā)行者(Issuers)

有了 Secrets，我們就可以創(chuàng)建引用它們的 cert-manager "Issuer" 資源：

cat <<EOF | kubectl apply -f - 
apiVersion: cert-manager.io/v1 
kind: Issuer 
metadata: 
  name: webhook-issuer 
  namespace: linkerd 
spec: 
  ca: 
    secretName: webhook-issuer-tls 
--- 
# ignore if not using the viz extension 
apiVersion: cert-manager.io/v1 
kind: Issuer 
metadata: 
  name: webhook-issuer 
  namespace: linkerd-viz 
spec: 
  ca: 
    secretName: webhook-issuer-tls 
--- 
# ignore if not using the jaeger extension 
apiVersion: cert-manager.io/v1 
kind: Issuer 
metadata: 
  name: webhook-issuer 
  namespace: linkerd-jaeger 
spec: 
  ca: 
    secretName: webhook-issuer-tls 
EOF 

頒發(fā)證書并將其寫入 secrets

最后，我們可以創(chuàng)建 cert-manager "Certificate" 資源， 它使用頒發(fā)者(Issuers)來生成所需的證書：

cat <<EOF | kubectl apply -f - 
apiVersion: cert-manager.io/v1 
kind: Certificate 
metadata: 
  name: linkerd-proxy-injector 
  namespace: linkerd 
spec: 
  secretName: linkerd-proxy-injector-k8s-tls 
  duration: 24h 
  renewBefore: 1h 
  issuerRef: 
    name: webhook-issuer 
    kind: Issuer 
  commonName: linkerd-proxy-injector.linkerd.svc 
  dnsNames: 
  - linkerd-proxy-injector.linkerd.svc 
  isCA: false 
  privateKey: 
    algorithm: ECDSA 
  usages: 
  - server auth 
--- 
apiVersion: cert-manager.io/v1 
kind: Certificate 
metadata: 
  name: linkerd-sp-validator 
  namespace: linkerd 
spec: 
  secretName: linkerd-sp-validator-k8s-tls 
  duration: 24h 
  renewBefore: 1h 
  issuerRef: 
    name: webhook-issuer 
    kind: Issuer 
  commonName: linkerd-sp-validator.linkerd.svc 
  dnsNames: 
  - linkerd-sp-validator.linkerd.svc 
  isCA: false 
  privateKey: 
    algorithm: ECDSA 
  usages: 
  - server auth 
--- 
# ignore if not using the viz extension 
apiVersion: cert-manager.io/v1 
kind: Certificate 
metadata: 
  name: tap 
  namespace: linkerd-viz 
spec: 
  secretName: tap-k8s-tls 
  duration: 24h 
  renewBefore: 1h 
  issuerRef: 
    name: webhook-issuer 
    kind: Issuer 
  commonName: tap.linkerd-viz.svc 
  dnsNames: 
  - tap.linkerd-viz.svc 
  isCA: false 
  privateKey: 
    algorithm: ECDSA 
  usages: 
  - server auth 
--- 
# ignore if not using the viz extension 
apiVersion: cert-manager.io/v1 
kind: Certificate 
metadata: 
  name: linkerd-tap-injector 
  namespace: linkerd-viz 
spec: 
  secretName: tap-injector-k8s-tls 
  duration: 24h 
  renewBefore: 1h 
  issuerRef: 
    name: webhook-issuer 
    kind: Issuer 
  commonName: tap-injector.linkerd-viz.svc 
  dnsNames: 
  - tap-injector.linkerd-viz.svc 
  isCA: false 
  privateKey: 
    algorithm: ECDSA 
  usages: 
  - server auth 
--- 
# ignore if not using the jaeger extension 
apiVersion: cert-manager.io/v1 
kind: Certificate 
metadata: 
  name: jaeger-injector 
  namespace: linkerd-jaeger 
spec: 
  secretName: jaeger-injector-k8s-tls 
  duration: 24h 
  renewBefore: 1h 
  issuerRef: 
    name: webhook-issuer 
    kind: Issuer 
  commonName: jaeger-injector.linkerd.svc 
  dnsNames: 
  - jaeger-injector.linkerd.svc 
  isCA: false 
  privateKey: 
    algorithm: ECDSA 
  usages: 
  - server auth 
EOF 

此時 cert-manager 現(xiàn)在可以使用這些 Certificate resources 來獲取 TLS 憑證， 這些憑證分別存儲在 linkerd-proxy-injector-k8s-tls、linkerd-sp-validator-k8s-tls、tap- k8s-tls、tap-injector-k8s-tls 和 jaeger-injector-k8s-tls 這些 secrets 中。

現(xiàn)在我們只需要通知 Linkerd 使用這些憑據(jù)。

在 CLI 安裝中使用這些憑據(jù)

要將 Linkerd 配置為使用來自 cert-manager 的憑據(jù)而不是生成自己的憑據(jù)， 我們生成了一個補充配置文件：

CA=$(awk '{ print " " $0 }' ca.crt)cat > config.yml <

現(xiàn)在我們可以使用這些配置文件安裝 Linkerd：

CA=$(awk '{ print "    " $0 }' ca.crt) 
 
cat > config.yml <<EOF 
proxyInjector: 
  externalSecret: true 
  caBundle: | 
$CA 
profileValidator: 
  externalSecret: true 
  caBundle: | 
$CA 
EOF 
 
# ignore if not using the viz extension 
cat > config-viz.yml <<EOF 
tap: 
  externalSecret: true 
  caBundle: | 
$CA 
tapInjector: 
  externalSecret: true 
  caBundle: | 
$CA 
EOF 
 
# ignore if not using the jaeger extension 
cat > config-jaeger.yml <<EOF 
webhook: 
  externalSecret: true 
  caBundle: | 
$CA 
EOF 

現(xiàn)在我們可以使用這些配置文件安裝 Linkerd：

linkerd install --values=config.yml | kubectl apply -f - 
 
# ignore if not using the viz extension 
linkerd viz install --values=config-viz.yml | kubectl apply -f - 
 
# ignore if not using the jaeger extension 
linkerd jaeger install --values=config-jaeger.yml | kubectl apply -f - 

使用 Helm 安裝

對于 Helm 安裝，我們可以直接配置 Helm 值：

helm install linkerd2 \ 
  --set installNamespace=false \ 
  --set proxyInjector.externalSecret=true \ 
  --set-file proxyInjector.caBundle=ca.crt \ 
  --set profileValidator.externalSecret=true \ 
  --set-file profileValidator.caBundle=ca.crt \ 
  linkerd/linkerd2 \ 
  -n linkerd 
 
# ignore if not using the viz extension 
helm install linkerd-viz \ 
  --set installNamespace=false \ 
  --set tap.externalSecret=true \ 
  --set-file tap.caBundle=ca.crt \ 
  --set tapInjector.externalSecret=true \ 
  --set-file tapInjector.caBundle=ca.crt \ 
  linkerd/linkerd-viz \ 
  -n linkerd-viz 
 
# ignore if not using the jaeger extension 
helm install linkerd-jaeger \ 
  --set installNamespace=false \ 
  --set webhook.externalSecret=true \ 
  --set-file webhook.caBundle=ca.crt \ 
  linkerd/linkerd-jaeger \ 
  -n linkerd-jaeger 

使用 Helm 安裝 Linkerd 時， 您還必須提供頒發(fā)者信任根(issuer trust root)和頒發(fā)者憑據(jù)(issuer credentials)， 如使用 Helm 安裝 Linkerd 中所述。

對于低于 v3 的 Helm 版本，必須專門傳遞 --name 標志。在 Helm v3 中，它已被棄用，并且是上面指定的第一個參數(shù)。