记录 K8S 挂了的解决经过

文章讲述了同事在部署Kubernetes(K8S)集群时遇到Redis和禅道服务不可用的问题。通过排查发现Kubesphereweb界面无法访问,kubectl命令失败,怀疑是由于/dev/mapper/centos-var目录满载。文章解释了LVM逻辑卷的概念,指出/var目录可能存在问题。最终通过删除日志文件解决,docker重启成功。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

背景:早上到公司,有同事反馈部署K8S在集群上的 Redis 和 禅道 都不可用

排查循序:

  1. 登录 kubesphere 的 web 界面 (界面打开失败)
  2. ssh 登录主服务器 (正常)
  3. 在主服务器上运行 kubectl get node 命令,报错 The connection to the server lb.kubesphere.local:6443 was refused - did you specify the right host or port? (不正常)
  4. 执行 docker ps -a,发现大量容器状态为 Exited (不正常)
  5. 执行 free 命令,可用空间足够 (正常)
  6. 执行 df -h 命令,发现有一个挂载 100%,目录为 /dev/mapper/centos-var (发现疑点

为了确认是不是这个问题导致,决定删除该目录下的一些文件

首先了解 /dev/mapper/centos-var 目录的作用

在Linux系统中,/dev/mapper/centos-var是一个设备映射(Device Mapper)的路径,它通常用于存储逻辑卷管理器(Logical Volume Manager,LVM)中的逻辑卷。

LVM是一种在Linux系统上进行磁盘管理的技术,它允许您将多个物理磁盘合并成一个或多个逻辑卷,并提供了更灵活的磁盘空间管理和扩展能力。

/dev/mapper/centos-var 表示一个逻辑卷,其中的"centos-var"是逻辑卷的名称。逻辑卷是由物理卷(Physical Volume)组成的,物理卷可以是磁盘分区、磁盘或者软件RAID等。逻辑卷可以被格式化并挂载到文件系统上,以供用户存储数据。

在这种情况下,/dev/mapper/centos-var很可能是CentOS操作系统中/var目录的逻辑卷。/var目录通常用于存储可变的数据,例如日志文件、数据库文件、缓存等。通过将/var目录放置在逻辑卷上,可以方便地对其进行管理、扩展和备份。

请注意,具体的用途可能因系统配置和需求而有所不同。如果您想详细了解该逻辑卷的具体用途,可以查看系统的LVM配置文件或者运行lvdisplay命令来获取更多信息。

解决方案:
删除一些日志文件,即删除 /var/log/ 下的一些文件,删除后 docker 自动重启成功

<think>好的,我现在需要帮助用户解决他们用KubeKey安装的KubernetesKubeSphere环境中的服务掉的问题,特别是如何重启这些服务。首先,我得理清可能的原因和解决步骤。 用户提到服务了,但具体哪个服务不明确。KubeSphere本身包含多个组件,比如APIServer、Controller Manager等,还有底层的Kubernetes组件如kube-apiserver、etcd等。首先,我需要确定用户的问题范围,是KubeSphere的界面无法访问,还是整个Kubernetes集群出了问题? 接下来,我应该建议用户先检查集群状态。使用kubectl命令查看节点状态和Pod状态,这能帮助确定问题所在。比如,运行kubectl get nodes看看节点是否都处于Ready状态,如果有节点NotReady,可能需要进一步排查该节点的问题。然后,检查kube-system命名空间下的Pod,特别是核心组件如etcd、kube-apiserver、kube-controller-manager、kube-scheduler是否都在运行。如果这些Pod有问题,可能需要重启它们。 如果发现某个组件崩溃,用户可能需要手动重启相关的Pod。例如,如果kube-apiserver的Pod处于CrashLoopBackOff状态,可以使用kubectl delete pod命令删除该Pod,让Kubernetes自动重新创建它。同样,对于KubeSphere的组件,如ks-apiserver,也可以采用同样的方法。 另外,用户可能没有直接访问系统服务的权限,因为KubeKey安装的集群通常使用容器化的组件,所以大多数情况下不需要操作systemd服务。不过,如果问题出在容器运行时(如containerd或docker),或者kubelet服务本身,那么可能需要检查这些服务的状态。例如,在节点上执行systemctl status kubelet看看kubelet是否在运行,如果没有,用systemctl restart kubelet来重启。 对于KubeSphere控制台无法访问的情况,除了检查相关的Deployment和Pod,还需要确认网络策略、Ingress配置以及存储是否正常。例如,如果使用了NodePort或LoadBalancer,确保端口是开放的,并且网络策略没有阻止访问。 用户可能遇到的问题还包括证书过期、资源不足(如CPU、内存、磁盘空间)、配置错误等。需要根据具体的错误日志进一步分析。例如,查看Pod的日志使用kubectl logs <pod-name>,或者描述Pod的状态kubectl describe pod <pod-name>来获取更多信息。 总结来说,处理步骤大致如下: 1. 检查集群整体状态,确认问题范围。 2. 检查核心组件Pod的状态,重启有问题的Pod。 3. 必要时检查节点上的服务如kubelet和容器运行时。 4. 查看日志和事件,定位具体错误原因。 5. 根据错误原因采取相应措施,如调整资源、修复配置、更新证书等。 在提供解决方案时,需要分步骤指导用户操作,并提醒他们在执行命令时的注意事项,比如替换Pod名称、确认命名空间等。同时,要考虑到用户可能对Kubernetes操作不太熟悉,所以命令示例要具体明确,避免歧义。</think>使用KubeKey安装的Kubernetes/KubeSphere集群服务异常时,可按以下步骤排查和重启服务: --- ### 一、首先检查集群状态 ```bash # 查看节点状态(若有NotReady节点需优先处理) kubectl get nodes # 检查核心组件Pod状态(关注kube-system命名空间) kubectl get pods -n kube-system kubectl get pods -n kubesphere-system ``` --- ### 二、重启服务的两种场景 #### 场景1:Kubernetes核心组件异常(如kube-apiserver崩溃) ```bash # 1. 查找相关Pod(例如kube-apiserver) kubectl get pods -n kube-system | grep apiserver # 2. 删除Pod触发自动重建(K8s会自动重新调度) kubectl delete pod <apiserver-pod-name> -n kube-system ``` #### 场景2:KubeSphere服务异常(如控制台无法访问) ```bash # 1. 查找KubeSphere相关Deployment(例如ks-apiserver) kubectl get deploy -n kubesphere-system # 2. 重启指定服务(通过scale操作触发重建) kubectl scale deploy ks-apiserver --replicas=0 -n kubesphere-system kubectl scale deploy ks-apiserver --replicas=1 -n kubesphere-system ``` --- ### 三、特殊情况的处理 #### 1. 如果节点上的kubelet服务异常(非常规情况) ```bash # 在故障节点上执行 systemctl restart kubelet journalctl -u kubelet -f # 查看实时日志 ``` #### 2. 容器运行时异常(如containerd/docker) ```bash systemctl restart containerd # 根据实际运行时选择 systemctl status containerd ``` --- ### 四、关键排查技巧 1. **查看Pod日志**: ```bash kubectl logs <pod-name> -n <namespace> --tail=100 ``` 2. **检查Pod事件**: ```bash kubectl describe pod <pod-name> -n <namespace> ``` 3. **存储/网络问题**: - 检查PVC是否处于`Pending`状态 - 检查Calico/Cilium等网络插件Pod是否正常 --- ### 五、预防建议 1. 通过KubeSphere仪表盘设置监控告警 2. 定期检查集群资源使用率(特别是CPU/内存/存储) 3. 重要生产环境建议部署高可用架构 > 💡 提示:如果问题持续存在,请提供以下信息以便进一步分析: > 1. `kubectl get nodes` 输出 > 2. 异常Pod的`describe`和`logs`信息 > 3. 故障发生前的集群操作记录
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值