Kubernetes集群证书过期导致kubectl命令失败，根本原因在于控制平面证书（如apiserver.crt、ca.crt等）失效，需通过kubeadm certs renew更新证书，而非修改Kratos代码；所有x509错误均源于TLS握手时标准库校验失败。
Kratos 框架本身不管理 TLS 证书生命周期，证书过期问题实际出在运行时环境（如反向代理、gRPC 客户端/服务端配置、或宿主机证书信任链），不是 Kratos 代码逻辑导致的。
查 kubectl get pods 报错是否来自 Kubernetes 集群证书
如果你在 Kratos 服务部署后执行 kubectl 命令失败并提示类似 x509: certificate has expired or is not yet valid，那问题根本不在 Kratos，而是你本地 ~/.kube/config 或集群控制平面证书已过期。
- 运行
kubectl cluster-info和kubectl auth can-i --list看是否同样报证书错误 - 检查
/etc/kubernetes/pki下证书有效期：openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates - 若确认是集群证书过期，需用
kubeadm certs renew更新，而非修改 Kratos 代码
查 Kratos gRPC 客户端连接失败是否因证书验证失败
Kratos 默认使用 grpc.WithTransportCredentials(credentials.NewTLS(&tls.Config{})) 启用双向 TLS，若服务端证书过期或 CA 不可信，客户端会直接断连并报 rpc error: code = Unavailable desc = connection closed 或更具体的 x509: certificate has expired。
- 确认服务端证书（如 Nginx / Envoy / 自建 gRPC server）是否在有效期内：
openssl s_client -connect your-service:9000 -servername your-service 2>/dev/null | openssl x509 -noout -dates - 若用自签名 CA，在 Kratos 客户端初始化时必须显式加载根证书：
creds := credentials.NewTLS(&tls.Config{RootCAs: rootCAPool})，漏掉这步会导致系统默认 CA 无法验证 - 开发调试可临时禁用验证（仅限测试）：
&tls.Config{InsecureSkipVerify: true}，但上线前必须撤回
查 Kratos HTTP Server 启动时报 http: TLS handshake error
当 Kratos 以 HTTPS 模式启动（http.Server.TLSConfig 非 nil），且绑定的证书文件过期或私钥不匹配，日志会出现 TLS handshake error 并伴随具体 OpenSSL 错误码。
- 检查证书文件路径是否正确：Kratos
server/http/http.go中传入的certFile和keyFile路径必须可读，且证书未被覆盖或 chmod 错误 - 用
openssl x509 -in server.crt -checkend 86400查 24 小时内是否过期（返回 0 表示未过期） - 常见坑：Docker 镜像里挂载证书时用了
:ro但证书实际是软链接，宿主机更新后容器内仍指向旧文件；或用cert-manager签发的证书 Secret 没被 Kratos 正确 reload
真正容易被忽略的是：Kratos 运行时完全不感知证书是否“快过期”，它只负责把 tls.Config 交给 Go 标准库。所有证书有效性校验都由 crypto/tls 在握手瞬间完成——这意味着你得在日志里抓 x509 关键字，而不是翻 Kratos 的 middleware 或 config 源码。
