[root@master ~]# kubectl get pods The connection to the server 192.168.58.19:6443 was refused - did you specify the right host or port?

<think>嗯，用户之前问过关于Kubernetes API Server无法访问的问题，现在又遇到了新的问题。之前的问题是关于身份验证的403错误，现在却提示连接被拒绝，也就是无法连接到服务器。可能需要考虑不同的原因。 首先，检查错误信息：“The connection to the server 192.168.58.19:6443 was refused - did you specify the right host or port?”，这通常意味着kubectl无法建立到API Server的网络连接。可能的原因有很多，比如API Server服务未运行，网络端口被阻止，或者配置错误。 接下来，需要分步骤排查。首先应该确认API Server是否在运行。用户是在master节点上执行命令，所以需要检查kube-apiserver的Pod状态。使用kubectl get pods -n kube-system | grep apiserver，如果发现Pod不存在或者处于非Running状态，可能需要重启相关组件，比如kubelet，或者检查日志。 如果API Server的Pod正常，那么可能需要检查API Server的日志，看看是否有启动错误。使用docker logs命令查看日志，或者journalctl -u kubelet查看kubelet的日志，因为kubelet负责管理这些静态Pod。 另一个可能性是网络问题。检查API Server是否在监听6443端口，使用ss -tuln | grep 6443命令。如果没有输出，说明API Server没有正确绑定到端口，可能是配置错误或者端口被占用。此外，防火墙设置也需要检查，比如iptables或firewalld是否阻止了6443端口的流量。 SSL证书问题也可能导致连接被拒绝。如果证书无效或过期，API Server可能无法启动。检查证书的有效期，使用openssl命令查看证书的日期，或者检查kube-apiserver的日志中是否有证书相关的错误信息。 还有可能是kubeconfig文件配置错误，比如指定了错误的主机地址或端口。检查~/.kube/config文件中的server字段是否正确指向了API Server的地址。如果是高可用集群，可能还需要检查负载均衡器的状态。 如果用户之前修改过API Server的配置，比如在kube-apiserver.yaml中添加了参数，可能需要检查这些参数是否正确，是否有语法错误导致服务无法启动。另外，节点资源不足，比如CPU或内存耗尽，也可能导致API Server崩溃，需要检查节点的资源使用情况。 总结下来，处理这个问题需要系统性地排查各个可能的原因，从服务状态、日志、网络配置、证书、kubeconfig等多个方面入手。需要逐步验证每个环节，找到具体的故障点，然后针对性地解决。</think>以下是对`kubectl get pods`报错`connection refused`的深度分析及解决方案，按照优先级排序： --- ### **一、核心问题定位** 错误`connection refused`表明存在以下可能性： 1. **API Server进程未运行** 2. **网络连接被阻断** 3. **证书配置错误** 4. **kubelet服务异常** --- ### **二、立即排查步骤** #### **1. 检查API Server运行状态** ```bash # 查看API Server容器状态（适用于使用docker的情况） docker ps | grep kube-apiserver # 检查kubelet日志（所有K8s节点） journalctl -u kubelet --since "5 minutes ago" | grep -i apiserver ``` #### **2. 验证6443端口监听** ```bash # 在master节点执行 ss -tuln | grep 6443 # 正确输出示例（应有LISTEN状态）： tcp LISTEN 0 4096 [::]:6443 [::]:* ``` #### **3. 检查基础服务** ```bash # 确认kubelet正常运行（所有节点） systemctl status kubelet -l # 确认etcd集群健康（master节点） docker exec -it etcd_container_name etcdctl endpoint health ``` --- ### **三、关键故障场景处理** #### **场景1：API Server崩溃** **现象**：`ss -tuln`无6443端口监听 **解决方案**： ```bash # 强制重启API Server（适用于静态Pod部署） rm -f /etc/kubernetes/manifests/kube-apiserver.yaml sleep 10 cp /etc/kubernetes/manifests.bak/kube-apiserver.yaml /etc/kubernetes/manifests/ # 检查恢复情况（等待1-2分钟） kubectl get componentstatuses ``` #### **场景2：证书过期** **验证方法**： ```bash # 检查API Server证书有效期 openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates # 检查客户端证书（如admin.conf） openssl x509 -in ~/.kube/config -noout -dates ``` **修复流程**： ```bash # 备份原有证书 mv /etc/kubernetes/pki/apiserver.{crt,key} ~/ # 重新生成证书 kubeadm init phase certs apiserver --config /etc/kubernetes/kubeadm-config.yaml # 重启API Server systemctl restart kubelet ``` --- ### **四、网络层深度排查** #### **1. 防火墙规则检查** ```bash # CentOS/RHEL firewall-cmd --list-all | grep 6443 # 或检查iptables iptables -L -n -v | grep 6443 ``` **临时开放端口**： ```bash firewall-cmd --add-port=6443/tcp --permanent firewall-cmd --reload ``` #### **2. 路由验证** ```bash # 从worker节点测试连通性 telnet 192.168.58.19 6443 # 或使用网络诊断工具 mtr -P 6443 192.168.58.19 ``` --- ### **五、高级调试技巧** #### **1. 直接访问etcd验证集群数据** ```bash ETCDCTL_API=3 etcdctl \ --endpoints=https://127.0.0.1:2379 \ --cacert=/etc/kubernetes/pki/etcd/ca.crt \ --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \ --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \ get / --prefix --keys-only ``` #### **2. 内存/CPU资源分析** ```bash # 检查API Server内存使用 ps aux | grep kube-apiserver | grep -v grep | awk '{print $4,$5}' # 设置内存限制（编辑kube-apiserver.yaml） spec: containers: - name: kube-apiserver resources: requests: memory: "2Gi" cpu: "1" limits: memory: "4Gi" cpu: "2" ``` --- ### **六、生产环境恢复预案** **步骤**： 1. 优先恢复etcd集群 2. 滚动重启control plane组件 3. 验证核心DNS和网络插件 4. 逐步恢复工作节点 **恢复检查清单**： ```bash kubectl get cs # 组件状态 kubectl get nodes -o wide nslookup kubernetes.default.svc.cluster.local curl -k https://localhost:6443/readyz ``` --- ### **常见误区提醒** 1. **错误认为所有节点都需要开放6443端口** *实际只需master节点的6443可被worker访问* 2. **误改kubelet的`--kubeconfig`参数** *worker节点的kubelet只需连接API Server，无需完整kubeconfig* 3. **忽略时间同步问题** *执行`chronyc sources`确保所有节点时间偏差<1秒* --- 通过以上步骤可系统性诊断和解决API Server连接问题。建议先执行第**二**部分的基础检查，再根据现象进入专项排查。