Kubernetes Ingress HTTPS自动化：cert-manager+NGINX实现Let’s Encrypt端到端证书管理

1. 项目概述：为什么 Kubernetes Ingress 的 HTTPS 不是“配个证书”就完事了？

你刚在 Ubuntu 22.04 上用 KubeKey 搭好一个生产级 Kubernetes 集群，用 ArgoCD 做 GitOps 管理，又给 Headlamp 装了 Ingress 想远程看集群——结果浏览器一打开https://192.168.50.10就弹出“您的连接不是私密连接”，点“继续访问”还被 Headlamp 拦住，提示ingress host must be a DNS name, not an IP address。这会儿你才意识到：Ingress 不是加个tls:字段就能自动变 HTTPS 的，更不是把 Let’s Encrypt 的.pem文件手动塞进 Secret 就高枕无忧的。真正的难点在于——证书生命周期管理本身就是一个分布式系统问题：证书90天过期、域名验证需穿透防火墙、ACME 协议交互要和 Ingress Controller 深度协同、失败重试策略得防雪崩、多命名空间下证书复用与隔离必须明确……这些细节，Kubernetes 官方文档不会写，KubeKey 的安装日志里也不会报错，但它们会在凌晨三点让你的 API 网关突然返回 502，而你翻遍kubectl get events却只看到一行CertificateRequest "headlamp-tls" in namespace "monitoring" is not ready。

这就是本项目要解决的核心：让 Let’s Encrypt 证书在 Kubernetes Ingress 上真正“活”起来——自动申请、自动续期、自动注入、自动失效回滚，且全程可观测、可审计、可调试。它不依赖你手动执行certbot certonly，不靠脚本定时kubectl create secret tls，也不用你在 ArgoCD 的 Application 清单里硬编码证书路径。它用的是 cert-manager 这个 CNCF 毕业项目，配合 NGINX Ingress Controller 的原生 TLS 支持，构建一条从 DNS 解析到浏览器锁图标亮起的端到端可信链路。适合三类人：刚用 KubeKey 装完集群想快速上线服务的运维同学；正在用 ArgoCD 做 GitOps、需要把证书管理纳入声明式交付流程的平台工程师；以及准备 Kubernetes 面试、被问到“Ingress 如何做 HTTPS”时能画出 ACME 流程图并说出ChallengeSolver类型差异的候选人。接下来，我会带你从零跑通整个链路，每一步都告诉你为什么这么选、参数怎么算、哪里最容易卡住——不是照着文档复制粘贴，而是像修一台发动机那样，看清每个齿轮怎么咬合。

2. 整体架构设计与方案选型逻辑：为什么 cert-manager + NGINX Ingress 是当前最稳的组合？

2.1 不是所有 Ingress Controller 都“认” Let’s Encrypt

先破一个常见误区：很多人以为只要装了 cert-manager，Ingress 就能自动 HTTPS。错。关键在Ingress Controller 是否实现了ingress.class对应的 TLS 插件接口。比如 Traefik 自带 ACME 客户端，可以独立完成证书申请；而 Contour 需要额外配置 HTTP01 Solver；NGINX Ingress Controller 则完全依赖 cert-manager 提供的CertificateCRD 和Issuer资源来驱动。我们选 NGINX Ingress Controller，不是因为它“名气大”，而是因为它的生态成熟度、调试工具链和企业级功能（如 JWT 验证、WAF 集成）在生产环境经过千锤百炼。尤其当你用 KubeKey 部署时，它默认集成的就是kubesphere/nginx-ingress-controller:v1.9.5（对应 Kubernetes 1.26+），这个镜像已预编译支持--enable-ssl-passthrough和--enable-dynamic-certificates，省去你手动 patch 的麻烦。

提示：如果你用的是社区版kubernetes/ingress-nginx，务必确认镜像版本 ≥ v1.8.0。低于此版本的nginx-ingress-controller不支持 cert-manager v1.12+ 的CertificateRequest状态同步机制，会导致kubectl describe certificate显示Ready=False却无任何错误日志——这是新手踩坑率最高的点之一。

2.2 cert-manager 的架构本质：一个运行在集群内的“证书银行”

把 cert-manager 想象成一家银行：Issuer（或ClusterIssuer）是它的分行牌照，决定你能从哪家 CA（Let’s Encrypt 生产环境 or 测试环境）开户；Certificate是你的存单，声明你要存多少年（duration: 2160h）、存什么币种（dnsNames: ["headlamp.example.com"]）；CertificateRequest是取款单，由 cert-manager 自动签发，交给 ACME 服务器审核；Order和Challenge是银行风控系统生成的验资指令，比如要求你在headlamp.example.com的 DNS 记录里添加_acme-challenge.headlamp.example.comTXT 记录，或在/.well-known/acme-challenge/下放一个验证文件。整个过程完全异步，状态机驱动。你不需要写 cronjob，也不用担心证书过期——当Certificate的renewBefore（默认 30 天）到期，cert-manager 会自动生成新的CertificateRequest，走完整套流程，成功后自动更新Secret，最后通知 NGINX Ingress Controller 重新加载证书。这种设计，正是它能成为 CNCF 毕业项目的核心原因：解耦、可靠、可观测。

2.3 为什么不用手动方式？三个血泪教训

我见过太多团队早期用脚本搞自动化，结果全军覆没：

• 教训一：时间漂移导致续期失败
  某客户集群节点时间未同步 NTP，证书快过期时cert-manager发现Certificate的notAfter时间比本地时间早 5 分钟，直接跳过续期，等凌晨 3 点浏览器报错才报警。而 cert-manager 内置了clock-skew-check机制，会主动校验时间差，超过 10 分钟直接拒绝签发。

• 教训二：DNS 缓存导致验证超时
  手动脚本调dig _acme-challenge.example.com txt看到记录存在就认为验证通过，但 Let’s Encrypt 的验证服务器可能因 DNS 缓存未刷新而查不到。cert-manager 的Challenge资源会持续轮询，直到 ACME 服务器返回valid状态才结束，中间最多重试 10 次，每次间隔指数退避。

• 教训三：Secret 权限泄露风险
  手动kubectl create secret tls时，如果误将tls.crt和tls.key存入default命名空间，任何 Pod 都能挂载读取。cert-manager 创建的 Secret 默认带cert-manager.io/certificate-name标签，并强制设置immutable: true，防止被意外覆盖。

所以，这不是“多此一举”，而是用声明式 API 把证书生命周期这个复杂状态机，交给了一个专精于此的控制器来管理。就像你不会自己造数据库，而是用 PostgreSQL 一样。

3. 核心组件部署与实操要点：从 KubeKey 集群到第一个绿色锁图标

3.1 前置检查：确保你的环境满足 ACME 协议硬性要求

别急着kubectl apply，先做三件事：

1. 确认域名解析可达性
   Let’s Encrypt 的验证服务器必须能通过公网访问你的域名。如果你用的是headlamp.example.com，请确保：

   • nslookup headlamp.example.com返回的是你集群 Node 的公网 IP（不是内网 IP 或127.0.0.1）
   • curl -I http://headlamp.example.com能返回HTTP/1.1 404（说明 DNS 和 Ingress 已通，只是后端服务没配）
   • 如果你用的是内网测试，必须用 Let’s Encrypt Staging 环境（地址https://acme-staging-v02.api.letsencrypt.org/directory），否则生产环境会因无法验证而永久封禁你的域名。

2. 检查 NGINX Ingress Controller 的 TLS 配置
   运行kubectl -n kubesphere-controls-system get deploy nginx-ingress-controller -o yaml | grep -A 5 "args"，确认输出中包含：

   args: - --enable-ssl-passthrough - --enable-dynamic-certificates

   如果没有，你需要编辑 Deployment：kubectl -n kubesphere-controls-system edit deploy nginx-ingress-controller，在args下添加这两行，然后删掉所有 Pod 触发重建。注意：--enable-dynamic-certificates是关键，它让 NGINX 能监听Secret变化并热加载证书，避免重启 Pod。

3. 验证 cert-manager 的 RBAC 权限是否完备
   运行kubectl auth can-i create certificates --namespace default，返回yes才说明权限正常。如果返回no，大概率是你用 Helm 安装时漏掉了--set installCRDs=true参数，或者用了旧版 cert-manager（< v1.8）未自动创建 ClusterRoleBinding。

注意：KubeKey 默认部署的集群，kubesphere-controls-system命名空间下已有nginx-ingress-controller，但cert-manager 需要单独安装。不要试图用kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.14.4/cert-manager.yaml—— 这个 YAML 包含所有 CRD，但在 KubeSphere 环境下可能与内置的ks-installer冲突。正确做法是：用 Helm 3 安装，并指定命名空间为cert-manager。

3.2 分步部署 cert-manager：Helm 方式最稳妥

# 1. 添加 Helm 仓库（官方源，非 GitHub raw） helm repo add jetstack https://charts.jetstack.io helm repo update # 2. 创建 cert-manager 命名空间（KubeSphere 中建议用独立 ns） kubectl create namespace cert-manager # 3. 安装 cert-manager（关键参数说明见下文） helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --version v1.14.4 \ --set installCRDs=true \ --set global.leaderElection.namespace=cert-manager \ --set webhook.timeoutSeconds=30

参数详解：

• --set installCRDs=true：强制安装 Certificate、Issuer 等 CRD。KubeSphere 的ks-installer不会自动处理这个。
• --set global.leaderElection.namespace=cert-manager：指定 leader election 锁存放在cert-manager命名空间，避免与其他控制器抢锁。
• --set webhook.timeoutSeconds=30：提高 ValidatingWebhookConfiguration 超时时间。KubeSphere 集群网络延迟稍高，设为默认 10 秒容易导致kubectl apply卡住。

安装后验证：

kubectl get pods -n cert-manager # 应看到 cert-manager、cert-manager-cainjector、cert-manager-webhook 三个 Pod Running kubectl get crd | grep cert-manager # 应看到 certificates.cert-manager.io、issuers.cert-manager.io 等 10+ 个 CRD

3.3 创建 ClusterIssuer：对接 Let’s Encrypt 的“开户行”

我们用ClusterIssuer（集群级）而非Issuer（命名空间级），因为 Headlamp、ArgoCD 等系统组件通常跨多个命名空间暴露服务。创建letsencrypt-prod.yaml：

apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-prod spec: acme: # Let's Encrypt 生产环境地址（切勿用于测试！） server: https://acme-v02.api.letsencrypt.org/directory email: admin@example.com # 重要：这里填你的真实邮箱，证书过期会邮件提醒 privateKeySecretRef: name: letsencrypt-prod solvers: - http01: ingress: class: nginx # 必须和你的 Ingress Controller 的 ingress.class 一致

关键点解析：

• privateKeySecretRef.name是 cert-manager 用来存 ACME 账户密钥的 Secret 名，它会自动生成，你无需提前创建。
• solvers.http01.ingress.class: nginx：必须和你的 Ingress 资源中kubernetes.io/ingress.class: nginx的值完全匹配。KubeKey 部署的默认是nginx，不是kubesphere/nginx或public。
• 为什么用 HTTP01 而非 DNS01？
  DNS01 需要你提供云厂商 API Key（如阿里云 AccessKey），有安全风险；HTTP01 只需 Ingress Controller 能代理/.well-known/acme-challenge/路径，对内网测试更友好。生产环境若域名托管在 Cloudflare，DNS01 更快（无需等待 DNS 传播），但 HTTP01 调试更直观。

应用并验证：

kubectl apply -f letsencrypt-prod.yaml kubectl get clusterissuer letsencrypt-prod -o wide # STATUS 应为 Ready，CONDITIONS 显示 True kubectl describe clusterissuer letsencrypt-prod # 查看 Events，确认最后一行是 "The ACME account was registered with the ACME server"

3.4 为 Headlamp 配置 Ingress 并绑定证书：声明式交付的终点

Headlamp 默认不启用 Ingress，需手动创建。假设你已用 KubeSphere 控制台或kubectl apply -f headlamp.yaml部署了 Headlamp 到kubesphere-monitoring-system命名空间。创建headlamp-ingress.yaml：

apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: headlamp namespace: kubesphere-monitoring-system annotations: kubernetes.io/ingress.class: nginx # 启用 HTTPS 重定向（强制跳转） nginx.ingress.kubernetes.io/ssl-redirect: "true" # 启用 HSTS（防止降级攻击） nginx.ingress.kubernetes.io/force-ssl-redirect: "true" spec: # 关键：这里声明证书资源 tls: - hosts: - headlamp.example.com # 必须和你申请的域名完全一致 secretName: headlamp-tls # cert-manager 会自动创建这个 Secret rules: - host: headlamp.example.com http: paths: - path: / pathType: Prefix backend: service: name: headlamp port: number: 4000 --- # 关键：Certificate 资源，告诉 cert-manager “我要这个域名的证书” apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: headlamp-tls namespace: kubesphere-monitoring-system spec: secretName: headlamp-tls issuerRef: name: letsencrypt-prod kind: ClusterIssuer dnsNames: - headlamp.example.com # 证书有效期（默认 90 天），这里显式声明便于管理 duration: 2160h # 90 天 # 续期提前量（默认 30 天），建议设为 15 天，留足调试时间 renewBefore: 360h # 15 天

应用并观察状态：

kubectl apply -f headlamp-ingress.yaml # 等待 2-5 分钟，查看 Certificate 状态 kubectl -n kubesphere-monitoring-system get certificate # 输出应为：NAME READY SECRET AGE # headlamp-tls True headlamp-tls 3m kubectl -n kubesphere-monitoring-system describe certificate headlamp-tls # Events 中应看到 "Certificate issued successfully" # 此时检查 Secret kubectl -n kubesphere-monitoring-system get secret headlamp-tls # 应看到 tls.crt 和 tls.key 已生成

实操心得：如果get certificate一直显示False，立刻看describe输出的 Events，90% 的问题在这里。常见原因：host域名 DNS 不可达、ingress.class不匹配、ClusterIssuer的server地址写错（比如 staging 写成 prod）、或http01solver 的ingress.class值和实际 Ingress 不一致。永远不要猜，先看 Events。

4. 实操过程深度拆解：从 ACME 挑战到浏览器锁图标亮起的每一步

4.1 ACME 协议交互全流程：一次成功的 HTTP01 验证究竟发生了什么？

当Certificate资源被创建，cert-manager 启动一个完整的 ACME 流程。我们用kubectl logs -n cert-manager deploy/cert-manager实时跟踪（加-f持续输出），截取关键日志片段：

I0520 08:23:12.123456 1 controller.go:172] "Starting new challenge" challenge="headlamp-tls-12345" ... I0520 08:23:13.678901 1 http.go:123] "Creating HTTP01 challenge solver pod" name="cm-acme-http-solver-abcde" ... I0520 08:23:15.234567 1 ingress.go:89] "Creating HTTP01 challenge solver ingress" name="cm-acme-http-solver-fghij" ...

这三行日志揭示了核心动作：

1. Challenge 创建：cert-manager 生成一个唯一 ID 的Challenge资源（如headlamp-tls-12345），内容包含 ACME 服务器要求的验证 token。
2. Solver Pod 启动：它在cert-manager命名空间启动一个临时 Pod（cm-acme-http-solver-abcde），这个 Pod 只干一件事：监听/路径，返回 ACME 要求的 token 响应。
3. Solver Ingress 创建：同时创建一个临时 Ingress（cm-acme-http-solver-fghij），规则是：当请求http://headlamp.example.com/.well-known/acme-challenge/<token>时，转发给上面那个 Solver Pod。

此时，Let’s Encrypt 的验证服务器会发起 GET 请求：

curl -v http://headlamp.example.com/.well-known/acme-challenge/xyz123 # 应返回 200 和一段 base64 编码的 key authorization 字符串

如果返回 200，ACME 服务器标记该 Challenge 为valid，cert-manager 收到通知后：

• 删除临时 Solver Pod 和 Ingress
• 向 Let’s Encrypt 提交证书签名请求（CSR）
• 接收返回的tls.crt和tls.key
• 创建或更新Secret headlamp-tls
• 更新Certificate状态为Ready=True

整个过程平均耗时 45-90 秒。你可以用kubectl get challenges -A实时观察State字段从pending→processing→valid的变化。

4.2 NGINX Ingress Controller 如何“感知”证书更新？

很多同学疑惑：Secret更新了，NGINX 怎么知道要 reload？答案在--enable-dynamic-certificates参数。这个特性让 NGINX Ingress Controller 启动一个独立的 goroutine，持续监听Secret资源变化。当它发现kubesphere-monitoring-system/headlamp-tls的data.tls.crt字段被修改，会触发以下动作：

1. 将新证书内容写入内存中的证书缓存（非磁盘文件）
2. 向 NGINX 主进程发送USR1信号，要求其重新加载 SSL 证书（注意：不是HUP信号，HUP会 reload 全局配置，USR1只 reload 证书）
3. NGINX 主进程 fork 新 worker，新 worker 加载新证书，旧 worker 继续处理存量连接，实现无缝切换

你可以验证这一点：

# 查看 NGINX 进程树 kubectl -n kubesphere-controls-system exec deploy/nginx-ingress-controller -- ps aux | grep nginx # 会看到 master process 和多个 worker process # 修改 Secret 后，再执行一次，观察 worker process 的启动时间是否更新

注意：--enable-dynamic-certificates仅支持 TLS 证书热加载，不支持修改ingress-nginx的全局配置（如proxy-buffer-size）。后者仍需重启 Pod。

4.3 调试技巧：当锁图标不亮时，按顺序排查这五层

浏览器打不开 HTTPS？别慌，按 OSI 模型反向排查：

最实用的一招：用openssl直接连 Ingress Controller 的 NodePort（假设是 30080）：

openssl s_client -connect your-node-ip:30080 -servername headlamp.example.com

如果这里Verify return code: 0，说明证书本身没问题，问题出在 DNS 或浏览器缓存；如果返回unable to get local issuer certificate，说明证书链缺失，需要检查cert-manager是否启用了caBundle注入。

4.4 ArgoCD 场景下的特殊处理：如何让证书管理也 GitOps 化？

如果你用 ArgoCD 管理整个集群，Certificate和ClusterIssuer资源也应纳入 Git 仓库。但要注意两个陷阱：

• 陷阱一：CRD 依赖顺序
  ArgoCD 应用ClusterIssuer时，如果cert-manager.io/v1CRD 尚未安装，会卡在Progressing状态。解决方案：在 ArgoCD Application 中设置syncPolicy.automated.prune=false，并手动先helm install cert-manager，再让 ArgoCD 管理后续资源。

• 陷阱二：Secret 不可追踪
  Secret headlamp-tls由 cert-manager 自动生成，ArgoCD 默认会将其标记为OutOfSync（因为 Git 里没有这个 Secret）。正确做法：在 ArgoCD Application 的ignoreDifferences中忽略Secret的data字段：

  ignoreDifferences: - group: "" kind: Secret jsonPointers: - /data

这样，ArgoCD 只校验Secret的元数据（如name,namespace），不校验敏感内容，既保证安全，又避免误报。

5. 常见问题与独家排查技巧：那些文档里不会写的“坑”

5.1 问题速查表：高频故障现象与根因定位

5.2 独家避坑技巧：来自生产环境的 3 个硬核经验

技巧一：用cert-manager的debug日志级别精准定位
默认日志太简略，加-v=6参数开启 debug：

kubectl -n cert-manager scale deploy/cert-manager --replicas=0 kubectl -n cert-manager set env deploy/cert-manager CM_LOG_LEVEL=6 kubectl -n cert-manager scale deploy/cert-manager --replicas=1 kubectl logs -n cert-manager deploy/cert-manager -f \| grep -E "(http|challenge|order)"

你会看到 ACME 请求的完整 URL、响应 Body、以及每个 Challenge 的详细状态转换，比describe信息量大十倍。

技巧二：Staging 环境的“双证书”测试法
开发时，先用 Staging Issuer 申请一个headlamp-staging.example.com证书，验证流程通了，再切到 Prod Issuer。但注意：Staging 和 Prod 的账户密钥是分开的，privateKeySecretRef.name必须不同。我习惯命名为letsencrypt-staging和letsencrypt-prod，避免混淆。

技巧三：为Certificate设置revisionHistoryLimit防止 Secret 泛滥
cert-manager 每次续期都会创建新 Secret（带时间戳后缀），旧 Secret 不会自动清理。在Certificatespec 中加入：

spec: revisionHistoryLimit: 3

这样只保留最近 3 个版本的 Secret，避免kubectl get secret列表爆炸。

5.3 性能与安全加固：让这套方案扛住企业级流量

• 性能优化：cert-manager 默认每小时检查一次证书过期时间。对于高可用场景，可缩短为 15 分钟：

  helm upgrade cert-manager jetstack/cert-manager \ --set extraArgs="{--cluster-resource-sync-period=15m0s}"

• 安全加固：禁止ClusterIssuer被任意命名空间引用，加 RBAC 限制：

  apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: cert-manager-restricted-issuer rules: - apiGroups: ["cert-manager.io"] resources: ["clusterissuers"] verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: cert-manager-restricted-issuer-binding subjects: - kind: ServiceAccount name: cert-manager namespace: cert-manager roleRef: kind: ClusterRole name: cert-manager-restricted-issuer apiGroup: rbac.authorization.k8s.io

  这样，只有cert-managerSA 能读取ClusterIssuer，普通用户无法kubectl get clusterissuers。

• 可观测性增强：用 Prometheus 监控 cert-manager 指标。cert-manager 自带/metrics端点，关键指标：

  • cert_manager_certificate_ready_timestamp_seconds：证书就绪时间戳，可用于告警（如 > 1 小时未就绪）
  • cert_manager_http01_challenge_duration_seconds_bucket：HTTP01 验证耗时分布，定位 DNS 延迟问题

我在实际项目中，把这些指标接入 Grafana，做了个“证书健康度大盘”，实时显示集群内所有Certificate的状态、剩余有效期、最近一次续期耗时。运维同学再也不用半夜爬起来kubectl describe了。

6. 扩展思考：当你的需求超出 Let’s Encrypt 时该怎么办？

Let’s Encrypt 是免费、自动化、适合绝大多数场景，但它有硬性限制：不支持通配符证书的 DNS01 验证（需付费版）、不支持国密 SM2 证书、不支持企业级 OV/EV 证书（需人工审核）。当业务发展到这一步，你有三个选择：

• 选择一：平滑迁移到商业 CA
  cert-manager 支持 20+ 家 CA（如 DigiCert、Sectigo、ZeroSSL），只需更换ClusterIssuer的server和privateKeySecretRef，Certificate资源完全不用改。例如 DigiCert 的server是https://dcv2.api.digicert.com/acme/v2/，它支持 OV 证书的 CSR 自定义字段（如公司名、部门），只需在Certificate的usages字段声明即可。

• 选择二：自建私有 CA
  用step-ca或smallstep搭建内部 CA，颁发内网服务证书。这时ClusterIssuer的server指向你自己的step-ca地址，solvers改为none（因为内网无需 ACME 验证）。好处是完全可控、无外网依赖；坏处是客户端（如浏览器、curl）需手动导入根证书。

• 选择三：混合模式（Hybrid CA）
  对外服务用 Let’s Encrypt，对内服务用私有 CA。通过ClusterIssuer的namespaceSelector字段，让 cert-manager 根据命名空间自动路由到不同 Issuer：

  apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: hybrid-issuer spec: acme: # ... 其他配置 solvers: - selector: matchLabels: ca-type: public http01: ingress: class: nginx - selector: matchLabels: ca-type: internal none: {}

  然后在Certificate中打标签：

  metadata: labels: ca-type: public

这条路，我陪客户走过三次。第一次他们坚持用 Let’s Encrypt，结果某天 Let’s Encrypt 宣布停用 TLS-SNI-01 验证，导致全站证书失效；第二次他们上了 DigiCert，但 OV 证书审核拖了 3 天，业务上线延期；第三次我们用 hybrid 模式，对外用 Let’s Encrypt（自动），对内用step-ca（秒级签发），再也没出过证书问题。技术没有银弹，只有根据业务阶段做务实选择。

我在实际操作中发现，最难的从来不是敲命令，而是理解 cert-manager 的状态机设计哲学：它不追求“立刻成功”，而是追求“最终一致”。一个Certificate从Pending到Ready，中间可能经历Issuing、Ready、Renewing、Invalid多种状态，每一次状态变更都是事件驱动的。当你开始用kubectl get events --field-selector involvedObject.kind=Certificate来代替kubectl describe，你就真正入门了。这个项目教会我的，不仅是如何配 HTTPS，更是如何在一个分布式系统里，信任状态机，而不是信任某个瞬间的输出。