Kubernetes воссоздает модуль, если узел переходит в автономный режим

Question

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

Если один модуль запущен на одном конкретном узле, и если я его выключил, потребуется ~5 минут, чтобы воссоздать модуль на другом онлайн-узле.

Я проверил все возможные файлы конфигурации, также установил все флаги pod-eviction-timeout, горизонтальный-pod-autoscaler-downscale, горизонтальный-pod-autoscaler-downscale-delay, но он все еще не работает.

Текущая конфигурация диспетчера контроллера куба:

spec:
 containers:
 - command:
   - kube-controller-manager
   - --address=192.168.5.135
   - --allocate-node-cidrs=false
   - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
   - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
   - --client-ca-file=/etc/kubernetes/pki/ca.crt
   - --cluster-cidr=192.168.5.0/24
   - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
   - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
   - --controllers=*,bootstrapsigner,tokencleaner
   - --kubeconfig=/etc/kubernetes/controller-manager.conf
   - --leader-elect=true
   - --node-cidr-mask-size=24
   - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
   - --root-ca-file=/etc/kubernetes/pki/ca.crt
   - --service-account-private-key-file=/etc/kubernetes/pki/sa.key
   - --use-service-account-credentials=true
   - --horizontal-pod-autoscaler-downscale-delay=20s
   - --horizontal-pod-autoscaler-sync-period=20s
   - --node-monitor-grace-period=40s
   - --node-monitor-period=5s
   - --pod-eviction-timeout=20s
   - --use-service-account-credentials=true
   - --horizontal-pod-autoscaler-downscale-stabilization=20s
image: k8s.gcr.io/kube-controller-manager:v1.13.0

Спасибо.

Answer 1

Если в определении модуля присутствуют исключения на основе заражения, диспетчер контроллера не сможет выселить модуль, который допускает заражение. Даже если вы не определяете политику выселения в своей конфигурации, она получает политику по умолчанию, поскольку подключаемый модуль контроллера допуска Default Toleration Seconds включен по умолчанию.

Плагин контроллера допуска в секундах допуска по умолчанию настраивает ваш модуль, как показано ниже:

tolerations:
- key: node.kubernetes.io/not-ready
  effect: NoExecute
  tolerationSeconds: 300
- key: node.kubernetes.io/unreachable
  operator: Exists
  effect: NoExecute
  tolerationSeconds: 300

Вы можете проверить это, проверив определение своего модуля:

kubectl get pods -o yaml -n <namespace> <pod-name>`

В соответствии с указанным выше допуском для воссоздания модуля на другом готовом узле требуется более 5 минут, поскольку модуль может выдерживать not-readyпортят до 5 минут. В этом случае, даже если вы установите--pod-eviction-timeout до 20 секунд диспетчер контроллеров ничего не может сделать из-за допусков.

Но почему это занимает больше 5 минут? Поскольку узел будет считаться неработающим после--node-monitor-grace-periodкоторый по умолчанию равен 40 секундам. После этого запускается таймер допуска пакета.

---

Рекомендуемое решение

Если вы хотите, чтобы ваш кластер быстрее реагировал на простои узлов, вам следует использовать taints и допуски, не изменяя параметры. Например, вы можете определить свой модуль, как показано ниже:

tolerations:
- key: node.kubernetes.io/not-ready
  effect: NoExecute
  tolerationSeconds: 0
- key: node.kubernetes.io/unreachable
  effect: NoExecute
  tolerationSeconds: 0

С указанным выше допуском ваш модуль будет воссоздан на готовом узле сразу после того, как текущий узел помечен как не готовый. Это должно занять меньше минуты, так как--node-monitor-grace-period по умолчанию - 40 секунд.

Доступные Варианты

Если вы хотите контролировать это время, ниже вы найдете множество вариантов для этого. Однако следует избегать изменения этих параметров. Если вы используете жесткие сроки, которые могут создать накладные расходы на etcd, поскольку каждый узел будет очень часто пытаться обновлять свой статус.

В дополнение к этому, в настоящее время неясно, как распространить изменения в диспетчере контроллеров, сервере api и конфигурации kubelet на все узлы в живом кластере. См. Раздел "Проблема отслеживания" для изменения кластера и динамической конфигурации Kubelet. На момент написания этой статьи реконфигурация кублета узла в живом кластере находится в стадии бета-тестирования.

Вы можете настроить плоскость управления и кубелет на этапе инициализации или присоединения kubeadm. Дополнительные сведения см. В разделах Настройка конфигурации плоскости управления с помощью kubeadm и Настройка каждого kubelet в кластере с помощью kubeadm.

Предполагая, что у вас есть кластер с одним узлом:

• диспетчер контроллера включает:
  • --node-monitor-grace-period по умолчанию 40 с
  • --node-monitor-period по умолчанию 5 с
  • --pod-eviction-timeout по умолчанию 5 мин.
• Сервер API включает:
  • --default-not-ready-toleration-seconds по умолчанию 300
  • --default-unreachable-toleration-seconds по умолчанию 300
• кубелет включает:
  • --node-status-update-frequency по умолчанию 10 с

Если вы настроили кластер с kubeadm вы можете изменить:

• /etc/kubernetes/manifests/kube-controller-manager.yaml для опций диспетчера контроллеров.
• /etc/kubernetes/manifests/kube-apiserver.yaml для параметров сервера api.

Примечание. Изменение этих файлов приведет к изменению конфигурации и перезапуску соответствующего модуля в узле.

Чтобы изменить kubelet config вы можете добавить строку ниже:

KUBELET_EXTRA_ARGS="--node-status-update-frequency=10s"

Чтобы /etc/default/kubelet (для ДОБ), или /etc/sysconfig/kubelet (для RPM), а затем перезапустите службу kubelet:

sudo systemctl daemon-reload && sudo systemctl restart kubelet

Answer 2

Вот что происходит, когда узел умирает или переходит в автономный режим:

1. Кубелец сообщает свой статус мастерам --node-status-update-fequency=10s,
2. Узел отключается
3. kube-controller-manager контролирует все узлы --node-monitor-period=5s
4. kube-controller-manager увидит, что узел не отвечает и имеет льготный период --node-monitor-grace-period=40s пока он не считает узел нездоровым. PS: этот параметр должен быть в N x node-status-update-fequency
5. Как только узел помечен как нездоровый, kube-controller-manager удалит модули на основе --pod-eviction-timeout=5m

Теперь, если вы настроили параметр pod-eviction-timeout скажем 30 секунд, это все равно займет

 node status update frequency: 10s
 node-monitor-period: 5s
 node-monitor-grace-period: 40s
 pod-eviction-timeout: 30s

Total 70 seconds to evict the pod from node node-status-update-fequecy and node-monitor-grace-period время имеет значение в node-monitor-grace-period также. Вы также можете настроить эти переменные, чтобы еще больше снизить общее время вытеснения узла.

Это мой файл kube-controller-manager.yaml (находится в /etc/kubernetes/manifes для kubeadm):

containers:
  - command:
    - kube-controller-manager
    - --controllers=*,bootstrapsigner,tokencleaner
    - --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt
    - --cluster-signing-key-file=/etc/kubernetes/pki/ca.key
    - --pod-eviction-timeout=30s
    - --address=127.0.0.1
    - --use-service-account-credentials=true
    - --kubeconfig=/etc/kubernetes/controller-manager.conf

Я эффективно вижу, как мои стручки выселяют в 70s как только я выключаю свой узел.

EDIT2:

Выполните следующую команду на мастере и убедитесь, что --pod-eviction-timeout приходит как 20s,

[root@ip-10-0-1-12]# docker ps --no-trunc | grep "kube-controller-manager"

9bc26f99dcfe6ac0e7b2abf22bff67af6060561ee8c0cdff08e11c3a479f182c   sha256:40c8d10b2d11cbc3db2e373a5ffce60dd22dbbf6236567f28ac6abb7efbfc8a9                     
"kube-controller-manager --leader-elect=true --use-service-account-credentials=true --root-ca-file=/etc/kubernetes/pki/ca.crt --cluster-signing-key-file=/etc/kubernetes/pki/ca.key \
**--pod-eviction-timeout=30s** --address=127.0.0.1 --controllers=*,bootstrapsigner,tokencleaner --kubeconfig=/etc/kubernetes/controller-manager.conf --service-account-private-key-file=/etc/kubernetes/pki/sa.key --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt --allocate-node-cidrs=true --cluster-cidr=192.168.13.0/24 --node-cidr-mask-size=24"        

Если здесь --pod-eviction-timeout является 5m и не 20s тогда ваши изменения не будут применены должным образом.