kubernetes集群的服务器重启之后遇到的问题

本文详细介绍了在Kubernetes集群服务器重启后遇到的一系列问题及解决方法,包括kubelet进程启动失败、交换空间未关闭导致的问题,以及如何正确创建容器实例等。通过关闭交换空间和使用正确的命令,成功恢复了集群的状态。

kubernetes集群部署见我的上一篇博客。部署kubernetes集群的服务器重启之后,执行kubectl get nodes报错:

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

查询进程,发现没有kube的进程启动:

[root@k8s-master ~]# ps -aux | grep "kube"
root      2911  0.0  0.0 112728   972 pts/0    R+   21:40   0:00 grep --color=auto kube

启动kubelet进程:

 systemctl start kubelet

再去查看kubectl get pods,发现还是报上面那个错,用journalctl -xeu kubelet这个命令查看,发现里面有报错。

[root@k8s-master ~]# journalctl -xeu kubelet
5月 25 22:01:59 k8s-master kubelet[6066]: I0525 22:01:59.542680    6066 plugins.go:100] No cloud provider specified.
5月 25 22:01:59 k8s-master kubelet[6066]: I0525 22:01:59.542691    6066 server.go:837] Client rotation is on, will bootstrap in
5月 25 22:01:59 k8s-master kubelet[6066]: I0525 22:01:59.544221    6066 certificate_store.go:130] Loading cert/key pair from "/
5月 25 22:01:59 k8s-master kubelet[6066]: W0525 22:01:59.544845    6066 container_manager_linux.go:912] CPUAccounting not enabl
5月 25 22:01:59 k8s-master kubelet[6066]: W0525 22:01:59.544855    6066 container_manager_linux.go:915] MemoryAccounting not en
5月 25 22:01:59 k8s-master kubelet[6066]: W0525 22:01:59.544888    6066 container_manager_linux.go:912] CPUAccounting not enabl
5月 25 22:01:59 k8s-master kubelet[6066]: W0525 22:01:59.544892    6066 container_manager_linux.go:915] MemoryAccounting not en
5月 25 22:01:59 k8s-master kubelet[6066]: I0525 22:01:59.568642    6066 server.go:646] --cgroups-per-qos enabled, but --cgroup-
5月 25 22:01:59 k8s-master kubelet[6066]: F0525 22:01:59.568815    6066 server.go:274] failed to run Kubelet: running with swap
5月 25 22:01:59 k8s-master systemd[1]: kubelet.service: main process exited, code=exited, status=255/n/a
5月 25 22:01:59 k8s-master systemd[1]: Unit kubelet.service entered failed state.
5月 25 22:01:59 k8s-master systemd[1]: kubelet.service failed.
5月 25 22:02:09 k8s-master systemd[1]: kubelet.service holdoff time over, scheduling restart.
5月 25 22:02:09 k8s-master systemd[1]: Stopped kubelet: The Kubernetes Node Agent.
-- Subject: Unit kubelet.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit kubelet.service has finished shutting down.
5月 25 22:02:09 k8s-master systemd[1]: Started kubelet: The Kubernetes Node Agent.
-- Subject: Unit kubelet.service has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit kubelet.service has finished starting up.
--
-- The start-up result is done.
5月 25 22:02:09 k8s-master kubelet[6089]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config
5月 25 22:02:09 k8s-master kubelet[6089]: Flag --cgroup-driver has been deprecated, This parameter should be set via the config
5月 25 22:02:09 k8s-master kubelet[6089]: I0525 22:02:09.816728    6089 server.go:417] Version: v1.18.3
5月 25 22:02:09 k8s-master kubelet[6089]: I0525 22:02:09.817028    6089 plugins.go:100] No cloud provider specified.
5月 25 22:02:09 k8s-master kubelet[6089]: I0525 22:02:09.817041    6089 server.go:837] Client rotation is on, will bootstrap in
5月 25 22:02:09 k8s-master kubelet[6089]: I0525 22:02:09.820725    6089 certificate_store.go:130] Loading cert/key pair from "/
5月 25 22:02:09 k8s-master kubelet[6089]: W0525 22:02:09.821336    6089 container_manager_linux.go:912] CPUAccounting not enabl
5月 25 22:02:09 k8s-master kubelet[6089]: W0525 22:02:09.821346    6089 container_manager_linux.go:915] MemoryAccounting not en
5月 25 22:02:09 k8s-master kubelet[6089]: W0525 22:02:09.821381    6089 container_manager_linux.go:912] CPUAccounting not enabl
5月 25 22:02:09 k8s-master kubelet[6089]: W0525 22:02:09.821385    6089 container_manager_linux.go:915] MemoryAccounting not en
5月 25 22:02:09 k8s-master kubelet[6089]: I0525 22:02:09.844321    6089 server.go:646] --cgroups-per-qos enabled, but --cgroup-
5月 25 22:02:09 k8s-master kubelet[6089]: F0525 22:02:09.844491    6089 server.go:274] failed to run Kubelet: running with swap
5月 25 22:02:09 k8s-master systemd[1]: kubelet.service: main process exited, code=exited, status=255/n/a
5月 25 22:02:09 k8s-master systemd[1]: Unit kubelet.service entered failed state.
5月 25 22:02:09 k8s-master systemd[1]: kubelet.service failed.

又是没有关闭交换空间的问题,关闭交换空间:swapoff -a.找个方法永久关闭交换空间,注释掉最后那一行即可。

#
# /etc/fstab
# Created by anaconda on Tue Oct 29 23:56:12 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/centos-root /                       xfs     defaults        0 0
UUID=3231dabf-3131-4282-a18f-71f680af55d3 /boot                   xfs     defaults        0 0
#/dev/mapper/centos-swap swap                    swap    defaults        0 0

现在执行命令systemctl start kubelet,可以看到master已经ok了:

[root@k8s-master ~]# kubectl get nodes
NAME          STATUS     ROLES    AGE   VERSION
k8s-master    Ready      master   34h   v1.18.3
k8s-node-01   NotReady   <none>   34h   v1.18.3
k8s-node-02   NotReady   <none>   34h   v1.18.3

对node节点执行一下命令:

swapoff -a
systemctl start kubelet

可以看到node节点也Ready了,最后别忘了永久关闭交换空间,以及设置kubelet开机时启动:

systemctl enable kubelet

运行第一个容器实例,发现报错:大概意思是replicas这个参数现在以及不支持了。

[root@k8s-master ~]# kubectl run my-first-nginx --image=nginx --replicas=2 --port=80
Flag --replicas has been deprecated, has no effect and will be removed in the future.
pod/my-first-nginx created

查看发现pod被创建了,但是deployment没有创建:

[root@k8s-master ~]# kubectl get pods
NAME             READY   STATUS    RESTARTS   AGE
my-first-nginx   1/1     Running   0          10m

[root@k8s-master ~]# kubectl get deployment
No resources found in default namespace.

解决方案就是用kubectl create代替这个kubectl run.
如何删除pod:

 kubectl delete pod my-first-nginx
### Kubernetes 集群重启操作指南与故障排查 #### 一、Kubernetes 集群重启概述 在 Kubernetes 中,集群重启通常涉及多个组件的操作。这些组件包括 Master 节点上的控制平面(API Server、Controller Manager 和 Scheduler),以及 Worker 节点上的 kubelet 和容器运行时环境(如 Docker 或 containerd)。为了确保服务连续性和数据一致性,在执行任何大规模重启之前,建议先备份配置文件和重要资源。 对于某些场景下的部分组件重启可以采用滚动更新的方式完成而无需完全停机整个集群[^1]。 --- #### 二、具体操作方法 ##### 1. **Master 节点重启** 如果需要重启 Master 节点,则可以通过以下命令逐一停止并重新启动各个核心服务: ```bash sudo systemctl stop kube-apiserver.service \ kube-controller-manager.service \ kube-scheduler.service # 等待几秒后再依次启动它们 sudo systemctl start kube-apiserver.service \ kube-controller-manager.service \ kube-scheduler.service ``` 上述过程适用于单个 master 的情况;如果是高可用架构下多台 master 组成的情况则需更加谨慎处理以防止脑裂现象发生[^2]。 ##### 2. **Worker 节点重启** 针对 worker 节点而言,主要关注的是 `kubelet` 这个守护进程的状态及其依赖项比如 cgroup driver 设置是否匹配等问题已经提到过一次。下面给出通用做法来安全地重置某个节点状态: ```bash kubectl drain <node-name> --ignore-daemonsets --delete-emptydir-data sudo systemctl restart docker kubelet kubectl uncordon <node-name> ``` 这里通过 kubectl 命令将该节点标记为不可调度(unready),驱逐上面运行的工作负载到其他健康节点上之后再做实际物理机器层面或者软件层面上的动作最后恢复其正常工作模式即可。 另外值得注意的是当遇到像 etcd 数据库这样的有状态应用实例所在的特殊位置时候要格外小心对待因为涉及到持久化存储管理等方面的知识点。 --- #### 三、常见问题分析及解决方案 | **症状描述** | **可能原因** | **解决办法** | |--------------|------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------| | Pod 不就绪 | CNI 插件未正确初始化或网络策略冲突 | 查看相关日志 `/var/log/kubelet.log`,确认插件安装成功与否,必要时卸载重配 | | Etcd 同步失败| 时间不同步导致证书验证错误 | 使用 ntp 客户端同步各服务器时间;检查 ssl/tls 参数设置准确性 | | Kube-proxy异常| iptables 规则混乱 | 清理旧版残留规则:`iptables -F && iptables -X`;依据官方文档调整代理模式(如 ipvs 替代原生方式) | 以上表格总结了几类典型的运维难题及其对应的调试思路供参考使用. --- #### 四、自动化工具推荐 除了手动干预外还可以借助一些开源项目简化日常维护流程例如 Prometheus+Grafana 实现监控告警功能及时发现潜在风险提前预防事故扩大范围;Ansible Playbook 编写标准化脚本批量部署升级减少人为失误概率等等都是不错的选择方向值得深入探索实践一番. ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值