Question

我有一个在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\"},{\"lastHeartbeatTime\":\"2020-08-05T03:18:00Z\",\"type\":\"DiskPressure\"},{\"lastHeartbeatTime\":\"2020-08-05T03:18:00Z\",\"type\":\"PIDPressure\"},{\"lastHeartbeatTime\":\"2020-08-05T03:18:00Z\",\"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和相关服务以再次与工作节点通信？

Answer 1

摘自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负载高

Kubernetes：集群正在运行但对更改无响应，无法检索日志

1 个答案: