[[322150]]

如何在樹莓派上使用 k3s 和 Let's Encrypt 來加密你的網站。

在上一篇文章中，我們在 k3s 集群上部署了幾個簡單的網站。那些是未加密的網站。不錯，它們可以工作，但是未加密的網站有點太過時了！如今，大多數網站都是加密的。在本文中，我們將安裝 cert-manager 并將其用于在集群上以部署采用 TLS 加密的網站。這些網站不僅會被加密，而且還會使用有效的公共證書，這些證書會從 Let's Encrypt 自動獲取和更新！讓我們開始吧！

準備

要繼續閱讀本文，你將需要我們在上一篇文章中構建的 k3s 樹莓派集群。另外，你需要擁有一個公用靜態 IP 地址，并有一個可以為其創建 DNS 記錄的域名。如果你有一個動態 DNS 提供程序為你提供域名，可能也行。但是，在本文中，我們使用靜態 IP 和 CloudFlare 來手動創建 DNS 的 A 記錄。

我們在本文中創建配置文件時，如果你不想鍵入它們，則可以在此處進行下載。

我們為什么使用 cert-manager？

Traefik（在 k3s 預先捆綁了）實際上具有內置的 Let's Encrypt 支持，因此你可能想知道為什么我們要安裝第三方軟件包來做同樣的事情。在撰寫本文時，Traefik 中的 Let's Encrypt 支持檢索證書并將其存儲在文件中。而 cert-manager 會檢索證書并將其存儲在 Kubernetes 的 “機密信息secret” 中。我認為，“機密信息”可以簡單地按名稱引用，因此更易于使用。這就是我們在本文中使用 cert-manager 的主要原因。

安裝 cert-manager

通常，我們只是遵循 cert-manager 的文檔在 Kubernetes 上進行安裝。但是，由于我們使用的是 ARM 體系結構，因此我們需要進行一些更改，以便我們可以完成這個操作。

第一步是創建 cert-manager 命名空間。命名空間有助于將 cert-manager 的 Pod 排除在我們的默認命名空間之外，因此當我們使用自己的 Pod 執行 kubectl get pods 之類的操作時，我們不必看到它們。創建名稱空間很簡單：

kubectl create namespace cert-manager

安裝說明會讓你下載 cert-manager 的 YAML 配置文件并將其一步全部應用到你的集群。我們需要將其分為兩個步驟，以便為基于 ARM 的樹莓派修改文件。我們將下載文件并一步一步進行轉換：

curl -sL \
https://github.com/jetstack/cert-manager/releases/download/v0.11.0/cert-manager.yaml |\
sed -r 's/(image:.*):(v.*)$/\1-arm:\2/g' > cert-manager-arm.yaml

這會下載配置文件，并將包含的所有 docker 鏡像更新為 ARM 版本。來檢查一下它做了什么：

$ grep image: cert-manager-arm.yaml
          image: "quay.io/jetstack/cert-manager-cainjector-arm:v0.11.0"
          image: "quay.io/jetstack/cert-manager-controller-arm:v0.11.0"
          image: "quay.io/jetstack/cert-manager-webhook-arm:v0.11.0"

如我們所見，三個鏡像現在在鏡像名稱上添加了 -arm。現在我們有了正確的文件，我們只需將其應用于集群：

kubectl apply -f cert-manager-arm.yaml

這將安裝 cert-manager 的全部。我們可以通過 kubectl --namespace cert-manager get pods 來檢查安裝何時完成，直到所有 Pod 都處于 Running 狀態。

這就完成了 cert-manager 的安裝！

Let's Encrypt 概述

Let's Encrypt 的好處是，它免費為我們提供了經過公共驗證的 TLS 證書！這意味著我們可以擁有一個完全有效的、可供任何人訪問的 TLS 加密網站，這些家庭或業余的愛好活動掙不到錢，也無需自己掏腰包購買 TLS 證書！以及，當通過 cert-manager 使用 Let's Encrypt 的證書時，獲得證書的整個過程是自動化的，證書的續訂也是自動的！

但它是如何工作的？下面是該過程的簡化說明。我們（或代表我們的 cert-manager）向 Let's Encrypt 發出我們擁有的域名的證書請求。Let's Encrypt 通過使用 ACME DNS 或 HTTP 驗證機制來驗證我們是否擁有該域。如果驗證成功，則 Let's Encrypt 將向我們提供證書，這些證書將由 cert-manager 安裝在我們的網站（或其他 TLS 加密的端點）中。在需要重復此過程之前，這些證書可以使用 90 天。但是，cert-manager 會自動為我們更新證書。

在本文中，我們將使用 HTTP 驗證方法，因為它更易于設置并且適用于大多數情況。以下是幕后發生的基本過程。cert-manager 向 Let's Encrypt 發出證書請求。作為回應，Let's Encrypt 發出所有權驗證的質詢challenges。這個質詢是將一個 HTTP 資源放在請求證書的域名下的一個特定 URL 上。從理論上講，如果我們可以將該資源放在該 URL 上，并且讓 Let's Encrypt 可以遠程獲取它，那么我們實際上必須是該域的所有者。否則，要么我們無法將資源放置在正確的位置，要么我們無法操縱 DNS 以使 Let's Encrypt 訪問它。在這種情況下，cert-manager 會將資源放在正確的位置，并自動創建一個臨時的 Ingress 記錄，以將流量路由到正確的位置。如果 Let's Encrypt 可以讀到該質詢要求的資源并正確無誤，它將把證書發回給 cert-manager。cert-manager 將證書存儲為“機密信息”，然后我們的網站（或其他任何網站）將使用這些證書通過 TLS 保護我們的流量。

為該質詢設置網絡

我假設你要在家庭網絡上進行設置，并擁有一個以某種方式連接到更廣泛的互聯網的路由器/接入點。如果不是這種情況，則可能不需要以下過程。

為了使質詢過程正常運行，我們需要一個我們要申請證書的域名，以將其路由到端口 80 上的 k3s 集群。為此，我們需要告訴世界上的 DNS 系統它的位置。因此，我們需要將域名映射到我們的公共 IP 地址。如果你不知道你的公共 IP 地址是什么，可以訪問 WhatsMyIP 之類的地方，它會告訴你。接下來，我們需要輸入 DNS 的 A 記錄，該記錄將我們的域名映射到我們的公共 IP 地址。為了使此功能可靠地工作，你需要一個靜態的公共 IP 地址，或者你可以使用動態 DNS 提供商。一些動態 DNS 提供商會向你頒發一個域名，你可以按照以下說明使用它。我沒有嘗試過，所以不能肯定地說它適用于所有提供商。

對于本文，我們假設有一個靜態公共 IP，并使用 CloudFlare 來設置 DNS 的 A 記錄。如果愿意，可以使用自己的 DNS 服務器。重要的是你可以設置 A 記錄。

在本文的其余部分中，我將使用 k3s.carpie.net 作為示例域名，因為這是我擁有的域。你顯然會用自己擁有的任何域名替換它。

為示例起見，假設我們的公共 IP 地址是 198.51.100.42。我們轉到我們的 DNS 提供商的 DNS 記錄部分，并添加一個名為 k3s.carpie.net 的類型為 A 的記錄（CloudFlare 已經假定了域的部分，因此我們只需輸入 k3s），然后輸入 198.51.100.42 作為 IPv4 地址。

請注意，有時 DNS 更新要傳播一段時間。你可能需要幾個小時才能解析該名稱。在繼續之前該名稱必須可以解析。否則，我們所有的證書請求都將失敗。

我們可以使用 dig 命令檢查名稱是否解析：

$ dig +short k3s.carpie.net
198.51.100.42

繼續運行以上命令，直到可以返回 IP 才行。關于 CloudFlare 有個小注釋：ClouldFlare 提供了通過代理流量來隱藏你的實際 IP 的服務。在這種情況下，我們取回的是 CloudFlare 的 IP，而不是我們的 IP。但對于我們的目的，這應該可以正常工作。

網絡配置的最后一步是配置路由器，以將端口 80 和 443 上的傳入流量路由到我們的 k3s 集群。可悲的是，路由器配置頁面的差異很大，因此我無法確切地說明你的外觀是什么樣子。大多數時候，我們需要的管理頁面位于“端口轉發”或類似內容下。我甚至看到過它列在“游戲”之下（顯然是端口轉發主要用于的游戲）！讓我們看看我的路由器的配置如何。

如果你和我的環境一樣，則轉到 192.168.0.1 登錄到路由器管理應用程序。對于此路由器，它位于 “ NAT/QoS” -> “端口轉發”。在這里，我們將端口 80/TCP 協議設置為轉發到 192.168.0.50（主節點 kmaster 的 IP）的端口 80。我們還設置端口 443 也映射到 kmaster。從技術上講，這對于質詢來說并不是必需的，但是在本文的結尾，我們將部署一個啟用 TLS 的網站，并且需要映射 443 來進行訪問。因此，現在進行映射很方便。我們保存并應用更改，應該一切順利！

配置 cert-manager 來使用 Let's Encrypt（暫存環境）

現在，我們需要配置 cert-manager 來通過 Let's Encrypt 頒發證書。Let's Encrypt 為我們提供了一個暫存（例如用于測試）環境，以便審視我們的配置。這樣它更能容忍錯誤和請求的頻率。如果我們對生產環境做了錯誤的操作，我們很快就會發現自己被暫時禁止訪問了！因此，我們將使用暫存環境手動測試請求。

創建一個文件 letsencrypt-issuer-staging.yaml，內容如下：

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  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: <your_email>@example.com
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt-staging
    # Enable the HTTP-01 challenge provider
    solvers:
    - http01:
        ingress:
          class: traefik

請確保將電子郵件地址更新為你的地址。如果出現問題或我們弄壞了一些東西，這就是 Let's Encrypt 與我們聯系的方式！

現在，我們使用以下方法創建發行者issuer：

kubectl apply -f letsencrypt-issuer-staging.yaml

我們可以使用以下方法檢查發行者是否已成功創建：

kubectl get clusterissuers

clusterissuers 是由 cert-manager 創建的一種新的 Kubernetes 資源類型。

現在讓我們手動請求一個測試證書。對于我們的網站，我們不需要這樣做；我們只是在測試這個過程，以確保我們的配置正確。

創建一個包含以下內容的證書請求文件 le-test-certificate.yaml：

apiVersion: cert-manager.io/v1alpha2
kind: Certificate
metadata:
  name: k3s-carpie-net
  namespace: default
spec:
  secretName: k3s-carpie-net-tls
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer
  commonName: k3s.carpie.net
  dnsNames:
  - k3s.carpie.net

該記錄僅表示我們要使用名為 letsencrypt-staging（我們在上一步中創建的）的 ClusterIssuer 來請求域 k3s.carpie.net 的證書，并在 Kubernetes 的機密信息中名為 k3s-carpie-net-tls 的文件中存儲該證書。

像平常一樣應用它：

kubectl apply -f le-test-certificate.yaml

我們可以通過以下方式查看狀態：

kubectl get certificates

如果我們看到類似以下內容：

NAME                    READY   SECRET                  AGE
k3s-carpie-net          True    k3s-carpie-net-tls      30s

我們走在幸福之路！（這里的關鍵是 READY 應該是 True）。

解決證書頒發問題

上面是幸福的道路。如果 READY 為 False，我們可以等等它，然后再次花點時間檢查狀態。如果它一直是 False，那么我們就有需要解決的問題。此時，我們可以遍歷 Kubernetes 資源鏈，直到找到一條告訴我們問題的狀態消息。

假設我們執行了上面的請求，而 READY 為 False。我們可以從以下方面開始故障排除：

kubectl describe certificates k3s-carpie-net

這將返回很多信息。通常，有用的內容位于 Events: 部分，該部分通常位于底部。假設最后一個事件是 Created new CertificateRequest resource "k3s-carpie-net-1256631848。然后我們描述describe一下該請求：

kubectl describe certificaterequest k3s-carpie-net-1256631848

現在比如說最后一個事件是 Waiting on certificate issuance from order default/k3s-carpie-net-1256631848-2342473830。

那么，我們可以描述該順序：

kubectl describe orders default/k3s-carpie-net-1256631848-2342473830

假設有一個事件，事件為 Created Challenge resource "k3s-carpie-net-1256631848-2342473830-1892150396" for domain "k3s.carpie.net"。讓我們描述一下該質詢：

kubectl describe challenges k3s-carpie-net-1256631848-2342473830-1892150396

從這里返回的最后一個事件是 Presented challenge using http-01 challenge mechanism。看起來沒問題，因此我們瀏覽一下描述的輸出，并看到一條消息 Waiting for http-01 challenge propagation: failed to perform self check GET request ... no such host。終于！我們發現了問題！在這種情況下，no such host 意味著 DNS 查找失敗，因此我們需要返回并手動檢查我們的 DNS 設置，正確解析域的 DNS，并進行所需的任何更改。

清理我們的測試證書

我們實際上想要使用的是域名的真實證書，所以讓我們繼續清理證書和我們剛剛創建的機密信息：

kubectl delete certificates k3s-carpie-net
kubectl delete secrets k3s-carpie-net-tls

配置 cert-manager 以使用 Let's Encrypt（生產環境）

現在我們已經有了測試證書，是時候移動到生產環境了。就像我們在 Let's Encrypt 暫存環境中配置 cert-manager 一樣，我們現在也需要對生產環境進行同樣的操作。創建一個名為 letsencrypt-issuer-production.yaml 的文件（如果需要，可以復制和修改暫存環境的文件），其內容如下：

apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
acme:
 # The ACME server URL
  server: https://acme-v02.api.letsencrypt.org/directory
  # Email address used for ACME registration
  email: <your_email>@example.com
  # Name of a secret used to store the ACME account private key
  privateKeySecretRef:
    name: letsencrypt-prod
  # Enable the HTTP-01 challenge provider
  solvers:
  - http01:
      ingress:
        class: traefik

（如果要從暫存環境進行復制，則唯一的更改是 server: URL。也請不要忘記修改電子郵件！）

應用它：

kubectl apply -f letsencrypt-issuer-production.yaml

申請我們網站的證書

重要的是需要注意，我們到目前為止完成的所有步驟都只需要進行一次！而對于將來的任何其他申請，我們可以從這個說明開始！

讓我們部署在上一篇文章中部署的同樣站點。（如果仍然可用，則可以修改 YAML 文件。如果沒有，則可能需要重新創建并重新部署它）。

我們只需要將 mysite.yaml 的 Ingress 部分修改為：

---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: mysite-nginx-ingress
  annotations:
    kubernetes.io/ingress.class: "traefik"
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  rules:
  - host: k3s.carpie.net
    http:
      paths:
      - path: /
        backend:
          serviceName: mysite-nginx-service
          servicePort: 80
  tls:
  - hosts:
    - k3s.carpie.net
    secretName: k3s-carpie-net-tls

請注意，上面僅顯示了 mysite.yaml 的 Ingress 部分。所做的更改是添加了注解 cert-manager.io/cluster-issuer: letsencrypt-prod。這告訴 traefik 創建證書時使用哪個發行者。 其他唯一增加的是 tls: 塊。這告訴 traefik 我們希望在主機 k3s.carpie.net 上具有 TLS 功能，并且我們希望 TLS 證書文件存儲在機密信息 k3s-carpie-net-tls 中。

請記住，我們沒有創建這些證書！（好吧，我們創建了名稱相似的測試證書，但我們刪除了這些證書。）Traefik 將讀取這些配置并繼續尋找機密信息。當找不到時，它會看到注釋說我們想使用 letsencrypt-prod 發行者來獲取它。由此，它將提出請求并為我們安裝證書到機密信息之中！

大功告成！ 讓我們嘗試一下。