修复kubectl get cs 健康状态问题：k8s端口配置与重启操作

在Kubernetes（k8s）环境中，当执行`kubectl get cs`命令时，可能会遇到显示某些组件如scheduler和controller-manager状态为不健康（Unhealthy）的情况。这通常是因为Kubernetes服务未能成功连接到这些组件的服务端口，比如scheduler和controller-manager通过HTTP健康检查暴露在`127.0.0.1:10251`和`127.0.0.1:10252`上。错误提示中的`dialtcp: connection refused`表示尝试连接时服务器没有响应。 问题的根源在于Kubernetes服务配置文件（如`kube-scheduler.yaml`和`kube-controller-manager.yaml`）中的端口设置可能被注释掉了或者默认配置导致端口未被公开。`--port=0`参数通常意味着该服务会随机选择一个端口，而非固定一个端口，这可能导致健康检查无法找到它们。 解决这个问题的步骤如下： 1. **检查和修改配置文件**：首先，打开调度器和控制器管理器的配置文件，找到类似`--port=0`的部分，将其注释掉或设置为一个固定的、可以访问的端口，确保它们可以被健康检查服务正确连接。 ```yaml # 原始配置示例： # - command: # - /usr/local/bin/kube-scheduler # - --port=0 # 修改后的配置示例： - command: - /usr/local/bin/kube-scheduler - --port=10251 # 或者一个你确定可以被健康检查服务访问的端口 ``` 2. **重启kubelet服务**：由于kubelet是Kubernetes节点的核心组件，它负责与API Server通信并管理Pods，所以重启kubelet服务可以帮助重新初始化连接，并可能解决因临时问题导致的连接失败。 ```sh [root@m1~]# systemctl restart kubelet ``` 3. **再次检查状态**：重启后，再次运行`kubectl get cs`来确认组件的状态是否已变更为健康（Healthy）。 执行以上操作后，你应该能看到scheduler和controller-manager的状态变为 Healthy，表明它们现在可以正常响应健康检查请求。值得注意的是，虽然解决了当前问题，但长期而言，确保组件暴露正确的端口以及网络策略配置也是维护集群稳定的重要环节。如果问题持续存在，可能还需要检查防火墙规则、网络配置、或集群内的服务发现机制等其他因素。