科技 · 實用指南
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。
