[[322150]]

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

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

準(zhǔn)備

要繼續(xù)閱讀本文，你將需要我們?cè)谏弦黄恼轮袠?gòu)建的 k3s 樹莓派集群。另外，你需要擁有一個(gè)公用靜態(tài) IP 地址，并有一個(gè)可以為其創(chuàng)建 DNS 記錄的域名。如果你有一個(gè)動(dòng)態(tài) DNS 提供程序?yàn)槟闾峁┯蛎?，可能也行。但是，在本文中，我們使用靜態(tài) IP 和 CloudFlare 來手動(dòng)創(chuàng)建 DNS 的 A 記錄。

我們?cè)诒疚闹袆?chuàng)建配置文件時(shí)，如果你不想鍵入它們，則可以在此處進(jìn)行下載。

我們?yōu)槭裁词褂?cert-manager？

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

安裝 cert-manager

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

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

kubectl create namespace cert-manager

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

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

這會(huì)下載配置文件，并將包含的所有 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"

如我們所見，三個(gè)鏡像現(xiàn)在在鏡像名稱上添加了 -arm?，F(xiàn)在我們有了正確的文件，我們只需將其應(yīng)用于集群：

kubectl apply -f cert-manager-arm.yaml

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

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

Let's Encrypt 概述

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

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

在本文中，我們將使用 HTTP 驗(yàn)證方法，因?yàn)樗子谠O(shè)置并且適用于大多數(shù)情況。以下是幕后發(fā)生的基本過程。cert-manager 向 Let's Encrypt 發(fā)出證書請(qǐng)求。作為回應(yīng)，Let's Encrypt 發(fā)出所有權(quán)驗(yàn)證的質(zhì)詢challenges。這個(gè)質(zhì)詢是將一個(gè) HTTP 資源放在請(qǐng)求證書的域名下的一個(gè)特定 URL 上。從理論上講，如果我們可以將該資源放在該 URL 上，并且讓 Let's Encrypt 可以遠(yuǎn)程獲取它，那么我們實(shí)際上必須是該域的所有者。否則，要么我們無法將資源放置在正確的位置，要么我們無法操縱 DNS 以使 Let's Encrypt 訪問它。在這種情況下，cert-manager 會(huì)將資源放在正確的位置，并自動(dòng)創(chuàng)建一個(gè)臨時(shí)的 Ingress 記錄，以將流量路由到正確的位置。如果 Let's Encrypt 可以讀到該質(zhì)詢要求的資源并正確無誤，它將把證書發(fā)回給 cert-manager。cert-manager 將證書存儲(chǔ)為“機(jī)密信息”，然后我們的網(wǎng)站（或其他任何網(wǎng)站）將使用這些證書通過 TLS 保護(hù)我們的流量。

為該質(zhì)詢?cè)O(shè)置網(wǎng)絡(luò)

我假設(shè)你要在家庭網(wǎng)絡(luò)上進(jìn)行設(shè)置，并擁有一個(gè)以某種方式連接到更廣泛的互聯(lián)網(wǎng)的路由器/接入點(diǎn)。如果不是這種情況，則可能不需要以下過程。

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

對(duì)于本文，我們假設(shè)有一個(gè)靜態(tài)公共 IP，并使用 CloudFlare 來設(shè)置 DNS 的 A 記錄。如果愿意，可以使用自己的 DNS 服務(wù)器。重要的是你可以設(shè)置 A 記錄。

在本文的其余部分中，我將使用 k3s.carpie.net 作為示例域名，因?yàn)檫@是我擁有的域。你顯然會(huì)用自己擁有的任何域名替換它。

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

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

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

$ dig +short k3s.carpie.net
198.51.100.42

繼續(xù)運(yùn)行以上命令，直到可以返回 IP 才行。關(guān)于 CloudFlare 有個(gè)小注釋：ClouldFlare 提供了通過代理流量來隱藏你的實(shí)際 IP 的服務(wù)。在這種情況下，我們?nèi)』氐氖?CloudFlare 的 IP，而不是我們的 IP。但對(duì)于我們的目的，這應(yīng)該可以正常工作。

網(wǎng)絡(luò)配置的最后一步是配置路由器，以將端口 80 和 443 上的傳入流量路由到我們的 k3s 集群?？杀氖牵酚善髋渲庙撁娴牟町惡艽?，因此我無法確切地說明你的外觀是什么樣子。大多數(shù)時(shí)候，我們需要的管理頁面位于“端口轉(zhuǎn)發(fā)”或類似內(nèi)容下。我甚至看到過它列在“游戲”之下（顯然是端口轉(zhuǎn)發(fā)主要用于的游戲）！讓我們看看我的路由器的配置如何。

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

配置 cert-manager 來使用 Let's Encrypt（暫存環(huán)境）

現(xiàn)在，我們需要配置 cert-manager 來通過 Let's Encrypt 頒發(fā)證書。Let's Encrypt 為我們提供了一個(gè)暫存（例如用于測試）環(huán)境，以便審視我們的配置。這樣它更能容忍錯(cuò)誤和請(qǐng)求的頻率。如果我們對(duì)生產(chǎn)環(huán)境做了錯(cuò)誤的操作，我們很快就會(huì)發(fā)現(xiàn)自己被暫時(shí)禁止訪問了！因此，我們將使用暫存環(huán)境手動(dòng)測試請(qǐng)求。

創(chuàng)建一個(gè)文件 letsencrypt-issuer-staging.yaml，內(nèi)容如下：

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

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

現(xiàn)在，我們使用以下方法創(chuàng)建發(fā)行者issuer：

kubectl apply -f letsencrypt-issuer-staging.yaml

我們可以使用以下方法檢查發(fā)行者是否已成功創(chuàng)建：

kubectl get clusterissuers

clusterissuers 是由 cert-manager 創(chuàng)建的一種新的 Kubernetes 資源類型。

現(xiàn)在讓我們手動(dòng)請(qǐng)求一個(gè)測試證書。對(duì)于我們的網(wǎng)站，我們不需要這樣做；我們只是在測試這個(gè)過程，以確保我們的配置正確。

創(chuàng)建一個(gè)包含以下內(nèi)容的證書請(qǐng)求文件 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（我們?cè)谏弦徊街袆?chuàng)建的）的 ClusterIssuer 來請(qǐng)求域 k3s.carpie.net 的證書，并在 Kubernetes 的機(jī)密信息中名為 k3s-carpie-net-tls 的文件中存儲(chǔ)該證書。

像平常一樣應(yīng)用它：

kubectl apply -f le-test-certificate.yaml

我們可以通過以下方式查看狀態(tài)：

kubectl get certificates

如果我們看到類似以下內(nèi)容：

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

我們走在幸福之路?。ㄟ@里的關(guān)鍵是 READY 應(yīng)該是 True）。

解決證書頒發(fā)問題

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

假設(shè)我們執(zhí)行了上面的請(qǐng)求，而 READY 為 False。我們可以從以下方面開始故障排除：

kubectl describe certificates k3s-carpie-net

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

kubectl describe certificaterequest k3s-carpie-net-1256631848

現(xiàn)在比如說最后一個(gè)事件是 Waiting on certificate issuance from order default/k3s-carpie-net-1256631848-2342473830。

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

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

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

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

從這里返回的最后一個(gè)事件是 Presented challenge using http-01 challenge mechanism?？雌饋頉]問題，因此我們?yōu)g覽一下描述的輸出，并看到一條消息 Waiting for http-01 challenge propagation: failed to perform self check GET request ... no such host。終于！我們發(fā)現(xiàn)了問題！在這種情況下，no such host 意味著 DNS 查找失敗，因此我們需要返回并手動(dòng)檢查我們的 DNS 設(shè)置，正確解析域的 DNS，并進(jìn)行所需的任何更改。

清理我們的測試證書

我們實(shí)際上想要使用的是域名的真實(shí)證書，所以讓我們繼續(xù)清理證書和我們剛剛創(chuàng)建的機(jī)密信息：

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

配置 cert-manager 以使用 Let's Encrypt（生產(chǎn)環(huán)境）

現(xiàn)在我們已經(jīng)有了測試證書，是時(shí)候移動(dòng)到生產(chǎn)環(huán)境了。就像我們?cè)?Let's Encrypt 暫存環(huán)境中配置 cert-manager 一樣，我們現(xiàn)在也需要對(duì)生產(chǎn)環(huán)境進(jìn)行同樣的操作。創(chuàng)建一個(gè)名為 letsencrypt-issuer-production.yaml 的文件（如果需要，可以復(fù)制和修改暫存環(huán)境的文件），其內(nèi)容如下：

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

（如果要從暫存環(huán)境進(jìn)行復(fù)制，則唯一的更改是 server: URL。也請(qǐng)不要忘記修改電子郵件?。?/p>

應(yīng)用它：

kubectl apply -f letsencrypt-issuer-production.yaml

申請(qǐng)我們網(wǎng)站的證書

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

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

我們只需要將 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

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

請(qǐng)記住，我們沒有創(chuàng)建這些證書?。ê冒?，我們創(chuàng)建了名稱相似的測試證書，但我們刪除了這些證書。）Traefik 將讀取這些配置并繼續(xù)尋找機(jī)密信息。當(dāng)找不到時(shí)，它會(huì)看到注釋說我們想使用 letsencrypt-prod 發(fā)行者來獲取它。由此，它將提出請(qǐng)求并為我們安裝證書到機(jī)密信息之中！

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