认识
以前，我们使用 ACME 脚本来申请 Let’s Encrypt 证书，享受着免费证书和脚本自动化的便利，部署 HTTPS 是那么简单。现在，我们切换到 Kubernetes 环境后，我们该怎样处理呢？最简单最直接的方法就是继续使用 ACME 申请证书，然后使用这个证书创建 Secret 对象，最后在 Ingress 中应用该 Secret 对象。但是 Let’s Encrypt 证书三个月到期，届时我们则需要继续证书续期，然后更新 Secret 信息，这绝对是项繁琐且易失误的工作。
我们使用 Certbot 工具向 Let’s Encrypt 免费申请并自动续期证书。在 Kubernetes Cluster 中，我们使用 cert-manager 组件来实现。
我们能够将 ACME 搬到 Kubernetes 集群中，实现证书的管理。但是，现在已有 cert-manager 组件，它将负责完成证书申请、自动续期等等系列任务，让我们从繁琐的工作中解脱出来。
该部分笔记将记录：在 Kubernetes 中，如何使用 Cert Manager 来管理 Let’s Encrypt 证书，以及相关问题的处理方法。
组成
整体架构以及各资源的作用
—— 该部分将介绍在 cert-manager 中需要知晓的基本概念及其技术架构。
Certificate -> CertificateRequest -> Order -> Challenge
Issuer
在 cert-manager 中，术语 Issuer 能够理解为“证书颁发机构（CA）”。支持以下类型： 1）SelfSigned，自签名证书； 2）CA，此类似代表证书及私钥在集群中的证书颁发机构； 3）Vault，第三方证书颁发机构； 4）Venafi，第三方证书颁发机构； 5）ACME，使用 ACME 协议获取证书。当然不限于 Let’s Encrypt 机构； 5）External，除了上述类型外，通过该方法能够自定义证书机构，以处理 CertificateRequest 资源；
Issuer 分为两种：命名空间级别的 Issuer 资源；集群级别的 ClusterIssuer 资源；
Certificate
当定义 CA（Issuer）之后，便能够申请证书，此时使用 Certificate 资源。
该对象引用 Issuer 或 ClusterIssuer 资源：
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: acme-crt
spec:
secretName: acme-crt[……]