kubectl get nodes -o wide

### 使用 `kubectl` 获取 Kubernetes 集群中的节点列表 为了获取 Kubernetes 集群中所有节点的列表及其状态信息，可以使用如下命令： ```bash kubectl get nodes ``` 此命令会返回集群内所有节点的相关数据，包括但不限于名称和健康状况等基本信息[^1]。 如果希望获得更详细的输出，比如查看每个节点更为详尽的状态描述和其他属性，则可以在原有指令基础上增加 `-o wide` 参数来实现扩展视图功能： ```bash kubectl get nodes -o wide ``` 这不仅限于展示基本详情，还会提供有关节点内部 IP 地址、操作系统映像以及其他附加组件的信息。 对于那些需要进一步了解特定节点情况的情况而言，还可以利用 `describe node` 子命令针对单个或多个指定目标执行深入查询动作。例如要详细了解名为 "node-name" 的具体实例时可输入下面这条语句： ```bash kubectl describe node node-name ``` 该操作能够揭示关于所选对象更加全面的技术细节以及最近发生的事件记录等内容。

<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连接问题。建议先执行第**二**部分的基础检查，再根据现象进入专项排查。