go应用无需适配cert-manager，只需标准deployment、service、ingress三件套，且ingress需声明tls并关联certificate资源；certificate必须显式创建，引用正确clusterissuer，并确保dnsnames与ingress hosts一致。
Go 应用本身不需要特殊适配 cert-manager，关键在于 Ingress（或 Gateway）资源是否正确声明 TLS 并关联 Certificate —— 证书续签完全由 cert-manager 控制器驱动，与 Go 代码无关。
Go 应用部署只需标准三件套
cert-manager 不关心你跑的是 Go、Python 还是 Java，它只认 Kubernetes 原生资源。只要你的 Go 服务暴露了 HTTP 接口，并通过 Ingress 暴露到公网，就满足自动签发前提。
- Deployment：定义 Go 二进制镜像、端口（如
8080）、健康检查（/healthz） - Service：ClusterIP 类型，
targetPort对应容器端口，比如8080 - Ingress：必须带
tls字段，hosts域名需和后续Certificate中一致，且ingressClassName要匹配你集群中实际的 Ingress Controller（如nginx、traefik或alb）
示例片段（Ingress 中关键部分）：
spec:
ingressClassName: nginx
tls:
- hosts:
- api.example.com
secretName: api-tls-secret # cert-manager 会自动创建并更新这个 Secret
rules:
- host: api.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: go-api-service
port:
number: 8080
Certificate 资源必须显式声明，且引用正确的 ClusterIssuer
很多人以为只要 Ingress 有 tls 就能自动触发签发 —— 实际上，cert-manager 不会“扫描” Ingress 自动创建证书。你必须手动创建一个 Certificate 资源，明确告诉它：“请为 api.example.com 向 letsencrypt-prod 申请证书，并把结果存进 api-tls-secret。”
-
spec.secretName必须和 Ingress 中的secretName完全一致（大小写敏感） -
spec.issuerRef.name要指向已存在的ClusterIssuer（如letsencrypt-prod），且kind写对（ClusterIssuer不是Issuer） -
spec.dnsNames必须包含 Ingress 中所有host，多域名用列表，不能漏
最小可用 Certificate 示例：
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: api-tls
namespace: default
spec:
secretName: api-tls-secret
issuerRef:
name: letsencrypt-prod
kind: ClusterIssuer
dnsNames:
- api.example.com
常见失败原因：HTTP-01 验证卡在 Pending 状态
这是最常卡住的环节。cert-manager 创建好 ACME Challenge 后，Let’s Encrypt 会向 http://api.example.com/.well-known/acme-challenge/xxx 发起 GET 请求。如果收不到响应，状态就永远是 Pending。
- 域名 DNS 未解析到 Ingress Controller 的 External IP（
kubectl get svc -n ingress-nginx ingress-nginx-controller查 LoadBalancer IP） - Ingress Controller 的
class和Certificate中 solver 的ingress.class不一致（比如 ClusterIssuer 写了nginx，但实际用的是traefik） - Ingress 注解里误加了重写规则（如
nginx.ingress.kubernetes.io/rewrite-target），导致/.well-known/...路径被改写或 404 - 防火墙或安全组没放开 80 端口（HTTP-01 强制走 80，443 不行）
排查命令：
kubectl describe certificate api-tls -n default<br>kubectl describe challenges -n default # 看具体哪条 challenge 失败<br>kubectl logs -n cert-manager deploy/cert-manager | grep 'api-tls'
别跳过 staging 环境验证这一步
直接上 letsencrypt-prod 很容易因配置错误触发 Let’s Encrypt 的速率限制（比如 5 次失败后 1 小时内无法重试）。务必先用 staging 地址测试通再切生产。
- 修改
ClusterIssuer的spec.acme.server为https://acme-staging-v02.api.letsencrypt.org/directory - staging 签发的证书浏览器会报不安全，但
kubectl get certificate显示Ready=True就代表流程通了 - 确认
Certificate的status.conditions里有Type: Ready, Status: "True"
真正上线前，唯一要改的只是 ClusterIssuer 的 server 地址和 privateKeySecretRef.name（可复用同一 Secret 名，cert-manager 会覆盖）。
复杂点在于 ClusterIssuer 的 solver 配置必须和你的实际网络拓扑严丝合缝——比如用阿里云 DNS-01，就要提前部署 cert-manager-webhook-alidns，并在 ClusterIssuer 里正确引用 accessKeyIDSecretRef；而 HTTP-01 表面简单，实则对 Ingress 路径透传的健壮性要求极高。这些细节一错，整个链路就静默失败。
