科技 · 实用指南
kubectl 报 x509：证书由未知机构签发？先证明实际信任路径
在更换凭据或关闭 TLS 验证之前，先确认实际使用的 kubeconfig、集群端点、CA 字节、代理路径和服务器呈现的证书链。
kubectl 的 x509 错误不会告诉你究竟是哪份配置、哪个端点或哪条证书链失败。第一步应证明当前进程实际使用的值。
本指南会在修改任何信任设置前，区分过期或合并后的 kubeconfig、意外代理、被替换的 API 服务器证书以及主机名不匹配。
固定准确的客户端、错误与调用环境
保存完整错误、命令、时间、客户端版本和 shell 环境。记录 HOME、KUBECONFIG 及显式参数，但不要把凭据复制到工单或聊天。
不要先删除 ~/.kube、替换所有 CA 或添加不安全参数；错误尚不能证明当前进程使用了哪个文件、端点、代理或证书链。
证明实际 kubeconfig 与当前 context
运行 current-context，并用 config view --minify 检查当前集群和用户。KUBECONFIG 合并时先设置映射键的文件胜出，而 --kubeconfig 只选一个文件。
仅在受保护的本地会话使用 --raw。把实际输出与预期文件比较，排除过期首文件、不同 HOME、服务账号或 GUI 启动器。
在不修改的情况下提取端点与信任锚
记录 server URL、tls-server-name、proxy-url、CA 路径及是否存在 CA data。嵌入数据覆盖 CA 文件，相对路径以包含它的 kubeconfig 为基准。
只在权限受限的临时文件中解码 CA，记录主题、签发者、有效期和指纹；引用 CA 文件时解析真实路径并哈希字节。
沿同一网络路径检查实际呈现的证书
从同一网络命名空间、VPN、容器或 runner 检查实际主机和端口。用 OpenSSL 的 -connect、-servername 与 -verify_return_error 验证，而不是把 TCP 成功当作信任成功。
检查 proxy-url、HTTPS_PROXY、HTTP_PROXY 与 NO_PROXY。复制证书前比较叶证书主题和 SAN、签发链及指纹。
先分类不匹配，再选择修复
常见分支包括 CA 轮换后的旧配置、合并后选错 context、CA data 覆盖正确文件、中间证书缺失、代理证书或 SNI 不匹配。
不要盲目信任意外端点返回的叶证书。信任锚应来自集群所有者、托管服务商或其他已认证控制面通道。
只修复一条明确的信任契约
托管集群应按服务商文档刷新凭据并比较新旧 cluster 条目；自管集群应安装已验证的签发 CA 或正确链，并保留预期服务器名。
代理不应参与时修正 proxy-url 或 NO_PROXY；代理必须参与时通过组织的已认证流程获取其 CA，保持 insecure-skip-tls-verify 为 false。
用原始环境验证并保留回滚证据
使用同一 kubeconfig、context、网络路径和原命令复测，先确认 TLS 错误消失且端点与签发者属于目标集群。
记录新旧配置哈希、cluster 条目、CA 指纹、端点、代理决策、刷新命令和回滚文件；安全删除临时 CA。
