Issuer/ClusterIssuer 与 ACME/CA

• HTTP01 与 DNS01 的原理
• 选型权衡
• 排障方法

ACME 提供 HTTP01 与 DNS01 两种域名验证挑战。HTTP01：ACME 服务器通过 HTTP 访问 http://域名/.well-known/acme-challenge/<token>，验证域名所有权；需 80 端口可达、挑战路径可访问，适合单域名、HTTP 可达的场景。DNS01：ACME 服务器查询域名的 _acme-challenge TXT 记录，验证后签发；需能操作 DNS 记录，支持通配符证书，适合通配符、无法开 80 端口、需批量签发的场景。选型：HTTP01 简单（无需 DNS 权限），但需 80 端口、不支持通配符；DNS01 支持通配符、无需 80 端口，但需 DNS 提供商 API 与传播等待。排障：HTTP01 失败查 80 端口可达性、挑战路径是否被路由/安全规则拦截、Ingress 注解冲突；DNS01 失败查 TXT 记录是否传播（dig 查询）、DNS 提供商 API 权限、传播延迟（TTL 过长）、多签发者争用（同一域名多个 TXT）。cert-manager 排障查 Order/Challenge 事件与日志。

选型核心是"是否需通配符与 80 端口"：HTTP01 简单、DNS01 支持通配符。排障按挑战类型分别查端口/路径（HTTP01）或 DNS 传播/权限（DNS01）。

• 三个组件的分工
• 各自的故障影响
• 签发链路

cert-manager 由三个组件组成。controller：核心控制器，负责调谐 Certificate/CertificateRequest/Order/Challenge 等资源，驱动证书签发与续期，是签发链路的主脑；cainjector：负责把 CA 证书注入到资源（如把根 CA 注入 Secret/ConfigMap、把 CA 注入 webhook 的 CAbundle），用于信任链分发；webhook：负责 CRD 的校验与默认（admission），在创建/更新 cert-manager 资源时校验参数合法性。故障影响：controller 故障——证书签发/续期停止，存量证书继续有效但到期前不续期，影响最大；cainjector 故障——CA 注入不更新，新信任链不生效，但已注入的证书仍可用；webhook 故障——无法创建/更新 cert-manager 资源（校验失败），存量资源不受影响，但新签发/变更被阻断。影响面：controller 最核心（签发续期），webhook 影响资源变更，cainjector 影响信任注入。需对三者分别监控与高可用。

分工是"主脑（controller）+ 信任注入（cainjector）+ 校验（webhook）"。故障影响面：controller 停签发续期、webhook 阻变更、cainjector 阻信任更新，三者需分别保障。

• Let's Encrypt 的配额
• 失败退避策略
• 大规模签发规避限流

Let's Encrypt 有 rate limit（配额）：每注册域名每周 50 个证书、每个标识集合每周 5 个重复证书、每账号每主机名每小时 5 次验证失败、每 IP 每 3 小时 10 个账户等。失败退避（Backoff）：ACME 客户端限量失败后应退避重试（指数退避），避免快速重试触发限流。大规模签发规避限流：一是合理规划——用通配符证书减少证书数量（通配符覆盖多个子域不必逐个签发）、避免重复签发同一证书、按需触发而非每次轮询；二是分批与错峰——大规模签发时分批、错峰，控制并发，避免同时触发同一配额；三是正确重试——失败的 Order 用指数退避（如 5 分钟、30 分钟、几小时），避免连续请求；四是监控配额剩余——跟踪已签发数量与配额，接近配额时暂停；五是复用证书——对短期不变化的证书延长有效期与续期，减少签发频率。核心是"减少签发量 + 控制节奏 + 退避重试"。

规避限流的核心是"减少签发量（通配符、复用）+ 控制节奏（分批错峰）+ 退避重试（指数退避）"。理解配额是规划大规模签发的前提。

• CA Injector 的注入机制
• 注入的目标
• 运行中 Pod 感知

CA Injector 是 cert-manager 的组件，负责把 CA 证书自动注入到资源。注入机制：当证书（如 Issuer 的 CA）创建/更新时，CA Injector 检测到引用了该 CA 的 ConfigMap/Secret（通过注解 cert-manager.io/inject-ca-from 声明），把 CA 证书写入这些资源的 ca.crt 字段。运行中 Pod 感知：CA Injector 只更新 ConfigMap/Secret 的 data，不会自动重启 Pod；运行中 Pod 要感知新信任链，需挂载该 ConfigMap/Secret 的应用自行热加载（如 reload 机制、重新读取文件），或通过触发滚动更新（依赖工具的 reloader，如 stakater reloader、手动 rollout）让 Pod 重新挂载。因此：CA 注入是"文件级更新"，运行时感知取决于应用是否支持热加载，否则需滚动重启。cainjector 也用于把 CA 注入 webhook 的 caBundle。

注入机制是"注解驱动 + 写 data"，但"运行中 Pod 感知"需额外机制：应用热加载或滚动重启。核心是区分"文件更新"与"进程感知"。

• Issuer 与 ClusterIssuer 的区别
• 多租户权限边界
• 安全隔离

Issuer 是命名空间级资源，只能被同一命名空间内的 Certificate 引用；ClusterIssuer 是集群级资源，可被任意命名空间的 Certificate 引用。多租户场景下的权限边界：Issuer 适合"租户独立签发"——每个租户（命名空间）用自己命名空间内的 Issuer，权限隔离，租户间互不影响；ClusterIssuer 适合"共享签发源"——平台统一管理的集群级签发源（如统一 ACME、统一内部 CA），所有租户共享，但需控制权限避免滥用。权限边界设计：集群管理员创建 ClusterIssuer 并限定其使用的 CA 与权限；租户用 Issuer 做自己的签发，或通过 RBAC 限制"谁能引用 ClusterIssuer"。多租户隔离：用命名空间级 Issuer 实现租户级隔离（各自密钥、各自签发配额），ClusterIssuer 实现平台级统一管理；限制租户创建 ClusterIssuer（仅管理员），防止租户越权签发证书。核心是"Issuer 命名空间隔离、ClusterIssuer 集群共享"的权限边界。

权限边界核心是"作用域"：Issuer 命名空间级隔离租户，ClusterIssuer 集群级共享需 RBAC 控制。多租户用 Issuer 隔离、用 ClusterIssuer 统一，权限收敛到管理员。

• Venafi 与 External Issuer 的接入
• 配置方式
• 故障定位

Venafi 与 External Issuer 用于对接外部证书签发系统。Venafi Issuer：cert-manager 支持通过 Venafi Issuer 对接 Venafi 平台（TLS Protect 或 VaaS），使用 Venafi 的 API 签发证书，需配置 Venafi 的 URL、zone、认证凭据（API key/Cloud 凭据）；External Issuer（cert-manager 的 external issuer 框架）：通过自定义的 issuer 类型对接第三方 CA（如 Vault、AWS PCA、GCP CAS），第三方实现一个签发逻辑，通过获取 CertificateSigningRequest 并签发，cert-manager 通过接口调用。接入方式：安装对应 issuer 的 controller，创建 Issuer/ClusterIssuer 类型（如 venafi、vault、aws-pca），配置端点与凭据，Certificate 引用该 Issuer。故障定位：查 Certificate 的 events（Issuer 不可用、认证失败、签发被拒）、查签发 controller 日志（Venafi 调用失败、API 错误）、查凭据配置（API key 是否有效、zone 是否正确）、查网络（到 Venafi/外部 CA 的连通性）。典型错误：认证失败、权限不足、zone 不存在、证书请求被策略拒绝。

接入核心是"配置端点 + 凭据 + 引用"；故障定位看 events、签发日志、凭据与网络。External Issuer 是扩展框架，对接自选 CA。

• selfsigned/CA Issuer
• 信任链集群内分发
• 浏览器与内部信任差异

selfsigned Issuer 生成自签根证书（用于创建自签 CA），CA Issuer 用自签 CA 签发下游证书。信任链在集群内分发：用 CA Injector 把根 CA 注入到集群内各服务信任的 ConfigMap/Secret（如注入到应用挂载的 ca.crt），服务通过挂载信任根 CA 来信任自签 CA 签发的证书；也可把根 CA 加入节点的系统信任库或容器的信任库。浏览器信任与内部服务信任的差异：浏览器信任公共 CA 或用户手动导入的证书，自签/私有 CA 默认不被浏览器信任（需用户导入或见"不受信任"警告）；内部服务信任通过把根 CA 注入到服务信任库即可，无需浏览器信任。因此：自签/私有 CA 适合内部服务间 mTLS/内部 HTTPS（信任根可注入），公共 CA 适合对外服务（浏览器信任）。差异本质是"信任根如何分发"：浏览器信任根固定（公共 CA），内部信任根可注入（私有 CA）。

信任链分发的核心是"根 CA 如何被信任"：内部用 CA Injector 注入信任根，浏览器信任公共 CA 或需手动导入。差异在于信任根的分发方式。

• 私钥存储与保护
• Secret 加密
• 合规审计

证书私钥的存储与保护：私钥应加密存储、最小权限访问、定期轮换。K8s 中私钥存于 Secret，默认明文存储（etcd），需加密——用 KMS 提供商（如 AWS KMS、GCP KMS、Vault）加密 Secret 的 etcd 静态加密（apiserver 的 encryption-at-rest 配置），或把私钥直接托管在 KMS/HSM 中（如 cert-manager 用 KMS 签发、私钥不落盘）。私钥格式：PEM 私钥（RSA/EC）、PKCS8（标准格式）、加密私钥（带口令），敏感场景用加密私钥或托管于 HSM。合规审计要求：记录私钥的创建、访问、轮换、吊销；对私钥访问做审计日志；敏感场景（金融、等保）要求私钥加密存储（KMS）、访问控制、定期轮换与审计留痕。核心是"私钥不落明文、加密存储、最小权限、审计可追溯"。K8s 中启用 secret encryption（KMS）是最佳实践。

私钥保护的核心是"加密存储（KMS/Secret 加密）+ 最小权限 + 审计"：K8s 用 KMS 加密 etcd 静态数据，私钥用安全格式，合规要求审计与轮换。

• 续期触发机制（renewBefore）
• Secret 更新
• 运行中 Pod 感知

cert-manager 在证书剩余寿命达到 renewBefore（默认约 1/3）时触发续期：Certificate 控制器检测到期时间，提前重新发起 CertificateRequest 签发新证书，签发成功后更新命名的 Secret（更新 tls.crt、tls.key）。续期是自动的、声明式的，无需人工干预。Secret 更新后运行中 Pod 感知新证书：cert-manager 只更新 Secret 的 data，不自动重启 Pod；运行中 Pod 要使用新证书，需应用自行热加载（如 Nginx 的 reload、TLS 库的重新读取证书）或通过滚动更新（把 Secret 的 annotation 或 hash 变化触发 Deployment 滚动，或用 reloader 工具监听 Secret 变更自动 rollout）。因此：续期更新是"文件级"，运行时生效取决于应用 reload 或滚动。若不支持热加载，需配合滚动更新让 Pod 挂载新证书。监控续期成功/失败，避免过期。

核心是"续期自动、运行时感知需额外机制"：cert-manager 在 1/3 寿命时续期并更新 Secret，但 Pod 需 reload 或滚动更新才能用新证书。区分"Secret 更新"与"进程生效"。

• 排查路径
• Order/Challenge 状态
• Events 与日志

证书长时间未 Ready 的排查路径：一、看 Certificate 状态——kubectl get certificate 看 READY 状态、kubectl describe certificate 看 Conditions 与 Events，判断是等待、失败还是退避；二、看 CertificateRequest——kubectl get certificaterequest 看是否 Approved、Conditions 是否 Ready，看签发请求的状态；三、看 Order——ACME 场景看 Order 状态（pending/valid/ready），Order 定义验证流程；四、看 Challenge——看 Challenge 状态与类型（HTTP01/DNS01），看 is being validated、错误原因（端口不可达、TXT 未传播、Authorized 失败）；五、看 Events 与日志——kubectl describe 看 cert-manager 写的事件（如 waiting for DNS-01 challenge、rate limit、authorization error），看 cert-manager controller 日志。常见根因：ACME 验证失败（端口/路径/DNS 传播）、限流、Issuer 配置错误、凭据无效、DNS 提供商 API 问题。按"Certificate→CertificateRequest→Order→Challenge→Events/日志"逐层排查。

排查路径是"逐层下钻"：Certificate 看状态，CertificateRequest 看签发，Order 看验证，Challenge 看具体失败，Events/日志看原因。核心是发现卡在"申请/验证/签发"哪一环。

• HTTP01 失败根因
• DNS01 失败根因
• 冲突与争用

ACME 挑战失败常见根因分类：一、端口可达性（HTTP01）——80 端口被防火墙/安全组拦截、Pod 未监听 80、端口转发未配置，导致 ACME 无法访问挑战路径；二、TXT 传播（DNS01）——TXT 记录未及时传播（TTL 过长、DNS 提供商延迟）、_acme-challenge 记录未创建或值错误，导致验证超时；三、Ingress 注解冲突——HTTP01 的 /.well-known/acme-challenge/ 路径被 Ingress 的 rewrite、安全规则、自定义路由拦截，或与业务路由冲突，导致挑战被错误处理；四、多签发者争用——同一域名被多个签发者（cert-manager 多个实例、Let's Encrypt 与手动 DNS）同时写入 _acme-challenge TXT 记录，互相覆盖或冲突，导致某次验证读取到错误记录。排障按类别定位：HTTP01 查端口与路径，DNS01 查传播与记录，冲突查 Ingress 规则与多签发者。根因分类有助于快速定位。

根因分类是"按挑战类型 + 冲突"：端口/路径（HTTP01 可达性）、TXT 传播（DNS01）、Ingress 冲突（路由）、多签发者争用（记录冲突）。分类排查更快。

• 多 DNS 提供商兼容
• TXT 传播延迟
• 冲突处理

DNS01 挑战的多 DNS 提供商兼容性：cert-manager 通过 DNS providers（AWS Route53、Cloudflare、阿里云、腾讯云等）使用提供商 API 创建 _acme-challenge TXT 记录，需配置对应提供商的认证凭据（API key、访问密钥）。不同提供商 API 能力、传播速度不同，需选用 cert-manager 支持的 provider 并配置凭据。TXT 传播延迟：创建 TXT 后，Propagation 需要等待记录在权威 DNS 生效，延迟受 TTL、提供商与递归缓存影响；TTL 太长或供应商传播慢会导致验证超时，可调低 TTL 或配置等待时间。冲突处理（多签发者共用域名）：同一域名被多个签发者（多个 cert-manager、不同 ACME 客户端）同时签发时，会向同一 _acme-challenge 写入多条 TXT 记录或互相覆盖，导致某次验证读到旧/错误记录失败。处理：避免同一域名多签发者并发、协调签发调度、用不同子域/记录隔离、或配置冲突检测。核心是"提供商 API 配置 + 传播延迟控制 + 冲突规避"。

兼容性核心是"提供商 API 接入 + 传播延迟 + 冲突规避"：配置凭据、控制 TTL 与等待、避免多签发者并发争用记录。冲突处理需协调签发。

• Secret 跨命名空间分发
• SecretTemplate
• 信任分发

跨命名空间复用同一张证书，需把证书 Secret 分发到多个命名空间。方法：一、SecretTemplate——cert-manager 的 Certificate 支持 spec.secretTemplate，可把证书内容同步到其他命名的 Secret（同一命名空间内创建额外 Secret），或通过注解把证书复制到其他命名空间；二、Secret 同步工具——用二次分发工具（如 re-secret、secret-sync、外部插件）把证书 Secret 复制到目标命名空间；三、引用共享——把证书放在一个命名空间，其他命名空间通过挂载/引用访问（但 K8s Secret 默认命名空间隔离，需复制）。信任分发：把根 CA（信任根）复制到各命名空间的 ConfigMap/Secret，供各服务的信任库挂载。实现上，用 SecretTemplate 生成证书副本、用 Secret 同步工具跨命名空间复制，或用 GitOps 管理 Secret 分发。核心是"证书在一个命名空间签发，复制到多个命名空间使用"，并保证复制同步与一致性。

跨命名空间复用的核心是"证书签发 + 同步分发"：SecretTemplate 生成副本、同步工具跨命名空间复制，信任根分发到各命名空间。需保证同步与一致性。

• CertificateRequest 控制器
• 审批机制
• 自定义审批

CertificateRequest 控制器是 cert-manager 处理签发请求的控制器，由 Certificate 触发，创建 CertificateRequest 资源，经 Issuer 签发后把证书写回。审批机制：CertificateRequest 需要被"Approved"才允许签发（新版本支持 approval 门控），默认由 cert-manager 自动批准（approval 策略），但可配置自定义审批流程。自定义审批：通过证书审批策略（CertificateSigningRequest 的 approval controller）或 cert-manager 的 approval 机制，把 CertificateRequest 的批准交给外部审批控制器——外部控制器根据策略（如特定签发者、权限、审计）决定 Approved 或 Denied，实现"谁可以申请、谁批准"。自定义审批用于：多租户控制（租户申请需管理员批准）、审计（签发前审批留痕）、安全策略（限制签发域名）。实现：部署 approval controller，监听 CertificateRequest，按策略设 Approved 条件。核心是"把签发审批从自动变为可控"。

自定义审批的核心是"把签发从自动批准变为审批门控"：CertificateRequest 需 Approved 才签发，外部控制器按策略批准，实现权限控制与审计。适合多租户与安全场景。

• 续期机制
• 监控指标
• 告警

cert-manager 的证书续期：Certificate 控制器在证书剩余寿命达到 renewBefore（默认约 1/3）时自动触发续期，重新签发并更新 Secret，续期失败会按退避重试。监控：cert-manager 暴露 Prometheus 指标，如 certmanager_certificate_expiration_timestamp_seconds（证书到期时间）、certmanager_certificate_ready_status（证书就绪状态）、续期相关指标（签发次数、失败次数）。告警设置：对证书到期时间监控（剩余天数低于阈值告警，如 30/14/7 天）、对 Certificate 非 Ready 状态告警、对续期失败/签发失败告警、对 CertificateRequest 长期未完成告警。监控结合 Observability：定期检查证书到期、就绪与续期状态，防止证书过期导致服务中断。工具上可用 x509-certificate-exporter 或 Prometheus 的 cert-manager 指标。核心是"自动续期 + 到期/就绪/续期失败监控告警"。

续期是自动的（renewBefore 触发），监控是保障——盯到期时间、就绪状态、续期失败。防止"自动续期链断裂"导致的过期，需监控与告警。

• 多集群证书分发
• 跨命名空间
• 分发方式

多集群与跨命名空间的证书分发，目标是在多个集群、多个命名空间安全地复用一致的证书与信任。多集群分发：一、各集群独立管理——每个集群用 cert-manager 独立签发（如各集群用同一 ACME 或内部 CA），证书独立但信任根一致；二、单一签发源 + 分发——在一个集群签发证书（或统一 CA），通过 Secret 同步工具（如 cert-manager 的 ClusterSecret 或外部同步工具、GitOps）把证书/信任根复制到其他集群；三、信任根共享——把根 CA 分发到所有集群，各集群服务信任同一根。跨命名空间分发：用 SecretTemplate 或 Secret 同步工具把证书复制到多个命名空间，信任根用 ConfigMap 分发。实现方式：用 GitOps（Argo CD/Flux）管理 Secret 分发、用云上层多集群 Secret 同步、或用 cert-manager 的跨集群能力。核心是"统一信任根 + 证书/信任分发到各集群各命名空间"，保证一致性与可管理性。

多集群分发的核心是"统一信任根 + 分发机制"：独立签发但共享信任根，或用单一签发源分发。跨命名空间用 SecretTemplate/同步复制。保证一致性与可管理。

• 自签 CA 与私有 CA 的建立
• 信任链管理
• 轮换与撤销

自签 CA 与私有 CA 的信任链管理：一、建立——用 selfsigned Issuer 生成自签根 CA，或用 CA Issuer/外部 PKI 建立私有 CA，根 CA 私钥离线/加密保存；二、信任分发——把根 CA 注入到各服务信任库（CA Injector、ConfigMap/Secret 挂载、节点信任库），内部服务信任根后即可验证私有 CA 签发的证书；三、层级——根 CA + 中间 CA（根离线签发中间，中间在线签发叶子），隔离与限定泄露影响；四、轮换——根 CA 低频轮换（离线流程），中间 CA 按需轮换（交叉签名平滑过渡），叶子高频轮换；五、撤销——中间 CA/叶子证书用 CRL/OCSP 撤销，泄露时及时吊销；六、审计——记录签发、轮换、撤销，保证可追溯。信任链管理的核心是"根受保护、层级清晰、信任分发、轮换与撤销可控"。自签 CA 适合内部信任，私有 CA 适合受控 PKI。

信任链管理核心是"根保护 + 层级 + 分发 + 轮换撤销"：根 CA 离线加密、中间 CA 隔离、信任分发到服务、轮换交叉签名、撤销用 CRL/OCSP。保证内部信任的完整与可控。