Менеджер по выселению Kubernetes выселяет стручки самолета управления, чтобы вернуть эфемерное хранилище - PullRequest
Новая
       14

Менеджер по выселению Kubernetes выселяет стручки самолета управления, чтобы вернуть эфемерное хранилище

0 голосов
/ 12 января 2019

Я использую Kubernetes v1.13.0. Мой мастер также работает как рабочий узел, поэтому на нем работают модули рабочей нагрузки, кроме модулей плоскости управления.

В логах kubelet моего мастера отображаются следующие строки: 

eviction_manager.go:340] eviction manager: must evict pod(s) to reclaim ephemeral-storage
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)

Как только модуль куб-аписервер выселяется, кластер становится непригодным для использования.

Что я могу сделать, чтобы это исправить? Должен ли я добавить больше эфемерной памяти? Как бы я поступил так? Что значит добавить больше места в корневой раздел на моем хосте?

Насколько я понимаю, эфемерное хранилище состоит из папок /var/log и /var/lib/kubelet, которые находятся под корневым разделом.

A df -h на моем хосте показывает: 

Filesystem                               Size  Used Avail Use% Mounted on
/dev/vda1                                 39G   33G  6.2G  85% /

Таким образом, похоже, что корневому разделу осталось много памяти, и на диске нет давления. Так, что вызывает эту проблему? Некоторые из моих рабочих контейнеров, должно быть, делают что-то сумасшедшее с хранилищем, но все равно 6G кажется достаточно места.

Исправит ли эта проблема временное добавление дополнительного пространства в корневой раздел?

kubectl describe vm2 дает следующую информацию: 

Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Fri, 11 Jan 2019 21:25:43 +0000   Wed, 05 Dec 2018 19:16:41 +0000   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Fri, 11 Jan 2019 21:25:43 +0000   Fri, 11 Jan 2019 20:58:07 +0000   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Fri, 11 Jan 2019 21:25:43 +0000   Wed, 05 Dec 2018 19:16:41 +0000   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Fri, 11 Jan 2019 21:25:43 +0000   Thu, 06 Dec 2018 17:00:02 +0000   KubeletReady                 kubelet is posting ready status. AppArmor enabled
Capacity:
 cpu:                8
 ephemeral-storage:  40593708Ki
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32946816Ki
 pods:               110
Allocatable:
 cpu:                8
 ephemeral-storage:  37411161231
 hugepages-1Gi:      0
 hugepages-2Mi:      0
 memory:             32844416Ki
 pods:               110

Мне кажется, что на эфемерное хранилище оказывалось давление, и менеджер по выселению пытается освободить часть хранилища, высвобождая наименее недавно использованные капсулы. Но он не должен выселять стручки плоскости управления, в противном случае кластер непригоден для использования.

В настоящее время Кубеле выселяет стручки самолета управления. Затем я пытаюсь вручную запустить сервер apiserver и другие модули управления, добавляя и удаляя пробел в файлах /etc/kubernetes/manifests. Это действительно запускает apiserver, но затем он снова выселяется. В идеале, Kubelet должен обеспечивать постоянное включение и правильное управление статическими модулями в /etc/kubernetes/manifests.

Я пытаюсь понять, что здесь происходит, и как исправить эту проблему, чтобы мой кластер kubernetes стал более устойчивым, и мне не нужно продолжать перезапускать сервер вручную.

1 Ответ

0 голосов
/ 30 января 2019

У меня была такая же проблема, и я решил ее, изменив порог для выселенияHard.

Глядя на /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/)), который должен полностью отключить выселение.

...