用 k3s 轻松治理 SSL 证书 | Linux 中国

如何在树莓派上利用 k3s 和 Let's Encrypt 来加密你的网站。
-- Lee Carpenter（作者）

在 上一篇文章 中，我们在 k3s 集群上支配了几个大略的网站。
那些是未加密的网站。
不错，它们可以事情，但是未加密的网站有点太过时了！
如今，大多数网站都是加密的。
在本文中，我们将安装 cert-manager 并将其用于在集群上以支配采取 TLS 加密的网站。
这些网站不仅会被加密，而且还会利用有效的公共证书，这些证书会从 Let's Encrypt 自动获取和更新！
让我们开始吧！

要连续阅读本文，你将须要我们在上一篇文章中构建的 k3s 树莓派集群 。
其余，你须要拥有一个公用静态 IP 地址，并有一个可以为其创建 DNS 记录的域名。
如果你有一个动态 DNS 供应程序为你供应域名，可能也行。
但是，在本文中，我们利用静态 IP 和 CloudFlare 来手动创建 DNS 的 A 记录。

我们在本文中创建配置文件时，如果你不想键入它们，则可以在 此处 进行***。

Traefik（在 k3s 预先捆绑了）实际上具有内置的 Let's Encrypt 支持，因此你可能想知道为什么我们要安装第三方软件包来做同样的事情。
在撰写本文时，Traefik 中的 Let's Encrypt 支持检索证书并将其存储在文件中。
而 cert-manager 会检索证书并将其存储在 Kubernetes 的 “ 机密信息(secret)” 中。
我认为，“机密信息”可以大略地按名称引用，因此更易于利用。
这便是我们在本文中利用 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 的好处是，它免费为我们供应了经由公共验证的 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.net198.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 颁发证书。
Let's Encrypt 为我们供应了一个暂存（例如用于测试）环境，以便核阅我们的配置。
这样它更能容忍缺点和要求的频率。
如果我们对生产环境做了缺点的操作，我们很快就会创造自己被暂时禁止访问了！
因此，我们将利用暂存环境手动测试要求。

创建一个文件 letsencrypt-issuer-staging.yaml，内容如下：

apiVersion: cert-manager.io/v1alpha2kind: ClusterIssuermetadata:name: letsencrypt-stagingspec:acme:# The ACME server URLserver: https://acme-staging-v02.api.letsencrypt.org/directory# Email address used for ACME registrationemail: <your_email>@example.com# Name of a secret used to store the ACME account private keyprivateKeySecretRef:name: letsencrypt-staging# Enable the HTTP-01 challenge providersolvers:- 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/v1alpha2kind: Certificatemetadata:name: k3s-carpie-netnamespace: defaultspec:secretName: k3s-carpie-net-tlsissuerRef:name: letsencrypt-stagingkind: ClusterIssuercommonName: k3s.carpie.netdnsNames:- 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 AGEk3s-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-netkubectl delete secrets k3s-carpie-net-tls配置 cert-manager 以利用 Let's Encrypt（生产***

现在我们已经有了测试证书，是时候移动莅临盆环境了。
就像我们在 Let's Encrypt 暂存环境中配置 cert-manager 一样，我们现在也须要对生产环境进行同样的操作。
创建一个名为 letsencrypt-issuer-production.yaml 的文件（如果须要，可以复制和修正暂存环境的文件），其内容如下：

apiVersion: cert-manager.io/v1alpha2kind: ClusterIssuermetadata:name: letsencrypt-prodspec:acme: # The ACME server URLserver: https://acme-v02.api.letsencrypt.org/directory# Email address used for ACME registrationemail: <your_email>@example.com# Name of a secret used to store the ACME account private keyprivateKeySecretRef:name: letsencrypt-prod# Enable the HTTP-01 challenge providersolvers:- http01:ingress:class: traefik

（如果要从暂存环境进行复制，则唯一的变动是 server: URL。
也请不要忘却修正电子邮件！
）

运用它：

kubectl apply -f letsencrypt-issuer-production.yaml申请我们网站的证书

主要的是须要把稳，我们到目前为止完成的所有步骤都只须要进行一次！
而对付将来的任何其他申请，我们可以从这个解释开始！

让我们支配在 上一篇文章 中支配的同样站点。
（如果仍旧可用，则可以修正 YAML 文件。
如果没有，则可能须要重新创建并重新支配它）。

我们只须要将 mysite.yaml 的 Ingress 部分修正为：

---apiVersion: networking.k8s.io/v1beta1kind: Ingressmetadata:name: mysite-nginx-ingressannotations:kubernetes.io/ingress.class: "traefik"cert-manager.io/cluster-issuer: letsencrypt-prodspec:rules:- host: k3s.carpie.nethttp:paths:- path: /backend:serviceName: mysite-nginx-serviceservicePort: 80tls:- hosts:- k3s.carpie.netsecretName: 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 发行者来获取它。
由此，它将提出要求并为我们安装证书到机密信息之中！

大功告成！
让我们考试测验一下。

它现在具有了加密 TLS 所有优点！
恭喜你！

via: https://opensource.com/article/20/3/ssl-letsencrypt-k3s

作者： Lee Carpenter 选题： lujun9972 译者： wxy 校正： wxy

本文由 LCTT 原创编译， Linux中国 名誉推出