如何解决Kubernetes:集群正在运行但对更改无响应,无法检索日志
我有一个在AWS EC2上运行k8s版本1.12.8
的现有集群。该集群包含多个Pod,其中一些Pod服务于Web流量,而另一些Pod配置为计划的CronJob。集群在当前配置中至少可以正常运行6个月,而CronJobs每5分钟运行一次。
最近,CronJobs停了下来。通过kubectl
查看Pod,显示所有计划运行的CronJob上次运行大致在同一时间。发送到AWS Cloudwatch的日志未显示错误输出,并在显示上一次运行的kubectl
同时停止。
在尝试诊断此问题时,我发现了更广泛的集群模式,无法响应更改,例如:我无法通过kubectl检索日志或节点。
我删除了副本集中的Pod,它们再也不会返回。我已经在副本集上设置了自动缩放值,但是什么也没发生。
对主实例上的kubelet
日志的调查显示出重复的错误,这与首次发现故障的时间一致:
I0805 03:17:54.597295 2730 kubelet.go:1928] SyncLoop (PLEG): "kube-scheduler-ip-x-x-x-x.z-west-y.compute.internal_kube-system(181xxyyzz)",event: &pleg.PodLifecycleEvent{ID:"181xxyyzz",Type:"ContainerDied",Data:"405ayyzzz"}
...
E0805 03:18:10.867737 2730 kubelet_node_status.go:378] Error updating node status,will retry: failed to patch status "{\"status\":{\"$setElementOrder/conditions\":[{\"type\":\"NetworkUnavailable\"},{\"type\":\"OutOfDisk\"},{\"type\":\"MemoryPressure\"},{\"type\":\"DiskPressure\"},{\"type\":\"PIDPressure\"},{\"type\":\"Ready\"}],"conditions\":[{\"lastHeartbeatTime\":\"2020-08-05T03:18:00Z\",\"type\":\"OutOfDisk\"},{\"lastHeartbeatTime\":\"2020-08-05T03:18:00Z\",\"type\":\"MemoryPressure\"},\"type\":\"DiskPressure\"},\"type\":\"PIDPressure\"},\"type\":\"Ready\"}]}}" for node "ip-172-20-60-88.eu-west-2.compute.internal": Patch https://127.0.0.1/api/v1/nodes/ip-x-x-x-x.z-west-y.compute.internal/status?timeout=10s: context deadline exceeded (Client.Timeout exceeded while awaiting headers)
...
E0805 03:18:20.869436 2730 kubelet_node_status.go:378] Error updating node status,will retry: error getting node "ip-172-20-60-88.eu-west-2.compute.internal": Get https://127.0.0.1/api/v1/nodes/ip-172-20-60-88.eu-west-2.compute.internal?timeout=10s: context deadline exceeded (Client.Timeout exceeded while awaiting headers)
在主节点上运行docker ps
显示k8s_kube-controller-manager_kube-controller-manager
和k8s_kube-scheduler_kube-scheduler
容器都是在6天前启动的,而其他k8s容器则是8个月以上。
tl; dr
我的主节点上的一个容器(可能是kube-scheduler
,kube-controller-manager
或两者都死了)。容器已恢复,但无法与现有节点通信-这将阻止满足所有计划的CronJob或新部署。
如何在主节点上重新配置kubelet和相关服务以再次与工作节点通信?
解决方法
摘自Troubleshoot Clusters上的文档
更深入地研究集群需要登录到相关计算机。这是相关日志文件的位置。 (请注意,在基于systemd的系统上,您可能需要改用journalctl
)
主节点
/var/log/kube-apiserver.log
-API服务器,负责提供API
/var/log/kube-scheduler.log
-计划程序,负责制定计划决策
/var/log/kube-controller-manager.log
-管理复制控制器的控制器
工作节点
/var/log/kubelet.log
-Kubelet,负责在节点上运行容器
/var/log/kube-proxy.log
-Kube Proxy,负责服务负载平衡
获取日志的另一种方法是使用docker ps
获取containerid
,然后使用docker logs containerid
如果您具有(应该)使用prometheus和Grafana进行的监视系统设置,则可以检查指标,例如API Server容器上的cpu负载高
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。