Kubernetes: игнорируемые настройки времени ожидания выселения пода

Созданный на 27 февр. 2019  ·  15Комментарии  ·  Источник: kubernetes/kubernetes

Пожалуйста, используйте этот шаблон при сообщении об ошибке и предоставьте как можно больше информации. Невыполнение этого может привести к тому, что ваша ошибка не будет исправлена ​​своевременно. Благодаря! Если проблема связана с безопасностью, сообщите об этом в частном порядке через https://kubernetes.io/security/.

Что произошло : я изменил настройки pod-eviction-timeout kube-controller-manager на главном узле (чтобы уменьшить время, по истечении которого k8s повторно создаст под в случае сбоя узла). Значение по умолчанию 5 минут, я настроил 30 секунд. С помощью команды sudo docker ps --no-trunc | grep "kube-controller-manager" я проверил, что модификация была успешно применена:

kubeadmin<strong i="10">@nodetest21</strong>:~$ sudo docker ps --no-trunc | grep "kube-controller-manager"
387261c61ee9cebce50de2540e90b89e2bc710b4126a0c066ef41f0a1fb7cf38   sha256:0482f640093306a4de7073fde478cf3ca877b6fcc2c4957624dddb2d304daef5                         "kube-controller-manager --address=127.0.0.1 --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf --client-ca-file=/etc/kubernetes/pki/ca.crt --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 --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 --pod-eviction-timeout=30s" 

Я применил базовое развертывание с двумя репликами:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      containers:
      - image: busybox
        command:
        - sleep
        - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always

Первый модуль создается на первом рабочем узле, второй модуль создается на втором рабочем узле:

NAME         STATUS   ROLES    AGE   VERSION
nodetest21   Ready    master   34m   v1.13.3
nodetest22   Ready    <none>   31m   v1.13.3
nodetest23   Ready    <none>   30m   v1.13.3

NAMESPACE     NAME                                 READY   STATUS    RESTARTS   AGE   IP          NODE         NOMINATED NODE   READINESS GATES
default       busybox-74b487c57b-5s6g7             1/1     Running   0          13s   10.44.0.2   nodetest22   <none>           <none>
default       busybox-74b487c57b-6zdvv             1/1     Running   0          13s   10.36.0.1   nodetest23   <none>           <none>
kube-system   coredns-86c58d9df4-gmcjd             1/1     Running   0          34m   10.32.0.2   nodetest21   <none>           <none>
kube-system   coredns-86c58d9df4-wpffr             1/1     Running   0          34m   10.32.0.3   nodetest21   <none>           <none>
kube-system   etcd-nodetest21                      1/1     Running   0          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-apiserver-nodetest21            1/1     Running   0          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-controller-manager-nodetest21   1/1     Running   0          20m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-proxy-6mcn8                     1/1     Running   1          31m   10.0.1.5    nodetest22   <none>           <none>
kube-system   kube-proxy-dhdqj                     1/1     Running   0          30m   10.0.1.6    nodetest23   <none>           <none>
kube-system   kube-proxy-vqjg8                     1/1     Running   0          34m   10.0.1.4    nodetest21   <none>           <none>
kube-system   kube-scheduler-nodetest21            1/1     Running   1          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   weave-net-9qls7                      2/2     Running   3          31m   10.0.1.5    nodetest22   <none>           <none>
kube-system   weave-net-h2cb6                      2/2     Running   0          33m   10.0.1.4    nodetest21   <none>           <none>
kube-system   weave-net-vkb62                      2/2     Running   0          30m   10.0.1.6    nodetest23   <none>           <none>

Чтобы проверить правильность вытеснения пода, я выключил первый рабочий узел. Примерно через 1 минуту статус первого рабочего узла изменился на NotReady, затем
Мне пришлось подождать +5 минут (что является тайм-аутом удаления модуля по умолчанию), чтобы модуль на выключенном узле был воссоздан на другом узле.

Что вы ожидали :
После того, как статус узла сообщает "NotReady", модуль должен быть воссоздан на другом узле через 30 секунд вместо 5 минут по умолчанию!

Как это воспроизвести (максимально минимально и точно) :
Создайте три узла. Запустите Kubernetes на первом узле ( sudo kubeadm init ), примените сетевой плагин ( kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')" ), затем присоединитесь к двум другим узлам (например: kubeadm join 10.0.1.4:6443 --token xdx9y1.z7jc0j7c8g8lpjog --discovery-token-ca-cert-hash sha256:04ae8388f607755c14eed702a23fd47802d5512e092b08add57040a2ae0736ac ).
Добавьте параметр pod-eviction-timeout в Kube Controller Manager на главном узле: sudo vi /etc/kubernetes/manifests/kube-controller-manager.yaml :

apiVersion: v1
kind: Pod
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/critical-pod: ""
  creationTimestamp: null
  labels:
    component: kube-controller-manager
    tier: control-plane
  name: kube-controller-manager
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-controller-manager
    - --address=127.0.0.1
    - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --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
    - --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
    - --pod-eviction-timeout=30s

(yaml усечен, здесь показана только соответствующая первая часть).

Убедитесь, что настройки применены:
sudo docker ps --no-trunc | grep "kube-controller-manager"

Примените развертывание с двумя репликами, убедитесь, что один модуль создан на первом рабочем узле, а второй - на втором рабочем узле.
Выключите один из узлов и проверьте время, прошедшее между событием, когда узел сообщает «NotReady» и созданный модуль повторно.

Что еще нам нужно знать? :
У меня такая же проблема в среде с несколькими мастерами.

Окружающая среда :

  • Версия Kubernetes (используйте kubectl version ): v1.13.3
    Версия клиента: version.Info {Major: «1», Minor: «13», GitVersion: «v1.13.3», GitCommit: «721bfa751924da8d1680787490c54b9179b1fed0», GitTreeState: «clean», BuildDate: «2019-02-01T20: 08: 12Z ", GoVersion:" go1.11.5 ", компилятор:" gc ", платформа:" linux / amd64 "}
    Версия сервера: version.Info {Major: «1», Minor: «13», GitVersion: «v1.13.3», GitCommit: «721bfa751924da8d1680787490c54b9179b1fed0», GitTreeState: «clean», BuildDate: «2019-02-01T20: 00: 57Z ", GoVersion:" go1.11.5 ", компилятор:" gc ", платформа:" linux / amd64 "}
  • Облачный провайдер или конфигурация оборудования: виртуальная машина Azure
  • ОС (например: cat /etc/os-release ): NAME = "Ubuntu" VERSION = "16.04.5 LTS (Xenial Xerus)"
  • Ядро (например, uname -a ): Linux nodetest21 4.15.0-1037-azure # 39 ~ 16.04.1-Ubuntu SMP Вт, 15 января 17:20:47 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux
  • Установить инструменты:
  • Прочее: Docker v18.06.1-ce
kinbug siapps sinode

Самый полезный комментарий

Спасибо за отзыв, Шеф Александр!
Такова ситуация, написали вы. Я проверил стручки и убедился, что стручкам присвоены значения по умолчанию для допуска:

kubectl describe pod busybox-74b487c57b-95b6n | grep -i toleration -A 2
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s

Поэтому я просто добавил свои собственные значения в развертывание:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      tolerations:
      - key: "node.kubernetes.io/unreachable"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      - key: "node.kubernetes.io/not-ready"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      containers:
      - image: busybox
        command:
        - sleep
        - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always

После применения развертывания в случае сбоя узла статус узла меняется на «NotReady», а затем поды создаются заново через 2 секунды.

Таким образом, нам больше не нужно иметь дело с таймаутом выселения пода, тайм-аут может быть установлен на основе пода! Круто!

Еще раз спасибо за помощь!

Все 15 Комментарий

@ kubernetes / сиг-узел-ошибки
@ kubernetes / сиг-приложения-ошибки

@danielloczi :
@ kubernetes / сиг-узел-ошибки, @ кубернетес / сиг-приложения-ошибки

В ответ на это :

@ kubernetes / сиг-узел-ошибки
@ kubernetes / сиг-приложения-ошибки

Инструкции по взаимодействию со мной с помощью PR-комментариев доступны здесь . Если у вас есть вопросы или предложения, связанные с моим поведением, сообщите о проблеме в репозиторий kubernetes / test-infra .

Я также столкнулся с этой проблемой при тестировании установки меньшего времени ожидания выселения. После того, как я некоторое время копался в этом, я понял, что причина в новом TaintBasedEvictions.

В версии 1.13 функция TaintBasedEvictions повышена до бета-версии и включена по умолчанию, следовательно, taints автоматически добавляются NodeController (или kubelet), а обычная логика для удаления подов с узлов на основе Ready NodeCondition отключена.

Установка для этого флага функции значения false приводит к тому, что поды удаляются, как и ожидалось. У меня не было времени на поиск кода выселения на основе заражения, но я предполагаю, что мы не используем в нем этот флаг тайм-аута выселения.

Подробнее об этом. Если для TaintBasedEvictions установлено значение true, вы можете установить время выселения ваших подов в пределах его спецификации в соответствии с допусками:
https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/#taint -based-выселения
Значения по умолчанию для них устанавливаются контроллером допуска: https://github.com/kubernetes/kubernetes/blob/master/plugin/pkg/admission/defaulttolerationseconds/admission.go#L34
Эти два флага можно установить через kube-apiserver, и они должны дать тот же эффект.

// Controller will not proactively sync node health, but will monitor node
// health signal updated from kubelet. There are 2 kinds of node healthiness
// signals: NodeStatus and NodeLease. NodeLease signal is generated only when
// NodeLease feature is enabled. If it doesn't receive update for this amount
// of time, it will start posting "NodeReady==ConditionUnknown". The amount of
// time before which Controller start evicting pods is controlled via flag
// 'pod-eviction-timeout'.
// Note: be cautious when changing the constant, it must work with
// nodeStatusUpdateFrequency in kubelet and renewInterval in NodeLease
// controller. The node health signal update frequency is the minimal of the
// two.
// There are several constraints:
// 1. nodeMonitorGracePeriod must be N times more than  the node health signal
//    update frequency, where N means number of retries allowed for kubelet to
//    post node status/lease. It is pointless to make nodeMonitorGracePeriod
//    be less than the node health signal update frequency, since there will
//    only be fresh values from Kubelet at an interval of node health signal
//    update frequency. The constant must be less than podEvictionTimeout.
// 2. nodeMonitorGracePeriod can't be too large for user experience - larger
//    value takes longer for user to see up-to-date node health.

Спасибо за отзыв, Шеф Александр!
Такова ситуация, написали вы. Я проверил стручки и убедился, что стручкам присвоены значения по умолчанию для допуска:

kubectl describe pod busybox-74b487c57b-95b6n | grep -i toleration -A 2
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s

Поэтому я просто добавил свои собственные значения в развертывание:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: busybox
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: busybox
  template:
    metadata:
      labels:
        app: busybox
    spec:
      tolerations:
      - key: "node.kubernetes.io/unreachable"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      - key: "node.kubernetes.io/not-ready"
        operator: "Exists"
        effect: "NoExecute"
        tolerationSeconds: 2
      containers:
      - image: busybox
        command:
        - sleep
        - "3600"
        imagePullPolicy: IfNotPresent
        name: busybox
      restartPolicy: Always

После применения развертывания в случае сбоя узла статус узла меняется на «NotReady», а затем поды создаются заново через 2 секунды.

Таким образом, нам больше не нужно иметь дело с таймаутом выселения пода, тайм-аут может быть установлен на основе пода! Круто!

Еще раз спасибо за помощь!

@danielloczi Привет, danielloczi, как решить эту проблему? Я тоже встречаюсь с этой проблемой

@ 323929 Я думаю, что @danielloczi не заботится о параметре pod-eviction-timeout в kube-controller-manager, но решает его с помощью Taint based Evictions , Я тестировал с Taint based Evictions , он работал для меня.

Правильно: я просто начал использовать Taint based Eviction .

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

+1 за возможность настроить его для всего кластера. настройка для каждого модуля или развертывания редко бывает полезной: в большинстве случаев разумное глобальное значение намного удобнее, а текущее значение по умолчанию 5 м для многих случаев является слишком большим.

пожалуйста, повторно откройте этот вопрос.

Я столкнулся с той же проблемой: есть ли способ отключить выселение на основе Taint и что таймаут pod-eviction-timeout работает в глобальном режиме?

Я столкнулся с той же проблемой: есть ли способ отключить выселение на основе Taint и что таймаут pod-eviction-timeout работает в глобальном режиме?

Я думаю, что вы можете настроить глобальное вытеснение подов через apiserver: https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
Я не пробовал это, но, как я вижу, есть варианты: --default-not-ready-допуск-секунды и --default-unreachable-толерантность-секунды.

Почему эта ошибка была отмечена как закрытая? Похоже, что первоначальная проблема не решена, а только обоснована.
Мне непонятно, почему не работает флаг pod-eviction-timeout

та же проблема

Была ли эта страница полезной?
0 / 5 - 0 рейтинги