I/O error on GET request for,PKIX path building failed,,unable to find valid certification path

Posted 2023-03-27

参考技术A 在使用Springboot的RestTemplate时候，我需要调用一个以Https开头的链接，遇到了如下报错

大意就是我这个是https的请求，比较安全，需要跟服务器建立链接，但是呢你又没有证书所以我就报错了。

如果需要证书，并且服务器是有这个东西，那么你就可以去找证书并且实现即可，如果你没有证书不想做这个东西那么我们就采取禁用ssl证书这样的方式来做了。

主方法：

禁用ssl方法

Terraform dial tcp 192.xx.xx.xx:443: i/o timeout error

【中文标题】Terraform dial tcp 192.xx.xx.xx:443: i/o timeout error

【英文标题】：

【发布时间】：2021-09-24 20:44:56

【问题描述】：

我正在尝试使用 GitLab + Terraform 实施 CI / CD 到 K8S 集群，并且在 CentOS

上设置了 K8S 控制平面（主节点）

但是，管道作业失败并出现以下错误

Error: Failed to get existing workspaces: Get "https://192.xx.xx.xx/api/v1/namespaces/default/secrets?labelSelector=tfstate%3Dtrue": dial tcp 192.xx.xx.xx:443: i/o timeout

根据上述错误 (default/secrets?labelSelector=tfstate%3Dtrue)，我认为该错误与默认命名空间中缺少“terraform secret”有关

示例（取自我的 Windows 的 Terraform 机密）

PS C:\> kubectl get secret
NAME                    TYPE                                  DATA   AGE
default-token-7mzv6     kubernetes.io/service-account-token   3      27d
tfstate-default-state   Opaque                                1      15h

但是，我不确定哪个进程会创建“tfsecret”，还是我们应该手动创建它？

如果我的理解有误以及是否遗漏了其他任何内容，请告诉我

编辑

出现上述问题是因为现有的 Gitlab-runner 位于不同的子网（例如 172.xx.xx.xx 而不是 192.xx.xx.xx）

我被要求使用在同一子网上运行的不同 Gitlab-runner，现在它抛出以下错误

Error: Failed to get existing workspaces: Get "https://192.xx.xx.xx:6443/api/v1/namespaces/default/secrets?labelSelector=tfstate%3Dtrue": x509: certificate signed by unknown authority

现在，我有点困惑证书问题是否在 GitLab-Runner and Gitlab-Server 或 Gitlab-Server and K8S Cluster 或其他之间

【问题讨论】：

错误提示访问apiserver失败。

dial tcp 192.xx.xx.xx:443: i/o timeout 是此错误的实际原因，default/secrets?labelSelector=tfstate%3Dtrue 端点不可访问，因为与 192.xx.xx.xx:443 的连接超时。 192.xx.xx.xx 应该是你的 api-server IP。

请提供有关您的环境的更多详细信息 - api-server 详细信息、部署的 yaml 清单等。这将使故障排除更容易。

用更新的结果编辑了我的问题

这似乎是 gitlab-runner 和/或 Terraform 的问题。 Failed to get existing workspaces 似乎是 Terraform 特有的。您可能还想看看gitlab-runner documentation。

【参考方案1】：

您已将 Kubernetes 配置为 Terraform 配置的远程状态后端。错误是，后端正在尝试查询现有机密以确定配置了哪些工作空间。 x509: certificate signed by unknown authority 表示远程状态后端使用的 KUBECONFIG 与您要连接的 API 服务器的 CA 不匹配。

如果运行器本身是 K8s pod，请确保您提供与目标集群匹配的 KUBECONFIG，并且通过读取每个 K8s pod 具有的服务帐户令牌，远程状态不会将自身配置为 in-cluster - 在大多数情况下仅适用于运行 pod 的集群。

您没有提供足够的信息来更具体。但从大局来看，您必须配置状态后端，以及连接到 K8s 的任何提供程序。理论上，状态后端机密和 K8s 资源不必在同一个集群上。这意味着，您可能必须对状态后端和 K8s 提供程序进行不同的配置。