kubectl命令报错:Unable to connect to the server: dial tcp XXX:16443: connect: no route to host

简介: kubectl命令报错:Unable to connect to the server: dial tcp XXX:16443: connect: no route to host

前提

架构:keepalived+haproxy+kubernetes


问题说明

kubernetes集群好久不用了,今天打开集群执行一个kubectl get nodes命令,报错如下:

Unable to connect to the server: dial tcp 192.168.2.XXX:16443: connect: no route to host


分析原因

出现这个问题几种原因,

  1. 集群坏了:如果报错的IP是master1的节点IP或虚拟IP(vip)加16443端口号,执行kubectl命令还报上面的错误,说明集群坏了,需要逐步排查原因。
  2. /root/.kube/config中的IP地址错误:如果错误中的IP地址不是master1的节点IP或虚拟IP(vip)加16443端口号,需要修改配置文件中的IP。一般改为虚拟IP(vip)+16443端口号。
  3. haproxy:由于haproxy配置的是监听16443端口,也是集群的入口。因为报错的端口号是16443,所以要检查是否是haproxy的IP问题,如果是的话要修改haproxy配置文件,然后重启haproxysystemctl restart haproxy


解决问题

经排查,我的问题属于第二种,因为报错的意思是没有找不到192.168.2.XXX:16443这个路由,于是检查config文件:

vim /root/.kube/config


查看IP是否正确,经检查,我虚拟IP为:192.168.2.249,而这里显然不是,将IP修改为192.168.2.249:16443

892ee2b773a5462cbad25e4083c4c297.png

保存退出后再次查看节点状态,kubectl命令就可以正常使用了。

bda88e6ec2cf4a329afa07bdb2aa410a.png

另一中错误:Unable to connect to the server: dial tcp 123.56.91.155:6443: i/o timeout

Unable to connect to the server: dial tcp 123.56.91.155:6443: i/o timeout

刚开始爆出的错误是这个,一看这个IP就不是我当初创建集群时的IP,而是一个阿里云公网IP,其实进入config文件中修改成自己集群的IP就可以了。

相关文章
|
Shell 容器 Perl
Back-off restarting failed container 问题解决
Back-off restarting failed container 问题解决
2584 0
|
Kubernetes 容器 Perl
【kubernetes】解决: kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = faile...
【kubernetes】解决: kubelet Failed to create pod sandbox: rpc error: code = Unknown desc = faile...
16187 0
|
Kubernetes 搜索推荐 数据安全/隐私保护
Containerd ctr、crictl、nerdctl 实战
Containerd ctr、crictl、nerdctl 实战
4295 1
|
6月前
|
Kubernetes API 网络安全
当node节点kubectl 命令无法连接到 Kubernetes API 服务器
当Node节点上的 `kubectl`无法连接到Kubernetes API服务器时,可以通过以上步骤逐步排查和解决问题。首先确保网络连接正常,验证 `kubeconfig`文件配置正确,检查API服务器和Node节点的状态,最后排除防火墙或网络策略的干扰,并通过重启服务恢复正常连接。通过这些措施,可以有效解决与Kubernetes API服务器通信的常见问题,从而保障集群的正常运行。
404 17
|
存储 Kubernetes 调度
k8s常见的排错指南Node,svc,Pod等以及K8s网络不通问题
k8s常见的排错指南Node,svc,Pod等以及K8s网络不通问题
4714 1
network is not ready: runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady me
network is not ready: runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady me
419 1
|
Kubernetes 容器
Kubernetes(K8S) 拉取镜像 ImagePullBackOff pull access denied
Kubernetes(K8S) 拉取镜像 ImagePullBackOff pull access denied
478 0
|
Kubernetes API 数据库
容器服务 Pod 处于 CrashLoopBackOff的原因及解决方法
"CrashLoopBackOff" 是 Kubernetes 中 Pod 进入的一种错误状态,通常是由于容器不断崩溃(失败)而触发的重启策略所导致的。以下是 Pod 处于 CrashLoopBackOff 状态的原因及相应的解决方法: ### 原因: 1. **应用错误:** - 容器内部的应用程序崩溃,导致容器退出。 - 应用程序可能因为异常、未捕获的错误、配置问题、依赖缺失等原因导致崩溃。 2. **错误的启动命令:** - Pod 的启动命令或入口点设置错误,导致容器无法正确启动。 3. **资源限制:** - Pod 可能受到内存或 CPU 资源限制,
3899 0
|
Kubernetes 容器
k8s-unable to connect to the server:x509:certificates signed by unknown authority......
k8s-unable to connect to the server:x509:certificates signed by unknown authority......
587 0
|
安全 数据安全/隐私保护 Docker
harbor使用http的解决办法
harbor使用http的解决办法
984 0