中英文对照表
| 英文 | 英文 - K8S CRD | 中文 | 备注 |
|---|---|---|---|
| certificates | Certificate | 证书 | certificates.cert-manager.io/v1 |
| certificate issuers | Issuer | 证书颁发者 | issuers.cert-manager.io |
ClusterIssuer | 集群证书颁发者 | clusterissuers.cert-manager.io | |
| certificate request | CertificateRequest | 证书申请 | certificaterequests.cert-manager.io |
| order | Order | （证书）订单 | orders.acme.cert-manager.io |
| challenge | Challenge | （证书）挑战 | challenges.acme.cert-manager.io |
| SelfSigned | 自签名 | cert-manager Issuer 的一种 | |
| CA | 证书颁发机构 | Certificate Authority 的缩写； cert-manager Issuer 的一种 | |
| Vault | 金库 | cert-manager Issuer 的一种，即 Hashicorp Vault | |
| Venafi | Venafi 在线证书办理服务，目前用的不多。 | ||
| External | 内部 | cert-manager Issuer 的一种 | |
| ACME | 主动证书治理环境 | Automated Certificate Management Environment 的缩写； cert-manager Issuer, 包含 HTTP01 和 DNS01 |
书接上回, 最初理解一下 cert-manager 的相干概念.
相干概念
Issuer（证书颁发者）
Issuers 和 ClusterIssuers 是 Kubernetes CRD，代表证书颁发机构（CA），可能通过兑现证书签名申请来生成签名证书。所有 cert-manager 证书都须要一个被援用的签发者，该签发者处于准备就绪的状态，能够尝试兑现申请。
Issuer 类型的一个例子是 "CA"。一个简略的CA Issuer如下。
apiVersion: cert-manager.io/v1kind: Issuermetadata: name: ca-issuer namespace: mesh-systemspec: ca: secretName: ca-key-pair这是一个简略的Issuer，将依据私钥（私钥存储在 Secret 的ca-key-pair中）签订证书。
Issuer: 限定在一个 NameSpace 的资源；ClusterIssuer: 能够用于在所有命名空间中颁发 "证书"。
Certificate（证书）
cert-manager 有 Certificate 的概念，定义了所需的 X.509 证书，它将被更新并放弃最新。一个 Certificate 是一个 Kubernetes 的 CRD，它援用了一个 Issuer 或 ClusterIssuer，决定了什么将被授予证书申请。
当一个 Certificate 被创立时，一个相应的 CertificateRequest 资源由 cert-manager 创立，其中蕴含编码的 X.509 证书申请，Issuer reference，以及其余基于 证书 资源标准的选项。
这个 Certificate 将通知 cert-manager 尝试应用哪个 Issuer 来获取域名的证书密钥对。如果胜利，失去的 TLS 密钥和证书将被保留在一个 secret 中，Key 别离为tls.key和tls.crt。这个 Secret 将与Certificate CRD 在同一个命名空间。示例如下：
当证书由两头 CA 签发，并且Issuer 能够提供签发的证书链时，tls.crt的内容将是申请的证书，前面是证书链。
此外，如果证书颁发机构是已知的，相应的 CA 证书将被存储在 Secret 中，密钥为ca.crt。例如，对于 ACME 发行者，CA 是不晓得的，ca.crt将不存在于acme-crt-secret中。
cert-manager 无意防止在tls.crt中增加根证书，因为在平安进行 TLS 的状况下，这些证书是无用的。
当配置一个客户端连贯到具备由私人 CA 签订的服务证书的 TLS 服务器时，你须要向客户端提供 CA 证书，以便它验证服务器。
dnsNames字段指定了与证书相干的 SAN 的列表。
证书生命周期
这张图显示了应用 ACME/Let's Encrypt Issuer 的名为cert-1的证书的生命周期。
CertificateRequest(证书申请)
CertificateRequest是 cert-manager 中的一个 Kubernetes CRD，用于向 Issuer 申请 X.509 证书。该资源蕴含一个 Base64 编码的 PEM 编码的证书申请字符串，它被发送到被援用的签发者。一个胜利的签发将返回一个基于证书签订申请的签名证书。CertificateRequests通常由控制器或其余零碎生产和治理，不应该由人类应用 - 除非特地须要。
CertificateRequest的spec内的所有字段，以及任何治理的 cert-manager 正文，都是不可扭转的，创立后不能批改。
胜利签发证书签订申请将导致对资源的更新，用签订的证书、证书的 CA（如果可用）设置状态，并将 Ready 条件设置为 True。如下图：
CertificateRequest Status" title="CertificateRequest Status">
无论证书签订申请的签发是否胜利，签发的重试都不会产生。治理CertificateRequests的逻辑和生命周期是其余控制器的责任。
条件
CertificateRequests 有一组强定义的条件，控制器或服务应该应用和依赖这些条件来决定下一步对资源采取什么口头。
Ready
每个筹备好的条件由一对Ready--一个布尔值，和Reason--一个字符串组成。这组值和含意如下：
| Ready | Reason | 条件含意 |
|---|---|---|
| False | Pending | CertificateRequest目前正处于期待状态，期待其余操作的产生。这可能是因为Issuer'还不存在，或者Issuer'正在签发证书。 |
| False | Failed | 证书未能被签发--要么是返回的证书未能被解码，要么是用于签名的参考签发者的实例失败。它的控制器将不会对CertificateRequest采取进一步口头。 |
| True | Issued | 被援用的 Issuer 已胜利签发了一份经签名的证书。 |
ACME Orders 和 Challenges
cert-manager 反对从 ACME 服务器申请证书，包含从 Let's Encrypt，应用 ACME Issuer。这些证书通常在公共互联网上被大多数计算机所信赖。为了胜利申请证书，cert-manager 必须解决 ACME challenge，实现这些 challenge 是为了证实客户领有被申请的 DNS 地址。
为了实现这些 challenge，cert-manager 引入了两种 CRD 类型：Orders 和 Challenges。
Orders （订单）
Orders资源被 ACME 发行者用来治理 ACME '订单' 的生命周期，以取得签名的 TLS 证书。对于 ACME 订单和域名验证的更多细节能够在 Let's Encrypt 网站 这里 找到。一个订单代表了一个繁多的证书申请，一旦一个新的 CertificateRequest 资源援用 ACME 发行人，该订单就会主动创立。一旦 Certificate 资源被创立、规格扭转或须要更新，CertificateRequest资源将由 cert-manager 主动创立。
作为终端用户，您将永远不须要手动创立一个 Order 资源。一旦创立，Order 不能被扭转。相同，必须创立一个新的 Order资源。
Order 资源封装了该 "订单" 的多个 ACME Challenge，因而，将治理一个或多个 Challenge 资源。
Challenges （挑战）
Challenges 资源被 ACME 发行者用来治理 ACME challenge 的生命周期，为了实现对一个 DNS 名称/标识的 "认证"，必须实现 challenge。
当一个 Order 资源被创立时，order 控制器将为每个正在被 ACME 服务器认证的 DNS 名称创立 Challenge资源。
作为终端用户，你永远不须要手动创立一个 Challenge 资源。一旦创立，Challenge就不能被扭转。相同，必须创立一个新的 Challenge资源。
Challenge 生命周期
在 Challenges 资源被创立后，它最后将被排队解决。在 challenge 被 "安顿" 开始之前，解决将不会开始。这种调度过程能够避免一次尝试太多的 challenge，或一次尝试对同一 DNS 名称的多个 challenge。
一旦 challenge 被安顿，它将首先与 ACME 服务器进行 "同步"，以确定其以后状态。如果 challenge 曾经无效，它的 status 将被更新为 valid，并且还将设置status.processing = false以 "勾销打算"。
如果 challenge 依然 "pending"，challenge 控制器将应用配置的解决办法（HTTP01 或 DNS01 之一）"present" challenge。一旦 challenge 被 "present"，它将设置status.presented = true。
一旦 "present"，challenge 控制器将执行 "self check"，以确保 challenge 曾经 "propagated（已流传）"（即权威的 DNS 服务器已被更新以作出正确响应，或 ingress 资源的变动已被 ingress controller 察看到并正在应用）。
如果自检失败，cert-manager 将以固定的 10 秒重试工夫距离重试自检。没有实现自检的 challenge 将持续重试，直到用户通过重试 "订单"（通过删除 "订单 "资源）或批改相干的 "证书 "资源来解决任何配置谬误进行干涉。
一旦自检通过，与此 challenge 相干的 ACME "authorization（认证） "将被 "accepted（承受）"。
承受认证后的最终状态将被复制到 challenge 的status.state 字段，如果 ACME 服务器试图验证 challenge 时产生谬误，也会复制 "error reason（谬误起因）"。
一旦 challenge 进入 valid、invalid、expired 或 revoked （撤销）状态，它将设置 status.processing = false，以避免 ACME challenge 的任何进一步解决，如果有积压的 challenge 要实现，容许安顿另一个 challenge。
Challenge 调度
cert-manager 并不试图一次解决所有的 challenge ，而是对 challenge 进行 "调度"。
这个调度器对同时进行的 challenge 的最大数量设置了下限，并且不容许对同一 DNS 名称和解算器类型（HTTP01或DNS01）的两个 challenge 同时实现。
一次能够解决的最大 challenge 数量是 60 个，起因是 ddff78
系列文章
- cert-manager TAG
️ 参考文档
- cert-manager - cert-manager Documentation
- 应用 cert-manager 为 dnspod 的域名签发收费证书 | kubernetes 学习笔记 (imroc.cc)
三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.