從 Kube-LEGO 遷移

kube-lego 是較舊的 Jetstack 專案，用於從 Let's Encrypt (或其他 ACME 伺服器) 取得 TLS 憑證。

自 cert-manager 發佈以來，kube-lego 已逐步棄用，轉而支持此專案。兩者之間存在一些關鍵差異

功能	kube-lego	cert-manager
設定	Ingress 資源上的註釋	CRD
CA	ACME	ACME，簽署金鑰對
Kubernetes	`v1.2` - `v1.8`	`v1.7+`
除錯	查看日誌	Kubernetes 事件 API
多租戶	不支援	支援
每個憑證都有不同的發行來源	不支援	支援
Ingress 控制器支援 (ACME)	GCE, NGINX	全部

本指南將逐步說明如何在不中斷服務的情況下，安全地將您的 kube-lego 安裝遷移至 cert-manager。

在本指南結束時，我們應該完成以下操作

縮減 kube-lego 的規模並移除
安裝 cert-manager
將 ACME 私鑰遷移至 cert-manager
使用此私鑰建立一個 ACME ClusterIssuer，以便在整個叢集中頒發憑證
設定 cert-manager 的 ingress-shim，以便為所有具有 kubernetes.io/tls-acme: "true" 註解的 Ingress 資源自動佈建憑證資源，並使用我們建立的 ClusterIssuer
驗證 cert-manager 安裝是否正常運作

1. 縮減 kube-lego 的規模

在開始部署 cert-manager 之前，最好將 kube-lego 部署的規模縮減至 0 個複本。這將防止兩個控制器潛在的「互相干擾」。如果您使用官方部署 YAML 部署 kube-lego，則像這樣的命令應該可以完成

$ kubectl scale deployment kube-lego \
    --namespace kube-lego \
    --replicas=0

然後，您可以使用以下命令驗證您的 kube-lego Pod 是否不再執行

$ kubectl get pods --namespace kube-lego

2. 部署 cert-manager

應根據我們的官方安裝指南使用 Helm 部署 cert-manager。此處不需要特殊步驟。我們將在本指南末尾返回此部署，並執行一些部署 cert-manager 的 CLI 標誌的升級。

請務必格外小心，確保在部署 Helm 和 cert-manager 時正確配置了 RBAC - 我們的部署文件中描述了一些細微之處！

3. 取得您的 ACME 帳戶私鑰

為了繼續代表您頒發和續訂憑證，我們需要將 kube-lego 為您建立的使用者帳戶私鑰遷移至 cert-manager。

您的 ACME 使用者帳戶身分是一個私鑰，儲存在密鑰資源中。預設情況下，kube-lego 會將此金鑰儲存在一個名為 kube-lego-account 的密鑰中，該密鑰與您的 kube-lego 部署在相同的命名空間中。您可能在部署 kube-lego 時覆蓋了此值，在這種情況下，要使用的密鑰名稱將是 LEGO_SECRET_NAME 環境變數的值。

您應該下載此密鑰資源的副本並將其儲存在您的本機目錄中

$ kubectl get secret kube-lego-account -o yaml \
    --namespace kube-lego \
    --export > kube-lego-account.yaml

儲存後，開啟此檔案並將 metadata.name 欄位變更為與 cert-manager 更相關的名稱。在本指南的其餘部分，我們將假設您選擇了 letsencrypt-private-key。

完成後，我們需要在 cert-manager 命名空間中建立此新資源。預設情況下，cert-manager 會將 ClusterIssuers 的支援資源儲存在它正在執行的命名空間中，並且我們在上面部署 cert-manager 時使用了 cert-manager。如果您已將 cert-manager 部署到不同的命名空間，則應變更此設定。

$ kubectl create -f kube-lego-account.yaml \
    --namespace cert-manager

4. 使用您舊的 ACME 帳戶建立 ACME `ClusterIssuer`

我們需要建立一個 ClusterIssuer，其中將保留先前透過 kube-lego 註冊的 ACME 帳戶的相關資訊。為此，我們需要從舊的 kube-lego 部署中取得另外兩項資訊：ACME 伺服器的伺服器 URL，以及用於註冊帳戶的電子郵件地址。

這兩項資訊都儲存在 kube-lego ConfigMap 中。

若要擷取它們，您應該可以使用 kubectl get ConfigMap

$ kubectl get configmap kube-lego -o yaml \
    --namespace kube-lego \
    --export

您的電子郵件地址應顯示在 .data.lego.email 欄位下，而 ACME 伺服器 URL 應顯示在 .data.lego.url 下。

在本指南中，我們將假設電子郵件是 user@example.com，而 URL 是 https://acme-staging-v02.api.letsencrypt.org/directory。

現在，我們已將私鑰遷移至新的密鑰資源，並取得了 ACME 電子郵件地址和 URL，我們可以建立一個 ClusterIssuer 資源！

建立一個名為 cluster-issuer.yaml 的檔案

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  # Adjust the name here accordingly
  name: letsencrypt-staging
spec:
  acme:
    # The ACME server URL
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: user@example.com
    # Name of a secret used to store the ACME account private key from step 3
    privateKeySecretRef:
      name: letsencrypt-private-key
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          ingressClassName: nginx

然後，我們將此檔案提交到我們的 Kubernetes 叢集

$ kubectl create -f cluster-issuer.yaml

您應該可以驗證 ACME 帳戶是否已成功驗證

$ kubectl describe clusterissuer letsencrypt-staging
...
Status:
  Acme:
    Uri:  https://acme-staging-v02.api.letsencrypt.org/acme/acct/7571319
  Conditions:
    Last Transition Time:  2019-01-30T14:52:03Z
    Message:               The ACME account was registered with the ACME server
    Reason:                ACMEAccountRegistered
    Status:                True
    Type:                  Ready

5. 設定 ingress-shim 預設使用我們的新 `ClusterIssuer`

現在我們的 ClusterIssuer 已準備好頒發憑證，我們還有一件事要做：我們必須重新設定 ingress-shim（作為 cert-manager 的一部分部署），以便為它找到的所有具有適當註解的 Ingress 資源自動建立憑證資源。

有關 ingress-shim 角色的更多資訊，請參閱文件，但現在我們只需執行 helm upgrade 以新增一些額外的標誌。假設您已將您的 ClusterIssuer 命名為 letsencrypt-staging（如上），請執行

$ helm upgrade cert-manager \
     jetstack/cert-manager \
     --namespace cert-manager \
     --set ingressShim.defaultIssuerName=letsencrypt-staging \
     --set ingressShim.defaultIssuerKind=ClusterIssuer

您應該會看到重新建立 cert-manager Pod，並且一旦啟動，它應該會自動為您之前已啟用 kube-lego 的所有 Ingress 建立憑證資源。

6. 驗證每個 Ingress 現在都有對應的憑證

在完成之前，我們應該確保您之前已啟用 kube-lego 的每個 Ingress 資源現在都有憑證資源。

您應該可以透過執行以下命令進行檢查

$ kubectl get certificates --all-namespaces

您的叢集中應該有一個具有 kube-lego 註解的每個 Ingress 的項目。

我們也可以透過檢視 cert-manager 的日誌，驗證 cert-manager 是否已「採用」舊的 TLS 憑證

$ kubectl logs -n cert-manager -l app=cert-manager -c cert-manager
...
I1025 21:54:02.869269       1 sync.go:206] Certificate my-example-certificate scheduled for renewal in 292 hours

在這裡，我們可以查看 cert-manager 已驗證現有的 TLS 憑證，並排定在 292 小時後續訂。