8

我正在使用 Kubernetes v1.13.0。我的主节点还充当工作节点，因此除了控制平面 pod 之外，它还运行着工作负载 pod。

我的 master 上的 kubelet 日志显示以下几行：

eviction_manager.go:340] eviction manager：必须驱逐 pod(s) 以回收临时存储
eviction_manager.go:358] eviction manager: pods ranked for eviction: kube-controller-manager-vm2_kube-system(1631c2c238e0c5117acac446b26d9f8c), kube-apiserver-vm2_kube-system(ce43eba098d219e13901c4a0b829f43b), etcd-vm2_kube-system(91ab2b0ddf4484a5ac6ee9661dbd0b1c)

一旦 kube-apiserver pod 被驱逐，集群就会变得不可用。

我能做些什么来解决这个问题？我应该添加更多的临时存储吗？我该怎么做呢？这意味着向我的主机上的根分区添加更多空间？

我的理解是，临时存储由/var/log和/var/lib/kubelet文件夹组成，它们都位于根分区下。

df -h我的主持人上的一个节目：

已使用的文件系统大小可用使用百分比已安装在
/dev/vda1 39G 33G 6.2G 85% /

所以看起来根分区还有很多内存，没有磁盘压力。那么是什么导致了这个问题呢？我的一些worker pod肯定在做一些疯狂的存储，但它仍然是6G，似乎有足够的空间。

向根分区添加更多空间会暂时解决此问题吗？

kubectl describe vm2提供以下信息：

条件：
  类型 状态 LastHeartbeatTime LastTransitionTime 原因消息
  ---- ------ ----- ------------------ ----- - --------
  MemoryPressure False 2019 年 1 月 11 日星期五 21:25:43 +0000 2018 年 12 月 5 日星期三 19:16:41 +0000 KubeletHasSufficientMemory kubelet 有足够的可用内存
  DiskPressure False 2019 年 1 月 11 日星期五 21:25:43 +0000 2019 年 1 月 11 日星期五 20:58:07 +0000 KubeletHasNoDiskPressure kubelet 没有磁盘压力
  PIDPressure False 2019 年 1 月 11 日星期五 21:25:43 +0000 2018 年 12 月 5 日星期三 19:16:41 +0000 KubeletHasSufficientPID kubelet 有足够的 PID 可用
  Ready True 2019 年 1 月 11 日星期五 21:25:43 +0000 2018 年 12 月 6 日星期四 17:00:02 +0000 KubeletReady kubelet 正在发布就绪状态。启用 AppArmor
容量：
 中央处理器：8
 临时存储：40593708Ki
 巨页-1Gi: 0
 巨页-2Mi: 0
 内存：32946816Ki
 豆荚：110
可分配：
 中央处理器：8
 临时存储：37411161231
 巨页-1Gi: 0
 巨页-2Mi: 0
 内存：32844416Ki
 豆荚：110

在我看来，临时存储存在压力，驱逐管理器正试图通过驱逐最近最少使用的 pod 来回收一些存储。但它不应该驱逐控制平面 pod，否则集群将无法使用。

目前，Kubelet 驱逐控制平面 pod。然后我尝试通过在/etc/kubernetes/manifests文件中添加和删除空格来手动启动 apiserver 和其他控制平面 pod。这确实启动了 apiserver，但随后它又被驱逐了。理想情况下，Kubelet 应确保其中的静态 Pod/etc/kubernetes/manifests始终处于开启状态并得到妥善管理。

我试图了解这里发生了什么，以及如何解决这个问题，以便我的 kubernetes 集群变得更加健壮，并且我不必继续手动重新启动 apiserver。

4

2 回答 2

10

我遇到了同样的问题，并通过更改 evictionHard 的阈值来解决它。

看着/etc/systemd/system/kubelet.service.d/10-kubeadm.conf我有：

[Service]
Environment="KUBELET_KUBECONFIG_ARGS=--bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf"
Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml"
# This is a file that "kubeadm init" and "kubeadm join" generates at runtime, populating the KUBELET_KUBEADM_ARGS variable dynamically
EnvironmentFile=-/var/lib/kubelet/kubeadm-flags.env
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
ExecStart=
ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS

所以我看到我的 kubelet 配置文件是/var/lib/kubelet/config.yaml

打开我将 evitionHard 设置更改为（我认为它们之前是 10% 或 15%）：

...
evictionHard:
  imagefs.available: 1%
  memory.available: 100Mi
  nodefs.available: 1%
  nodefs.inodesFree: 1%
...

还有--experimental-allocatable-ignore-eviction（https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/）设置应该完全禁用驱逐。

于 2019-01-30T15:13:32.513 回答
1

这是因为你的 eviction nodefs 和 imagefs % 的 kubelet config 设置太高了，设置得低一些，问题就解决了： Modify config in/var/lib/kubelet/config.yaml

找出部分 evction 并将百分比设置得更低，如下所示：

 evictionHard:
   imagefs.available: 1%
   memory.available: 100Mi
   nodefs.available: 1%
   nodefs.inodesFree: 1%
于 2020-02-05T03:34:47.413 回答